• Verknüpfte Objekte auf Quellen-Seiten sind jetzt sortiert nach Position in Quelle
  • Damit ergibt sich quasi automatisch ein Register für die Quelle
• Ziel-URL bei Nutzung des unspezifischen Suchschlitzes für Objekte auf neues Format umgezogen
• OAI-PMH-Schnittstelle
  • Standartisierter Zugang für Aggregatoren, um Daten vieler Objekte abzurufen
  • Bisher unterstützte Objekt-Metadatenformate:
    • LIDO
    • OAI-DC (Pflicht)
  • Siehe auch: Blogpost dazu auf Englisch
• PDFs werden außerhalb der Standardsprache einer Instanz nur noch bei niedriger Ressourcen-Auslastung generiert
  • Der Großteil der „Benutzer“ von museum-digital sind derzeit tatsächlich offensichtliche KI-Crawler. Blocken ist schwer bis unmöglich, und ihnen Inhalte zu liefern auch im Sinne der freien Verfügbarmachung von Kulturdaten. Andererseits konkurrieren sie auf dem Server mit realen Menschen. Gerade das Generieren von PDFs ist rechenintensiv und ein Abschalten der Funktion bei hoher Auslastung des Servers bringt relativ wenige negative Konsequenzen (dieselben Daten finden sich auch auf Objektseiten). Dadurch, dass die Sprache beim Blocken der Funktionalität berücksichtigt wird, ist die Wahrscheinlichkeit, dass tatsächliche Nutzer in Mitleidenschaft gezogen werden, weiter beschräkt.
• Sammlungsspezifische ISIL-IDs werden jetzt auch in der LIDO-Schnittstelle berücksichtigt
• Alternative Nummern eines Objektes werden jetzt auf Objektseiten dargestellt
  • Ist in den Einstellungen für das Museum das Schema / die Art der weiteren Nummer hinterlegt, kann eine Erklärung dazu in einem Tooltip abgerufen werden

musdb

• Objektsuche
  • Type-Ahead-Suche für Sprache (des Inhalts eines Objektes)
  • Suche nach Bearbeitungsstatus von Objekten
• Stapelverarbeitung von Bearbeitungsstatus (offen, gesperrt, archiviert, etc.)
• Parameter des Volltext-Such-Indexes angepasst, um Kofferworte besser zu unterstützen

Importer

Kern

• Dry-Run-Modus hat neue Funktion, alle bisher nicht gemappten Werte zu sammeln und gemeinsam anzuzeigen
  • Damit können sie in der Folge einfacher und stapelweise über concordance.museum-digital.org gemappt werden
• Unterstützung für Import alternativer Nummern von Objekten
• Unterstützung für Import der Hierarchie von Räumen

Parser

• AdlibXml
  • Alternative Nummern werden jetzt ins entsprechende Feld importiert
• CsvXml
  • Alternative Nummern werden jetzt ins entsprechende Feld importiert
• CsvLocations
  • Neuer CSV-basierter Parser zum Import von Ortshierarchien
• ImageByInvno
  • Neue Einstellung: Append Chars (zum Hinzufügen regulärer Suffixe von Inventarnummern)

Frontend

• Objekte, die mit einer Quelle verlinkt sind (als Referenz auf die Quelle oder in der Quelle referenziert), werden jetzt auf der Seite der Quelle gelistet
  • Beispiel: Quelle: „Novalis Schriften. Die Werke Friedrich von Hardenbergs. Historisch-kritische Ausgabe. Erster Band: Das dichterische Werk. 3. Auflage“
• Anzeige von Notizen, Status & Typ für Transkription ist jetzt auf der Objektseite implementiert
• Neue Typen zur Klassifikation von Beziehung von Objekt zu Schlagwort
  • Taxon
  • Thema
  • Erwähntes (Analog zu „abgebildetes“)
• Dependencies
  • OpenLayers auf Version 10.6 geupdatet

musdb

• Verhinderung von Umbenennen von Vokabulareinträgen zu geblacklisteten Begriffen
  • Zuvor konnte man „Unbekannt“ anlegen, wenn man einen neuen Begriff angelegt und den neuen Begriff in der Folge zu „Unbekannt“ umbenennt
