Das HeBIS Discovery System

1 Einleitung

Da die Anzahl der weltweit nachgewiesenen Publikationen die Milliardengrenze bereits weit überschritten hat, erhält das Thema Resource Discovery für Bibliotheken immer größere Bedeutung. Viele Dokumente und Volltexte sind in den von den Bibliotheken lizenzierten Datenbanken nachgewiesen oder Bestandteil der vor Ort lizenzierten E-Book- und E-Journal-Pakete. Für Benutzer sind sie trotzdem schwer zugänglich, weil für die betreffenden Quellen ein integrierter Recherchezugang mit ausreichender Tiefenerschließung fehlt. Der OPAC als Nachweisinstrument für die lokal vorhandenen Bibliotheksbestände ist ebenfalls unverzichtbar, aber leider ein weiteres separat zu durchsuchendes Parallelangebot.

Um eine effektivere Literatursuche zu ermöglichen und die Sichtbarkeit der mit hohem finanziellen Aufwand erworbenen Datenbank- und Volltext-Angebote zu erhöhen, sehen sich Bibliotheken zunehmend vor die Aufgabe gestellt, möglichst viele dieser Quellen sowie den lokalen OPAC unter einer gemeinsamen Rechercheoberfläche zu integrieren.^[1] Diesem Ziel versucht das HeBIS Discovery System (HDS)^[2] die Bibliotheken des HeBIS-Verbunds einen großen Schritt näher zu bringen.

2 Vom OPAC zum Discovery-System

Der Gedanke, alle verfügbaren Kataloge und Dienste einer Bibliothek zu integrieren und unter einer Oberfläche anzubieten, ist nicht neu. Schon 2006 hat der HeBIS-Verbund seinen Mitgliedsbibliotheken ein Portal auf Basis der Software SISIS Elektra zur Verfügung gestellt. Technisch ist das HeBIS-Portal eine Metasuche, also eine gleichzeitige Recherche in mehreren Katalogen. Das Ziel des Projekts war, alle für die jeweilige Bibliothek relevanten Quellen wie OPAC, eigene Repositorien, weitere regional wichtige Bibliotheken und Verbundkataloge zu durchsuchen und für die gefundenen Treffer die jeweils beste Bestellmöglichkeit, also Ausleihe, Vormerkung, Online-Zugriff oder Online-Fernleihe anzubieten. Obwohl das Elektra-Portal ein Fortschritt war, hat es sowohl technische als auch organisatorische Grenzen. Die Metasuche kann immer nur so schnell sein, wie die langsamste angesprochene Quelle, was bei der Vielzahl der Kataloge oft zu nicht akzeptablen Suchzeiten führt. Viele relevante Quellen, vor allen Dingen Datenbanken hätten zwar technisch eingebunden werden können, wurden dann aber aus Aufwandsgründen nicht berücksichtigt. Das Elektra-Portal war also technisch und organisatorisch an seine Grenzen gestoßen. Als dann 2010 auch noch die Weiterentwicklung und Wartung der Software SISIS Elektra eingestellt wurde, war klar, dass eine Alternative gefunden werden musste.

Parallel zur Erstellung eines Anforderungskatalogs wurde in Kooperation mit dem Studiengang Information Science and Engineering an der h_da Hochschule Darmstadt eine verbundweite Katalogumfrage durchgeführt, um herauszufinden, wo Benutzer den dringendsten Verbesserungsbedarf in den von den HeBIS-Bibliotheken verwendeten Katalog- und Portaloberflächen sahen. In die Auswertung gingen die Antworten von über 22.000 Benutzern aus 16 Verbundbibliotheken unterschiedlichen Typs ein. Wie sich zeigte, hatten die Umfrageteilnehmer klare Vorstellungen davon, welche neuen Funktionalitäten die zentrale Aufgabe der Kataloge, ein effektives Retrieval des lokalen wie deutschlandweiten Bibliotheksbestands zu ermöglichen, besser unterstützen würden. Die prominentesten Wünsche waren kürzere Wege („weniger Klicks“) zur Standort- und Verfügbarkeitsinformation, eine bessere Suchunterstützung (z. B. durch automatische Suchvorschläge) und bessere Möglichkeiten zur nachträglichen Filterung der Trefferlisten. Viele der abgegebenen freien Kommentare ließen außerdem erkennen, dass die Benutzer sich eine integrierte Suchoberfläche für alle Ressourcen der Bibliothek sowie eine bessere Erschließung von Zeitschriften auf Artikelebene wünschten.^[3]

