Vor mehr als vier Jahren haben wir im KUG damit begonnen einzelne Titel mit den Namen der sie referenzierenden Artikel aus der Wikipedia anzureichern. Für den Nutzer liegen die Vorteile auf der Hand. Er bekommt ausgehend von einem einzelnen Titel einen zielgenauen Einsprung in die thematisch passenden Artikel der Wikipedia. Darüber hinaus wird auch die Recherche mit den zugehörigen Artikelnamen angereichert. Somit wird die Menge an Suchbegriffen, unter denen ein Titel gefunden werden kann sinnvoll erweitert. Ein gutes Beispiel ist der Titel Vergleichende Primatologie von Thomas Geissmann, den man auch finden kann, wenn man eine der vielen Affenarten sucht, die in den bibliographischen Daten nicht genannt wurden und die nur durch die Wikipedia für die Recherche angereichert werden konnten.

Diese von der Wikipedia bereitgestellten Literaturlisten in den einzelnen Artikeln bilden zusätzlich aber auch – gerade wegen ihres relativ engen Themen-Fokus – eine recht gute Grundlage für die Vernetzung eben jener Titel in einem Katalog. Durch sie können neue thematische Verbindungen zwischen verschiedenen Titeln nachträglich angereichert werden und den Nutzer auf andere relevante Literatur verweisen.

Nach einer einfachen Literaturanalyse in der Wikipedia werden OpenBib und KUG mit diesem Netz an Literaturverweisen angereichert, das beim Aufruf eines einzelnen Titels in Echtzeit mit dem davon tatsächlich vorhandenen Bestand im aktuellen Katalog abgeglichen wird. Die Grundlage bildet das bereits für die Artikel- und Recherche-Anreicherung verwendete Programm wikipedia2enrich.pl, welches nur geringfügig erweitert werden musste, um die Mengen thematisch benachbarter Titel per ISBN in einer neuen Tabelle related_isbn der Anreicherungsdatenbank abzulegen.

Die Schritte zur Bestimmung der ISBN-Mengen sind:

1. Bestimme die Artikelnamen, in denen eine gegebene ISBN referenziert wird
2. Fasse alle weiteren in diesen Artikeln genannten ISBNs zusammen
3. Kopple diese gefundenen ISBNs zur gegebenen ISBN zur Anfragezeit mit dem lokalen Bestand

Während 1 und 2 durch wikipedia2enrich.pl durchgeführt werden, ist die Rückkopplung in den lokalen Bestand im Modul OpenBib::Record::Title angesiedelt.

Sicherlich lässt sich diese Analyse der Literaturnennungen in der Wikipedia weiter verfeinern, aber auch so sind die Ergebnisse für unsere Nutzer vielversprechend, wie z.B. folgende Beispieltitel zeigen:

• James Rumbaugh: Objektorientiertes Modellieren und Entwerfen
• Andreas Paul: Von Affen und Menschen
• Marion Meyer: Die Personifikation der Stadt Antiocheia

In der Zwischenzeit machten mobile OPAC’s jedoch eher dadurch von sich reden, dass sie quasi kaum genutzt werden. Im offiziellen mobilen Portal der Universität zu Köln brachte es die Buchrecherche gerade einmal auf knapp 5 Benutzer pro Tag.

Seit ich selbst mit einem einfachen Smartphone (Nokia 5230, Symbian) unterwegs bin, weiss ich jedoch – unabhängig von der immer wieder postulierten Sinnlosigkeit eines mobilen OPACs – die Vorzüge von Webseiten und Inhalten zu schätzen, die für mobile Endgeräte mit kleinerem Bildschirm ausgelegt sind. Um möglichst viele Nutzer zu erreichen, wurde mir – gerade mit meiner bald obsoleten Smartphone-Plattform Symbian – sehr schnell klar, dass dies mit vertretbarem Aufwand nur mit Web-Applikationen und keinesfalls mit nativen Apps gelingen kann.

Nachdem der Mensaspeiseplan – sozusagen “die Killer-WebApp des mobilen Uni-Portals” – aus eben jenem verschwunden war, stolperte ich letztes Wochenende über die mobile Version der Speisepläne auf den Webseiten des Kölner Studentenwerks. Diese war als Web-App mit dem mobilen Ableger des altbekannten JavaScript-Toolkits jQuery umgesetzt – jQuery Mobile.

Wie iWebKit unterstützt jQuery Mobile verschiedene Smartphone-Betriebssysteme und -Browser, wenn auch in einer Mehr-Klassen-Gesellschaft. Nach einer kurzen Web-Recherche zeigte es sich jedoch schnell, dass bereits andere mobile OPACs auf dieses Toolkit gesetzt haben, darunter vuFind und Evergreen.

Da OpenBib bereits jQuery nutzte, erschien jQuery Mobile als sinnvolle Wahl für einen mobilen OPAC. Zu dieser Wahl hat auch beigetragen, dass der HTML-Seitenaufbau von jQuery Mobile sehr übersichtlich war und die Online-Dokumentation einen guten Eindruck machte.

Für die eigentliche Umsetzung wurde dann mit OpenBib-Mitteln ein neues Mobil-Profil erstellt und eine kleine Untermenge aller vorhandenen Templates – derzeit insgesamt 16 – für ein Beispiel Mobil-Portal prototypisch angepasst. Die Wahl fiel dabei auf das Demo-Portal www.richter-bibliothek.de. Mit der Spezialisierung dieser wenigen Templates gelang – mit entsprechend geringem Aufwand – an nur einem Abend bereits der Aufbau eines einfachen mobilen Recherche-Portals. Durch Hinzunahme und Anpassung weiterer OpenBib-Templates könnte dieses sukzessive um alle Funktionen erweitert werden, die ein Standard-OpenBib-Portal mitbringt – insbesondere Nutzerkonten, Verlängerungen usw.