• Seitenspalte / Filter für Suche nach Objektgruppen
• Neue Typen zur Klassifikation von Beziehung von Objekt zu Schlagwort
  • Taxon
  • Thema
  • Erwähntes
• Neue APIs: Alle mit Objekten des Museums verlinkten Vokabulareinträge
• Dependencies
  • OpenLayers auf Version 10.6 geupdatet

Importer

• Kern
  • Deakzessionen importieren ist jetzt implementiert
  • Empfänger eines Deakzessions-Vorgangs kann jetzt als Bezug zum Adressbuch gesetzt werden
• Parser
  • CSVXML: Deakzessionen importieren ist jetzt möglich
  • ImageByInvno: Option für Zuordnung alle Buchstaben vor einer gegebenen Komibination zu ignorieren

CSVXML

• Neue Felder: tag_related_identifier_type, tag_related_identifier

Vorträge etc.

• Vortrag „Von museum-digital zum eigenen Online-Katalog“ bei der AG Digitalisierung des Museumsverbands Rheinland-Pfalz
  • Folien als PDF
  • Folien als ODP zur Nachnutzung

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

Die allgemeine Entwicklung dieses Jahr deutet auf weniger kleinere Entwicklungen in den Kernbereichen, aber dafür größeren / aufwendigeren einzelnen neuen Features. Siehe etwa die Versionierung in musdb aus dem Januar, das Tool zur Import-Automatisierung im März (andere nennen es Hotfolder), die Sortierung nach ästhetischem Score im öffentlichen Bereich, ebenfalls im März, oder die Funktion zur KI-gestützten Generierung von Objektbeschreibungen im Juni. Diese Tendenz setzt sich erst einmal fort.

Juli

Frontend

• Übersetzung nach Hindi und Telugu
• Untergruppierung von Schlagworten, falls mehr als 10 gesetzt sind
  Die Beziehung in zwischen einem Objekt und seinen Schlagworten kann in musdb klassifiziert und spezifiziert werden. Mögliche Beziehungs-Typen sind etwa „Objektart“, „Material“, „Technik“, und „Abgebildetes“. Gerade bei „Abgebildetes“ kann, bei entsprechenden Objekten und entsprechend ausführlicher Erfassung, eine hohe Menge von Schlagworten verknüpft werden. Um die Übersichtlichkeit zu wahren, werden die Schlagworte auf einer Objektseite nach ihrem Beziehungs-Typ gruppiert, sobald mehr als zehn Schlagworte mit dem Objekt verknüpft sind.
  

musdb

Neue Features

• Export-Option für LIDO, wie es vom Koloniale Kontexte-Portal der Deutschen Digitalen Bibliothek erwartet wird

Verbesserungen & Änderungen

• Mindestlänge für Volltextsuch-Begriffe sind jetzt in der Benutzeroberfläche (Suche verfeinern) sichtbar
  Volltext-Suchbegriffe in musdb müssen, damit der Suchserver nicht überlastet wird, mindestens zwei Zeichen lang sein. Bisher wurden Suchparameter mit kürzeren „Suchbegriffen“ schlicht ignoriert. Seit Juni ist ein Abschicken einer entsprechenden Abfrage über die erweiterte Suche nicht mehr möglich – dass zwei Zeichen das Mindestmaß sind, wird schon im Suchdialog kommuniziert.
• Rezeptionsgeschichte: Angaben für Position in Quelle können jetzt bis 40 Zeichen lang sein
• Transkriptionen
  • können jetzt 4000000 Zeichen lang sein
  • Neue Felder: Notiz, Status, Zielsetzung

Bugfixes

• Fehler beim Stapelweisen verstecken von Feldern vom Reiter Zusatz korrigiert

Juni

Frontend

• Performance-Verbesserungen
  • Objekt-Suche kann ohne Verbindung zu Such-Server arbeiten (falls keine Volltextsuche durchgeführt werden soll)
  • Suche nach Zeit und Zeit vor/nach ignoriert Zeit vor/nach, falls Zeitbegriff spezifischer ist
