Frontend

• Bugfix: Detaillierte Beschreibung fehlte bisher in der Objekt-API, auch wenn sie auf „öffentlich“ gestellt war
• Übersetzung: Kannada

musdb

• Bugfix: Fehler bei Einrichtung von 2-Faktor Authentifizierung (per TOTP) gelöst
• Bugfix: Symbole für Bild-Dreh-Richtung waren vertauscht
• Feature: Wird das Generieren des PDF-Katalogs über die Seitenspalte einer Objektgruppen-Seite aufgerufen, wird die Reihenfolge der Objekte innerhalb der Objektgruppe zur Sortierung genutzt

Importer

• Bisher wurde kein Standardname für Ressourcen vergeben, jetzt wird – wie in musdb – der Objektname genommen, falls kein spezifischer Name für eine Ressource (Video, Audio-Datei, extern gehostete Bilder) angegeben wurde
• Der CSVXML-Parser kann jetzt mit mehreren Objekten pro Import XML-Datei umgehen

Autouploader

• Komplett neues Tool
• Man stellt Ordner ein, das Tool prüft, ob er Inhalte hat. Ist das der Fall, so werden die Inhalte zum Import hochgeladen und eine passende Import-Settings-Datei wird automatisch generiert. Siehe „Importe selbst durchführen„.
• Zweck: Automatisierter Upload für Museen, die häufiger dieselbe Art von Import durchführen. Fall: Museum hat Adlib, will immer wieder updaten. Zweiter Fall: Museum hat Reproanlage und immer wieder viele Bilder, die es uploaden will statt von Hand heraufladen. Voraussetzung dafür: Eindeutiges Dateibenennungs-Schema.
• Nicht interessant für Importe über CSVXML oder Datenmigration, wo eh entweder viele manuelle Anpassungen geschehen oder der Import nur einmal geschieht.
• Siehe den eigenen Blogpost dazu.
• Der Code des Tools ist unter GPL v3 lizensiert hier verfügbar.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Museen, die bisher ein anderes Tool zum Sammlungsmanagement genutzt haben migrieren ihre Daten einmal mit Hilfe des Importtools – oft mit dem generischen CSVXML-Import – um dann in musdb weiterzuarbeiten. Museen, die ein anderes Sammlungsmanagement-System haben und damit zufrieden sind nutzen museum-digital rein zur Publikation und fallen dabei in zwei bis drei Kategorien. Die wahrscheinlich größte Gruppe sind dabei Museen, die zum Abschluss eines Digitalisierungsprojektes die im Rahmen des Projektes digitalisierten Bestände importieren und dann gesammelt publizieren. Andere, oft eher größere Institutionen wie das Landesmuseum Württemberg oder die Staatlichen Schlösser und Gärten Hessens importieren und veröffentlichen regelmäßiger um die neuesten gut erfassten Objekte auch unabhängig von Projektkontexten schnell publiziert zu sehen. Dazu kommen Institutionen wie die in den Interaktiven Katalogen des Münzkabinetts arbeitenden Münzsammlungen, die eine eigene primäre Publikationsplattform betreiben und für einen regelmäßigen Datenabgleich daraus importieren.

Zu guter Letzt gibt es Häuser, die zwar direkt in musdb erfassen, aber schlicht zu viele Bild-Digitalisate erstellen, als das ein manueller Upload Sinn machen würde – etwa das Freie Deutsche Hochstift in Frankfurt mit seiner Handschriftensammlung. Hier werden die Bilder entsprechend ihrer Dateinamen zu den bestenfalls schon bestehenden Objektdatensätzen importiert.

Für alle, die regelmäßig und immer wieder mit denselben Methoden bzw. im selben Format importieren, macht es Sinn zu lernen, wie man Importe selbst durchführt.

Importe selbst durchführen

Für das eigenständige Importieren von Objektdaten zu museum-digital steht eine WebDAV-Schnittstelle zur Verfügung. Grob funktioniert der Upload dann wie mit einem Netzwerklaufwerk (bzw. ist genau das) – man verbindet sich und bekommt Zugriff auf einen Ordner.

In diesem befinden sich zwei leere Unterordner, einer für Metadaten und einer für Mediendateien. Nun können die Objektdaten hochgeladen werden. Zuletzt muss man dem Server mitteilen, dass der Upload bereit steht und welche Einstellungen für den Import genutzt werden sollen. Das passiert über eine Konfigurationsdatei. Mehr dazu im Handbuch.

Einerseits ermöglicht das Prozedere Usern einen – einmal probiert – halbwegs einfachen und stabilen Import. Andererseits ist es bei häufigen und regelmäßigen Importen doch weiter mit manueller Arbeit verbunden. Man muss sich eben erstmal verbinden, Uploads auswählen und hochladen, und die Konfiguration erstellen (oder kopieren). Bei großen Datenmengen kann die notwendigerweise chronologische Abfolge der Arbeitsschritte zudem aller Vereinfachung zum Trotz einen nicht zu verachtenden Zeitaufwand bedeuten.

