OpenBibBlog

Das Blog zu OpenBib und OPAC 2.0
Optionen:

Bereits seit 2008 werden andere Ausgaben, also andere Auflagen und Sprachversionen einer Titelaufnahme im KUG ausgegeben. Die Integration war damals sehr einfach möglich, da die Bücher-Plattform LibraryThing, deren Nutzer diese Art von Information intellektuell erfassen, alle ihre diesbezüglichen Daten kostenfrei als Feed in der Datei thingISBN.xml.gz zur Verfügung gestellt hat.

Leider wurden diese Daten von LibraryThing immer seltener aktualisiert – die letzte Datenlieferung datiert von Herbst 2012. Ebenso waren dort keine der von uns erworbenen E-Book-Ausgaben enthalten. Grund genug, sich diesem Thema noch einmal intensiver zuzuwenden und nach Verfahren zu suchen, um diese Titelverknüpfungen selbst automatisch – idealerweise in Echtzeit – zu bestimmen.

Durch die Integration von BibSonomy in den KUG haben wir bereits Erfahrungen im Titel-Fingerprinting über sog. BibKeys sammeln können. Beim Bibkey werden zur Erstellung des bibliographischen Fingerabdrucks die Informationen aus den Feldern für Verfasser/Personen, (Hauptsach)Titel sowie Erscheinungsjahr normiert, kombiniert und dann mit einer kryptographischen Hash-Funktion verkürzt. So kann schnell bestimmt werden, ob ein Titel des KUG auch in BibSonomy enthalten ist und umgekehrt.

Dieses Verfahren haben wir als Grundlage genommen und für den neuen Anwendungsfall  angepasst.

Bei der Bestimmung anderer Ausgaben muss ein unschärferer Titel-Fingerabdruck als beim BibKey verwendet werden, da hier gerade keine identischen Titel bestimmt werden sollen.

Welche Fälle sind dabei zu bedenken?

  • Die Autorenschaft kann sich verändern, indem Autoren dazukommen oder verschwinden
  • Die Titelaufnahme kann von einer Auflage zur nächsten den Verlag oder gar den (Hauptsach)Titel wechseln
  • Auflageninformation können schwer zu bestimmen sein, wie z.B. ‘2. Nachdruck der 3. Auflage’

Nicht für alle diese Fälle gibt es Lösungen, wie z.B. bei Änderungen des (Hauptsach)Titels, da – wenn überhaupt – entsprechende Informationen lediglich in Fußnoten abgelegt werden und sich nicht maschinell zuverlässig verarbeiten lassen.

Dennoch lassen sich auch so sehr gute Ergebnisse erzielen. Dazu gehen wir zweigleisig vor, da die Aufgabe nicht nur darin besteht

  1. zu einer Titelaufnahme die Menge aller verschiedenen Auflagen zu bestimmen, sondern auch
  2. die Eingrenzung auf die “anderen Auflagen” ausgehend von einer konkreten Titelaufnahme

Zusätzlich müssen wir auch Seiteneffekte der Katalogisierung nach RAK bedenken, die in der Auftrennung der Titelinformationen in verschiedene Hierarchieebenen begründet sind. Nach unserer Erfahrung haben wir es mit einer “ordentlichen”  Titelaufnahme zu tun, wenn alle BibKey-relavanten Informationen – Verfasser/Person, (Hauptsach)Titel und Erscheinungsjahr – in einer Titelaufnahme besetzt sind. Nur solche “ordentlichen” Titelaufnahmen verarbeiten wir im Folgenden.

Um die Menge aller Auflagen zu einer Titelaufnahme bestimmen zu können, konstruieren wir in Anlehnung an den BibKey normierte Zeichenketten für eine Titelaufnahme. Wegen der benötigten Unschärfe verwenden wir hierzu lediglich die Kategorien für Verfasser/Person und Hauptsachtitel sowie Einheitssachtitel (für andere Sprachversionen) . Allerdings bilden wir wegen des Problems wechselnder Autorenschaft sowie verschiedener Sprachversionen nicht nur einen “WorkKey” für eine Titelaufnahme, sondern mehrere. So besteht ein WorkKey immer nur aus einem Verfasser bzw. einer Person sowie einer Titelkategorie – Hauptsachtitel oder Einheitssachtitel. Bei einer Titelaufnahmen mit 2 Verfassern und sowohl vorhandenem Hauptsachtitel wie auch Einheitssachtitel werden also 4 WorkKeys gebildet. Eine Erweiterung um zusätzliche Titel-Kategorien wie AST oder WST wäre möglich, um noch höhere Identifizierungsquoten zu erreichen. Aber auch ohne diese zusätzlichen Kategorien sind die von uns beobachteten Resultate bereits sehr gut.

Um die “anderen” Auflagen bezogen auf die aktuelle Titelaufnahme auf der mit dem WorkKey bestimmten Titelmenge bestimmen zu können, benötigen wir eine zusätzliche Information über die Auflage. Gleichzeitig müssen Sprache und Publikationform (print/online) damit unterscheidbar sein.

Während die Publikationsform online noch sehr einfach über den Zugriffsstatus in der (vorher angereicherten) Kategorie T4400 zu bestimmen ist, wird dies bei der Auflagenbezeichnung und der Sprache schon schwieriger.

Bei der Auflagenbezeichnung ist zwischen

  • dem Problem der Bestimmung der korrekten Auflage aus dem Kategorieinhalt von T0403 (2. Nachdruck der 3. Auflage) und
  • dem Problem verschiedener Auflagen im selben Jahr

abzuwägen. Dementsprechend würde man entweder die Zahl der Auflage aus T0403 oder das Erscheinungsjahr aus T0425 bzw. T0424 verwenden. Wir haben uns erst einmal für die Jahreszahl aus Charakteristikum für die Auflage entschieden.

Die Sprache, in der ein Titel erschienen ist, kann leider häufig nicht in der Titelaufnahme gefunden werden. Das ist bereits bei der Facettierung nach Sprache ein Problem. Deshalb haben wir bereit seit einiger Zeit eine Spracherkennung auf Grundlage linguistischer Methoden mit dem Perl-Modul  Lingua::Identify::CLD integriert (Nutzung der Spracherkennung des Chrome-Browsers), falls keine Sprache in der Titelaufnahme erfasst wurde. Dieses Verfahren haben wir für die Bestimmung der verallgemeinerten Auflagenbezeichnung durch eine Analyse des Sprach- bzw. Ländercode in der ISBN erweitert. Beispielsweise kennzeichnet der ISBN-Anfang 9780 bw 9781 englische, 9872 französische und 9873 deutsche Titel. Zwar kann auch hier der Fall auftreten, dass ein deutscher Verlag ein englischsprachiges Buch herausbringt, aber die Auswirkungen sehen wir als nicht gravierend an.

Beispiel 1

Anhand des Titels “Programming perl” von Tom Christiansen, Larry Wall und John Orwant in der 3. deutschen Auflage aus dem Jahr 2001 wird die konkrete Vorgehensweise veranschaulicht.

In der ersten Stufe werden die Basis-WorkKeys anhand der belegten Titelkategorien mit der Funktion gen_workkeys bestimmt und in der Titelkategorie T5055 abgelegt. Dieser hat die Form “WorkKey <Auflage>” und enthält zwei Anteile, den eigentlichen WorkKey und eine verallgemeinerte Auflagenbezeichnung in spitzen Klammern. Im konkreten Fall werden folgende Basis-WorkKeys generiert:

  • programmingperl [l.wall] <2001ger>
  • programmierenmitperl [l.wall] <2001ger>
  • programmingperl [t.christiansen] <2001ger>
  • programmierenmitperl [t.christiansen] <2001ger>
  • programmingperl [j.orwant] <2001ger>
  • programmierenmitperl [j.orwant] <2001ger>

Für alle Kataloge werden diese Informationen durch das Programm update_all_isbn_table.pl selektiert und in einer speziellen Tabelle all_titles_by_workkey unserer zentralen Anreicherungsdatenbank abgelegt. In dieser Tabelle werden WorkKey und verallgemeinerte Auflagenbezeichnung getrennt und zusammen mit Katalogname und -ID eines jeden Titels abgelegt. Die Bestimmung anderer Auflagen in beliebigen Katalogmengen kann dann – in Echtzeit – für einen Titel bestimmt werden.

Dazu werden zunächst für alle WorkKeys eines Ursprungs-Titels die jeweiligen anderen Titel gesucht, die den gleichen WorkKey besitzen. Aus dieser Menge werden dann jene Titel selektiert, deren verallgemeinerte Auflagenbezeichnung sich vom Ursprungs-Titel unterscheidet. Zusätzlich wird eine absteigende Sortierung nach den Auflagenbezeichnungen vorgenommen, so dass aktuellere Auflagen am Anfang ausgegeben werden.