• Verbesserungen beim Löschen von PDF-Dateien
• Übersetzung: Tamil

musdb

Neue Features

• Empfänger für Deakzession kann aus dem Adressbuch heraus verknüpft werden
• KI-generierte Objektbeschreibungen auf Basis anderweitiger Metadaten

Verbesserungen

• Objekt-Suche kann ohne Verbindung zu Such-Server arbeiten (falls keine Volltextsuche durchgeführt werden soll)

Importer

• CSVXML-Parser ergänzt um
  • neue Ereignistypen
  • Markierungen
• Automatisch generierte Objektgruppe für alle Objekte aus einem Import: Beschreibung kann festgelegt werden (per Settings)

nodac

• Auswählbare (Navigations-)Sprachen sind jetzt auf die, in denen tatsächlich eine Übersetzung vorliegt, beschränkt

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

Neue Features

• Tabs sind jetzt aktiviert, wenn das md-Frontend als PWA installiert ist (Siehe)

Verbesserungen

• Doppelte alpha / omega -Suchen (Aktivität vor / nach) werden entfernt
  Bei einer Suche nach „Objekte nach 1900, die auch nach 2000 sind“ ist eine der Angaben doppelt. Die letztere Bedingung kann und sollte ignoriert werden, weil das Jahr 2000 immer nach dem Jahr 1900 ist.
  Durch die Timeline konzentrieren sich Web-Crawler gerne auf Suchen, und besonders alpha/omega-Suchen. Das Problem kann hiermit eingeschränkt werden.
• Links, die auf der Timeline nicht auf konkrete Objekte verweisen, sind jetzt mit rel=nofollow markiert
  Bots werden angewiesen, sie zu ignorieren.

musdb

Neue Features

• Tabs sind jetzt aktiviert, wenn musdb als PWA installiert ist (Siehe)
• Neue Suchoption für Objekte: „Kann publiziert werden“
  Sucht nach Objekten, die bisher nicht veröffentlicht sind, aber eine ausreichende Beschreibung und mindestens eine Abbildung haben.
• Stapelweises eintragen von Maßangaben
  Verfügbar über „Treffer zuordnen“
• Institutionsweite Einstellung: Benutzerdefinierte Objekt-Bearbeitungsmaske kann für alle Nutzende aus einem Museum verpflichtend machen
  Deaktiviert die reguläre Objekt-Bearbeitungsmaske für alle dem Museum zugeordneten User.
• Ausstellungen können jetzt über die API gesucht werden
  API-Route: /exhibition/list
• User-Agent (Browser-Kennung) wird beim Seitenaufruf auf Änderung gecheckt. Automatischer Logout bei Änderung.
  Hilft etwas gegen Session-Hijacking.

Verbesserungen

• Panorama für Tour von Ausstellung / Institution wird jetzt auf 2400 px Höhe statt 1400 px heruntergerechnet
• APIs zur Suche nach Einträgen in den kontrollierten Vokabularen sind jetzt über den zentralen API-Endpunkt verfügbar
  Siehe z.B. /actor/search_linked_to_objects/{term} , /actor/search/{term} etc.

Bugfixes

• Fix: „Visiting scientists“ konnten Reiter „Verbleib“ nicht öffnen (verlangte Berechtigung für museumsweite Rechte)
• Fix: Benutzerdefinierter Vorgabewert für Beschreibung bei neuen Objekten wurde beim Anlegen neuer Objekte ignoriert
• Fix: Thumbnails wurden als doppelte Bilder für Ausstellungen angezeigt (Reiter „Bilder“)
• Fix: „Voranstellen“ übertrug Werte des vorherigen Objektes neben dem eingegeben Wert beim „Globalen Ändern“

Importer

Neue Features

• Neuer Parser für CSV-Exporte / Importe aus Robotron Daphne

Verbesserungen

• CSVXML-Parser
  • Neue Literatur-Felder (ISSN, Herausgeber, etc.) sind jetzt abgedeckt
  • Wikidata-Referenzen für Tags werden jetzt importiert
