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)

Werbung

Aggregation und Harmonisierung

Beim Zusammenführen der auf verschiedenen Dokumentenservern generierten und archivierten Metadaten – beim Prozess der Aggregation – ergibt sich die Frage, wie die eingesammelten Daten für die Schaffung eines gemeinsamen Datenraumes vergleichbar gemacht werden können. Open-Access-Netzwerk hat für dieses Themenfeld häufig den Begriff „Harmonisierung“ verwendet. In diesem Artikel soll dies näher betrachtet werden.

Metadaten und Metadatenformat

Zur Begriffsklärung vorweg: Die Metadaten eines Dokumentes sind ein semantisches Konstrukt. Es sind Eigenschaften, die das Dokument, sowie den Kontext seiner Entstehung und Verbreitung, beschreiben. Bibliothekarisch gesehen ein ganz alter Hut, unabhängig von der elektronischen bzw. digitalen Welt gewachsen und gereift. Um interoperabel zu werden, um Vergleichbarkeit zu schaffen, wurden und werden Standards geschaffen. Formal abgebildet ergibt sich daraus ein Datenmodell und aus dem Datenmodell eine Syntax. Ein Informatiker würde sagen, man einigt sich auf eine Grammatik, d. h. auf ein Format für die Metadaten, um sie durch einen strukturierten Symbolstrom abbilden zu können.

So, und da fangen die Probleme an. Wie umfangreich will bzw. kann man die Dokumente beschreiben? Welches Datenmodell bzw. Metadatenformat wende ich an? Ist es mächtig genug, um die zu erfassenden, semantischen Beziehungen abzubilden? Wie werden die formatierten Daten möglichst verlustarm zwischen verschiedenen, technischen Umgebungen übertragen? Und ist das, was der Aggregierende am Ende aus Symbolstrom und Datenmodell semantisch als Aussage ableitet, wirklich das, was der Erfasser ursprünglich intendiert hat?

Schwierig. Halten wir uns zuerst an die konkreten Fakten: Der gemeinsame Nenner, mit denen die Datenerfasser (die Dokumentenserver) und die Datenzusammenführer (z. B. Open-Access-Netzwerk) ihre Metadaten austauschen, ist (zumindestens hier in Deutschland) noch immer das Metadatenformat „Dublin Core Simple„. Einige Server bieten auch alternative Formate an, aber nicht alle. Welches Format auch immer konkret eingesammelt und verarbeitet wird, es muss irgendwie „ins System“. Also muss es ein Datenmodell geben, was die von außen kommenden Datensätze aufnimmt.

Internes Metadatenformat und Objekterfassung

Die Technik von Open-Access-Netzwerk ist so beschaffen, dass alle ankommenden Daten in ein Internes Metadatenformat gespeichert werden. Das bedeutet wiederum, dass die Harmonisierung in diesem Speicherschritt stattfindet. Da das Filterungen und Interpretationen bedingt, die möglicherweise Information verwerfen, weil sie nicht auswertbar ist, haben wir Harvesting und Aggregation auf separate Komponenten verteilt. Der Datensatz wird zuerst im Originalformat bezogen und einem Objekt innerhalb unseres Systems zugeordnet (bzw. ein neues Objekt erstellt). Dabei wird genau der Datensatz unverändert als BASE64-Blob gespeichert und sein Bitstrom gegen Zeichensatzverluste konserviert. Die Aggregation, die Umsetzung ins Interne Metadatenformat, findet erst in einem Folgeschritt statt.

Im Vorübergehen haben wir jetzt einen wichtigen Punkt gestreift: Wie ist die Datenhaltung strukturiert bzw. was ist ein Objekt? Ein Objekt in Open-Access-Netzwerk ist immer genau das, was ein Datensatz abbildet. Im günstigsten Fall ist das genau ein Dokument. Wie genau der Dokumentbegriff zu fassen ist und welche Ausnahmen dabei in der Praxis auftreten, führt in eine tiefere Diskussion. Halten wir an der Stelle einfach fest, dass ein Objekt einem Datensatz entspricht und dieser Datensatz in der Mehrheit aller Fälle genau ein Dokument (eine Publikation) beschreibt.