Beispiel 2

Beim zweiten Beispieltitel handelt es sich um ein Buch, dass sowohl in Print-Form vorliegt als auch frei im Netz. Es ist die erste Auflage aus dem Jahr 1999, heisst “Open sources” und wurde von Chris DiBona und Sam Ockman geschrieben. Hier sind die Basis-WorkKeys in 5055:

  • opensources [c.dibona] <1999engonline>
  • opensources [s.ockman] <1999engonline>

Zusätzlich zum Erscheinungsjahr und der Sprache wird hier auch noch der Publikationsstatus online hinzugefügt.

Fazit

Mit relativ wenig Aufwand konnten wir die Unzulänglichkeiten der bisherigen Bestimmung der anderen Auflagen eines Titels beseitigen. Das beschriebene Verfahren kann an verschiedenen Stellen noch weiter optimiert werden. So könnten durch ein mehrstufiges Suchverfahren – gerade bei nicht durchgängig besetzten Einheitssachtiteln – noch mehr infrage kommende Titel in anderen Auflagen bestimmt werden. Allerdings muss immer gewährleistet sein, dass der zusätzliche Zeitaufwand für den Endanwender noch hinreichend responsiv bleibt.

 

 

 

Nachweise von E-Books dank Open Data

Nichts ist ärgerlicher als teuer lizensierte E-Book-Pakete, die für den Nutzer mehr oder weniger unsichtbar sind. Ein Beispiel hierfür sind die E-Books des Pakets Nomos online Premium von der Beck-Online-Plattform. Anders als z.B. das Beck-Online Hochschulmodul wird dieses nicht im hbz erfasst und ist damit nicht automatisch in unserer lokalen Recherche-Infrastruktur für USB-Portal und KUG auffindbar. Ebenso ist das Paket nicht in dem von uns lizensierten Dienst EBSCO Discovery Search enthalten. Lediglich in Beck-Online.beck.de selbst können die E-Books recherchiert werden. Das ist alles andere als optimal.

Aus diesem Grund sind wir an Beck herangetreten, um von dort idealerweise die Metadaten der von uns lizensierten E-Books des Pakets zu erhalten, aber leider kann uns Beck diese Daten für den Nachweis nicht liefern. Normalerweise wäre hier jetzt – bis auf Selbstkatalogisieren – Schluss und wir müssten uns in unser Schicksal fügen.

Eine kurze Google-Recherche lieferte jedoch eine sehr informative Webseite des SWB, in der weitergehende Informationen über die Beck’schen Pakete zu finden sind. Demnach hat der SWB bereits damit begonnen, die Nomos-Titel unter dem Kennzeichen ZDB-18-NOI in seinem Verbundkatalog zu erfassen.

Da der SWB wie auch das hbz, heBIS und BVB/KOBV bereits seinen Verbundkatalog als Open Data freigegeben hat, waren diese Katalog-Dumps unser neuer Ansatzpunkt. Sind die Linked Open Data-Dumps für die Erstellung eines eigenen Recherchekatalogs wegen der z.T. verschiedenen verwendeten Ontologien weniger geeignet, bietet der SWB die Daten auch in MARC-XML an.

Nach der Selektion der betreffenden Records mit einem kleinen Program, war es danach sehr einfach möglich, daraus einen eigenen Katalog nomos zu erstellen und in unsere Recherche-Infrastruktur einzubringen. Die ersten Nomos-Titel waren in der SWB-Update-Lieferung von Juli 2014 zu finden, so dass erst ab diesem Zeitpunkt die SWB-Daten sukzessive extrahiert werden müssen.

Der neue Katalog nomos ist seit gestern im USB-Portal und dem KUG freigeschaltet und kann nun – wie alle anderen Nachweise auch – recherchiert werden.

Beispiel:

http://www.ub.uni-koeln.de/usbportal?query=nomos:282602623

bzw.

http://kug.ub.uni-koeln.de/portal/kug/databases/id/nomos/titles/id/282602623.html?l=de

Diese schnelle Integration relevanter Bestände wäre ohne die Öffnung der Daten von Verbund-  sowie einzelner Bibliothekskataloge so nicht möglich gewesen und demonstriert sehr eindrucksvoll welchen praktischen Mehrwert sich aus der Open Data-Bewegung ziehen lässt.

Zur schnellen Nachnutzung haben wir die extrahierten bibliographischen Daten des E-Book-Pakets im MAB2-basierten JSON-Format abgelegt unter

http://opendata.ub.uni-koeln.de/dumps/ZDB-18-NOI/

CIB vs. libOS – Eine Analyse

Analog zu Christian Hauschkes “Operation Frühjahrsputz” einige Gedanken, die ich im April 2013 kurz nach der DFG-Entscheidung zusammengefasst hatte, aber die bisher im Blog auf Halde lagen.

Mit der Bewilligung des CIB-Antrages von HeBIS, KOBV und BVB im Bereich “Neuausrichtung überregionaler Informationsservices” durch die DFG wurde eine weitreichende Weichenstellung für die zukünftige deutsche Bibliothekslandschaft getroffen. Das alternative Konzept libOS von hbz, GBV, SWB und DNB hat die DFG augenscheinlich nicht überzeugen können. Vereinzelt sind bereits Reaktionen auf die Entscheidung gefolgt, wie z.B. die Analyse des CIB-Antrages durch Adrian Pohl, eine große Diskussion darüber in der betroffenen bibliothekarischen Fachöffentlichkeit findet aber – an der Durchschlagskraft der DFG-Entscheidung gemessen – derzeit nur ansatzweise auf InetBib statt.

CIB

Kurz gefasst wird im CIB-Antrag der Weg zu einem internationalen Verbund von kommerziellen Cloudsystemen der Anbieter OCLC und ExLibris skizziert, der auf die deutsche nationale Bibliothekslandschaft heruntergebrochen und durch die antragstellenden Verbünde geregelt vollzogen werden soll. Dabei soll u.a. möglichst viel Offenheit und Gestaltungsmöglichkeiten bei den Anbietern herausgehandelt werden. Grundlage sind verschiedene Prognosen:

  • Die Katalogisierung wird in internationalen Verbünden stattfinden
  • Die Cloudlösungen können für lokale Belange auf Deutschland-Ebene heruntergebrochen werden via Schnittstellen oder Abzug
  • Die Verbund- und Lokalsysteme verschmelzen im Cloudsystem

Auch wenn ich diesen Weg für bedenklich halte, so ist nach meiner Einschätzung das präsentierte Konzept auf den ersten Blick in sich durchaus stimmig und umfassend, gerade wie es die Zukunft von Lokal- und Verbundsystemen und die Konsequenzen skizziert. Allerdings sind viele grundlegenden Annahmen sehr schwammig und zu euphemistisch, wie z.B. zu offenen APIs, Datenschutzanforderungen, Linked (Open) Data (man beachte: mit Klammen um Open) usw. Die wesentlich zu leistende Arbeit im Antrag besteht darin, die beiden Hersteller-Clouds miteinander vertraglich und technisch zu verheiraten und synchronisieren, so dass bestehende nationale Dienste (Fernleihe, Datenanreicherungen, usw.) weiterhin funktionieren können sowie – laut Antrag – den “technischen, organisatorischen, finanziellen und (datenschutz)rechtlichen Übergang” zu gestalten.

libOS

Demgegenüber soll mit libOS technisch und organisatorisch eine vollständig offene und herstellerunabhängige deutschlandweite Erschließungs- und Nachweisplattform für bibliographische Daten  geschaffen werden, die von den beteiligten Verbünden anteilig entwickelt und betrieben wird. Damit sollen dann Endnutzer und Bibliothekssysteme versorgt werden. Durch die Bereitstellung von Basisdiensten sollen komplexe Abläufe und Anwendungen realisiert werden können. Die Informationsversorgung verbleibt explizit in öffentlicher Hand.

Anders als CIB setzt libOS auf eine Optimierung der Zusammenarbeit der Katalogisierungszentren mit dem Ziel einer einheitlichen nationalen Infrastruktur und nicht auf eine de-facto Abschaffung der bestehenden Informationsstrukturen. Technisch kann libOS auf bereits bestehende eigenentwickelte und offene Plattformen, wie CultureGraph, zurückgreifen. Bemerkenswert bei libOS ist aus meiner Sicht, dass die beteiligten Verbünde das Wagnis eingehen die neue Infrastruktur selbst in Kooperation zu erschaffen, während CIB lediglich das bestehende System “abwickelt” und in kommerzielle Cloud-Strukturen überführt.

