Das Herunterladen von Seiten, Kapiteln oder des ganzen Buches ist nicht kostenfrei, bei Gesamtdownloads mancher Bücher sogar recht teuer. Das Buch Mastering Perl kostet z.B. bei PaperC 38 EUR verglichen mit 31.99 US$ direkt bei oreilly.com. Demgegenüber sind Kauf und Download beliebiger einzelner Seiten zu “Copy-Shop-Preisen” a 10 Cent bei anderen Anbietern in der Regel erst gar nicht möglich.

Bisher erscheinen Verweise zu PaperC lediglich für bereits im KUG nachgewiesene Fachbücher. Ist das Buch nicht im Bestand oder noch nicht elektronisch für den KUG erfasst, so laufen unsere Nutzer mit ihren Recherchen ins Leere.

Aus diesem Grund bieten wir jetzt den Gesamtbestand der mehr als 14.000 Fachbücher von PaperC als eigenen Katalog sowohl im KUG als auch – per Schnittstelle zum KUG – in der Standard-Recherche des USB-Portals an.

Ermöglicht wird dies durch eine gegenüber 2010 deutlich erweiterte Export-Datei von PaperC. Neben der Hinzunahme wesentlicher bibliographischer Informationen wird nun auch ein Export im XML-Format (derzeit 14.5 MB) angeboten. Dieser lässt sich relativ einfach in das Metadatenformat des KUG mit einem Konvertierunsprogramm für generische XML-Daten sowie einer zugehörigen Parametrisierung für die PaperC XML-Daten umwandeln und dann einspielen.

Insgesamt bieten wir mit diesem neuen Katalog in beiden Recherche-Portalen – neben den bereits vorhandenen Katalogen unserer lizensierten “E-Books” – für unsere Nutzer einen bequemen Zugriff auf die von ihnen benötigte Literatur. Solange dieser Mehrwert durch das Angebot von PaperC in der derzeitigen Form für unsere Nutzer besteht ist die Bereitstellung des Katalogs eine sinnvolle Erweiterung unseres Rechercheangebots.

Dazu gehört insbesondere das CVS-Reposistory, in dem alle Korrekturen und Erweiterungen von OpenBib nachgehalten wurden. Innerhalb der USB Köln dient dieses Repository gleichzeitig als Softwareverteilungswerkzeug zwischen den verschiedenen KUG-Produktionssystemen, auf denen OpenBib jeweils direkt in einem ausgecheckten Branch läuft.

Änderungen konnten so sehr einfach auf unserem Testsystem auf Herz und Nieren geprüft, dort danach eingecheckt und dann direkt auf allen Produktionssystemen ausgecheckt werden.

Leider erreichte mich – wie knapp 47.000 andere Nutzer  – am 30.9.2011 eine Mail von BerliOS, in der die Einstellung dieser Open Source Plattform bekannt gegeben wurde:

Sehr geehrte BerliOS Entwickler und Anwender,

BerliOS wurde vor 10 Jahren als eines der ersten Repositories in
Europa gegründet.  Es wurde von Fraunhofer FOKUS entwickelt und
gepflegt. Als ein europäisches, nicht proprietäres Projekt verfolgt
BerliOS das Ziel, die verschiedenen Open-Source-Akteure zu
unterstützen und eine neutrale Vermittlerfunktion zu bieten. 2011
wurden 4710 Projekte auf BerliOS gehosted, mit 50.000 registrierten
Nutzern und über 2,6 Millionen Dateien Downloads jeden Monat. Wir sind
stolz, dass wir mit BerliOS die Idee eines OSS-Repository nach Europa
gebracht haben. Mittlerweile hat sich das Konzept durchgesetzt und es
gibt zahlreiche gute Alternativen.

Leider hat ein Forschungsinstitut wie Fraunhofer FOKUS nur wenig
Möglichkeiten, langfristig ein Repository wie BerliOS zu
betreiben. Ein solches Projekt funktioniert nur, wenn es gelingt, eine
Anschlussfinanzierung zu finden, bzw. Sponsoren oder Partner zu
gewinnen, die das Repository übernehmen. Das ist im OSS-Bereich ein
schwieriges Unterfangen. In einer kürzlich durchgeführten Umfrage
haben wir zwar Unterstützung an Geldmitteln und Arbeitsleistung
signalisiert bekommen, für die wir uns bedanken. Leider reicht das
Ergebnis aber nicht aus, um das Projekt auf eine nachhaltige
finanzielle Basis zu stellen. Auch die Suche nach Sponsoren oder
Partnern war leider erfolglos.