Um nun aus dem registrierten Metadatensatz im Originalformat einen Datensatz des Internen Metadatenformats zu aggregieren, setzt Open-Access-Netzwerk eine eigene Software-Komponente als Aggregator ein. Diese ist so implementiert, dass später neben Originaldaten in Dublin Core Simple auch andere Formate geparst werden können. Aktiv ist jedoch im Moment nur ein Interpreter für den besagten, gemeinsamen Nenner Dublin Core Simple. Alternative Formate in den Prozess einzubeziehen, machte momentan nur Sinn, wenn man dadurch mehr Datensätze aufnehmen könnte. Das ist nicht der Fall. Einfach alternative Formate für bereits durch Dublin Core Simple beschriebene Objekte auszuwerten, stellt die Frage, wie beide (gewissermaßen konkurrierende) Formate in eine gemeinsame Beschreibung (das Interne Metadatenformat) abgebildet werden. Dafür gibt es noch kein zufriedenstellendes Lösungskonzept.

Harmonisierung = Informationsverlust? Smart Up!

Wie bereits angedeutet, ist der große TradeOff bei der Aggregation, die Balance zwischen „Was verwerfe ich, weil es für mich Rauschen bzw. Abweichungen zum erwarteten Standard darstellt?“ und „Was bewahre ich zusätzlich, auch wenn noch unklar ist, wozu ich es später parallel zu den benutzten Standards als Information habe?“

Man muss sich klarmachen, dass wenn wir sagen, wir beziehen einen Metadatensatz in Dublin Core Simple, dann haben wir zum Zeitpunkt der Aggregation ein XML-Dokument, welches in seinen Elementen die Metadatenfelder benennt und ihre Werte mit Zeichenketten ausdrückt. Was in diesen Zeichenketten steht, ist jetzt die große Frage. Weder bildet das XML-Schema ab, welche Kodierung für die Zeichenkette gilt, um von diesem primitiven Datentyp z.B. auf eine Datumsangabe zu kommen, noch welches Datum hier semantisch erfasst wurde. Erstellungsdatum des Dokuments? Publikationsdatum? Datum der letzten Änderung? Komplexere Formate wie Dublin Core Qualifed machen sich genau über diese beiden Punkte mehr Gedanken. Deren Datenmodell ist komplexer, ausdrucksmächtiger. Aber auch daran hängen im Grundsatz die selben Fehlermöglichkeiten, ganz zu Schweigen von der Problematik der Altbestände, die „unschärfer“ beschrieben sind.

Im Umfeld des besagten Dublin Core Qualifed wird bisweilen der Begriff des „Dumb-Down“ verwendet. Er adressiert das Problem unterschiedlich detaillierter Metadaten und wie man damit umgeht. Bei Open-Access-Netzwerk stellen wir den Gedanken auf den Kopf. Wir machen gewissermaßen ein „Smart-Up„. Fakt ist, wir wollen bei der Harmonisierung Daten nicht einfach umschreiben, und damit vielleicht Informationen verlieren oder falsche Interpretationen einbauen, sondern Daten mit Mehrwerten anreichern. Die Metadatenfelder im Internen Metadatenformat sind daher – auch wenn das Konzept in der vorliegenden Implementierung noch nicht perfekt überall eingehalten wurde – kleine „Smart-Up„-Container aus Originalwert und harmonisiertem Wert.

Der harmonisierte Wert darf dabei leer sein, wenn er nicht sinnvoll ermittelbar ist. Der Originalwert wird nicht mit einer Interpretation überschrieben und bleibt für alternative Deutungen mundgerecht zugreifbar. Vor allen Dingen kann man ihn einem menschlichen Nutzer wieder zur Anzeige bringen, der kann damit vielleicht intellektuell noch eine Mehrinformation herauslesen.

Mal ein Beispiel: Sprachkennung

In Dublin-Core-Simple-Metadatensätzen gibt es ein Feld „language„. Da soll in der Regel semantisch vermerkt sein, in welcher Sprache der Volltext vorliegt. Faktisch ist es jedoch eine Zeichenkette beliebiger Kodierung. Beim Aggregator kommen also wild gemischt natürlich sprachliche Begriffe, Kürzel konkurrierender Kodierungsstandards oder einfach falsch eingetragene oder falsch übertragene Kodierungen an. (Ja, auch die OAI-PMH-Schnittstelle kann die in der Datenbank eines Dokumentenservers abgelegten Werte falsch in den „Container“ des auszuliefernden Metadatenformats einfügen. Solche serienmäßigen Fehler kann man jedoch im Gegensatz zu Ungenauigkeiten der initialen Metadaten-Erfassung leicht identifizieren und abstellen.)