Diese Ergebnisse waren wenig überraschend und bestätigten weitgehend die grundlegenden Vorüberlegungen zur Auswahl eines neuen Systems. Um zu einer Lösung zu kommen, die den Vorstellungen und Anforderungen aller HeBIS-Bibliotheken gerecht wird, wurde eine AG gegründet, die das angestrebte Gesamtkonzept abstimmen und eine entsprechende Empfehlung erarbeiten sollte. Die zentralen konzeptionellen Eckpunkte waren unstrittig. Das neue System sollte sowohl die Vorteile der alten Lösung, hauptsächlich die bruchfreie Einbindung der elektronischen Fernleihe, abdecken als auch eine modernere Oberfläche, Suchunterstützung durch Suchmaschinentechnologie und eine verbesserte Anbindung an den Benutzerbereich des Lokalsystems der Bibliotheken bieten. Darüber hinaus wurde es als unabdingbar angesehen, auch die von den Bibliotheken lizenzierten Datenbanken in die neue Suchoberfläche zu integrieren. Aufgrund der bisherigen Erfahrungen mit dieser Problematik war sich die AG aber einig, dass die Bibliotheken ebenso wie der Verbund wegen der schieren zu berücksichtigenden Datenmengen und der Vielzahl der Anbieter dieser Aufgabe personell und technisch nicht gewachsen sein würden und dass dieses Ziel nur mit Hilfe eines kommerziellen Discovery-Service (DS) zu erreichen sei.

Nach Festlegung der allgemeinen Ziele war es Aufgabe der AG, die Möglichkeiten zur Integration des DS mit dem lokalen Katalog auszuloten. Als Alternative zu kostenpflichtiger Software und gehosteten Lösungen kristallisierte sich schnell die Open-Source-Software VuFind als potenzieller Kandidat heraus. Außerdem galt es, den passenden DS für die HeBIS-Bibliotheken auszuwählen. Die Wahl fiel nach einer längeren Evaluierungsphase auf den EBSCO Discovery Service (EDS). Dafür war neben dem Preis und der Datenqualität vor allem die Abdeckung der in den HeBIS-Bibliotheken lizenzierten Quellen ausschlaggebend. Da es im Verbund neben Hochschulen mit geisteswissenschaftlicher auch solche mit naturwissenschaftlich-technischer Ausrichtung gibt, sollten Inhalte der Geisteswissenschaften sowie Science, Technology & Medicine möglichst gleich gut abgedeckt sein. EDS konnte diese Anforderung besser erfüllen als die Konkurrenzprodukte, die zum Zeitpunkt der Evaluierung einen deutlichen Schwerpunkt im STM-Bereich hatten.

Technisch und konzeptionell musste entschieden werden, ob die Katalogdaten und die Daten des DS gemischt oder in zwei getrennten Anzeigebereichen präsentiert werden sollen. Die Diskussion um diesen Punkt wurde sehr kontrovers geführt. In den DS werden Metadaten und Volltexte verschiedenster Anbieter und Quellen in einem gemeinsamen globalen Suchindex zusammengeführt. Auch die eigenen Katalogdaten können direkt in die Discovery-Services hochgeladen werden, was den Vorteil hat, dass Suchergebnisse aus dem Katalog und dem DS in einer gemeinsamen Trefferliste präsentiert werden können. Die HeBIS-Bibliotheken sprachen sich am Ende aber dafür aus, für die Katalogdaten einen HeBIS-eigenen Solr-Index aufzubauen und die Ergebnisse der Katalog- und DS-Suche in der Oberfläche separat auf zwei „Tabs“ zu präsentieren. Die Gründe dafür waren ähnlich wie in anderen vergleichbaren Systemen. Zum einen wurde befürchtet, dass die Nachweise des lokalen Bestands in den großen Ergebnismengen eines DS untergehen, zum anderen dass aufgrund der heterogenen Qualität der Daten im DS Nachteile für die Qualität der Indexierung und des Katalog-Retrievals entstehen, dessen Niveau dank der Erschließung nach einheitlichen Regelwerken und dank der Nutzung von Normdaten bislang sehr hoch und einheitlich ist.