In anderen Worten: Da ist Raum für weitere Automatisierung.

Automatisieren

Gesagt, getan. Mit einem neuen Upload-Tool (erst einmal unkreativ museum-digital:uploader genannt) lässt sich der Upload einfacher gestalten und/oder weiter automatisieren.

Das Tool basiert auf der Annahme, dass man als Museum nur eine Art von Import regelmäßig durchführen möchte – die Einstellungen für den Import also stabil bleiben. Entsprechend beginnt die Nutzung des Tools mit der Konfiguration.

Hier wird neben der ID der Institution, der Mailadresse der importierenden User und dem Importformat auch nach einem Ordner für die Uploads gefragt. Dieser wird in der Folge regelmäßig überprüft. Befinden sich darin Metadaten-Dateien (XML, JSON, CSV) und/oder Mediendateien, so wird ein Import initiiert. Dazu werden die Dateien hochgeladen und die Importkonfiguration auf Basis der Anfangs einmal eingegebenen Einstellungen generiert. Zuletzt werden die Dateien aus dem Ordner gelöscht. Dabei werden sowohl auf lokaler Seite als auch auf dem Server Checks durchgeführt, damit der Upload nicht durchgeführt werden kann, wenn die Ordner gerade noch befüllt werden (etwa lokal erst vor 20 Sekunden ein neu hereinkopiertes Bild vorliegt oder auf dem Server noch ein vorheriger Upload geplant ist).

Damit sich das Tool möglichst flexibel genutzt werden kann, kann es sowohl über Kommandozeilen-Parameter als auch über ein browserbasiertes Interface genutzt werden. Ersteres könnte etwa bei Nutzung eines externen, regelmäßigen Aufrufs genutzt werden. Das Browser-Interface andererseits kommt sowohl mit einer Möglichkeit zum manuellen Anwerfen des Uploads als auch mit einem eingebauten Scheduler, der die Prüfung des Ordners und das etwaige Uploaden alle drei Stunden automatisch durchführt.

Somit ist mit dem Tool der einzige verbleibende Schritt zum vollständig automatisierten Datenabgleich. Für die Häuser, die über einem festgelegten Schema Bild-Digitalisate importieren um sich den manuellen Upload zu sparen heißt das ein einfaches Kopieren der Dateien in den Ordner. Ggfs. schwieriger wird es für die, die häufiger aus einem hausinternen Sammlungsmanagement-System (CMS) importieren. Wie leicht – und ob – sich daraus automatisiert Exporte erstellen lassen, hängt vom jeweiligen CMS und seinen Schnittstellen ab. Es wäre interessant, hier mehr über die Möglichkeiten der einzelnen CMS zu erfahren.

Code-Signing, Windows, Leiden

Schon beim ersten Ideensammeln zum Uploader standen ein paar Grundanforderungen fest.

• Der Uploader muss auf einem lokalen Rechner genutzt werden können.
• Er muss unabhängig von der Wahl des Betriebssystems eingesetzt werden können. Während der überwiegende Teil der Museen Windows nutzt, sind MacOS-Systeme doch immer wieder anzutreffen. Und die Entwicklung geschieht primär unter Linux.
• Alle nötigen Ressourcen für das Programm müssen entweder im Programm enthalten oder über das Netz nachgeladen werden. Die Bedingungen in vielen Museen sind nicht so, dass man sich auf Ordnerstrukturen verlassen könnte, oder als das das zusätzliche Installieren eines Interpreters nicht eine große zusätzliche Hürde darstellen würde.
• Das Programm muss stabil sein. Im Idealfall sollte es einmal eingerichtet quasi unsichtbar im Hintergrund arbeiten.

Für die Wahl der Programmiersprache heißt das, dass es eine kompilierte Sprache brauchte, deren Compiler Cross-Compilation (also das Kompilieren von Programmen für ein Betriebssystem unter einem Anderen) unterstützt. Die Wahl fiel auf Go. Die Implementation gestaltete sich damit sehr angenehm, sodass die erste volle Release-Version jetzt zum Download zur Verfügung steht. Die Anwendung ist nach GPL 3 lizensiert, kann also frei weiterentwickelt werden (solange man die eigenen Anpassungen auch wieder teilt).

Unter anderem durch die Wahl der Programmiersprache tauchen aber an anderen Stellen Schwierigkeiten auf. Unter Linux läuft das Programm flüssig – unter Windows blockiert der Windows Defender SmartScreen die Benutzung. Und so eröffnet sich eine ganz neue Problemklasse.

Zur Abwehr von Malware blockiert der SmartScreen Anwendungen, die a) verdächtig aussehen, b) nicht von einer vertrauenswürdigen Stelle signiert sind und/oder c) noch keine breite Verwendung haben. Wie genau die verschiedenen Aspekte zusammenspielen ist nicht öffentlich bekannt.

Da das Programm neu ist, ist klar, dass es noch keine breite Benutzerbasis hat. Und mit seiner Zielgruppe und seinem Zweck wird es die wohl auch nie bekommen.