Open-Access-Netzwerk möchte das Metadatum der Sprachkennung gerne mit einer ISO-standardisierten Kodierung notieren. Das ist in dem Fall ISO-639-2, ein eindeutiger, dreibuchstabiger Code, dessen Interpretation in der Zuordnung zu einer Sprache weltweit nachlesbar ist. Für die Sprache „Deutsch“ gibt es das ISO-639-2 Kürzel „deu“. Ist in einem Wert also die Zeichenkette „Deutsch“ enthalten, soll auf „deu“ abgebildet werden. Leider gibt es im Standard auch den alternativ gültigen Wert „ger“. (Einige wenige Sprachkennungen haben nämlich nach terminologisch (ISO 639-2/T) und bibliografisch (ISO 639-2/B) synonyme Werte. Aber das kann man ja abbilden.)

So, ignorieren wir Case-Sensitivität, bilden zweibuchstabige Codes (ISO 639-1) auf die höhere Kodierung ab, ordnen natürlich sprachliche Begriffe den korrespondierenden Kürzeln zu, dann sind wir schon einen Schritt weiter. Dank Smart-Up-Container haben wir ja später immer den Original-Wert. Bei „Deutschland“ wäre „deu“ als Wert relativ unstrittig. (Obwohl in Deutschland nicht nur deutsch gesprochen und publiziert wird und der Wert eigentlich uneindeutig ist.) Bei „Schweiz“ wäre es noch komplizierter, da man auch auf die Werte von „Italienisch“ oder „Französisch“ abbilden könnte. Allein, dass „Schweiz“ selbst ein deutsches Wort ist, könnte man als Hinweis werten. Doch da endet die implementierte Heuristik unserer Harmonisierung. Am besten würde hier eine nachgeschaltete Sprachprüfung des Volltextes helfen, die die Werte zusätzlich am Volltext nachprüft, anstatt sie nur zu harmonisiseren.

Der Vollständigkeit halber sei noch erwähnt, dass auch die Spezialwerte des Standards verwendet werden: Mit mul (von englisch multiple languages für „mehrere Sprachen“), der für die Auszeichnung mehrerer Sprachen gedacht ist, wenn eine Kennzeichnung durch alle einzelnen Kennungen nicht angebracht ist, sowie und (von englisch undetermined für „unbekannt“) für eine nicht identifizierbare Sprache gibt es zwei besondere Kennungen. Mit mis kann man angeben, dass die Kennung generell fehlt, und sie nicht einfach weglassen. Das grenzt Leerkennungen von bloßen Fehlern ab.

Andere Beispiele sind Datumswerte, die nach ISO8601 normiert werden müssen, oder die Dewey-Dezimalklassifikation (DDC), die mit den Set-Strukturen der OAI-PMH-Records übertragen werden. Nicht alle Set-Strukturen sind sofort als Wert von DDC, DNB oder DINI-Standard interpretierbar und werden ggf. als „OtherClassification“ aufbewahrt. Die Volltextlinks, die aus den Identifiern gezogen und dahingehend überprüft werden, ob sie zu einem vermutlich zugehörigen Volltext führen, schlagen in die gleiche Kerbe. Wie gesagt, Open-Access-Netzwerk wirft nach Möglichkeit nichts weg. Anreicherung ist die Prämisse.

Das Problem an der Wurzel packen – DINI-Zertifizierung

Die handfesten Erfahrungen mit den ankommenden Daten zeigen, dass man an vielen Stellen Hand anlegen kann, um die Qualität der Metadaten zu erhöhen und dass Forschung und Entwicklung  (s. Testbett-Aspekt) in Fragen der Harmonisierung noch Fortschritte erzielen kann. Verglichen mit Projekten, die sich auf ganz andere Datenquellen bzw. ein viel größeren Datenraum stützen, hat Open-Access-Netzwerk eine ganz entscheidende Erleichterung: Die DINI-Zertifizierung.

Die OAI-PMH-Schnittstelle wird kontrolliert, Dublin Core Simple ist als gemeinsamer Nenner Pflicht, es gibt Empfehlungen, welche Werte wie auszufüllen sind, Klassifikationen werden per Set-Struktur übertragen. Das alles macht das Leben als Aggregator so viel leichter. Wenn man jemals zu komplexeren Formaten als Dublin Core Simple kommen will, muss man schon an dieser Stelle beginnen, Richtlinien zu schaffen und vor allen Dingen eine organisatorische Infrastruktur schaffen, um diese Richtlinien einzuhalten und in Hinblick auf zukünftige Entwicklungen auszubauen. Auch da setzt Open-Access-Netzwerk immer wieder an. Das Netzwerk ist eben nicht nur – auch wenn es durch die technische Orientierung des Autors oft den Anschein haben mag – eine technologische Infrastruktur.