Die Mobil-Version des Demo-Portals Richter-Bibliothek befindet sich unter

http://m.richter-bibliothek.de/

Sicherlich kann in diesem mobilen Portal noch das eine oder andere verbessert werden, insgesamt zeigt es jedoch, dass mobile Katalog-Portale nicht zwangsläufig mit riesigem Implementationsaufwand einhergehen – wie auch ich es anfangs befürchtete.

Und bei so einem geringen Aufwand lässt es sich dann auch sehr leicht verschmerzen, dass die Nutzerschaft eventuell nicht direkt in die Abertausende geht…

• Das Rad muß nicht immer neu erfunden werden (“building on the shoulder of giants”)
• Die Anwendung wird wartbarer
• Nach der Beschäftigung mit verbreiteten Frameworks lassen sich auch zukünftige Probleme an anderer Stelle einfacher lösen.
• Wichtig ist für mich aber: So ein Framework sollte nicht zu abstrakt und die learning curve nicht zu steil sein, so dass man immer noch sehen kann, was dahinter denn eigentlich passiert. Gerade bei kontraproduktiver “Eigenintelligenz” von Frameworks wird einem dadurch einiges an Unbill erspart.

Neben der bereits erwähnten Neuausrichtung im Bereich Web-Standards (“Cool URI’s”, Semantic Web, REST) und -Frameworks (CGI::Application für die Web-Anwendung, DBIx::Class als ORM) kommt nun der nächste Schritt im Bereich (X)HTML/CSS.

Gerade beim Layout mit CSS macht es Sinn, sich nicht immer wieder mit den neuesten Problemen des IE (oder anderer Browser) auseinander setzen zu müssen, sondern die Browser-Unabhängigkeit des Layouts mit einem geeigneten Framework sicher zu stellen.

Für OpenBib fiel dabei die Wahl auf das mächtige und exzellent dokumentierte CSS-Framework YAML von Dirk Jesse, das schon vielfach erfolgreich eingesetzt wird – z.B. bei der DigiBib mit IPS.

Um dieses Framework im Rahmen der Version 2.4 erst einmal in einem überschaubaren Bereich auszutesten, wurde ‘Die Bibliothek Elise und Helene Richter‘ als Demonstrations-Portal komplett neu aufgesetzt. Denn dort wird nur eine kleine Teilmenge der insgesamt knapp 380 Basis-Templates von OpenBib verwendet, die durch die Vererbungseigenschaften von Templates  in verschiedenen Sichten (=Portalen) einfach für die Sicht “richter” spezialisiert wurde – ohne die anderen bereits existierenden Nicht-YAML-Sichten zu stören.

Die in diesem Demo-Portal recherchierbaren Katalog-Daten wurden von der USB Köln im letzten Jahr als Open Bibliographic Data freigegeben und es zeigt gerade in diesem Bereich, wie quasi jeder aus offenen bibliographischen Daten eine Rechercheanwendung mit eigenen oder gemeinfreien Texten und Bildern im Netz realisieren kann.

Neben der Umstellung auf YAML werden mit diesem Portal weitere Besonderheiten der Version 2.4 demonstriert. Ganz wesentlich ist die Fähigkeit, dass einzelne Portalsichten in einer OpenBib-Installation fortan auch unter eigenen Host- und Domainnamen  im Web erscheinen können. Das mag selbstverständlich klingen, ist es aber nicht.

Bisher muss man sich bei OpenBib für einen Servernamen pro Installation entscheiden und andere Host/Domainnamen wie z.B. portrait.ub.uni-koeln.de können lediglich über den Weg eines umgebenden Frames umgesetzt werden, das dann für den Nutzer in der Location-Zeile des Browsers unbemerkt doch wieder den Servernamen wie kug1.ub.uni-koeln.de usw. aufruft.

Ab Version 2.4 können Sichten durch interne Konfiguration in OpenBib selbst, wie durch entsprechendes URL-Rewriting komplett als unabhängige Portale im Web in Erscheinung treten. Dieser Umstand wird perfekt durch das Portal www.richter-bibliothek.de mit der Sicht “richter” demonstriert, das ebenso wie search.openbib.org in nur einer einzigen OpenBib-Installation bereitgestellt wird.

Konkret findet bei der Richter-Bibliothek eine URI-Verkürzung statt, bei der z.B. aus der generischen URI-Form

/portal/:sicht/home

der Sicht-Name via URL-Rewriting nach aussen in den Hostnamen gezogen wird und der Sicht-Name effektiv aus dem URI verschwindet. Aus dem Start-URL wird somit aus intern

/portal/richter/home

nach aussen

http://www.richter-bibliothek.de/portal/home

Die URI-Verkürzung muss natürlich in den Templates für alle aufrufenden URI-Pfade automatisch angepasst werden. So etwas wird einfach über die Web-Administration konfiguriert.

Ein Beispiel für die interne Konfiguration zeigt der nächste Screenshot:

Einher mit der eher technischen Umstellung auf das YAML-Framework gehen Experimente mit einfacher strukturierten Nutzerführung. Bewusst wurde daher ein simples 2-Spalten-Layout gewählt. Ziel ist eine visuelle Reduzierung und das lässt sich im Demo-Portal Richter-Bibliothek sehr gut austesten, um es dann auch in den großen umfassenden Sichten umzusetzen.