Dass Go-Programme von Microsoft als „verdächtig“ eingeschätzt werden ist ein so bekanntes Problem, dass es dazu einen eigenen Eintrag im FAQ der Programmiersprache gibt. Auch daran scheint sich wenig ändern zu lassen.

Bleibt ein Zertifikat: Die zum Signieren von Programmen für Windows nötigen Zertifikate werden in einer Struktur ausgegeben, die sehr an die Vergabe von TLS-Zertifikaten vor 20 Jahren erinnert (und tatsächlich sind dabei dieselben Firmen vertreten). Man beantragt ein Zertifikat und wird kurz überprüft – je nach Art des Zertifikats muss man eine Kopie eines Ausweisdokuments einsenden oder Nachweisen, dass man eine seit mehreren Jahren registrierte Firma/Organisation ist. Dazu muss man – wieder unterschiedlich je nach Anbieter und Zertifikatstyp – einige hundert Dollar zahlen (z.B. hier). Dazu bieten alle außer dem „größten“ Zertifikatstyp (EV) keine Garantie, dass die Warnungen damit vermieden werden können. Schon vor dem Hintergrund jedes einzelnen dieser Aspekte ist das Signieren der Anwendung keine Option. Falls jedoch jemand ein Zertifikat hat und zur Verfügung stellen möchte, wären wir darüber froh.

Einen Ausweg – oder zumindest einen Schritt dahin – könnte es doch geben. Microsoft bietet einen Service an, bei dem man sein Binary hochladen und sich über fälschliche Kategorisierungen beschweren kann. Um diesen zu nutzen braucht man einerseits ein Benutzerkonto (warum ist nicht ersichtlich, aber immerhin ist die Hürde gering), andererseits die Fehlermeldungen / Warnungen, über die man sich beschweren möchte. Und das heißt dann doch wieder, dass man einen Windows-Rechner braucht, um die richtigen Fehlercodes zu ermitteln. Cross-Compilation funktioniert heute also technisch eigentlich problemlos – eine cross-compilation tatsächlich nutzbarer und verteilbarer Programme bleibt schwierig.

So oder so führt wohl mittelfristig kein Weg an einer Meldung bei Microsoft vorbei. Ob das ausreicht, damit das Programm ohne Warnungen genutzt werden kann, bleibt unklar. Auch dazu hält sich Microsoft bedeckt, und es gibt verschiedene Erfahrungsberichte. Aber immerhin scheint es die wahrscheinlich zu erhöhen, dass es (zumindest innerhalb eines Releases) problemlos genutzt werden kann.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Dezember 2024

Frontend

• Datumsangaben in Transkriptionen (TEI) werden geparst, unabhängig davon, ob when="" oder when='' genutzt wurde
• Notizen zu Markierungen werden jetzt auf Objektseiten dargestellt
  Das fehlte bisher und ist jetzt über ein Tooltip umgesetzt, das beim Überfahren der Markierung erscheint – analog zur Anzeige von Ereignis-Anmerkungen.

musdb

• Namen und Beschreibungen von Ausstellungen und Objektgruppen können jetzt übersetzt werden
• Versionierung
• Log von „aktuellen Aufenthalten“ eines Objektes kann als CSV-Datei exportiert werden
• Hochgeladene Objekt-Abbildungen können nun stapelweise versteckt oder veröffentlicht werden (Umsetzung analog zu dem hier beschriebenen, nur eben im Bilder-Menü)
• API erweitert
  • (Neue Funktionen)
  • Objekt-Maße übertragen
  • Bilder und Resourcen zu einem Objekt auflisten
  • Bild-Metadaten
  • Objektbilder veröffentlichen / verstecken

Januar 2025

Frontend

• Sortierung nach „Ästhetik“ der Objekt-Thumbnails (Dazu folgt noch ein eigener Blog-Post)

musdb

• Angleichung der maximalen Feldlänge für Notiz zu Öffnungszeiten ist jetzt konsistent durchgesetzt (UI vs. DB)
• Problem beim Wechseln zwischen Institutionen bei Konsistenzchecks behoben
• Literatur kann jetzt nach Herausgeber durchsucht werden
• Stapelweises umschreiben aus einem Freitextfeld in ein anderes

Importer

• Kern
  • Automatische Transformation von Lebensdaten bei Akteuren
    • Todesjahr „01.01.2012“ wird jetzt „2012“, statt wie bisher 01.01
  • „?“ und „(?)“ werden vom Anfang und Ende von importierten Schlagworten entfernt
  • Verschiedene Arten von Klammern in Schlagwortnamen werden zu regulären Klammern umgewandelt
• Parser
  • Striktere interne Umsetzung von Settings, alle Importe können jetzt das start_at-Setting umsetzen
    • Das ist vor allem für das wiederholte Durchführen von Importen, die wegen neuen, bisher noch nicht abgedeckten Elementen abbrechen, und sonstiges Debugging, wichtig.
  • Neue Parser:
    • MODS (v.a. Bibliotheksdaten)
    • Parser für Exporte aus Faust für das Händel-Haus
    • Parser für XML-Dumps aus MuseumPlus Classic (MsSQL > XML-Export pro Tabelle > Import)
    • Bugfixes
      • Feld „Verwender“ in Primus-Parser war auf Herstellungsereignisse gemappt
      • Material / Technik werden im Parser für BeeCollect-Exporte für die Industriemuseen Sachsen jetzt korrekt importiert
• „Frontend“
  • CLI hat jetzt auch Optionen für das Abschalten des Imports einzelner Bereiche
  • Hilfe-Text für Kommandozeilen-Tool

nodac

• Aufspaltung von Schlagworten erkennt jetzt auch Schlagworte, die in Orte, Zeiten, etc. aufgespalten werden sollten
  • Bsp.: „Helm; Berlin“ > Schlagwort „Helm“ + Ort „Berlin“
• Bei Suche nach Schlagworten mit zweideutigen Namen werden jetzt sowohl Schlagworte als auch allgemein zweideutige Begriffe berücksichtigt
• Zeiten können jetzt direkt von der Zeit-Bearbeitungsseite aus mit anderen zusammengeführt werden

This content is licensed under a Creative Commons Attribution 4.0 International license.

Ein Beispiel: Die bisherige Datenbank eines Museums verwendete Akteurrollen statt einer Ereignisstruktur um auszudrücken wer ein Objekt erstellt hat. Das Museum hat entsprechend eingetragen, dass ein gegebenes Objekt Objekt einen verknüpften Akteur X hat, der als „Haupthersteller“ mit dem Objekt verknüpft ist, und eine verknüpfte Zeit Y, die als „Herstellungszeit“ gekennzeichnet ist. Beim Import werden diese Rollen („Haupthersteller“ und „Herstellungszeit“) dann in die Ereignistypen von museuem-digital übersetzt, um ein Ereignis zu bilden: Das Objekt wurde von Akteur X zum Zeitpunkt Y hergestellt. Dies funktioniert, weil die Begriffe „Haupthersteller“ und „Herstellungszeit“ dem Ereignistyp „Herstellung“ zugeordnet sind.

Wenn einem Begriff noch kein entsprechender Wert einer kontrollierten Liste in museum-digital zugeordnet ist, bricht der Importer den Import beim ersten Auftauchen des Begriffs in einem der kontrollierten Felder schlicht ab. Einerseits ist das gut, um unnötigen Ressourcenaufwand für einen Import der ohnehin nicht abgeschlossen werden kann, zu sparen. Andererseits ist es mühsam. Noch nicht zugeordnete Einträge erkennt man so immer nur einzeln.

Ein kleines neues Tool

Ein kleines neues Tool, concordance.museum-digital.org, macht den Vorgang etwas weniger mühsam. Benutzer können alle Importdaten eines bestimmten Felds (z. B. der Schauspielerrollen) zeilenweise hochladen und prüfen, ob sie bereits in den Konkordanzlisten zugeordnet wurden oder nicht.

Für bisher nicht zugeordnete Einträge besteht nun die Möglichkeit, diese über die Oberfläche des Werkzeugs einem der bei museum-digital erlaubten Feldinhalte zuzuordnen und schlussendlich die Codezeilen zu generieren, die für eine Aufnahme in die Konkordanzlisten nötig sind.

Während das einfache Überprüfen und Erweitern der relevanten Open-Source-Listen auch für nicht technisch versierte Nutzer trivial sein sollte, ist dieser Weg sicherlich bequemer. Wichtig ist auch, dass der Import nicht mehr mehrmals ausgeführt werden muss, bis keine Fehler mehr auftreten, die durch nicht übereinstimmende Einträge verursacht werden. Und, nun ja, es ist sicherlich auch bequemer, Werte in normaler menschlicher Sprache abzugleichen, als die internen IDs der Zielwerte zur Bestimmung von Entsprechungen zu nutzen.

Der Code des Konkordanz-Prüfers kann, MIT-lizensiert, hier gefunden werden.

Dieser Transfer läuft als Serviceleistung über das Team der Landesstelle für Museen, wodurch hier mittlerweile einige Erfahrungen dazu vorliegen:

Zu betonen ist, dass der technische Aufwand für den Datenupload zu museum-digital äußerst gering ist. Dank eines speziell für Primus programmierten Parsers können wir selbstständig alle notwendigen Dateien auf einen Server laden. Das klappt so einfach und zuverlässig, dass das Technik-Team von museum-digital in diesen Prozess überhaupt nicht involviert ist.

Die eigentliche Herausforderung für die Landesstelle – und natürlich für die Museen selbst – besteht vielmehr in der nachträglichen Qualifizierung der Quelldaten. Denn die Datensätze in Primus sind und waren immer frei editierbar. Hier gab es nie eine Kontrolle des verwendeten Vokabulars oder eine Anbindung an Normdaten. Entsprechend heterogen erweisen sich heute die Datenbestände in Primus, die noch vor einem Upload mit den Anforderungen von museum-digital in Einklang zu bringen sind.

