Schlankes OAI Data Providing mit Aleph 500

Präsentation zum Thema: "Schlankes OAI Data Providing mit Aleph 500"—  Präsentation transkript:

1 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…

2 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?

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

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

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

6 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

7 2 Standard OAI Data Providing mit Aleph 500

8 Wer O sagt, muss auch P sagen
Aleph 500 kommt mit eingebautem OAI Data Provider Base-URL: 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.

9 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

10 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

11 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

12 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!)

13 3 Schlankes OAI Data Providing mit Aleph 500

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

15 Wo ist es dokumentiert?

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

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

18 4 Cavete!

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

20 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).

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

22 5 Wozu braucht man das?

23 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!] …

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

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