Nachtrag zu Metadaten modellieren und Schnittstellen nutzen

Validierung & Deklaration von XML
Das Ergebnis in OpenRefine haben wir als XML in ein neues Verzeichnis exportiert. Möchte man die XML-Datei validieren, könnte man das in Ubuntu vorinstallierte Programm xmllint nutzen. Auch kann man die Datei mit dem offiziellen Schema von MARC21 (XSD) abgleichen, wofür man dieses aber zuerst herunterladen muss:

wget https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd
xmllint *.xml --noout --schema MARC21slim.xsd

Damit ein Programm versteht, dass es sich bei einer Textdatei um XML handelt, wird dies korrekterweise in der ersten Zeile der Datei deklariert. Die Reihenfolge der Attribute ist festgelegt und lässt sich folgendermassen aufschlüsseln:

  <?xml version="1.0" encoding="utf-8" standalone="yes"?>
  • xml: Dies ist eine XML-Datei
  • version=”1.0”: Die Datei entspricht dem XML-Standard in der Version 1.0. Diese Angabe ist zwingend erforderlich.
  • encoding=”utf-8”: Die Zeichen sind nach dem Unicode-Standard codiert. Diese Angabe ist optional aber gehört zur guten Praxis.
  • standalone=”yes”: Die Datei enthält eine Dokumenttypdefinition (DTD). Auch diese Angabe ist optional.

OpenRefine im Vergleich
Neben OpenRefine gibt es weitere Tools zur Metadatentransformation. Was diese Software ausmacht ist zum einen die grafische Oberfläche; die Ergebnisse der Transformation werden direkt sichtbar. Dank diverser Skriptsprachen (GREL, Jython, Clojure) sind komplexe Vorgänge möglich. Der Schwerpunkt bei OpenRefine liegt bei der Datenanreicherung (Reconciliation). Es gibt alternative Software, die z.T. andere Schwerpunkte haben, weshalb je Anwendungsfall evaluiert werden sollte, welche sich am besten eignet. In der Praxis wird häufig jene gewählt, die bereits gut beherrscht wird – auf der einen Seite nachvollziehbar, da der Aufwand des Erlernens einer neuen Software entfällt und man sich sicherer fühlt bei dem, was man tut. Auf der anderen Seite werden deshalb Aufgaben umständlicher ausgeführt, als es mit einer passenderen Software möglich wäre. Alternativen zu OpenRefine wären:

Nutzung von JSON-APIs
Während ältere Schnittstellen wie OAI-PMH oder SRU Antworten in XML liefern, erhält man diese bei modernen APIs häufig in JSON. Wie XML auch kann JSON direkt im Browser betrachtet und gut maschinell verarbeitet werden.

Ein Beispiel für eine solche API ist lobid-gnd: Die Suchergebnisse sind in JSON und auch das Abrufen der Datensätze über deren ID erfolgt direkt über JSON. Auch sind über JSON lines Bulk-Downloads (Massen-Downloads) möglich. Die API unterstützt ein “spezielles Antwortformat”, welches Vorschläge zur Autovervollständigung ermöglicht. Im unteren Beispiel etwa wird bei der Suche nach der Künstlerin Isa Genzken automatisch im rechten Feld die GND-ID ergänzt:
lobid-gnd

Als Beispiel für ein Tool, mit dem solche Schnittstellen abgefragt werden können, ist scrAPIr. Wie es der Slogan “Making Web Data APIs Accessible to Everyone” schon verrät, können mit diesem Werkzeug Daten von bekannten Webseiten wie Google Books, NASA Image, YouTube oder The New York Times bezogen werden. Ein cooles Tool, mit dem interesssante Abfragen machen kann! Bspw. lässt sich auf einfache Weise eine Liste generieren mit den 10 häufigsten geklickten Musikvideos einer bestimmten Künstlerin. Oder es können – wie in meinem Beispiel unten – alle Artikel der New York Times im Monat November 2020 abgefragt werden (hier limitiert auf 10 Ergebnisse):
scrAPIr

Praktisch ist, dass die ausgegebenen Spalten selber definiert werden können. Die Ergebnisse können dann wahlweise im Format CSV, JSON oder als Code (Javascript, Python) betrachtet und gespeichert werden.

Metadatenstandard LIDO
LIDO (Lightweight Information Describing Objects) ist ein auf dem CIDOC Conceptual Reference Model (CIDOC CRM) basierender XML-Standard, mit dem Kulturobjekte beschrieben werden können. Spziell an LIDO ist, dass diese Beschreibung ereignis-zentriert erfolgt – z.B. wird von der Herstellung eines Werks als Ereignis ausgegangen, woran eine bzw. mehrere Personen beteiligt sind, die an einem spezifischen Ort und zu einer spezifischen Zeit stattfindet und so weiter. Vorteile gegenüber dokumentzentrierten Formaten sind dessen Linked Data-Struktur, die Verwendung von kontrollierten Vokabularen/Ontologien sowie Wiederverwendung von Entitäten wie Ereignissen.

CIDOC CRM ist eine formale Ontologie, die Begriffe im Bereich des Kulturellen Erbes vereint. Vorrangiges Ziel ist es, die Integration, Zugriffsvermittlung und den Austausch von unterschiedlich strukturierten Daten zu unterstützen. Es kann somit als gemeinsame Sprache verstanden werden, die alle CRM-kompatiblen Daten zu einer gemeinsamen Wissensressource eint.