Unter anderem dieser Umstand hat die Landesstelle dazu veranlasst, in diesem Jahr für die nichtstaatlichen Museen im Land das Sonderförderprogramm „Sammlungsqualifizierung 2024“ in Höhe von 300.000 EUR aufzulegen. Anmeldungen für dieses Programm sind mittlerweile leider nicht mehr möglich.

Näheres zum Thema findet sich auf der Homepage der Landesstelle für Museen Baden-Württemberg.

Andererseits handelt es sich um eine klar definitierte Aufgabe, die immer wieder dem selben Muster folgend erledigt wird. Das heißt: Es ist eine fast ideale Aufgabe um automatisiert zu werden.

In den letzten Jahren hat sich eine Arbeitsgruppe im Rahmen von CIDOC zusammengefunden, um die Grundlagen genau für eine solche Automatisierung des Austauschs von Objektinformationen im Zusammenhang von Leihverkehren zu legen. Da offensichtlich nicht alle Museen dieselbe Sammlungsdatenbank benutzen, hieß dies zu aller erst einen offenen Standard – quasi eine gemeinsame Sprache, die den verschiedenen Programmen beigebracht werden kann – zu definieren.

Der so entwickelte Standard – EODEM, kurz für Exhibition Object Digital Exchange Model – ist mittlerweile weit genug gereift, dass er einer öffentlichen Betaphase verfügbar gemacht wurde. Wir haben erst sehr spät damit angefangen, uns ernsthaft damit zu befassen, aber es war merklich an der Zeit, einen Versuch zu unternehmen, Import- und Exportwerkzeuge für EODEM im musdb zu implementieren. Schon im November hatten wir ein entsprechendes Import-Feature veröffentlicht. Im Januar konnte der EODEM-Export gerade noch mit dem großen Update und Re-Design des Monats in musdb untergebracht werden.

Im Folgenden soll es zuerst darum gehen, wie man Objektinformationen in EODEM in musdb importieren und exportieren kann. Final folgen einige Anmerkungen zum allgemeinen Nutzen von EODEM zum jetzigen Zeitpunkt und in der näheren Zukunft.

Wie kann ich EODEM in musdb benutzen?

Wie Leihverkehre eingehend und ausgehend sein können, so gibt es auch zwei übliche Anwendungsfälle für EODEM-kodierte Objektinformationen. Das empfangende Museum kann durch den Import von EODEM-Daten viel Zeit sparen und Fehler umgehen, während die Kollegen im ausleihenden Museum den Leihnehmern niedrigschwellig viel helfen können, indem sie die Daten in EODEM exportieren.

EODEM importieren

Im Handbuch findet sich eine ausführliche Beschreibung des Importprozesses in musdb. Kurz zusammengefasst: Zuerst wird ein Passwort generiert, mit dem man mithilfe eines WebDAV-Clients Zugang zu einem Import-Ordner bei museum-digital erhalten kann. Dieser Ordner hat zwei Unterordner, in die man die Metadaten und (falls vorhanden) die zu importierenden Mediendateien hochladen kann. Dazu finden sich im Ordner eine Anleitung und eine Konfigurationsdatei, die man dem vorliegenden Import entsprechend anpassen kann. Benennt man die Konfigurationsdatei nun in import_config.txt um, dient dies dem Server als Indikator, dass ein Import durchzuführen ist. Der Server prüft die Import-Ordner regelmäßig (derzeit alle vier Stunden) auf das Vorhandensein von Importdaten und importiert, falls Importdateien (besonders die Konfigurationsdatei) gefunden werden.

EODEM wurde als „Application Profile“ von LIDO 1.1 entwickelt, das heißt, das EODEM auf dem etablierten LIDO-Standard für den Austausch von Objektinformationen aufbaut und diesen um die für Leihverkehre relevanten Datenfelder erweitert. So ließ sich der EODEM-Import unkompliziert als Erweiterung in den bestehenden LIDO-Import integrieren. Möchte man also einen EODEM-Import durchführen, muss in der Konfigurationsdatei „Lido“ als „parser“ eingestellt werden.

Je nach dem, wie die Inventarnummern innerhalb eines Museums geformt werden, kann der Import von Objektdaten aus fremden Häusern zu einem Problem führen. Das Import-Tool bei museum-digital vergleicht die Inventarnummer der Objekte mit denen der schon erfassten Objekte. Gibt es bereits ein Objekt mit einer gegebenen Inventarnummer, wird dies als Zeichen genutzt, um den bestehenden Datensatz zu aktualisieren statt einen neuen Datensatz anzulegen. So wird normalerweise zwischen neuen Objekten und Updates unterschieden. Wird aber dieselbe Inventarnummer in beiden Häusern verwendet (offensichtlich für verschiedene Objekte), so würde der Server dies folgerichtig als Aufforderung zum Updaten sehen – und den eigenen Objektdatensatz mit den Daten des Leihobjektes überschreiben. Um diesem Problem zu begegnen bietet der LIDO-Parser jetzt eine zusätzliche Einstellung: prefix_inventory_numbers . Wird hier ein Wert (Beispielsweise die Referenznummer des Leihverkehrs, oder ein Kürzel des Namens des ausleihenden Museums) eingetragen, so wird dieser den in den Importdaten angegebenen Inventarnummern vorangestellt. Damit ist eine Kollision quasi ausgeschlossen und der Import auch fremder Objekte sollte problemlos durchgeführt werden können.

