Bibliotheks-Mashups mit Hürden auf dem Vormarsch

13. Juli 2007 um 18:06 8 Kommentare

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.

8 Kommentare »

RSS Feed für Kommentare zu diesem Artikel. TrackBack URI

  1. Offene Standards ermöglichen ja eigene Bastellösungen erst. Für Allegro-C gibt es eine BibTex-Exportparameterdatei, die allerdings noch an eigene Bedürfnisse angepasst werden muss. z. B. müssen wegen der von Dir erwähnten Schmalspur-Codierung alle zu erwartenden Sonderzeichen in LaTeX übersetzt werden. Da Bibliotheken hierzulande meist mit RAK-Transliterationen arbeiten, müssen die zu erwartenden Umschriften der einzelnen Zeichen in der Exportparamterdatei ebenfalls übersetzt werden.

    Kommentar by AG — 15. Juli 2007 #

  2. Klar, aber die Bastellösungen sollten wiederum soweit wie möglich auf Standards aufbauen und nicht völlig eigene Welten schaffen, wie in Allegro-C. Da gibt es zwar einen Haufen Dokumentation aber alles in Allem doch ein ziemliches viele historisch gewachsenene, selbstenwickelten Lösungen, die keinem Standard außer Allegro-C selbst folgen. Wohin die Entwicklung geht zeigt beispielsweise Indexdata mit Pazpar2: Das spricht nach der einen Seite Z39.50 – egal was für ein System dahinter steht – und kann auf der anderen Seite über eine offen dokumentierte Web-API angesprochen werden.

    Kommentar by jakob — 16. Juli 2007 #

  3. Ich habe die Erfahrung gemacht, dass Allegro nach allen Seiten hin offen ist – im Gegensatz zu vielen Web 2.0-Anwendungen. Man kann alles importieren und überallhin exportieren. Zum Glück ist die Welt nicht völlig standardisiert und wird es auch nicht sein – flexible Programme wie Allegro helfen dabei, trotzdem zu kommunizieren. Bibliographische Daten sind sehr komplex und lassen sich nicht optimal mit XML, BibTeX etc. abbilden (Bspl. Verknüpfungen und Hierarchien bei mehrbändigen Werken etc.). Kataloge sind über Jahrhunderte gewachsen und haben einige Standardmoden (PI, RAK) überdauert, die Daten sind heterogen. Bei Webstandards gebe ich Dir völlig recht – die sind auch schon immer offen (im Gegensatz zu bibliothekarischen… und den ISO-Normen) – aber wer hält sich schon daran? Am wenigsten gängige WYSIWYG-Editoren. Ergo: man braucht tolerante Browser, die den Quelltext trotzdem halbwegs richtig interpretieren und flexible Katalogsoftware, die mit verschiedensten Daten etwas anfangen kann.

    Kommentar by AG — 16. Juli 2007 #

  4. Jein. Wenn sich HTML-Autoren und WYSIWYG-Editoren nicht an Standards halten ist das nicht unsere Baustelle. Wenn sich aber Bibliotheken nicht an (u.A. ISO)-Standards halten oder eigene Standards für Dinge heranziehen, die anderswo schon standardisiert sind, ist das ein Mißstand, der zu beheben gilt. Die Aussage “Bibliographische Daten sind sehr komplex und lassen sich nicht optimal mit XML, BibTeX etc. abbilden” ist falsch und käme einer Bankrotterklärung gleich. Richtig wäre: “Bibliographische Daten sind sehr komplex und ihre Abbildung mit XML, BibTeX etc. ist nicht trivial”. Im übrigen habe ich manchmal den Eindruck, dass die Komplexität bibliographische Daten zu einem nicht unwesentlichen Teil erst durch Bibliothekare geschaffen wird, denen die Genauigkeit von Metadaten wichtiger ist als deren Nutzbarkeit. Die schönsten bibliographischen Daten sind jedoch wertlos wenn sie aufgrund von nicht-eingehaltenen oder nicht-verwertbaren Standards nicht genutzt werden können.

    Zum Glück ist es ja nicht so, dass Standards grundsätzlich mißachtet werden. Für Ländercodes gibt es beispielsweise ISO 3166 und für Sprachcodes ISO 639. Nur müssen Fehler bei der Anwendung dieser Standards auch als solche erkannt und nicht als “Hausinternere Zusatzregeln” beschönigt werden.

    Kommentar by jakob — 18. Juli 2007 #

  5. Das hat aber nichts mit der internen Datenbankstruktur zu tun. Es kommt darauf an, die richtigen Sachen in die richtigen Kategorien zu schreiben (DB-Austauschformat) und die Standards der bibliographischen Beschreibung (RAK) und der Sacherschließung einzuhalten. Das ist völlig unabhängig von der verwendeten Bibliothekssoftware. Wie das dann in Bibtex etc. abgebildet wird (Verknüpfungen, Sonderzeichen etc.), hängt von der Qualität der Exportparameter ab. Bei den Standards ist einiges im Fluss, MAB vs. MARC, Regensburg vs. Dewey, da einigen sich noch nicht mal die großen, es gibt also (noch?) keinen allgemeinverbindlichen Standard. Darauf kann man auch nicht warten, sondern muss eine (ggf.) vorläufige Entscheidung treffen.
    Bei den Sprachcodes ´weicht RAK von ISO 639 ab. Von hausinternen Zusatzregeln kann also keine Regel sein.

    Kommentar by AG — 23. Juli 2007 #

  6. P.S. Rede meinte ich natürlich. Das Entscheidungsträger im Bibliothekswesen die Einhaltung von Webstandards nicht für ihre Baustelle halten, merkt man an diversen Portalen, Digitalisierungsprojekten und Bibliothekshomepages. Sehr beliebt: Frames, nur für IE optimierte Webseiten, bibliographische Daten aus Bibliothekskatalogen werden in verschachtelte HTML-Tabellen ausgegeben, so dass man sie nicht einmal mittels Copy & Paste in eine Literaturliste bekommt, andere Anzeige- bzw. Exportmöglichkeiten werden sehr selten angeboten.

    Kommentar by AG — 23. Juli 2007 #

  7. [...] um die Fernleihe zu koordinieren. Das alles spielt sich aber rein intern ab und hat mit Web 2.0 und Bibliotheks-Mashups noch nichts zu [...]

    Pingback by Mehr zu Schnittstellen von Bibliothekssystemen « Jakoblog — Das Weblog von Jakob Voß — 14. September 2007 #

  8. Zu ““Bibliographische Daten sind sehr komplex und ihre Abbildung mit XML, BibTeX etc. ist nicht trivial”” gebe ich Jakob vollkommen recht und muss ihm hier beistehen. Der ELIB Katalog arbeitet seit 5 Jahren mit bibliografischen Daten und präsentiert diese als XML-Daten nach außen. Die Kunst liegt hier in der Konvertierung in die geeignete Darstellungsform, sei es als BibTex- oder HTML-Format. Entscheidend ist, dass die Konvertierung offen für alle einsehbar ist und nachgenutzt werden kann.
    Die Konvertierung mittels Allegro-C bzw. php ist nur dann einsehbar, wenn man die Sourcen hat. Daher scheint die Neigung zu OpenSource-Lösungen stark ausgeprägt zu sein.
    Es gibt auch einen anderen Ansatz: Freie Verfügbarkeit der Konvertierungsvorschrift, wie diese z.B. in http://suche3.suub.uni-bremen.de/styles/bibsonomy.xml zu sehen ist.
    Mit Hilfe dieser Konv.vorschrift ist es prinzipiell möglich, mit Hilfe von XML-Daten via Cocoon oder Xalan aus jedem Katalog eine Exportmöglichkeit zum Bibsonomy-Konto mit UTF-8-Kodierung (unterstützt gerade auch Sonderzeichen) herzustellen (wie dies bei ELIB mittlerweile auch möglich ist).

    Kommentar by EH — 17. Juli 2008 #

Entschuldige, das Kommentarformular ist zurzeit geschlossen.

Powered by WordPress with Theme based on Pool theme and Silk Icons.
Entries and comments feeds. Valid XHTML and CSS. ^Top^