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.

Dazu werden Metadaten zu den Digitalisaten benötigt. Im Folgenden skizziere ich exemplarisch den Weg, den wir für die deutschen Wikisource-Bestände gegangen sind, um sie in den KUG zu integrieren.

Anstatt den Weg über die Index-Seite des zugehörigen Text-Eintrags zu gehen – wie ihn Jakob Voss in seinem Artikel Wikisource im DFG-Viewer dank Schnittstellen skizziert, analysieren wir dazu den gesamten Wikisource-Dump dewikisource im XML-Format.

Die benötigten Metadaten zu den jeweiligen Digitalisaten befinden sich direkt in deren Seite in einem Template mit dem Namen Textdaten. In ihm sind entsprechend der zugehörigen Informationsseiten Vorlage_Diskussion:Textdaten sowie Wikisource:Metadaten – letztere wieder unter Federführung von Jakob Voss – folgende Felder definiert:

|VORIGER=
|NAECHSTER=
|AUTOR=
|TITEL=
|SUBTITEL=
|HERKUNFT=
|HERAUSGEBER=
|AUFLAGE=
|ENTSTEHUNGSJAHR=
|ERSCHEINUNGSJAHR=
|ERSCHEINUNGSORT=
|ÜBERSETZER=
|ORIGINALTITEL=
|ORIGINALSUBTITEL=
|ORIGINALHERKUNFT=
|WIKIPEDIA=
|BILD=
|QUELLE=
|KURZBESCHREIBUNG=
|SONSTIGES=
|BEARBEITUNGSSTAND=

Wie schon Jakob Voss in Wikisource:Metadaten ausführt, wären weitere Kategorien sehr wünschenswert. Die vorhandenen sind aber schon ganz brauchbar – speziell wenn man sie mit den Metadaten anderer Wikisource-Bestände, wie z.B. der englischen vergleicht. Dort wird das Template header2 verwendet und dieses kennt an katalogrelevanten Kategorien gerade mal Autor und Titel:

 | title    =
 | author   =
 | section  =
 | previous =
 | next     =
 | notes    =

Problematisch und undefiniert sind die Trenner zwischen mehreren Verfassern. Mal wird das HTML-BR, mal und, mal ein Komma verwendet. Mit den entsprechenden regulären Ausdrücken für den Trenner kann man aber schon sehr weit kommen und viel auflösen. Dennoch wäre eine verbindliche Definition des Trenners in Wikisource aus meiner Sicht sehr sinnvoll, z.B. Leerzeichen Semikolon Leerzeichen.

Unser Mapping für die Daten aus dem Textdaten-Template zu unserem internen MAB2-basierten Zwischen-Format für den KUG ist in der Konfigurationsdatei wikisource_de.yml im YAML-Format definiert. Als numerische Identifikationsnummer eines Wikisource-Digitalisats verwenden wir die zugehörige interne Id-Nummer des Artikels im Wikisource-Dump.

Neben dem Textdaten-Template verwendet die deutsche Wikisource Textsammlung darüber hinaus auch ein Template Personendaten. In diesem sind folgende Informationen enthalten:

|NACHNAME=
|VORNAMEN=
|ALTERNATIVNAMEN=
|SORTIERUNG=
|PERSON=
|KURZBESCHREIBUNG=
|SONSTIGES=
|GEBURTSDATUM=
|GEBURTSORT=
|STERBEDATUM=
|STERBEORT=
|BILD=
|WIKIPEDIA=
|WIKIQUOTE=
|COMMONS=
|PND=

Fast alle dieser Verfasser-Kategorien übernehmen wir auch für den Import in den KUG. Problematisch und erst einmal nicht abbildbar auf einen Verfasser-Normdateneintrag in einem Katalog wird es, wenn in einem Wikisource-Artikel mehr als ein Personendaten-Template verwendet wird – wie z.B. beim Artikel zu den Brüdern Grimm.

Bei den gelieferten Metadaten – Text- und Personendaten – stellt sich sofort die Frage, wie dort mit Verlinkungen – sei es zu anderen Artikeln aus dem Wikipedia-Universum oder zu externen Webseiten umzugehen ist. Aus unserer Sicht stellen diese Links für unsere Nutzer einen wesentlichen Wert dar. Darüber hinaus ist es speziell bei den Quellenangaben eine reine Selbstverständlichkeit auch auf die Ursprungsdigitalisate direkt zu verweisen – wenn die Information denn da ist und maschinell ausgewertet werden kann.

