My BAIN Blog [Bibliotheks- und Archivinformatik]

Ein Lerntagebuch für den Kurs Bibliotheks- und Archivinformatik HS2020, übernommen von Dozent Lohmeier

Follow me on GitHub

Vorletzter Unterrichtstag

Wir werden im zweiten Teil dieses Blocks die Suchmaschine SolR und das Discovery-System VuFind behandeln, machen eine Übung zur Datenintegration all unserer bisheriger Daten in VuFind, diskutieren miteinander, was denn ein guter Katalog beinhalten sollte, und schauen uns wieder um, was es noch für andere Discoverysysteme auf dem Markt gibt. Oder zumindest ist das so geplant. Bei mir hat sich die virtuelle Maschine aufgehängt. Nach einer gewissen Zeit ohne irgendeine Rückmeldung habe ich es also abgeschaltet und wollte wieder über die VPN hinein, aber dann sagt das Ubuntu, dass mein Passwort falsch sei. Das ist sehr ärgerlich, weil ich die Übungen nicht mitmachen kann. Aber zum Glück gibt es ja noch Aufzeichnungen (und später hat die IT der FHGR das Problem auch behoben). Zu LIDO erfahren wir noch zudem, wie man ein Crosswalk (siehe Tag 6) erstellen würde, wenn man damit arbeitet.

Fachbegriffe nicht durcheinanderbringen

Umgangssprachlich mag man das so salopp sagen, aber ein Discovery System ist keine Suchmaschine. Und ein Katalog ist kein Bibliothekssystem. Diese fehlerhafte Vermischung ist mir tatsächlich so auch passiert. Bei Search sucht man nach etwas spezifischem, von dem man schon weiss, dass es existiert, und man es wiederauffinden will.

  • Zum Beispiel, wenn ich nach Bildern vom Planeten Saturn suche, dann gebe ich den Begriff Saturn ein, und kriege in der Suchmaschine in der jeweiligen Datenbank die enbtsprechenden Bildern.
  • Bei Discovery geht es darum, etwas neues zu entdecken. Wenn ich Saturn eingebe, werde ich also möglicherweise auch noch herausfinden, dass das vielleicht für eine Spiel-Konsole von der Firma SEGA stehen könnte. Es kommt also auf den Kontext drauf an. Eine Discovery basiert auf Search.

SolR-Suchmaschine und VuFind-Discovery

SolR ist die Basis für das Discoverysystem VuFind. Zusammen mit Elasticsearch bildet es den Industriestandard auf dem Markt für open source-Suchmaschinen. Wir erfahren, dass SolR im Hintergrund von den Discovery-Systemen läuft und auch beim Marktführer Ex Libris Primo ebenfalls verwendet wird. Es ist nicht gedacht, dass es eigenständig funktioniert. Bei der Übung stellen wir mal fest, dass die Benutzeroberfläche bei SolR für die Suche (Query) stark simplifziert ist, und die Ausgabe im JSON-Format erfolgt. Benutzt man hingegen die Suche über Schema, kann man erkennen, ob anhand der Eigenschaften die Felder indexiert, tokenized (aufgesplittete Werte) oder multivalued (mehrere Werte) sind. Vergleicht man im Log dann die Suchtätigkeiten von SolR mit dem von VuFind, stellt man fest, dass bei VuFind es gehörige Aktivitäten gibt, um nur schon die Vorschläge für die Autovervollständigung anzuzeigen im Suchschlitz von VuFind. Wir erkennen auch, dass VuFind nicht nur in den Allfields-Feldern sucht, sondern auch in anderen Schema-Facetten nach dem Begriff psychology herumstöbert, und dabei diese mit Zahlenwerten multipliziert (der Titel hat mehr Punkte zugewiesen als die übrigen Felder z.B.). Das ist die Gewichtung für die Relevanzranking, und kann sehr willkürlich getroffen sein, je nachdem, was die Ersteller des Katalogs denken, sei für die Nutzenden wichtiger (Bibliothekare achten mehr auf den Titel, Archivare wahrscheinlich eher primär Personen). Künstliche Intelligenz ist hier vor allem dann wichtig, um die richtige Gewichtung je nach Nutzer’innen-Gruppen herauszufinden und zuzuteilen, was eher wohl der Grund für Googles Marktdominanz sein sollte, anstatt die Gewichtungsnummer selbst. Bei der Expertensuche schliesst man aus, welche andere Felder ebenfalls gesucht sollen.

Suchindex vs. relationale Datenbanken

