Das Problem

Schon mit der Entstehung des Internets als verteiltes, heterogenes und zugleich relativ schwach strukturiertes Informationsmedium stellte sich die Frage nach der parallelen – und möglichst effizienten – Durchsuchbarkeit der permanent wachsenden Datenmenge. Suchmaschinen und Metasuchmaschinen waren die Antwort. Dass sich die meisten Menschen heute bei Google & Co. ziemlich gut aufgehoben fühlen, wenn sie irgendetwas im Netz der Netze suchen, sollte aber im Übrigen nicht darüber hinwegtäuschen, dass auch die ausgereiften Suchtechnologien und Rankingmechanismen gängiger Suchmaschinen nicht alles finden bzw. präsentieren können: Alles, was nicht über Links von bereits »bekannten« Seiten erreicht werden kann, bleibt als blinder Fleck im Verborgenen – im so genannten deep web.

Ein ähnliches Problem ergab sich mit dem Aufbau verteilter Dokumenten- und Publikationsserver und so genannter Preprint-Archive, auf denen wissenschaftliche Publikationen vorab veröffentlicht werden. Auch wenn die Daten ihrem Anspruch gemäß natürlich frei zugänglich und meist auch über entsprechende Suchschnittstellen recherchierbar sind, werden sie von gängigen Suchmaschinen nicht unbedingt gefunden – der Nutzer muss die einzelnen Suchmasken direkt mit dem Webbrowser ansteuern. Schon bald ergab sich die verständliche Forderung nach einer integrierenden Recherchemöglichkeit, um an einer Stelle gleichzeitig die Publikationen mehrerer Server nachweisen zu können. Dabei wollte man auf die Vorteile strukturierter Metadaten, die für Publikationen auf den meisten Dokumentenservern mit erfasst werden, ebenso wenig verzichten wie auf die Möglichkeit, die Recherche auf relevante – in der Regel also wissenschaftliche – Inhalte einzugrenzen. Nicht zuletzt geht es hierbei um die Erhöhung der weltweiten Sichtbarkeit und damit der Akzeptanz wissenschaftlicher Arbeiten, die nicht in einer traditionellen Zeitschrift, sondern in Form von Open Access veröffentlicht wurden.

Die Idee

Mit dem Ziel, die technischen Voraussetzungen für einen so genannten Universal Preprint Server, also eine Art virtuellen Verbundkatalog für wissenschaftliche (Vor-)Veröffentlichungen zu schaffen, schlossen sich 1999 Betreiber – vorwiegend nordamerikanischer – Preprint-Server zur Open Archives Initiative (OAI) zusammen¹. Dabei gehörte es neben der Funktionalität des Protokolls zu den wichtigsten Entwurfskriterien, dass der Implementierungsaufwand – vor allem aufseiten der Datenanbieter – möglichst gering ist. Denn im Gegensatz zu den Entwicklern klassischer Bibliotheks- und Verlagssysteme verfügen die Betreiber von Preprint-Servern und Open-Access-Archiven in vielen Fällen nicht über ausreichend Ressourcen für die Implementierung komplexer Datenschnittstellen.

Prinzipiell gibt es zwei Ansätze, verteilt liegende Daten zum Zwecke der Recherche über eine gemeinsame Schnittstelle zusammenzuführen: Das Cross Searching und das Harvesting. Beim Cross Searching werden die eigentlichen Datenquellen im Moment der Nutzeranfrage gleichzeitig durchsucht. Die Ergebnisse werden ohne Zwischenspeicherung unmittelbar präsentiert. Dabei müssen die Suchparameter in die jeweiligen Suchsprachen der Datenanbieter übersetzt werden. Ein klassischer Vertreter dieses Ansatzes sind die Metasuchmaschinen. Dagegen ist das Harvesting ein asynchrones Verfahren, bei dem die verfügbaren bzw. relevanten Daten zunächst regelmäßig eingesammelt, aufbereitet und anschließend in einer gemeinsamen Datenbank gespeichert werden. Die eigentlichen Suchanfragen von Benutzern werden dann ausschließlich an diese zentrale Datenbank gerichtet.

Die Umsetzung

Es liegt auf der Hand, dass beide Methoden ihre Stärken und Schwächen haben. Die OAI entschied sich vor allem wegen der besseren Skalierbarkeit, aber auch im Hinblick auf die einfachere Implementierbarkeit, für den Harvesting-Ansatz und so entstand das OAI Protocol for Metadata Harvesting (OAI-PMH), das inzwischen in der Version 2.0 vorliegt.