Eines der großen Ziele für kommende Projektphasen soll daher auch sein, den Bezug der neuen DRIVER Guidelines für Content Provider zum DINI-Zertifikat besser zu klären. Ein großer Abschnitt darin (Kapitel S.52) befasst sich mit der immer wiederkehrenden Thematik, wie Dublin Core Simple denn zu benutzen und günstigerweise strikter zu handhaben ist. Auch wenn hier bisweilen noch einige DRIVER-spezifische Zusatzannahmen getroffen werden, die gerade auch im Kontext des DINI-Zertifikates diskutiert werden müssen: Dieses Kapitel sollte jeder Data Provider einmal gelesen haben! Es beantwortet wichtige Fragen. Bei der Implementierung der Harmonisierung lag eine gedruckte Version immer neben den Begleitempfehlungen zum DINI-Zertifikat griffbereit.

Weiterführende Gedanken

Zuletzt noch ein paarAnmerkungen, die in die Thematik der Harmonisierung hineinspielen. Einerseits möchte ich den, meiner persönlichen Meinung nach sehr mächtigen (wenn auch sehr aufwändigen) Ansatz erwähnen, die Methoden der Harmonisierung repositorienabhängig zu gestalten. Meines Wissens nach zielt DRIVER darauf ab bzw. ist bereits an der Umsetzung einer solchen Aggregation. Anstatt einer gemeinsamen Heuristik für alle Datenquellen, kann man in DRIVER angeblich jede Datenquelle einzeln durch Mapping-Dateien „finetunen“. Fündig wird man wohl unter dem Begriff „transformation rules“. Ein guter Ansatz, und auf paneuropäischer Ebene (ohne die Erleichterungen der DINI-Zertifizierung) wahrscheinlich unumgänglich. Open-Access-Netzwerk stützt sich eher auf das Prinzip der Anreicherung, so dass im Datenknoten möglichst viele Daten erhalten bleiben.

Als Zweites stellte sich im Zuge der Implementierung die Frage, ob jemals konkret durch ein Projekt untersucht wurde, wie man bereits durch die Gestaltung der Technologien der Dokumentenserver während der Erfassung Fehler minimieren und Standard-Einhaltung anregen, wenn nicht gar forcieren kann. Warum – ganz ketzerisch gefragt – ist es überhaupt möglich, in ein Feld, das eine Sprachkennung aufnehmen soll, Freitext einzufügen? Warum gibt es da nicht serienmäßig eine Auswahlbox für ISO-Werte? Wenn unbedingt Freitext gewünscht ist, dann nur als optional auszufüllender Zusatz zum Striktwert. Das gleiche gilt für viele andere Werte. Ein optionaler (in der Repository-Software zuschaltbarer) strikt-Modus für die Eingabe-Oberflächen würde bereits dort die Datenqualität erhöhen.

Unterm Strich wäre es wirklich spannend zu erfahren, wo und wie die Fehler eigentlich entstehen und wie man Guidelines und Empfehlung dem Erfassenden zum Zeitpunkt der Ersteingabe wirklich präsent und praktisch umsetzbar macht. Mensch-Maschine-Interaktion ist doch kein neues Themenfeld. Da gibt es etablierte Methoden und Leute, die sich damit auskennen.

(-rm)

Zusammenspiel der Open-Access-Projekte

Das Projekt Open-Access-Netzwerk stellt, wie im Überblick erwähnt, den Rahmen für zwei selbstständige Schwesterprojekte – Open-Acces-Statistik (OAS) und Open-Access-Zitationen (DOARC) – die zeitlich überlappend nachfolgen und deren Bemühungen u.a. in Mehrwertdiensten zum Nutzungs- und Zitationskontext der erfassten Dokumente gipfeln werden. Diese Mehrwertdienste werden mittelfristig in die Rechercheoberfläche integriert.

Wie ist das gedacht?

Folgende Grafik wurde bereits zur Veranschaulichung auf einem gemeinsamen Poster verwendet:

Dargestellt sind, in sehr abstrahierter Form, die drei Projekte mit Open-Access-Netzwerk als stützende Kernarchitektur in der Mitte. Die Grafik ist am einfachsten von unten nach oben zu lesen.

Datenbeschaffung

Die Metadaten, die man auf der Ebene der in Deutschland verteilten Dokumentenserver („Repositories“) über Harvesting-Schnittstellen wie OAI-PMH V2.0 beziehen kann, werden in eine Datenbank („Core Data Storage“) gezogen. Das kleine Zahnrad-Symbol deutet an, dass hier eine Aufbereitung, Harmonisierung und Aggregation der Daten stattfindet. Zum Beispiel werden Metadaten-Felder zu Sprachkennung oder Daten auf ISO-Standards abgebildet. Aber es werden auch gänzlich neue Daten generiert, wie gesicherte Links zu den Volltexten oder die aufwändig erstellten Maßzahlen zur textuellen Ähnlichkeit von Dokumenten zueinander.

Datenverarbeitung

Um die zentrale Datenhaltung ist ein Ring gezogen. Dies stellt den REST-Webservice dar, der sowohl für das Einspielen als auch für das Auslesen von Daten in die Datenhaltung genutzt werden kann. Diese REST-Schnittstelle wird separat noch einmal zum Thema werden. Der Clou daran ist, dass man durch Zugriff auf den Webservice über das Internet (respektive dem HTTP-Protokoll) Zugriff auf die Datenhaltung erhält. Erst diese Indirektion ermöglicht eine sehr stark modularisierte, verteilte Architektur. Das Zahnrädchen sind eigentlich viele Zahnrädchen und alle arbeiten sie daran, die Daten, die von den Dokumentenservern bezogen und gespeichert werden, schrittweise zu verbessern und anzureichern.

Datenanwendung

Wie in den drei Bedeutungsaspekten des Projektes anklang, ist nicht nur die Datensammlung allein von Wert. Sie soll auch, um die konkreten Inhalte einsehbar zu machen und einige Möglichkeiten der Anwendung zu demonstrieren, in einer grafischen Benutzerschnittstelle enden, der Rechercheoberfläche. Dabei erschöpfen sich die nutzbaren Schnittstellen, über die die Nutzer auf die Datensammlung zugreifen können („User Interfaces“), nicht allein in einer Webanwendung. Es sind beispielsweise auch RSSFeeds, ein OAI-PMH-Export und eine rein lesende REST-Schnittstellen-Variante angedacht, über die jeder auf die Daten zugreifen und sie in einen eigenen Nutzungskontext integrieren kann. Letztlich werden auch übergeordnete Netzwerke diesen Weg gehen können, nötigenfalls mit Adapter-Module, die die Kommunikationswege und Austauschprotokolle miteinander bekannt machen.

Beitrag der Schwesterprojekte

Sowohl das Nutzungsdaten-Projekt (Open-Access-Statistik) als auch das Zitationsanalyse-Projekt (DOARC) wollen, wie eingangs erwähnt, die Quintessenz der durch ihre Systeme generierten Mehrwertdaten zur Datenhaltung hinzufügen und die darin verwalteten Objekte damit anreichern. Beide Projekte gehen dabei unterschiedliche (Daten-)Wege.

Um Nutzungsdaten für Dokumente zu erhalten, bedarf es einer weiteren Schnittstelle auf die Ebenen der Dokumentenserver, denn nur dort langern die Volltexte, deren Metadaten Open-Access-Netzwerk verarbeitet, als herunterladbare Dateien. Von dort werden sie also auch zum Lesen bezogen, nicht nur von Nutzern, die über die Rechercheoberfläche oansuche.open-acces.net kommen, sondern von allen Oberflächen, die die Dokumente des Servers zugänglich machen. Das bedeutet, genau dort fallen auch Nutzungsereignisse an, die registriert und ausgewertet werden können. Das Projekt Open-Access-Statistik muss also einen eigene Harvest-Prozess integrieren, der die Rohdaten der Dokumentnutzung da abholt, wo sie entstehen. Das ist in den Metadaten, die Open-Access-Netzwerk einsammelt, nicht enthalten.

