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.

Bereits seit vielen Jahren wurden einzelne Sammlungen im Rahmen von Projekten mit Hilfe der KUG-Plattform OpenBib als eigenständige Portale unseren Nutzern angeboten – im KUG heissen sie Sichten oder Views. Zu nennen sind hier u.a. unsere Portraitsammlung, die digitale Einband- und Umschlag-Sammlung, die Landschaftbilder, die Historischen Bestände im Rheinland oder die Richter-Bibliothek.

Allen gemeinsam ist, dass sie auf Grundlage nur einer Software-Installation von OpenBib realisiert sind – wie auch die Sichten des Standard-KUG, des KUGlight usw. Insgesamt kommen derzeit so 185 separate Sichten mit ihren verschiedenen Einsprüngen zustande.

Ermöglicht und handhabbar wird das aber erst durch die verschiedenen Abstraktionsebenen im KUG – Datenbanken, Sichten und Profile (zur Gruppierung von Datenbanken/Sichten), die bequem über ein Web-Frontend verwaltet werden können.

Durch sie wird ein Kontext vorgegeben, in dessen Abhängigkeit sich Templates und CSS-Dateien geschickt plazieren lassen, um so den Aufwand für die Realisierung eines neuen Portals zu minimieren.

Die Universitäts- und Stadtbibliothek Köln verfügt über eine große Zahl an Sammlungen, die jedoch im Gesamtbestand  aller Katalogtitel leider weitgehend untergehen – vielen Nutzern erschließt sich nicht, welche Sammlungen wir überhaupt haben.

Aus diesem Grund haben wir begonnen, Kriterien für deren Identifikation zu bestimmen, um dann in einem ersten Schritt die jeweilige Sammlung aus dem Gesamtbestand zu extrahieren und in eine eigene Datenbank in der KUG-Plattform einzuspielen.Die Sammlungsbestände werden so – jeder für sich – aus der Anonymität des gesamten Kataloges herausgelöst und getrennt ansprechbar.

Dazu nutzen wir ein einfaches Konvertierungs-Plugin, das für die Bildung des jeweiligen Teilbestandes sorgt. Sehr vorteilhaft ist hier die eigenständige Datenhaltung in einer SQL-Datenbank und einem Suchmaschinenindex in der KUG-Plattform, mit der Sammlungen auch aus verschiedenen Erfassungssystemen dort zusammengeführt werden können. Das ist umso wichtiger, da etliche Sammlungen an der Universität zu Köln gerade nicht im USB-Katalog nachgewiesen sind, wir aber eine Gesamtlösung anstreben. Das Spektrum der vorhandenen Daten reicht hier von der einfachen Excel-Datei bis zum spezialisierten Erfassungsystem.

Für jede dieser Sammlungen erstellen wir eine eigene Portalsicht, in der die Bestände beschrieben und über Recherchemöglichkeiten, Übersichten und/oder Register für die Nutzer zugänglich gemacht werden. 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.

Zusätzlich sollen alle Sammlungen später auch zusammen in einem eigenen Portal recherchierbar sein – eine zentrale Recherche ala KUG wird dann auch für alle Sammlungen möglich sein . Die Einbeziehung aller verfügbaren Sammlungen in die KUG Portalsicht unter kug.ub.uni-koeln.de ist derzeit nicht geplant.

In den letzten Tagen konnten auf diese Weise drei Sammlungen in eigenen Portalen fertig gestellt werden – zwei aus der USB und eine aus der Universität. Der Aufwand bestand lediglich in 14 zu ändernden Templates für alle Sammlungen sowie 5 Templates für jede einzelne USB-Sammlung, wie die von H. C. Artmann.

Es sind dies:

Die Abklatsch-Sammlung der Arbeitsstelle für Papyrologie, Epigraphik und Numismatik der Nordrhein-Westfälischen Akademie der Wissenschaften und der Künste am Institut für Altertumskunde der Universität zu Köln unter http://abklatschsammlung.ub.uni-koeln.de/

Die Sammlung Gertrud von Le Fort unter http://lefort.ub.uni-koeln.de/

Die H. C. Artmann-Sammlung Knupfer unter http://artmann.ub.uni-koeln.de/

Insgesamt haben wir allein im USB-Bestand schon mehr als 30 Sammlungen mit Selektionskriterien identifizieren und in eigene Kataloge der KUG-Plattform einspielen können. Dazu kommt zukünftig noch eine unbestimmte Anzahl aus der Universität. Für diese Sammlungen werden wir in den nächsten Tagen und Wochen sukzessive eigene Portale aufbauen und freischalten.

