Seit März 2010 werden Fachbücher in allen Katalogen des KUG durch Verweise auf die gegebenenfalls vorhandene Online-Version bei PaperC angereichert. So können unsere Nutzer bei ausgeliehenem Bestand – oder wenn gerade dringend etwas nachgeschlagen werden muss – direkt am Bildschirm nach einer kostenfreien Registrierung lesend auf das Buch zugreifen.

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.

Seit der Beschäftigung mit diesem Thema vor knapp 2.5 Jahren und einer Integration in den Kölner UniversitätsGesamtkatalog KUG hat sich einiges getan.

Einen interessanten Überblick verschiedener Herangehensweisen und die exemplarische Erarbeitung einer eigenen fachlichen Facette für einen Bibliothekskatalog liefert die als CC-NC-ND veröffentlichte Bachelor-Arbeit  Konzeption einer fachlichen Facette für einen Bibliothekskatalog am Beispiel der Universitätsbibliothek Mannheim von Julian Frick.

Zitat des Abstact:

Eine in vielen Bibliothekskatalogen bislang nicht verwirklichte Recherchefunktion ist die gezielte Suche nach Literatur aus bestimmten Fachgebieten. Recherchen mit Notationen der im Katalog verwendeten Klassifikation oder mit Schlagwörtern können den Anspruch an eine fachgebietsumfassende Suche meist nicht erfüllen. Eine mögliche Lösung ist die Erstellung einer bibliotheksspezifischen fachlichen Facette, in der jeder Titel über seine sachlichen Erschließungsdaten einem oder mehreren Fächern zugeordnet wird.

In der vorliegenden Arbeit wird nach einem Überblick über bereits vorhandene fachliche Facettierungsmöglichkeiten in verschiedenen Bibliothekskatalogen eine fachliche Facette für den Bibliothekskatalog der Universitätsbibliothek Mannheim konzipiert. Hierbei werden im Besonderen die vorliegenden Sacherschließungsdaten sowie die fachlichen Schwerpunkte der Medienbestände der Universitätsbibliothek Mannheim berücksichtigt. Das Ziel ist die Definition und die Zusammenstellung von Fächern, die im Bibliothekskatalog in unterschiedlichen Varianten umgesetzt und verwendet werden können.

Als zentrale Merkmale für eine thematische Einordnung werden SWD, DNB und RVK herangezogen. Das zeigt sehr eindringlich, wie vorteilhaft es ist, wenn diese thematischen Merkmale im  entsprechenden Katalog vorhanden sind. Für fast alle Kataloge des KUG – gerade im Instituts- und Seminarbereich, und das sind mehr als 130 – bestehen z.B. keine solchen Merkmale. Daher sind wir damals den Weg über die Kataloganreicherung mit der Basisklassifikation aus dem USB-Katalog gegangen.

Durch die Öffnung der Bibliothekskataloge im Rahmen von Open Bibliographic Data ergeben sich nun aber viele neue Möglichkeiten für eine inhaltliche thematische Einordnung der Titel eines Katalogs. Lokal eventuell nicht vorhandene Merkmale können fortan durch Abgleich mit andernorts veröffentlichten Katalogdaten mit eben jenen Merkmalen angereichert werden.

Interessant ist dabei – neben den bereits mit dem hbz geöffneten Katalogen – insbesondere die Veröffentlichung des B3Kat von BVB und KOBV, der sich für solches Data-Mining nutzen lässt. Ebenso lohnen sich die offenen Daten aus dem SWB.

Denn die Datenqualität ist dort schon beachtlich. Das hat sich eindrucksvoll gezeigt, als ich test- und spielenderweise einen Schwung von knapp 1 Mio. MARC-Titeln der Universitätsbibliothek Tübingen in eine lokale out-of-the-box VuFind-Installation eingeladen habe. Die direkt in VuFind vorhandene Möglichkeit im Bestand nach Signatur-(=Fach)Gruppen, Sprache und Format zu stöbern – und das ohne Vorbehandlung der Daten bzw. Anpassung in VuFind selbst – ist auf Grundlage dieser Daten vorbildlich.

