Suchmaschinen und Discovery-Systeme 2/2

Einordnung von Solr
Solr bildet gemeinsam mit Elasticsearch den Standard, der in der Praxis verwendet wird. Auch wir nutzen die Suchmaschine Solr – gemeinsam mit dem Discoverysystem VuFind, das wie auch viele kommerzielle Lösungen (wie z.B. Ex Libris Primo) auf Solr basiert. Solr selbst hat zwar auch eine integrierte Suchoberfläche, diese dient aber eher Demo-Zwecken und ersetzt somit kein Discoverysystem. VuFind ist also das System, mit dem Nutzer/innen in Berührung kommen und Solr die Technik, die dahintersteckt. Was wir im Kurs nicht tun aber üblicherweise Usus ist: Vor dem Datenimport in eine Suchmaschine wird in einem Schema festgelegt, welche Felder existieren und welche Datentypen diese beinhalten dürfen. Den umgekehrten Weg (“schema-less”) gibt es jedoch auch: Die Daten werden importiert und Solr versucht dann das Beste daraus zu machen und die Inhalte den Feldern zuzuordnen. Beides geht, wobei man nur bei der ersten Variante die Kontrolle darüber hat, was Solr genau mit den Daten macht. Auch bringt das Festlegen von Datentypen Vorteile: definiert man z.B. 2020-12-24 als Datumsfeld, kann später auch in Zeiträumen gesucht werden, während dies mit einem blossen String “2020-12-24” nicht möglich ist.

Funktion von Suchmaschinen am Beispiel von Solr
Was ist eigentlich der Unterschied zwischen einem Suchindex und einer Datenbank bzw. wann verwendet man was? Grundsätzlich speist man in beide Systeme Daten ein und ruft sie später wieder ab. Die Schwerpunkte sind jedoch verschieden:

Suchindex (z.B. Solr):

  • Struktur: flache Dokumente, die mehrere Eigenschaften haben aber keine Beziehungen zu anderen Dokumenten aufweisen. Ein Datensatz entspricht somit einem Objekt, das für sich allein steht.
  • Abfrage: beherrscht lexikalische Suche, wodurch eingegebene Werte als Begriffe inkl. deren Grammatik verstanden werden. Dies ermöglicht es, dass z.B. Verben auf deren Grundform reduziert werden und eine Suche nach “las” auch “gelesen” als Treffer bringt.
  • Es gibt keine Kontrolle darüber, ob die enthaltenen Daten in sich konsistent sind. Wenn beim Indexieren eines Objekts ein Fehler auftritt, z.B. der Server abbricht, ist der Suchindex hinüber und dieser muss neu aufgebaut werden. Ein Suchindex ist daher eher ein flüchtiger Speicher und nicht darauf ausgelegt, dass Daten dort über einen längeren Zeitraum hinweg sicher gespeichert werden können.
  • Daten sind statisch und können nicht verändert werden. Indexiert man ein gleiches Objekt erneut, wird eine Kopie angefertigt und das vorherige gelöscht.
  • Einsatzzweck: Eignet sich sehr gut für Retrieval, also die gezielte und schnelle Suche nach Objekten, die bestimmten Kriterien entsprechen.

Datenbank (z.B. MySQL):

  • Struktur: relationale Datensätze, sodass Informationen zu einem Objekt ggfls. in verschiedenen Datensätzen vorliegen, die untereinander in Beziehung stehen. Diese Verknüpfungen können dann auch abgefragt werden, z.B. Suche alle Werke, die von Picasso hergestellt wurden und aktuell ausgestellt sind.
  • Abfrage: es wird ein Glyphenvergleich gemacht, also die eingegebene Werte (ggfls. Verwendung von Suchoperatoren) werden 1:1 mit den vorhandenen Daten abgeglichen. Ganz so starr muss die Suche in Datenbanken jedoch auch nicht sein: In der neuen Version von MuseumPlus gibt es eine “Ähnlichkeitssuche”, die bspw. “Hodler” vorschlägt, wenn man sich mit “Holder” vertippt hat. Aber klar, dieses Feature kommt natürlich nicht an die Funktionen eines Suchindexes ran und ob da wirklich etwas Schlaues dahintersteckt, kann ich nicht beurteilen. Mir fällt gerade auch noch ein Statement eines Mitarbeiters im Kunstmuseum ein, der im Rahmen unserer Umfragen bez. Anforderungen an das Nachfolgesystem von MuseumPlus Classic gesagt hat, dass er sich eine Suche wünsche, die Google-like (Suchindex) ist. Dass die beschränkte Performanz hauptsächlich mit der Art und Weise zu tun hat, wie die Daten abgelegt sind, war mir vorher nicht bewusst. Eine Suche in MuseumPlus wird also wohl nie wie eine Suche in Google werden aber vielleicht geht ja noch was.
  • Es wird eine Transkationssicherheit geboten: Bei Auftreten eines Fehlers, z.B. Serverabsturz, wird garantiert, dass der Datenbestand danach immer noch in sich konsistent ist. Ein fehlerhafter Datensatz beeinträchtigt somit nicht die Konsistenz des gesamten Datenbestandes.
  • Daten können direkt aktualisiert und verändert werden, ohne dass eine Kopie erstellt werden muss.
  • Einsatzzweck: Für Storage geeignet, also das persistente und konsistente Ablegen von Daten. Darin enthalten sind die sog. CRUD-Operationen (Create, Read, Update, Delete).