Open Source wird bei Fraunhofer FOKUS als Paradigma für
zukunftsweisenden intelligenten IT-Einsatz verstanden. Es schmerzt uns
deshalb um so mehr, dass wir gezwungen sind, den Betrieb von BerliOS
zum 31.12.2011 einzustellen.
[...]
Wir bedanken uns bei allen, die über die Jahre BerliOS genutzt haben.

Fraunhofer FOKUS
www.fokus.fraunhofer.de

Auch ich möchte mich an dieser Stelle bei Fraunhofer FOKUS ganz herzlich für die Bereitstellung der für OpenBib so wichtigen Entwickler-/ und Projekt-Infrastruktur bedanken.

Es schmerzt, daß eine so nützliche – sowie speziell in Deutschland einmalige – Infrastruktur für Open Source Projekte nun Geschichte ist, und das bei – wie in Heise News genannt – aus meiner Sicht vergleichsweise überschaubaren Kosten von knapp 150.000 EUR pro Jahr für den Betrieb dieser Plattform.

Also heißt es für das OpenBib-Projekt nun: Sachen zusammenpacken, eine neue Plattform suchen und umziehen.

Das größte Problem ist dabei, eine geeignete neue Plattform zu finden. Hierzu wurde in der FOKUS-Mail dankenswerterweise direkt auf eine Vergleichs-Matrix entsprechender Systeme in Wikipedia verlinkt.

Wie erwartet gehörte BerlioOS (sogar weltweit) zu den Systemen mit dem umfangreichsten Dienste-Spektrum. Eine Alternative zu finden mit folgenden Kern-Anforderungen war daher nicht einfach:

• Unterstützung von CVS und die Möglichkeit später auf Subversion zu wechseln. Git/Bazaar/Mercurial lohnt sich aus meiner Sicht für dieses Projekt erst einmal nicht.
• Eine entsprechende Größe (Umfang Projekte/Nutzer, Bindung an etablierte Projekte) der Plattform, die eventuell auf Nachhaltigkeit und eine potentiell längere Verweilzeit als bei BerliOS schließen lässt…
• kostenlos

Die Mutter aller Hosting-Systeme – sourceforge.net – fiel sofort weg, da dort – ein Jahr nach der Einrichtung von OpenBib auf BerliOS – ein anderes Projekt gleichen Namens registriert wurde und der Projektname damit schlichtweg schon vergeben war.

Interessant waren ebenso: Alioth von Debian, GNU Savannah von der Free Software Foundation und Knowledge Forge von der Open Knowledge Foundation. Ohne die Bedingung der CVS Unterstützung wäre zusätzlich auch noch Google Code geeignet.

Nach und nach lichtete sich die Auswahl.

Savannah verlangt – ganz FSF – für die Begutachtung des jeweiligen Projektes die Lizenzdateien aller verwendeten Komponenten und Abhängigkeiten mitzuschicken. Die Arbeit, das alles zusammenzutragen, war einfach zu zeitraubend. Dafür greift OpenBib auf zu viele Open Source Komponenten zurück.

Knowledge Forge ist begrenzt auf Projekte im Umfeld von Open Knowledge und es wäre zu argumentieren, wie eng dies definiert ist bzw. wie OpenBib da hereinpasst. Darüber hinaus ist KForge eher klein in Bezug auf die Anzahl der Nutzer und Projekte.

Übrig blieb schließlich Alioth des Debian Projektes, bei dem ich am 1.10.2011 dann auch eine “Bewerbung” für die Aufnahme des OpenBib-Projektes eingereicht habe. So eine Bewerbung war auch bei BerliOS für OpenBib notwendig und das OK für das Projekt kam damals direkt am nächsten Tag.