Bei einem Suchindex wie SolR steht jedes Dokument für sich alleine und ist nicht in einer Verbindung mit anderen Dokument-Typen. Die Dokumente bei Suchmaschinen haben Metadaten, um das Wiederauffinden zu erleichtern, während bei relationale Datenbanken jeden Datensatz (Tupel) in einzelne Tabellen erfasst und dann in teilweise komplexe Abfragen die Auswertung wiedergeben. Vereinfacht gesagt, mit SolR sucht man nach einem bestimmten Buch mit dem bestimmten Inhalt, mit einer relationalen Datenbank will man eher wissen, wieviele Bücher es zu einem bestimmten Thema gibt (dieses Beispiel ist aber nicht abschliessend). Auch suchen beide Maschinen ihre abgelegten Daten jeweils anders. Die relationale Datenbank wird alles haargenau nach den spezifisch abgefragten Begriffen absuchen, je nach Einschränkung von Operatoren, während bei SolR die Suchbegriffe grammatikalisch verstanden werden (lexikalische Suche). So werden Verben z.B. auf ihre Grundform heruntergebrochen, und dann alle Datenobjekte wiedergegeben, die sinngemäss etwas damit zu tun haben könnten. Datenbanken sind konsistent und lassen sich aktualisieren, während ein Suchindex einfach eine Kopie erstellen würden, wenn man eine Datei einspeist, welches schon vorhanden ist, und nur geringfügige Änderungen vorweist zur vorherigen Version. Ein Suchindex ist gut geeignet für das Retrieval von Daten, Datenbanken sind eher dazu gedacht, Daten zu speichern und zu verwalten mittels Create-Read-Update-Delete (CRUD).

Sprich, wenn man Text suchen will, dann eher Suchindex benutzen.

Datenintegration in VuFind

Die Dozenten haben die Datensätze aus KOHA, DSpace, ArchivesSpace und dem Directory of Open Access Journals (DOAJ) in eine Zip-Datei verpackt und zur Verfügung gestellt. Dabei sind bewusst noch Fehler eingebaut, die man beim Integrieren von Datensätzen aus DSpace und ArchivesSpace in SolR erhalten wird. Wir vermuten, dass da höchstwahrscheinlich die eindeutige Schlüssel-ID nicht vergeben wurde, weil in Marc21-XML diese Felder nicht belegt wurden, und dies durch die Validierung durchging, weil das Marc21-Feld 001 nicht verpflichtend ist gemäss Marc21. Um dieses Problem zu beheben, würde man wohl mit OpenRefine dieses Feld bearbeiten und die einzigartigen ID-Nummern vergeben.

Swisscovery

Diese neue Plattform von der SLSP hat nun seit dem 7. Dezember 2020 ihren Dienst aufgenommen. Wir schauen uns mal an, was damit angestellt werden kann, was man mit SwissBib (welches wie schon gesagt VuFind verwendet) und andere vorherige Verbundskataloge nicht machen konnte.

  • Swisscovery nutzt als Discovery-System das Primo VE von Ex Libris (einem Tochter-Unternehmen der ProQuest-Gruppe), welches Marktführer ist bei den wissenschaftlichen Bibliotheken.
  • Damit ist jetzt auch Alma als Repository mitinbegriffen.
  • Es bietet über die Google Chrome-Browseroberfläche eine Sprachgesteuerte Suche an (mit Firefox ist diese Option noch nicht gegeben).
  • Man muss sich mittels der Switch-edu ID anmelden

Fazit für diesen Tag

Das wars also. Wir haben über mehrere Lektionen die Datensätze von verschiedenen anderen Repositorien abgesaugt, deren Metadaten vereinheitlicht (so gut es geht), und dann in ein anderes System übertragen, wo man es wieder durchsuchbar machen will. Diese an und für sich banale, aber doch sehr wichtige Tätigkeit zeigt auf, dass es zu einem sehr viele Werkzeuge gibt, wie man dieses Ziel erreicht, dass man da noch viele Fehler machen kann, dass die Übersetzung von einem Standard zum anderen mit unerwarteten Schwierigkeiten versehen ist, und dass die Ansprüche immer komplexer werden. Schlussendlich kommt es immer noch auf die intellektuelle Erfassung von menschlichen Arbeitenden drauf an, dass am Anfang bei den sehr ausführlicheren Metadatenstandards so viele Felder wie möglich befüllt wurden, damit es später weniger Probleme gibt, wenn man zu einem simpleren Metadaten-Modell “downgraded”. Jedoch, dass das sehr viel Aufwand, sehr viel Zeit, und sehr viel Gründlichkeit voraussetzt, ist ebenfalls ersichtlich, und das bedeutet wiederum noch mehr Kosten, um die gestiegene Datenanforderung Herr zu werden.