Heidelberger Katalog auf dem Weg zu Serviceorientierter Architektur

23. Dezember 2007 um 20:59 4 Kommentare

Die zunehmende Trennung von Bibliotheksdaten und ihrer Präsentation zeigt „HEIDI“, der Katalog der Unibibliothek Heidelberg. Vieles, was moderne Bibliothekskataloge bieten sollten, wie eine ansprechende Oberfläche, Einschränkung der Treffermenge per Drilldown, Permalinks, Exportmöglichkeit (u.A. direkt nach BibSonomy), RSS-Feeds und nicht zuletzt eine aktuelle Hilfe für Benutzer ist hier – zwar nicht immer perfekt, aber auf jeden Fall vorbildhaft – umgesetzt. Soweit ich es von Außen beurteilen kann, baut der Katalog auf zentralen Daten des Südwestdeutschen Bibliotheksverbundes (SWB) und lokalen Daten des lokalen Bibliothekssystems auf. Zum Vergleich hier ein Titel in HEIDI und der selbe Titel im SWB-Verbundkatalog. Aus dem Lokalsystem werden die Titeldaten mit Bestands- und Verfügbarkeitsdaten der einzelnen Exemplare angereichter, also Signatur, Medien/Inventarnummer, Standort, Status etc.:

Exemplardaten in HEIDI

Die tabellarische Ansicht diese Daten erinnert mich an WorldCat local, das sich zu WorldCat teilweise so verhält wie ein Bibliotheks-OPAC zu einem Verbundsystem. Hier ein Beispieldatensatz bei den University of Washington Libraries (und der gleiche Datensatz in WorldCat). Die Exemplardaten werden aus dem lokalen Bibliothekssystem als HTML-Haufen per JavaScript nachgeladen, das sieht dann so aus:

Exemplardaten in University of Washington Libraries

Bei HEIDI findet die Integration von Titel- und Exemplardaten serverseitig statt, dafür macht der Katalog an anderer Stelle rege von JavaScript Gebrauch. In beiden Fällen wird eine proprietäres Verfahren genutzt, um ausgehend von einem Titel im Katalog, die aktuellen Exemplardaten und Ausleihstati zu erhalten. Idealerweise sollte dafür ein einheitliches, offenes und webbasiertes Verfahren, d.h. ein RDF-, XML-, Micro- o.Ä. -format und eine Webschnittstelle existieren, so dass es für den Katalog praktisch egal ist, welches lokale Ausleih- und Bestandssystem im Hintergrund vorhanden ist. Die Suchoberfläche greift damit als als ein unabhängiger Dienst auf Katalog und Ausleihsystem zu, die ihrerseits eigene unabhängige Dienste mit klar definierten, einfachen Schnittstellen bereitstellen. Man spricht bei solch einem Design auch von „Serviceorientierter Architektur“ (SOA), siehe dazu der Vortrag auf dem letzten Sun-Summit. Eigentlich hätte beispielsweise die IFLA sich längst um einen Standard für Exemplardaten samt Referenz-implementation kümmern sollen, aber bei FRBR hat sie es ja auch nicht geschafft, eine RDF-Implementierung auf die Beine zu stellen; ich denke deshalb, es wird eher etwas aus der Praxis kommen, zum Beispiel im Rahmen von Beluga. Der Heidelberger Katalog setzt SOA noch nicht ganz um, geht allerdings schon in die richtige Richtung. Beispielweise wird parallel im Digitalisierten Zettelkatalog DigiKat gesucht und ggf. ein Hinweis auf mögliche Treffer eingeblendet. Wenn dafür ein offener Standard (zum Beispiel OpenSearch oder SRU) verwendet würde, könnten erstens andere Kataloge ebenso dynamisch zum DigiKat verweisen und zweitens in fünf Minuten andere Kataloge neben dem DigiKat hinzugefügt werden.

Ein weiteres Feature von HEIDI sind die Personeneinträge, von denen auf die deutschsprachige Wikipedia verwiesen wird – hier ein Beispiel und der entsprechende Datensatz im SWB. Die Verlinkung auf Wikipedia geschieht unter Anderem mit Hilfe der Personendaten und wurde von meinem Wikipedia-Kollegen „Kolossos“ erdacht und umgesetzt. Ãœber einen statischen Link wird eine Suche durch einen Webservice angestossen, der mit Hilfe der PND und des Namens einen passenden biografischen Wikipedia-Artikel sucht. Ich könnte den Webservice so erweitern, dass er die SeeAlso-API verwendet (siehe Ankündigung), so dass Links auf Wikipedia auch nur dann angeboten werden, wenn ein passender Artikel vorhanden ist. Für einen verlässlichen und nachhaltigen Dienst ist es dazu jedoch notwendig, dass der SWB seine Personenangaben und -Normdaten mit der PND zusammenbringt. Natürlich könnte auch nach Namen gesucht werden aber warum dann nicht gleich den Namen einmal in der PND suchen und dann die PND-Nummer im Titel-Datensatz abspeichern? Hilfreich wäre dazu ein Webservice, der bei Ãœbergabe eines Namens passende PND-Nummern liefert. Die Fälle, in denen eine automatische Zuordnung nicht möglich ist, können ja semiautomatisch gelöst werden, so wie es seit über zwei Jahren der Wikipedianer APPER mit den Personendaten vormacht. Hilfreich für die Umsetzung wäre es, wenn die Deutsche Nationalbibliothek URIs für ihre Normdaten vergibt und ihre Daten besser im Netz verfügbar macht, zum Beispiel in Form einer Download-Möglichkeit der gesamten PND.