EODEM-Daten exportieren

Objektdaten können in musdb genauso wie in alle anderen unterstützten XML-Exportformate exportiert werden. So erscheint EODEM jetzt primär als zusätzliches Exportformat im Formular für Exporteinstellungen (weiter unten lassen sich hier z.B. auch einzelne Felder abwählen, die regulär bei EODEM-Exporten mit exportiert würden, aber im gegebenen Fall nicht exportiert werden sollen). Ist der Export den eigenen Wünschen entsprechend eingestellt, wird mit dem Klick auf den Abschicken-Button eine ZIP-Datei bereitgestellt, in der sich die Objektinformationen in EODEM finden. Dieses ZIP kann man nun dem empfangenden Museum schicken.

Um den Prozess weiter zu vereinfachen gibt es zusätzlich auf der Bearbeitungsseite für Leihverkehre einen neuen Button „Objekte (EODEM)“ in der Rubrik „Exporte“ in der Seitenspalte. Durch einen Klick darauf wird man gleich zum entsprechend vorkonfigurierten Exportdialog für das Exportieren aller Objekte aus dem gegebenen Leihverkehr geleitet.

In musdb and darüber hinaus

Wie schon gesagt haben wir uns erst sehr spät mit EODEM beschäftigt. Der Standard ist schon seit einigen Jahren in der Entwicklung, während wir erst gegen Ende 2022 ernsthaft begonnen haben, uns damit auseinanderzusetzen. (Der Arbeitsgruppe gebührt aller Dank für die Entwicklung von EODEM und das Erkennen der damit einhergehenden Potentiale!)

Andererseits ist musdb tatsächlich das erste System zum Sammlungsmanagement, das Import- und Exportfunktionen für EODEM-Daten ausliefert. Damit ist der Datenaustausch vorerst schon einmal für den Fall von Leihverkehren zwischen zwei Museen, die beide musdb als Werkzeug für die Inventarisierung und das Sammlungsmanagement verwenden, einsetzbar.

Allgemein ist die Benutzung eines Standards ist aber nur so sinnvoll, wie er weit verbreitet ist. Die Website der Arbeitsgruppe bietet eine Liste der Softwarelösungen, in denen Import- und / oder Exportfunktionen für EODEM geplant sind. Viele der großen Namen sind darauf zu finden und haben sich aktiv in die Entwicklung des Standards eingebracht, sodass eine baldige Implementation in einigen der weiter verbreiteten Programmen absehbar ist.

Andererseits gibt es natürlich noch viele andere Programme für das Sammlungsmanagement, die sich bisher nicht auf der Liste finden. Die Implementation an sich ist definitiv nicht schwer, wenn bereits ein LIDO-Import oder Export unterstützt wird und je mehr sich der Standard verbreitet, desto sinnvoller wird seine Benutzung. Es ist daher zu hoffen, dass bald noch deutlich mehr Implementationen folgen, und wir alle die Interoperabilität zwischen Sammlungsdatenbanken stärken und Zeit sparen können.

Beitragsbild: “Relief zweier sich die Hände reichenden Männer, Seebronn (?)“, CC BY-SA @ Landesmuseum Württemberg

This content is licensed under a Creative Commons Attribution 4.0 International license.

Die wichtigste Bedingung dafür war wie schon beschrieben, dass eine Möglichkeit geschaffen werden musste, die Importdaten überhaupt hochzuladen. Dies kann über eine neu eingerichtete WebDAV-Schnittstelle getan werden. WebDAV ist ein Protokoll, das grob analog zu FTP benutzt werden kann, und zum Beispiel auch für die Synchronisierung zwischen einem Rechner und einem Cloudspeicher wie Google Drive oder Nextcloud zum Einsatz kommt. Es hat den Vorteil, dass es auf HTTP (also das Standard-Protokoll, über das Webseiten aufgerufen werden) aufsetzt, und so auch in größeren Institutionen oder in solchen, deren IT von der jeweiligen Kommune gemanaged wird, nicht von Firewalls blockiert werden sollte. Zusätzlich gibt es selbst im Windows Explorer die Möglichkeit, sich mit WebDAV-Netzwerklaufwerken zu verbinden (siehe z.B. hier für eine Anleitung). Ein Upload sollte also protokollbedingt kein Problem darstellen.

Wie importieren?

Zugangsdaten zur WebDAV-Schnittstelle kann man in musdb bei den Einstellungen für das eigene Benutzerkonto erhalten (oben in der Navigation auf den eigenen Namen klicken, dann im Menü auf „Kontoeinstellungen“). Unterhalb der grundlegenden Tabelle für Logindaten findet sich hier ein neuer Reiter „WebDAV“. Öffnet man diesen „Reiter“ erhält man eine kurze Erläuterung auf Englisch und einen Button „Generate WebDAV password“. Klickt man diesen, werden die Zugangsdaten mit einem automatisch generierten Password angezeigt. Das Password sollte gut gespeichert werden, weil es auf dem Server nur in gehashter – also gezielt nicht zurückberechenbarer – Form vorliegt.