Daher wandeln wir Verweise durch unser Konvertierungsprogramm aus der Wikisprache in explizite, vollqualifizierte HTML-Links um. Der Titel und die Verfasser sind davon allerdings ausgenommen, da diese für die Navigation innerhalb des KUG benötigt werden.

Mehr war für die Integration nicht zu tun.

Die deutschen Wikisource-Daten befinden sich im KUG in einem externen Katalog mit dem Namen E-Texte / Wikisource deutsch (Online-Vollzugriff) und umfassen derzeit 10448 Titel. Darüber hinaus bieten wir ihn auch einzeln vorausgewählt in einer eigenen Katalogsicht an.

Ein gutes Beispiel für die Integration der Wikisource-Daten in den KUG ist der Text Elementargeister von Heinrich Heine.

Zusätzliche Erweiterungen sind geplant. So wollen wir z.B. untersuchen, inwieweit man die Kategorie-Bezeichnungen der Wikisource-Artikel auswerten und daraus Schlagworte für den Katalog generieren kann. Denkbar wäre auch eine automatische Weiterleitung aus dem KUG an den DFG-Viewer auf Grundlage von MODS. In wieweit wir es wagen sollen auch die Digitalisate anderssprachiger Wikisource-Sammlungen in den KUG zu integrieren ist aufgrund der mageren Metadaten noch nicht final entschieden.

Update 11.9.2009: Im Finanzer Blog gibt es als Reaktion auf meinen Artikel einen interessanten Verweis auf das Wikimedia-API. Mit diesem ließe sich der Bestand von Wikisource sicherlich auch sehr gut via AJAX oder für eine föderierte Suche einbinden. Da wir im KUG keine klassische föderierte Suche einsetzen, sondern unseren Mehrwert durch die Verarbeitung der gesamten Quelldaten schöpfen, ist das für uns nicht direkt anwendbar – für andere Katalogarchitekturen könnte das aber ein guter Weg sein.

Seit Ende der 90er Jahre verwendet OpenBib mod_perl im Apache Webserver – zunächst als Beschleuniger auf CGI-Basis mit Apache::Registry, ab Anfang 2005 als in den Apache vollintegrierte modulare Webanwendung. Doch die Zeit steht nicht still und während wir im KUG bisher noch sehr zuverlässig mod_perl mit dem Apache in der Version 1.x verwendeten, merkten wir so langsam, dass diese Kombination um uns herum fast schon ausgestorben war…

Alle großen Linux-Distributionen sind inzwischen auf Apache2 und mod_perl2 umgestiegen und den Schlusspunkt setzte nun die von uns vewendete Debian-Distribution. Bot die letzte Version etch – die momentan die Basis für die Produktionssysteme des KUG liefert – noch sowohl Apache1 und Apache2 mit ihren jeweiligen mod_perl-Varianten an, so zieht die aktuelle Version lenny hier einen Schlussstrich und verbannt Apache1 endgültig aus ihrer Paketsammlung.

Grund genug den Umstieg von OpenBib auf Apache2 mit mod_perl2 nun endlich anzugehen. Dazu haben wir erstmal einen separaten mod_perl2-Branch im CVS angelegt, um dann auf Basis von Debian etch die notwendigen Anpassungen vorzunehmen.

Eigentlich war der Aufwand deutlich geringer als erwartet. Die größte Arbeit bestand im Austausch bzw. dem Hinzufügen der vielen neuen Perl-Module. Diese hatten sich von sehr wenigen Modulen in mod_perl1 auf eine Vielzahl in mod_perl2 verteilt. Im Abgleich mit der Online-Dokumentation musste deshalb herausgefunden werden, welche von OpenBib verwendete Methode in welches neue Modul gewandert ist – und dieses dann in OpenBib ausgetauscht oder hinzugefügt werden. Eine große Hilfe war hier die offizielle Portierungs-Dokumenation als Referenz sowie als ausführliches Beispiel.  Insbesondere der Trick mit PerlModule Apache2::porting in der httpd.conf liefert wesentliche Hinweise darüber, was genau zu tun ist.