Nach wie vor hat die thematische Bündelung der Informationsressourcen einer Bibliothek (Katalogtitel, EZB, DBIS, Literaturlisten, etc.) einen hohen Nutzwert für die Recherchierenden. Die Bachelor-Arbeit macht jedenfalls Lust, sich mal wieder mit diesem Thema zu beschäftigen.

Update:

Und hier noch ein Link auf einen Artikel im gleichen Kontext:

Wiesenmüller, Heidrun ; Maylein, Leonhard ; Pfeffer, Magnus (2011) Mehr aus der Schlagwortnormdatei herausholen – Implementierung einer geographischen Facette in den Online-Katalogen der UB Heidelberg und der UB Mannheim B.I.T. online 14 (2011) Nr. 3, S. 245-252

Die Wikipedia beinhaltet sein jeher viele Informationen, die sich – gerade wegen des offenen Charakters und der Zugänglichkeit aller Daten als Vollabzug – für eine Integration in einen Katalog eignen. Sehr interessant sind die zugehörigen Literaturnachweise mit ISBNs in den einzelnen Artikeln als Startpunkt für eine weitere Beschäftigung mit dem jeweiligen Thema.

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

 

oder: Wie aus dem Verzeichnis eines Künstlerlebenswerks in einem Katalog ein ausdruckbares Werkverzeichnis wurde

Im Jahr 2010 erhielt die USB Köln einen Großteil des künstlerisches Lebenswerkes des Kölner Graphikers, Illustrators und Pressendruckers Eduard Prüssen als Vorlass. Die Illustrationen und Bücher wurden daraufhin in einem Katalog aufwändig erfasst.

Wie schon bei vielen anderen Sammlungen der USB Köln wurde auch diese durch ein eigenes Sammlungs-Portal besonders hervorgehoben und gewürdigt:

Der Kölner Graphiker, Illustrator und Pressendrucker Eduard Prüssen zählt zu den bedeutendsten Buchillustratoren in Deutschland. Zahlreiche Bücher der Weltliteratur wurden von ihm illustriert, darunter Werke von Heinrich Böll, Guy de Maupassant, Pearl S. Buck, Franz Kafka und Theodor Fontane. Graphik und Buchkunst bestimmen das Hauptwerk des Künstlers, der überdies auch als Verleger mit seinen “Donkey-Press” Handdrucken Erfolge feiern konnte.

Im Jahr 2010 übergab Eduard Prüssen der Universitäts- und Stadtbibliothek Köln einen Großteil seines künstlerisches Lebenswerkes als Vorlass.

Die Sammlung Prüssen besteht vorwiegend aus Illustrationen in druckgraphischer Technik als Holz- und Linolschnitte und als Radierungen. Sie umfasst im Wesentlichen Buch- und Presse-Illustrationen sowie Plakate, Exlibris, Werbe-Illustrationen und Handpressendrucke. Mit der “Prüssen-Bibliothek” stellte der Künstler der USB überdies eine Anzahl von Büchern zur Verfügung, die von ihm illustriert worden sind. Besonders wertvoll ist, dass die Sammlung Eduard Prüssens graphisches Werk von der ersten Skizze über die Entwürfe bis zum veröffentlichten Buch oder Plakat umfasst. Das erlaubt der USB Köln, dem interessierten Nutzer einen tiefen Einblick in die Entstehungsweise, die Anwendung verschiedener Techniken und auf die zeitgenössische Graphik und Buchkunst zu ermöglichen.

Zusätzlich zu diesem Portal sollte – mit vertretbarem Aufwand – ein Werkverzeichnis der Sammlung im Rahmen der elektronischen Schriftenreihe der USB Köln als eigene Publikation im PDF-Format erscheinen.