Mit diesen Logindaten kann man sich über einen WebDAV-Client einloggen. Möchte man nur Ausprobieren, wie das Ganze funktioniert, bietet sich hier der jeweilige Dateimanager (also z.B. der Windows Explorer) an. Möchte man öfter selbst importieren, lohnt sich spezialisiertere Software wie z.B. WinSCP. Je nach Software muss die Angabe des Protokolls von davs:// zu https:// geändert werden.

Wichtig ist dabei anzumerken, dass die generierten Zugangsdaten immer nur Zugang zur Schnittstelle für die eigene „Heimat-Institution“ geben. Für die meisten Benutzer ist das unproblematisch, aber für Benutzer, die Zugriff auf die Daten mehrerer Museen haben, bedeutet das, dass sie nur für das Haus, dem ihr Benutzerkonto primär zugeordnet ist, Importe durchführen können.

Angekommen auf dem Netzwerklaufwerk: Importdaten hochladen

Hat man sich mit einem WebDAV-Client und mit den eben bezogenen Logindaten zum Server verbunden, sieht man zwei Dateien und zwei Ordner.

.
├── import_config.sample.txt
├── IMPORT_IMG
├── IMPORT_XML
└── README.md

Der Zweck der Datei README.md sollte offensichtlich sein. Hier werden noch einmal die Ordnerstruktur und die folgenden Schritte beschrieben.

Importdaten hochladen

Die Ordner IMPORT_IMG und IMPORT_XML sind die Ordner, in die die zu importierenden Daten hochgeladen werden können. Das geschieht, wie schon von der Ordnerstruktur angedeutet, getrennt nach Dateitypen, wobei die Metadaten in den Ordner IMPORT_XML geladen werden, und Mediendateien in den Ordner IMPORT_IMG hochgeladen werden.

Datei ist zweierlei zu beachten: Einerseits sollte man sich von den Benennungen nicht verwirren lassen. Der Ordner IMPORT_XML ist für alle Metadaten-Dateien gut, sie müssen nicht unbedingt im XML-Format vorliegen. Andererseits sollten in diesen Ordnern keine weiteren Unterordner erstellt werden. Fast alle Import-Scripte („Parser“) verlangen, dass die Daten direkt in den jeweiligen Ordnern liegen.

Die zu importierenden Daten werden nun also in die beiden Ordner hochgeladen.

Den Import konfigurieren

Im letzten Schritt muss dem Server mitgeteilt werden, was für eine Art von Daten dort importiert werden soll. Und, dass der Import überhaupt stattfinden soll. Das geschieht mit der Datei import_config.sample.txt. Öffnet man diese Datei in einem Texteditor (z.B. Notepad++ oder dem Windows Editor – auf keinen Fall MS Word), sieht man verschiedene Optionen, den Import einzustellen.

Verpflichtend sind dabei die Angabe einer Mailadresse, an die Nachrichten über den Fortschritt des Imports gesendet werden sollen (Achtung: Die Mailadresse muss einem Benutzerkonto in musdb, das mindestens die Benutzerrolle „Museumsdirektor“ hat, zugeordnet sein), und die Angabe des „Parsers“, kurz gesagt, des nötigen Import-Formats.

Eine Liste der Import-Formate mit ihren Benennungen findet sich am Ende der Datei. So möglich, stehen hier auch die möglichen parser-spezifischen Einstellungen aufgelistet. So lässt sich etwa für den Parser „ImagesByInvno", also dem Importieren von Bildern nach einer im Dateinamen angegebenen Inventarnummer, einstellen, wie lang die Inventarnummer sein soll, oder ob die Inventarnummer über die ersten 10 (11, 12, 13, …) Buchstaben ermittelt werden soll, oder über ein Trennzeichen (überblicherweise ein Unterstrich) ermittelt werden soll.

Weitere allgemeine Einstellungen sind optional. So kann eingestellt werden, ob die Objekte gleich nach dem Import veröffentlicht werden sollen, oder ob sie alle in eine spezifische Sammlung importiert werden sollen. In der Datei finden sich zu jedem dieser Punkte relativ ausführliche Erläuterungen.

Ist die Import-Konfiguration soweit abgeschlossen, kann die Datei in import_config.txt umbennant werden. Das vorhandensein einer Datei mit diesem Namen auf der obersten Ebene des WebDAV-Laufwerks ist das Zeichen an den Server, dass importiert werden soll.

Der Import findet statt

Für das automatische Importieren prüft der Server alle vier Stunden, ob sich passende Importdateien in den WebDAV-Verzeichnissen befinden (also, Daten hochgeladen wurden, und eine Datei import_config.txt vorhanden ist). Ist das der Fall, läuft der Import ab.