Zentrale neue Module sind:

• Apache2::Const
• Apache2::Request
• Apache2::RequestRec
• Apache2::SizeLimit
• Apache2::Log
• Apache2::SubRequest
• Apache2::URI
• APR::URI
• Apache2::RequestIO
• Apache2::Connection
• Apache2::Reload

Daneben haben sich auch einige Methoden in ihren Namen geändert: Apache::Request->instance wird zum Standardverhalten von Apache2::Request->new – muss also entsprechend umgeschrieben werden, $r->send_http_header zum Setzen des Content-Type wandert nach $r->content_type, $r->header_out nach $r->headers_out->add und $r->header_in nach $r->headers_in->get. Es empfiehlt sich Konstanten vollqualifiziert anzugegeben, also z.B. Apache2::Const::SERVER_ERROR. Insgesamt kann das alles sehr schnell per sed in der Bash für alle Module geändert werden.

Problematischer war da nur Apache2::Request. Aus Gründen der Abwärtskompatabilität hatten wir eigentlich bereits obsolete – aber extern immer noch verwendete – Request-Parameter mit Apache::Request in einem unserer Perl-Module nachträglich gesetzt. Das geht nun leider nicht mehr. So mussten wir unser entsprechendes Modul ändern und einen anderen Weg finden.

All das ist in der offziellen Dokumentation aber gut beschrieben und die Umstellung artet – von den wenigen Fällen abgesehen, wo der Code individuell angepasst werden musste – zur eher simplen Fleißarbeit aus.

Problematischer und unerwartet war nur das Verhalten von einigen 3rd party Modulen, die wir in OpenBib nutzen. Da wäre zunächst einmal das Template Toolkit. Dieses wollte nach der Umstellung per se nicht mehr zuverlässig auf übergebene Hashwerte per Punktnotation zugreifen – mal funktionierte es, dann wieder nicht. Stattdessen beklagte es sich sporadisch, dass die entsprechende Methode nicht existiere. Variablen-Aufrufe wurden also fälschlicherweise als Methoden-Aufrufe angesehen. Also mussten entsprechende Accessor-Methoden eingeführt werden – das hatte ich bereits einige Zeit vor mir hergeschoben und die damit einhergehende Kapselung war ohnehin dem wilden Referenzieren mit Punkten vorzuziehen.

Und dann war da noch Apache::Singleton::Request, das wir an verschiedenen Stellen zur Realisierung des Singleton Design-Patterns verwenden. Augenscheinlich auch für Apache2 geschrieben, funktioniert es dort aber nicht richtig. Der Effekt: Eine Anfrage und der Apache saugt sich allen verfügbaren Hauptspeicher, bis der Recher tot ist – mausetot. Nur noch aus- und wieder einschalten hilft… – also musste das Modul von uns gepatcht werden. Da der Maintainer leider nicht auf ihm zugesandte Patches reagiert, werden wir die gepatchte Version wahrscheinlich bald als eigenes Debian-Paket bereitstellen.

Die ganze Umstellung im Programmcode von OpenBib war in wenigen Tagen vollzogen. Seit dem 20.7.2009 laufen nun auch beide Produktionsserver des KUG mit Apache2 und mod_perl2.

Damit kann nun auch bei uns Apache1 mit mod_perl1 endlich seinen verdienten Ruhestand genießen. So long, and thanks for all the fish.

Seither habe ich rund um das Auffinden und Aufarbeiten der Digitalisate des Internet Archives in lokalen Katalog-Anwendungen recherchiert und fasse das Gefundene hier einmal kurz zusammen. Vielleicht kann das ja dem einen oder anderen bei einer möglichen Integration helfen…

Feeds …

Ein großer Teil des Textbestandes im Internet Archiv, insgesamt knapp 565.000 Verweise auf digitalisierte Bücher und Zeitschriften, kann über den Umweg der Open Library sehr einfach verarbeitet werden. Anders als das Internet Archiv bietet die Open Library einen Komplettabzug ihres Datenbestandes im JSON-Format an – das sind mehr als 20 Millionen Titel- und mehr als 6 Millionen Verfassersätze. Digitalisierte Titel sind über eine vergebene ocaid identifizierbar – Namensgeber für diese ID ist anscheinend die Open Content Alliance (Wikipedia-Eintrag). Die ocaid geht sowohl beim Internet Archiv wie auch bei Open Library an verschiedenen Stellen in die Struktur von URLs ein, für das Digitalisat von Alice’s Abenteuer im Wunderland ist sie z.B. alicesabenteueri00carr. Zwar sind bei der Open Library an vielen Stellen mehr als 1 Million verfügbare Digitalisate genannt, ein einfaches grep nach ocaid in der Feed-Datei bringt jedoch nur die knapp 565.000 Digitalisate zum Vorschein.