Wie die Version 2.4 ist auch das Demo-Portal “Richter-Bibliothek” noch alpha. Sukzessive wird sich die Fehlerquote – z.B. durch noch nicht angepasster Templates- aber sicherlich verbessern…

Vorgemacht hatte die Kopplung eines Ausleihkontos mit einem (eigenen) Kalender die Anwendung EDsync, die neben der Anzeige der Entleihungen u.a. auch Anzeige von Gebühren, Verlängerung per Knopfdruck sowie VoiceOver für sehbehinderte Menschen bietet. EDsync ist jedoch nur für MacOS und iPhone verfügbar.

Damit unsere Nutzer die Leihfristenden ihrer entliehenen Medien besser im Blick behalten können, haben wir für das Ausleihkonto unseres Katalogs zunächst eine weitere Ausgabemöglichkeit im iCalendar-Format integriert. Das war schnell gemacht, da lediglich ein weiterer Übergabeparameter für das neue Format und ein korrespondierender Abschnitt im Ausgabetemplate für die Entleihungen hinzugefügt werden musste.

Ausleihkonto als iCalendar und per QR-Code

Ein Nutzer kann damit per Knopfdruck einen Kalender seiner Entleihungen herunterladen und – dank der Verwendung des iCalendar-Standards – in ein beliebiges Kalender-Programm importieren. Um eine bestmögliche Kompatibilität sicherzustellen, wurde das von OpenBib generierte iCalendar-Format mit einem besonders kritischen Validator überprüft und konnte dort einen Kompatiblität von 100% erreichen. Wichtig ist u.a.:

• Standard-Zeichenkodierung ist UTF8
• Zeilenenden sind mit CRLF kodiert
• Zeilen dürfen nicht länger als 78 Octets sein, können aber über spezielle Zeichen in der nächsten Zeile weitergehen
• Doppelpunkte und Kommas müssen mit Backslash escaped werden
• PRODID ist zwingend

Bei der Erzeugung des Kalenders wurde aus Gründen der Unaufdringlichkeit bewusst auf das Setzen eines Erinnerungs-Alarms verzichtet.

Um in einem zweiten Schritt auch mobil einen möglichst schnellen und unkomplizierten Snapshot der Leihfristenden in den eigenen Smartphone-Kalender anbieten zu können, fiel unsere Wahl sofort auf den QR-Code. Kein Abtippen, kein Rumsurfen – einfach abknipsen und gut.

Auf die Problematik von QR-Codes und Kalenderdaten hatte kürzlich Christian Hauschke im Kontext weiterer Anwendungsmöglichkeiten von QR-Codes berichtet. Sie liegt darin, dass

• es keinen definierten Standard für die Kodierung von Kalenderdaten in QR-Codes gibt. Neben der Möglickeit einen normalen standardkonformen iCalendar zu verwenden, wird z.B. vorgeschlagen BEGIN/END:VCALENDAR wegzulassen
• es zwar QR-Code-Generatoren gibt, die iCalendar generieren, aber nicht jede Readersoftware kommt damit zurecht. Oft (i-nigma, kaywa Reader) wird der Kalendereintrag dann nur als einfacher Text angezeigt und kann nicht in den Smartphone-Kalender übernommen werden.
• QR-Codes für manche Ausleihkontos mit mehreren hundert Medien schlicht zu klein sein können (ja, das gibts…)

All das spricht dagegen, die Kalenderinformationen direkt in einen QR-Code zu packen. Die direkte Platzierung der Information wäre sonst eigentlich der bevorzugte Weg gewesen. Andererseits verarbeiten die Smartphones einen per Web-Browser aufgerufenen iCalendar mit Mime-Type text/calendar normalerweise problemlos. Als QR-Code muss dann nur der URL zum Kalender kodiert werden.

Da die Ausleihdaten sehr privat und dementsprechend sensibel zu handhaben sind, darf nur ein autorisierter Zugriff auf den Kalender ermöglicht werden. Hier gab es zwei Varianten. Entweder sitzungsbasiert (SessionID) oder zustandslos (HTTP). Um dem Nutzer eine weitere Authentifizierung mit Benutzername und Passwort zu ersparen, haben wir den Weg über die SessionID gewählt.

Jenseits dieses neuen Betriebssystem- und Smartphone-übergreifenden Angebots im KUG steht der zusätzlichen Integration in dedizierte iPhone, Android, Symbian, etc. Anwendungen ala EDsync eigentlich nur die Schnittstellenproblematik entgegen. Bei der Definition oder Einigung auf konkrete offene und frei verwendbare Schnittstellen ist eine noch intensivere mobile Kopplung mit dem Katalog sicherlich zukünftig mit wenig Aufwand möglich.

Das Handy kann so bequem als “Merkzettel” für recherchierte Katalog- und Bibliotheksinformationen genutzt werden.

Seit ich vor rund einem Jahr das erste Mal die Einbindung von QR-Codes im Heidelberger Katalog Heidi gesehen hatte, wanderte das Thema relativ schnell auf meine ToDo-Liste für OpenBib, blieb dort aber aus Zeitmangel bisher liegen. Erst durch die umfangreiche Zusammenstellung des QR-Code Einsatzes in diversen Bibliotheken, die Viola Voß in einer Mail an InetBib vor zwei Tagen verschickte, rückte das Thema wieder in meinen Fokus.

