Wenn ich mir meine Discovery-Projekte gerade anschaue, avanciert eine Frage derzeit zu einer Art Modethema – und zwar sowohl bei ganz kleinen als auch sehr großen Häusern: Wie soll der Suchraum zugeschnitten sein, oder anders gefragt: Welche Bestandsdaten und sonstigen Quellen soll das Discovery-System zugänglich machen? Da sind kleine Spezialbibliotheken, die eigene Datenbanken mit Rezensionen pflegen und diese Inhalte auch über das Discovery-System zugänglich machen wollen – oder große Unibibliotheken, die eine Suche in alle möglichen Richtungen einschränken (nur Hochschulbibliographie) oder ausweiten (jetzt bitte mal den ganzen Verbund) wollen. Ein typisches Beispiel dafür, wie im Zuge der Einführung von Discovery-Systemen strategische und technische Herausforderungen zusammentreffen.
Ich nehme an, dass kommerzielle Index-Anbieter durchaus von sich behaupten würden, dass ihre Lösungen das Versprechen eines „One-Stop-Shops“ einlösen, also bibliografische Daten aus Quellen mit großer Reputation (Content aus Fachbibliografien, JSTOR) genauso durchsuchbar machen wie Open Access-Inhalte (Base) und lokale Bestände. Insbesondere für die lokalen Bestände wünschen sich Bibliotheken aber in der Regel sehr individuelle Aufbereitungen – konfigurierbare Standortfacetten, maßgeschneiderte Auswertung der lokalen Sacherschließung, individuelle Auswahl von Zugangslinks, um nur einige wenige Beispiele zu nennen. Aus diesem Grund wird häufig entschieden, zwei Reiter anzubieten – für den eigenen lokalen Bestand und für alles darüber hinausgehende, also insbesondere Artikel, und dabei bei letzterem dann auf einen kommerziellen Index zurückzugreifen. Bei diesen hat sich meiner Einschätzung nach EDS von EBSCO durchgesetzt, zumindest zahlenmäßig mit astronomischen 3,7 Billionen Datensätzen.
Dabei kann aktuell niemand sonst mithalten, auch nicht die (relativ) neuen (halb-) offenen Zitationsindices, die vormaligen Platzhirschen wie Web of Science und Scopus Beine machen und von denen auch bibliothekarische Systeme lernen können, wie in dieser kleinen Konkurrenzbeobachtung aus dem März 2020 schon einmal beleuchtet. Aber zurück zu den lokalen Beständen, denn auch hier gibt es zumindest in Deutschland einen Platzhirschen, und der heißt K10plus Zentral. Der kostenfrei (!) nutzbare Index besteht zu etwa einem Viertel aus solchen Bestandsdaten, und zwar von allen GBV- und BSZ-Bibliotheken. Wer hier dabei ist, kann davon ausgehen, dass sich die eigenen Daten mit sehr vertretbarem Aufwand über Oberflächen-Systeme wie Lukida oder VuFind, gern auch in Flavors wie beluga, recherchierbar und präsentierbar machen lassen. Und auch in Punkto bibliografische Daten wächst und gedeiht der K10plus Zentral – langsam zwar, aber nachhaltig, wie sich an der Arbeit der AG Discovery nachverfolgen lässt.
Welche Optionen es für Bibliotheken jenseits des K10plus gibt, schauen wir weiter unten an. Vorher müssen leider noch ein paar Haare in dem K10plus-Zentral-Suppentopf identifiziert werden:
- Jenseits der Frage, ob die Aufteilung von Suchergebnissen auf einzelne Reiter eine kluge Sache ist: Der K10plus Zentral basiert auf Solr, und in VuFind gibt es für Solr-Indices fertige Treiber („Record Driver“). Wie schon gesagt ist es vielerorts die gängige Praxis, Bestandsdaten in einem Reiter zu präsentieren und bibligrafische Daten in einem zweiten Reiter. Wenn man dann noch einen dritten (oder gar noch weitere) Reiter möchte, um zum Beispiel auch einen kommerziellen Index anzubieten, muss man immer schauen, was technisch möglich ist – es sind nicht notwendigerweise alle Kombinationen technisch realisierbar.
- Viele der Kollektionen im K10plus haben keine Besitznachweise. Für sinnvolle Zugangsinformationen braucht es zusätzliche Lösungen – Link Resolver, Journals Online and Print, OpenURL-Gateway, der Webdienst DAIA+ aus der beluga core-Community. Das Problem erwähne ich stellvertretend auch dafür, dass man Discovery und Delivery (also Verfügbarkeit) immer zusammen denken sollte, denn der schnelle Weg zum Volltext muss ein strategisches Ziel sein, wenn man neben Google Scholar und Co. mit bibliothekarischer Discovery überhaupt einen Blumentopf gewinnen will.
- Das angesprochene langsame Wachstum des K10plus Zentral bedeutet leider auch, dass für die Integration neuer Quellen (eigene Datenbanken, Verlagsdaten) einiges an Zeit und Geduld investiert werden muss. Zwar ist das Metadaten-Schema des Index offen und insbesondere für die Lieferung von Artikeln gibt es eine sehr gut handhabbare Vorlage, aber bis zu einer Bereitstellung von neuen Daten vergeht erfahrungsgemäß vor allem auch aus technischen und rechtlichen Gründen viel Zeit.
- Möglicherweise lassen sich mit dem K10plus Zentral auch nicht alle Wünsche an das Eingrenzen und Ausweiten von Treffermengen realisieren – zumindest nicht in jeder Kombination und mit jeder Suchoberfläche. So gibt es in der beluga core-Community zum Beispiel einen „Bibliotheksselektor“, mit dem man etwa standardmäßig den Bestand von Bibliothek X einstellt und eine nachträgliche Ausweitung auf weitere Bibliotheken der Region (Hobsy, Hamburger Regionalkatalog) ermöglichen kann. Dieser Selektor – technisch gesehen ein Filter und keine Facette - basiert auf einem Feld aus dem Index, also zum Beispiel in der GBV-Welt einer ILN, dem Code für eine Bibliothek. Es ist aber nicht möglich, hier verschiedene Felder zu Grunde zu legen und zu kombinieren. Wenn also beispielsweise die Daten aus einer Hochschulbibliographie ein anderes Selektionskriterium haben, dann wäre eine nachträgliche Einschränkung darauf mit dem Bibliotheksselektor nicht möglich, man bräuchte dann also noch eine zusätzliche Facette.
Auch für Bibliotheken mit Besitznachweisen im K10plus Zentral ist es also unumgänglich, sich einige Gedanken über den Zuschnitt des Suchraums zu machen. Mehr ist vielleicht nicht immer mehr – zumal wenn das Ziel des „One-Stop-Shops“ ohnehin unerreichbar ist, weil nicht alle relevanten Datenquellen ihren Weg in einen Index, egal ob kommerziell oder frei verfügbar finden können, wollen oder sollen. Bevor man sich beispielsweise darüber ärgert, dass der „Munzinger“ nicht im K10plus Zentral ist, sollte man einen Schritt zurücktreten und sich fragen, welchen Mehrwert dieses Nachschlagewerk in dem geplanten System haben würde und ob dieser Wert strategisch eine zentrale Rolle spielt.
Natürlich kann man auch die Ärmel hochkrempeln und sich einen eigenen Index bauen. Einen Eindruck davon, was es dafür an Tools und Kompetenzen braucht, kann man sich in Felix Lohmeiers Kurs „Wir bauen uns einen Bibliothekskatalog“ verschaffen – der ist auch dann sinnvoll, wenn man nicht ernsthaft plant, selbst Hand anzulegen, sondern einem Dienstleister wie uns die Arbeit zu überlassen. Der eigene Index ist manchmal leichter als erwartet – Bestandsdaten aus gängigen Bibliothekssystemen einer halbwegs neuen Generation kommen in der Regel gut hinüber in die Suchmaschinenwelt, und es ist auch nicht unmöglich, in Excel geführte Bestandstabellen, wie sie in manchen sehr kleinen Bibliotheken geführt werden, zu konvertieren. Die Herausforderungen fangen meistens erst danach an: Wie hält man den Index aktuell? Kommen so wichtige Daten wie lokale Schlagwörter sinnvoll im Index an oder ist hier eine Nachbearbeitung erforderlich, um die Daten sinnvoll zu präsentieren? Wie dedupliziert man die Daten? Wo werden Index und Suchoberfläche gehostet und gepflegt? Wie funktioniert das Zusammenspiel mit dem Ausleihsystem? Auf alle diese Fragen gibt es gute und praktikable Antworten, so dass ein eigener Index unterm Strich kein Hexenwerk ist – aber Projekte mit eigenem Index kommen in der Regel teurer als solche mit einem bestehenden Index. Über den Daumen gepeilt ist hier mit wenigstens 100 Stunden zu rechnen – und steigen mit der Anzahl an zu integrierenden Datenquellen. Und auch hier kommt man im Vorfeld um konzeptionelle und strategische Überlegungen nicht herum: Welche Sucheinstiege und Facetten sollen angeboten werden? Will man parallel auch einen bestehenden Index wie K10plus Zentral oder EDS nutzen?
Discovery-Systeme beschäftigen Bibliotheken seit über 15 Jahren. Die ersten Jahre waren geprägt von einer relativ großen Euphorie, insbesondere aus der technischen Ecke – auf einmal waren Indexierungswerkzeuge und bald auch eine Lösung wie VuFind frei verfügbar und konnten schnell das Potenzial aufzeigen, das eine neue, integrierte Art des Suchens in bibliografischen Daten bietet. Sinnbildlich für diese Zeit ist zum Beispiel tub.find aus Hamburg-Harburg, das zunächst als Aprilscherz entstand.
Auf diese Zeit folgte eine Phase der Ernüchterung. In diese Phase fielen zwar Erfolge wie standardisierte Schnittstellen für den Austausch von Verfügbarkeits- und Kontoinformationen zwischen Discovery- und Bibliothekssystemen. Gleichzeitig klar wurde aber auch klar, dass manches nicht so einfach ist wie gedacht – auch aus vielen anderen Gründen, denn auch die internen Akzeptanzprobleme der Systeme wurden rasch offenbar und zuletzt haben die Herausforderungen rund um die Forschungsunterstützung sowohl die Entscheidungstragenden als auch diverse Bibliotheksabteilungen stark gefordert.
Dennoch haben es die Discovery-Systeme geschafft, sich vielerorts gegen die alten Kataloge durchzusetzen – oder aber auch die Entwicklung von Katalogmodulen in konventionellen Lösungen beeinflusst. So hat Koha beispielsweise ein ausgesprochen anständiges OPAC-Modul. Wer aber andere Bibliothekssysteme nutzt und/oder perspektivisch zu Folio wechseln wird, kommt vermutlich um die Beschäftigung mit Discovery-Systemen nicht herum – genauso wenig wie die kleinen Verbünde von Spezialbibliotheken, die gemeinschaftliche Sichten auf ihre Bestände anstreben, aber hausintern sehr verschiedene Lösungen für die Erfassung und Verwaltung von Beständen nutzen.
Und letztlich treiben auch die erwähnten forschungsnahen Services die Entwicklung von Discovery-Systemen an, denn mit diesen Services lassen sich die Discovery-Systeme vielleicht in Zukunft wirklich zu genau denjenigen Sucheinstiegen mit starkem lokalen Bezug weiterentwickeln, als die sie sich einst erträumt wurden.