Für Update-Zwecke per Bulk-Load und PermaLinks zu den jeweiligen bibliographischen Daten im KUG sind die von Open Library vergebenen numerischen Identifikationsnummern sicherlich hilfreich, die man dann intern übernehmen könnte.

… oder OAI?

Alternativ besteht auch der Weg über einen Abzug der Metadaten via OAI im Internet Archiv, entweder eingeschränkt auf einzelne Sammlungen oder generell über den Medientyp Texts:

http://www.archive.org/services/oai.php?verb=ListIdentifiers&metadataPrefix=oai_dc&set=mediatype:Texts

Immerhin wären so derzeit potentiell 1.432.511 Verweise auf Texte abrufbar. Was alles genau darunter zu fassen ist, wäre auszutesten. Danach müsste man sich dann nach den Identifiern mit GetRecord durchhangeln wie hier bei unserem Beispiel Alice’s Abenteuer im Wunderland

Dieser Identifier besitzt folgende Detail-Anzeige im Internet Archiv: http://www.archive.org/details/alicesabenteueri00carr

Ein großer Nachteil beim Harvesten über OAI ist, daß es damit leider nicht getan wäre – denn die dort ausgegebenen DC-Metadaten entsprechen nicht dem Umfang eines zugehörigen Open Library-Titels. Also müssten MARC-Daten zusätzlich per HTTP via wget pro Titel z.B. über

http://www.archive.org/download/alicesabenteueri00carr/

abgeholt und verarbeitet werden. Da aus diesen MARC-Daten aber offensichtlich wiederum die Katalogisate in der Open Library gebildet werden, haben wir uns wegen der deutlich einfacheren Handhabbarkeit der Feed-Dateien für eine Integration des E-Book-Teilbestandes der Open Library entschlossen – auch wenn damit noch nicht das theoretische Maximum an Digitalisaten ausgeschöpft wird. Insgesamt ist der Download der Feed-Dateien sicherlich deutlich leichtgewichtiger als der Weg über OAI und wget. Die Erstellung des zugehörigen Konverter-Programms für den KUG war ebenfalls relativ simpel.

Der genannte Beispieltitel entspricht dann z.B. folgender Aufnahme im KUG:

http://kug.ub.uni-koeln.de/portal/connector/permalink/openlibrary/9803468/1/openlibrary/index.html

Somit können wir seit heute den Bestand der knapp 565.000 E-Books aus der Open Library im KUG als weiteren Katalog anbieten. Dieser ist zusätzlich über einen eigenen Einsprung “OpenLibrary.org / E-Books” erreichbar. Interessant bei der Integration dieses Katalogs waren für uns auch die im KUG-Kontext verfügbaren Wort-Wolken für Schlagworte, DDC-Systematik und Erscheinungsjahre, um einen groben Überblick der thematischen und zeitlichen Zusammensetzung des Bestandes zu bekommen.

Aktualisierung 13.6.2009:

Anders als Herr Graf, der – entsprechend seiner Kritik an unserer Entscheidung für Feeds – technische Praktikabilität, Umsetzbarkeit und Effizienz bei der Entscheidung Feeds vs. OAI  als Entscheidungskriterium nicht gelten lässt, sind diese für eine tatsächliche Umsetzung dennoch gemeinhin von einer zentralen Relevanz.

Wie er aus einem einfachen Identify auf die OAI-PMH-Schnittstelle des Internet Archives leicht hätte entnehmen können, kann diese leider keine Informationen über gelöschte Datensätze weitergeben. Hier die wesentliche Stelle aus der OAI-PMH-Spezifikation:

2.5.1 Deleted records

If a record is no longer available then it is said to be deleted. Repositories must declare one of three levels of support for deleted records in the deletedRecord element of the Identify response:

no – the repository does not maintain information about deletions. A repository that indicates this level of support must not reveal a deleted status in any response.

Damit müsste man sich nach der Wahl für OAI nun entscheiden, ob man recherchierbare Verweise ohne tatsächlich auffindbares Digitalisat weiterhin im Katalog belassen möchte – und damit die berechtigte Kritik der Nutzer auf sich zieht – oder alle derzeit knapp 1.4 Millionen Datensätze bei jeder lokalen Aktualisierung immer wieder komplett abfragen muss…

Wie mir scheint sehr aufwändig und unsozial dem Internet Archive gegenüber, wenn z.B. jede Nacht deren Komplettbestand per OAI abgesaugt würde…

Aus meiner Sicht ein sehr praktischer Grund, warum eine Entscheidung für die OAI-Schnittstelle des Internet Archivs nicht unproblematisch ist. Es bleibt zu hoffen, dass die Open Library selbst nicht via OAI vom Internet Archive gefüllt wird…

In der Vergangenheit wurden wir des Öfteren nach dem konkreten Einsatz von OpenBib gefragt. Was ist zu bedenken, wenn eine Bibliothek die Software lokal einsetzen möchte? Wie aufwändig sind Installation und Betrieb, ist die Software überhaupt etwas für uns, usw.

Sehr schnell hat sich dann gezeigt, dass insbesondere die Installation eine abschreckende Wirkung zu haben scheint – obwohl sie sich für einen Kundigen mit dem entsprechend praktischen Know-How nach meiner Einschätzung unter Zuhilfenahme des OpenBib Wiki an einem Vormittag bewerkstelligen lässt. Wenn man es schon einmal gemacht hat, dann geht es sogar in 30-60 Minuten (Infrastruktur inklusive).

Nicht nur die Installation und Konfiguration der Basis-Infrastruktur mit Apache, MySQL, mod_perl und Xapian scheint hier problematisch zu sein, sondern auch die Installation der eigentlichen OpenBib-Anwendung mit ihren verschiedenen Perl-Modulen.

Da aber gerade eine Evaluation vor einem möglichen Einsatz steht, sollte für eine Probefahrt mit KUG und OpenBib auch nicht viel Aufwand anfallen. Aus diesem Grund habe ich auf Basis von VMWare Workstation einen fertig installierten und konfigurierten virtuellen Rechner mit OpenBib erstellt, der sich mit minimalem Aufwand in Betrieb nehmen lässt.

Das Abbild des fertig konfigurierten Rechners ist über folgenden URL erreichbar:

http://kug.ub.uni-koeln.de/testdrive/

Für die Inbetriebnahme reicht folgendes aus:

1. Das OpenBib-VMWare-Image herunterladen und auspacken
2. VMWare starten und unter File/Open das ausgepackte Image ansteuern und auswählen
3. Den lokalen Port 80 auf den Port 80 der virtuellen Maschine durchreichen, damit der Web-Zugriff funktioniert
4. Den lokalen Port 22 auf den Port 22 der virtuellen Maschine durchreichen, damit man bequem per SSH auf dem Rechner arbeiten kann
5. Den KUG via http://localhost/portal/opac?view=kug oder die Web-Administration via http://localhost/portal/admin aufrufen

Die Installation auf dem virtuellen Rechner entspricht dem aktuellen KUG in der Version 2.3 und enthält zwei fertig eingespielte Kataloge. Beim Betriebssystem und dem MySQL-Server wird das Passwort StrengGeheim für den Nutzer root verwendet, in der Web-Administration von OpenBib selbiges Passwort für den Nutzer admin.

Eine Aktualisierung der OpenBib-Sofware als Nutzer www-data ist jederzeit durch ein cvs update -d unter /opt/cvs/openbib-current/ möglich.

Jenseits der Evaluation besteht mit dem Image natürlich auch die Möglichkeit OpenBib direkt in eine lokale virtualisierte Infrastruktur auf Basis von VMWare aufzunehmen und es somit als Ausgangspunkt für ein lokales virtualisiertes Produktionssystem zu verwenden. Gerade Virtualisierung ist auch bei uns ein Thema. Als OpenSource-Lösungen favorisiere ich aber derzeit KVM, womit zusätzlich zum VMWare-Image sicherlich in der Zukunft ein KVM-Image stoßen wird.