• Länge für einzelne Schlagworte wird zentral auf 95 Buchstaben reduziert

Bugfixes

• Einige neuere Felder aus dem Reiter Objektverwaltung waren korrekt geparst, aber bisher nicht in die Datenbank übertragen worden

nodac

Neue Features

• Tabs sind jetzt aktiviert, wenn das md-Frontend als PWA installiert ist (Siehe)

CSVXML

Verbesserungen

• Neue Literatur-Felder eingefügt: Typ, Herausgeber, Ausgabe, ISSN

• Übersetzung: Kannada
• Im Menü für Zitiervorschläge bei Objekten können Museen jetzt ihre eigenen Zitierhinweise anzeigen lassen
  Das ist relevant, wenn es objektartenspezifische Zitierweisen gibt, und das Objekt (im Gegensatz zum Datensatz) zitiert werden soll.
• Oder-Suchen können innerhalb eines Suchbegriffs geklammert durchgeführt werden, etwa: place:61~1
  • Bisher nur mithilfe der Abfragesprache nutzbar
    • d.h. es gibt bisher keine Umsetzung im „Erweiterte Suche“-Menü
    • Über die Abfragesprache ist es auch über die API benutzbar
  • Funktioniert nicht bei Zeiten und ganzen Ereignissen

musdb

• Einstellungen für das Museum
  • Verstecken von Freitextfelder, wo inhaltlich gleiche kontrollierte Felder verfügbar sind
    • Beispielsweise der Eingang eines Objektes kann über Freitextfelder oder über die Verknüpfung mit einem Erwerbungsvorgang verzeichnet werden. Mit der neuen Funktion können die Freitextfelder versteckt werden, sodass gesichert ist, dass im Museum einheitlich erfasst wird.
  • Institutionsspezifische Zitierhinweise können für die Ausgabe eingestellt werden
• Buchstabensuche nach Inventarnummer jetzt wieder möglich
• Bei eingeschränkten Ereignissen (z.B. Ereignis ohne Ort) gab es verschiedenen Umgang bei Import, CSVXML und Eingabe, das wurde bereinigt / angeglichen
• Refactoring in administrativer Kommandozeile
  Insbesondere mit vielen Überarbeitungen in Autokorrekturtools
  Folge: Schnellexporte werden jetzt automatisch täglich generiert
• Getrenne Maßangaben neu positioniert auf Reiter: Zusatz
• Weblinks für Objektgruppen können jetzt erfasst werden

Importer

• Eigene neue Art von Grund-Aufgaben: Harvester
  • Erste Nutzung: OAI-Harvester für LIDO
• Externe Abbildungen („Resourcen“), die nicht JPG sind können importiert werden
• Lido-Parser deutlich erweitert, kann mehrsprachige Objektinformationen importieren
  • Lido Terminology wird benutzt um mehrere Maßangaben zu importieren

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

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.

• Grundlegende Reimplementation der Erfassung von getrennten Maßangaben (Reiter „Zusatz“)
  • Die Auswahl der Messgrößen (Breite, Länge, etc.) ist jetzt über eine kontrollierte Liste umgesetzt, die leicht erweitert werden kann. Auch abgestufte / spezifizierte Messgrößen können festgehalten werden (z.B. „Breite des Sockels“).
  • Neu sind die Möglichkeit, die Exaktheit einer Messung und Notizen zu dieser Festzuhalten
• Auswahl der „Räume“ beim Festhalten eines aktuellen Aufenthalts eines Objektes ist jetzt alphabetisch sortiert
• Eindeutige Identifikatoren für Beziehungen zwischen Schlagwort und Objekt werden erkannt und automatisch ausgewertet („Apfel (Motiv)“ –> „Apfel“ + „Abgebildetes“)
• Äquivalenz von Abgebildetes mit Dargestellter Person oder Dargestellter Ort ist jetzt in Autokorrekturen abgebildet (Berlin (Motiv) –> 1. Schlagwort wird zu Berlin + Abgebildetes –> 2. Berlin ist Ort –> Ereignis: Wurde abgebildet, wer: Berlin)