Da die erfassten Daten im Rahmen des Sammlungs-Portals bereits in die OpenBib-Plattform eingespielt wurden, konnte auf sie von dort bequem strukturiert zugegriffen werden. Mit einem einfachen Programm und zwei Ausgabe-Templates (Gesamtdokument,Titelaufnahme) war eine automatische Erzeugung des E-Books direkt aus der Katalogdatenbank über das Textsatzsystem LaTeX möglich.

Für eine zusätzliche Print-Ausgabe wurde dieses E-Book um einige Grafiken und einen handgefertigten Einband durch die Buchbinderei der USB Köln ergänzt. Die Katalogdaten selbst wurden – entsprechend der Open Data Strategie der USB Köln – unter CC0 freigegeben.

Das fertige Dokument ist frei über den Hochschulschriftenserver der Universität zu Köln zugreifbar.

Seit der Erstellung der ersten Sammlungs-Portale wurde konzeptionell an einer Verbesserung des allgemeinen Sammlungsauftritts an der USB Köln gearbeitet. Problematisch war insbesondere, dass die Sammlungen quer über die Homepage verstreut waren. Einige fanden sich unter “Suchen & Bestellen”, andere unter “E-Medien”, wieder andere unter “Wir über uns” wieder.

Daher war sehr schnell klar, dass alle Sammlungen der USB Köln zukünftig an einer zentralen und prominenten Stelle auf der Homepage gebündelt und vereinheitlicht werden müssen. Eine Übersicht aller Sammlungen ist nun sowohl alphabetisch wie auch systematisch unter dem zentralen Sammlungseinstieg “Sammlungen” direkt von der Startseite aus erreichbar.

Die eigenständigen Sammlungs-Portale haben weiterhin den bekannten einheitlichen Aufbau:

• Die Startseite fasst alle wesentlichen Informationen zur Sammlung kurz und prägnant zusammen, so dass ein Blättern auf der Seite vermieden wird und der gesamte Inhalt auf einen Blick ersichtlich ist. Weitere Informationen zur Sammlung auf zusätzlichen Seiten sind von dort aus verlinkt. Links neben den Informationen ist jeweils ein Bild zur Illustration der Sammlung dargestellt.
• Der Banner-Bereich umfasst links ein sammlungsspezifisches Logo mit dem Titel der Sammlung sowie rechts ein Logo der beteiligten/besitzenden Institution.
• Jedes Sammlungs-Portal wird über einen eigenen “Visitenkarten”-URL aufgerufen, wie z.B. http://richterbibliothek.ub.uni-koeln.de/, http://schmalenbach.ub.uni-koeln.de/, http://abklatschsammlung.ub.uni-koeln.de/
• Der Inhalt jeder Sammlung wird neben einer sammlungsspezifischen Recherche u.a. auch über Wortwolken und Register weiter inhaltlich erschlossen.
• Wenn eine Sammlung durch ein eigenes Projekt erschlossen wurde, sind die zugehörigen Informationen im zusätzlichen Hauptmenü-Eintrag “Projekt” gebündelt.
• Anhand der Hintergrundfarbe werden die verschiedenen Sammlungsarten unterschieden. Zum Altbestand gehörige Sammlungen (Dante, Landschaftsbilder) werden z.B. hell-beige und moderne Sammlungen (LeFort, Prüssen) weiß dargestellt.

Auf diese Weise wird erreicht, dass jede Sammlung aus der Anonymität des USB-Katalogs herausgelöst und mit ihren vielen Informationen wie in einer “Sonderausstellung” präsentiert wird. Mit dieser individuellen Präsentation möchten wir unserer Wertschätzung einer jeden Sammlung und eines jeden Sammlers Ausdruck verleihen und unsere Nutzer auf diese verborgenen Schätze aufmerksam machen.

Funktionell entspricht jedes Sammlungs-Portal dem Kölner UniversitätsGesamtkatalog KUG mit Suchmaschinentechnologie, Tagging, Literaturlisten usw.

Zusätzlich zu den bereits damals vorgestellten Sammlungen wurden für viele neue (und alte) Sammlungen Portale in einheitlicher Struktur erstellt.