Generelle Überarbeitung des Designs und der Nutzerführung

Nach der letzten KUG-Version Mitte 2008 sahen wir einen guten Zeitpunkt, bewusst einen Schritt zurück zu treten, um uns den KUG in seiner Gesamtstruktur – jenseits einzelner Features – mit kritischem Abstand zu betrachten. So besitzt das KUG-Design beispielsweise immer noch den spröden Charme der 90er Jahre, die logische Gruppierung verschiedener Funktionen sollte verbessert oder Funktionselemente sprechender werden. Auch externes Feedback, wie z.B. von den Arbeitsgruppen zu Wissensorganisation 2.0 oder dem Wiki der AG Web 2.0, war uns dabei sehr willkommen.

Im Rahmen einer Umstellung weiter Teile auf ein zeitgemäßes Layout mit Cascading Stylesheets (CSS) wurden diese Ziele angegangen. Vorteilhaft für diese Arbeiten zu unserem KUG der nächsten Generation (Arbeitstitel) hat sich dabei die Technik systemweiter Katalogprofile erwiesen, mit der wir bereits den KUG light realisieren konnten. Damit konnten wir auf unserem Produktionssystem gefahrlos mit der Überarbeitung der jeweiligen Templates beginnen und diese agierten immer auch auf den aktuellen Katalogdaten.

Verknüpft mit der strukturellen Überarbeitung war darüber hinaus die inhaltliche Integration der Elektronischen Zeitschriftenbibliothek EZB und des Datenbank-Infosystems DBIS.

Vom Suchschlitz zum Discovery-Portal

Bewusst haben wir auf unsere schlanke Einstiegsseite mit Suchschlitz verzichtet, um unsere Nutzer unmittelbar auf viele der vom KUG bereitgestellten Funktionen und Recherchemöglichkeiten aufmerksam zu machen. Diese wurden nach dem Motto „Ach, das kann der KUG auch“ oft als zu versteckt angesehen. Dazugekommen ist eine Beschränkung der Recherche auf die Medientypen Zeitschrift/Serie und Aufsatz sowie ein direkter thematischer Zugang in den KUG (und darüber hinaus).

Ebenso kann sich der Nutzer sofort einloggen, um Zugriff auf personalisierte Funktionen wie Tagging, Literaturlisten, eigene Suchprofile usw. zu bekommen. EZB und DBIS sind ebenso direkt – nach Fachgebieten geordnet – erreichbar, wie viele der weitergehenden Funktionen des KUG, um in den Gesamtbestand abzutauchen. Als Teaser werden schließlich die zuletzt angelegten Literaturlisten sowie die neu vergebenen Tags angezeigt.

Thematischer Einstieg in den KUG

Nachdem wir bereits in die aktuelle Version die Möglichkeit eingebracht haben, die Katalogtitel thematisch nach der Basisklassifikation BK über zentrale Kataloganreicherung zu erschliessen (Systematisches Blättern), wollten wir diesen Weg konsequent weiter verfolgen. Das erhaltene Feedback – der generelle Wunsch nach einem thematischen Zugang – entspricht den Ergebnissen der Fokusgruppe aus Studierenden des beluga-Projektes.

Die inhaltliche Erschließung in Themengebieten wollten wir dabei auf eine möglichst breite Basis stellen (s.u.). Es war von vornherein klar, dass die Anzahl von Top-Level Themengebieten überschaubar sein musste – kein Anwender würde seine Literaturlisten schliesslich mit den mehr als 2000 Fachgruppen der BK klassifizieren…

Daher wurden von uns in der Web-Administration des KUG insgesamt 20 Themengebiete festgelegt und diese dann ebenfalls dort mit BK sowie EZB- und DBIS-Fachgruppen verknüpft – die Verwaltung von beliebigen Themengebieten hielt also ebenfalls Einzug in den KUG.

Aus dieser sehr übersichtlichen Anzahl an Gebieten kann ein Nutzer nun eines oder mehrere für die thematische Einordnung seiner Literaturlisten auswählen. Mit der Einordnung von

• Katalogtiteln über die BK
• Elektronisch verfügbaren Zeitschriften (EZB) und ihren EZB-Fachgruppen
• Elektronisch verfügbaren Datenbanken (DBIS) und ihren DBIS-Fachgruppen
• Öffentlichen Literaturlisten