Probleme mit CIB

Bezogen auf den CIB-Antrag sehe ich gerade die Herstellerabhängigkeit als zentrales Problem. Viele vergessen vielleicht, dass es diese Abhängigkeit bereits jetzt schon gibt. Denn bisher stellen dieselben Hersteller auch die jeweiligen Verbund- und einen Großteil der universitären Lokalsysteme. Das ist auch grundsätzlich kein Problem. Wenn die jeweiligen Systeme die Anforderungen besser als andere (auch Open Source-Systeme) erfüllen, spricht nichts dagegen, dass das jeweilige kommerzielle System angeschafft wird.

Der wesentliche Unterschied ist jedoch, dass im bisherigen Ist-Zustand der Betrieb und die Datenhaltung der deutschen Verbundsysteme in öffentlicher neutraler Hand war und dieser zukünftig in die private Hand der beiden Cloud-Anbieter überführt werden soll, die potentiell auch von Eigeninteressen geleitet sein könnten.

Folgen ergeben sich auch für die Verbünde, da die neuen Cloudsysteme bereits selbst Verbundsysteme sind. Durch ihren Einsatz werden in letzter Konsequenz alle deutschen Verbünde überflüssig – wenn im CIB-Antrag auch nur von den Verbundsystemen gesprochen wird:

Die Arbeit in dieser internationalen Infrastruktur macht die herkömmlichen regionalen Verbunddatenbanken entbehrlich, sie können nach einer Übergangsphase abgeschaltet werden. Ebenso ist eine eigenständige nationale Katalogisierungsumgebung für deutsche Bibliotheken funktional nicht mehr notwendig.

Darüber können auch nicht die Themenfelder ‘App-Entwicklung’, ‘Lokale Cloud-Knoten’ und ‘regionaler Support’ hinwegtäuschen, die einige Verbünde in diesem Umfeld zukünftig besetzen wollen – und als Überlebensstrategie letztendlich auch müssen.

Nicht minder problematisch ist die Gewährleistung der bisherigen Servicequalität und weitere grundlegende Probleme der kommerziellen Cloudsystem, die ich bereits im Artikel Wieviel Cloud braucht das Land thematisiert habe:

Es ist nachvollziehbar, dass die Hersteller die Entwicklung ihrer jeweiligen Systeme vereinheitlichen, zentralisieren und letztlich unnötige Kosten in Parallelentwicklungen (und Sonderanpassungen für die Bibliotheken ) einsparen möchten. In Bezug auf die vorhandenen Funktionalitäten wird dabei gerne von ‘entschlacken’ gesprochen.

Insofern profitieren die Anbieter zuallererst selbst von einer Cloud-Lösung – wo aber Bibliotheken, Verbünde und deren Nutzer ihren konkreten Mehrwert gegenüber den bestehenden Lösungen ziehen, muss thematisiert und klarer dargestellt werden.

Einen guten Überblick von den Chancen und Risiken von Cloudsystemen hat bereits Herr Diedrichs vom GBV auf dem Bibliothekartag 2012 in einem Vortrag gegeben.

Bei der Überführung eines bestehenden lokalen Bibliothekssystems in das Cloudsystem des jeweiligen Anbieters wird man zukünftig zwangsläufig mit der Vereinheitlichung und Entschlackung konfrontiert werden. Von Hause aus bringen die neuen Cloudsysteme folglich nicht mehr all das mit, was man bisher gewohnt ist und worauf die lokalen Arbeitsabläufe optimiert sind. Gleiches gilt für etablierte lokale Sonderanpassungen.

Gelöst werden soll dieses Problem laut den Anbietern ganz einfach über bereitgestellte APIs,  auf deren Grundlage man dann – einheitlich – Sonderanpassungen erstellen und in der jeweiligen Cloud-Community austauschen kann.

Die entscheidende Frage ist hier aber: Werden die APIs überhaupt so umfangreich sein, dass der Status-Quo gehalten werden kann – einmal abgesehen davon, dass man alles noch einmal selbst programmieren darf und damit effektiv – unbezahlt – für den Anbieter arbeitet und dessen Produkt aufwertet. Aber auch das ist nichts Neues, wandert bibliothekarische Expertise bereits seit Jahrzehnten in Form von Konzepten, Change Requests und Aufträgen aus den Verbünden und Bibliotheken zu den Anbietern. Wäre es nicht vorzuziehen diese Expertise endlich für eigene offene Systeme zu nutzen?

Wie offen werden diese APIs sein? Neben den Bibliotheken wird diese Frage vor allem alle anderen Anbieter konventioneller Bibliothekssysteme interessieren, die an die Cloudsysteme andocken wollen. Ist ohnehin schon von einer gewissen Sogwirkung von anderen Anbietern hin zu den beiden Cloudsystemen auszugehen, so wird dies durch mangelnde Offenheit oder im Fall von Open Source System durch potentielle Lizensierungskosten des APIs weiter verschärft.

Neben der Dienstqualität ist auch die zukünftige Datenqualität ein Problem, wie Prof. Wiesenmüller auf InetBib anmerkt:

Betont wird im CIB-Antrag auch, dass die deutschen Daten ja schon im WorldCat seien. Nun ja – aber man muss doch fragen: In welcher Qualität? M.W. müssen bisher erhebliche Abstriche gemacht werden. Auch hier kann man natürlich hoffen, dass durch das CIB-Projekt alles viel besser wird. Aber was passiert, wenn dies nicht der Fall ist? Müssen wir dann letztlich akzeptieren, was die amerikanischen Partner bereit sind, uns zu geben – einfach, weil wir keine Alternative haben?

Probleme mit libOS

Für die zukünftige Enwicklung der deutschen Bibliothekslandschaft ist meines Erachtens die Entwicklung im Bereich der Lokalsysteme entscheidend. Das ist ein Bereich, der im libOS-Antrag – anders als bei CIB – nach meiner Wahrnehmung nur einen nebenläufigen Charakter hatte. Bei libOS wird davon ausgegangen, dass die Struktur der Lokalsysteme im Wesentlichen so (heterogen) bleibt wie bisher, wenn sie nicht durch Open Source Systeme sogar noch heterogener wird. Davon ist aber nicht auszugehen, wenn die bisherigen Lokalsysteme der grossen kommerziellen Anbieter auslaufen und von Cloudsystemen abgelöst werden.

Es reicht nicht im libOS-Antrag eine offene Katalogisierungsplattform zu erschaffen, wenn sich auf Lokalsystemseite niemand daran andocken kann – denn grundlegende Lokalsystem-Funktionalität stellen im täglichen Routine-Betrieb in deutschen Bibliotheken die Bereiche Ausleihe und Erwerbung dar. Wenn die aktuell etablierten kommerziellen Lokalsystem auslaufen ist es unrealitisch zu erwarten, dass große Universitätsbibliotheken freudig auf ein anderes kommerzielles oder Open Source Lokalsystem, wie z.B. Koha umsteigen werden. Im Hinblick auf den eigenen Betriebsfrieden und den Migrationsaufwand vom alten System ins neue ist sicherlich ein Systemwechsel innerhalb des jeweiligen aktuellen Anbieters deutlich entspannter.

Prognosen

Meine Prognose ist daher ziemlich genau die des CIB-Antrags: Durch die herstellergetriebene Verschmelzung von Lokal- und Verbundsystem werden die Universitätsbibliotheken im Rahmen von typischen Upgrade-Pfaden quasi automatisch integraler Teil des jeweiligen Cloud-Verbunds. Damit einher wird zwangsläufig ein Riss quer durch Deutschland, Verbund für Verbund, gehen – zumindest was die großen Universitätsbibliotheken angeht – zwischen den Bibliotheken, die in die OCLC-Cloud und denen, die in die ExLibris-Cloud wandern.

Wozu dann noch das künstliche Artefakt von zusätzlichen regionalen deutschen Verbünden? Und das umso mehr, wenn man die Tendenz betrachtet, dass  Verbünde – politisch gewollt –  in privatwirtschaftliche Strukturen überführt werden und ihren Unterhalt zukünftig selbst von den Bibliotheken erwirtschaften sollen. Warum als Bibliothek dann für den regionalen oder nationalen Verbund noch zahlen, wenn man ohnehin sein Lokalsystem bezahlt und damit der (private) Cloud-Verbund all-inklusive ist?

Der Lock-In im Cloud-System, das unbezahlte Katalogisieren für die Datenbasis des Cloudherstellers, was sind das schon für Hindernisse, wenn das Geld im Bildungsbereich, und da speziell bei den Bibliotheken, ohnehin knapp gesäht ist? Nicht ohne Grund touren die Hersteller der grossen Cloudsysteme beständig durchs Land und suggerieren den Entscheidern in Präsentationen mit Worten wie “Rechfertigungsdruck der Bibliotheken” usw. dringend gewünschte Einsparungen, die durch den Wegfall der lokalen Systembetreuung und die weltweite gemeinschaftliche Katalogisierung entstehen (könnten).

Die Verbünde haben dann nur noch die Wahl sich arbeitstechnisch als Dienstleister für die Cloudsysteme aufzuteilen, z.B. das hbz und der KOBV betreuen die ExLibris-Kunden und  BVB sowie GBV die OCLC-Kunden. Können Verbundzentralen durch die neue Dienstleistung “Programmierung für das Cloudsystem” noch künstlich am Leben gehalten werden, so wird so manche Hochschule versucht sein ihre Bibliotheks-IT deutlich zu schrumpfen oder ganz auflösen – analog dem Status-Quo bei Öffentlichen Bibliotheken. Für den lokalen Betrieb und die Verbindung sämtlicher Bibliotheks-Services zu einem stimmigen Ganzen für den Nutzer wäre das eine Katastrophe. Lokales Know-How wird vernichtet und muss später wieder teuer von externen Dienstleistern oder dem Hersteller selbst eingekauft werden.

Alternativstrategien

Eine Alternativstrategie müsste – ausgehend von der bisherigen Analyse – zwingend eine offene Katalogisierungsplattform und ein (offenes) Lokalsystem umfassen. Bemerkenswert ist hier die breite aktuelle Aufstellung des SWB, der frühzeitig bei der Lokalsystemseite auf Koha gesetzt hat. Idealerweise würden sich die aktuellen Verbünde mit ihren Entwicklungskapazitäten entsprechend der Anforderungen der Bibliotheken die Arbeit an der Plattform und einem offenen Lokalsystem aufteilen. Das ist umso wichtiger, als dass speziell beim Design und der Einführung eines neuen Lokalsystems “die Bibliotheken und ihre Mitarbeiter mitgenommen werden müssen”. Dafür wäre aber die wesentliche Voraussetzung, dass alle, Verbünde und Bibliotheken, an einem Strang ziehen – wovon bei der unterschiedlichen Ausrichtung derzeit nicht ausgegangen werden kann. Und damit sehe ich jegliche Alternativstrategie realistisch von vorherein zum Scheitern verurteilt. So bleibt als letztes formales Hindernis gen internationale Cloud-Systeme lediglich der Datenschutz bei Ausleihe und Erwerbung, aber dort wird man sicherlich kreative Lösungen finden…

Wir sehen uns dann…. in der Cloud und versuchen wie immer das Beste für unsere Nutzer daraus zu machen.

Kooperative Bearbeitung von Sammlungs-Portalen

Die KUG Recherche-Infrastruktur mit OpenBib war seit jeher nicht als Content-Management-System (CMS) konzipiert. Inhalte und Logik für dynamische Inhalte werden über ein Templating-System organisiert. Durch dessen Objektorientierung kann über Vererbungs-Mechanismen elegant und mit wenig Aufwand eine Vielzahl von Sammlungs-Portalen – derzeit 26 zuzüglich weiterer 14 für die RheinlandBib – verwaltet werden. Die zugehörigen Templates sind auf jedem der derzeit vier Recherche-Server in einer Verzeichnis-Struktur abgelegt. Insgesamt umfasst die gesamte Recherche-Infrastruktur über alle damit realisierten Portale hinweg derzeit 1585 Templates.

Sollen Inhalte geändert werden, so muss das zugehörige bearbeitete Template auf jeden der vier Rechner übertragen werden. Durch die Verwendung des öffentlichen Subversion-Repositories ist das mit wenig Aufwand über die Abteilung UniversitätsGesamtKatalog der USB Köln möglich.

Gerade bei Sammlungs-Portalen, die in Zusammenarbeit mit Wissenschaftlern aus den verschiedenen Fachbereichen der Universität entstehen, Stichwort Forschungsdaten, kommt diese zugrundeliegende Organisation von Inhalten durch Templates an ihre Grenzen.

Ist die Konzeption einer Recherche-Infrastruktur auf einen zentralen Dienstleister und Betreiber ausgerichtet, so besteht nun der nachvollziehbare Wunsch der Wissenschaftler dezentral Texte auf der Einstiegs- oder weiteren Informationsseiten des jeweiligen Portals selbständig ändern zu können. Andererseits können wir als Betreiber der Infrastruktur von den Wissenschaftlern nicht verlangen, dass sich diese mit Template- oder Markup-Sprachen auseinander zu setzen haben, nur wenn sie Texte ändern oder Zahlen aktualisieren wollen.

Weiterlesen »

Nachdem vor knapp 2 Wochen Rudolf Mumenthaler im Bibliotheksdienst das Fehlen von offenen E-Books in vielen Bibliothekskatalogen monierte und den möglichen Ursachen nachging, haben wir uns einem Bereich zugewandt, bei dem es noch viel düsterer aussieht – der Integration von offenen Lern- und Lehrmaterialien, den Open Educational Resources (OER). Ähnlich wie bei den offenen E-Books existieren zwar inzwischen verschiedene Aggregationsplattformen wie z.B. OERCommons, aber leider stellen diese ihre Metadaten meist nicht offen ins Netz, so dass diese auch nicht geharvestet und in eigene Recherche-Infrastrukturen der Bibliotheken integriert werden können.

Gerade die Bereitstellung der Metadaten ist aber eine wesentliche Voraussetzung dafür, dass die unzähligen über den Globus verteilten Vorlesungs-Materialien auch überall gefunden werden. Hier müssen die OER-Plattformen mit dem Fehlen von Synchronisierungsmechanismen wie OAI-Schnittstellen oder bibliothekarischen Standard-Datenformaten im Vergleich zu den klassischen OpenAccess-Materialen (Hochschulschriften, Institutional Repositories, Pre-Print-Server) noch massiv aufholen. Die Dezentralität von Resourcen wurde im klassischen OA-Bereich bereits vor vielen Jahren gemeistert. So ist eine Aggregation aller vorhandenen OERs in dem Umfang wie es BASE bei klassischen OpenAccess-Materialien macht, im Moment geradezu utopisch.

Der Weg der OERs in die lokalen Recherche-Infrastrukturen ist derzeit also noch etwas steinig. Dennoch gibt es auch bereits jetzt pragmatische Lösungen, um einzelne ausgewählten OER-Bestände zu integrieren – vorausgesetzt, die Metadaten sind verfügbar.

Einzelne Plattformen

Als Aggregator stellt das OpenCourseWare Consortium seine Daten sowohl über eine eigenes API wie auch über eine Excel-Tabelle bereit. Diese Daten sind grundsätzlich brauchbar, auch wenn im Bereich der Personenerfassung klassische Fehler ausgemacht werden können (keine einheitliche Ansetzungsform, Ansetzungsformen verschiedener Personen mit Komma getrennt).

Alternativ steht auch ein RDF-Abzug im Turtle-Format samt SPARQL-Endpoint auf datahub.io bereit - dort sind Personen aber z.T. ins Nichts verlinkt, so dass die regelmäßig aktualisierte Excel-Tabelle hier ganz klar vorzuzuiehen ist. Für den KUG wurde die Excel-Tabelle zunächst mit LibreOffice in eine CSV-Datei umgewandelt und dann mit einer geeigneten Parametrisierung für das Programm simplecsv2meta.pl in einen eigenen KUG-Katalog geladen.

Eine weitere Plattform mit API ist die Khan Academy. Für die Erkundung des API’s wird neben einer Dokumentation eigens ein API-Explorer bereitgestellt. Für eine Integration bietet sich hier insbesondere der topictree-Call an, mit dem sämtliche Inhalte in einer hierarchischen Struktur heruntergeladen werden können. Für die JSON-Inhalten des topictree-Calls haben wir ein eigenes Konvertierungsprogramm und eine Parametrisierung erstellt.

YouTube

Auch wenn viele OER-Plattformen selbst kein API oder Dumps ihrer Metadaten anbieten, so nutzen viele von ihnen aber YouTube als zentralen Dienstleister für die Bereitstellung ihrer Kurs-Videos. YouTube selbst hat die dem Bereich Bildung zugeordneten Videos zentral unter http://youtube.com/edu virtuell zusammengefasst.