Es sind dies bisher:

Die Dante Sammlung

unter: http://dante.ub.uni-koeln.de/

 

Die Bibliothek Herbert von Dirksen

unter: http://dirksen.ub.uni-koeln.de/

 

Die Thomas a Kempis-Sammlung

unter: http://kempis.ub.uni-koeln.de/

 

Die Digitale Sammlung Europäische Städte- und Landschaftsdarstellungen des 16. und 17. Jahrhunderts

unter: http://landschaftsbilder.ub.uni-koeln.de/

mit fachspezifischen Facetten bei der Recherche

 

Die Poetica-Sammlung

unter: http://poetica.ub.uni-koeln.de/

 

Die Portraitsammlung

unter: http://portraitsammlung.ub.uni-koeln.de/

 

Die Sammlung Prüssen

unter: http://pruessen.ub.uni-koeln.de/

 

Die Virtuelle Bibliothek Elise und Helene Richter

unter: http://richterbibliothek.ub.uni-koeln.de/

 

Die Bibliothek Eugen Schmalenbach

unter: http://schmalenbach.ub.uni-koeln.de/

 

Die Syndikatsbibliothek

unter: http://syndikatsbibliothek.ub.uni-koeln.de/

 

Die Totenzettel-Sammlung

unter: http://totenzettel.ub.uni-koeln.de/

mit sammlungsspezifischer Kurztrefferanzeige und Facetten

 

Die Digitale Umschlagsammlung

unter: http://umschlagsammlung.ub.uni-koeln.de/

 

Die Bibliothek Franz Ferdinand Wallraf

unter: http://wallraf.ub.uni-koeln.de/

 

Die Digitale Kölner Sammlung von Zeitungsausschnitten 1840-1969

unter: http://zeitungsausschnitte.ub.uni-koeln.de/

 

Die bibliographischen Daten einer jeden Sammlung sind zusätzlich – gesondert von den Gesamtdaten des USB Katalogs – als Open Data unter CC Zero durch die USB Köln bereitgestellt worden.

 

Seit dem Jahr 2004 wird das OpenBib-Projekt bei BerliOS gehostet, einer von Fraunhofer FOKUS betriebenen Infrastruktur für Open Source Projekte (Source Code Hosting, Wiki, Mailinglisten, Trouble Ticket System etc. pp.).

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.

Jakob Voss hatte bereits Anfang 2010 in einem Blog-Artikel die Entwicklungen im Bereich mobiler OPACs skizziert und eine eigene Design-Studie für PICA-Systeme vorgestellt. Diese basiert auf der bekannten Schnittstelle Z39.50/SRU sowie dem Toolkit iWebKit, das für diverse Smartphone-Betriebssysteme und -Browser optimiert ist. Auch Christian Hauschke hat diesen OPAC kurz darauf für den Gesamtkatalog Hannover eingesetzt.

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 Motto der kommenden Version 2.4 von OpenBib könnte lauten “weg von handoptimierten Sonderlösungen und hin zu weiter verbreiteten Frameworks und Web-Standards“. Das bringt viele Vorteile mit sich – sowohl beim Einstieg anderer in die Nutzung oder Erweiterung von OpenBib, wie auch für mich als Entwickler:

• 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…

 

Nach der Integration von QR-Codes in den KUG vor wenigen Tagen haben wir nach weiteren praktischen Verwendungsmöglichkeiten im Umfeld eines Bibliothekskatalogs gesucht. Neben Text und URL’s lassen sich mit QR-Codes auch andere Inhalte transportieren. Besonders interessant erschien uns der Transport von Kalenderdaten, da sich diese in einem Kernbereich eines Katalogs – dem Ausleihkonto – befinden.

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.

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.

Ein QR-Code (QR steht für englisch: quick response = schnelle Antwort) ist entsprechend Wikipedia ein zweidimensionaler (2D) Code, der durch geeignete Programme mit einem Photohandy (oder PDA oder Tab) verarbeitet werden kann.

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:

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:

 

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.