zu unseren festgelegten Themengebieten konnten wir dann den thematischen Zugriff auf eine vernünftige Basis für unsere Nutzer stellen. Zu jedem unserer Themengebiete bekommt der Nutzer immer eine Übersicht aller thematisch zugeordneten verfügbaren Medien – mit EZB und DBIS auch jenseits der KUG-Bestände, dank der Integration über das Regensburger XML-API, das wir in den KUG integriert haben.

Überarbeitung der Einzeltreffer und Titel-Listen

Eine strukturelle Überarbeitung erforderte insbesondere die Einzeltrefferanzeige im KUG. Hier haben wir aufgeräumt und ähnliche Funktionen in visuell abgegrenzten Gruppen zusammengefasst.

• Im Bestandsbereich finden sich nun nur noch Bestands- und Ausleihdaten sowie Verweise auf den Bestand in anderen Katalogen oder andere Ausgaben
• Im Bereich “Behalten Sie diesen Titel” sind alle Funktionen zusammengefasst, mit denen sich der aktuelle Titels durch den Nutzer verarbeiten lässt. Gerade hier hatten wir in der Vergangenheit Kritik wegen des fehlenden Beschreibungstextes der Icons einstecken müssen – obwohl Tooltips natürlich vorhanden waren.
• Im Bereich “Entdecken Sie weitere Titel über…” sind alle Funktionen zusammengefasst, mit denen Nutzer auf weitere Titel gelenkt werden, seien dies Empfehlungen, Tags, Literaturlisten oder – ebenfalls neu – thematisch verwandte Personen oder Schlagworte.

Auf Basis des aktuellen Kataloges erhält der Nutzer bei diesen thematisch verwandten Personen und Schlagworten sehr schnell einen Überblick

• mit welchen Personen die aktuellen Verfasser in anderen Publikationen zusammengearbeitet haben
• welche anderen Schlagworte in anderen Publikationen zusammen mit denen das aktuellen Titels verwendet wurden

Die einzelnen Personen und Schlagworte werden mit der Anzahl anderer Titel korreliert und in Form einer Wort-Wolke dargestellt.

Auch die Ausgabe von Titellisten wurde im KUG vereinheitlicht und diese erscheinen nun alle im gleichen Design. Hinzugekommen ist die Möglichkeit jeden Titel einer Liste direkt nach BibSonomy zu überführen. Bisher war das lediglich in der Einzeltrefferanzeige und der Merkliste der Fall.

Merklisten, Tags und Literaturlisten

Deutlich überarbeitet wurde die Konzeption der Merklisten, Literaturlisten und Listen von Titel zu einem Tag. Seit sehr langer Zeit verfügt der KUG über eine Merkliste. Sie ist das Mittel der Wahl für unsere Anwender wie mit einem großen Einkaufskorb durch den KUG zu wandern und alles Interessante erst einmal dort abzulegen. Sie wird nun zur zentralen Verteilungs-Instanz für die individuelle weitergehende Organisation der Titel ausgebaut. Während bisher bereits ausgehend von einer Merkliste einzelne Titel sofort in Literaturlisten hinzugefügt werden konnten, besteht nun auch die Möglichkeit dort selektierte Titel auf einen Rutsch mit gemeinsamen Tags zu versehen.

Damit wachsen Merklisten, Tags und Literaturlisten weiter zusammen. Überarbeitet und der Einzeltrefferanzeige angepasst wurden auch die einzelnen Funktionselemente im Bereich Behalten Sie diese Liste.

LiveSearch und Rechtschreibvorschläge

Auf der Basis von Aspell haben wir bei der Version 2.2 in der einfachen Recherche und der Trefferliste Rechtschreibvorschläge für die Nutzer eingebaut. Wie sich jedoch schnell zeigte, fühlten sich einige dadurch massiv gestört und wünschten eine Möglichkeit selbst über die Aktivierung dieser Funktion zu entscheiden. Sie brachten es – wie jüngst Herr Eversberg in NGC4LIB – auf den Punkt

What I mean is my business and mine alone. When I make mistakes entering search terms, that’s my problem and mine to solve, using my own intelligence and judgement when looking at inadequate results or “zero hits”. This kind of features only raises unrealistic expectations and creates a trust where mistrust in technology is vital and trust in one’s own capacities must not be eroded but supported.