YouTube selbst bietet ein API in verschiedenen Versionen an. Version 3 gilt offiziell noch als experimentell, Version 2 des Google Data API für YouTube wird aber  von verschiedenen Programmiersprachen durch entsprechende Programm-Module unterstützt. Die Programmiersprache Perl wird zwar offiziell nicht unterstützt, mit dem Modul WebService-GData steht aber eine gute Umsetzung bereit, die lediglich in Kombination mit der encode_json-Methode aus JSON::XS mit doppeltem UTF8-Encoding patzt. Mit to_json aus dem JSON-Modul wird aber auch UTF8 korrekt umgesetzt.

Wichtig war uns bei einer Integration von OER aus YouTube, dass wir selbst festlegen können, welche Channels wir in den KUG integrieren, denn nicht alle unter youtube.com/edu angebotenen Videos scheinen uns hierfür geeignet. Und selbst bei einzelnen Channels, wie z.B. bei der Stanford University müssen die Kurse erst noch ausgefiltert werden.

Darüberhinaus ermöglicht uns die Übertragung einzelner Channels in einzelne KUG-Recherche-Kataloge das Mischen von OERs aus verschiedenen Quellsystemen. Ein gutes Beispiel hierfür ist die Khan Academy, die zwar ein API und die Daten bereitstellt, aber nur für die englischsprachigen Kurse. Die deutschsprachigen Kurse der Khan Academy sind in diesen Daten gerade nicht enthalten, aber stattdessen im YouTube-Channel KhanAcademyDeutsch. So können wir die Original API Daten der englischen Khan Academy dem zugehörigen YouTube-Channel vorziehen, uns zusätzlich aber des deutschen Channels bedienen und so beide Sektionen der Khan Academy abdecken.

Im Vergleich mit den dedizierten Plattformen wie OCW Consortium oder der Khan Academy stellt YouTube weniger Daten bereit, die zum Set der klassischen bibliographischen Daten gehören. Insbesondere fehlen idR Personeninformationen – einziger author-Name im YouTube-API ist der Username des Channelerstellers. Dennoch sind die Daten selbst gut strukturiert.

Normalerweise wird ein ganzer Kurs als Playlist organisiert, in der die einzelnen Video-Lektionen enthalten sind. Dadurch erst lässt sich die kursspezifische Zusammenfassung der Videos auch 1:1 in den zugeordneten KUG-Katalog übertragen. Dennoch ziehen wir ganz allgemein die potentiell reichhaltigeren originalen Daten ala OCW oder Khan Academy denen von YouTube vor. Bis solche Daten aber irgendwann einmal für alle OER-Quellen bereitgestellt werden, ist YouTube die bestmögliche Lösung, um diese Materialien überhaupt im lokalen Bibliotheksumfeld sichtbar zu machen.

Gestartet sind wir in dem neuen Bereich der OER mit folgenden Katalogen im KUG:

Das sind insgesamt 43.389 Nachweise. Weitere OER-Quellen lassen sich – speziell im Bereich der YouTube-Channels – einfach durch Nennung des Channel-Namens in entsprechenden Parametrisierungsdateien für das generelle Harvesting-Programm youtube2meta.pl festlegen.

Die Sichtung weiterer geeigneter Quellen und Aggregationsplattformen mit vorhandenen Metadaten ist nach wie vor das gravierendste Problem bei der Integration von OERs in die lokalen Recherche-Infrastrukturen. Die allgemeine Zugänglichmachung von Informationen zu solchen OER-Quellen von jedweder Seite würden wir daher sehr begrüßen. Die nächste neue OER-Plattform, die wir uns genauer anschauen werden, ist sicherlich learningregistry.org mit eigenem API.

Seit heute haben wir im Kölner UniversitätsGesamtkatalog KUG die Zahl von 200 gemeinsam recherchierbaren Datenquellen erreicht. Davon entfallen knapp 150 auf klassische Bibliothekskataloge der Universität zu Köln und die restlichen 50 auf Sonderbestände und freie E-Books bzw. sonstige elektronische Materialien. Gerade die freien Inhalte tragen massgeblich zu der stattlichen Zahl von 19.5 Millionen Nachweisen bei, denn die klassischen Bibliothekskataloge machen hiervon lediglich knapp 7 Millionen Titel aus.

Insgesamt schlüsselt sich der Bestand im KUG von 19.539.367 Nachweisen aktuell auf in

  • 414.092 Zeitschriften bzw. Serien,
  • 450.813 Artikel/Aufsätze sowie
  • 10.823.009 digital verfügbare Medien.

Bereits seit vielen Jahren haben wir in den KUG freie digital verfügbare Inhalte aufgenommen, wie z.B.

  • KUPS, den Kölner UnversitätsPublikationsServer
  • GDEA, das Graph Drawing E-Prints Archive
  • DFG Nationallizenzen
  • Digitalisierte Bücher der Open Library
  • RePEc, Research Papers in Economics
  • DRIVER Forschungsdaten
  • Digitalis-Projekt des Seminars der Wirtschafts- und Unternehmensgeschichte der Universität zu Köln
  • Volltexte des ehem. SSG BWL
  • Texte von de.wikisource.org
  • Internationales Projekt Gutenberg
  • Directory of Open Access Books

von denen viele, aber leider nicht alle, in ihren Metadaten frei verfügbar sind.

Durch die Vereinheitlichung des Harvesting von OAI-Quellen mit REPOX vor einigen Wochen konnten wir sehr schnell weitere Quellen integrieren, wie z.B.

  • Gallica (1.198.908 Objekte)
  • Göttinger Digitalisierungszentrum (85.064 Titel)
  • HathiTrust (1.182.308 Titel)
  • LoC (242.394 Objekte)
  • Münchener Digitalisierungszentrum (924.580 Titel)
  • National Libray of Australia (233.148 Objekte)
  • National Science Digital Library (122.928 Titel)
  • ZVDD (296.830 Tite, via OAI leider ohne MDZ und einige andere)
  • E-Lis – EPrints in Library and Information Science (16.055 Titel)
  • InTech Open E-Books (39.126 Titel)
  • Networked Digital Library of Thesis and Dissertations (3.613.947 Titel)

Jenseits der 200 Datenquellen, die über das zentrale KUG-Rechercheportal kug.ub.uni-koeln.de, den “KUG”, angeboten werden, sind in die allgemeine KUG-Rechercheinfrastruktur viele weitere Datenquellen integriert, die ausserhalb des “KUG” entweder in eigenen Recherche-Portalen – z.B. Sammlungen wie die Totenzettel-Sammlung der USB oder die Sammlung DDR-Kinderbuch der ALEKI – bereitgestellt werden, oder ausschliesslich in das USB-Portal integriert sind, wie z.B. die Daten von Print- und E-Book PDA-Projekten.

Seit dem Start des USB-Portals als in die USB-Homepage integriertes Recherche-Portal im Herbst 2009 gab es – nicht nur unter unseren Anwendern – immer wieder Verwirrung darüber, welches Recherche-Portal sie denn sinnvollerweise nutzen sollen:

  • Das USB-Portal der Universitäts- und Stadtbibliothek Köln mit seiner Möglichkeit auch entfernte Kataloge und Datenbanken, speziell den EBSCO Discovery Service zu nutzen (Recherche “in die Breite”) und der Integration der Fernleihe
  • oder den Kölner UniversitätsGesamtkatalog KUG aus gleichem Hause mit seinen erweiterten Möglichkeiten eines Katalogs 2.0, Recherche-Anreicherungen und der Spezialisierung auf Suchmaschinen-Technologie auf Basis lokal vorhandener Daten, wie der Kataloge der Universität zu Köln (Recherche “in die Tiefe”).

Die Vermittlung der Vorzüge eines jeden Portals für die jeweilige Recherche-Situation war dementsprechend mühsam.

Es war klar, dass solch ein Nebeneinander von zwei Systemen immer wieder berechtigtes Unverständnis der Nutzer auf sich ziehen würde.

Aus diesem Grund wurde bereits Ende des Jahres 2010 entschieden, künftig nur noch einen zentralen Sucheinstieg anzubieten. Hierzu sollten die beiden bisher separaten Systeme gekoppelt werden, wobei das USB-Portal fortan als Rechercheoberfläche fungiert und der KUG die darunter liegende Infrastruktur mit den zu recherchierenden Daten bereit stellt. Die zentrale Voraussetzung für die Verschmelzung des USB-Portals mit dem KUG ist die Bereitstellung entsprechender Schnittstellen in der OpenBib-Software. Durch die bereits Ende 2009 begonnene Neuausrichtung und Überarbeitung der OpenBib-Software waren die dazu notwenigen Vorausetzungen bereits in der Entwicklung.

Meilenstein 1

