Schlankes OAI Data Providing mit Aleph 500 oder

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… Dr. Mathias Kratzer, Bayerische Staatsbibliothek / BVB-Verbundzentrale

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

1 OAI Protocol for Metadata Harvesting (OAI-PMH) 3

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

Aufbau eines lokalen Spiegels Download des Gesamtabzugs zum Stichzeitpunkt T 0 Teilpake t B 3 Kat 5 Lokaler Spiegel

Schritt 2: Laufendes Harvesting List. Records from T 0 until T 1, from T 1 until T 2, … Identify Data Provider (OAI Repository) List. Metadata. Formats Get. Record List. Identifiers List. Records 6 OAI Harvester List. Sets Service Provider

2 Standard OAI Data Providing mit Aleph 500 7

Wer O sagt, muss auch P sagen § Aleph 500 kommt mit eingebautem OAI Data Provider § Base-URL: http: //<host>: <port>/OAI § Konfiguration: $alephe_tab/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. 8

Publishing mit Aleph 500 § Base-abhängig oder Gesamtbestand § Konfigurationsdatei: $data_tab/tab_publish § Zieltabelle Z 00 P, u. a. mit den Spalten • Publishing Set (Z 00 P_SET) Z 00 P_SET • Zeitstempel (Z 00 P_TIMESTAMP) Z 00 P_TIMESTAMP • Metadatensatz (Z 00 P_STR) Z 00 P_STR § initiales Publishing mit Aleph-Service publish_04 § laufendes (Re-)Publishing durch den mit UE_01 „in Serie geschalteten“ UE_21 9

Vorteile dieser Implementierung § sehr performantes Data Providing, da bereitzustellende Metadaten direkt anhand der Anfrageparameter aus der Datenbank (Z 00 P) 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 10

Nachteile dieser Implementierung § Soll ein Metadatensatz in m (≥ 2) Formaten und n Sets angeboten werden, so muss er (m × n)-mal in die Z 00 P geschrieben werden. Hoher Platzverbrauch! § initiales Publishing sehr langsam (B 3 Kat-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 11

Initiales Publishing des B 3 Kat § Klonen der Titeldatenbank BVB 01 unter Oracle § Gesamtabzug der BVB 01 in MARCXML und Start des UE_21 auf leerer Z 00 P zum selben Zeitpunkt T 0 § initiales Publishing des BVB 01 -Klons in einer exklusiv hierfür gesperrten Aleph-Testumgebung mit „Z 00 PK“ § satzweises Übertragen aus Z 00 PK nach Z 00 P, sofern dort keine neuere Version existiert (OAI-Zeitstempel übertragener Sätze hinter T 0 zurückshiften!) 12

3 Schlankes OAI Data Providing mit Aleph 500 13

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

Wo ist es dokumentiert? https: //www. bib-bvb. de/web/b 3 kat/open-data 15

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

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

4 Cavete! 18

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! 19

Kleine Schritte, schneller am Ziel! § Auch wer nicht laufend, sondern z. B. nur einmal am Tag harvestet, sollte sukzessive kleinere Zeitstempelbereiche 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). 20

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. 21

5 Wozu braucht man das? 22

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

Requestaufkommen [Messzeitraum 08. 05. bis 18. 06. 2017] § im Schnitt etwas mehr als Requests pro Woche 81. 100 Harvester- § Tagesmittel über eine Woche schwankt zwischen 6. 000 und etwas mehr als 31. 000 Harvester-Requests • knapp • 24

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