Auch hier vereinfacht ein Zahnrad-Symbol die komplette Verarbeitungslogik rund um die Nutzungsdaten. Aus Sicht von Open-Access-Netzwerk wird dabei ein Zieldatensatz pro Objekt erzeugt, der auf Zeitintervalle normiert Maßzahlen nach verschiedenen Auswertungsstandards bereithält. Diese  Mehrwertdaten werden dann über die REST-Schnittstelle eingespielt und können sowohl in der Rechercheoberfläche angezeigt als auch von anderen Schnittstellen, die die Datenhaltugn anzapfen, nachgenutzt werden.

Um Zitationsdaten zu analysieren, genügen als Kern die Metadaten, die bereits in der Datenhaltung vorhanden sind, sowie die Volltexte, die über die in den angereicherten Metadaten enthaltenen URLs bezogen werden können. Der Pfeil und das obligatorische Zahnrädchen arbeiten hier von der Datenhaltung in die Datenhaltung. Auch hier werden zusätzlich erzeugte Mehrwertdaten erst als Anreicherung in das Kernsystem zurückgespielt.

Beide Projekte haben zusätzlich eine eigene Datenhaltung. Diese scheinbare Redundanz ist notwendig, um einerseits die Zwischenergebnisse der teilweise extrem aufwändigen Berechnungen lokal vorzuhalten und andererseits der verteilten Organisation und Entwicklung des virtuellen Projektverbundes Rechnung zu tragen.

Ausblick und Herausforderungen

Das unterschiedliche Vorgehen der beiden Projekte stellt verallgemeinernd betrachtet zwei Optionen dar, wie sich auch in Zukunft nachfolgende Projekte in die bestehende Infrastruktur integrieren können: Entweder werden Daten, die bereits vorliegen, auf neue Weise untereinander in Verbindung gebracht, analysiert und aggregiert, so dass neue Mehrwertdaten entstehen, oder es werden gänzlich neue Datenquellen erschlossen und dem System verständlich aufbereitet eingespielt.

Die wirkliche Herausforderung, die auf die Projekte zukommt, ist dabei nicht so sehr das Zusammentragen der Daten. Das verteilte System bietet hier über die REST-Schnittstelle gangbare Lösungen. Es sind eher die konkreten Visualisierungen der neu hinzukommenden Mehrwertdaten, die in die gemeinsame Oberfläche integriert werden müssen, was gemeinsames Arbeiten an der dahinterstehenden Webanwendung erfordert – oder ein Konzept, wie man es vielleicht mit „MashUp“ am einfachsten umschreiben könnte.

(-rm)

Die drei Bedeutungsaspekte der Technik

Es geht bei der Rechercheoberfläche nicht um den Versuch, die eine Killerapplikation zu erschaffen, welche alle anderen in den Schatten stellt und erfolgreich mit Google Scholar, BASE oder DRIVER konkurriert. Abgesehen davon, dass die Ressourcen eines einzelnen Projektes dafür gewiss nicht ausreichen würden, müsste man ernsthaft in Frage stellen, ob dies in einer dynamischen Umgebung noch möglich bzw. sinnvoll ist.

Was die Technologie von Open-Access-Netzwerk jedoch sehr wohl für die Open-Access-Bewegung auf der einen Seite und den Wissenschaftlern auf der anderen Seite leisten soll, lässt sich am leichtesten mit drei Kernaspekten umschreiben, drei Facetten bzw. Sichtweisen, die sich wechselseitig beeinflussen:

drei Aspekte von OAN

Es ist ein Knoten, weil es auf einer übergeordneten Daten sammelt, verbessert und als Kollektion bereitstellt. Dazu wird die implementierte REST-Webservice API offengelegt werden, um diese Daten auch jenseits der OAI-PMH-Mechanismen abzurufen und in anderen Kontexten nachzunutzen. Langfristiges Ziel ist ferner, technische Möglichkeiten zu finden und anzuwenden, um die Daten in übergeordneten Netzwerken wie DRIVER verfügbar zu machen.

Es ist ein Portal, in dem die Daten des Knotens exemplarisch Mehrwertdienste ermöglichen, die den Nutzern Funktionen zur Recherche anbieten. Erst in der praktischen Anwendung lässt sich die Qualität der Daten auf einen Prüfstein stellen, mit dem man konkretes Feedback für die Standardisierungsleistungen des DINI-Zertifikats ableiten kann. Die Verlinkung unter der Open-Access-Informationsplattform sehen wir dabei als wichtigen, organisatorischen Schritt, Open-Access-Vorhaben in Deutschland generell stärker in Kontext zueinander zu setzen.