Projekte auf Alioth sollen laut FAQ einen Bezug zum Debian-System haben. Da OpenBib einen engen Bezug zum Debian-System hat – es basiert auf einem laufenden Debian System, es werden Debian Pakete für fehlende Module sowie für die für OpenBib notwendige Infrastruktur in einem eigenen Debian-Repository unter http://packages.openbib.org/debian/ bereitgestellt – schien eine Bewerbung dort naheliegend.

Bei Alioth habe ich nun insgesamt 10 Tage auf die Begutachtung gewartet – bisher ohne Ergebnis. Um nicht wie bei SourceForge.net mit dem Projektnamen OpenBib und der Policy “first come, first served” über ein anderes Projekt gleichen Namens zu stolpern, wurde schließlich kurzerhand das CVS-Repository nach Subversion migriert und das Projekt bei Google Code registriert.

Eigentlich war diese Migration nach Subversion für einen späteren Zeitpunkt geplant, aber vor dem Hintergrund, dass vor allem schnell ein neues Code-Repository benötigt wurde, damit die Entwicklung weitergehen kann, musste auf die ursprüngliche Anforderung “CVS” verzichtet werden.

Die notwendige Umwandlung des gesamten CVS-Repositories wurde nach der von Carlo Wood vorgeschlagenen “Vorbehandlung” mit cvs2svn durchgeführt. Das so entstandene SVN-Dump-File wurde dann mit svnadmin load in ein lokales Repository eingeladen.

Die Einrichtung des Projektes bei Google Code geschieht instantan. Nach Anmeldung mit meinem Google-Account bei Googles Projekt Hosting Seite musste nur ein Formular mit Namen und Kurzbeschreibung eingegeben werden, abschicken, fertig. Ab sofort stehen dem Projekt knapp 4 GB an Speicherplatz zur Verfügung. Eine nachträgliche Erweiterungsmöglichkeit schließt Google ausdrücklich nicht aus.

Das lokale OpenBib-SVN-Repository musste nun nur noch nach Reset des Google-Archivs auf Revision 0 mit svnsync dorthin übertragen werden. Bei OpenBib mit seinen knapp 5500 Revisionen dauerte das knapp 24 Stunden. Grund ist sicherlich die geringe DSL-Übertragungsleistung zuhause sowie ein potentieller Zwangs-Disconnect meines lokalen ISP.

Wie stabil Google Code im laufenden Betrieb ist, wird sich zeigen. Der Einstieg war jedenfalls denkbar einfach. Und die neue Projektseite von OpenBib bei Google Code macht auch einen ganz guten Eindruck.

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…

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.

Die Universitäts- und Stadtbibliothek Köln (USB Köln) hat heute in Kooperation mit dem Hochschulbibliothekszentrum des Landes Nordrhein-Westfalen (hbz) ihre bibliographischen Daten für die Allgemeinheit geöffnet. Jahrzehntelang wurde die Erfassung dieser Daten öffentlich finanziert, nun stehen sie der Öffentlichkeit in ihrer Gesamtheit uneingeschränkt zur Verfügung.

Zusammen mit der USB Köln haben sich weitere Bibliotheken zu einer Freigabe ihrer Daten entschlossen und mit dem hbz eine gemeinsame Mitteilung verfasst.

Die zentrale Adresse mit Informationen über die von der USB Köln freigegebenen bibliographischen Daten ist:

http://opendata.ub.uni-koeln.de/

Zusätzlich wird auch auf Verbundebene im hbz eine Sammelstelle für alle freigegebenen bibliographichen Daten eingerichtet.

Durch die Freigabe der Daten wird es jedem möglich, die Daten herunterzuladen, zu modifizieren und für beliebige Zwecke zu nutzen.

Die bibliographischen Daten des Katalogs der USB Köln umfassen etwa 3.1 Millionen Titelaufnahmen, 1.5 Millionen Personenaufnahmen, 156 Tausend Körperschaftsaufnahmen, 40 Tausend Notationen sowie 243 Tausend Schlagworte (Stand: 12.3.2010).