Ein erster Meilenstein war im Februar 2013 mit der Einführung von OpenBib 3 für die KUG Recherche-Infrastruktur erreicht. Durch das von dieser Version umgesetzte Paradigma “Das Recherche-Portal ist der WebService” mit der Bereitstellung eines REST-Interfaces auf JSON-Basis konnten weite Teile der Recherche in das USB-Portal mit der dort verwendeten IPS-Software integriert werden. Zusätzlich kann die KUG Infrastruktur seine Inhalte auch direkt als HTML-Schnipsel über die Include-Repräsentation bereitstellen. So können z.B. Wortwolken, Literaturlisten usw. direkt in das Content-Management-System ZMS eingebunden werden, das ebenfalls im USB-Portal Verwendung findet.

Unmittelbar nach der Einführung der neuen KUG Infrastruktur wurde das USB-Portals darauf umgestellt, so dass ab Februar 2013 dieses nun auch eine facettierte Suche für die Profile “USB” und “Uni” anbieten konnte.

Meilenstein 2

Neben dem primären Sucheinstieg kug.ub.uni-koeln.de bietet die KUG Infrastruktur knapp 120 individuelle Sucheinstiege für die Institute und Seminare der Universität zu Köln an. Dort kann gezielt im jeweiligen Bibliothekskatalog recherchiert werden, zusätzlich der Suchradius aber auch auf den Bestand der zugehörigen Fakultät bzw. den Gesamtbestand erweitert werden.

Für all jene Sucheinstiege musste ein Äquivalent auf Seiten des USB-Portals gefunden werden. Daher haben wir den bereits in das USB-Portal integrierten Bibliotheksführer, in dem jede Institutsbibliothek eine eigene Informationsseite besitzt, als Grundlage genommen und diese Informationsseite zu einer Einstiegsseite für die Recherche im lokalen Institutsbestand umgearbeitet. Dabei waren eine Unmenge an Detailfragen zu klären, was alles in diese Seite reingepackt werden sollte, wie Ausleihfunktionen integriert werden können oder wie der Zugriff auf alle separaten Instituts-Benutzerkonten sinnvoll vereinheitlicht werden konnte.

Lösungen zu diesen und anderen Fragen mussten von unserer Portal-AG beratschlagt und beschlossen werden. In der AG sind fast alle Dezernate der USB und auch die dezentralen Bibliotheken vertreten. Sie gibt die Richtung vor bei der Weiterentwicklung des USB-Portals. Und dann mussten die dort gefundenen Ergebnisse noch 120 Mal – für jede Institutsbibliothek einzeln – umgesetzt werden. Dadurch hat die Umstellung dann doch etwas länger gedauert, als ursprünglich gedacht…

Ehemaliger Recherche-Einstieg für Institute auf KUG-Basis

Ehemaliger Recherche-Einstieg für Institute auf KUG-Basis

Neuer Recherche-Einstieg für Institute im USB-Portal

Neuer Recherche-Einstieg für Institute im USB-Portal

Bestands-Wolke nach Jahre im USB-Portal

Bestands-Wolke nach Jahre im USB-Portal

Mit der Freischaltung dieser Recherche-Einstiegsseiten für Institute und Seminare wurde am 3.2.2014 der zweite Meilenstein geschafft. Um eine möglichst “sanfte” Migration hin zu den neuen Recherche-Seiten zu gewährleisten, sollen die zugehörigen “alten” KUG-Portale noch bis Ende Februar parallel bereitgestellt und danach deaktiviert werden.

Meilenstein 3

Jetzt steht nur noch der dritte und letzte Meilenstein aus. In diesem muss die Nutzerdatenbank der KUG Infrastruktur in das USB-Portal integriert werden, so dass

  • auch im USB-Portal Literaturlisten und Tags Einzug halten und bearbeitet werde können sowie
  • alle bestehenden Merklisten, Literaturlisten und Tags aus der KUG-Infrastruktur auch ins USB-Portal übernommen und bearbeitet werden können.

Ebenso müssen Überlegungen angestellt werden, ob und wie sich andere Funktionen des KUG in das USB-Portal integrieren lassen. Dazu gehören z.B. die Informationen über gleiche Titel in anderen Katalogen, andere Ausgaben eines Titels usw.

Bis dahin muss das zentrale KUG-Portal weiterhin angeboten werden, so dass die Nutzer ihre eigenen Inhalte dort weiterhin bearbeiten können. Ist der Meilenstein erreicht, kann der KUG als Präsentations-Schicht für die Recherche im Gesamtbestand unter kug.ub.uni-koeln.de ebenfalls deaktiviert werden. Dieser finale Schritt hin zu einem einheitlichen Recherche-Portal für die Universität ist von uns für Mitte 2014 geplant.

Dennoch wird die KUG Infrastruktur auch weiterhin mit der von ihr bereitgestellten Präsentations-Schicht die Basis für verschiene Spezial-Portale bilden. Dazu gehören u.a. Portale mit Sammlungen und Forschungsdaten der Universität (z.B. die Abklatsch-Sammlung des Instituts für Altertumskunde) oder die Portale der Arbeitsstelle Historische Bestände im Rheinland.

Mit der Vereinigung von KUG und USB-Portal hin zu einem einheitlichen Recherche-Portal für die Nutzer der Universität konnten wir die Meriten beider Systeme optimal bündeln und sind für zukünftige Anforderungen bestens gerüstet.

Ausgehend von den OAI-Daten des Kölner UniversitätsPublikationsServers KUPS werden seit knapp 10 Jahren OAI-Daten in den Kölner UniversitätsGesamtkatalog KUG für die Recherche integriert. Die dafür zuständigen Programme haben – mangels Notwendigkeit – in dieser Zeit nur geringfügige Anpassungen erfahren.

Mit der Einführung von OpenBib 3 für den KUG haben wir gleichzeitig die zugrundeliegende Infrastruktur modernisiert. In zwei Clustern mit jeweils 2 Servern wird seither die KUG Recherche-Infrastruktur an der USB Köln – sowohl für den KUG selbst, wie auch für das USB Portal – betrieben. Ein Cluster ist jeweils für die Beantwortung von Rechercheanfragen über das Web-Interface verantwortlich, das andere aktualisiert während dessen die Daten aus allen Katalogen sowie anderen Quellen. Nach erfolgter Aktualisierung wechseln die Cluster und das bisher für Rechercheanfragen zuständige Cluster steht für die nächste Aktualisierung bereit und umgekehrt.

Diese lastverteilte und weitgehend ausfallresistente Architektur wirkt sich jedoch nachteilig auf das Harvesten von OAI-Quellen aus, da die jeweiligen Repositories ihre Daten ingesamt viermal liefern müssen – an jedes der beteiligten KUG-Serversysteme. Diese unnötige Belastung der OAI-Repositories – insbesondere, wenn sie großen Bestand haben – muss zwingend verhindert werden. Darüber hinaus können Synchronisationsprobleme innerhalb eines KUG-Clusters auftreten, wenn z.B. ein Repository von Rechner A zeitlich vor Rechner B geharvestet wird. In der Zwischenzeit können weitere Titel dort verfügbar sein, so dass die beiden Rechner von ihren Datenbeständen nicht mehr synchron sind – was aber eine absolute Voraussetzung für einen konsistenten Betrieb ist.

Das war Grund genug die bisherige Praxis bei der Integration von OAI-Quellen ebenfalls zu modernisieren und die Probleme auszuräumen.

Der wesentliche Baustein hierzu ist die Einrichtung eines zentralen OAI-Aggregators, der einerseits die Daten aller externen OAI-Repositories harvestet, andererseits diese Daten selbst wieder über OAI-PMH für die einzelnen KUG-Server bereitstellt. Damit müsste nur noch einmal pro Repository geharvestet werden und etwaige Synchronisationsprobleme würden auch verhindert.

In der Vergangenheit haben wir hierzu die Softwarelösung Celestial von Tim Brody (Universität von Southampton) evaluiert. Diese hätte sich als LAMP-System sehr gut bei uns integrieren lassen, wenn wir nicht Zweifel an dessen Weiterentwicklung hätten. Die letzten Änderungen sind sporadisch und der Betrieb in Southampten selbst unter celestial.eprints.org wurde schon vor einiger Zeit eingestellt.

Vor einigen Wochen sind wir dann aber auf die Softwarelösung REPOX aus dem Europeana-Umfeld gestossen. REPOX wird von der Technischen Universität Lissabon als JAVA-Webanwendung innerhalb eines Jetty-Containers entwickelt und als Open Source-Software bereitgestellt. Zentraler Bestandteil ist OCLC’s OAICat Repository Framework, das unter der Apache 2.0 Lizenz frei nutzbar ist. Die Installation und Konfiguration war ausgesprochen schnell erledigt. Herunterladen, entpacken, Installationsskript aufrufen, Konfigurationsdatei anpassen und jetty starten. Das wars.

REPOX Einstiegsseite

Danach konnten wir bereits mit Harvesting-Tests beginnen. REPOX bietet viele Funktionen, u.a. auch die automatische Konvertierungen zwischen Metadatenformaten, die auch erweiterbar ist. Wesentlichste Funktionen für uns waren jedoch ausschließlich das Einrichten von OAI-Repositories, das Harvesten inkl. Scheduling sowie die Bereitstellung via OAI-PMH. Derzeit werden alle Repositories ausschließlich im Dublin Core-Format geharvestet. Die Hinzunahme anderer Formate (MARCXML u.a.) ist möglich.

Anlegen eines Data Sets

Jede OAI-Quelle wird als sog. Data Set eingerichtet. Jeder Data Set kann dann wiederum bei der Bereitstellung der Daten via OAI-PMH als Selektionskriterium entsprechend der im OAI-PMH-Standard definierten Sets genutzt werden. Sehr einfach können auch Schedules für das Harvesten der jeweiligen Data Sets eingerichtet werden. Standardmäßig harvesten wir mit REPOX täglich inkrementell.

REPOX - Scheduling des Harvestens

Im Betrieb verhält sich REPOX weitestgehend unauffällig. Allerdings haben wir auch schon einige kleinere Probleme beobachten können. Diese sind während unserer anfänglichen Tests beim gleichzeitigen Harvesten eines Repositories in mehreren Data Sets für verschiedene Metadaten-Formate aufgetreten. Ebenso ist die Performance beim inkrementellen Harvesten von REPOX mittels Zeiträumen suboptimal. Beides lässt sich aber problemlos umgehen. So harvesten wir von REPOX z.B. immer komplett. Das dauert bei knapp 1 Millionen Datensätzen für einen Data Set auch nur wenige Minuten…

Insgesamt ist REPOX eine leichtgewichtige Lösung, wenn OAI-Daten lokal aggregiert und dann intern weiterverarbeitet werden sollen. Diese Aufgaben kann es mit wenig Aufwand erledigen.

Parallel zur Einführung von REPOX wurde auch der Harvester der KUG-Serversysteme überarbeit. Neu ist die Verarbeitung von Metadaten mittels des allgemeinen Konverters simplexml2meta.pl und zugehöriger Parametrisierungsdateien, in denen das Metadaten-Mapping ausgehend von den geharvesteten Metadaten-Formaten via XPath-Ausdrücken erfolgen kann.

Nachdem von uns bisher vorwiegend lokale bzw. kleine Repositories geharvestet wurden, haben wir damit begonnen auch größere Repositories zu integrieren. Speziell komplett digitalisierte Quellen sind hier für uns von Interesse, wie z.B. die Digitalisate der Digitalisierungszentren in Göttingen und München sowie das ZVDD.

 Update 23.1.2014:

Nach der Integration der genannten nationalen Repositorien GDZ mit 85.064 Nachweisen, MDZ mit 924.580 Nachweisen und ZVDD mit 296.830 Nachweisen (per OAI ist nur ein Teilbestand harvestbar, da einige Institutionen, u.a. die BSB, der Weiterverbreitung ihrer Nachweise durch ZVDD via OAI widersprochen haben) haben wir nun einige internationale Repositorien in unsere Recherche-Infrastruktur mit OAI integriert.

Es sind dies

  • die Gallica der Französischen Nationalbibliothek mit 1.198.908 Nachweisen auf ihre Digitalisate
  • HathiTrust, ein Konsortium US-amerikanischer Bibliotheken, mit 1.182.308 Nachweisen auf ihre Digitalisate sowie
  • die Library of Congress mit 242.394 Nachweise auf ihre Digitalisate im Kontext American Memory

Mit diesen digitalisierte Quellen konnte der Umfang des KUG auf derzeit knapp 15.4 Millionen Nachweise gesteigert werden.

 

 

Facetten im KUG – Standorte und Sprachen

Vor einigen Wochen wurden die Facetten im KUG mit der Eingrenzung der Rechercheergebnisse nach Themengebieten erweitert. Das sollte aber nur der Anfang für weitergehende Änderungen bei den Facetten sein. So ist es gerade im Bereich der Erscheinungsjahre aus Nutzersicht hilfreich eine Recherche im Nachhinein auf Jahresbereiche einzugrenzen, wie es andere Kataloge schon seit einiger Zeit anbieten.

Jenseits einer solchen vergleichsweise kleinen Erweiterung haben wir uns auch noch einmal andere Facetten genauer angeschaut, speziell die Rechercheeingrenzungen “nach Katalogen” und “nach Sprache”.

Kataloge vs. Standorte

Seit jeher stellt der einzelne Katalog die kleinste Daten- und Rechercheeinheit im KUG dar. Strukturell war dies immer durch die Organisation der Bibliotheken an Universität zu Köln als autonome Einheiten vorgegeben und hat sich auch später nach Hinzunahme externer Datenbestände bewährt. Dementsprechend existieren derzeit insgesamt 125 separate Kataloge von Institutsbibliotheken zuzüglich dem der USB Köln. Einer der Erfolge des KUG-Projektes war die Vereinheitlichung dieser vielen Kataloge unter nur noch einer Bibliothekssoftware, die in der USB auf zwei Servern gehostet wird – ein Server für den Katalog der USB und einer für die 125 Kataloge der Institutsbibliotheken.

Um die Qualität der bibliothekarischen Dienstleistungen an der Universität zu verbessern und Kräfte effizient zu bündeln, versucht die USB seit einigen Jahren gezielt fachzentrierte Kooperationen mit Institutsbibliotheken auf freiwilliger Basis einzugehen und sogenannte “gemeinsame Fachbibliotheken” zu bilden. Recherchetechnisch hat das einige Auswirkungen, denn diese Fachbibliotheken nutzen fortan das Bibliothekssystem der USB, während jedes zugehörige Institut seine Bestände bisher in einem eigenständigen Katalog erfasst hat. Während ein Institut nach dem anderen also einer Fachbibliothek beitritt und seine Bestände nach und nach migriert werden müssen, wird die “alte Ordnung” – ein Institut hat einen Katalog an einem Standort – aufgebrochen. Die Bestände sind erst einmal auf mehrere Kataloge verteilt, obwohl sie physikalisch an einem Standort aufgestellt sind.

Wie soll man das aber einem Nutzer klar machen, der doch nur wissen will, wo er das Medium denn nun bekommen kann bzw. seine Rechercheergebnisse auf die Medien “in seiner Bibliothek” eingrenzen will.

Der einzelne Katalog als Informationseinheit reicht hier nicht mehr aus. Daher können in der Administration des KUG Recherche-Portals nun zusätzlich Standorte erfasst werden.

Übersicht aller Standorte

Ein Standort besteht aus einem Identifier, mit dem man ihn referenzieren kann, einer Beschreibung und einem Typ. Wird als Identifier eine standardisierte ISIL verwendet, so lautet der Typ einfach “ISIL”, für alle anderen wird einfach der Typ “generic” besetzt. Zusätzlich werden für einen Standort verschiedene Informationen erfasst wie Institutsname, Adresse, Telefonnummer, Geo-Positionen usw.

Einzelne Standortdefinition

Jedem Katalog kann hiermit in der KUG-Administration einfach ein Standort zugewiesen werden, an dem die Bestände zu finden sind. Dies entspricht dem bisherigen Normalfall. Bei Beständen, die auf mehrere Kataloge verteilt sind, können die zugehörigen einzelnen Standorte pro Katalog  nun aber alternativ in den Daten angereichert werden. Im USB-Katalog sind das z.B. folgende Bestände, die durch den Filter add-locationid.pl mit Standorten angereichert werden:

  • Fachbibliothek Chemie (ISIL DE-38-507)
  • Fachbibliothek Versicherungswissenschaft (ISIL DE-38-123)
  • Fachbibliothek VWL (derzeit ISIL DE-38-105, später ISIL DE-38-101)
  • Fachbibliothek Medienkultur und Theater (2 Standorte mit ISIL DE-38-428 und DE-38-429)
  • USB: Hauptabteilung (ISIL DE-38)
  • USB: Humanwissenschaftliche Abteilung (Generisch DE-38-HWA)
  • USB: Sofortausleihbereich (Generisch DE-38-SAB)
  • USB: Lehrbuchsammlung (Generisch DE-38-LBS)
  • USB: Europäisches Dokumentationszentrum (Generisch DE-38-EDZ)
  • USB: Lesesaal (Generisch DE-38-LS)