Frontend

• Neue Implementation von getrennten Maßangaben ist auch hier umgesetzt

Import

• Import von getrennten Maßangaben nutzt neu Implentation der getrennten Maßangaben (siehe musdb)
• Eindeutige Identifikatoren für Beziehungen zwischen Schlagwort und Objekt werden erkannt und automatisch ausgewertet (Schlagwort: „Apfel (Motiv)“ wird automatisch korrigiert zu Schlagwort: „Apfel“ + Bezug zwischen Objekt und Schlagwort: „Abgebildetes“)
• Äquivalenz von Abgebildetes mit Dargestellter Person oder Dargestellter Ort ist jetzt in Autokorrekturen abgebildet („Berlin (Motiv)“ –> 1. Schlagwort wird zu Berlin + Abgebildetes –> 2. Berlin ist Ort –> Ereignis: Wurde abgebildet (Ort), was: Berlin)
• Verknüpfung von Objekt zu Objekt war bisher über Weblink, jetzt wird über den extra für Objekt-Objekt-Bezüge vorgesehenen Datentyp verknüpft (d.h.: Verknüpfte Objekte werden beim Veröffentlichen erst angezeigt, wenn beide Objekt-Datensätze sichtbar sind)

nodac

• Beim Zusammenführen von zwei Vokabulareinträgen werden jetzt auch Ausstellungen, Sammlungen etc. in den verknüpften Instanzen berücksichtigt und umgeschrieben
  • Bisher wurde schon auf deren Existenz geachtet. Ein Umschreiben war dabei jedoch nicht implementiert, sodass das Zusammenführen nicht vollständig durchgeführt werden konnte und weiterhin beide Einträge im Vokabular verblieben.
• Ist ein Begriff als „Immer ein Schlagwort“ markiert, so erscheint der Schalter „Diesen Eintrag ins Akteursvokabular transferieren“ nicht mehr
• Wenn zwischen Vokabularen verschoben wird, dann werden die Beziehungs- und Ereignistypen (Abgebildetes / Dargestellte Person / Dargestellter Ort) berücksichtigt und entsprechend umgeschrieben
  • Ist bei einem Objekt etwa notiert, dass dieses das Schlagwort „Berlin“ darstellt, wird beim Übertragen des Schlagworts „Berlin“ in das Ortsvokabular aus dem Schlagwortbezug ein Bezug auf den „Abgebildeten Ort“ „Berlin“.
• Funktion „Begriff aufspalten“ (Orte und Schlagworte) schlägt Ziele der Aufspaltung auf Basis der permanenten Umschreibungen vor
  • Ist also etwa notiert, dass „Cöln“ immer in „Köln“ umgeschrieben werden soll, so erkennt das System automatisch, dass der Begriff „Cöln & Berlin“ aufgespalten werden kann – in „Köln“ und „Berlin“.
• Kontextmenu in Übersichten (Rechtsklick auf einen Eintrag in der Tabelle) bietet direkten Zugriff auf verschiedene Funktionen

Diese sind in Form von Auflistungen gehalten, und so soll es nun auch hier sein.

Frontend

Features & Verbesserungen

• Einige Verbesserungen bei Hintergrundscripten, v.a. besseres Handling von Timeouts beim Errechnen der „Ähnlichen Objekte“ in sehr großen Instanzen
• Beitragende, verknüpfte Orte und Zeiten zu einer Objektgruppe werden jetzt alphabetisch nach Namen sortiert aufgelistet
• Tabellenköpfe für Ereignis-Komponenten (wer, wann, wo) werden im A4-PDF nur noch angezeigt, wenn auch Inhalt für die Zeile vorhanden ist
• Neue Suchoption für Objektsuchen: „Ist derzeit ausgestellt“
• Links zum Themator nutzen jetzt das neue URL-Schema des Themators
  (https://themator.museum-digital.de/t/690 statt https://themator.museum-digital.de/ausgabe/showthema.php?m_tid=690&tid=690)

Bugfixes

• Fehler beim Suchen nach kontrollierten Listen-Begriffen, die mehrere Leerzeichen beinhalteten, über das „Suche verfeinern“-Overlay (Suche nach Lizenz „Public Domain Mark“)
• Exaktheits-Einstellung im „Suche verfeinern“-Overlay wurde nicht übertragen
• Einfache Einbettung eines Objektes (analog z.B. zu Youtube-Videos; erreichbar über das „Zitieren“-Menü einer Objektseite) hatte diverse Fehler / funktioniert jetzt wieder

musdb

Features & Verbesserungen

• In der API-Dokumentation von musdb gibt es jetzt einen Hinweis, dass auch das Frontend eine API hat
  • Frontend-API
    • Für die Nutzung der API des Frontends muss man sich nicht authentifizieren
    • Die API des Frontends ist tendenziell schneller und einfacher zu nutzen
    • Ist nur lesend
  • musdb-API
    • Kann mehr: Kann auch nicht öffentliche Bestände und Felder / Datentypen sehen
    • Ist sehr viel feingliedriger (mehr Aufrufe für dieselben Daten, dafür bekommt man ggfs. genau die Daten, nach denen man sucht, statt gleich das ganze Objekt)
    • Kann schreiben
• Vorschlagslisten bei Suche nach Vokabularbegriffen in der Seitenspalte der Objekt-Suchseite überarbeitet
  • Tooltips erscheinen beim Überfahren
  • Implementation in Vanilla JS, ausbauen von jQuery
    (das bedeutet eine deutlich bessere Performance der Suchergebnisliste im Listenformat, weil jQuery nicht mehr geladen werden muss)

• Benutzerseite / Login
  • Log der Logins jetzt auch mit IP und User-Agents
  • Login per im Browser persistierten Login („Remember me“) wird geloggt und angezeigt
  • Alle per Cookie dauerhaft eingeloggten Browser werden nach Passwortwechsel zu einem neuen Login gezwungen
  • Neue Option, um alle gemerkten Logins auf anderen Geräten zu invalidieren (Browser muss neu eingeloggt werden

• Objekt
  • Mehr Restriktionen für Publikation von Objektdatensätzen.
    Es kann nicht mehr veröffentlicht werden, wenn:
    • … der Objektname der Objektbeschreibung gleicht
    • … die Beschreibung die Zeichenkette „lorem ipsum“ beinhaltet
  • Beim Depublizieren / Verstecken von Objektdatensätzen werden die mit dem Bild verknüpften Abbildungen umbenannt (und so Links zu den Bildern invalidiert). Beim erneuten Publizieren wird das rückgängig gemacht, sodass die Links wieder funktionieren.
  • Räume werden jetzt beim Verknüpfen als eigentlicher Standort alphabetisch aufgelistet
• Literatur
  • Erwerbungen können jetzt mit Literatur verknüpft werden
    • Darüber z.B. auch Vorbesitzer etc.
  • Räume (eigentlicher Standort) können mit Literatur verknüpft werden

Bugfixes

• Overlay zur Einstellung von Suchen nach Objekten: Mehrwortige Suchbegriffe wurden in mehrere Suchen umgewandelt, statt als Kette von Worten gesucht zu werden („roter Helm“ > „roter“ UND „Helm“ statt „roter Helm“)
• Fehler beim Suchen nach kontrollierten Listen-Begriffen, die mehrere Leerzeichen beinhalteten, über das „Suche verfeinern“-Overlay (Suche nach Lizenz „Public Domain Mark“)

Importer

• Verknüpfung zwischen Literatur und Räumen (eigentlicher Standort) sowie Erwerbungen ist im Kern implementiert
• ImageByInvno-Parser (Zuordnung von Abbildungen zu Objekten per im Dateinamen enthaltenen Inventarnummern) kann jetzt auch PDFs importieren

files.museum-digital.org

• Kleines Script hinzugefügt, um PDF-Metadaten auf Basis einer kleinen XML-Datei zu setzen. Siehe z.B.: https://files.museum-digital.org/de/Praesentationen/2024-10-18_md-deutschland-eV-stellt-sich-vor_Usertreffen_MA.xml

Beitragsbild generiert mit illustriousXL_smoothftSPO

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

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.

Ausgehend von diesem Hintergrund gibt es nun einen zweiten Anwendungsfall für museum-digital:qa: Es kann nun als Werkzeug zum Konvertieren eingesetzt werden. Wie gewohnt können die meisten für den Import in museum-digital unterstützten Formate zum Hochladen von Daten verwendet werden – z.B. eine einfache CSV-Struktur, die wir regelmäßig zum Importieren von Daten verwenden, die zuvor in Tabellenkalkulationsprogrammen gehalten waren – die dann in diejenigen XML-Formate konvertiert werden, in die Benutzer ihre Objektdaten in musdb exportieren können (wobei wiederum Code aus musdb nachgenutzt wird).

Derzeit werden das Konvertieren nach LIDO (beide Versionen 1.0 und 1.1) und EODEM unterstützt. Vor allem Letzteres könnte interessant sein: EODEM ist eine kürzlich veröffentlichte Erweiterung von LIDO, die einen deutlich vereinfachten Datenaustausch zwischen verschiedenen Institutionen im Rahmen von Leihverkehren ermöglichen soll. Das ausleihende Museum exportiert die Daten der für den Leihverkehr relevanten Objekte aus seinem Sammlungsverwaltungssystem in EODEM; das leihende Museum importiert es dann und hat sofort alle relevanten Informationen in seinem jeweiligen Sammlungsmanagementsystem – ohne dass die Daten, wie bisher oft üblich, von Hand abgeschrieben werden müssen. Der Nutzen von EODEM in der Praxis hängt jedoch davon ab, inwieweit es von den verschiedenen Sammlungsverwaltungssystemen unterstützt wird.

Inden es eine Möglichkeit zur Konversion aus vielen Formaten hin zu EODEM bietet kann museum-digital:qa also hoffentlich dazu beitragen, die Vorteile von EODEM auch solchen Museen zugänglich zu machen, deren Sammlungsmanagementsoftware den Export in den Standard noch nicht unterstützt.

Image: Bell Telelphone crew with a dog, ca. 1892

Der Erfolg und die weitere Verbreitung von EODEM hängen aber weiter von zwei kritischen Faktoren ab. Einerseits müssen Entwickler und Softwareanbieter EODEM-Import- und Exporttools in ihren Sammlungsverwaltungssystemen implementieren. Andererseits müssen die entsprechenden Funktionen zugänglich und einfach zu genug zu verwenden sein, dass sie auch tatsächlich genutzt werden.

musdb deckt die erste Bedingung wie gesagt bereits seit einigen Monaten ab. Die Zugänglichkeit aber war sicher – insbesondere für kleinere Museen mit weniger technisch versiertem Personal – noch ausbaufähig. Im letzten Monat haben wir daran gearbeitet, sie zu verbessern. Mittlerweile ist es möglich EODEM-Daten sowohl zu exportieren als auch zu importieren, ohne dass es spezielle Software abseits des Dateimanagers und eines Browser bräuchte. verwendet werden muss.

EODEM-Daten exportieren

Der Export von EODEM-Daten (v.a. bei ausgehenden Leihverkehren) ist im oben verlinkten Beitrag ausführlich beschrieben und war schon damals recht leicht zu benutzen. Sind die Objekte in musdb mit dem gegebenen Leihverkehr verknüpft, erscheint in der Seitenspalte links auf der Seite des Leihverkehrs ein Export-Button spezifisch für den Export der Objektdaten in EODEM.

Einfach importieren?

Das Importtool von Museum-Digital bietet eine große Auswahl an auswählbaren „Parsern“ (im Wesentlichen Formaten der zu importierenden Daten) und Einstellungen für viele davon. Es mag zum Importieren von fünf Objekten ohne verknüpfte Bilddateien oder von 50000 Objekten mit extern gespeicherten Bilddateien, die während des Imports heruntergeladen werden müssen, verwendet werden. Während der Import im ersten Fall in wenigen Sekunden abgeschlossen ist, kann letzterer abhängig von der Geschwindigkeit des externen Bild-Servers Stunden dauern.

Um Zeitüberschreitungen zu vermeiden und Benutzern die volle Flexibilität des Importers zu bieten – und dazu eine einfache Automatisierung zu ermöglichen -, funktioniert der Upload-Workflow bei Importen über das WebDAV-Protokoll. Hiermit wird der Import in einer Klartext-Konfigurationsdatei konfiguriert und die Importdaten können in entsprechende Ordner für Metadaten und Mediendateien hochgeladen werden. Abschließend prüft ein Skript alle vier Stunden, ob im jeweiligen Verzeichnis für ein Museum Importdaten vorhanden sind und importiert diese im Hintergrund. Dieser Prozess funktioniert hervorragend für große Importe und Migrationen. Für kleinere Importe ist er aber doch alles andere als zugänglich.

Da EODEM-Importe einem vordefinierten Standard folgen und einen klar umrissenen Anwendungsfall haben, konnten wir ein direktes Upload-Formular für EODEM-Importdaten direkt in der Seitenspalte der Bearbeitungsseite von Leihverkehren einbauen. Hier findet sich jetzt eine neue Upload-Box „EODEM-Daten importieren“. Klickt man darauf öffnet sich ein Overlay, mit dem die EODEM-XML-Dateien hochgeladen werden können. Anschließend werden die XML-Dateien in das übliche Importverzeichnis des Museums hochgeladen und die Konfiguration automatisch mit den gängigen Einstellungen für EODEM-Importe geschrieben.

Das Upload-Feld in der Seitenleiste ist nun aktualisiert und zeigt eine Meldung mit Einzelheiten zum verbleibenden Arbeitsablauf an: Man muss nur noch warten, bis die Importdaten verarbeitet wurden. Nach Abschluss des Imports erhält man eine E-Mail an die für das eigene musdb-Konto angegebene E-Mail-Adresse.

Wenn man nun sich die importierten Objektdaten ansieht, erkennt man schnell die Auswirkungen einer kleinen neuen Funktion. Der Importer bestimmt automatisch anhand der Inventarnummer, ob er Objekte aktualisieren oder neue hinzufügen soll. Wenn zwei Museen das gleiche Inventarnummernschema verwenden, könnte es damit dazu kommen, dass die Leihobjektinformationen die Daten eines anderen Objekts im Museum überschreiben. Um solche Fälle – so selten sie auch sein mögen – zu verhindern, wird der Inventarnummer des Leihobjekts automatisch die ID der Leihgabe vorangestellt.

EODEM-Importe können somit jetzt direkt über die Weboberfläche und mit minimaler Gefahr von Datenverlusten durch fälschliches Updaten durchgeführt werden. Die einzige Einschränkung besteht darin, dass auf diese Weise durchgeführte EODEM-Importe den Import von Objekt-Abbildungen nicht unterstützen, da hierfür eine zusätzliche Einstellung erforderlich gewesen wäre, um festzustellen, ob die Bilder zusammen mit den Importmetadaten gesendet wurden oder sich auf einem über das Internet zugänglichen Verzeichnis befinden Server – oder ob sie schlicht fehlen.

Ein Blick in die Zukunft

musdb deckt nun beides ab – EODEM-Importe und -Exporte sind nicht nur mehr implementiert und nutzbar, sondern sie sind mittlerweile hoffentlich auch sehr einfach zu nutzen. Die EODEM-Arbeitsgruppe steht weiterhin kurz vor der Veröffentlichung des endgültigen Standards und weitere Implementierungen sind für die kommenden Versionen einiger weiterer Sammlungsmanagementsysteme angekündigt.

Es ist wahrscheinlich, dass das Testen des EODEM-Imports mit realen Daten aus anderen Systemen aller Standardisierung zum Trotz noch einige weitere Anpassungen erfordern wird. Wir freuen uns auf solche Fälle und auf mehr Nutzer des EODEM-Standards, sowohl im Hinblick auf die Anbieter, die ihn unterstützen, als auch auf die tatsächlichen Museen, die davon profitieren können.

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.