Mit LIDO hattee ich bisher im Rahmen meiner Tätigkeit im Kunstmuseum Basel am Rande schon zu tun gehabt. Das Kupferstichkabinett möchte nämlich seit geraumer Zeit seine Sammlung im Graphikportal zugänglich machen. Als ich dort vor zwei Jahren mit der Betreuung von MuseumPlus Classic begonnen habe, hiess es von der Leiterin des Kabinetts, dass dieser Wunsch lediglich daran scheitern würde, dass unser in die Jahre gekommenes System jene Schnittstelle nicht unterstützt. Im Rahmen der Evaluierung des Nachfolgesystems habe ich mich dann näher damit beschäftigt und gelernt, dass LIDO nicht nur die Schnittstelle meint, sondern vielmehr ein Format ist. Wenn wir also unsere Daten an das Graphikportal weitergeben möchten, muss nicht nur eine Schnittstelle vorhanden sein, sondern auch eine Mappingtabelle, die regelt, wie welche Daten aus MuseumPlus transformiert werden müssen, sodass sie LIDO entsprechen. Diese Erkenntnis war sehr wichtig für uns, da wir nun im Zuge der Datenbereinigung und -optimierung für die Migration auch den LIDO-Standard im Hinterkopf behalten und somit Vorbereitungen treffen können um ein späteres Mapping zu erleichtern. Denn mittels einer Mappingtabelle lassen sich wohl einige Unstimmigkeiten hinbiegen aber wenn die Daten wie Kraut und Rüben im System vorliegen, hat auch dies seine Grenzen.

Kürzlich habe ich ausserdem erstmals von EODEM (Exhibition Object Digital Exchange Mechanism) gehört, als ich an einem Austausch zu LIDO in der aktuellen Version von MuseumPlus mit einem der Zetcom-Entwickler teilgenommen habe. Es handelt sich um ein Projekt (Beginn 2018), bei dem ein Datentransfer-Standard entwickelt werden soll, um den Leihverkehr zwischen Institutionen zu vereinfachen. Bibliotheken sind hier viel weiter; die Übernahme von Fremddaten hat sich fest etabliert, sodass theoretisch kein Buch mehr als ein Mal katalogisiert werden muss. In der Museumswelt ist das leider anders: Der Leinehmer erfasst alle Werke des Leihgebers erneut im eigenen System, was zeitaufwändig und auch fehleranfällig ist. EODEM (lat. für ebenda, an derselben Stelle) basiert auf CIDOC CRM und LIDO und soll angeblich bald in MuseumPlus in Form einer weiteren Exportmöglichkeit (neben z.B. Excel, Word) integriert werden. Mehr über das Projekt erfährt man im Video von Rupert Shepherd, das ich sehr empfehle. Er geht darin u.a. auf folgende Probleme ein:

  • Unterschiedliche Institutionen dokumentieren unterschiedlich tief. Die EODEM-Arbeitsgruppe schlägt deshalb ein relativ kleines Datenset vor, welches die wichtigsten Informationen umfasst (ganz nach dem Prinzip “anything is better than nothing”). Darunter etwa Object Identifier, Object Type, Title, Lender Details, Export Date.
  • Unterschiedliche Institutionen dokumentieren unterschiedlich strukturiert. Beispiel hierfür ist die Angabe der Werkmasse, die entweder als String (“23.4 cm x 36.2 cm”) oder zerlegt in separaten Feldern erfasst werden kann. Die Informationseinheiten von EODEM sehen deshalb vor, die Daten strukturiert und unstrukturiert zu übernehmen. Somit werden Daten eines Leihgebers so übertragen, wie sie im System vorliegen – auf der anderen Seite ist es abhängig vom System des Leihnehmers, ob diese unstrukturiert übernommen oder versucht werden soll, die Inhalte in individuelle Felder zu parsen. Letzteres verlangt dann wohl Eingriffe in die Mappingtabelle.

Suchmaschinen und Discovery-Systeme 1/2

Installation und Konfiguration von VuFind
VuFind haben wir gemeinsam nach folgender Anleitung installiert: https://vufind.org/wiki/installation:ubuntu. Dabei mussten ein paar Abweichungen berücksichtigt werden:

  • In VuFind 7.0.1 wird die Version Solr 7.3.1 verwendet, die nicht mit der aktuellen Java-Version unter Ubuntu 20.04 kompatibel ist. Es wird empfohlen, entweder Java 8 zu verwenden (was wir tun) oder den Release 7.0.2 abzuwarte.
  • Ubuntu 20.04 wird mit MariaDB ausgeliefert, nicht mit MySQL (Fehler in der Anleitung)

Zum Schluss haben wir in VuFind ein paar Testdaten (250 Datensätze) geladen: /usr/local/vufind/import-marc.sh /usr/local/vufind/tests/data/journals.mrc /usr/local/vufind/import-marc.sh /usr/local/vufind/tests/data/geo.mrc /usr/local/vufind/import-marc.sh /usr/local/vufind/tests/data/authoritybibs.mrc

—

Quellen: lobid-gnd, scrAPIr, CIDOC CRM, EODEM, BAIN-Skript 6