Übung: Suche in VuFind vs. Suche in Solr
Wir starteten eine Suche in VuFind nach psychology unter http://localhost/vufind. Denselben Term suchten wir als allfields:psychology in der Admin-Oberfläch von Solr unter http://localhost:8983/solr/#/biblio/query. Parallel dazu, also nachdem wir die Suchanfrage abgeschickt haben, schauten wir im Terminal, was genau im Hintergrund passiert (Log-Datei):

less +F /usr/local/vufind/solr/vufind/logs/solr.log

In den Oberflächen von VuFind und Solr werden dieselben Treffer angezeigt, wobei in Solr nur die reinen Daten gezeigt werden, während in VuFind z.B. die Treffer highlighted sind. Diese unterschiedliche Darstellung spiegelt sich auch im Terminal: Das Logfile zur Suche in Solr sagt nur, was die Suchanfrage war und wie viele Treffer es gibt. Im Logfile zur Suche in VuFind wird zusätzlich auch dokumentiert, was in den Ergebnissen highlighted wurde (mit START_HILITE bzw. END_HILITE).

Übung zur Datenintegration
Zum Schluss haben wir Beispieldaten aus Koha, ArchivesSpace, DSpace und DOAJ in VuFind importiert. Hierfür mussten zunächst die zuvor eingespielten Testdaten gelöscht werden:

/usr/local/vufind/solr.sh stop
rm -rf /usr/local/vufind/solr/vufind/biblio/index /usr/local/vufind/solr/vufind/biblio/spell*
/usr/local/vufind/solr.sh start
  1. Neue Beispieldaten laden und entpacken.
  2. Vor dem Import die Datei marc_local.properties bearbeiten, um die Daten unterschiedlichen Collections zuzuweisen. Dies muss bei jeder Datenquelle gemacht werden, sodass man später sieht, welche Daten aus welcher Quelle kommen. 
    gedit /usr/local/vufind/import/marc_local.properties
  3. Importskript starten. Auch hier muss man den Befehl je Datenquelle leicht anpassen. Beispiel für Koha: 
    for f in ~/Downloads/vufind-testdaten/koha/*.xml; do /usr/local/vufind/import-marc.sh $f; done

Der Import der ArchivesSpace- und DSpace-Daten hat dabei fehlgeschlagen. Im Terminal verriet die Fehlermeldung “Document is missing mandatory uniqueKey field: id”.
Datenintegration

Das Problem war, dass in diesen Daten ein MARC-Feld nicht vorhanden war: 001 Control Number. Dieses Feld ist zwar nicht verpflichtend – wenn man also diese MARC-Dateien validieren würde, würde keine Fehlermeldung erscheinen –, trotzdem wird es von VuFind erwartet. Lösung: Das Feld händisch in den Dateien ergänzen (oder mit OpenRefine).

Wie sieht ein perfekter Katalog aus?
Der perfekte Katalog ist deshalb schwierig zu konzipieren, da es immer unterschiedliche Nutzer/innen mit unterschiedlichen Bedürfnissen und Zielen geben wird. Für jemanden, der nur mal schnell stöbern möchte was es so gibt, ist ein einfacher Suchschlitz sehr willkommen. Am besten leuchten dann noch die wichtigsten Treffer hervor. Eine andere Person sucht Literatur zu einem Spezialgebiet und möchte Facetten, Filter, Schlagworte nutzen um ein möglichst detailliertes und relevantes Ergebnis zu erhalten. Ein guter Katalog bietet Möglichkeiten für beide Szenarien; also einfache Einstigesmöglichkeiten und Expterten-Funktionen. Es sollte auch die Möglichkeit geboten werden, erfahren zu können, wie die Trefferliste zustande kommt: Einsicht in das Katalogisat im MARC21-Format (gab es in Swissbib), sodass man z.B. die vergebenen Schlagworte nachvollziehen kann, oder in die Relevanzsortierung.

Marktüberblick Discovery-Systeme
Der jährliche Library Systems Report im ALA Magazine von Marshall Breeding, den wir ja bereits kennengelernt haben, informiert über Discoverysysteme im internationalen Umfeld. Einen guten Überblick bietet auch eine Statistik, die im Rahmen des Reports erstellt wurde. Für die Schweiz ist v.a. das Discovery-System Primo VE von Ex Libris Alma zu nennen, das durch die Swiss Library Service Platform eingeführt wurde. Das neue Rechercheportal heisst swisscovery.


Quellen: BAIN-Skript 6