OAI-PMH ist das Protocol for Metadata Harversting der Open Archives Initiative. Die aktuelle Version dieses Protokolls ist Protocol Version 2.0 of 2002-06-14. Frei übersetzt aus der Einleitung der Spezifikation:
OAI-PMH stellt eine Anwendungs-unabhängige Rahmenumgebung für Interoperabilität dar, das auf Metatdata-Harvesting beruht. In dieser Rahmenumgebung gibt es zwei Klassen von Teilnehmern:
- Data Provider betreiben Systeme, die OAI-PMH als Mittel zur Zugänglichmachung von Metadaten nutzen
- Service Provider benutzen via OAI-PMH geharvestete Metadaten als Grundlage zum Aufbau von Mehrwertdiensten
Ein OAI-Repository ist nun ein Server oder Dienst des Data Providers,
der auf die im Protokoll definierten Anfragen der von den Service-Providern betriebenen
Harvester reagiert.
Ein OAI-Repository ist (derzeit) nie ein Dienst für Endbenutzer, das Protokoll
dient in seiner Grundfunktion dem (blockweisen) Transport der Metadaten aller
verfügbaren "Items" vom Repository zum Harvester.
Verfeinerungen im Protokoll sind der selektive Transport der Metadaten, die sich
in einem vom Harvester spezifizierten Zeitraum geändert haben oder die
Einschränkung auf vom Repository definierte Sets, die den Datenbestand
sachlich oder formal einschränken.
Insbesondere Konzepte wie "Recherche" oder "Verknüpfung" sind völlig ausserhalb der
Begriffswelt von OAI-PMH.
Transport der Metadaten erfolgt in einem Format, das der Harvester sich aus der
Menge der vom Repository unterstützten Formate aussucht, Dublin Core (oai_dc)
muss dabei zwingend unterstützt werden um zu gewährleisten, dass Repository
und Harvester stets mindestens ein gemeinsames Austauschformat haben.
^Top
Die Implementierung erfolgt als datenbankabhängiges Perlskript, das Konfigurationsinformation (durch das Protokoll erforderliche Angaben zum Repository, für die Anbindung der konkreten Datenbank benötigte Einstellungen etc.) enthält und populo.pl als Avanti-Client sowie eine weitere Bibliotheksdatei oaipop.pl mit Hilfsfunktionen einbindet. Bei der Verarbeitung von Requests nutzen die Routinen dann populo-Templates für Avanti-Jobs und die diversen Ausgabezustände des Protokolls.
Die typische Vorgehensweise bei der Verarbeitung eines Requests ist, dass in Avanti-Jobs (portionsweise) sämtliche Records der Datenbank geladen und bereits von Avanti daraufhin untersucht werden, ob sie unter den Filterkriterien des aktuellen Requests (Datum "von" bzw. "bis", Zugehörigkeit zu Sets) relevant sind. Derart gefilterte Datensätze werden dann (bis auf den letzten, der als Sicherheitspuffer für die nächste Portion aufbewahrt werden muss) an das Skript zurückgegeben, das dann die Aufbereitung vornimmt oder veranlasst. Sofern die Datenbank geeignet indexiert ist, kann in der Konfigurationsdatei eingetragen werden, wie diese portionsweise "Volltextsuche" durch Avanti- find-Kommandos oder den Einsatz von Restriktionen effizienter gestaltet werden kann. Beim Einsatz von find-Kommandos ist jedoch zu bedenken, dass Avanti auch bei Zwischenergebnissen komplexer Anfragen recht niedrige Limits für die maximale Ergebnismengengrösse hat.
Die untersützte Granularität der Zeitstempel sind Tagesgenaue Daten. Ist die von Avanti genutzte Datenbank nicht die Produktionsdatenbank und wird seltener als täglich aktualisiert, so ist es äusserst wichtig, in der Konfigurationsdatei die Historie sämtlicher Aktualisierungsdaten peinlich genau nachzuführen: Die realen Ersterfassungs- und Änderungsdaten der allegro-Datensätze werden mit dieser Liste sowohl beim Verarbeiten von Requests als auch bei der Präsentation der Ergebnisse in Beziehung gesetzt: Nur so kann im folgenden Ablauf garantiert werden, dass der Datensatz von Dienstag, den der Harvester am Mittwoch noch nicht sehen konnte, ihm am Freitag auf seine Anfrage "alles nach Mittwoch" geliefert wird.
| Datum | Aktion |
|---|---|
| Montag | Avanti-Datenbank wird aktualisiert |
| Dienstag | Datensatz wird in der Produktionsdatenbank eingegeben |
| Mittwoch | Harvester: "Liefere alles bis heute (Mittwoch)" |
| Donnerstag | Avanti-Datenbank wird aktualisiert (Jetzt ist der Satz von Dienstag erstmalig sichtbar) |
| Freitag | Harvester: "Liefere alles von Mittwoch bis heute" |
Wird eine komplett reorganisierte Datenbank (bei der sich Satznummen vorhandener Datensätze geändert haben) aktualisiert, so empfiehlt es sich, das Interface anlässlich der Aktualisierung mindestens für die Lebenszeit von Resumption Tokens ($ExpireAfter in der Konfigurationsdatei) stillzulegen, da die Integrität der Folgerequests nicht mehr gewährleistet werden kann.
OAI-PMH hat eine recht breite Definition von "Änderungen" (an einem Datensatz): "[...] changes include, but are not limited to, changes to the metadata of the record, changes to the metadata format of the record, introduction of a new metadata format, termination of support for a metadata format, etc.". In solchen Fällen wird man in der Konfigurationsdatei den Wert $InterfaceDateStamp korrespondierend dem Identify-Element earliesteDatestamp auf das aktuelle Datum setzen müssen.
OAI Sets sind optional ($UseSets = 1) und können explizit in der Konfigurationsdatei angegeben werden, die Demoanbindung oai-cat.cgi enthält Beispiele ($UseFreeSets = 1), wie zusätzlich "Klassen" von Sets direkt über Registerauszüge oder sogar indirekt (unter Rückgriff aus Information in Stammsätzen) generiert werden können. Dies ermöglicht es in vielen Fällen, eine eigene Systematik in (ineinandergeschachtelte) OAI-Sets zu transformieren.
Die Ausgabe der Metadaten erfolgt vorzugsweise durch eine geeignete Parameterdatei
(für HANS: e-oai_dc.hpr für Dublin Core und e-hansxml
sind Bestandteil der HANS-Distribution und in oai-hans.cgi angebunden;
für allegro-NRW: e-mabxml.mpr für Export als MABXML
ist verfügbar); dabei muss die Parameterdatei natürlich korrektes
XML liefern, das ausserdem den Syntaxvorschriften von OAI-PMH für einzuhägende
Fremdformate genügt.
Für das vom Protokoll vorgeschriebene (unqualified) Dublin Core unterstützt
die Anbindung eine Alternativmethode ohne Parameterdatei: In der Konfigurationsdatei
geben Sie zu jedem der relavanten Elemente von Dublin Core jeweils die Avanti-Befehle
(etwa "write #20" für title), die diese aus den Kategorien
der allegro-Datensätze sinnvoll beschicken.
^Top
Aktuelle Version: populo OAI v0.9_01 (08.02.2011)
Entpacken Sie das Distributionsarchiv populo-oai_n_m.zip unter Erhalt der Unterverzeichnisstruktur in ein CGI-Verzeichnis Ihres Webservers, in das populo.pl installiert ist.
Bauen Sie sich nach dem Muster der drei mitgelieferten Beispielkonfigurationen oai-avdemo.cgi (am vollständigsten kommentiert), oai-hansdemo.cgi (mit Voreinstellungen für allegro-HANS-Datenbanken) bzw. oai-nrwdemo.cgi (mit Voreinstellungen für allegro-NRW-Datenbanken) eine Konfigurationsdatei für Ihre Datenbank, in die Sie
Diese Version funktioniert mit populo ab v1.21 und aktuellen Avanti-Versionen (v30.10 / Januar 2011, Grundfunktionalitä möglicherweise ab v29.7).
populo-oai-0.9_02.zip (08.09.2011, 60kB) Enthält die Bibliotheksdatei oaipop.pm sowie ein Unterverzeichnis oai_tpl mit Job- und XML-Templates für populo, ausserdem Beispielinterfaces oai-xxdemo.cgi für die Avanti-Demodatenbank ($A.CFG) sowie die Demodatenbanken von allegro-HANS und allegro-NRW.
Lizensiert unter der GPL v3 oder neuer oder der Artistic License 2.0
Diese Version funktioniert mit populo ab v1.16 und äteren Avantis. Die Konfiguration ist inkompatibel zu der der neueren Version.
populo-oai_0_8.zip (23.1.2006, 45kB) Enthält die Bibliotheksdatei oaipop.pl sowie ein Unterverzeichnis oai_tpl mit Job- und XML-Templates für populo, ausserdem Beispielinterfaces oai-xxdemo.cgi für die Avanti-Demodatenbank ($A.CFG) sowie die Demodatenbanken von allegro-HANS und allegro-NRW.
Lizensiert unter der GPL v2
siehe Changes-OAI.txt.