Jakoblog — Das Weblog von Jakob Voß

GBV-Verbunddaten weiterverarbeiten mit SRU-Schnittstelle und Perl

Ende Juli habe ich im Rahmen meiner Arbeit bei der VZG mit PICA::Record eine Perl-API zur Verarbeitung von PICA+-Daten veröffentlicht. PICA+ ist das interne Katalogformat von PICA-Bibliothekssystemen, die neben dem GBV und den Verbünden HeBIS und SWB auch bei der Deutschen Nationalbibliothek und für Zentralsysteme in den Niederlanden, Australien, Frankreich und England eingesetzt werden. Inzwischen ist PICA übrigens eine vollständige OCLC-Tochterfirma. Mehr zum PICA+ Format findet sich in den jeweiligen Katalogisierungsrichtlinien, zum Beispiel beim GBV und in dieser kurzen Einführung.

PICA::Record ist sozusagen ein Pendant zu Mike Rylanders CPAN-Modul MARC::Record, das bereits seit einigen Jahren bei MARC-Anwendern genutzt und in der Mailingliste perl4lib diskutiert wird. Feedback in Form von Anwendungen, Ideen, Bugreports etc. ist sehr willkommen – zum Beispiel öffentlich bei der Dokumentation im GBV-Wiki. Neben der Erzeugung von Datensätzen in PICA+, um diese in Katalogsysteme einzuspielen, eignet sich PICA::Record auch für die umgekehrte Richtung. Dazu ist ein einfacher SRU-Client implementiert; die entsprechende SRU-Schnittstelle bietet der GBV seit einiger Zeit inoffiziell und nun auch öffentlich an. Für Bibliotheks-Mashups ist die SRU-Schnittstelle ein Baustein und die Perl-API ein mögliches Bindemittel. Natürlich kann der Webservice auch mit anderen Methoden als mit Perl abgefragt werden.

Beispiele und Anleitungen gibt es unter Anderem in der API-Dokumentation, im Quelltext oder hier.

Förderpreis für Suchmaschinen

Der Gemeinnützige Verein zur Förderung der Suchmaschinen-Technologie und
des freien Wissenszugangs (SuMa e.V.) schreibt mit dem SuMa Awards 2008 einen Förderpreise für Suchmaschinen aus. Für seine Bemühungen Alternativen zu Google aufzuzeigen und umzusetzen musste Herr Sander-Beuermann schon einige Häme einstecken – jetzt können die Kritiker also beweisen, dass sie es besser können.

Nach den bisherigen Informationen beschränkt sich der Wettbewerb nicht nur auf technische Realisierungen – auch wirtschaftliche und künstlerische Auseinandersetzungen sind gefragt. Mich würde beispielsweise interessieren, was an Semantic Web und Suchagenten wirklich dran ist und wie personalisierte Suchdienste das Suchverhalten verändern – werden wir ohne Internet bald an digitalem Alzheimer leiden? Am Wettbewerb kann also jeder vom Studenten bis zur Forschungsgruppen teilnehmen.

Unter SuMa-Lab.de zeigt der Verein einige existierende Projekte, daneben ist sicherlich A9 einen Blick wert. Eine Suchmaschine muss auch nicht von Grund auf neu programmiert werden, sondern kann mit etablierten Techniken (OpenSearch, SRU, OAI, RSS etc.) vielleicht sogar einfach zusammengeklickt werden – ob kleine Lösungen wie Planet Biblioblog den Hauptpreis bekommen, weiß ich nicht aber mit vielen solcher kleinen Lösungen („Webservices“) ist sicherlich mehr zu erreichen als mit dem Versuch eines dicken Google-Clons. Vergleichbare Wettbewerbe (allerdings mehr technik-zentriert) gab es übrigens schon bei Talis (Mashing Up The Library competition) und bei OCLC (OCLC Research Software Contest).

Bibliotheks-Mashups mit Hürden auf dem Vormarsch

Wie von Patrick und im BibSonomy Blog berichtet wurde, bietet der Kölner UniversitätsGesamtkatalog (KUG) seit kurzem den Export von Datensätzen in das Kasseler Social-Cataloging-System Bibsonomy an. Als gemeinsames Datenformat fungiert BibTeX, das neben Dublin Core trotz einiger Probleme im Gegensatz zu Spezialformaten wie MARC und MAB De-facto-Standard für solche Anwendungen ist.

