Tag 9 - Suchmaschinen und Discovery-Systeme, Teil 2

Am heutigen Tag stehen die Suchmaschine Solr sowie die Datenintegration ins Discovery-System VuFind im Mittelpunkt. Wir bringen die aus den bisherigen Systemen exportierten Daten in VuFind und lassen sie uns dort im Katalog anzeigen.

Solr

Solr ist eine Suchmaschine, die zu den am meisten verwendeten Suchmaschinen gehört, selbst in kommerziellen Produkten wie Ex Libris Primo steckt Solr.

Solr ist Basis für das Discovery-System VuFind. Solr läuft also im Hintergrund und hat keine eigene Webseite worauf man suchen könnte (es gibt eine Admin-Oberfläche, die ist aber nicht zum Suchen gedacht, sondern nur zu Testzwecken). Um die Volltextsuche zu nutzen braucht es also zusätzlich noch eine Webseite oder eine Software.
(Zu Solr gibt es übrigens ein Handbuch mit einem Tutorial).

Unterschiede Suchindex (z.B. Solr) und Datenbank (z.B. MySQL)

Suchindex und (relationale) Datenbank haben beide eigentlich eine ähnliche Funktion: Daten werden aufgenommen und anschliessend abgefragt. Die Unterschiede finden sich in verschiedenen Schwerpunkten, wie die untenstehende Abbildung (entnommen aus dem gemeinsamen Codi-Dokument zeigt:

Wie die Tabelle zeigt, finden sich Unterschiede zunächst in der Datenstruktur. In Suchindexen werden die Dokumente als flache Dokumente abgespeichert, das bedeutet, dass zwischen den Dokumenten keine Beziehungen bestehen. Im Gegensatz dazu in der Datenbank, hier entstehen relationale Datensätze, es werden Beziehungen zwischen den Datensätzen hergestellt, entsprechend ist es strukturierter und die Abfragen können darauf abgestimmt erfolgen und gefiltert werden.

Die Art der Abfrage erfolgt bei der Datenbank als Glyphenvergleich, die Datenbank gleicht also das Eingegebene mit den in der Datenbank existierenden Daten ab und gibt dann die Treffer aus. Der Suchindex hingegen basiert auf einer lexikalischen Suche, das bedeutet, dass das Eingegebene mit einer Grammatik versehen wird und entsprechend gesucht werden kann und somit auch sinngemäss gesucht werden kann, man muss nicht das Wort exakt treffen. Das ist ein grosser Vorteil von Suchindexen.

Ein Nachteil hingegen ist, dass bei einem Suchindex nicht festgestellt werden kann, ob die Daten konsistent sind, sie können nicht gespeichert werden, wie dies in einer Datenbank der Fall ist. Datenbanken bieten also eine gewisse Transaktionssicherheit, bei einem Verbindungsproblem z.B. bleibt die Datenkonsistenz erhalten.

Entsprechend enthält ein Suchindex statische Daten, ein Dokument an sich kann nicht verändert werden, sondern es werden Kopien der verschiedenen Versionen angelegt und indexiert. In einer Datenbank können die Daten verändert werden, wobei der ganze Datensatz aktualisiert wird.

Aus all diesen Punkten ergibt sich ein unterschiedlicher Schwerpunkt bei der Verwendung: Ein Suchindex eignet sich für die Suche nach einzelnen Datensätzen in einem grossen Datenbestand (Retrieval). Eine Datenbank eignet sich für die die konsistente und dauerhafte Ablage und Verwaltung von Daten (Storage), mit den für Datenbanken vier fundamentalen Operationen create, read, update und delete – kurz CRUD.

Übung: Suche in VuFind und Solr (Admin-Oberfläche und Terminal)

Die Suche in VuFind und Solr nach «psychology» ging rasch und zeigte dieselben Ergebnisse an, nämlich drei. Sofort aufgefallen ist, dass die Anzeige bei VuFind von der Oberfläche her übersichtlicher gehalten ist. Die Suche auf der Admin-Oberfläche in Solr hingegen ist nicht ganz so übersichtlich, aber das erstaunt kaum, schliesslich ist diese Oberfläche ja nicht für die Suche gedacht. Die Logdatei von Solr im Terminal blieb mir recht rätselhaft (vielleicht hat es auch nicht alles richtig angezeigt, und/oder ich habe etwas falsch gemacht, zumindest ist bei mir der Text im Terminal viel kürzer als auf dem geteilten Screen aus der Vorlesung im Webex zu sehen).

Die Suche in VuFind gestaltet sich übersichtlich.

Screenshot der Suche in Solr in der Admin-Oberfläche.

Ansicht aus der Logdatei der Suche in Solr.

Was ich nun mit dieser Logdatei im Terminal anfangen soll? Das Mitverfolgen in Webex der gemeinsamen, auf die Übung folgenden Besprechung brachte dann etwas Licht ins Terminaldunkel: VuFind sucht nämlich in verschiedenen Feldern. Im Terminal ist dann die Gewichtung der Felder zu erkennen (jeweils die Zahl hinter dem ^), dadurch werden dann z.B. bestimmte Titel weiter oben angezeigt, je nach dem welche Felder weiter oben im Ranking sind. Jedoch ist es nicht einfach, festzulegen welche Felder wie gewichtet werden sollen; am sinnvollsten ist es, dies nach den Nutzer*innen auszurichten. Dies kann kaum mathematisch berechnet werden, sondern muss unter Umständen auch ausprobiert werden.

Datenintegration

Nachdem wir die sich aus der vorherigen Übung in VuFind sich befindenden Daten gelöscht haben, ging es daran, unsere Daten aus Koha, ArchivesSpace und DSpace zu importieren. Dazu habe ich die zur Verfügung gestellten Beispieldaten genutzt, da bei mir der Datenexport ja nicht vollumfänglich funktioniert hatte.

Die Übung lief gut an und schien funktioniert zu haben. Der Datensatz aus koha wurde mir in vuFind nun angezeigt:

Die Datensätze aus ArchivesSpace und DSpace waren wie geplant und erwartet (noch) nicht in vuFind enthalten - zu Übungszwecken enthielten diese nämlich Fehler in den Datensätzen, was einen Import verhinderte. Im Terminal werden die Fehler angezeigt. Für ArchivesSpace und DSpace erschien dieselbe Fehlermeldung:

Ich vermutete aufgrund der Angabe id und null, dass da irgendein Feld nicht ausgefüllt worden war. Doch welches Feld genau? Und wie kann ich das beheben? Ich war gespannt auf die Auflösung.

Auflösung: Der Entscheidende Hinweis steckt hierin: Document is missinig mandatory uniqueKry field: id. Im Schema von Solr wurde das Feld id (Idenitfier) als verpflichtend und mit einem eindeutigen Key zu belegen festgelegt. Das Feld id entspricht dem Marc-Feld 001. Nur ist das in Marc kein Pflichtfeld, entsprechend erscheint beim Validieren der Marc-Daten keine Fehlermeldung, wenn 001 nicht ausgefüllt ist. Solr und somit VuFind hingegen erwarten ein ausgefülltes Feld.

Wie ist dieses Problem zu lösen? Das Feld in den Daten aus ArchivesSpace und DSpace manuell nachbearbeiten oder ein anderes Feld als Grundlage für den Identifier nehmen.

Und damit beende ich den heutigen Tag. Das ist ein guter Schluss, wir haben den Höhepunkt und Ziel des Kurses (siehe Schaubild) erreicht.