Bereitgestellt werden die Daten in einem auf dem MAB2-Kategorienschema basierenden Metadaten-Format, das nächtlich im Rahmen des KUG-Projektes automatisch aus unserem Bibliothekssystem generiert wird. Im Rahmen dieses Projektes werden aus dem USB-Bestand auch Teilkataloge gebildet, z.B. des wirtschaftswissenschaftlichen Bestandes, der Lehrbuchsammlung usw. Auch diese automatisch generierten Daten werden an dieser Stelle getrennt bereit gestellt.

Das Metadaten-Format ist in diesem Wiki-Artikel genau beschrieben und lässt sich sehr einfach weiter verarbeiten.

Alle Datenbestände werden unter dem URL http://opendata.ub.uni-koeln.de/dumps/ bereit gestellt.

Jenseits der bibliographischen Daten im Katalog der USB Köln werden an der USB im Rahmen von Projekten weitere Bestände in anderen Spezial-Katalogen erfasst. Die Daten dieser Spezial-Kataloge werden ebenso freigegeben.

CC zero als Lizenz/Waiver der Wahl

Sämtliche Daten, die zum Download bereitstehen, sind unter der Creative Commons Lizenz CC0 veröffentlicht. Sie sind somit gemeinfrei, d.h. die Daten gehören allen und dürfen zu beliebigen Zwecken und ohne Auflagen genutzt werden. Jeder Person und Institution wird ein zeitlich und inhaltlich uneingeschränktes Nutzungsrecht an den Werken eingeräumt. Aus unserer Sicht ist die wirklich vollständige Freigabe als gemeinfreie Daten wesentliche Voraussetzung für ein semantisches Web mit Linked Data. Dies hatte bereits Patrick Danowski auf der SWIB09 in seinem Vortrag “Free Data – the road to linked data” (pdf,wmv) sehr gut verdeutlicht.

Es freut mich ganz besonders, daß das hbz ein so innovatives Feld wie das Semantic Web und die Freigabe bibliographischer Daten besetzt hat, aktiv die Entwicklung voran treibt und hier als Katalysator und Kooperationspartner für unsere Aktivitäten an der USB und den anderen beteiligten Bibliotheken gewirkt hat.

Gerade die Einbeziehung von uns und den anderen “Willigen” in ihre interne Arbeitsgruppe war sehr fruchtbar und ich freue mich schon auf die weitere Zusammenarbeit, wenn wir im nächsten Schritt die Beschreibung unserer Daten durch Web-Standards wie OWL angehen.

Ich denke 2010 wird ein sehr spannendes Jahr!

Update 12.4.2010: Die Zentralbibliothek der Sportwissenschaften der Deutschen Sporthochschule Köln schließt sich der Open-Access-Bewegung für bibliographische Daten an. Weitere Informationen unter http://www.vifasport.de/OpenDATA.html und http://opendata.zbsport.de/.

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.

Hier sind Recherche-Portale mit eigener Datenhaltung – wie z.B. BASE, beluga, Heidi oder der KUG – ganz klar im Vorteil, da erst dort datenbestandsübergreifend einheitliche Analysen sowie Anreicherungen vorgenommen werden und diese auch wieder in den Datenbestand zurückfließen können. Die erweiterten oder angepassten Daten stehen dann für die Recherche und die Anzeige also wieder zur Verfügung. Eine standardisierte Zugriffsschnittstelle auf entfernte Daten kann so etwas nicht leisten.

Vor einiger Zeit erhielt ich die Kopie einer Arbeit über den KUG im Rahmen des MALIS-Studiengangs an der FH Köln mit dem Titel “Der Kölner UniversitätsGesamtkatalog (KUG) – Analyse der praktischen Inhaltserschließung“. In dieser Arbeit wurden sehr viele der Probleme angesprochen, mit denen wir uns wegen eben jener ausgesprochenen Heterogenität der Ausgangsdaten für den KUG herumschlagen müssen und darüber hinaus sehr viel Feedback geliefert, worüber ich ausgesprochen dankbar bin.