P.S.: Hier ist testweise die PND-Suche in Wikipedia als SeeAlso-Service umgesetzt, zum Ausprobieren kann dieser Client verwendet werden, einfach bei „Identifier“ eine PND eingeben (z.B. „124448615“).

4 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Auf der interessanten VDB-Fortbildungsveranstaltung „Der OPAC der Zukunft“ am 9. Juli 2007 in Stuttgart hat Leonhard Maylein den OPAC vorgeführt – als Indexmaschine (ein weiterer unabhängiger Service) werkelt im Hintergrund Lucene. Außerdem empfehlenswert sind die Vorträge von Heidrun Wiesenmüller (HdM Stuttgart) über die Problematik herkömmlicher OPACs (PDF), von Peter Kostädt (USB Köln) über das Integrierte Rechercheportal und den Kölner Uni-Gesamtkatalog (PDF | siehe direkt den KUG), von Esther Steiner (Studierende an der HdM Stuttgart) über Web 2.0-Grundlagen für Bibliotheken (PDF), Markus Hennies (HdM Stuttgart) über Katalogsuche als Mashup (PDF), und Harald Reiterer (Konstanz) über MedioVis (PDF | siehe auch Projekthomepage). Abgesehen davon, dass die Vorträge nicht auf einem Repository liegen anscheinend eine sehr gelungene Veranstaltung, die positiv stimmt, was die Entwicklung in deutschen Bibliotheken angeht.

    Comment by jakob — 24. Dezember 2007 #

  2. Passend zur Ãœberschrift ein Artikel aus der Erstausgabe des Code4Lib Journals über die, wenn man es halt so nennen will, serviceorientierte Architektur des neuen Katalogs der North Carolina State University (der ja auch an anderen Stellen gerne wegen seiner „tollen Features“ wie Facetten-Browsing herausgestellt wird). Der Artikel liefert eher Einblick in die Gedanken, die zu dem „Gerüst“ hinter den Features an der (einen, bekannten) Oberfläche gefürt haben. Auf dieses Gerüst kommt es letztendlich an, nicht auf eine tolle Oberfläche. Die kann man hoffentlich mal mit jedem „Katalog“ im Hintergrund realisieren, wenn eben die Architektur darauf stimmt (man muss es ja nicht immer gleich SOA nennen, das lockt wieder nur Dogmatiker an, die jahrelang darüber streiten wollen, ob das denn nun echt-SOA oder pseudo-SOA oder sonstwas ist, ich will einfach nur Schnittstellen, an denen ich eigene Dienste anhängen kann). Der Artikel (der übrigens ohne die Begriffe serviceorientierte Architektur oder SOA oder so auskommt): http://journal.code4lib.org/articles/10

    Zum Thema „Delivery“/“Ausleihe“/“Verfügbarkeitsprüfung“: In den letzten Tagen vor Weihnachten ist mir da das Protokoll NCIP begegnet (jepp, sogar ein Standard, ich gestehe vorher noch nie etwas davon gehört zu haben). Und ein Vortrag von Janifer Gatenby zum Thema „Bridging the gap between discovery and delivery“, in dem sie auch Vorschläge für einen Standard für den „Delivery“-Prozess macht.

    Sollten wir uns im neuen Jahr vielleicht mal genauer anschauen. Denn Janifer ist ja gar nicht so weit von gewissen in Deutschland recht relevanten Softwareprodukten entfernt, vieles, was man von ihr liest und hört findet man nur leider nicht oder nur langsam in der Software…

    So und nun noch Frohes Restfest und so,
    Till

    Comment by till — 25. Dezember 2007 #

  3. […] Dezember habe ich über Serviceorientierte Architektur geschrieben und bin unter Anderem auf den Heidelberger UB-Katalog eingegangen. Dabei ging es darum, wie Daten […]

    Pingback by Schnittstelle für Verfügbarkeitsdaten von Bibliotheksbeständen « Jakoblog — Das Weblog von Jakob Voß — 21. Januar 2008 #

  4. […] to be specified by the ILS-DI task group”. Yes, there is definitely a need (in december I wrote about such an API in German). However the main point is not the API but to define what “availability” […]

    Pingback by Working group on digital library APIs and possible outcomes « Jakoblog — Das Weblog von Jakob Voß — 13. April 2008 #

Sorry, the comment form is closed at this time.