Nachtrag zu Metadaten modellieren und Schnittstellen nutzen_Suchmaschinen und Discovery-Systeme

Zu Beginn wurde ein Thema aufgegriffen, was ich so ebenfalls in verschiedenen Quellen angetroffen und deshalb in einem meiner letzten Lerntagebucheinträge verarbeitet hatte. Es betrifft die Möglichkeit der Selektion über die OAI-PMH Schnittstelle, wozu zu sagen ist, dass die Schnittstelle in erster Linie zum Harvesten grösserer Datenmengen gebaut wurde und weniger zur selektiven Abfrage. Trotzdem kann man sagen, dass auch OAI-PMH selektive Elemente drin hat, insofern, dass wir z.B. beim Hochladen der Daten in ArchivesSpace auch selektiv nur unser Set ausgewählt haben.

Mit grossem Interesse habe ich die beiden Beispiele für Metadatenmanagement in der Praxis angeschaut. Vor allem das Video mit Kirsten Jeude, welche kurzgefasst, ihre Arbeit zu einem grossen Teil als Übersetzung bezeichnet, mit dem Ziel eine Vielzahl an Daten aus verschiedensten Quellen unter einer Oberfläche durchsuchbar machen zu können.

Aufgrund der Hinweise zu OpenRefine im Vergleich zu anderen Tools scheint mir für den Datentransfer im Fall unserer Bibliothek, also für Daten im MARC-Format, das Vorgehen, wie es im Handbuch «Processing MARC» mit den XSLT Crosswalks beschrieben wird, als eher zutreffend, da dies eine Transformation in RDF und BIBFRAME ermöglicht, was sehr wahrscheinlich eines der Formate unseres neuen LMS sein wird.

Dann wurde ein Thema behandelt, wessen ich mir so nicht bewusst war, und zwar ging es um XML bzw. JSON. Nämlich, dass XML als Datenaustauschformat eigentlich bereits veraltet ist. So bestehen die Felder in JSON nur aus Name und Inhalt und nicht noch aus zusätzlichen Attributen, wie bei XML. Mögliche Attribute werden in JSON in einem separaten Feld angelegt. Eine Hierarchie ist möglich und es eignet sich für viele Webanwendungen, da die Verarbeitung durch JavaScript gut und schnell möglich ist. JSON ist im Vergleich zu XML schlanker, effizienter und trotzdem strukturiert, dabei aber weniger standardisiert. Die in JSON codierten Daten sind von Mensch und Maschine lesbar. Ein JSON Dokument besteht aus Objekten, welche wiederum jeweils aus mehreren Namen-Wertepaaren bestehen. Die Feldnamen werden als String dargestellt. Diese «Schlankheit» bei JSON ist auch darauf zurückzuführen, dass nicht wie in XML, wo das Root-Tag uns angibt, um was es eigentlich gerade geht, offen legt, um was für Daten es sich eigentlich handelt. Das wiederum hat den Vorteil, dass JSON einiges weniger an Speicherkapazität benötigt und sich so eben für den Datenaustausch eignet. XML hingegen bietet aufgrund der semantischen Auszeichnung noch mehr, bläht aber v.a. kleine Datenbestände auch unnötig auf.

Hier der auf den Punkt gebrachte Beitrag zum Thema von W3C:

JSON is Like XML because…

  • Both JSON and XML are “self describing” (human readable)
  • Both JSON and XML are hierarchical (values within values)
  • Both JSON and XML can be parsed and used by lots of programming languages
  • Both JSON and XML can be fetched with an XMLHttpRequest

JSON is Unlike XML because…

  • JSON doesn’t use end tag
  • JSON is shorter
  • JSON is quicker to read and write
  • JSON can use arrays

The biggest difference is:

XML has to be parsed with an XML parser.
JSON can be parsed by a standard JavaScript function.

Why JSON is better than XML:

XML is much more difficult to parse than JSON.
JSON is parsed into a ready-to-use JavaScript object.

Dieser Beitrag wird etwas zu einem Sammelsurium aus verschiedenen Themen. Irgendwie konnte ich mich nicht auf ein paar wenige konzentrieren wie sonst. Naja, ist jetzt wohl nicht so angenehm zu lesen, aber anscheinend habe ich diese Mal an mehreren Stellen Klärungsbedarf.

Nun möchte ich auf das Thema API eingehen, das wurde schon oft erwähnt, aber ich musste hierzu jetzt trotzdem mal noch genauer nachlesen. Also, auch die API (Application Programming Interface) ist eine Schnittstelle. Sie ist wie ein Bausatz an verschiedenen Standardbefehlen (Funktionen, Protokolle, Objekte) für die Ausführung allgemeiner Operationen, an welchem sich Entwickler*innen bedienen können, um eine Software zu erstellen oder mit externen Systemen zu interagieren. APIs vereinfachen und beschleunigen den Datentransfer zwischen Systemen. Der Code der API regelt den Zugangscode für den Server und ermöglicht so die Kommunikation.

Zum Abschluss folgt das Thema Solr, was bei der Installation von VuFind ein zentraler Begriff ist, ich mich aber noch nicht weiterführend damit befasst hatte und somit den Begriff noch zu wenig einordnen konnte. Solr ist ein Suchserver, welcher es ermöglicht, vertikale Suchmaschinen zu integrieren. Vertikale Suchmaschinen beschränken sich im Gegensatz zu horizontalen Suchmaschinen, wie z.B. Google, Yahoo etc., auf eine bestimmte Domain, ein bestimmtes Thema oder eine bestimmte Zielgruppe. Solr bietet mächtige Suchfunktionen und ist sehr gut skalierbar. Ausserdem kann Solr in Echtzeit indexieren, wobei die Schlagwörter mit den entsprechenden Dokumenten verbunden werden. Die Suche selbst läuft dann lediglich durch die indexierten Begriffe in der Bibliothek, statt dass die gesamte Website abgesucht wird. Das Ergebnis einer vertikalen Websuche ist also eine Liste mit Verlinkungen zu den jeweiligen Dokumenten. Dies führt dann allerdings dazu, dass von jedem neuen Dokument auch sämtliche Metadaten in der Bibliothek abgelegt werden und nicht wie man es von Datenbanken kennt, nur mit einem Eintrag, der dann mit den Dokumenten verlinkt wird. Bei der Suche können Boolesche Variablen und Trunkierungen bzw. Wildcards eingesetzt werden. Weitere Suchfunktionen, die Solr bietet, sind die Facettenklassifikation, die Begriffsanpassung, ein Relevanzranking und erweiterte Volltextsuchen.
Hier noch die Beschreibung eines typischen Ablaufs einer Suche mit Solr, von der Seite bigdata-insider.de:

Bei der Suche mit SolR werden typischerweise die folgenden vier Schritte nacheinander durchlaufen

  1. Indizierung
  2. Abfragen
  3. Mapping
  4. Darstellung und Sortierung der Ergebnisse

Im ersten Schritt erfolgt die Indexierung der zu durchsuchenden Dateien. Hierfür werden sie in ein maschinenlesbares Format, den Index, übersetzt. Anschließend findet die Übersetzung der Sucheingaben und Suchbegriffe der User oder der Anwendung statt. Diese Suchbegriffe werden im Mapping auf die Dokumente des Index angewandt, um die gewünschten Ergebnisse zu finden. Die von der Suchmaschine gelieferten Ergebnisse werden anschließend nach bestimmten Kriterien wie Relevanz sortiert und gelistet.

Verwendete Quellen: