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

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

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

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

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

http://paperc.de/9780596002060.json

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

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

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

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

Konkret verwenden wir nun diesen Abschnitt im Template

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

anstelle von

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Expires

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

Bei Apache 1.3 geht das mit mod_expire und den Direktiven

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

Bei lighttpd mit:

server.modules   += ( “mod_expire” )

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

Komprimierte Auslieferung

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

Bei Apache 1.3 geht das sehr einfach mit mod_gzip:

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

Entsprechendes geht bei lighttpd mit mod_compress und

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

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

ETags

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

In Apache 1.3 geht das mit:

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

Entsprechend in lighttpd:

static-file.etags = “disable”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hier nun zwei konkrete Beispiel im KUG.

Zunächst die Zeitschrift Remote Sensing

und danach die Zeitschrift Nature

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

Update 21.12.2009:

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

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

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.

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.

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…

Auch viele unserer InstitutsbibliothekarInnen nutzen aktiv die vom KUG bereitgestellten Funktionen. Dies beginnt z.B. mit der Veranschaulichung des eigenen Bestandes durch schlagwortspezifische Wortwolken und endet mit eigens für die Studierenden eingerichteten fachspezifischen Literaturlisten, die zusätzlich über PermaLinks in eLearning-Plattformen eingebunden werden.

Zu unserer Überraschung werden diese erweiterten Funktionen von einigen unserer InstitutsbibliothekarInnen jedoch auch entschieden missbilligt. RSS Feeds für Neuzugänge? Neumodischer Schnickschnack, den sowiso niemand nutzt. Tagging? Wir machen das eh besser. Literaturlisten? Zu subjektiv. Wikipedia? Unwissenschaftliches Teufelswerk. Und schließlich Coverbilder – braucht kein Mensch.

Auf den Punkt gebracht scheinen sich einige schlicht mit den neuen Funktionen überfordert zu fühlen, andere lehnen sie kategorisch ab. Mir klingen noch Jesse Ephraims Worte auf der NGC4LIB-Liste im Ohr, aber auch diese – Neuerungen ablehnende – Einstellung muss von uns selbstverständlich respektiert werden. Daher macht es durchaus Sinn, solche Strömungen zu integrieren und letztlich auch zu bedienen.

Das machen wir seit letzter Woche im KUG. Seither haben die Institute die Wahl, ob sie für ihre institutsspezifischen Sichten, in denen insbesondere ihr jeweiliger Katalog vorausgewählt ist, den normalen KUG haben möchten oder aber eine um jegliche weitergehenden Funktionen entschlackte Version – den neuen KUG light.

Ermöglicht wird dies über die von OpenBib bereitgestellte Kaskadierung von Templates in Verbindung mit systemweiten Katalogprofilen, nach denen kaskadiert wird. Jede (Instituts-)Sicht ist genau einem Katalogprofil zugeordnet. Damit lassen sich verschiedene Sichten gruppieren und mit alternativen Templates bestücken. Neben dem normalen Profil KUG gibt es dort nun ein neues Profil KUG light. Über die Webadministration kann mit einem Klick die Zuordnung einer einzelnen Sicht zu einem Profil geändert werden. Damit stellt diese neue Wahlmöglichkeit der Institute auch für uns keinen sonderlichen Mehraufwand dar.

Die Zahl der Templates, die für den KUG light geändert werden musste, ist ebenfalls sehr überschaubar. Lediglich 12 Basis-Templates wurden hierfür entsprechend angepasst. Der Rest wird weiterhin aus dem Pool der Standard-Templates verwendet.

Mit dem gleichen Mechanismus arbeiten wir derzeit auch an einer visuell überarbeiteten nächsten KUG-Version mit verbesserter Nutzerführung, die intern mit dem Kürzel kugng (=KUG next generation) versehen ist und auf die man bereits jetzt einen ersten Blick über die gleichnamige Sicht werfen kann.