Parallel dazu existieren die ehemaligen Institutskataloge mittelfristig weiter. Im Falle der Fachbibliothek Medienkultur sind das z.B. die Kataloge inst428 und inst429, die mit den Standorten DE-38-428 und DE-38-429 verknüpft sind. Eine Eingrenzung auf DE-38-429 führt den Nutzer also auf die Bestände aus den Katalogen der USB und der Theaterwissenschaftlichen Sammlung, die beide in Köln-Wahn aufgestellt sind.

Insgesamt bildet die Anreicherung mit Standorten bei einer Recherche über den Gesamtbestand aller Kataloge alle Möglichkeiten ab, die mit der alten Facettierung über Kataloge erreicht wurden und flexibilisiert sie zusätzlich mit der Zusammenfassung von Beständen über Kataloggrenzen hinweg. Ebenso lassen sich – wie im Fall der USB – verschiedene Unterstandorte (USB: Sofortausleihbereich) innerhalb eines Standortes (USB: Hauptabteilung) realisieren. Bisher wurden die Daten verschiedener Einzelstandorte des USB-Katalogs in eigene Kataloge extrahiert, wie z.B. für die Humanwissenschaftliche Abteilung, den Sofortausleihbereich usw. Bei einer Rercherche resultierten daraus zwangsläufig Mehrfacheinträge in den Trefferlisten. Mit den neuen Möglichkeiten der Standort-Facetten sind diese Kataloge nun nicht mehr notwendig, können entfernt werden und führen so nicht mehr zu den Mehrfacheinträgen.

Eine weitere Verbesserung ergibt sich für den Inhalt des Katalogs “Zeitschriften der Institute”. Zeitschriften werden für die Institute durch die USB direkt in der Zeitschriftendatenbank (ZDB) erfasst und normalerweise nicht in den einzelnen Institutskatalogen. Der daraus resultierende Katalog mit allen Zeitschriftenbeständen wird nun ebenfalls mit den verschiedenen Standorten angereichert. Bei einer Eingrenzung der Recherche auf den Standort eines Instituts werden dann automatisch auch die zugehörigen Zeitschriften mit ausgegeben.

 Standort-Facette

Sprachen

Eine weitere Facette ist die Eingrenzmöglichkeit nach Sprache. Wie bei allen Eingrenzmöglichkeiten entgehen dem Nutzer, der sie verwendet, jedoch zwangsläufig potentiell relevante Titel, da in der Regel nie alle Titel eines Kataloges konsequent und vollständig mit den entsprechenden Informationen versehen wurden. Das betrifft auch andere Facetten, wie z.B. nach Themen (Schlagworte) oder nach Systematik (Notationen). Wir versuchen diesen Umstand durch geeignete Anreicherungen (Schlagworte aus dem b3kat usw.) fortlaufend zu verbessern, aber eine 100 prozentige Abdeckung des Bestandes ist leider sehr unrealistisch.

Bei der Facettierung nach Sprache kommt zum Abdeckungsgrad zusätzlich noch die Normierung auf standardisierte Sprachcodes hinzu. Im KUG normieren wir mit der Funktion normalize_lang die Sprachcodes z.B. auf ISO-639-2 (3stellig) von ISO-639-1, aber auch innerhalb von ISO-639-2 bei Mehrdeutigkeiten (ger und deu für Deutsch) .

Grundproblem ist und bleibt aber die Abdeckung. Nur wenige Kataloge im KUG vergeben Sprachcodes bei den Titelaufnahmen. Dazu gehören der USB-Katalog, Projekt Gutenberg, die OpenLibrary, aber z.B. quasi kein Institutskatalog. Das ist ziemlich wenig…

Aus diesem Grund haben wir nach Anreicherungsmöglichkeiten gesucht. Zunächst haben wir uns die offenen Daten des b3kat angeschaut, aber hier wurde sehr schnell klar, dass auch dort überproportional wenig  Zuordnungen ISBN-zu-Sprachcode geschürft werden konnten, typischerweise gerade einmal 10-20 Tausend Zuordnung pro Dump-Datei der insgesamt 26 Dateien.

Also kommt hier – wenn man die Facette nicht grundsätzlich entfernen will – nur eine vollautomatisierte Vergabe von Sprachcode durch entsprechende linguistische Methoden in Frage. Angereichert werden sollen natürlich nur die Titel, die noch keinen Sprachcode besitzen – intellektuell katalogisierte Sprachcodes gehen immer vor.

Klein, schnell, kompakt und mit Unterstützung der Programmiersprache Perl erledigt die Chrome Language Detection Bibliothek (CLD) genau diese Aufgabe. Sie ist vollständig offener Bestandteil der Entwicklung des Web Browsers Chrome (genauer Chromium) und lässt sich sehr einfach mit dem Perl-Modul Lingua::Identify::CLD einsetzen. Setzt man dessen Objekt-Methode identify einen Text vor, so erhält man als Ergebnis den Sprachnamen, seinen Code (ISO-639-1), einen “Zuversichtlichkeitswert” für die Erkennung – und ein Flag, ob die Erkennung zuverlässig ist. Anhand dieses Flags können bei der Anreicherung sehr einfach alle unzuverlässigen Einordnungen verworfen werden und allein so die Qualität der Anreicherung gesteigert werden.

Ein weiterer qualitätssteigernder Faktor ist durch den Text selbst gegeben, anhand dessen die Identifizierung gemacht wird. Hier reicht der Titel in der Regel allein nicht aus. Daher konstruieren wir den Identifizierungstext aus dem Hautpsachtitel, seinem Zusatz und ggf. vorhandenen Gesamttiteln. In einem typischen Bibliothekskatalog kommen wir so auf ein Anreicherungsquoten über 80 Prozent. Sicherlich wird sich immer der eine oder andere Titel finden, der falsch identifiziert wurde, aber der Nutzen überwiegt hier ganz klar.

Die Ergebnisse der automatischen Sprach-Anreicherung sind sehr vielversprechend. Im Katalog der USB sind bereits Sprachcodes für 1.315.552 Titelaufnahmen erfasst. Nach der automatischen Anreicherung sind es bereits   2.044.780 Titelaufnahmen von insgesamt 3.227.887. In anderen Katalogen ohne Erfassung von Sprachcodes liegen die Anreicherungsquote z.T. bei über 80 Prozent der Titelaufnahmen.

 

 

Recherche von Normdaten im KUG

Neben der bekannten Suchmöglichkeit nach Titeln stellt der KUG ab sofort auch eine Recherche nach Normdaten-Einträgen von Personen, Körperschaften sowie Schlagworten mit Suchmaschinentechnologie bereit, wie sie vor allem von bibliothekarischer Seite gewünscht wird. Grundlage für die Erschließung der Normdaten ist ein zusätzlicher Suchindex für jeden Katalogbestand, in den die vorhandenen Normdatensätze eingeladen werden.

Das Suchformular Normdaten kann über die Erweiterte Suche erreicht werden. Neben einem eigenen Suchfeld für Personen, Körperschaften sowie Schlagworten kann über das Suchfeld Freie Suche gleichzeitig in allen Normdatenarten recherchiert werden. Recherchiert wird jeweils als Volltext in den Ansetzungsformen, Verweisungsformen und ggf. darüber hinaus.

Suchmaske für Normdaten

Analog zu den Titeln wird auch hier eine Facettierung nach Katalogen durchgeführt, in denen Treffer gefunden wurden. Um sich bei nachfolgenden Recherchen in den Normdaten nicht immer wieder mühsam zum entsprechenden Suchformular durchklicken zu müssen, wird dieses zusätzlich direkt bei den Suchergebnissen ausgegeben.

Ergebnis einer Normdaten-Recherche

Verlinkt sind die jeweiligen Normdatensätze, über die man wiederum zu den damit verknüpften Titeln kommt.

Personen-Normdatensatz

Ein Beispiel für eine themenbasierte Suchstrategie ist z.B. eine Normdatensuche in den Schlagworten nach “hexe*” – nachfolgend mit der Eingrenzung auf den Bestand der USB Köln.

Schlagwortsuche nach Hexe

Interessant wird diese Suchstrategie, wenn sich Einträge aus der Gemeinsamen Normdatei GND der Deutschen Nationalbibliothek in den Katalogen befinden. Derzeit ist dies aber nur beim Katalog der USB Köln der Fall – zuzüglich der dort enthaltenen Bestände von gemeinsamen Fachbibliotheken mit der USB –  jedoch nicht bei den Katalogen der Instituts- und Seminarbibliotheken. Dort erfolgt keine automatische Belieferung mit GND-Daten über die Versorgungsschnittstelle des hbz-Verbunds.