Für OpenBib wurde ich mit dem Perl-Modul GD::Barcode, in dem auch GD::Barcode::QRcode enthalten ist, relativ schnell fündig. Mit diesem Modul konnte dann umgehend ein neuer QR-Code-Dienst – in OpenBib-Sprache “Konnektor” genannt – umgesetzt werden. Die Essenz des Dienstes steckt in nur 4 Zeilen:


use GD::Barcode::QRcode;
my $code = GD::Barcode::QRcode->new($text,{ECC => 'M', Version => 12, ModuleSize => 5});
$r->content_type("image/png");
$r->print($code->plot->png);


Dieser Dienst ist USB- und Uni-intern insbesondere auch dafür gedacht, erst einmal mit QR-Codes experimentieren zu können und diese dann gegebenenfalls vermehrt auch produktiv einzusetzen. Dabei geht es ganz zentral darum, Akzeptanz für den Nutzen der QR-Codes zu schaffen, denn hier liegt sicherlich das größte Problem: Aus der Niche ‘technische Spielerei, die sowiso niemand braucht’ herauszukommen und als sinnvolles Werkzeugt aus dem bibliothekarischen Dienste-Werkzeugkasten akzeptiert zu werden.

Der Basis-URL des Dienstes lautet:

http://kug.ub.uni-koeln.de/portal/connector/qrcode

Mit dem Parameter ‘text‘ wird dann der Text angehängt, der in einen QR-Code umgewandelt werden soll. Dieser ist derzeit (mit dem verwendeten ECC-Level M und der QR-Code Version 12) auf 419 aphanumerische Zeichen begrenzt, um die Größe des QR-Code-Bildes in einem erträglichen Rahmen zu halten. Weitere Informationen über die Kapazität von QR-Codes abhängig von ECC-Level und Version stellt der ‘QR-Code Erfinder’ Denso Wave auf seiner Webseite zur Verfügung.

Der QR-Code-URL für den Text ’123′ ist somit z.B.

http://kug.ub.uni-koeln.de/portal/connector/qrcode?text=123

Der KUG bedient mit QR-Codes zwei typische Szenarien: Informationen über Exemplare und Bibliotheken

Exemplarinformationen

Der Nutzer recherchiert im KUG verschiedene Titel und möchte diese dann im Regal finden. Wesentliche Informationen, die er sich für das jeweilige Exemplar merken muss, sind ‘Titel’, ‘Standort’ (gegebenenfalls auch den Namen der Bibliothek) und ‘Signatur’.

Bei jedem relevanten Exemplar geht er mit der Maus im KUG über das QR-Code-Icon und fotographiert den dann erscheinenden QR-Code mit einem QR-Code-Reader-Programm auf seinem Handy (ohne aktiviertes JavaScript klickt er einfach auf das Icon). Mit der sukzessiv anwachsenden Bücher-Liste auf seinem Handy kann er dann zu den Regalen gehen und die jeweiligen Bücher heraussuchen.

Ein Beispiel ist z.B. folgender Titel aus dem Europäischen Dokumentationszentrum (EDZ) in der USB:

QR-Code mit relevanten Exemplar-Informationen

Permalink: http://kug.ub.uni-koeln.de/portal/connector/permalink/edz/4687797/1/kug/index.html

Wesentlich ist hier neben der Signatur insbesondere auch die Sachgruppen-Nummer als weitere Standortangabe, da der Nutzer über diese erst den relevanten Regalabschnitt finden muss, bevor er dort mit der Signatur weitersucht.

Bibliotheksinformationen

Ein Nutzer möchte eine (Instituts-)Bibliothek aufsuchen. Wesentliche Informationen, die er sich hier merken muss, sind ‘Institutsname’, ‘Adresse’ (gegebenfalls mit Gebäudeteilangaben) und ‘Öffnungszeiten’.

Auch diese Informationen kann er bequem mit seinem Handy über den QR-Code abfotographieren und verarbeiten.

Ein Beispiel ist z.B. die Instituts-Sicht des Instituts für Ethnologie im KUG:

Bibliotheksinformationen als QR-Code

Link: http://kug.ub.uni-koeln.de/portal/lastverteilung?view=inst431

Im ‘Steckbrief der Bibliothek’ findet er den QR-Code mit den relevanten Informationen.

Zusätzlich wird der QR-Code auch in der vollständigen Informationsseite zu einer jeden (Instituts-)Bibliothek im KUG angeboten. Dieser ist u.a. bei den Exemplaren über die besitzende Bibliothek oder im Steckbrief unter [Mehr] verlinkt.

Benötigte Software für das Handy

Um QR-Codes mit dem Handy zu verarbeiten benötigt man eine entsprechende Software für das Handy, wie z.B.

• den i-nigma Reader

• oder den Kaywa Reader.

Beide Programme sind gratis. Speziell der i-nigma Reader unterstützt eine Vielzahl von Handy-Modellen (iPhone, Android, Symbian, Java-fähige Handys)

Gegenüber dem einfachen Abfotographieren hat der QR-Code den wesentlichen Vorteil, dass nicht einfach nur ‘ein Bild’ abgespeichert wird, sondern der tatsächliche Text. Diesen Text kann man weiter verarbeiten, auflisten, abspeichern, weiterleiten oder – falls es ein URL ist – z.B. auch automatisch diesen über den Web-Browser im Smartphone aufrufen.

Wir sind froh das Thema QR-Codes ausgehend vom KUG nochmals aufgegriffen zu haben und überlegen uns gerade weitere sinnvolle Anwendungen innerhalb und außerhalb des KUG.

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:

http://search.openbib.org/

http://paperc.de/documents/export.csv

für eine weitere interne Verarbeitung in anderen Plattformen – wie z.B. dem KUG mit OpenBib – zur Verfügung.

In dieser CSV-Datei befindet sich die ISBN13 der E-Book- und  Print-Ausgabe (die Print-ISBN leider noch nicht überall), der Titel und der URL des Buches bei PaperC. Damit lässt sich PaperC nun noch einfacher für eine Anreicherung der lokalen Katalogdaten im KUG nutzen. Obwohl die Titel weiterhin in der PaperC-Webseite selbst nicht – weder mit der ISBN10, noch mit der ISBN13 der Print-Ausgabe – über das Suchfeld in einem URL der Form

http://paperc.de/search?query=0596002068&commit=Suchen

auffindbar sind, so kann nun zumindest über das PaperC JSON-API mit der ISBN13 die Existenz der Print-Ausgabe verifiziert werden:

http://paperc.de/9780596002060.json

Für einen Mashup rein über JavaScript reicht dies aus. Im Artikel PaperC im KUG habe ich einen anderen Weg skizziert, der ohne JavaScript auskommt, der aber von der Recherchierbarkeit des Titels in PaperC mit der ISBN aus den lokal erfassten bibliographischen Daten abhängt. Das ist weiterhin nicht möglich.

Bei der Entwicklung des KUG verfolgen wir seit jeher die Strategie, dass jede Funktion auch ohne aktiviertes JavaScript nutzbar sein soll. Die jeweilige Funktion im KUG ist dann zwar gegebenenfalls nicht ganz so bedienungsfreundlich eingebunden wie die JavaScript-Variante, prinzipiell aber immer verfügbar.

Vor diesem Hintergrund der weiterhin nicht mehr funktionierenden Einbindung via Recherche-URL der Print-ISBN, kommt der CSV-Export gerade Recht.

Jetzt können wir aus der Export-Datei die PaperC-URL der jeweiligen Titel  mit den verfügbaren ISBNs einfach in unsere Zentrale Anreicherungsdatenbank zu den dort bereit vorhandenen Inhalten einspielen. Dafür verwenden wir ein einfaches Skript paperc2enrich.pl, mit dem wir über einen Cron-Job die PaperC-Daten alle 14-Tage automatisch aktualisieren. Zusätzlich musste dann nur noch das entsprechende Ausgabe-Template angepasst werden. Wenn ein PaperC-URL in der Kategorie E4122 (in der steckt der PaperC-URL des Titels) vorhanden ist, dann wird das bereits bekannte “PaperC-Verfügbarkeits-Bild” ausgegeben.

Konkret verwenden wir nun diesen Abschnitt im Template

[% IF normset.${"E4122"} %]
<p>
<a href=”[% config.get('redirect_loc') %]/[% sessionID %]/512/[% normset.${"E4122"}.first.content %]” target=”_blank” title=”Online Lesen bei PaperC”><img src=”/images/openbib/paperc.png” alt=”Bei PaperC vorhanden” border=”0″ /></a><br/>
</p>
[% END %]

anstelle von

<p>
<a href=”[% config.get('redirect_loc') %]/[% sessionID %]/512/http://paperc.de/search?query=[% isbn %]&commit=Suchen” target=”_blank” title=”Online Lesen bei PaperC”><img src=”[% config.get('connector_availabilityimage_loc') %]?action=lookup;id=[% isbn %];target=paperc” alt=”Bei PaperC vorhanden?” border=”0″ /></a><br/>
</p>

Für die Bereitstellung der PaperC-Informationen aus unserer Anreicherungsdatenbank für andere lokale Dienste, wie unser USB-Portal, bieten wir diese zusätzlich mit dem SeeAlso-Abfrageprotokoll über unseren SeeAlso-Konnektor an. Für die ISBN10 des Beispiel-Titels lautet die Abfrage

http://kug.ub.uni-koeln.de/portal/connector/seealso/isbn2paperc?id=0-596-00206-8&format=seealso

Durch die automatische Anreicherung eines jeden Titels in den verschiedenen KUG-Katalogen, der eine Print- oder E-Book-ISBN aus dem PaperC Export enthält, haben wir wieder eine funktionierende Einbindung von PaperC für unsere Nutzer – und auch der Beispiel-Titel Programming Web-Services with Perl aus dem vorangegangenen Blog-Artikel zu PaperC zeigt die Verfügbarkeit dort wieder richtig an.

Vielen Dank an Lukas Rieder für die Bereitstellung der CSV-Exporte!

Welche Gründe das haben – und wie man mit wenig Aufwand die gefühlte Performance für den Endanwender verbessern kann, hat Steve Souders für die Platform Engineering Group von Yahoo bereits vor einigen Jahren bei den Top 10 Web-Sites in den USA untersucht und in seinem Buch “High Performance Web Sites” zusammengefasst. Inzwischen gibt es in Buchform  bereits den Nachfolger “Even faster Web Sites” mit noch mehr Optimierungs-Tips.

Sein Fazit: Schuld an der Zähigkeit vieler Seiten ist selten das Backend mit dem die Inhalte generiert werden, sondern das Frontend, also die Auslieferung und die Art, wie Seiten aufgebaut sind und im Browser gerendert werden. Nach seiner Erfahrung entfallen durchschnittlich nur 20 Prozent der Gesamtzeit auf das Backend, aber 80 Prozent auf das Frontend.

