Tag 8 begann mit einem Nachtrag zum Thema Metadaten modellieren, bevor wir dann ins Thema Suchmaschinen und Discovery-Systeme einstiegen und uns mit VuFind und Solr befassten.

Nachtrag Metadaten und Schnittstellen

Zunächst ein Input zur sehr wichtigen Validierung von Daten. Anschliessend folgen weitere Tools zur Metadatentransormation, ein Ausflug in die Nutzung von JSON-APIs, ein Exkurs zu ScrAPIr und zu LIDO.

Validierung von XML

Das Validieren ist ein sehr wichtiger Schritt. Darum soll hier festgehalten werden, wie das gemacht werden kann. Zum Validieren der XML-Daten werden diese mit einem Schema abgeglichen. Dieses Schema wird auf der Webseite der Library of Congress zur Verfügung gestellt:

Screenshot Webseite Library of Congress

Mit so einem Schema werden Regeln festgelegt, dabei werden sowohl Form wie Inhalte festgelegt und es kann entsprechend beides validiert werden.

Das Vorgehen:

  1. Die Daten aus dem OpenRefine als XML exportieren; dazu als heruntergeladene Datei die Dateiendung in .xml ändern, weil es aus OpenRefine heraus als .txt daherkommt.
  2. Das Schema herunterladen, in den entsprechenden Ordner, darum lautet der erste Befehl cd Downloads (wenn es im Downloadordner zu liegen kommen soll).
  3. Mit dem Programm xmllint validieren (dieses ist unter Ubuntu bereits vorinstalliert).

Für die Schritte zwei und drei werden die folgenden Befehle eingegeben. Besser statt *xml zu schreiben, ist es den konkreten Dateinamen, welchen man validiern möchte, einzugeben, weil *xml geht über alle xml-Dateien.

Code zum validieren

Quelle: Das gemeinsame Codi.

Anschliessend zeigt es im Terminal die Fehler an, im Abgleich mit der geöffneten Datei im Texteditor lassen sich die Fehler dann eruieren. Auf folgendem Bild ist zu sehen, wie dies im Terminal aussieht. Zu sehen sind alle eingegebenen Befehle und dass die Daten alle validiert, d.h. frei von Fehlern sind:

Screenshot Terminal Validierung

Weitere Tools zur Metadatentransformation

Neben OpenRefine gibt es noch andere Tools. OpenRefine hat dabei einige Vorteile, wie beispielsweise die grafische Oberfläche, was die Arbeit damit erleichtert. Zudem eignet sich OpenRefine sehr gut für die Datenanreicherung (Reconciliation).

Die Wahl der Software hängt ab vom Metadatenformat und was damit gemacht werden soll. Ein weiteres Kriterium, gerade in der Praxis, ist die Programmiersprache. Denn da eine grafische Oberfläche nicht immer möglich ist, ist es am effizientesten mit einem Tool zu arbeiten, wo man die Sprache kennt.

So eignet sich für Pearl Catmandu und für Java Metafacture. Für MARC21 eignet sich, wie bereits im Kurs gesehen, MarcEdit. Für Python gibt es nicht eine vollumfängliche Lösung, aber für MARC21 Daten gibt es z.B. pymarc.

Nutzung von JSON-APIs

JSON-APIs? Sieben Buchstaben mit Bindestrich. Mehr stand da für mich erstmal nicht, ausser dass ich beide Buchstabenteile schonmal gehört hatte, sie allerdings in den Untiefen meines Gedächtnisses nicht mehr auffinden oder gar sinnvoll kombinieren konnte. Eine Auffrischung ist an dieser Stelle also wohl dringend nötig.

JSON steht für JavaScript Object Notation und ist ein Format für den Datenaustausch, basiert auf JavaScript und kann beispielsweise anstelle von XML verwendet werden (siehe wiki.selfhtml).

API steht für application programming interface. Es ist also eine Schnittstelle zur Anbindung von Programmen, die auf Quelltextebene dafür sorgt, dass die Daten ausgetauscht werden können.

Die Schnittstellen, welche wir hier im Kurs bislang betrachtet haben, sind Archiv- und Bibliotheksspezifisch und dort auch immer noch zentral. Ausserhalb dieser Bereiche, werden in der Regel Schnittstellen verwendet, die JSON ausgeben, denn JSON ist das am meisten verwendete Format für moderne Web-Schnittstellen. Deswegen ist es wichtig, diese JSON-APIs auch zu kennen.

Ein Beispiel für eine JSON-API ist lobid-gnd. Hier sieht man gut, was JSON ausmacht: Es lässt sich (wie xml) recht leserlich im Browser anzeigen und eignet sich zugleich gut für die maschinelle Verarbeitung.

Exkurs: ScrAPIr

ScrAPIr ist ein Tool, womit Web-Schnittstellen auch für Nicht-Informatiker*innen einfache zugänglich sein sollen. Es können hier Daten über die Web-APIs geholt werden. So können Webseiten wie Google Books, The New York Times oder auch NASA Images abgefragt werden.

Die Benutzerschnittstelle ist in Form einer Tabelle dargestell und lässt sich recht einfach abfragen. Die Ergebnisse kann man sich dann in verschiedenen Formaten (CSV, JSON, Code) ausgeben und/oder speichern. Der Code lässt sich entweder in Python oder JavaScript anzeigen. Das ist sehr nützlich, weil man dadurch sieht, wie die Schnittstelle in Form von Code abgefragt werden könnte. Zudem lässt sich die Tabellenansicht verändern: Tabellenasicht, Ansicht in Form einer Baumstruktur oder in Form einer Liste. Die letztere Ansicht ist besonders leicht zu lesen und zeigt im Falle von NASA Images auch gleich das Bild mit an.

Screenshot ScrAPIr

Ansicht in ScrAPIr in der Listenansicht, zu sehen ist ein Eintrag aus NASA Images.

Exkurs: Metadatenstandard LIDO

LIDO (Lightweight Information Describing Objects) ist ein XML-Standard, der auf dem CIDOC Conceptual Reference Model basiert, das ist eine Ontologie für den Bereich des Kulturerbes und ein Modell, das dann für Standards verwendet wird, zum Informationsaustausch in Museen, Archiven oder auch Bibliotheken. Entsprechend wird LIDO vorallem in Museen eingesetzt.

Was LIDO speziell macht ist, dass es dem Linked-Open-Data-Konzept folgt, wodurch Querverweise zu anderen Objekten und auch Institutionen gelegt werden können. Zudem ist LIDO Ereigniszentriert und nicht Dokumentzentriert wie andere Standards (z.B. MARC), das bedeutet, es wird nun nicht vom Objekt ausgegangen, sondern es gibt verschiedene Ereignisse: wann wurde ein Werk geschaffen, wann wurde es verkauft, durch wen wurde es gekauft, wann entstand ein Schaden am Werk, wann wurde das Werk restauriert, usw. – das sind alles Ereignisse, die für ein Objekt und den Museumskontext wichtig sind und die nun in LIDO beschrieben werden. Festgehalten werden Personen, zeitliche Daten usw., dadurch können Beziehungen hergestellt werden. Das macht LIDO sehr interessant. Nachteilig hingegen könnte sein, dass durch diesen grundlegend anderen konzeptuellen Aufbau mit der Ereigniszentriertheit es recht kompliziert ist, einen Datenaustausch zwischen LIDO und dokumentzentrierten Formaten (verlustfrei) hinzubekommen.

Suchmaschinen und Discovery-Systeme

Nun kommen wir zum ersten Teil Suchmaschinen und Discovery-Systeme und nähern uns allmählich dem Ende des Kurses. Heute wollen wir zunächst VuFind installieren und das nächste Mal die Solr und die Datenintegration ansehen.

VuFind

VuFind ist ein Open-Source-Discovery-System für Bibliotheken und kann den OPAC ersetzen. VuFind ist eine php-Software, hat im Hintergrund MariaDB und für die Suche wird der Suchindex Solr eingesetzt.

Wir haben VuFind gemeinsam installiert, in der Basisversion. VuFind ist modular aufgebaut mit zahlreichen Erweiterungen, weswegen das System gut auf die eigenen Bedürfnisse angepasst werden kann.

Nachtrag (von Tag 10): Ein wichtiges Stichwort bei Discovery-Systemen ist der Central Index (auch Artikel Index). Um elektronische Ressourcen in einem Bibliothekskatalog verwalten zu können, braucht es, wegen der grossen Datenmenge, ein System zur Verwaltung der elektronischen Ressourcen. Dazu kauft man diesen Central Index mit ein, nur so hat man die Informationen und Daten, z.B. welche wissenschaftlichen Artikel es gibt. Diese Daten kommen von anderen Servern, ein Beispiel ist der Primo Central Index von Ex Libris. Es gibt auch Open Data-Ansätze (z.B. finc). Ein Discovery-System ohne diesen Index bringt nicht so viel.

Für mich war das Vorgehen VuFind gemeinsam zu installieren sehr hilfreich, weil erstens wäre es alleine doch recht kompliziert gewesen mit vielen möglichen Stolpersteinen, zweitens hat es funktioniert und drittens waren die zusätzlichen Ausführungen zu den einzelnen Schritten erhellend, so war das Copypasten angereichert mit ein bisschen nachvollziehen und verstehen können was wir tun.