Der TicTocs Journal Tables of Contents Dienst wurde konsortial unter Führung der University of Liverpool Library erschaffen, um den Nutzern mit wenig Aufwand eine Übersicht der zuletzt in einer Zeitschrift veröffentlichten Artikel zu geben. Der Nutzer sucht zunächst nach den ihn interessierenden Zeitschriften und kann diese dann mit nur einem “Tic” anhaken und dauerhaft abonnieren.

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.

Ein bekanntes Problem der Zusammenführung vieler Katalogbestände unter einer Rechercheoberfläche – egal, ob als klassische föderierte Suche oder als Suchmaschine mit einem/mehreren Indizes realisiert – ist für den Nutzer die z.T. hohe Heterogenität der erfassten Daten und ihrer inhaltlichen Erschließung. Dazu gehört z.B. die Vergabe von Medientypen, die Systematisierung oder die Verschlagwortung. Daher besteht eine der zentralen Aufgaben in der Architektur und den Funktionen eines Recherche-Portals gerade darin, hier konkrete Lösungen zu finden, um dieser Heterogenität einigermaßen Herr zu werden – und vielleicht sogar einen Nutzen daraus zu ziehen. Kurz gesagt also nichts weniger, als auf Grundlage der zur Verfügung stehenden Daten möglichst automatisiert eine Homogenität zu erzeugen, wo ürsprünglich eigentlich gar keine ist.

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.

Im Bestreben die Digitalisate von Wikisource – jenseits des schon erfolgten Nachweises im KUG – für unsere Nutzer noch einfacher zugänglich zu machen, haben wir die Idee von Jakob Voss, diese über den DFG-Viewer zu erschließen, weiter verfolgt und nun für den KUG umgesetzt.

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.

Im Artikel Nachweise freier Inhalte in den OPAC hatte ich vor knapp 2 Monaten bereits Überlegungen angestellt, dass man die Inhalte von Wikisource für die Recherchen der Nutzer in einem OPAC erschließen könnte.

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.

Mit dem Modul mod_perl wird der Interpreter der Programmiersprache Perl persistent in den Apache Webserver eingebettet. Dadurch ist es möglich in alle Verarbeitungsphasen des Apache Webservers über Programme in der Sprache Perl einzugreifen. Perl-Programme können Apache damit quasi beliebig erweitern und werden – einmal beim Start in ausführbaren Code übersetzt – selbst Teil des Apache. Der durch die Einbettung entfallende Fork beim Aufruf eines (ehemals üblichen CGI-)Programms und die Startup-Zeit für eine Webanwendung entfallen fast vollständig. Diese tiefgehende Integration in den Webserver und die hohe Performanz ermöglichen erst die Erstellung komplexer und performanter Webanwendungen im Unternehmens- sowie Universitäts-Umfeld mit Perl.

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.

Bei der Entwicklung des KUG ist – analog zur Vernetzung gleichgesinnter Nutzer im Web 2.0 – die Vernetzung der Titel im Katalog eines unserer Hauptziele.

Nachdem ein Nutzer durch seine Suchanfrage bei einem passenden Titel gelandet ist, kann er sich von dort durch Empfehlungen, Literaturlisten, Tags, Personen, Schlagworte, Systematiken usw. thematisch treiben lassen und so auf andere interessante Titel stoßen – frei nach dem beluga-Zitat: Ich möchte auch finden, was ich gar nicht gesucht habe.

Eine zentrale Rolle nimmt hier die Systematisierung der Titel ein – sowohl um andere Titel eines Themengebiets zu finden, als auch zur Bereitstellung eines hierarchischen Browsings über Themengebiete.

Gerade im KUG mit seinen vielen teilnehmenden Instituten hat sich das jedoch als ein Problem herausgestellt, denn nur ein Bruchteil der Institute systematisiert überhaupt ihre Titel. Dazu kommt dann noch ein genereller Nachteil an Systematiken: Es gibt so viele davon – und diese finden tatsächlich bei den wenigen systematisierenden Katalogen im KUG auch Anwendung.

Die Universitäts- und Stadtbibliothek Köln (USB) verwendet z.B. die Basisklassifikation BK, das eine Institut die DDC, das andere die RVK, wieder eines eine fachspezifische Klassifikation aus Saarbrücken. Selbstverständlich wird dadurch eine katalogübergreifende Einheitlichkeit, vor allem auch im Interesse der Nutzer, nicht gerade gefördert. Aus meiner Sicht sollte das aber gerade ein zentrales Ziel für einen Katalog höherer Zählung sein.

Für die Vereinheitlichung haben wir uns für den KUG erst einmal auf die Basisklassifikation BK geeinigt – nicht zuletzt weil der große USB-Katalog sofort als Fremddatenquelle genutzt werden kann – und reichern über unsere zentrale Anreicherungsdatenbank alle Kataloge im KUG automatisch damit an. Das Schöne an der BK ist, dass

• sie recht überschaubar ist. Geordnet in zwei Hierarchie-Ebenen kommt man in der zweiten Ebene derzeit auf etwa 2086 Gebiete. Diese Hierarchisierung kommt auch den Nutzern zugute.
• für alle BK’s ausführliche Beschreibungen verfügbar sind und auch angezeigt werden. Dazu  haben wir eine YAML-Datei mit den Beschreibungen erstellt, die wie alle Teile von OpenBib gerne nachgenutzt werden kann.
• auch die Möglichkeit von Fremddatenübernahmen existiert.

Als allgemeine Voraussetzungen für den Einsatz einer Systematik für einen Katalog 2.0 sehe ich nach den Erfahrungen im praktischen Einsatz mit der BK beim KUG:

• Sie sollte hierarchisch sein. So kann sie vom Nutzer auch über einen Browsing-Einstieg angeboten werden.
• Sie sollte übersichtlich sein. Es macht keinen Sinn, wenn im Extremfall alle real existierenden abermillionen Themen eine Entsprechung in der jeweiligen Systematik finden.
• Neben kryptischen Themenkürzeln soll auch immer eine grobe Beschreibung des Themengebiets ausgegeben werden. Kein Nutzer kann etwas mit 12.34 oder 123.456 anfangen.
• Es sollten Möglichkeiten der Fremddatenübernahme existieren, bzw. Mappings von anderen Systematiken

Die aber wirklich zentrale Grundvoraussetzung für den Einsatz ist jedoch die vollkommen freie Nutzung der Systematik (genauer: free as in free speech and not free beer). Es macht z.B. keinen Sinn Open Access zu fordern und bei der Erfassung eines Open Access-Werkes dann aber eine proprietäre Systematik zu verwenden, bei der irgendwelche Nutzungsmöglichkeiten erst lizensiert (und bezahlt) werden müssen – wenn sie nicht sowiso grundsätzlich verboten sind.

Gerade hier hat sich im KUG  dann auch ein großes praktisches Problem im Einsatz der DDC herausgestellt.

Zwei der Institute im KUG setzen die DDC lokal ein – nur sagen dem Nutzer die Nummern leider überhaupt nichts (s.o.). Was liegt also näher als bei den Katalogaufnahmen, Quantitäts-Aufschlüsselungen in Wortwolken usw. zusätzlich die textlichen Beschreibungen mit auszugeben – sie vielleicht sogar für die Recherche auch noch zu indexieren. Bei der BK machen wir das, technisch ist das also kein Problem.

Hier kommt nun aber leider der proprietäre Charakter der DDC zum Tragen, der eine vollständige Verwendung der Beschreibungen nicht erlaubt. Maximal die ersten drei Stellen sollen möglich sein. Vor dem Hintergrund, dass die DDC in ihren Toplevel-Kategorien jedoch nur den Wissensstand des 19. Jahrhunderts widerspiegelt – unsere beiden Institute aber im Bereich Informationstechnologie angesiedelt sind und die DDC-Kodierungen dieser Themengebiete dementsprechend lang sind – dürfen wir die Beschreibungen also erst gar nicht ausgeben. Viele sehen daher die DDC als “no go” an und suchen nach Alternativen.

Ein interessanter Vorstoß ist in diesem Zusammenhang die Open Shelves Classification (OSC), die auf einen Vorschlag von Tim Spalding zurück geht – auch wenn der Fokus hier mehr auf öffentlichen und nicht unbedingt wissenschaftlichen Bibliotheken liegt. Auch hier war die Lizenzproblematik der DDC ein wesentlicher Ausgangsgrund. Tim Spalding’s Anwort auf einen negativen Kommentar zum o.g. OSC-Blogeintrag sagt eigentlich alles:

Mr. Ronald, I note that you omitted all mention of “free.” This is at the core of the project’s goals. I—and many others—object to public libraries being constrained by a classification system that is (1) copyrighted, (2) trademarked, (3) licensed, (4) expensive. You cannot with safety make changes to DDC and circulate them around to other interested libraries—this would violate both copyright and trademark. (Some have done so, admittedly.) You cannot publish detailed schedules for your patrons to understand your system and how it maps to your books—again, copyright and trademark. You can’t get a full schedule in digital form, but have to subscribe to a “service” that gives it out in dribs and drabs, reinforcing your dependency. OCLC holds the reins so tightly that it famously sued a hotel that dared to number its rooms by DDC, filling them with appropriate books. They even hold trademark on Dewey’s first name.

