Schlankes OAI Data Providing mit Aleph 500 oder: Wie mittels Perl & XSLT aus einem realen beliebig viele virtuelle OAI-Sets am Rande der Protokoll-Konformität werden…

Inhalt OAI Protocol for Metadata Harvesting (OAI-PMH) Standard OAI Data Providing mit Aleph 500 Schlankes OAI Data Providing mit Aleph 500 Cavete! Wozu braucht man das?

1 OAI Protocol for Metadata Harvesting (OAI-PMH)

OAI Basics OAI-PMH ist eine Methode zum „Daten-Abgrasen“. Standard-Use-Case: Synchronisation mit Masterdatenbank

Aufbau eines lokalen Spiegels Download des Gesamtabzugs zum Stichzeitpunkt T0 B3Kat Lokaler Spiegel Teilpaket

Schritt 2: Laufendes Harvesting ListRecords from T0 until T1, from T1 until T2, … Data Provider (OAI Repository) OAI Harvester Service Provider Identify ListSets ListMetadataFormats GetRecord ListIdentifiers ListRecords

2 Standard OAI Data Providing mit Aleph 500

Wer O sagt, muss auch P sagen Aleph 500 kommt mit eingebautem OAI Data Provider Base-URL: http://<host>:<port>/OAI Konfiguration: $alephe_tab/oai/oaipubconf.xml Grundprinzip: Bereitstellung der Metadaten zum Harvesting erfolgt nicht „on the fly“ sondern per Publishing vorab, d. h. unmittelbar nach Erst- bzw. jeder Neuindexierung, in sämtlichen potentiell angefragten Formaten und für alle definierten Sets, zu denen ein Datensatz gehört.

Publishing mit Aleph 500 Base-abhängig oder Gesamtbestand Konfigurationsdatei: $data_tab/tab_publish Zieltabelle Z00P, u.a. mit den Spalten Publishing Set (Z00P_SET) Zeitstempel (Z00P_TIMESTAMP) Metadatensatz (Z00P_STR) initiales Publishing mit Aleph-Service publish_04 laufendes (Re-)Publishing durch den mit UE_01 „in Serie geschalteten“ UE_21

Vorteile dieser Implementierung sehr performantes Data Providing, da bereitzustellende Metadaten direkt anhand der Anfrageparameter aus der Datenbank (Z00P) gelesen werden können sichere Synchronisation bei sukzessivem Harvesting, da OAI-Zeitstempel = Publishing-Zeitstempel (im Allg. nicht der Indexierungs-Zeitstempel!) Bereitstellung von Updates in Quasi-Echtzeit, sofern die Indexierung von Aleph nicht gerade hinterherhinkt aktuelle

Nachteile dieser Implementierung Soll ein Metadatensatz in m (≥2) Formaten und n Sets angeboten werden, so muss er (m × n)-mal in die Z00P geschrieben werden.  Hoher Platzverbrauch! initiales Publishing sehr langsam (B3Kat-Gesamtbestand braucht mehrere Monate!) initiales Publishing „sperrt“ Titeldatenbank für schreibende Zugriffe (z.B. Katalogisierung) laufendes Publishing kann durch Massenimporte evtl. weit hinter den Gegenwartshorizont zurückfallen

Initiales Publishing des B3Kat Klonen der Titeldatenbank BVB01 unter Oracle Gesamtabzug der BVB01 in MARCXML und Start des UE_21 auf leerer Z00P zum selben Zeitpunkt T0 initiales Publishing des BVB01-Klons in einer exklusiv hierfür gesperrten Aleph-Testumgebung mit „Z00PK“ satzweises Übertragen aus Z00PK nach Z00P, sofern dort keine neuere Version existiert (OAI-Zeitstempel übertragener Sätze hinter T0 zurückshiften!)

3 Schlankes OAI Data Providing mit Aleph 500

Weerchattserrrfunden?! Dr. Stefan Brecheisen Brigitte Kudszus Dr. Petra Schröder Bernhard Weitzhofer

Wo ist es dokumentiert? https://www.bib-bvb.de/web/b3kat/open-data

Request oai_opendata.pl Aleph OAI Data Provider OAI Harvester ohne Set mit Set

Response oai_opendata.pl XSLT-Filter OAI Harvester Aleph Treffer OAI Provider OAI Harvester Treffer alle oai_opendata.pl Set- Treffer XSLT-Filter

4 Cavete!

Resumption Tokens Qualifizieren sich „zu viele“ Treffer für die Response, wird sie in Portionen mit zugehörigem Resumption Token ausgeliefert. Gegen das Resumption Token der jeweils letzten Portion gibt es die nächste. Wo „zu viel“ beginnt, ist ein Parameter des Repositorys. Im Falle von Aleph liegt das Limit hartcodiert bei 31. Resumption Tokens sind nicht ewig gültig!

Kleine Schritte, schneller am Ziel! Auch wer nicht laufend, sondern z.B. nur einmal am Tag harvestet, sollte sukzessive kleinere Zeitstempel- bereiche abfragen, statt alles mit einem Request. Ansonsten drohen Responses in so vielen Teilportionen, dass nicht alle abgeholt werden können, bevor die Resumption Tokens ablaufen. Im schlimmsten Fall tritt der Harvester dauerhaft auf der Stelle (z.B. wegen regelmäßiger Wartungsfenster des Repositorys).

Leere Response? – Immer weiter! Durch die XSLT-Filterung von oai_opendata.pl enthalten Teilportionen neben dem Resumption Token in aller Regel keine 30 Datensätze mehr … … sondern können bis auf das Resumption Token sogar völlig leer sein! Was menschliche „Harvester“ irritiert, sollte maschinelle nicht aus der Bahn werfen, denn OAI-PMH verbietet leere Teilportionen nicht.

5 Wozu braucht man das?

Nutzungsszenarien OAI-Sets für alle B3Kat-Teilnehmer! Titelversorgung von Lokalsystemen (z.B. Koha) Export on demand für selbst nicht am B3Kat teilnehmende FID-Partner von B3Kat-Teilnehmern Aktualisierung von Suchmaschinenindices: Gateway Bayern, KOBV-Portal, GVI und Primo Central GetRecord wahlweise auch mit B3Kat-ID statt SYS-ID … [Open Data!] …

Requestaufkommen [Messzeitraum 08.05. bis 18.06.2017] im Schnitt etwas mehr als 81.100 Harvester- Requests pro Woche Tagesmittel über eine Woche schwankt zwischen knapp 6.000 und etwas mehr als 31.000 Harvester-Requests Wochen

… gerne auch an kratzer@bsb-muenchen.de ! Fragen? … gerne auch an kratzer@bsb-muenchen.de !