Sobald es einen Fehler gibt wird der Import abgebrochen und eine Fehlermail an die in der Konfigurationsdatei angegebene Mailadresse und das Entwicklerteam gesendet. Fehler können z.B. bei einer bisher unbekannte Lizenzangabe vorliegen, aber auch schlicht unlogisch formulierte Daten betreffen. Bei Parsern mit Vollständigkeitsprüfung kann der Fehler auftreten, dass ein bestimmtes Datum bisher nicht vom Parser abgedeckt wird.

Im Fehlerfall werden die Importdaten dann in einem Ordner IMPORTS_FAILED verschoben. Sobald der Parser oder die Daten angepasst wurden, damit der Fehler nicht mehr auftritt, können sie von dort wieder an die richtige Stelle für ausstehende Importe (also die Ordner IMPORT_XML und IMPORT_IMG) verschoben werden.

Läuft der Import andererseits fehlerfrei durch, wird eine Benachrichtigungsmail an die oben angegebene Adresse gesendet.

Nötige Anpassungen für die Ermöglichung von benutzergesteuerten Importen

Damit all das möglich wurde, mussten wir den Importer großflächig anpassen. Gerade für die Konfigurierbarkeit von parserspezifischen Werten brauchte es auf Seiten der Parser eine grundlegend andere Architektur.

Der Importer besteht grundlegend aus vier Arten von Scripten:

• Eine Repräsentation der grundlegenden importierbaren Datentypen (Objekte, Ereignisse, Bilder, Sammlungen) in Code
• Scripte, die das Schreiben von Daten in die Datenbank übernehmen
• Parsern, die den Ablauf eines Imports für die verschiedenen Arten von Importdaten und die Zuordnungen von Werten aus den Importdateien zu den bei museum-digital bestehenden Datentypen herstellen
• Frontend-Scripten, die z.B. das Kommandozeilen-Interface bereitstellen

Von diesen waren bisher nur die Datentypen und Schreib-Scripte mit einem objektorientierten Ansatz geschrieben. Für die neue Möglichkeit selbst zu importieren, wurden auch die Parser und die Frontend-Scripte angepasst, sodass das ganze Importtool jetzt mithilfe eines objektorientierten Ansatzes geschrieben ist. Das hat u.a. auch den Vorteil, dass für alle vorhandenen Parser automatische Tests eingerichtet werden konnten, sodass z.B. Fehler, die durch Updates der Programmiersprache oder Änderungen an anderen Stellen entstehen, frühzeitig auffallen und gelöst werden können.

Der Anspruch automatisierte Tests für alle Aspekte des Importers zu haben führt allerdings auch dazu, dass nicht mehr alle bisher vorhandenen Parser verfügbar sind. Beim Überführen der Parser in die neue Architektur wurden solche Parser übergangen, die mit größerer Wahrscheinlichkeit nicht wieder gebraucht werden (z.B. der Parser für Museo, das alte Inventarisierungssystem der Museen der Lausitz, das seit längerem nicht mehr gepflegt wird und nicht mehr im Einsatz ist).

Und für wen ist das sinnvoll?

Wer kann also von der Möglichkeit, Daten selbst zu importieren, profitieren? Einerseits sind das Museen, die mit einem anderen Programm inventarisieren, aber ihre Daten mit museum-digital veröffentlichen und deren Daten schon einmal erfolgreich importiert wurden. In diesen Fällen ist davon auszugehen, dass das bestehende Importformat sich nicht weiter geändert hat und ein passender Parser bereitsteht.

Andererseits können Museen profitieren, die sehr viele Abbildungen für ihre Objekte haben, und bei denen der Upload mit dem regulären Bild-Uploadtool zuviel Zeit kosten würde. Im Freien Deutschen Hochstift / Frankfurter Goethe-Museum wird die Funktion etwa schon fleißig genutzt, um gescannte Handschriften zu den Metadaten-Datensätzen in musdb hochzuladen.

Für Museen, die das erste Mal importieren wollen, oder für solche, die Daten importieren möchten, für die es bisher noch keinen Parser gibt, macht der eigenständige Import andererseits keinen Sinn. In diesen Fällen weiterhin heißt es wie so oft: Einfach eine Mail schreiben, eine Lösung wird sich finden.

P.S.: Auch im Handbuch findet sich eine jeweils aktuelle Beschreibung des Import-Prozesses.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Ganz aktuell wurden zwei Importe vom Schloßmuseum in Jever bei museum-digital integriert, Grafiken und Zinngegenstände, jeweils ca. 200 Objekte.

Der Massenimport der Digitalisate funktioniert mittlerweile sehr gut. Durch die vorrangegangenen Erfahrungen und den permanente Austausch mit Herrn Rohde-Enslin vom Institut für Museumsforschung (Staatliche Museen zu Berlin – Preußischer Kulturbesitz) konnte ein Stand erreicht werden, bei dem der Import von Digitalisaten über Excel-Listen und dem Upload der dazugehörigen Bilder in ein „elektronisches Postfach“ innerhalb weniger Stunden (je nach Auslastung der Beteiligten) möglich ist.