Wie der Name bereits erkennen lässt, dient das Protokoll der Übertragung von Metadaten – also Daten über Daten wie z. B. Titel, Autorennamen und Erscheinungsdatum eines Artikels. Sie dienen der Beschreibung der elektronischen Dokumente und eignen sich daher für die Recherche ebenso wie für die Präsentation von Resultaten. Die eigentlichen Dokumente werden mit dem OAI-Protokoll nicht eingesammelt. Sie verbleiben auf den Ursprungsservern und werden später aus dem Suchergebnis heraus mit einem Link referenziert, der seinerseits Bestandteil der übermittelten Metadaten ist.

Abb. 1 zeigt die grundsätzliche Arbeitsweise des OAI-Protokolls. Während aufseiten der Data Provider – also der einzelnen Dokumentenserver – die Dokumente und deren Metadaten gehalten werden, speichert der Service Provider lediglich die Metadaten, die er mithilfe des OAI-PMH eingesammelt hat. Die Art des Dienstes, den der Service Provider nach außen hin zur Verfügung stellt, ist im Protokoll nicht näher spezifiziert. Neben einer einfachen Suche können, ggf. nach entsprechender Aufbereitung der Metadaten, auch Mehrwertdienste wie z. B. Alertingsysteme oder das Erstellen dynamischer Browsing-Bäume implementiert werden². Auch der Metadatenaustausch für das System Proprint (siehe Seite 65) wurde mit dem OAI-Protokoll realisiert [1].

Abb. 1: Grundprinzip des OAI-Protokolls.

Das Protokoll

Das Protokoll setzt auf HTTP auf, als Antwortformat wird XML verwendet. Somit bedient sich das OAI-PMH gängiger und etablierter Standards und ist vergleichsweise sehr einfach zu implementieren. Um einen Data Provider für einen existierenden Dokumentenserver zu realisieren, genügt in der Regel ein Webserver mit einer Skriptsprachenerweiterung (z. B. PHP oder CGI). Das Skript stellt die Schnittstelle zwischen dem Harvester und den eigenen Metadaten her, die meistens in einer relationalen Datenbank verwaltet werden.

Die Spezifikation [2] des OAI-PMH definiert insgesamt sechs Anfragetypen: Identify, ListMetadataFormats, ListSets, ListIdentifiers, ListRecords und GetRecord. Der Anfragetyp und in Abhängigkeit davon die übrigen Argumente werden der Basis-URL als GET- oder POST-Parameter angehängt und bilden gemeinsam eine OAI-Anfrage. Beispielsweise bildet der URI http://edoc.hu-berlin.de/OAI-2.0?verb=ListRecords&from=2005-08-01&until=2005-08-31&metadataPrefix=oai_dc eine gültige Anfrage an die OAI-Schnittstelle des Dokumenten- und Publikationsservers der Humboldt-Universität. Sie liefert alle Metadatensätze, die im August 2005 erstellt oder verändert wurden – also auch diejenigen über die Artikel, die in diesem Heft erschienen sind.

Die Metadaten

Das OAI-Protokoll ist so beschaffen, dass damit beliebige Metadatenformate übertragen werden können. Die einzige Bedingung ist, dass ein entsprechendes XML-Schema, das dann als eigener Namensraum in den XML-Code eingebunden wird, existiert. Aus Gründen der Interoperabilität wurde das für die Beschreibung elektronischer Dokumente etablierte Metadatenformat Dublin Core [3, 4] als verpflichtende Mindestanforderung in die Protokollspezifikation aufgenommen. Das heißt, jeder Data Provider muss die verfügbaren Metadaten zumindest in diesem Format liefern können. Es spricht viel dafür, dass die weite Verbreitung und vielfältige Nutzung des Protokolls wesentlich auf diese Festlegung zurückzuführen ist.

Die Sanktionierung von Dublin Core bedeutet jedoch mitnichten die Einschränkung auf dieses Format. Die Metadaten können und sollen auch in anderen Formaten zur Verfügung gestellt werden, um Dokumente detaillierter und exakter beschreiben zu können. Nutzbringend ist dies freilich nur, wenn auch der jeweilige Harvester das angebotene Format interpretieren und damit weiterverarbeiten kann.

Abb. 2 zeigt das Beispiel einer GetRecord-Anfrage an einen OAI-kompatiblen Data Provider und die entsprechende XML-kodierte Antwort. Um die gezeigte Anfrage zu stellen, musste der Harvester zunächst mithilfe einer ListIdentifiers-Anfrage den hier verwendeten eindeutigen Identifikator oai:HUBerlin.de:20519 ermitteln. Dieser Schritt kann eingespart werden, wenn der Harvester gleich eine ListRecords-Anfrage stellt.

Wie bereits im Zusammenhang mit den grundsätzlichen Ansätzen für die Realisierung einer verteilten Recherche beschrieben, handelt es sich beim OAI-PMH nicht um ein Suchprotokoll. Das heißt, über das Protokoll selbst können keine Suchanfragen gestellt werden, wie man das beispielsweise von dem im Bibliotheksbereich etablierten Standard Z39.50 kennt. Dennoch gibt es einige Möglichkeiten, nur eine bestimmte Auswahl der über einen Data Provider zur Verfügung gestellten Metadaten abzufordern. Diese Kriterien sind:

Daneben sieht das OAI-Protokoll auch eine Methode zur Flusskontrolle vor. Wäre der XML-Strom, der auf eine OAI-Anfrage gesendet werden müsste, zu lang, kann der Data Provider die Antwort in mehrere Segmente aufteilen. Um den jeweils nächsten Teil der gesamten Datenmenge anfordern zu können, erhält der Harvester außerdem einen so genannten ResumptionToken, den er als Parameter einer weiteren HTTP-Anfrage angeben muss.

Erste Schritte

Für wissenschaftliche Dokumentenserver gehört eine OAI-Schnittstelle heutzutage zum Pflichtprogramm. Wer selbst mit dem Gedanken spielt, das OAI-Protokoll zu implementieren – sei es als Data Provider oder als Harvester – dem stehen auf der Webseite der OAI³ neben der Spezifikation umfangreiche Materialien, eine Vielzahl fertiger Softwarelösungen sowie zwei Mailinglisten zur Verfügung. Dort kann man sich auch einen Überblick über die bisherige Verbreitung des OAI-Protokolls und über Produkte, die bereits über eine integrierte OAI-Schnittstelle verfügen, verschaffen.

Die Humboldt-Universität gehörte zu den ersten Einrichtungen in Europa, die das OAI-PMH implementiert hatten. In den vergangenen Jahren gab es zu diesem Thema zahlreiche Aktivitäten⁴ der Arbeitsgruppe Elektronisches Publizieren, unter anderem das EU-Projekt OAForum⁵. Neben einem Data Provider für den Dokumenten- und Publikationsserver wurde an der Humboldt-Universität auch ein Service Provider entwickelt⁶, der zurzeit die deutschsprachigen universitären Dokumentenserver abfragt und deren Veröffentlichungen nachweist (siehe Abb. 3). Die Arbeitsgruppe hat auch an der Erstellung und Durchführung diverser Tutorials zum OAI-Protokoll mitgewirkt⁷. Seit dem Frühjahr 2005 kann im Computer- und Medienservice außerdem eine DVD zu diesem Thema bestellt werden.

Fazit

Trotz oder wohl gerade wegen seiner Einfachheit erfährt das OAI-Protokoll weltweit eine wachsende Verbreitung. Unzählige Implementationen in fast allen Programmiersprachen sind inzwischen verfügbar. In gängigen Softwarelösungen für Dokumentenserver wie eprints ⁸ oder DSpace ⁹ ist eine OAI-Schnittstelle längst selbstverständlich. Und auch zahlreiche Service Provider bedienen sich inzwischen der vermittels des OAI-Protokolls eingesammelten Daten¹⁰. Im Rahmen von Google Scholar ¹¹ fragt selbst die weltgrößte Suchmaschine OAI-Archive ab.

Dabei lässt sich das OAI-Protokoll keineswegs nur zur Realisierung klassischer monohierarchischer Verbundkataloge verwenden, siehe Abb. 4 (1). Data Provider, die bei der OAI registriert und auf ihre Korrektheit hin überprüft sind, können allein aufgrund der Kenntnis der Basis-URL von beliebigen Harvestern abgefragt werden (2, 3, 4). Darüber hinaus kann zum Beispiel ein Service Provider seinerseits wieder als Data Provider fungieren und somit für übergreifende Service Provider als aggregierender Data Provider wirken (3, 4) – sei es wiederum über das OAI-PMH (5) oder auch mit einem anderen Harvest- oder Suchprotokoll (6). Auf diese Weise ist es beispielsweise möglich, über eine Zwischeninstanz OAI-kompatible Quellen in das Portalsystem Metalib einzubinden, obwohl diese Software nicht direkt in der Lage ist, OAI-Data-Provider abzufragen.

Abb. 4: Unterschiedliche Einsatzmöglichkeiten für das OAI-Protokoll.

Ein Wermutstropfen bleibt dennoch. Denn abgesehen von abgeschlossenen Communities werden die Metadaten über das OAI-Protokoll in den meisten Fällen nur in Form von Dublin Core ausgetauscht. Ebenso wenig wie die Verwendung alternativer Metadatenformate hat sich bisher die Nutzung von Sets durchgesetzt. Für beides müssten inhaltliche Vereinbarungen entwickelt werden, die in Abhängigkeit von der jeweiligen Domain als zusätzliche Empfehlungen für das OAI-Protokoll gelten. Ein weiteres Problem in diesem Zusammengang – die bisherige Unmöglichkeit, die rechtlichen Bedingungen, unter denen die Metadaten genutzt werden dürfen, nach dem jeweiligen Format zu differenzieren – wird im folgenden Artikel besprochen [6].