Die AG sprach sich schließlich für eine Lösung mit VuFind als Oberfläche, Solr zur Indexierung der Katalogdaten, EDS als Discovery-Service und ReDI-Links als Linkresolver aus. Die Lösung verzichtet dabei vorerst auf eine bruchfreie Einbindung der Fernleihe, bietet aber im Sinne der Ergebnisse der HeBIS-Katalogumfrage dennoch einen großen Mehrwert für die Benutzer durch eine moderne Oberfläche mit schneller Verfügbarkeitsanzeige, Suchunterstützung mit Suchmaschinentechnologie und Suchraumerweiterung durch einen DS.

3 HDS – unsere Lösung

Der Aufbau des HeBIS Discovery Systems ist, wie aus dem vorherigen Abschnitt hervorgeht, modular und besteht aus vier Hauptkomponenten. Unter einer Oberfläche, die mit VuFind realisiert ist, werden jeweils die Katalogdaten in einem Solr-Index und die Daten des Discovery-Service über die API des Anbieters angeboten. Das Paket wird durch eine Anbindung an den Benutzerbereich des Lokalsystems komplettiert. Durch den Aufbau ist maximale Flexibilität gegeben – sei es für die Anbindung an ein anderes Lokalsystem, einen Anbieterwechsel beim Discovery-Service oder das Hinzunehmen eines weiteren Moduls unter der gleichen Oberfläche.

VuFind^[4] ist ein Open-Source-OPAC unter GPL-Lizenz. Technisch besteht VuFind aus einer PHP-Oberfläche und einem Solr-Index. Eine flexible Schnittstelle zur Anbindung an beliebige Lokalsysteme und der modulare Aufbau, der es einfach ermöglicht, weitere Funktionen hinzuzufügen, komplettieren das Paket. Ein Konzept von hierarchisch sich überschreibenden Templates für die Oberfläche ermöglicht es zudem sehr leicht, Look and Feel an die jeweilige Einrichtung anzupassen, ohne die Programmlogik zu verändern. Suchunterstützung durch Facetten, eine Autocomplete-Funktion, Suchvorschläge und weitere Web-2.0-Funktionen runden die moderne Rechercheoberfläche ab. VuFind ist nicht das einzige Open-Source-Produkt seiner Art. Die Entscheidung für VuFind fiel vor allen Dingen wegen der großen deutschen Anwendercommunity.

Um den gewohnten OPAC adäquat ersetzen zu können, musste das von VuFind geerbte Datenschema stark verändert werden. Große Herausforderungen dabei waren Normdaten, die Navigation in mehrbändigen Werken und Serien und die für jede Bibliothek getrennt einstellbare Relevanzsortierung. Für alle HeBIS-Bibliotheken wird ein gemeinsamer Index vorgehalten, was für die Nachnutzung und für die Betriebskosten entscheidende Vorteile hat, aber nicht ganz einfach zu realisieren ist. So dürfen bei der Suche nach lokalen Feldern wie Signaturen und lokalen Schlagworten eben nur die „eigenen“ Bestände gefunden werden. Vergleichbar einfach war es dagegen, externe Titelanreicherungen wie Scans der Inhaltsangaben oder Verlagsinformationen bei der Suche zu integrieren. Bei allen Erweiterungen war es von großem Vorteil, dass Solr^[5] ein Quasi-Standard ist, der nicht nur in der Bibliothekswelt benutzt wird.

Für die Anbindung an die Bestellkomponente der lokalen Ausleihsysteme bietet VuFind Plug-ins zu unterschiedlichen Systemen an. Die Funktionalität des PICA-Plug-ins ging den HeBIS-Bibliotheken aber nicht weit genug. Darum wurde diese durch eine stark angepasste Variante ersetzt, die den Benutzern teilweise sogar genauere Informationen gibt als der originale OPAC des LBS. Leider greift diese Lösung direkt auf interne Daten des Ausleihsystems zu. Darum soll die HeBIS-eigene Lösung bald auf die generische Schnittstelle PAIA^[6] umgestellt werden. Genau wie die generische Schnittstelle zur Verfügbarkeit DAIA^[7] , die schon genutzt wird, wird PAIA helfen, HDS zukünftig auch für andere Lokalsysteme anzubieten.