Problematisiert wurde insbesondere die bereits angesprochene unterschiedliche sachliche Erschliessung mit Schlagworten bei gleichen Titeln in unterschiedlichen Katalogen. Entsprechend der Verschlagwortungsvorlieben der jeweiligen InstitutsbibliothekarInnen (die nicht nach RSWK verschlagworten – was allerdings nicht notwendigerweise ein Nachteil ist) werden im besten Fall verschiedene, im schlimmsten Fall gar keine Schlagworte vergeben. Einmal abgesehen von der uneinheitlichen Erscheinungsform des Titels in der Vollanzeige für den Recherchierenden – was notfalls noch zu verschmerzen wäre – kann dieser den Titel in einem Katalog eventuell über die Suche nach dem entsprechenden Schlagwort finden, im anderen aber gerade nicht. Das ist definitv ein Problem.

Als finaler Denkanstoß war dieser Artikel Grund genug sich im Rahmen des KUG etwas eingehender mit diesem konkreten Problem im Bereich Verschlagwortung zu beschäftigen und nach einfach zu realisierenden Lösungsansätzen zu suchen. Sehr schnell hat sich herauskristallisiert, dass sich dieses Problem sehr gut mit dem bereits bestehenden Toolset des KUG angehen lässt. Wie schon bei anderen Maßnahmen zur katalogübergreifenden Homogenisierung von Daten im KUG greifen wir auch hier auf das Konzept der Zentralen Kataloganreicherung zurück.

Dazu werden in einem ersten Schritt beim nächtlichen Update eines jeden Katalogs im KUG die dort vergebenen Schlagworte mit der zugehörigen ISBN als Zugriffsschlüssel (unter einer neuen Kategorienummer) in unserer zentralen Anreicherungsdatenbank abgelegt. Das geschieht durch ein sehr einfaches Anreicherungsprogramm swt2enrich.pl. Damit wurde bereits folgendes erreicht:

1. Jeder Titelaufnahme mit der jeweiligen ISBN stehen alle korrespondierenden “angereicherten” Schlagworte jenseits der (etwaig vorhandenen) lokalen Verschlagwortung zur Verfügung.
2. Darüber hinaus wird durch die Anreicherungdatenbank ein Verknüpfungsnetz von Titeln – identifiziert durch alle ISBNs zum jeweiligen Schlagwort – quasi unsichtbar über den aktuellen (Teil-)Katalog gelegt. Auf diese Weise lassen sich zu jedem so angereicherten Schlagwort auch weitere thematisch gleich eingeordnete Titel im aktuellen Katalog finden und verknüpfen – auf Grundlage der Verschlagwortung des Titels in einem anderen Katalog.

Im KUG werden diese “angereicherten Schlagworte” mit entsprechender Verknüpfung in der Einzeltrefferanzeige im Block “Entdecken Sie weitere Treffer über:” als “Verschlagwortung aus anderen Katalogen” angezeigt – für den Recherchierenden bewusst getrennt von den sonstigen bibliographischen Daten.

In einem zweiten Schritt werden nun nur noch durch entsprechende Parametrisierung die “angereicherten Schlagworte” mit in den Suchindex des jeweiligen Katalogs übernommen und sind so neben den “normalen” Schlagworten recherchierbar. Ein so mit weiteren Schlagworten angereicherter Titel profitiert unmittelbar von dieser Anreicherung explizit dadurch, dass die Wahrscheinlichkeit steigt, dass er “mit den Suchworten des Recherchierenden” auch gefunden wird. Die Grundannahme ist also: Je größer die Wortbasis der intellektuell verschlagwortenden BibliothekarInnen, desto größer auch die Wahrscheinlichkeit, dass der Nutzer mit einem davon rechierchiert und dadurch den Titel findet.

Ein gutes Beispiel für diese Kataloganreicherung mit Schlagworten ist der Titel “Die materielle Polizeipflicht des Zustandsstörers und die Kostentragungspflicht nach unmittelbarer Ausführung und Ersatzvornahme – dargestellt am Beispiel der Altlasten-Problematik” aus dem Katalog der Fachbibliothek Rechtswissenschaft.

Anreicherung des Titels mit weiteren Schlagworten

Dieser Titel wurde lokal mit den Worten Altlasten, Kostenpflicht und Polizeipflicht verschlagwortet. Durch die Anreicherung kommen nun noch die Begriffe Altlastsanierung, Störer, Zustandshaftung und Gefahrenabwehr hinzu. Gleichzeitig ist dieser Titel auch im Katalog des Instituts für Öffentliches Recht und Verwaltungslehre vorhanden (PermaLink hier).