Optimierungen des Backends sind typischerweise mit viel Aufwand verbunden, erreichen dann aber doch meist nur Beschleunigungen im 1-stelligen Prozentbereich. Demgegenüber kann man mit vernachlässigbarem Einsatz die 80 Prozent in großen Teilen reduzieren. Selbstverständlich gilt das nur, wenn man nicht das langsamste Recherche-Backend aller Welten hat, wie es bei Recherchen in klassischen SQL-basierten Katalogen bei Begriffen wie “Deutschland” oder “Geschichte” auch heute manchmal immer noch der Fall ist – mal abgesehen, wie sinnlos so eine Recherche eigentlich ist…

Aufbauend auf dem angesprochenen Buch gibt es ein Firefox-Add-on von Yahoo! mit dem sinnigen Namen YSlow – “Why Slow?”, das in das beliebte Firebug-Add-on integriert ist.

Nach der Installation des YSlow Add-ons kann man es auf eine beliebige Webseite, sei sie aus einer statischen Web-Präsenz oder einem Bibliothekskatalog anwenden. Entsprechend der Optimierungsbereiche aus dem erstgenannten Buch wird der jeweiligen Webseite zunächst eine erreichte Bewertungs-Punktzahl und eine allgemeine Note von A (sehr gut) bis F (sehr schlecht) gegeben. Darauf folgen die “Einzelwertungen” in den jeweiligen Bereichen. Wie im Buch sind die Bereiche von “bringt viel” bis “bringt auch noch etwas” von oben nach unten geordnet – daraus gibt sich dann automatisch die Reihenfolge, mit der man potentielle Defizite angehen kann.

Sehr gelungen ist hier, dass neben den Bewertungen unter “Read more” direkt per Mausklick weitergehende Informationen auf den Webseiten von Yahoo!s Developer Network mit einer Kurzfassung der Tips aus dem Buch angeboten werden.

Nach Lektüre des Buches habe ich dann auch sofort YSlow installiert und auf den KUG und weitere Kataloge losgelassen. Das Ergebnis war dann jedoch etwas enttäuschend. Gerade mal ein D-E hatte der KUG erreicht. Angemäkelt wurde insbesondere folgendes

• Weniger HTTP-Request machen
• Ein Content Delivery Network verwenden
• Für viele statische Inhalte langlebige Expires-Header hinzufügen
• Auslieferung mit gzip komprimieren
• ETags konfigurieren

Bei vielen anderen Bibliothekskatalogen, die ich mir mit YSlow angeschaut habe, sind es oft die gleichen Optimierungsbereiche. Die Behebung der gravierendsten Mängel war danach sehr einfach, auch wenn wir uns z.B. nicht in ein CDN wie Akamai mit dem KUG einkaufen werden…

Zuerst haben wir CSS- und JavaScript Files reduziert und so gut es ging zusammenfasst. Die Verwendung von CSS-Sprites für die Icons steht noch aus, da hier auch noch der Bereich Barrierefreiheit mit bedacht werden muss.

Für den KUG verwenden wir ein Setup mit gestaffelten Web-Servern. Das eigentliche Applikations-Backend bildet ein Apache2. Vor diesen haben wir einen weiteren Web-Server postiert, der alle statischen Inhalte ausliefert, also Stylesheets, JavaScript, Bilder usw. Alle Anfragen an die KUG-Anwendung werden per ProxyPass an den Apache2 weitergereicht. Auf diese Weise muss sich der “dicke” Apache2 mit mod_perl

1. nicht mit den statischen Anfragen abplagen und kann
2. seine Inhalte schnell an den vorgeschalteten Webserver ausliefern. Damit wird er nicht von Anfragen über langsame Datenverbindungen blockiert.

Als vorgeschaltete Web-Server setzen wir hier teils noch den Apache 1.3, teils lighttpd ein. Dementsprechend müssen dort die weiteren Optimierungen erfolgen.

Expires

Da wären dann die Expires-Header für die statischen Inhalte. Diese sollten auf mehr als 30 Tage gesetzt werden.

Bei Apache 1.3 geht das mit mod_expire und den Direktiven

<IfModule mod_expires.c>
<LocationMatch “^/(js|styles|images)/”>
ExpiresActive on
ExpiresDefault “access plus 30 days”
</LocationMatch>
</IfModule>

Bei lighttpd mit:

server.modules   += ( “mod_expire” )

expire.url = ( “/images/” => “access plus 30 days”, “/styles/” => “access plus 30 days”, “/js/” => “access plus 40 days” )

Komprimierte Auslieferung

Ein weiterer Bereich ist die komprimierte Auslieferung der Daten mit gzip.

Bei Apache 1.3 geht das sehr einfach mit mod_gzip:

<IfModule mod_gzip.c>
mod_gzip_on                   Yes
mod_gzip_can_negotiate        Yes
mod_gzip_static_suffix        .gz
AddEncoding              gzip .gz
mod_gzip_update_static        No
mod_gzip_command_version      ‘/mod_gzip_status’
mod_gzip_temp_dir             /tmp
mod_gzip_keep_workfiles       No
mod_gzip_minimum_file_size    500
mod_gzip_maximum_file_size    500000
mod_gzip_maximum_inmem_size   60000
mod_gzip_min_http             1000
mod_gzip_handle_methods        GET POST
mod_gzip_item_exclude         reqheader  “User-agent: Mozilla/4.0[678]”
mod_gzip_item_include         file       \.html$
mod_gzip_item_include         file       \.js$
mod_gzip_item_include         file       \.css$
mod_gzip_item_include         file       \.pl$
mod_gzip_item_include         handler    ^cgi-script$
mod_gzip_item_include         mime       ^text/html$
mod_gzip_item_include         mime       ^text/plain$
mod_gzip_item_include         mime       ^text/css$
mod_gzip_item_include         mime       ^application/javascript$
mod_gzip_item_include         mime       ^application/x-javascript$
mod_gzip_item_include         uri       ^/styles/
mod_gzip_item_include         uri       ^/js/
mod_gzip_item_exclude         mime       ^image/
mod_gzip_dechunk              Yes
LogFormat                     “%h %l %u %t \”%V %r\” %<s %b mod_gzip: %{mod_gzip_result}n In:%{mod_gzip_input_size}n -< Out:%{mod_gzip_output_size}n = %{mod_gzip_compression_ratio}n pct.” common_with_mod_gzip_info2
CustomLog                     /var/log/apache/mod_gzip.log common_with_mod_gzip_info2
mod_gzip_add_header_count     Yes
mod_gzip_send_vary            On
</IfModule>

Entsprechendes geht bei lighttpd mit mod_compress und

compress.cache-dir          = “/var/cache/lighttpd/compress/”
compress.filetype           = (“text/plain”, “text/html”, “application/x-javascript”, “text/css”, “application/javascript”)

Diese Direktiven stehen so bereits in der Konfigurationsdatei lighttpd.conf und müssen dort nur aktiviert werden.

ETags

Weiter geht es mit der Konfiguration von ETags. Hier bietet es sich an, diese komplett zu deaktivieren

In Apache 1.3 geht das mit:

<LocationMatch “^/(js|styles|images)/”>
FileEtag None
</LocationMatch>

Entsprechend in lighttpd:

static-file.etags = “disable”

Mit diesen wenigen Maßnahmen konnten wir uns von D-E im KUG auf eine Bewertung von B steigern. Auf unserem Entwicklungssystem für die nächste KUG-Version konnten wir die HTTP-Request weiter minimieren und haben es sogar auf ein A geschafft.Und das alles durch minimale Konfigurationsänderungen, die nicht wirklich Arbeit gekostet haben.

Selbstverständlich gibt es auch Bereiche, wo man mehr oder weniger machtlos ist, weil man z.B. externe Cover einbindet und der Lieferant keine Expires setzt oder nicht komprimiert oder … Manchmal kann man aber auch selbst dann noch optimieren. So ist bei uns auf allen Rechercheseiten der BIX-Zählpixel eingebunden, der natürlich prompt angemäkelt wurde. Da dieser aber ohnehin nur für einen definierten Zeitraum von wenigen Wochen pro Jahr aktiv ausgewertet wird, haben wir dessen Integration in die KUG-Seiten einfach parametrisiert. So wird er jetzt nur noch im Auswertungszeitraum aktiviert und erscheint sonst auf unseren Seiten nicht mehr.

Insgesamt hat das YSlow Add-on bei der Optimierung des KUG als Beispiel für einen Bibliothekskatalog gute Dienste geleistet. Gerade durch die Adressierung konkreter Optimierungsbereiche und seine Evaluationmöglichkeiten deckt es den Frontendbereich sehr gut ab. Weitere Blog-Artikel zu YSlow finden sich hier und hier.

Hinweis: Seit dem 11.3.2010 werden in PaperC nicht mehr die ISBNs der Print-Ausgabe indexiert. Damit sind die Titel aus einem Bibliothekskatalog – wo eben diese vorhanden ist – nicht mehr auffindbar. Lukas Rieder von PaperC hat jedoch angekündigt, dass die Print-ISBNs zukünftig wieder erfasst werden sollen.

Der Online-Dienst PaperC (Pay-per-Copy) bietet seinen Nutzern die Möglichkeit kostenlos Fachbücher im Internet zu lesen und wurde mit dieser Idee “Startup des Jahres”. Will der Nutzer Seiten aus einem Fachbuch weiter verarbeiten, so zahlt er dafür 10 Cent pro Seite und kann fortan laut PaperC-Startseite

• Seiten herunterladen und ausdrucken
• Textstellen einfach kopieren und zitieren
• eigene Notizen anfügen und online verwalten

Für Rechercheplattformen wie dem KUG mit seinen Nutzern ist PaperC damit ein sehr nützlicher Dienst, stellt er doch eine interessante Alternative zu teuer erworbenen E-Books dar. Gerade in der letzten Woche schlug der Dienst in der Blogsphäre einige Wellen, als der Verlag O’Reilly 600 Bücher zu PaperC beisteuerte und die Einbindung von PaperC in Verbundkataloge thematisiert wurde. Sehr erfreulich ist die Bereitschaft von PaperC seine Metadaten zur Kataloganreicherung zu liefern. Ebenso wurde auf breiten Wunsch ein API fertig gestellt, dass allerdings bisher noch nicht öffentlich im Blog dokumentiert ist.

Um unseren Nutzern die Vorteile von PaperC schon jetzt anbieten zu können – und weil die Implementierung eine Sache von knapp 3 Minuten war – zeigt der KUG nun bei den Vollanzeigen derjenigen Titeln, die in PaperC vorhanden sind, deren Verfügbarkeit direkt an – wie im Beispiel-Titel “Programming web services with Perl“.

Der schon für die Einbindung von Google Books verwendete Mashup-Mechanismus im KUG ist sehr einfach und verzichtet bewusst auf die Verwendung von JavaScript. Stattdessen wird lediglich ein Bild mit einem URL verlinkt, der die Recherche bzw. den Einsprung in den jeweiligen Dienst (über die in der Titelaufnahme enthaltene ISBN) aufruft. Im Fall von PaperC ist das einfach

http://paperc.de/search?query=0596002068&commit=Suchen

Das “Verfügbarkeits-Bild” wird dynamisch über einen Konnektor erzeugt. Dieser überprüft – ebenfalls über eine einfache Recherche – die Verfügbarkeit. Ist der jeweilige Titel bei PaperC enthalten, so wird das PaperC-Bild ausgegeben und der Recherche-Link ist nutzbar, falls nicht wird stattdessen ein transparenter Pixel ausgegeben und der Link ist unsichtbar.

Wichtig ist bei dieser Art der Nutzung für den konnektorseitigen Aufruf – z.B. bei Google Books – die Weiterreichung der IP des aufrufenden Nutzers über den auch in Proxies gesetzten X-Forwarded-For-Header, um einem generellen Blocking der IP des Portal-Rechners zu entgehen. Da bei PaperC darüber hinaus ein Buch nicht über seine korrespondierende ISBN13 recherchierbar zu sein scheint, falls nur die ISBN10 ursprünglich vorhanden ist, konnten wir für den Konnektor nicht die sonst übliche Normierung auf ISBN13 nutzen, sondern mussten 1:1 die in der KUG Titelaufnahme enthaltene ISBN10 verwenden.

Stehen später dann irgendwann einmal die Metadaten oder das API wirklich zur Verfügung, kann für den KUG im Hintergrund problemlos – und für den Nutzer weitgehend unsichtbar – eine Umstellung darauf erfolgen.

Update 2.3.2010: Nach einer Anregung in einem Tweet geht aus dem PaperC-Verfügbarkeitsbild nun eindeutig hervor, dass die Lehrbücher kostenlos gelesen werden können.

Kernstück dieses Dienstes sind RSS-Feeds der entsprechenden Zeitschriften auf Verlagsseite, die die gewünschten Informationen zum Artikel wie Titel, URL zum Volltext sowie Abstract bereitstellen. In diesem Sinne werden im TicTocs-Dienst eben jene RSS-Feeds zu möglichst vielen Zeitschriften gesammelt. Derzeit umfasst der Dienst die aktuellsten Inhaltsverzeichnisse zu 12719 Zeitschriften von 448 Verlagen.

Interessant wird dieser Dienst für einen Katalog, wie z.B. den Kölner UniversitätsGesamtkatalog (KUG), dadurch, daß die Betreiber des TicTocs-Dienstes die von ihnen gesammelten RSS-Feeds für jedermann als Tabulator-separierte Tabelle unter http://www.tictocs.ac.uk/text.php zur weiteren Nutzung bereitstellen.

Sehr vorteilhaft ist dabei, daß zu den Feeds – wenn immer möglich – sowohl die ISSN der Printausgabe wie auch der elektronischen Ausgabe mitgeliefert werden. Edlef Stabenau hatte bereits im März im netbib-Weblog darüber berichtet, aber leider hatte ich das damals wohl überlesen und bin erst vor drei Wochen auf diesen Dienst gestoßen…

Die Integration in den KUG war dann schnell erledigt. Die Anreicherung der Titelaufnahmen geschieht – wie immer – katalogübergreifend in unserer zentralen Anreicherungsdatenbank, wobei der Identifizierungsschlüssel diesmal die ISSN ist. Die Einspielung der RSS-Feeds zu den ISSN’s in diese Datenbank übernimmt unser Skript tictocs2enrich.pl. Der Aufruf dieser Feeds und die Anzeige in den Titelaufnahmen kann auf verschiedene Weisen erfolgen. Am ehesten Web 2.0-artig ist sicherlich die Einbindung ausschließlich via JavaScript mit dem JQuery-Plugin jFeed (funktioniert wegen der JavaScript-Sandbox aber nur mit Proxy) oder mit Googles AJAX Feed API.

Stattdessen haben wir den noch fehlende RSS-Reader mit effektiv 2 Zeilen Perl-Code in einer eigenen Methode load_rss_feed für die Nutzung in unserem Templating-System realisiert: So können wir für die JavaScript-Nutzer alles via AJAX anbieten, für die anderen – mit aus Sicherheitsgründen deaktiviertem JavaScript – die Informationen aber dennoch einfach als weitere Seite verlinken. Die eigentliche Ausgabe übernimmt das Informations-Template info_62, das sowohl die Ausgabe via AJAX, wie auch als eigenständige Webseite übernimmt.

Hier nun zwei konkrete Beispiel im KUG.

Zunächst die Zeitschrift Remote Sensing

und danach die Zeitschrift Nature

Mit der Integration von TicTocs können wir unseren Nutzern fortan sinnvolle Zusatzinformationen zu den abgedeckten Zeitschriften geben. Gemessen an dem geringen Integrationsaufwand wünschen wir TicTocs den Einzug in möglichst viele weitere Kataloge.

Update 21.12.2009:

Damit andere Interessierte den TicTocs-Dienst noch einfacher als Mashup in ihre eigenen Kataloge einbinden können – unter anderem auch wir selbst mit unserem USB-Portal – bieten wir ihn selbst via SeeAlso-Protokoll an. Der Dienst hat den Namen issn2tictocs und kann sehr einfach mit einem Formatparameter seealso sowie dem Namen einer optionalen Callback-Funktion aufgerufen weden. Als Standard-Darstellung wir JSON zurückgeliefert.

Hier beispielsweise der Aufruf für die Zeitschrift Remote Sensing.