Welcher Link wäre Ihnen recht?

Die Frage ist scherzhaft formuliert, doch muss sie ein Service Provider früher oder später für sich und sein System beantworten. Ob es nun darum geht, Suchergebnisse in einer Rechercheoberfläche aufzubereiten, Alerting-Dienste auf neue Artikel anzubieten oder ganz einfach einen Metadatensatz in einem Format wie BibTeX zu exportieren – immer hat man die Option, einen Link mit Bezug auf das durch die Metadaten beschriebene Objekt anzugeben. Welcher Link sollte dies sein, wo kommt er her und ist man sich sicher, dass er dorthin zeigt, wie man es annimmt?

Volltextlink vs. Jump-Off-Page

Beschäftigen wir uns zuerst damit, was wir anbieten wollen. Mit dem Begriff ‚Volltextlink‘ soll im Folgenden eine URL benannt werden, die direkt auf die Volltext-Datei eines elektronischen Dokumentes im Netz zeigt. Surft man diese URL an, wird – je nach lokaler Browsereinstellung und unter der URL abgelegtem Dateiformat (z.B. pdf, html, xml, ps, doc) – das Dokument als neue Seite geladen, durch ein Plug-In dargestellt oder als Download zum Speichern bzw. Öffnen mit einer externen Anwendung angeboten.

Die Alternative wäre die so genannte ‚Jump-Off-Page‘, die auch als Abstract-Seite, Metadaten-Seite oder Frontpage tituliert wird. Hier handelt es sich um eine menschenlesbare Webseite, die den Metadatensatz strukturiert und mit allerlei Links, Zusatzinformationen und Corporate Design darstellt. Günstigenfalls ist einer der Links darin ein Volltextlink. Wir reden ja über Open-Access-Publikationen. Der Volltext sollte also auf die eine oder andere Weise verfügbar sein.

Zitat DRIVER Guideline Wiki:

  • The jump-off page is an html intermediate page that is used for human readable presentations when an Item that has more than one digital object file. This situation typically occurs with dissertations (theses) with separate object files (e.g. when the thesis consists of a set of previously published articles). It also occurs when the content provider has a PDF, MS Word DOC and a HTML version of the same article.

Jetzt müsste man korrekterweise weiter fragen: Woher kommt die Jump-Off-Page, respektive woher die Metadaten darin? Sowohl Service Provider wie Open-Access-Netzwerk als auch die Dokumentenserver stellen solche Übersichten im Stil von Datenblättern oder Karteikarten da. Auf eine der beiden Jump-Off-Pages könnte ein Link potentiell zeigen.

Welche Jump-Off-Page ist zu bevorzugen? Die lokale ‚Originalseite‘ des Data Providers, die eventuell zusätzliche Metadaten oder Services enthält, die gar nicht durch das starre Korsett der OAI-PMH-Schnittstelle an den Service Provider übertragen wurden, dafür aber keine Harmonisierung erfahren haben? Oder doch die Seite des Service Providers, wo vielleicht für die OAI-PMH-Welt unsichtbare Informationen verloren sind, aber dafür aus dem Kontext der Aggregation ganz neue, eventuell repositorienübergriefende Mehrwerte verfügbar sind?

In die Entscheidung spielt nebenbei hinein, dass nur auf Service-Provider-Seite ein einheitliches Layout der Jump-Off-Pages garantiert werden kann. Vertrautheit in der Anordnung der Informationen ist ein Usability-Kriterium.

Die durch OAI-PMH gegebene Realität

Der Service Provider ’sieht‘ in erster Linie nur, was die OAI-PMH-Schnittstellen der Data Provider exponieren. Im Format ‚Dublin Core Simple‘– noch immer der verbreitetste Standard in Deutschland – gibt es das Metadatenfeld dc:identifier. Die Dublic Core Metadata Initiative schreibt hierzu, das Feld möge eine ‚unambiguous reference to the resource within a given context‘ enthalten. Die Begriffe ‚unambiguous‘ und ‚within a given context‘ lassen Interpretationspielraum. Und der wird genutzt. Bei der Aggregation sieht man verschiedene Varianten. Jump-Off-Pages hier, Volltextlinks dort. Manchmal sind Ausnahmen wie relative Pfade dabei. So etwas sollte schon auf Data-Provider-Seite im OAI-PMH-Export korrigiert werden. Andere (meist zusätzliche) Varianten sind alternative Links, URNs, DOI oder irgendeine andere Form von Persistent Identifier oder was man dafür hält.

Zitat DRIVER Guideline Wiki:

  • […] many repositories place a link to a jump-off page in dc:identifier instead of a direct link to the digital resource file

In Open-Access-Netzwerk haben wir, wie in der Harmonisierung beschrieben, extra ein Modul integriert, welches die Aufgabe hat, den Volltextlink aus den übertragenen DC-Identifiern zu bestätigen bzw. sich heuristisch über die Jump-Off-Page dem finalen Link zu nähern. Für die Rückrichtung vom Volltextlink zur Jump-Off-Page – obwohl zum Beispiel für Open-Access-Statistik interessant – hat Open-Access-Netzwerk noch kein Konzept. Fakt ist, dass auf der Jump-Off-Page häufig alternative Dateiformate vermerkt sind. Das ist eine wichtige Information. Aus technischer Sicht benötigt das System jedoch den Volltextlink, um eine maschinenlesbare Repräsentation des Volltextes für nachgeschaltete Mehrwertdienste abrufen zu können.

Wolfram Horstmann und Friedrich Summann (DRIVER Projekt) waren 2007 nicht die Ersten und auch nicht der Letzten, die diese Thematik in einem Redebeitrag auf dem Workshop ‚Technische Aspekte des DINI-Zertifikats 2007‘ aufgegriffen haben. Die Folien 16-18 zu ‚Harvesting Challenges‘ zählen das beschrieben Problem auf: ‚Links to the Document adress a jump-off page (prevent indexing the fulltext)‘. Diese Hürde geht, wie gesagt, in Open-Access-Netzwerk der Volltextfinde-Dienst an. Die DRIVER Guidelines widmen dem Thema dc:identifier einen Abschnitt.

Exkurs: Dokumentbegriff und OAI-ORE

Bevor wir jetzt eine Empfehlung abgeben, wie man das in dc:identifier abbilden könnte, verweise ich die Problematik auf ein größeres Problemfeld: Welches Dokumentmodell wenden wir eigentlich an? Links auf alternative Dateiformate, die inhaltlich die selbe Publikation darstellen, oder Publikationen aus verschiedenen Datei-Komponenten, sind nur ein Teilproblem dessen. Hinzu kommen unterschiedliche Versionen einer Publiaktion, sowie die Einbettung von Dokumenten ineinander, wenn zum Beispiel ein Konferenzband verschiedene, per se unabhängige Beiträge zusammenfasst. Denkbar und teilweise bereits lokal auf einigen Dokumentenservern vermerkt sind verschiedenste Relationen, wie Volltexte zueinander einnehmen können. Das alles kulminiert in der Frage, was genau denn ein und dasselbe Dokument ist und was nicht.

Open-Access-Netzwerk stützt sich in der vorliegenden System-Version auf die Granularität, welche die OAI-PMH-Schnittstellen vorgeben. Was auf den einzelnen, in Deutschland verteilten Dokumentenservern ein Objekt ist, ist es auch in der Aggregation. Wie Beziehungen zwischen einzelnen, mittels OAI-PMH übertragen Dublin-Core-Simple-Datensätzen zu fassen sind, da gibt es aktuell keine Regelung, auch wenn die Problematik auf den einschlägigen Fachtagungen heiß diskutiert wird. Wer hier tiefer einsteigen will, sollte sich nach OAI-ORE (Object Reuse and Exchange) umschauen.

Grob gesagt, handelt es sich bei ORE um eine zusätzliche Schnittstellendefintion bzw. ein Protokoll, welches nicht nur bestehende Relationen zwischen Dokumenten abbilden kann, sondern ganz allgemein ein Konzept vorstellt, wie Dokumente unter beliebig vielen Gesichtspunkten bestimmten Gruppen (hier: Aggregationen) zugeordnet werden können. Dabei treten diese Aggregationen selbst als Mehrwertdaten auf, die verbreitet werden. Technologisch orientiert sich das Format im Übrigen an Austauschprotokollen, wie sie eher für Newsfeeds benutzt werden. Open-Access-Netzwerk verfolgt die Entwicklungen mit großem Interesse.

Benutzerführung zu Volltext und Metadaten

Kehren wir zur eigentlichen, ganz pragmatisch motivierten Problematik zurück und nehmen an, wir sind uns bereits im Klaren, welche Jump-Off-Page und welchen Volltextlink wir präferieren, und wir haben beides als Datum im System vorrätig. Was erwartet nun der Nutzer? Eine schwierige Frage.

Usability ist in dem Bereich ein Thema, das nicht unbedingt erschöpfend behandelt wurde. Die Rechercheoberfläche von Open-Access-Netzwerk orientiert sich salopp gesagt am ‚Google-Gewohnheitswert‘. Unter dem Namen bzw. Titel des Treffers verbirgt sich der ermittelte Volltextlink. Ein Klick und man hat in der Regel direkt den Volltext der beschriebenen Publikation auf dem Bildschirm. Open-Access-Netzwerk geht davon aus, dass bei der Recherche in Open-Access-Publikationen der möglichst hürdenlose Zugriff auf den Volltext Priorität hat. Ein separates Icon – zur Zeit das Lupensymbol – öffnet alternativ dazu die lokale Jump-Off-Page mit den Metadaten.

Die aktuelle Weiterentwicklung der Rechercheoberfläche bettet im Testbetrieb einen BibTeX-Export und einen RSS-Feed ein. Während der BibTeX-Export bereits brauchbare Ergebnisse beim Import in Literaturverwaltungsprogramme wie z.B. Citavi liefert, ist der RSS-Feed, der als Alerting-Feature eine Suche als Feed abonieren kann, noch nicht hinreichend performant. Wie das Format jedoch technisch aussehen wird und welche Möglichkeiten sich als Nutzung ergeben, lässt sich jedoch skizzieren. Hier bietet sich die Gelegenheit, von Anfang an auf konkrete Anmerkungen aus Nutzersicht einzugehen – nicht nur zu diesem Thema. Ich würde daher gerne versuchen, über die Kommentarfunktion Anmerkungen und Hinweise einzuholen.

Nachwort

Dieses Thema im Blog anzuschneiden und zur Diskussion zu stellen, wurde von Christian Hauschke vom Infobib-Blog angeregt bzw. durch begleitende Diskussionen unterstützt. Seiner Bereitschaft zu konstruktiver Kritik und der damit verbundenen Zeitinvestition sei an dieser Stelle ausdrücklich gedankt!

(-rm)

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: