oder: Wie können Recherche-Portal(e), WebServices und die Publikation von Daten im Semantic Web zusammengefasst werden.
Was bisher geschah
Seit der Umstellung des Kölner UniversitätsGesamtkatalogs KUG auf die aktuelle OpenBib-Version 2.3 im April 2009 sind nun fast zwei Jahre vergangen. Diese Version zeichnete sich vor allem durch ein moderneres Design und eine verbesserte Nutzerführung aus.
In ihren Grundfunktionen war jedoch über die Jahre inzwischen eine spürbare Sättigung erreicht, so dass für den Endanwender seither nur noch kleinere Erweiterungen (Kataloganreicherung mit Schlagworten, TicTocs, PaperC) und Optimierungen (YSlow) sichtbar wurden. Umso mehr hat sich unterhalb der Oberfläche abgespielt, so dass auf Grundlage von OpenBib – jenseits des Einsatzes als Recherche-Portal KUG – viele neue Dienstleistungen innerhalb der USB Köln und der Universität realisiert werden konnten.
Vieles von dem, “wofür man OpenBib auch noch sonst so verwenden kann”, hatte ich im März 2010 beim 11. Bibliothekskongress in dem Vortrag “Der Kölner UniversitätsGesamtkatalog – Praktischer Einsatz des KUG mit OpenBib an der USB Köln” ausgeführt. Dort lag der Fokus gerade nicht ausschließlich bei dem klassischen Einsatz als Recherche-Portal, sondern speziell dem Vernetzungsaspekt (Mashups, Offene Schnittstellen, Daten) und den Dienstleistungen (automatisch generierte ZDB-Listen für Institutsbibliotheken, E-Book des Bibliotheksführers, Bestands- und Erwerbungskoordination , Approval plans usw.). Ausführliche Informationen hierzu finden sich auch in meinem Beitrag “Anreicherungen, Mashups und Vernetzungen von Titeln in einem heterogenen Katalogverbund am Beispiel des Kölner UniversitätsGesamtkatalogs KUG” (Open Access, CC-BY) zum Handbuch Bibliothek 2.0 von Julia und Patrick.
In der Vergangenheit gab es aber nicht nur Licht, sondern auch Schatten. Sehr problematisch war z.B. die Lastverteilung mit verschiedenen Servern (kug1.ub…, kug2.ub…, …) und der Einsatz der SessionID in den URLs. Beides hat dazu beigetragen, dass der Nutzer im KUG nicht einfach jeden URL bookmarken konnte, sondern eine eigene künstlich aufgepfropfte PermaLink-Funktion nutzen musste – die aber auch nur für einzelne Titel und Literaturlisten angeboten wurde.
Andere prominente Portale machen das ähnlich, indem sie dem Nutzer z.B. einen künstlichen URL für copy-and-paste anbieten. Das kann aber nicht der Weg sein. Eines der wenigen Portale, die es richtig machen ist VuFind. Dort kann jeder aufgerufene URL direkt im Browser gebookmarked werden. Hier und an anderen Stellen zeigt sich, dass VuFind eine ausgezeichnete Portal-Software ist – und auch noch Open Source.
Bewährt hat sich in OpenBib der Weg, über sogenannte Konnektoren, ausgewählte Daten oder Funktionen über (Standard-)Schnittstellen (SeeAlso, UnAPI, DigiBib, …) für die Integration in externe Dienste bereitzustellen. Aber auch hier wäre es wünschenswert, wenn alle Funktionen und Daten, mit denen der Endanwender im Recherche-Portal interagiert, auch direkt für eine externe Vernetzung bereitständen.
Der Weg zu einer neuen Architektur, oder: Das gesamte Portal ist der WebService
Seit der Freigabe der letzten OpenBib-Version hat sich das Augenmerk für eine Weiterentwicklung genau auf diese Problembereiche gerichtet und die bestehende Architektur wurde kritisch analysiert. Maßgeblich für eine mögliche Lösung war die Beschäftigung mit den Grundprinzipien des Semantic Web, die insbesondere durch die Tagung “Semantic Web in Bibliotheken” (SWIB09) von hbz und der ZBW im November 2009 entscheidend weiter befördert wurde.
Es ist eine sinnvolle Herangehensweise des Semantic Web, einzelne Resourcen durch feste HTTP “Cool” URI’s referenzierbar zu machen, dann aber die verschiedenen möglichen “Repräsentationen” oder Beschreibungen in diversen Formaten davon zu trennen und z.B. über 303er-Content-Weichen automatisch dahin weiterzuleiten. Diese Orientierung an Standard-HTTP-Mechanismen mit “Cool URI’s” findet auch in anderen Bereichen statt, z.B in RESTful WebServices. Session-IDs sind in solchen URIs dann eher hinderlich… Weitere Vorteile einer klaren Strukturierung der URI’s im genannten Sinn sind u.a.
- für eine Lastverteilung kann auf etablierte Standard-Software wie z.B. HAproxy zurückgegriffen werden
- mit einfachem URL-Rewriting und ProxyPass können Teile der Anwendung bei Bedarf durch andere Software-Lösungen ersetzt werden.
Für die Weiterentwicklung von OpenBib mit dem Ziel einer maximalen Vernetzbarkeit von Diensten und Daten bedeutete dies somit: Man nehme das bestehende Portal, dazu eine Prise
- Semantic Web (HTTP-URI’s zum Referenzieren von Resourcen, Content-Weichen, Trennung der HTTP-URI’s von den verschiedenen Daten-Repräsentationen wie HTML,JSON,RDF,RSS) und
- RESTful WebServices mit definierten “Cool URI’s” und CRUD (Create, Read, Update, Delete) über Standard-HTTP Methoden (POST, GET, PUT, DELETE),
- vereinheitliche und entschlacke mit geeigneten übersichtlichen Frameworks (CGI::Application, DBIx::Class) den Programm-Code für eine einfachere Anpassbarkeit, und
- setzte einen flexiblen Dispatcher für die URI’s ein (CGI::Application::Dispatch), damit sie “cooler” werden,
dann kräftig schütteln und heraus kommt: OpenBib Version 2.4alpha.
Durch diese Kombination wird erreicht, dass das gesamte Recherche-Portal selbst zu einem WebService wird und sich mit allen seinen Funktionen und Informationen in beliebige andere Dienste integrieren lässt. Zusätzlich besteht weiterhin der bereits etablierte Mechanismus, beliebige Informationen über (neue) Konnektoren mit definierten Standardschnittstellen (s.o.) bereitzustellen.
Das OpenBib-Portal ist somit gleichzeitig ein herkömmliches Recherche-Portal, das Endanwender über Ihre Web-Browser nutzen, wie auch eine grundlegende Infrastruktur, die Programme als WebService und Web-Crawler als Linked Open Data ansprechen können.
Wie immer ist es auch hier nicht zielführend in jedem Bereich evangelistisch der “reinen Lehre” zu folgen, vielmehr muß bei den sich zum Teil ergebenden Widersprüchen ein pragmatischer Mittelweg gefunden werden. Dies betrifft z.B. Cookie based authentication (nicht stateless, aber gut für Endanwender, die sich abmelden können) vs. HTTP Basic Authentication (stateless, aber schlecht für Endanwender, die zum Abmelden immer den Browser schließen müssen) oder den Einsatz von Cookies überhaupt, die im Umfeld von RESTful WebServices eher verpönt sind.
Folgende Repräsentationen von Information bietet das Portal derzeit an verschiedenen Stellen an. Eine Erweiterung um zusätzliche Daten-Repräsentationen ist mit wenig Aufwand möglich.
- HTML
- Der Endanwender, der im Portal recherchieren möchte, erhält eine bekannte Ausgabe im HTML-Format. Die entsprechenden URI’s enden auf .html.
[Beispiel: Wortwolke] - JSON
- Für eine bestmögliche Integration in externe Anwendungen werden standardmäßig alle verfügbaren Informationen im JSON-Format bereitgestellt. Damit lässt sich insbesondere auch jede Information direkt über AJAX (via JSON) integrieren. Die entsprechenden URI’s enden auf .json.
[Beispiel: Literaturliste] - RDF
- Als lingua franca des Sematic Web können die Informationen – wenn geeignete Ontologien zu ihrer Beschreibung existieren – im RDF-XML-Format bereitgestellt werden. Die entsprechenden URI’s enden auf .rdf
[Beispiel: Titel-Resource] - RSS
- Verschiedene Informationen lassen sich direkt als RSS-Feed abonnieren, wie z.B. die Literaturlisten zu einem Themengebiet. Die entsprechenden URI’s enden auf .rss
[Beispiel: Literaturlisten in einem Themengebiet] - HTML Include
- Zur noch einfacheren Integration kann der effektive Nutzinhalt im HTML-Format ohne das ihn umgebende Layout abgerufen und in externe Webseiten oder -anwendungen eingebettet werden. Die entsprechenden URI’s enden auf .include
[Beispiel: Letzte 5 Literaturlisten in einem Themengebiet]
Zusätzlich zum Aufruf des eine Resource referenzierenden HTTP-URI und anschließender Weiterleitung über eine 303-Redirect-Weiche kann jede Repräsentation der Resource auch direkt über das Anhängen der jeweiligen Endung aufgerufen werden. Die für einen URI verfügbaren Repräsentationen werden dabei in der HTML-Repräsentation als Links über Icons (RDF, JSON) dargestellt [Beispiel: Titel].
Beispiel
Der Titel Perl cookbook in der Datenbank ‘openbib’ und der dortigen internen (aber persistenten) ID-Nr 462 bekommt so einen fest definierten HTTP-URI
http://search.openbib.org/portal/openbib/title/openbib/462
Ein Browser akzeptiert ‘text/html’ und wird bei der Referenzierung des HTTP-URI auf die zugehörige HTML-Repräsentation mit dem URL
http://search.openbib.org/portal/openbib/title/openbib/462.html
weitergeleitet.
Eine Web-Anwendung möchte die Daten verarbeiten und hätte sie gerne im praktischen JSON-Format, akzeptiert also ‘application/json’ und wird an den URL
http://search.openbib.org/portal/openbib/title/openbib/462.json
weitergeleitet.
Ein WebCrawler (Google, etc.) sieht in der HTML-Version die Information
<link rel="alternate" type="application/rdf+xml" title="RDF Representation" href="http://search.openbib.org/portal/openbib/title/openbib/462.rdf"/>
oder hat den HTTP-URI bereits woanders geharvested und kann nun die Informationen im RDF/XML-Format und beschrieben durch “geeignete Ontologien” strukturiert unter
http://search.openbib.org/portal/openbib/title/openbib/462.rdf
ansprechen.
Problematisch und mit durchweg viel Aufwand verbunden ist die Modellierung aller vorhandenen Dienste und Informationen im Portal durch “geeignete Ontologien”. Aus pragmatischen Gründen wird daher für eine möglichst einfache Integration in externe Dienste als Repräsentation das verbreitete JSON-Format bevorzugt.
Realisiert werden die verschiedenen Daten-Repräsentationen durch den Einsatz einer Weiche in den bereits vorhandenen Basis-Templates [Beispiel: Titel-Resource], die nun nicht mehr für eine Ausgabe der Informationen im HTML-Format, sondern je nach gewünschter Repräsentation auf das zuständige Template im gewünschten Ausgabeformat weiterreichen. Vorgeschaltet ist eine 303er-Content-Weiche für den grundlegenden HTTP-URI (ohne Endung).
Die neue URL-Struktur bildet nun auch direkt die Portal-Sicht ab, über deren Name verschiedene Portale auf OpenBib-Basis für den Endanwender angesprochen werden können. Ein URL beginnt immer mit
/portal/[Name der Portalsicht]/[Rest-URL]
und bietet sich somit für URL-Rewriting/Proxying an.
Bis zur offiziellen Freigabe dieser neuen OpenBib-Version wird es sicherlich noch etwas dauern, aber den aktuellen Entwicklungsstand kann man bereits jetzt in einem neuen Demo-Portal mit einem kleinen Datenbestand besichtigen:
