Wer sucht, der findet? Für Recherche in digitalen Ressourcen gilt dieses Sprichwort nur bedingt. Allein die Möglichkeit, auf unüberschaubare Mengen von Information zugreifen zu können, genügt nicht – ihre Zugänglichkeit entscheidet darüber, wie Daten ausgewertet und für Forschung verwendet werden können. Da sich Datenbank-Einträge mithilfe klassischer Websuchmaschinen wie Google nicht unbedingt finden lassen, zählt das Durchsuchbarmachen zu den zentralen Aufgaben beim Aufbau einer Datenbank. Ein stichprobenartiger Blick in einige für die Geschichtswissenschaft relevante Datenbanken offenbart, dass hier deutlicher Nachholbedarf besteht.
Die folgende Systematik von Problemfeldern versteht sich als konstruktive Kritik: Sie möchte aus Sicht einer Nutzerin Impulse geben, wie die Funktionalität einer Suchoberfläche ohne besonderen Aufwand erhöht werden kann. Ergänzende Vorschläge über die Kommentarfunktion sind herzlich erwünscht!
Kombinierbarkeit
Um Jahreszahlen oder Daten zu filtern, bieten einige Datenbanken Dropdown-Menüs mit Single-Choice-Option an (z.B. der Katalog zur Chorbibliothek der Lübecker St. Marienkirche von Kerala J. Snyder: „The Choir Library of St. Mary’s in Lübeck, 1546-1674. A Database Catalogue“). Wer für den Zeitraum einer Dekade oder gar eines ganzen Jahrhunderts sucht, muss daher viele einzelne Datenabfragen durchführen. Deutlich effizienter lässt sich suchen, wenn ein Zeitraum angegeben werden kann. Die Suche verliert dabei nicht an Präzision, sofern es möglich bleibt, den Zeitraum auf ein Jahr oder ein Datum einzugrenzen.
Ebenfalls hinderlich sind Suchoberflächen, die zu wenig Möglichkeiten zum Einschränken der Suche bieten: Wird lediglich ein Suchfeld angeboten, das beispielsweise für eine Bibliographie nur entweder nach Titel, nach Autor, nach Schlagwort oder nach Erscheinungsdatum suchen lässt (wie bei der Bibliografía Mesoamericana der Fall), kann es notwendig werden, die Suchergebnisse händisch nach einer eigentlich suchbaren Kategorie durchzusortieren.
Wer die Datensätze dennoch mehrdimensional filtern möchte (beispielsweise nach Autor und Datum), kann nach einer Suche nach dem Autor, falls vorhanden, eine Sortierung nach Datum wählen und dann zu den gewünschten Ergebnissen scrollen. Lässt sich die Sortierung nicht einstellen, kann ggf. die Browser-Funktion „Seite durchsuchen“ oder „In Seite suchen“ Abhilfe schaffen: Die Ergebnisse einer Suche nach dem Autorennamen könnten so nach einer bestimmten Jahreszahl durchleuchtet werden. Allerdings funktioniert diese Strategie nur, wenn die Jahreszahl direkt in der Ergebnisübersicht angezeigt ist – was zum nächsten Kritikpunkt überleitet:
Such- und Sichtbarkeit aller verzeichneter Spaltennamen
Besonders wenn eine Datenbank viele Spalten pro Datensatz verzeichnet, ist es natürlich sinnvoll, Nutzende nicht mit einer Ergebnisliste zu überwältigen, die selbst 60-Zoll-Bildschirme sprengen würde. Wichtig ist jedoch, dass die Datenbank ihren Informationsnutzen durch limitierte Suchkategorien nicht künstlich beschränkt! Alle Spalten, die verzeichnet sind, sollten sich auch durchsuchen lassen – und zwar spezifisch nach den einzelnen Spalten. Ansonsten verliert die Suche an Präzision: So bleibt zur Eingabe von Erscheinungsdatum, Erscheinungsort und sogar Schlagworten in der Suche der Digitalen Sammlungen Bielefeld nur die Restkategorie „Alle Felder“. Das ist insofern problematisch, als dass sich beispielsweise nicht zwischen in der Stadt Detmold publizierten oder Detmold thematisierenden Werken unterscheiden lässt. Besonders komfortabel ist eine Suche hingegen dann, wenn sich die Suchkategorien nach Belieben ein- und ausklappen lassen, sodass die Übersichtlichkeit nutzerdefiniert erhalten bleibt.
Es lohnt sich außerdem, (Erst-)Nutzende der eigenen Datenbank etwas an die Hand zu nehmen. Dazu tragen eine übersichtliche Gestaltung und eine prominent platzierte Kurzbeschreibung des Datenbankinhalts ebenso bei wie Suchvorschläge in Freitextfeldern und eine präzise Benennung aller Suchfelder. Hier treten auch die Vorteile eines Dropdown-Menüs (mit der Möglichkeit zur Wahl mehrerer Items) zu Tage: Europeana bietet beispielsweise an, durch ein Dropdown-Menü einzusehen, welche Dateiformate unter Berücksichtigung bereits vorgenommener Filtereinstellungen überhaupt zur Verfügung stehen.
Reguläre Ausdrücke
Nutzerspezifische Suchfunktionalität lässt sich mit geringem Aufwand vergrößern, indem die Suche mit regulären Ausdrücken ermöglicht wird. Leider ist das in überraschend vielen, auch bekannten Datenbanken nicht gegeben – oder die Anleitung nur über große Umwege auf versteckten Hilfeseiten zu finden. Solche datenbankspezifischen Anleitungen sind nötig, weil unterschiedliche Datenbanken gänzlich verschiedene Syntaxen nutzen. So lassen sich im Katalog der Universitätsbibliothek Freiburg mit einem simplen „a OR b“ zwei Alternativen in der Suchanfrage angeben, während für Europeana eine komplexe Konstruktion der Form „where:(a OR b)“ notwendig ist. Für neue Datenbanken wäre es sehr wünschenswert, wenn mit regulären Ausdrücken gesucht werden könnte, die einem einheitlichen Standard folgen.
Wer suchet, der erfindet!
Diese Vorschläge hoffen darauf, beim Aufbau neuer oder der Überarbeitung bestehender Datenbanken bedacht zu werden. Was aber können Sie tun, wenn die Aufbereitung einer Datenbank die für Sie benötigten Suchfunktionen nicht ermöglicht? Auch mit wenig informatischen Kenntnissen lassen sich die Funktionalitäten der Suchoberflächen an die eigenen Rechercheziele angepasst erweitern. Das folgende Beispiel soll dies illustrieren und zum DIY motivieren: Stellen Sie sich vor, Sie interessieren sich für die Orgeln des 19. Jahrhunderts, die im Schweizer Kanton Luzern gebaut wurden und besondere technische Eigenschaften aufweisen, wie z.B. einen besonders kleinen Tastenumfang der Manuale und Pedale. Nun haben Sie im Datenbankinformationssystem die Orgeldatenbank des Orgeldokumentationszentrums der Hochschule Luzern entdeckt. Angaben zum Tastenumfang einer Orgel finden Sie jedoch erst, nachdem Sie eine Detail-Seite in einem neuen Tab öffnen, wo alle zur Orgel vorliegenden Daten dargestellt werden. Das bedeutet, Sie müssten für jeden der 1.100 Einträge so verfahren und händisch die Werte für Tastenanzahl der Manuale, Pedale sowie alle analyserelevanten Zusatzinformationen wie Standort, Erbauer etc. in eine eigene Liste übertragen. Haben Sie dafür Zeit und Motivation?
Gleiches Backend, neues Frontend
Die allermeisten Datenbanken sind in ein Frontend und ein Backend aufgeteilt. Das Frontend besteht aus den sichtbaren Teilen der Datenbank: Der Suchmaske mit ihren Feldern und der Liste der Ergebnisse, idealerweise beides ansprechend gestaltet und nutzerfreundlich strukturiert. Das Backend einer Datenbank besteht aus den puren Daten in Rohform – für Menschen schwer zu lesen, für Maschinen jedoch kein Problem. Ihre Eingaben aus den Maskenfeldern werden nun in eine Anfrage an das Backend kodiert, das Backend sammelt die Ergebnisse und liefert sie anschließend in Rohform (häufig als JSON oder XML) zurück an das Frontend, das Ihnen daraus die sichtbare Ergebnisseite zusammenfügt. Besonders, wenn die Websites Antworten auf Suchanfragen im JSON-Format zurückgeben, kann darauf beispielsweise mit JavaScript eine eigene Suche konstruiert werden. Sie tauschen sozusagen das Frontend der Datenbank aus, kommunizieren aber weiterhin mit demselben Backend.
Für das Orgelbeispiel gehen Sie wie folgt vor:
- Ermitteln Sie aus dem Frontend die Adresse des Backends.
- Über Ihre eigene Suchmaske stellen Sie nach Ihrem Belieben eine Anfrage an das Backend, deren Ausführung allerdings einige Minuten dauern kann. Für das Beispiel lautet diese: https://orgeldokumentationszentrum.ch/backend/v3/recherche.php?kantone=lu&yearFrom=1801&yearTo=1900&=
- Die Antwort des Backends enthält nun mehr Daten als die Ergebnisliste des offiziellen Frontends – das ist Ihr Trumpf: Nun können Sie die Liste selbst entweder mit einem selbstgeschriebenen Programm nach allen Daten durchsuchen – beispielsweise lässt sich mit dem regulären Ausdruck 3|4 filtern, ob drei oder vier und somit viele Manuale vorliegen – oder Sie importieren die Daten in Excel, um sie dort zu sortieren und zu filtern.
Vielleicht sind die Datenbankbetreibenden jedoch auch bereit, Ihnen Ihre Anfrage zu beantworten oder Ihnen die Backend-Adresse mitzuteilen, sodass Sie gleich loslegen können.
Mein Beispiel der Orgeldatenbank der Hochschule Luzern finden Sie hier.
[1] Der Code ist durch „Seitenquelltext anzeigen“ einsehbar und darf gern als Anregung für das Programmieren eigener Suchmasken genutzt werden.
[1] Herzlich möchte sich die Autorin bei Roman Wetenkamp bedanken, der seinen Server für diese Website zur Verfügung stellt.