Andere sehen Rechtschreibvorschläge als essentielle Funktion eines OPAC 2.0 an.

Sinnvoller und mit mehr praktischem Nutzwert wird hingegen eine LiveSearch-Funktion angesehen, in der konkrete Personen oder Schlagworte aus dem tatsächlichen Katalogbestand on-the-fly angezeigt und ausgewählt werden können. Wir haben beides berücksichtigt und sowohl den KUG um eine LiveSearch-Funktion erweitert wie auch die vollständige Kontrolle über eine Aktivierung jedweder dieser Funktionen unseren Nutzern in ihren persönlichen Einstellungen überlassen. Standardmässig sind sowohl Rechtschreibvorschläge wie auch LiveSearch bei den Nutzern deaktiviert – nicht angemeldete Nutzer bekommen beides gar nicht mehr angeboten. Gezeigt hat uns dieses Beispiel:

1. Unsere Nutzerschaft ist sehr heterogen, was die Bewertung und Nutzung einzelner Funktionen angeht
2. Ein Ausweg ist die Personalisierbarkeit, bei der jeder Nutzer selbst entscheiden kann, was er verwenden möchte und was nicht.

Automatische Kataloganreicherung mit Medientypen

Bei der Beschränkung der Recherche auf Zeitschriften/Serien oder Artikel hatten wir das grundlegende Problem, das in einer Vielzahl unserer Kataloge der Medientyp der Titel gar nicht besetzt wird – unsere Titelbasis gab eine solche Einschränkung der Suche also gar nicht her. Aus diesem Grund haben wir die schon lange verwendete Kataloganreicherung auf diesen Aspekt ausgedehnt. Jeder Titel wird daher nun von uns analysiert und entsprechend seiner verwendeten Kategorien und deren Inhalten automatisch mit einem Medientyp versehen – sofern dieser nicht bereits existiert. Dieser Medientyp wird auch für die Rechercheverfeinerung in der Treffermenge genutzt, so ist auch nachträglich eine Eingrenzung auf Zeitschriften/Serien und Artikel möglich.

Um unseren Nutzern einen quantitativen Überblick geschlüsselt nach Medienart anbieten zu können, geben wir die Anzahl der im KUG verfügbaren Zeitschriften/Serien sowie Artikel direkt auf der einfachen Rechercheseite in den jeweiligen Reitern mit aus. Nach Sichtung der Zahlen waren auch wir überrascht, speziell wieviele Artikel wir im KUG haben – instinktiv hatten wir nur mit knapp einem Drittel der tatsächlich mehr als 300.000 verfügbaren Artikel gerechnet.

Integration der Informationen des Bibliotheksführers und Mashup mit Google Maps

Bisher musste für Informationen des Bibliotheksführers zu den einzelnen Instituts- und Seminarbibliotheken auf externe Seiten aus dem KUG herausgesprungen werden. Diese Informationen wurden nun vollständig in den KUG integriert. Hinzugefügt wurde eine englische Lokalisierung der Kategorie-Namen sowie ein Kartenausschnitt mit der Lage der Bibliothek, der über einen Mashup mit Google Maps geliefert wird. Als weiterer Mashup ist eine Integration der Informationen aus dem Interaktiven Lageplan der Universität zu Köln geplant – sobald dieser über eine entsprechende Zugriffsschnittstelle verfügt. Ein Nutzer kann sich dann diese Seite einfach ausdrucken und hat sofort alle wesentlichen Informationen zur jeweiligen Bibliothek an der Hand – samt Lageplan, um die Bibliothek auch zu finden.

Ähnliches – wie bei den Bibliotheksinformationen – gilt für die verschiedenen Online-Tutorien, die wir für den KUG anbieten. Auch diese waren bisher externe Webseiten und sind nun in den KUG integriert.

Feedback

Nachdem wir nun den Weg eines offenen Beta-Tests „des nächsten KUG“ beschritten haben, sind wir sehr gespannt, ob und wieviel Feedback wir bekommen werden. Denn Feedback in Form von Kritik, Verbesserungsvorschlägen, neuen innovativen Ideen oder auch Lob unserer Nutzer ist schließlich die Grundlage für die Weiterentwicklung von OpenBib und damit des KUG.