Es ist ein Testbett, denn wo sonst kann Hilfe bekommen, um anhand der Echtdaten Forschung und Entwicklung zu betreiben? Das beste Modell der Wirklichkeit ist die Wirklichkeit selbst. Das gilt auch für den Datenraum mit all seinen verbleibenden Fehlern und Ausnahmen aber auch seinen Chancen. Erst in der Aggregation kann man experimentieren, welche neuen Mehrwerte die Open-Access-Welt aus der Möglichkeit der freien Verfügbarkeit von Volltext und Metadaten ziehen kann. Dublettenerkennung, automatische Fachklassifikation und verbesserte Harmonisierung sind hier Schlüsselworte.

(-rm)

Worum geht es eigentlich?

Überblick

Das DFG-Projekt „Open-Access-Netzwerk“ hat sich zum Ziel gesetzt, die Sichtbarkeit des deutschen Forschungsbeitrags national und international zu verbessern. Auf der technischen Seite hat das zu der Rechercheoberfläche im Datenraum der Open Access Dokumente DINI-zertifizierter Volltextserver geführt.

oansuche.open-access.net

Um der Entwicklung dieser Rechercheoberfläche ein wenig mehr Transparenz zu verleihen, folgen wir einer Idee von den „Vernetzungstagen 2009“ und verlinken dieses Blog.

Das Projekte Open-Access-Netzwerk steht dabei nicht alleine da. Es liefert schon jetzt den Rahmen für zwei selbstständige Schwesterprojekte – Open-Acces-Statistik (OAS) und Open-Access-Zitationen (DOARC) – die zeitlich überlappend nachfolgen und deren Bemühungen u.a.  in Mehrwertdiensten zum Nutzungs- und Zitationskontext der erfassten Dokumente gipfeln werden. Diese Mehrwertdienste werden mittelfristig in die Rechercheoberfläche integriert.

Erste Version der Nutzeroberfläche online

Zum Zeitpunkt der Verlinkung unter der Subdaomain bei der Informationsplattform Open Access sind nur die grundsätzlichsten Funktionen von Suche und Browsing aktiviert und in den Rahmen der Webanwendung integriert: Ein Suchschlitz erlaubt die Eingabe eines Freitextbegriffes, der mittels des angebundenen OA-Netzwerk-Suchservice (Lucene/Nutch) eine Trefferliste generiert.

Zu jedem Treffer werden ein möglichst direkt zum Volltext verweisender Link sowie (in verknappter Form) die im System vorgehaltenen Metadaten angezeigt. Durch Klick auf das Lupensymbol kann man sich eine Langsicht der Metadaten ansehen. Ferner ist eine Art Warenkorb-Feature (hier: „Merkzettel“) vorhanden, mit der man sich über das Plus-Symbol – querschneidend zu verschiedenen Suchanfragen – gefundene Dokumente markieren und als Auswahl weiterbearbeiten kann. Hier können später Mehrwertdienste wie Exportfunktionen in Literaturdatenbankformate ansetzen, die auf eine Gruppe von Dokumenten angewendet werden sollen.

Das jüngste, zur Zeit noch nicht voll funktionstüchtige Feature ist ein Browsing nach DDC-Fachgebieten, welches de facto auch als Filter für die Suche dienen wird. Die Oberfläche skizziert bereits, dass Stichwortsuche und Fachgebietskategorie Hand in Hand gehen sollen.

Technischer Rahmen

Die Rechercheoberfläche, obwohl noch in einem Status des „Alpha-Release“ befindlich, arbeitet bereits auf den Echtdaten des Systems, d. h. auf den durch die DINI-zertifizierten Volltextserver per OAI-PMH-Schnittstelle exponierten Metadaten. Die korrespondierenden Dokumentdateien verbleiben in den Repositorien – denn nur dort können die Fragen der Langzeitarchivierung gestemmt werden – sind für den Nutzer aus der Oberfläche heraus durch Verlinkung aufrufbar.

Die zugrunde liegende Technologie, die Infrastruktur, ist einen eigenen Artikel wert. Verknappt kann man sagen, dass es sich um eine modulare, auf die Hardware der Projektpartner verteilte Implementierung handelt. Das Back-End-System, welches die Daten sammelt und aufbereitet, macht sich den REST-Webservice-Ansatz zunutze. Das Front-End, welches die durch das Back-End bereitgestellte Datenkollektion exemplarisch visualisiert, ist eine MyFaces-Webanwendung.

(-rm)