Der Discovery-Service EDS^[8] wird über die EDS-API in die HDS-Oberfläche eingebunden. Sie unterstützt alle wesentlichen Suchfunktionalitäten einschließlich der Filterung der Suchergebnisse über Facetten und Limiter sowie die Präsentation der Daten in der Trefferliste und der Detailanzeige. VuFind-Anwendern stellt EBSCO außerdem ein EDS-VuFind-Modul zur Verfügung. Dieses wird in HDS ebenfalls verwendet und hat mit dazu beigetragen, dass die technische Implementierung des „Artikel-&-mehr“-Tabs nur weniger eigener Anpassungen bedurfte.

EDS ist wie alle Discovery-Services ein riesiger Datenpool für einen großen internationalen Kundenkreis und enthält zwangsläufig auch Content, für den die Bibliotheken weder eine Volltextlizenz haben noch ihren Benutzern sinnvolle Beschaffungsalternativen wie z. B. die Fernleihe oder andere Dokumentlieferdienste empfehlen können. Deshalb muss EDS im Profil der jeweiligen Bibliothek in HDS eingebunden werden. Die Profilkonfiguration ist Aufgabe der HDS-Anwenderbibliothek und fällt unabhängig von der technischen Einbindung an. Sie erfolgt über eine Administrationsoberfläche von EBSCO und beinhaltet vor allem die Aktivierung der Index-Segmente, die den Benutzern für die Suche zur Verfügung stehen sollen, sowie Einstellungen zur Steuerung der Anzeige von Volltextlinks und des von der Bibliothek genutzten Linkresolvers. Die Profileinstellungen werden von der EDS-API berücksichtigt, sodass für die EDS-Einbindung keine bibliotheksspezifischen Konfigurationseinstellungen im HDS vorgenommen und gepflegt werden müssen.

Da der lokale Bestand und EDS parallel durchsucht werden, genügt ein einfacher Tab-Wechsel, um die EDS-Ergebnisse abzurufen und umgekehrt. Damit ist ein großer Schritt getan, um die Sichtbarkeit der von den Bibliotheken lizenzierten E-Ressourcen zu erhöhen und Benutzern den Zugang zu Volltexten leichter zu machen. Obwohl EDS – wie andere DS auch – keine vollständige Abdeckung aller von den Bibliotheken lizenzierten Produkte bieten kann, werden viele Benutzer bereits von diesem einfachen, integrierten Sucheinstieg profitieren.

Findet man in EDS einen Treffer, so kann oftmals ein direkter Link zum zugehörigen Volltext angeboten werden. Aber auch wenn das nicht funktioniert, soll der Benutzer nicht in eine Sackgasse gelangen. An dieser Stelle greift der Linkresolver, der aus den bibliographischen Daten unter Zuhilfenahme von Lizenzinformationen den bestmöglichen Weg zum Volltext generiert. Die HeBIS-Bibliotheken nutzen ReDI^[9] -Links, einen Service der UB Freiburg. Die Vorteile von ReDI-Links bestehen in einer einfachen Anpassbarkeit des Layouts und einer sehr freien Konfigurierbarkeit nach Wünschen der betreffenden Einrichtung. Für den Einsatz in der HDS-Umgebung wurden von ReDI z. B. Links auf lokale Bestandsnachweise auf dem „Bücher-&-mehr“-Tab ergänzt sowie Links auf den Zugang zur Fernleihe.

Nutzer sollen ihre über EDS gefundenen Favoriten genauso in der Merkliste speichern können wie die aus dem lokalen Katalog. Dazu wurde die in VuFind integrierte Merkliste deaktiviert und komplett durch eine Anbindung an das von BibSonomy abgeleitete PUMA^[10] ersetzt. Nutzer, die nur die Grundfunktionalität einer Merkliste benötigen, werden den Unterschied wahrscheinlich nicht bemerken. PUMA bietet aber viele zusätzliche Möglichkeiten. So kann man Teile der Merkliste dynamisch als Literaturliste in ein E-Learning-System wie Moodle einblenden.

4 Kooperative Entwicklung – unser Weg

Während der Durchführung eines großen Entwicklungsprojekts, an dessen Ende ein bedarfsgerechter Service für alle Mitglieder stehen soll, hat eine Organisation wie der HeBIS-Verbund zwei Herausforderungen zu bewältigen. Zum einen muss für eine begrenzte Zeit ein erhöhter Personalbedarf gedeckt werden. Weiterhin ist es erforderlich, verteiltes Know-how zu bündeln. Der HeBIS-Verbund hat sich deshalb zu einer Entwicklungskooperation mit zwei großen Bibliotheken, die Know-how und Personalkapazitäten sowohl im IT- als auch im bibliothekarischen Bereich beisteuern können, entschlossen.

Als diese Entwicklungspartner stellten sich die UB Kassel und die UB Frankfurt zur Verfügung. Beide Bibliotheken sind gleichzeitig zwei von fünf Betreibern von HeBIS-Lokalsystemen und decken die Fälle Freihand- bzw. Magazinbibliothek ab, sodass umfassendes Wissen über lokale Gegebenheiten in das Projekt einfließen konnte. Im Gegenzug konnten die UB Frankfurt und die UB Kassel als Erste mit ihren Installationen in den Produktionsbetrieb gehen. Ohne den engen Kontakt zur UB Kassel in der Pilotphase wäre auch die Realisierung der Merkliste über PUMA nicht möglich gewesen.

Zur Anpassung der mobilen Oberfläche für das HDS bot sich die ULB Darmstadt als weiterer Kooperationspartner an, da dort im Rahmen eines LOEWE-Projekts^[11] gerade Know-how im Bereich mobiler Oberflächen gesammelt wurde.

Der HeBIS-Verbundzentrale kam die Aufgabe zu, das Projekt HDS zu koordinieren und den Fortgang in allen Bereichen zu gewährleisten und zu unterstützen. Am Anfang stand eine Vorbereitungsphase. Für das Projekt wurden Meilensteine definiert und die zum Erreichen der Meilensteine notwendigen Aufgaben wurden auf die Entwicklungspartner verteilt. Darüber hinaus wurden vor allen Dingen Voraussetzungen geschaffen. Das betraf sowohl das Einrichten der Hardware und diverser Softwarepakete als auch das Sammeln von Anforderungen, das Auswerten vorhandener Schnittstellen und vieles mehr. Im März 2012 fand dann das Kick-off-Meeting statt, das den offiziellen Beginn der kooperativen Entwicklungsphase markiert.

In der Entwicklungsphase fanden regelmäßige Treffen mit allen Entwicklern und bibliothekarischem Fachpersonal statt, bei denen Aufgaben verteilt, Designentscheidungen getroffen, Anforderungen gesammelt und Probleme bei der Umsetzung von Teilaufgaben diskutiert und ausgeräumt wurden. Um das Zusammenspiel von vielen Entwicklern sicher zu gestalten, wird die Versionierungssoftware Subversion^[12] benutzt. Ergänzend dazu bietet Trac^[13] mit einem Wiki, einer Roadmap und einem Ticketing-System Unterstützung bei der Projektkoordination. Die Kommunikation zwischen den Entwicklertreffen lief hauptsächlich über eine Mailingliste. Eine Projektwebseite^[14] komplettiert das Paket.

Bei EDS erstreckt sich die Kooperation vor allem auf den Informations- und Erfahrungsaustausch zwischen den Profilbearbeitern. Schon beim Aufbau der HDS-Pilotinstallationen hatte sich gezeigt, dass die Profilkonfiguration eine relativ komplexe Aufgabe ist, die gründliche Einarbeitung erfordert und dauerhaft in die lokalen Workflows integriert werden muss. Entsprechend besteht großer Bedarf an Admin-Trainings sowie gegenseitiger Unterstützung. Dem wird mit einer Mailingliste, EDS-Anwendertreffen und Workshops Rechnung getragen, die teilweise auch mit EBSCO vereinbart werden konnten. Darüber hinaus bietet das HDS-Team der HeBIS-Verbundzentrale Hilfestellung bei der Konfiguration der Profile an.

Die erste Projektphase, in der die Entwicklung und Fertigstellung der beiden Pilotinstallationen im Fokus stand, endete im Mai 2013 mit dem Beta-Start der HDS-Installationen Kassel und Frankfurt. Anschließend konnte nach einer kurzen Konsolidierung der Rollout in den weiteren interessierten Bibliotheken gestartet werden. Aus technischen Gründen wurde beschlossen, erst alle HeBIS-Lokalsysteme mit einer Bibliothek anzubinden und danach die restlichen Kandidaten zu versorgen.

Zu Beginn einer neuen Installation vereinbart das HDS-Team der HeBIS-Verbundzentrale ein Treffen mit der lokalen HDS-AG der betroffenen Bibliothek. Beteiligt sind jeweils die lokale IT, besonders die Lokalsystem-Betreuer, die Benutzung und die Medienbearbeitung. Bei diesem Treffen werden die Konfigurationsmöglichkeiten aufgezeigt und mögliche Probleme durch individuelle lokale Anforderungen angesprochen. Im weiteren Verlauf baut die Verbundzentrale eine Testinstallation auf, mit der ein Testbetrieb im erweiterten Mitarbeiterkreis stattfinden kann. Am Ende der Tests wird die Installation evtl. nachgebessert und der Produktionsbetrieb mit Benutzern kann beginnen.

So sehr die kooperative Entwicklung zum Gelingen des Projekts beigetragen hat, gibt es doch immer wieder kollidierende Interessen, die gegeneinander abgewogen werden müssen. Die Pilotbibliotheken haben einen erhöhten Personal- und Zeitaufwand und bestehen deshalb auf einer Lösung, die ihren individuellen Bedürfnissen exakt angepasst ist. Die Verbundzentrale muss hingegen sicherstellen, dass das System den Bedarf aller Mitgliedsbibliotheken abdeckt. Die Bibliotheken, die bereits eine Installation haben, zeigen großes Interesse an der Weiterentwicklung, während für Bibliotheken, die noch auf ihre Installation warten, der Rollout oberste Priorität besitzt. Die Verbundzentrale als Projektkoordinatorin muss außerdem dafür sorgen, dass das System zukunftsfähig bleibt. So gibt es eine komplett neue Version der Software VuFind, die künftig zum Einsatz kommen soll, was aber nur mit viel Arbeitsaufwand zu erreichen ist. Obwohl natürlich auch die Bibliotheken Interesse an der Zukunftsfähigkeit des Systems haben, ist solch ein Aufwand nur schwer zu vermitteln, da sich an der bestehenden Funktionalität zunächst nichts ändert. Wenn in solchen Punkten Entscheidungen getroffen werden müssen, kommt noch hinzu, dass die vorher beschriebenen Kommunikationsinstrumente naturgemäß nur von Bibliotheken benutzt werden, die bereits eine Installation haben oder deren Installation im Aufbau ist. Aus all diesen Gründen hat sich im Laufe des Rollouts gezeigt, dass auch ein Gremium nötig ist, das die inhaltliche Abstimmung und Aufgabenpriorisierung unter Beteiligung aller an einer Installation interessierten Bibliotheken vornimmt. Zu diesem Zweck wurde eine Fach-AG Portal gegründet, die im März 2014 ihre Arbeit aufgenommen hat.

Aktuell sind vier Installationen im produktiven Beta-Test. Neben den Pilotbibliotheken UB Kassel und UB Frankfurt sind das die UB Marburg und die UB Mainz. Zwei weitere Bibliotheken, die ULB Darmstadt und die UB Gießen, planen, im Oktober den Produktionsbetrieb zu starten. Sechs weitere Bibliotheken werden Ende 2014 und im Laufe des nächsten Jahres eine Installation erhalten.

5 Fazit

Dank Kooperation wurde mit dem HDS ein stimmiges und erweiterbares System aufgebaut, das dem Benutzer eine Suchraumerweiterung auf Basis eines Discovery-Service, aber auch die Funktionen des lokalen OPAC in gewohnt hoher Qualität bietet. Das System geht auf die individuellen Besonderheiten der Bibliotheken ein und ist trotzdem verbundweit einsetzbar. Durch den modularen Aufbau ist es auch für kommende Herausforderungen wie veränderte Nutzergewohnheiten durch Touchgeräte und Bedarf an innovativen Oberflächen und Präsentationskonzepten von Spezialbibliotheken gewappnet.