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.

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.

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.

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.