Prinzipiell kann jede Bibliothek, die BibTeX exportieren kann, den gleichen Service anbieten. Die Übergabe an BibSonomy funktioniert über eine einfache REST-API, die anscheinend in Kürze veröffentlicht werden soll. Die URL-Syntax is

http://www.bibsonomy.org/BibtexHandler?requTask=upload&encoding=ISO-8859-1&selection=…BibTeX-Datensatz…

Welche Zeichenkodierungen neben ISO-8859-1 noch möglich sind, weiß ich nicht; bislang werden auch sinnlose Werte anstandslos akzeptiert. Problematisch könnte es auch bei umfangreichen Datensätzen werden. Prinzipiell legt der HTTP-Standard zwar keine Längenbegrenzung für URLs fest, aber verlassen würde ich mich darauf nicht. Natürlich gibt es auch bei der Konvertierung noch einige Bugs, siehe zum Beispiel dieser Datensatz, bei dem die Keywords ziemlich durcheinander geworfen werden.

Dazu muss gesagt werden dass ein fehlerfreier BibTeX-Export komplizierter ist als angenommen. Der KUG wird mit der Software OpenBib betrieben, die – so sollte es sein – Open Source ist. Nach kurzer Recherche im Quelltext zeigt sich die Funktion normset2bibtex als Kernbestandteil der Konvertierung nach BibTeX. Mir ist neulich auch schon ein PICA+ nach BibTeX-Script über den Weg gelaufen, aber wenn jede Bibliothek und jeder Hersteller ihr eigenes kleines Skript schreiben, können bei der Konvertierung qualitativ keine großen Sprünge gemacht werden. Ein guter Kandidat für eine dauerhafte Lösung sind vielleicht die Bibutils bibliography conversion utilities, die als Intermediate-Format das Metadata Object Description Schema (MODS) verwenden und ebenso wie OpenBib unter der GPL zur Verfügung stehen. By the way: Warum werden von DFG & Co eigentlich laufend Anträge ohne technischen Sachverstand gefördert, bei denen am Ende nur unfreies Gewurstel rauskommt, anstatt konsequent auf Open Source zu setzen, damit am Ende alle etwas davon haben?

Und noch eine positive Überraschung brachte das Stöbern im Quellcode und der Dokumentation: Der OpenBib-Entwickler Oliver Flimm hat bereits 2005 mit den Open Library WebServices eine SOAP-Schnittstelle für Sisis-Systeme implementiert (siehe Dokumentation und Quellcode), die anscheinend direkt auf die SQL-Datenbank zugreift. Bisher hatte ich von Sisis-Systemen eher den Eindruck, dass sie mit Schnittstellen nicht so freizügig sind. Zwar gibt es beispielsweise schon seit längerer Zeit das Simple Library Network Protocol (SLNP), aber eine offene API-Dokumentation und freie Implementierungen von auf diese API zugreifenden Clients habe ich bisher nicht finden können.

Mit den Open Library WebServices können Benutzerdaten (Ausleihen, Vorbestellungen etc.) und über die interne Datenbank-ID eines Katalogdatensatzes der Medienstatus (Signatur, Exemplar, Standort, Status, Rueckgabe) sowie die vollständigen Titeldaten abgerufen werden. Um welches „nativen Kategorienschema“ es sich bei den Titeldaten handelt, kann ich leider aus Unkenntnis von Sisis-LBS-Systemen nicht sagen, vielleicht MAB2, aber dann sollte besser MABXML geliefert werden und die Konvertierungsroutine nach BibTeX wie oben angedeutet als eigenständiges MAB2-nach-BibTeX-Modul.

Jedenfalls ein großes Lob an Oliver Flimm für die Entwicklung von OpenBib. Ich hoffe, dass die Weiterentwicklung mehr in Richtung einer Serviceorientierten Architektur geht, indem einzelne Funktionen sauber getrennt und als Webservice gekapselt werden. So können Funktionen wie der BibTeX-Export und die Weiterreichung nach BibSonomy als Bausteine auch in anderen Katalogprojekten zum Einsatz kommen können, beispielsweise bei X-OPAC und E-LIB Bremen. Auch dort steckt eine Menge intelligenter Eigenentwicklung, aber noch werkelt jeder vor sich hin. Bei den Schnittstellen sollte deshalb, wie ich vor kurzem in INETBIB betonte, streng auf offene Standards gesetzt werden anstatt eigene Bastellösungen zu verwenden, dann klappt’s auch mit den Mashups.