Anreicherung mit Schlagworten bei einem lokal nicht verschlagworteten Titel

Dort ist der Titel überhaupt nicht verschlagwortet und er profitiert maximal von der Anreicherung. Mehr noch – wie bereits angesprochen können alle Titel durch den Nutzer in diesem Katalog erreicht werden, die auch in anderen Katalogen vorhanden sind und dort entsprechend verschlagwortet wurden – z.B. mit dem Schlagwort Gefahrenabwehr ergeben sich so 5 zusätzlich vernetzte Titel.

Titel zur Gefahrenabwehr im lokalen Katalog entsprechend der Verschlagwortung in anderen Katalogen

Die Kataloganreicherung mit Schlagworten ist ein gutes Beispiel dafür, wie mit relativ wenig Aufwand für den Recherchierenden ein deutlicher Mehrwert im Bereich Recherchierbarkeit sowie thematische Titelvernetzung geschaffen werden konnte. Dieser Mehrwert ließe sich noch weiter steigern, wenn es zu einem freien Austausch dieser (und weiterer) Informationen mit anderen Katalogen bzw. Katalogprojekten kommen könnte. So überlegen wir derzeit z.B. ob und wie wir weite Teile unserer Anreicherungsdatenbank frei verfügbar machen können, so dass sie von anderen interessierten Katalogen genutzt werden können. Solch ein Austausch würde insbesondere im Bereich der “social web”-Inhalte wie z.B. bei Tags, Literaturlisten usw.  in Katalogen, die jeder für sich unterhalb einer kritischen Masse von Nutzern agieren, einen gangbaren Weg darstellen, um eben jene kritische Masse durch Zusammenarbeit dennoch zu erreichen.

Der DFG-Viewer benötigt die Strukturinformationen des Digitalisats im METS-Format, wie es auch vom Zentralen Verzeichnis Digitalisierter Drucke zvdd verwendet wird. Da Jakob für Wikisource bereits einen Proof-Of-Concept-Code veröffentlichte, habe ich diesen mit seiner Erlaubnis erst einmal als Grundlage für unsere Umsetzung genommen und ihn dann sukzessive überarbeitet.

Ausgehend von der Indexseite der jeweiligen Digitalisate, die alle mit Index: beginnen, können dort – ähnlich den Personen- und Textdaten für die bibliographischen Daten in der deutschen Wikisource – z.T. strukturiert vorliegende rudimentäre Metadaten des Digitalisats aus dem XML-Dump von Wikisource entnommen werden. Diese sehen normalerweise so aus:

|BILD=[[Datei:Kafka Der Prozess 1925.jpg|200px]]
|AUTOR=[[Franz Kafka]]
|TITEL=[[Der Process]]
|VERLAG=Verlag die Schmiede
|JAHR=1925
|ORT=[[Berlin]]
|QUELLE=[http://anno.onb.ac.at/cgi-content/anno-buch?apm=0&aid=318 ÖNB-ANNO]
|SEITEN=[[Seite:De Kafka Prozeß I.jpg|I]]

Für den DFG-Viewer sind hier insbesondere die Informationen AUTOR, TITEL, JAHR, ORT und vor allem SEITEN interessant. Die Namen aller im zugehörigen Werk digitalisierten Seiten beginnen mit Seite: gefolgt von der effektiven Seitenzählung, die mit Pipe abgetrennt ist. Leider verfügen nicht alle Einträge über solche Metadaten, die über die Seiten-Verweise hinausgehen. In diesem Fall muss man sie den Textdaten der zugehörigen Wikisource-Seite entnehmen und einfach alle Verweise einsammeln die mit Seite: beginnen. Manchmal wird auch das Container-Format DJVU für Digitalisate verwendet. Dieses können wir bisher leider noch nicht verarbeiten.

Die Kunst ist nun zu den Seiten-Verweisen ala

[[Seite:De Kafka Prozeß I.jpg|I]]

die effektiven Dateinamen und -urls zu bestimmen, die für die METS-Datei benötigt werden. Hier hätte ich aus Effizienzgründen, und um Wikisource nicht allzusehr zu belasten, gerne einen geeigeneten Wikimedia-Dump herangezogen, konnte aber keinen finden. Daher muss man zwingend das Wikimedia-API verwenden, bei dem man zudem an die Beschränkungen der maximalen Request-Menge denken muss.

Eine solche Abfrage hat z.B. folgende Form:

http://de.wikisource.org/w/api.php

?format=json&action=query∝=imageinfo&iiprop=url&iiurlwidth=1000&titles=Image
e Kafka Prozeß I.jpg|Image:De Kafka Prozeß II.jpg|Image:De Kafka Prozeß 001.jpg|Image:De Kafka Prozeß 002.jpg

Zurückgeliefert bekommt man dann alle benötigten Datei-Informationen im JSON-Format und kann diese sehr einfach weiter verarbeiten.

Wichtig ist hier die Forderung des DFG-Viewers nach einer Standardauflösung von 1000 bis 1500 Pixel für die Breite der Bilder, die über den CGI-Parameter iiurlwidth konfiguriert wird. Mit den Metadaten des Digitalisats, den Labeln für die effektive Seitenzählung, den URLs für die Bilder in der geforderten Standard- sowie maximal möglichen Auflösung, hat man nun alle Informationen an der Hand, um die METS-Beschreibung zu erstellen.

Geplant war zuerst die Katalogeinträge im KUG um eine Kategorie zu erweitern und in diese dann die in XML kodierten METS-Informationen abzulegen. Just in diesem Moment haben wir aber bemerkt, daß der DFG-Viewer die METS-Daten von Jakob gar nicht mehr anzeigen kann. Die Seite bleibt einfach weiß – eine Fehlermeldung gibt es nicht und auch der Validator für den DFG-Viewer bescheinigte späteren METS-Kodierungen von uns Korrektheit – nur der DFG-Viewer zeigte nichts an. An dieser Stelle möchte ich darauf hinweisen, daß der DFG-Viewer anscheinend mindestens für einen Tag die METS-Daten eines Digitalisats zwischenspeichert – für jeden fehlerhaften Versuch muss man sich also ein neues Digitalisat suchen…

An diesem Punkt habe ich die Idee mit der fertig abgespeicherten METS-Beschreibung aus Flexibilitätsgründen sehr schnell verworfen, um auch später noch schnell Anpassungen im geforderten METS-Derivat vornehmen zu können. Dazu erfolgte mit unserem Konvertierungsprogramm eine Serialisierung der wesentlichen Basisinformationen (Metadaten, URLs, Label, usw.) in ein Set an neu geschaffenen Kategorien. Aus diesen Kateogorien generieren wir dann erst später über unser Templating-System, dem Template Toolkit, im Template connector_unapi_mets die für den DFG-Viewer geeignete METS-Beschreibung.

Konkret haben wir zur Lieferung der METS-Beschreibung die schon vorhandene unAPI-Schnittstelle um das METS-Format erweitert. Da wir aber noch nicht genau wissen, ob der Hauptnutzer dieser Schnittstelle – Zotero – eventuell Probleme mit diesem zusätzlichen Format hat, wird es erst einmal bei unAPI-Anfragen nicht explizit “beworben” und muss explizit mit format=mets spezifiziert werden (Beispiel).

Die Verlinkung zum DFG-Viewer erfolgt im KUG in den Vollanzeigen der jeweiligen Katalogaufnahme, wie z.B. beim gewählten Beispiel von Kafka’s Prozeß.

Oft ist hier das gesamte Buch verlinkt – dieses ist üblicherweise via INDEXSEITE in den Textdaten spezifiziert, falls Artikelnamen differieren – und man muß erst den durch die Katalogaufnahme beschriebenen Aufsatz darin finden. Aber dafür gibt es ja normalerweise ein Inhaltsverzeichnis – falls vorhanden..

Schön wäre es aber dennoch, sofort passgenau zur entsprechenden Seite zu springen – bisher konnten wir die dazu benötigten Informationen aus den Wikisource-Artikel aber noch nicht extrahieren bzw. verarbeiten.

Es gibt hier also auch noch einiges zu tun.