Entsprechend einer Mail von Lukas Rieder stellt PaperC nun einen CSV-Export mit rudimentären Metadaten aller dort verfügbaren E-Books unter

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!

Manchmal verwundert es, warum sich die eine oder andere Web-Anwendung oder -Seite so langsam, geradezu zäh “anfühlt”. Für Kataloge gilt das gleiche.

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.

Schon beim Bibliothekskongress in Leipzig war ein sehr positives Echo auf die Freigabe der Katalogdaten zu vernehmen. Oft wurde ich darauf angesprochen und in den vielen Gesprächen, die ich dort geführt habe, wurde unser Schritt durchweg begrüßt. Sicherlich muss zukünftig aber dennoch weitere Überzeugungsarbeit geleistet werden, um auch andere Bibliotheken von den Vorteilen der Daten-Öffnung zu überzeugen.  Sie ist eine fundamentale Voraussetzung dafür, dass die hochwertigen Bibliotheksdaten wirklicher intergraler Teil des Netzes im Semantic Web werden können und damit die Nutzer auch ausserhalb der Bibliothekskataloge und dedezierten Suchanwendungen (neudeutsch Discovery Interfaces) erreichen.

Das generelle Interesse unterstreicht auch die Zahl der insgesamt knapp 1300 Aufrufe unserer opendata.ub.uni-koeln.de-Seite und  die etwas mehr als 800 Aufrufe meines Blog-Artikel in den vergangenen 6 Tagen.

Als einer der Ersten hat Mathias Schindler am 12.3. bei uns die bibliographischen Daten für die Weiterverarbeitung in der deutschen Wikipedia heruntergeladen. Insgesamt waren bisher etwa 1500 Downloads zu verzeichnen. Da wir die Daten aber getrennt nach Normdaten anbieten, andererseits manchmal aber auch nur Interesse an einzelnen Normdaten-Dateien zu bestehen scheint, ist die Anzahl der  Komplettabzüge entsprechend geringer und liegt bei uns in der USB schätzungsweise zwischen 300 und 400. Zahlen aus dem hbz – 600 Downloads am ersten Tag – hatte bereits Felix Ostrowski in einem Blog-Kommentar genannt.

Auch in der Blogsphäre – und anderswo – hat sich die Kunde von der Öffnung der Daten entsprechend verbreitet – und das sowohl national wie international. Ich habe hier einige Meldungen gesammelt:

• Bundestagsfraktion Bündnis 90/Die Grünen: Öffentliches Wissen sinnvoll verknüpfen
• heise online – Open Access: Bibliotheken geben Katalogdaten frei
• D: Freiheit für Bibliotheksdaten – futurezone.ORF.at
• Stuttgarter Zeitung: Bibliotheken bieten neuen Service rund um das Buch
• Open Knowledge Foundation Blog » Blog Archive » Libraries in Cologne open up bibliographic data!
• Informationsplattform Open Access: USB Köln: 3,1 Millionen freie Bibliografische Daten
• Open Content Alliance (OCA) » Blog Archive » Going Open
• Endlich freie bibliografische Daten aus Bibliotheken! « Jakoblog — Das Weblog von Jakob Voß
• KoopTech » Titelgeschichte » Kölner Bibliotheken öffnen Katalogdaten
• KoopTech » Inspiration Wissensmanagement » Neuigkeiten aus dem Schwarzen Loch
• Freigabe der Katalogdaten: Kölner Bibliotheken leisten Pionierarbeit | Gemeingüter
• buchreport: Kölner Bibliotheken geben Katalogdaten frei -
  Bibliothekskatalog zum Download
• Endlich (wirklich) freie Katalogdaten – jurabilis – juristisches Weblog aus Berlin
• Kataloge deutscher Bibliotheken zur freien Nutzung im Internet – datensicherheit.de Informationen zu Datenschutz und Datensicherheit (Vorsicht: Ungewünschte Popups)
• Luxcommons » Blog Archive » Libraries make available 5.4 million bibliographic records under CC Zero
• Kölner Bibliotheken geben ihre Katalogdaten frei « Nachrichten für öffentliche Bibliotheken in NRW
• Library Automation News: Releasing catalogue data: Cologne-based libraries to pioneer Open Data practices
• netbib weblog » Offene bibliographische Daten
• Several Libraries in Germany Make Their Bibliographic Data Open Access « ResourceShelf
• Open Access: Bibliothekskataloge veröffentlicht | Open Data Network
• Archivalia: Endlich: Open Access auch für bibliographische Daten in Deutschland (einige Datenbestände)
• VÖB BLOG (verschiedene Meldungen)

Auf Twitter sieht es ähnlich aus – viele, viele Tweets. Im anglo-amerikanischen Raum waren dabei insbesondere die Blog-Artikel der Open Knowledge Foundation und der Open Content Alliance große Multiplikatoren.

Der Abzug der offenen Daten vom hbz-Server ist bereits im Internet Archiv selbst archiviert (Internet Archive: Free Download: Cologne Linked Open Data) und wird von dort daher sicherlich zukünftig in die Open Library integriert. Mit der Wikipedia und dem Internet Archiv (mit OpenLibrary) haben damit bereits in kürzester Zeit zwei wichtige Dienste im Netz unsere Daten abgeholt, um sie in ihren Projekten für die Allgemeinheit möglichst nutzbringend zu verwenden.

Inzwischen hat das hbz auch eine eigene offizielle Projektseite für die offenen Daten eingerichtet:

http://opendata.hbz-nrw.de/

Bezeichnend war ein Kommentar, auf den ich bei futurezone vom ORF in Österreich gestoßen bin:

Und das schon 2010: Die Bibliotheken sind aufgewacht! Guten Morgen im Jahre 2010. Soetwas gibt es auch nur im geschützten Bereich.

Die Zeit ist nicht nur reif, sie ist überfällig!

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

Schon seit einiger Zeit wird im Bibliotheksbereich laut über die Freigabe der bibliographischen Daten als (Linked) Open Data nachgedacht – zuletzt in größerem Rahmen bei der SWIB09 im Kontext des Semantic Web. Kein anderer als der “Erfinder” des Web, Tim Berners Lee, propagierte schon vor einigen Jahren die Freigabe von Daten, zunächst als Roh-Daten, dann beschrieben durch Web-Standards, um sie zum integralen Teil des Webs zu machen. Diese Daten – oder Teile davon – können dann vielfältig genutzt und kombiniert werden – in Anwendungsgebieten, an die man selbst mit seinen Daten eventuell noch gar nicht gedacht hat. Adrian Pohl hat die Thematik der Freigabe bibliographischer Daten gerade sehr schön in dem Blog-Artikel “Die Zeit ist reif, wir müssen sie nur pflücken” zusammengefasst. Und diese Zeit ist nun endlich gekommen.

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

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

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

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

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

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

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

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

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

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

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

CC zero als Lizenz/Waiver der Wahl

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

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

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

Ich denke 2010 wird ein sehr spannendes Jahr!

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

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

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

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

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

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

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

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

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

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

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

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

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.