Ebenso stellt sich natürlich auch immer die Frage, in wieweit sich lokale Themengebiete in anglo-amerikanischen Systematiken wiederfinden – ansonsten wird in wissenschaftlichen Bibliotheken dort vor dem Hintergrund der Aufstellung überwiegend die Library of Congress Classification (LCC) verwendet. Die LCC wiederum ist in ihrer Nutzung wirklich frei, also potentiell auch ein geeigneter Kandidat.

Aber warum unbedingt in die Ferne schweifen? Auch im deutschsprachigen Raum gibt es mit der Basisklassifikation BK (verwendet im GBV, ursprünglich aus den Niederlanden) und der Regensburger Verbundklassifikation RVK (verwendet im BVB) geeignete Systematiken. Bei der BK hat man zwei Hierarchieebenen, wobei in der ersten Ebene mehr Gebiete als in der RVK zu finden sind, sich diese auch nochmal in 5 Gruppen zusammenfassen lassen. Dafür hat die RVK mit ihren Haupt-, Unter- und Feingruppen gleich drei Hierarchieebenen, zu denen dann u.a. noch eine Verschlüsselung des Autorennamens kommt.

Weder die BK noch die RVK muss lizensiert werden, anders als die DDC, und beide erfüllen damit die von mir geforderte zentrale Grundvoraussetzung für einen Einsatz. Es wäre zu begrüßen, wenn beide Klassifikationen gerade im Bereich Katalog 2.0 vermehrt eingesetzt werden – und sich auch aktiv dafür positionieren. Bei einer internationalen Ausrichtung wäre die Auswahl an geeigneten Systematiken sicherlich eine andere und man würde sich u.a. LCC und OSC, wenn letztere denn mal fertig ist, genauer anschauen.

Die proprietäre DDC jedoch – auch wenn sie de facto die am meisten verbreitete Systemtik darstellt – ist aufgrund ihrer Lizenzproblematik nach meinem Dafürhalten nicht geeignet als thematischer Grundpfeiler für einen Katalog 2.0 – gerade weil es dort genau um eine verbesserte Usability des Katalogs geht und die Lizenzbedingungen (und etwaige Kosten) dieser massiv im Weg stehen.

Es wäre interessant zu hören, wie andere das sehen bzw. welche Schritte schon anderenorts in Richtung eines thematischen Zugangs gegangen wurden – und welche Systematiken dort Verwendung finden.

Zur Pflege der Kontakte zwischen den einzelnen IT-bereitstellenden Fachbereichen an der Universität zu Köln und um so die Zusammenarbeit bei den vielen dort durchgeführten Projekten zu fördern, hat unser Regionales Rechenzentrum die Vortragsreihe IT an der Universität zu Köln für das SS 2009 organisiert. Zitat zu den Zielen der Vortragsreihe:

In Lehre, Forschung und deren administrativem Umfeld spielt die Informationstechnologie eine immer wichtigere Rolle. Im Kolloquium “IT an der Universität zu Köln” soll die Vielfalt der diesbezüglichen Einsatzgebiete, Angebote und Forschung widergespiegelt werden. Die Vorträge von Anwendern, IT-Diensteanbietern und Forschenden werden die Informationstechnologie an der Universität zu Köln vorstellen und sollen zur Bildung eines integrierten Informationsmanagements beitragen. Die Vortragsreihe wendet sich an alle Angehörigen der Universität.

Mit dem KUG als zentralem Recherche-Portal für die Literaturbestände an der Universität (und darüber hinaus…) habe ich am 24.6.2009 dort einen Vortrag über den KUG gehalten. Nach ein paar allgemeinen Worten zu den Hintergründen gab der Vortrag einen ganz guten Überblick davon, wo sich der KUG gegenüber einem normalen Recherche-Katalog unterscheidet, wie er mit dem WebOPAC an der USB und vielen anderen Institutionen als Einzel-OPAC noch sehr oft eingesetzt wird. Darüber hinaus wird dort auch nochmal die dafür konkret eingesetzte Technik – Hardware und Software-Infrastruktur inklusive OpenBib – skizziert.

Weitere Vorträge zum KUG können Sie ebenso auf meiner USB-Homepage finden.

In der vergangenen Woche habe ich im Artikel Nachweise freier Inhalte in den OPAC bereits davon berichtet, dass wir über Möglichkeiten der Integration von Nachweisen der Digitalisate des Internet Archivs in den KUG nachdenken.

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…