[Allegro] OAI-PMH Repository fuer avanti
Thomas Berger
ThB at Gymel.com
Fr Jan 28 12:34:19 CET 2011
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Liebe AllegrologInnen,
0. Vor- und Fruehgeschichte
Am 15.04.2005 16:29, schrieb Thomas Berger:
> Auf dem heute zuende gegangenen Anwendertreffen von allegro-HANS
> wurde gestern eine Schnittstelle praesentiert, die ein OAI-PMH-Repository
> fuer avanti realisiert, mit Konfigurationsmoeglichkeit fuer beliebige Datenbanken.
> Diese Schnittstelle ist im Rahmen des DFG-gefoerderten Projekts Kalliope II
> entwickelt worden und steht unter der GPL.
>
> Informationen zu OAI-PMH unter http://www.openarchives.org/
> Informationen zur Schnittstelle unter http://www.gymel.com/populo/oai-pmh.html
Am 29.01.2009 10:23, schrieb Bernhard Eversberg:
> Verlautbarung 213 der Entw.Abt. 2009-01-29
> -------------------------------
[...]
> 7. OAI : Jetzt auch aktiv - Werden Sie Data-Provider!
> -----------------------------------------------------
> Was ist eigentlich OAI? Hier steht's: http://www.allegro-c.de/oai.htm
>
> Wer mittels OAI Daten anderswo aberntet und sinnvoll verwendet, wird
> "Service Provider" genannt, weil er aus den geernteten Daten einen
> (Mehrwert-)Dienst macht. Wer auf der anderen Seite sitzt, also seine
> eigenen Daten zum Abernten per OAI freigibt, ist ein "Data Provider".
> Vielleicht wollen auch Sie dieser Erzeugergemeinschaft beitreten?
> Die Voraussetzungen dafuer wurden jetzt geschaffen mit einer Anzahl von
> PHPs und JOBs. Das Skript oai.php bildet die Basis-Adresse der Sache,
[...]
1. Gegenwart
In letzter Zeit gab es ein zunehmendes Interesse, zwar nicht explizit
an OAI-Schnittstellen, sondern eher an gezielter Datenuebernahme aus
nicht unbedingt bibliothekarische Mainstream-Anwendungen. Im Prinzip sind
hierfuer unAPI-Schnittstellen meiner Meinung nach am besten geeignet,
wirken allerdings sehr informell, OAI-PMH ist aber auch recht gut
geeignet, ebenso wie SRU, was aber wegen seines Schwerpunkts auf
*Recherche* aufwendiger zu implementieren waere (eine Aufgabe fuer avanti?).
"Echtes" Z39.50 ist da schon weniger attraktiv, Vorhalten der Schnittstelle
bedeutet ja nicht unbedingt, dass man anhand Signaturen, Identnummern oder
anderer bekannter "Identifier" zugreifen kann, dazu muessen bereits
Sonderverabredungen getroffen werden...
In den aktuellen Szenarios (Digitalisierungsprojekte, Teilnahme an
Virtual Libraries) ist es jeweils bekannt dass die Zielanwendung zwar
gerne etwas mehr als Dublin Core moechte, aber gemaess ihren eigenen
Zwecken ausschlachten und Ausduennen wird (spaetestens wenn es um
Anzeige in einer Publikumsanwendung geht, tun wir das ja sogar selber).
Ausserdem liegt es in der Natur dieser Projekte, dass eine Art
Rueckverlinkung in das Herkunftssystem gewaehrleistet sein muss. Fuer
"traditionelle" Datenlieferungen muss man entweder mit dem Empfaenger
verabreden, wie er aus dem Inhalt des Identnummernfelds im jeweils
verabredeten Format eine URL bauen kann (und hoffen, dass er dies dann
in sein System einprogrammiert oder die Daten vor dem Import geeignet
vorbehandelt) oder aber verabreden, in welchem - dann latent gesondert
zu behandelndem - Datenfeld man eine URL auf den Katalogeintrag dieses
Datensatzes hinterlegt hat (konkret etwa eine zusaetzliche MAB 655 mit
Katalog-URL und einem schematischen Kommentar $zKatalognachweis).
2. backlinks - Format
OAI-PMH erlaubt es, sowohl zentral fuer das Repository im Rahmen von
"description"-Containern als auch zusaetzlich zu den eigentlichen Metadaten
(im vom Abgreifenden gewaehlten Format) in sogenannten "about"-Containern
zusaetzliche Informationen *ueber* die Metadaten abzulegen, metameta
also. In http://www.openarchives.org/OAI/2.0/guidelines.htm sind im
Abschnitt "Guidelines for Optional Containers" einige offizioese Formate
aufgefuehrt, hier geht es z.B. um Rechte-Hinweise allgemein und um
Branding (zwingend zu zeigende Logos bzw. sogar zur Formatierung zu
nutzende Stylesheets). Fuer Rueckverlinkungs-Zwecke habe ich nun
adhoc ein ganz einfaches Format definiert,
http://www.findbuch.de/OAI/backlinks/0.1/backlinks.xsd
das sich am HTML-Link-Element orientiert. Es erlaubt das Einhaengen
eines "backlinks"-Elements in einem description-Container im OAI-
Identify Request:
<description>
<backlinks xmlns="http://www.findbuch.de/OAI/2.0/backlinks/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.findbuch.de/OAI/2.0/backlinks/
http://www.findbuch.de/OAI/backlinks/0.1/backlinks.xsd">
<urlTemplate placeHolder="{ID}"
type="text/html"
rel="opac"
>http://avdemo.gymel.com/cgi-bin/avdemo.pl?t_idn={ID}</urlTemplate>
</backlinks>
</description>
oder in einem about-Container anlaesslich der Ausgabe eines Datensatzes
mit Metadaten:
<about>
<backlinks xmlns="http://www.findbuch.de/OAI/2.0/backlinks/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.findbuch.de/OAI/2.0/backlinks/
http://www.findbuch.de/OAI/backlinks/0.1/backlinks.xsd">
<backReference type="text/javascript"
ref="http://avdemo.gymel.com/cgi-bin/avdemo.pl/seealso/?id=834486;format=seealso"
rel="seealso" />
<backReference type="text/html"
ref="http://avdemo.gymel.com/cgi-bin/avdemo.pl?t_idn=834486"
rel="opac" />
<backReference type="application/xml"
ref="http://avdemo.gymel.com/cgi-bin/avdemo.pl/seealso/?id=834486"
rel="unapi" />
</backlinks>
</about>
Die Sache ist wiederholbar gestaltet, bei maschineller Weiterverarbeitung
kann man sich auf Links eines Mime-Typs konzentrieren, den man kennt,
oder sich am eher informellen Wert des rel-attributs orientieren.
Dieses Format ist ein *Format*, d.h. unabhaengig von der Betriebssoftware
eines Repositories koennten die Betreiber beschliessen, dass es nuetzlich
ist und ihre Antworten mit den entsprechenden Containern ausstatten.
3. OAI Interaktiv
Beeindruckt hatte mich stets die von OCLC betriebene Registry zu OpenURL:
http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=Identify
Im Prinzip handelt es sich hier um ein OAI-Repository, das durch die
Referenzierung eines XSLT-Stylesheets in den XML-Antworten zu einer
Interaktiven Anwendung fuer Menschen wird (dank der XSLT-Faehigkeiten
ihrer Browser). Ich indirekt ueber die Tools-Abteilung von
< http://www.openarchives.org/pmh/tools/ > ein primitiveres XSLT-
Stylesheet unter der GPL gefunden, das ich etwas aufgemotzt habe und
unter der GPL v3 zur Verfuegung stelle:
< http://svn.gymel.com/viewvc/allegro/oai/trunk/fixoai/styles/ >
Wird das Stylesheet ausgefuehrt, so fuehrt es im Hintergrund stets
einen weiteren "Identify"-Request auf das Repository aus und ist
damit in der Lage, eine halbwegs sinnvolle Ueberschrift zu praesentieren,
und auch anderes, wenn der Identify-Request etwas reichhaltiger als
das vom Protokoll erforderte Minimum ist.
Beispiel-Anwendung:
< http://avdemo.gymel.com/cgi-bin/oai-avdemo.cgi >
(das hatte mich immer geaergert: Das Protokoll verlangt, dass die
Anwendung mit einer Fehlermeldung reagiert, wenn sie ganz ohne
Parameter aufgerufen wird. Dank XSLT-Stylesheet gibt es nun im
Browser immer etwas, wo man draufklicken kann und es dann sinnvoll
weiter geht...)
Dieses Stylesheet ist universell, d.h. es kann in den Antworten beliebiger
Repositories referenziert werden. (Sicherheits-) Voraussetzung ist allerdings,
dass seine URL denselben Host bezeichnet, wie die URL des einbindenden
Repositories (etwas weniger korrekt, aber vielleicht verstaendlicher
formuliert: Skript und Repository muessen auf demselben Server liegen,
sonst wird ein Internet-Browser die Ausfuehrung ablehnen)
4. Die Populo-Realisierung eines OAI-PMH-Interfaces
Ich hatte die seit 2005 nicht weiter angefasst, jetzt im Januar
jedoch mich dafuer interessiert, ob sie unter aktuellen Populo-
und Avanti-Versionen noch funktioniert. Die Datenbank, fuer die
mich das besonders interessierte, ist mit ueber 500.000 Saetzen
nicht besonders klein und es gab Probleme mit den Standard-
Timeouts des Webbrowsers, wenn man etwa alle Aenderungen vom
letzten Sonntag selektierte: Die "erschwerte Volltextsuche" (alle
Saetze in Satznummernreihenfolge besuchen und per Flex testen)
ist zwar ganz schoen fix, der Browser als Interface aber im Gegensatz
zu dedizierten OAI-Harvestern recht ungeduldig und der eigene
Apache beschloss bereits nach 120 Sekunden ohne Ausgabe, das sich
Warten nicht mehr lohnt und beendete die Angelegenheit.
In Folge habe ich dann die Selektionen, Filter und Tests in den
Beispielanwendungen neu strukturiert, wenn die relevanten Datums-
stempel indexiert sind, koennen nun die Saetze vom (oder seit dem,
bis zum, von-bis) "letzten Sonntag" mit der von-bis-Suche in der
Flex/Jobsprache selektiert werden, das macht es bei kleinen Datenmengen
wesentlich schneller (bei grossen Datenmengen kann es theoretisch weiterhin
Probleme geben, wenn die Datumsselektion die Ergebnismengengroesse
sprengt, aber alle zu ziehenden Saetze hohe Satznummern haben, dazu folgt
demnaechst eine Mail mit Feature-Requests ...)
Ergebnis: Die neue Version funktioniert nur mit neueren Avanti-
Versionen ($-Variable und "xcode" werden genutzt) ab ca. v29.8
Die Standard-Portionsgroesse ist 1000 Saetze, dazu werden dann
auch find # ... -Befehle mit dieser Zahl von Satznummern abgesetzt.
avanti bis V30.10 von 2011 konnte dies aber nur fuer Zeilen mit
weniger als 4000 Zeichen laenge, fuer aeltere Avantis muss die
Portionsgroesse daher niederiger konfiguriert werden (500 oder kleiner).
Eine andere Anforderung war, dass (HANS-Datenbanken) durch Aktivierung
exakt einer Konfigurationseinstellung um die OAI-PMH-Funktionalitaet
"angereichert" werden sollen, d.h. Standalone-Anwendungen wie
< http://hansdemo.gymel.com/cgi-bin/oai-hansdemo.cgi >
sollen immer noch moeglich sein, aber auch "integrierte" wie das in
den Standard-Katalog
< http://hansdemo.gymel.com/cgi-bin/hansdemo.pl >
integrierte OAI-Interface
< http://hansdemo.gymel.com/cgi-bin/hansdemo.pl/oai-pmh/ >
Und weil nicht jeder Webserver "PathInfo" (also das Anhaengen von
Pfadkomponenten an die "echte" URL eines Skripts) unterstuetzt oder
der Web-Administrator zur Steuerung der Zugriffsrechte lieber ein
"echtes" Objekt im Dateisystem mag, sollen auch Zwischenloesungen
moeglich sein, die als eigene URL ansteuerbar sind, aber die
Konfiguration des bestehenden OPACs auslesen:
< http://hansdemo.gymel.com/cgi-bin/oai-pmh >
Ergebnis: Die neue Version funktioniert nur mit der aktuellsten
Populo-Version (1.21)
Und Konsequenz aus beiden: Die Konfiguration des Populo-OAI-Interfaces
ist aehnlich den frueheren Versionen, aber nicht kompatibel.
Abweichend von den vorigen Versionen steht die aktuelle Version unter
der GPL v3 (war v2) oder neuer. Die Informationsseite
< http://www.gymel.com/populo/oai-pmh.html >
war inhaltlich vage genug, so dass sie auch weiterhin gueltig ist,
die hier zitierten Demo-Anbindungen sind im Distributionspaket
populo-oai-0.9.zip (auf der erwaehnten Seite zum Download angeboten,
es enthaelt nur die "OAI"-Dateien, nicht die Populo-Distribution)
enthalten, sowie in die kommenden Versionen des HANS-Standard-OPAC
bereits integriert.
viele Gruesse & Schoenes Wochenende
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iJwEAQECAAYFAk1CqboACgkQYhMlmJ6W47O8RAP/VYaqBVM/fiQ9OhllaUq2PkCD
/el7PkfLD9dfbSgdJxGFpCNXwPrNbdG3EaHshAABRATgsuGFsPMMkLIG7S13uNF/
ergW6dVgiLhta/m9zKmxH6cQfVgS8e02zPIbgp4F8AL54zj0qhIuMIKE84mKIz2x
UOi0FZIgONH7FRS6SUE=
=qFbn
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Allegro