• 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

• Anzeige der Transkriptionen auf Objektseite grundsätzlich überarbeitet
  • Titel wird ausgegeben
    • Falls nicht vorhanden werden weiterhin Art (Original vs. Übersetzung) als Ersatz für den Titel genutzt
  • Transkriptionen sind sortiert nach Titel
  • Kachel-Darstellung deutlich verbessert
    • Probleme mit horizontalem Scrolling sind gelöst
    • Bei nur einer Transkription ist diese auf gesamter Breite dargestellt
    • Bei mehr als 2 Transkriptionen sind die jeweiligen Inhalte by default eingeklappt, lassen sich aufklappen
• Stapelweises Abfragen von Objektmetadaten über die API
  • Bisher verfügbare Formate: JSON, LIDO
  • API-Dokumentation
  • Siehe auch: Blog-Post dazu auf Englisch
• Punkte in Gleitkommazahlen bei Maßangaben auf Objektseite sind bei Anzeige in Deutsch durch Komma ersetzt
• Sammlungsspezifische ISIL-Nummern werden in LIDO-API genutzt

musdb

• Titel / Name von Transkriptionen kann nun erfasst werden
• ISIL-Nummern pro Sammlung
• Setzen von Objektart über Verbesserungsvorschläge setzt den Bezug jetzt korrekt als Objektart
• Zusätzliche Formen von Objekten in der Liste verfügbar
  • Z.B.: Rund, rechteckig
• Suche nach Objektgruppen ohne/mit übergeordneten Objektgruppen

Vorträge etc.

• 08.10.2025: Vortrag auf der Herbsttagung der Fachgruppe Dokumentation des Deutschen Museumsbundes: „Interoperabilität schaffen – Geschichten aus 1001 Importen“
  • PDF
  • ODP
• 14.10.2025: Vortrag auf einer Tagung des Projektes CiVers (Citation of Versioned Web Pages by PID)
  • PDF
  • ODP
• 17.10.2025: museum-digital Usertagung 2025

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

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.

Entwicklung

musdb

• Tool zur KI-gestützten Erkennung von Bildinhalten (Schlagworte -> Abgebildetes)
  • Muss explizit für eine Sammlung aktiviert werden, über einen neuen Schalter in der Seitenspalte der Sammlungs-Bearbeitungs-Seite
  • Nutzbar als Auswahlliste im Verschlagwortungs-Overlay auf der Objekt-Bearbeitungs-Seite
  • Siehe auch den Blog-Beitrag: https://blog.museum-digital.org/de/2025/08/27/automatische-erkennung-von-abgebildeten-elementen/
• Inhalte im Feld „Ausgabe“ bei Literatur können jetzt bis 50 Zeichen lang sein
• Hochgeladene PDFs können jetzt bis 40 MB groß sein
• Neue Kommandozeilen-Option, um alle Rechte eines Accounts auf den rollenbasierten Standard zurückzusetzen
• Neuer Ereignistyp: „Verändert“

nodac

• KI-generierte Vorschläge für Definition und übersetzte Namen bei Schlagworten
  • Sichtbar rechts in der Seitenspalte (großer Bildschirm)
  • Besonders auch genutzt und hilfreich, um Duplikate zu finden

Vorträge

• Posterpräsentation auf der CoRDI 2025 (Archivversion) in Aachen, 27.8,2025: „To Educate or to Enforce – The Case for Underhanded Methods to Improve Research Data“
  • PDF
  • Abstract / Zenodo

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

Mit einem neuen KI-Feature zur Bildklassifikation, das ab Donnerstag Nacht bereit stehen wird, versuchen wir aus unseren Fehlern zu lernen. Bevor dieses vorgestellt wird aber seien die damaligen Fehler besprochen.

Bildklassifikation, Versuch 1

Im ursprünglichen Anlauf zur Bildklassifikation wurden alle Abbildungen zu allen Objekten entweder beim Upload oder über eine gezielt dazu eingerichtete Seite klassifiziert.

Die Abbildungen wurden dabei an ein KI-Modell übergeben, und seine (englischen) Ausgaben mit dem Schlagwort-Katalog von museum-digital abgeglichen. Die gefundenen Schlagworte wurden dann als Schlagwort-Vorschläge angeboten.

KI braucht passende Hardware

KI-Tools arbeiten am besten auf Grafikkarten. Das, was ein herkömmlicher Webserver nicht hat, ist eine Grafikkarte. Also entschieden wir uns für den offensichtlich klugen Weg: Mithilfe von Tensorflow.js wurden die Berechnungen auf die Geräte der gerade eingebenenden User ausgelagert.

Gut: Die Berechnungen liefen nicht mehr auf der ungeeigneten Server-Hardware. Schlecht: Wer einen durchschnittlichen PC in einem kommunalen Museum kennt, sollte wissen, dass er vielleicht eine Grafikkarte haben mag – aber dann höchstwahrscheinlich auch nur eine Office-Grafikkarte aus dem untersten Preissegment. Und vor allem 2021 waren die meisten Laptops nicht besser für KI-Anwendungen geeignet, als die Server-Hardware von museum-digital. Ergo: Die Berechnungen zur Bildklassifikation dauerte lange(!).

Workflows

Schlimmer noch: Die Berechnungen zur Bildklassifikation waren blockierend. D.h., dass man in dem Browserfenster, in dem die Berechnungen ausgeführt wurden, nicht weiter arbeiten konnte. Dadurch, dass die Bildklassifikation in den Objekt-Ersterfassungs-Workflow eingebaut war, verlangsamte sie diesen deutlich.

In der Reflexion lässt sich feststellen, dass, solange keine wirklich gute Hardware zur Verfügung steht, KI-Anwendungen zu Anfang oder zu Ende des Erschließungsprozesses und von diesem getrennt / im Hintergrund eingesetzt werden sollten. Zu Anfang der Erschließung, wenn nur die Inventarnummer und hoffentlich ein Bild vorliegen, kann z.B. Bilderkennung nützlich sein, um Eingabehilfen und Vorschläge zu generieren. Die erratische Natur von KI – meistens richtig, mal falsch, und bei jedem Durchlauf unterschiedlich – spielt somit keine Rolle, weil es sich nur um später von Menschen nachbearbeitete, akzeptierte oder abgelehnte Vorschläge handelt.

Zu Ende des Erschließungsprozesses kann KI sinnvoll eingesetzt werden, um einerseits auf Basis der vorliegenden Daten zusätzliche Datenfelder zu befüllen (KI-generierte Objektbeschreibungen mit Zwischenspeicherung) oder zusätzliche Funktionen, die naturgemäß schwammigen Kategorien folgen anzubieten (Sortierung nach Ästhetik von Thumbnails).

Der Einsatz von KI-Tools in Echtzeit, wie er im ursprünglichen Bildklassifikations-Tool erwartet wurde, kann mit entsprechend guter Hardware sinnvoll sein. Die im Juni vorgestellte, in Zusammenarbeit mit dem Zuse-Institut und digiS testweise bereitgestellte, Erstellung von Objektbeschreibung auf Basis bestehender Metadaten ist ein gutes Beispiel. Im Zuse-Institut kommt hierzu eine Nvidia GH-200 zum Einsatz. Der Preis der Hardware alleine übersteigt das Jahresbudget vieler Museen.

Die Wahl des Modells sei weise getroffen

Weil eben die Hardware unzureichend war und wir eine Bildklassifikation in Echtzeit ermöglichen wollten, waren wir bei der ursprünglichen Bildklassifikation auf kleine, sehr effiziente Modelle angewiesen. Nach einigem Suchen endeten wir bei MobileNet.

MobileNet kommt zwar prinzipiell aus dem richtigen Bereich (Objekterkennung), hat aber offensichtlich sehr anders gelagerte Trainingsdaten. Straßenschilder und Tiere werden auch bei der vorliegenden, mittlerweile veralteren Version recht stabil erkannt. Anderes eher nicht.

Dass ein Modell mit einen der Verschlagwortung im Museumsbereich näheren ursprünglichen Einsatzgebiet bessere Ergebnisse geben sollte, bedarf eigentlich keiner größeren Erläuterung.

Für welche Objekte eignet sich Bildklassifikation?

Die ursprüngliche Bilderkennung hat also technische und organisatorische Probleme. Aber sie hat inhaltliche: Bilderkennung erkennt eben Bilder. Objekte sind Objekte. Eine annähernd deckungsgleiche Übereinstimmung zwischen Bild und Objekt kann vorliegen, muss aber nicht. Meist lässt sich das an Objektarten festmachen: Beschreibt man den Scan einer frühen Fotografie oder eines Ölgemäldes, beschreibt man gleichzeitig das Objekt. Beschreibt man das Foto eines Schranks, hat man wahrscheinlich deutlich weniger über das Objekt selbst und dafür mehr über die Umstände des Fotografierens gesagt.

Auch eine relativ naive, nicht spezifisch auf Objektabbildungen nachtrainierte Bilderkennung kann im Museumsbereich also sinnvoll sein, ihr Nutzen ist aber Kontextabhängig.

Der zweite Anlauf: Bilderkennung für abgebildete Elemente

Ab Donnerstag wird nun eine neue Funktion zur automatisierten Bilderkennung zur Verfügung stehen, die vor dem Hintergrund der Fehler des ersten Anlaufs spezifischer agiert und (hoffentlich) sinnvoller in bestehende Workflows integrierbar ist. Ziel ist die Erkennung von Bildinhalten spezifisch für solche Objekte, bei denen Bild und Objekt annähernd deckungsgleich sind.

Da dies eben nicht alle Objekte sind, muss das Feature spezifisch aktiviert werden. Dies ist über eine neue Einstellung auf Ebene von Sammlungen möglich.

Wird ein neuer Objektdatensatz erstellt, der einer Sammlung mit aktivierter Bilderkennung zugeordnet ist, und zu dem ein Bild vorliegt, so wird dieses später automatisiert mit Vorschlägen aus der Bilderkennung angereichert.

Hierzu wird die reguläre Suchfunktion genutzt, um relevante Objekte und ihre primären Abbildungen zu identifizieren. Diese werden auf lokale Entwicklungs-Maschinen (PC mit Grafikkarte – aber aktuellen, besseren Consumer-Modellen) heruntergeladen und dort ausgewertet. Die so generierten Schlagworte werden auf den Schlagwort-Katalog gemappt und zurück zum Server geschickt.

Ist das einmal geschehen, erscheinen sie als Liste von Checkboxen in der rechten Seitenspalte des Schlagwort-Overlays.

Auswahl des Modells

Dadurch, dass homogenere und stärkere Hardware zur Verfügung steht, können auch größere Modelle eingesetzt werden. Für das neue Feature kommt dabei Joycaption zum Einsatz. Dieses stammt aus dem Umfeld der Open-Source-Bildgenerierung und wurde gezielt für das Beschreiben von Bildern erstellt. Es unterstützt dabei sowohl Prosa- als auch schlagwortartige Beschreibungen.

Ein wichtiger Vorteil des Modells ist, dass es unzensiert ist, während kommerzielle Modelle bei möglicherweise problematischen Inhalten zunehmend eingeschränkt sind. So werden zuverlässig auch z.B. Aktzeichnungen erkannt und beschrieben.

Schlagworte

Joycaption verschlagwortet teils spezifischer als wir das im Rahmen von museum-digital getan hätten. „Schwarzes T-Shirt“ wäre etwa bisher nicht als Schlagwort zugelassen gewesen, ist aber im Sinne der Beschreibung visueller Elemente sinnvoll zuzulassen. „Schwarzes T-Shirt mit einem Ärmel“ wäre allerdings sehr spezifisch. Um die Ausgaben des Modells mit dem Schlagwortkatalog zusammenzubringen haben wir also für ca. 20000 Objekte Beschriftungen erstellt und die daraus resultierenden ca. 6000 Schlagworte auf die bestehenden Vokabulare gemappt.

Wo es bisher keine Entsprechung gab (und der Begriff nicht grundsätzlich unerwünscht ist [„Ohne Menschen“]), wurde ein neues Schlagwort angelegt. Gerade bei Begriffen wie dem „schwarzen T-Shirt“ sind die Begriffe denkbar einfach zu definieren: Ein T-Shirt, das Schwarz gefärbt ist. Entsprechend wurden die so neu eingerichteten Schlagworte automatisiert mit durch das LLM Gemma3 generierte Beschreibungen und deutsche Übersetzungen angereichert, die derzeit gesichtet und bereinigt werden. In diesem Arbeitsschritt werden auch überspezifische Begriffe wie „Schwarzes T-Shirt mit einem Ärmel“ mit unspezifischeren Begriffen („schwarzes T-Shirt“) zusammengeführt, sodass diese unspezifischeren Begriffe stabiler erkannt werden.

Workflows

Durch die nachgelagerte Arbeitsweise – erst Bildupload, dann warten, dann Verschlagwortung- macht der Einsatz der neuen Funktion besonders Sinn, wenn man institutionell einen arbeitsteiligen Workflow hat. Werden Objekte in einem Arbeitsgang von Inventarnummer bis Publikation erfasst, bietet das Tool wahrscheinlich wenig Mehrwert.

API: Wer kann berechnen?

Alle für die Bildklassifikation genutzten Abfragen auf dem Server sind, ebenso wie die Schnittstelle zum Eintragen der Ergebnisse der Klassifikation, auch über die API von musdb verfügbar.

Derzeit werden die API-Abfragen über die administrative Kommandozeile durchgeführt – eine Übersetzung hin zu einer Durchführung mithilfe der Webschnittstelle wäre aber ein leichtes und ist in der bestehenden Implementation schon mitgedacht. Hiermit könnten einzelne Museen die Berechnungen spezifisch für ihre eigenen Objekte durchführen und zeitlich unabhängiger agieren. Bei Interesse: Einfach schreiben. Der Aufwand hielte sich wie gesagt in Grenzen.

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.

In der Praxis ist es vor allem letzterer Punkt, weshalb Objektbeschreibungen bei museum-digital verpflichtend anzugeben sind. Aber oft zeigt sich, dass die tatsächlich erfassten Beschreibungen hinter den „strukturiert“ erfassten Metadaten zurückbleiben oder beide ausbaufähig sind. Dies ist oft eine Frage der Objektgattung und des fachlichen Hintergrunds. Gerade z.B. bei Druckgrafiken findet man oft eine grandiose Verschlagwortung mit minimalen Prosa-Beschreibungen. Andererseits leidet jeder mal unter einer Schreibblockade, und der ganze Museumsbereich unter einem Mangel von Arbeitskraft und Zeit.

Sind aber die sonstigen Objektdaten gut, und fehlt die Beschreibung – wie eben oft bei Grafiken – dann sollte sich doch eigentlich eine brauchbare mithilfe moderner KI formulieren lassen. „Sprache“ steckt ja wortwörtlich schon im Namen „Large Language Model“. Und ist das Erstellen von Prosa-Beschreibungen einfacher, sollte doch eigentlich mehr Zeit und Motivation übrig sein, um die Verschlagwortung zu verbessern.

KI-generierte Beschreibungstexte

Mit diesen Gedanken startet heute ein Versuch und damit eine neue Funktion in musdb: Klickt man beim Bearbeiten eines Objektes in das Feld „Objektbeschreibung“, erscheint ein neu Marker „Automatisch formulieren“. Mit einem Klick darauf öffnet sich ein Overlay, in dem nach einer Wartezeit drei Vorschläge für Objektbeschreibungen angeboten werden, generiert auf Basis der bestehenden Objektmetadaten und mithilfe dreier verschiedener Sprachmodelle.

Mit einem ersten Klick auf einen der Vorschläge wird dieser in Gänze sichtbar. Mit einem zweiten Klick öffnet sich der Text in einer Bearbeitungsansicht. Ist er fertig bearbeitet, kann er mit einem Klick in die Datenbank übernommen werden.

Um überhaupt Vorschläge generieren zu können muss der Datensatz angelegt sein und mindestens ein Ereignis und ein Schlagwort haben, wobei die Ergebnisse mit mehr und besseren Metadaten entsprechend besser und zuverlässiger werden. Aufgrund der Abfragemethode sollte man zudem darauf achten, die Objektart als Schlagwort zu erfassen und entsprechend auszuzeichnen.

Gedanken

Drei Vorschläge

Eine gewichtige Befürchtung am Anfang der Überlegungen war, dass die Möglichkeit, Objektbeschreibungen maschinell generieren zu lassen mittelfristig zu Nachlässigkeit und dem Akzeptieren falsch generierter Beschreibungen führen könnte. Dabei ist KI zwangsläufig – bauartbedingt – unzuverlässig, und ihre Ergebnisse sollten immer (!) noch einmal gegengeprüft werden, bevor man sie veröffentlicht.

Um dieser Befürchtung zu begegnen, werden nun eben drei alternative Vorschläge generiert. Um den passendsten zu finden, muss man erst einmal lesen. Das heißt, man muss sich mit den Vorschlägen auseinandersetzen, sodass eine Korrektur eventuell falscher oder verkürzter Stellen deutlich näher liegt.

Das Generieren dauert lange!

Gerade, wenn man viele Objekte eingibt, dauert das Generieren der Vorschläge derzeit noch zu lange. Im Schnitt braucht die Generierung zwischen 10 und 11 Sekunden. Was bei einem Objekt akzeptabel sein mag, wird bei 50 eine echte Arbeitserschwernis. Andererseits sind die derzeit ausgewählten Modelle (Gemma 2, Gemma 3, Phi4) ein guter Kompromiss zwischen Geschwindigkeit und guten Vorschlägen. Kleinere, schnellere Modelle haben bei unsern Versuchen keine vergleichbar guten Resultate erzielt.

Um das Tool trotzdem auch bei vielen Objekten effektiv nutzen zu können, kann man die Vorschläge „vorgenerieren“. Dazu geht man in die Objektübersicht, klickt auf eine Objekt-Kachel, hält die Maustaste gedrückt und zieht den Mauszeiger zur Seite. Damit öffnet sich die Stapelverarbeitung per Auswahl. Hier gibt es nun eine neue Funktion, eben um Vorschläge zu generieren und zwischenzuspeichern.

Ein guter Workflow wäre also etwa, die Objekte des Tages erst einmal in ihren Metadaten gut zu erfassen, und dann in der Mittagspause die Vorschläge generieren zu lassen. Nach der Mittagspause können diese dann abgearbeitet werden.

Kooperation: Hardware & Auswertung

Wie eingangs erwähnt handelt sich beim neuen Tool erst einmal um einen Versuch, der in Kooperation von digiS, dem Zuse-Institut Berlin und museum-digital entsteht. Durch diese Kooperation können die Beschreibungen auf der Hardware vertrauenswürdiger Partner (nicht OpenAI, sondern dem Zuse-Institut!) generiert werden.

Um die Potentiale und Nutzung des Einsatzes von KI in der Museumsdokumentation – und spezifisch des vorliegenden Tools – besser zu verstehen und das Tool weiterzuentwickeln, werden die Anfragen, die Vorschläge und die final abgeschickten Objektbeschreibungen gesammelt und in den nächsten Monaten systematisch ausgewertet (dabei werden Benutzerkennungen pseudonymisiert). Wir berichten!

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.

Um das Jahr 2021 haben wir in musdb und dem Frontend von museum-digital die Objekt-Suchfunktion grundlegend neu implementiert, um eine erweiterte Suche über (fast) alle relevanten Felder hinweg, die beliebig kombinierbar ist und z.B. auch ODER- oder NICHT-Suchen erlaubt, zu ermöglichen. Möglich wurde das durch den Einsatz eines dedizierten Suchservers (Manticore).

Während eine traditionelle relationale Datenbank (hier MySQL) darauf ausgerichtet ist, sehr effektiv erwartbare Abfragen, für die vorher ein Index angelegt wurde, zu beantworten, erlaubt der Suchserver eine bessere Performanz beim freien Kombinieren. Dazu bietet er erweiterte Features vor allem im Bereich der Volltextsuche (etwa eine Berücksichtigung von Flexionen). Andererseits ist er gezielt nicht auf Buchstaben-Suchen ausgerichtet. Ein allgemein unbedingt gewünschter Nebeneffekt der Nutzung von Manticore war also, das alle Suchen in Freitextfeldern zu Volltextsuchen wurden.

Probleme macht das aber eben bei Feldern, die eigentlich keine herkömmlichen „Text“-Felder sind, sondern nach einer (institutions-spezifisch) formalisierten Regel ausgefüllte Buchstabenkombinationen abbilden. Konkret: Standortangaben und Inventarnummern.

Im Falle der Standorte bietet das seitdem eingeführte Modul zur Raumverwaltung eine ohnehin bessere Alternative zu den herkömmlichen Freitextfeldern für Objekt-Standorte. Verknüpft man ein Objekt mit einem „Raum“, lassen sich hierarchische Suchen durchführen, Sensordaten mit den Objektdaten zusammenführen, man erhält ein detailliertes Log der Standortverschiebungen – und man hat durch die kontrollierte Liste von Räumen eine Sicherheit, dass nicht durch Tippfehler falsche Zuordnungen geschehen. Ein Migrationstool ist über das Dashboard in musdb verfügbar. Es spricht also eigentlich nichts mehr für die alternative Benutzung der herkömmlichen Standortfehler. Auch wenn dort eine Buchstabensuche Sinn machen würde, ist diese bei den eigentlich eh mittlerweile obsolet gewordenen Feldern somit leicht umgehbar.

Im Fall der Inventarnummern gibt es andererseits keinen solchen Ausweg: Eine Buchstabensuche wird unbedingt benötigt, und fehlte bis zu diesem Wochenende.

Die Grundlagen legen: Von MySQL zu Manticore und (ein wenig) zurück

Der Einsatz von Manticore war die Basis für die Implementation der neuen, verbesserten Suchfunktion. Mit der Zunahme von Abfragen zeigte sich allerdings ein weiterer Vorteil von MySQL: Seine bessere Stabilität. Solange Abfragen im Kernbereich von MySQL liegen (Suchen über Indexe), ist MySQL stabiler und annähernd ähnlich performant wie Manticore. Als es zeitweise zu Stabilitätsproblemen kam wurden die Suchfunktionen erweitert, um je nach Anwendungsfall mit beiden – MySQL und Manticore – als Backend arbeiten zu können.

Das war relativ leicht möglich, weil alle Suchabfragen von Manticore beantwortet werden konnten, während MySQL viele, aber nicht alle beantworten kann. Die grobe Logik ist also wie folgt: Wird eine Suchabfragen an den Server gestellt, wird jeder Parameter eingeordnet und in eine Abfragekomponente für Manticore und – soweit möglich – für MySQL übersetzt. Können alle Abfrageparameter mit MySQL beantwortet werden, wird die Frage direkt an die Datenbank gestellt. Andernfalls kommt Manticore zum Einsatz.

In der Praxis:

• Lautet die Abfrage: Objekte zum Schlagwort „Helm“ mit Bezug zum Ort „Berlin“, dann kann die Abfrage sowohl von MySQL als auch von Manticore beantwortet werden. MySQL wird bevorzugt.
• Lautet die Abfrage: Objektdatensätze, die irgendwo den Text „Helme“ erwähnen, mit Bezug zu „Berlin“, dann kann MySQL die Abfrage nicht bedienen. Also kommt Manticore zum Einsatz.

So blieben alle Abfrageparameter miteinander kombinierbar, während dem Kontext entsprechend das effektivere Backend gewählt wurde.

Entgegen der Logik oder Umgang mit Unvollkommenheit

Aufgrund ihrer Bedeutung für die Arbeit in vielen Museen haben wir nun Buchstabensuchen nach Inventarnummern wieder implementiert. Aber Buchstabensuchen nach Inventarnummern brechen die bestehende Logik und Kombinierbarbeit:

• Lautet die Abfrage: Objekte zum Schlagwort „Helm“, deren Inventarnummer auf „1“ endet, dann kann die Abfrage nur von MySQL beantwortet werden. MySQL wird genutzt.
• Lautet die Abfrage: Objektdatensätze, die irgendwo den Text „Helme“ erwähnen, und deren Inventarnummer auf „1“ endet, dann nur Manticore die Volltextsuche nach „Helme“ sauber und in der erwarteten Form (als Volltextsuche) beantworten, während nur MySQL die Buchstabensuche nach der Inventarnummer durchführen kann. Die Suche kann logisch nicht (sauber) durchgeführt werden.

So gut es ist, dass die wichtige Suchoption bei Inventarnummern zurück ist, musste also ein Umgang mit dieser jetzt unvollständigen Kombinierbarkeit gefunden werden. Vorstellbar wären zwei Optionen gewesen.

Die naheliegendere Form wäre es gewesen, alle Erweiterung einer Bestehenden Suche nach Inventarnummern um Volltextsuchen zu verbieten. In diesem Fall hätten die Benutzer möglichst schlicht nie zum problematischen Ausnahmefall gelangen können. Andererseits hätten die plötzlich fehlenden oder ausgegrauten Erweiterungsoptionen zu Verwirrung geführt. Schlimmer: Im eh schon sehr dichten Such-Interface von musdb fehlt ein geeigneter Platz, um zu dokumentieren, warum die Erweiterung in diesem spezifischen Fall auf einmal unmöglich ist. Die Verwirrung hätte also auch nicht sinnvoll aufgelöst werden können.

Entsprechend kommt nun die Alternative zum Einsatz: Kombinieren User die Suche nach Inventarnummern mit einer Volltextsuche, dann wird aus der Buchstabensuche nach der Inventarnummer eine Volltextsuche und es erscheint eine Warnung – auf jeder Seite der Paginierung – dass die gerade durchgeführte kombinierte Suche nicht die erwarteten Ergebnisse liefern wird und vermieden werden sollte. Das mag unsauber wirken, ist aber transparent, und ermöglicht den Suchenden die Möglichkeit, alternative Zugänge zu finden. Naheliegend wäre etwa, die Ergebnisse der Buchstabensuche nach Inventarnummer in eine Merkliste zu überführen und dann in dieser Merkliste weiterzusuchen.

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.

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.

Versionierung

Ein zentrales und lange schmerzlich vermisstes Feature in musdb war bis vor wenigen Tagen eine detaillierte Versionsgeschichte der Datensätze, um beispielsweise nach fälschlichen Stapelverarbeitungen oder Flüchigkeitsfehlern beim Löschen von Feldinhalten diese nachvollziehen und wiederherstellen zu können.

Eine solche Ansicht aller Arbeitsstände eines Objektdatensatzes seit Beginn der Aufzeichnung (Mai 2024) kann jetzt über den Reiter „Datensatz“ beim Ansehen und Bearbeiten eines Objektes in musdb abgerufen werden. Hier erscheint gleich oben ein neuer Button „Versionierung öffnen“.

Mit einem Klick darauf öffnet sich ein Overlay, in dem die verschiedenen Arbeitsstände tabellarisch aufgelistet werden. Die verschiedenen Aspekte des Objektdatensatzes sind dabei in verschiedene Reiter und damit verschiedene Tabellen gegliedert, z.B. für die Basisangaben, Verwaltungsangaben, Verknüpfungen zu Sammlungen, Schlagworten, etc.

„Feldweise transferieren“

Ein zweites oft gewünschtes Feature – besonders nach dem Importieren – ist das stapelweise Transferieren von Inhalten aus einem Datenfeld von Objekten in ein anderes. Sollen z.B. die bisher im nicht veröffentlichbaren Feld „Objektgeschichte“ geführten Informationen in Zukunft im Feld „Detaillierte Beschreibung“ geführt und darüber veröffentlicht werden, so kann der Übertrag aus dem einen in das andere Feld jetzt mit ein paar Mausklicks auch für hunderte Objekte durchgeführt werden.

Wie alle anderen Optionen des „Globalen Änderns“ bezieht sich das Feldweise transferieren von Feldinhalten dabei immer auf die Treffermenge einer Objektsuche. Die Funktion ist über die Seitenspalte der Objektübersicht verfügbar, sobald ein Suchkriterium eingestellt ist.

Die neue Funktion zum „Feldweisen transferieren“ ist auch über die API von musdb über den neuen Endpunkt /object/transfer_by_search/{mode} verfügbar.

• 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

Am 1. Januar 2021 waren in Deutschland 866 Museen und ähnliche Einrichtungen bei museum-digital registriert. 688 davon waren öffentlich gelistet, das heißt, sie hatten mindestens einen Objekteintrag erfasst und veröffentlicht. Die Erfassung von Objektmetadaten in musdb ist ohne die Verwendung von kontrollierten Vokabularen (die wiederum mit den großen Normdatenkatalogen wie der Gemeinsamen Normdatei, den Library of Congress Subject Headings oder Geonames verknüpft sind) kaum möglich. Das heißt, dass im Jahr 2021 mit großer Sicherheit 688 Museen in Deutschland Normdaten nutzten.

Etwas stimmt sichtbar nicht mit unseren Zahlen.

Neben Fragen auf einer hauptsächlich statistisch und politisch interessanten globalen/nationalen Ebene tauchen regelmäßig Fragen zu den teilnehmenden Institutionen in eher praxisrelevanten Situationen auf. Museen, die musdb als Sammlungsmanagementlösung in Betracht ziehen, fragen, wie viele andere Museen musdb für das Sammlungsmanagement nutzen. Da es sich sowohl um ein Sammlungsmanagementsystem als auch um das Tor zur Veröffentlichung von Museumsdaten über museum-digital handelt, können wir diese Frage auf Basis der verfügbaren Daten nicht sicher beantworten. Es bleiben nur die bekannteren Fallbeispiele.

In Deutschland genießt museum-digital den Ruf, besonders von kleineren Museen genutzt zu werden. Die Museumslandschaft kennend, kann man grob sagen, dass dies in Bezug auf das Sammlungsmanagement eher zutrifft, weniger in Bezug auf die Veröffentlichung von Sammlungsdaten. Für eine genauere Einschätzung fehlen jedoch quantitative Daten.
Angesichts des Ansatzes einer zentralen Vokabularverwaltung mit zentral festgelegten Bezeichnungen für Akteure, Orte, Zeiten und Tags liegt die Vermutung nahe, dass kunsthistorische Museen museum-digital seltener nutzen als andere Museumstypen. Das können wir zum jetzigen Zeitpunkt weder bestätigen noch dementieren.

Bessere Daten wären sehr wertvoll, um gleichgesinnte Museen zu vernetzen und ein besseres Verständnis dafür zu erlangen, wer museum-digital und/oder musdb tatsächlich nutzt.

Bei museum-digital kennen wir zwar Details über die teilnehmenden Museen, aber es fehlt der Überblick. Und Details können eine übergreifende Perspektive verdecken. Wenn ein Museum nur seine numismatische Sammlung über museum-digital veröffentlicht hat, aber tatsächlich alle Arten von Objekten sammelt, wäre es eindeutig falsch, anhand der veröffentlichten Objekte auf eine numismatische Sammlung zu schließen.

Übergreifende statistisch interessante Informationen über Institutionen lassen sich daher nicht sicher aus den veröffentlichten Sammlungen ableiten. Es handelt sich um Informationen, die die Mitarbeiter dieser Einrichtungen selbst am besten kennen.

Eine Kleine Umfrage

Vor diesem Hintergrund ist es an der Zeit, dass wir versuchen, etwas mehr über die Einrichtungen zu erfahren, die die musdb nutzen. Und das geht natürlich am besten, wenn man die Leute selbst fragt.

Ab heute werden die Benutzer, die sich bei der musdb anmelden, gebeten, eine kurze Umfrage mit sechs Fragen auszufüllen:

• Bitte wählen Sie die Art ihrer Institution. (Museum, Archiv, …)
• Ist Ihre Institution ein öffentlich oder privat getragen?
• Für was Benutzen Sie museum-digital? (Sammlungsmanagement, Publikation, beides)
• Wie viele Objekte befinden sich schätzungsweise in der Sammlung des Museums?
• Wie groß ist Ihre Ausstellungsfläche (Quadratmeter)?
• Bitte wählen Sie die Hauptsammlungsgebiete des Museums.

Der Dialog mit der Aufforderung, diese Umfrage auszufüllen, erscheint nur beim Einloggen, bis die Umfrage für das Museum ausgefüllt ist.

Wofür werden die Daten verwendet?

Die Daten werden zunächst nur für die Beantwortung der oben genannten Fragen genutzt. Die Kenntnis des Verwendungszwecks der musdb und der thematischen Schwerpunkte eines Museums eröffnet aber auch neue Möglichkeiten, die musdb insbesondere für neue Nutzer einfacher zu gestalten. Diese Information kann z.B. genutzt werden, um für neue Benutzer Voreinstellungen zu setzen, die auf den beabsichtigten Anwendungsfall der musdb zugeschnitten sind, anstatt nur einen einzigen, allgemeinen Satz von Voreinstellungen für eine bestimmte Funktionalität anzubieten.

museum-digital:qa nutzt diejenigen Funktionen des Import-Tools von museum-digital nach, die für das Auslesen der verschiedenen importierbaren Formate verantwortlich sind. So können Objektdaten aus einer Vielzahl von Formaten ausgelesen werden – sowohl offenen Standards wie LIDO als auch den softwarespezifischen Exportformaten einer Reihe von Sammlungsmanagementlösungen. Die so eingelesenen Objektdaten werden in der Folge auf ihre Qualität geprüft – mit den aus musdb bekannten Datenqualitätschecks zur Ermittlung der Vollständigkeit und Plausibilität der gelieferten Objektdaten. So werden diese Checks aus musdb auch für solche Museen zugänglich, die nicht selbst mit musdb oder museum-digital allgemein arbeiten. Über eine offene Schnittstelle können die Checks zudem in beliebige Software-Lösungen integriert werden.

Gleichzeitig bietet das Tool eine leicht zu erweiternde Plattform, mit der weitere Checks, die (bisher?) noch nicht in musdb selbst angeboten werden, integriert werden können. Im Rahmen der Herbsttagung konnte so ein Check zur Prüfung der Vollständigkeit gemäß den Maßgaben der AG Minimaldatensatz integriert werden.

Während Teile des Import-Tools nachgenutzt werden, geschieht kein tatsächlicher Import. Andererseits bedeutet die Nachnutzung, dass die Liste der unterstützten Formate suksessive wachsen wird, immer wenn Importe aus bisher noch nicht abgedeckten Formaten in museum-digital stattfinden. Ein zusätzlicher Vorteil ist der so absehbar sehr geringe Wartungsaufwand.

P.S.: Im Zuge der Arbeit an museum-digital:qa konnte auch ein lange geforderter Check in musdb integriert werden: Die Prüfung der Plausibilität von Lizenzangaben für Abbildungen auf Basis der Schaffenden bzw. der Herstellung des Objektes.

P.P.S. (23.10.2023): Mittlerweile sind die Folien des Vortrags, in dem museum-digital:qa auf der Herbsttagung vorgestellt wurde: https://files.museum-digital.org/de/Praesentationen/2023-10-10_museum-digital-quality-Datenqualitaet_Herbsttagung-FG-Doku_JRE.pdf

Gemeinsam mit diesen kommt auch eine neue Such-Schnittstelle für md:term (siehe Dokumentation).

Die Dokumentation kann hier abgerufen werden:

• md:term
• frontend (via the global portal)

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.

Über das Wochenende haben wir ein neues Feature auf der Projektseite, www.museum-digital.org, hinzugefügt: einen Kalender für Schulungen, Treffen, etc. Die hier aufgelisteten Termine werden wiederum aus verschiedenen vorhandenen Kalendern, die bereits online erreichbar sind, zu Listen der nächsten kommenden Termine zusammengesetzt.

Während die wichtigste Quelle dafür bisher der vom museum-digital e.V. gepflegte Schulungskalender ist, haben wir auch einen geteilten, aber bisher unveröffentlichten Kalender für englischsprachigen Termine wie die monatlichen Benutzertreffen eingebunden. Damit ist es nun möglich, die Benutzertreffen Monate im voraus zu planen und Zeit und Ort (bzw. URL) festzulegen, ohne jedes Mal einen neuen Blogpost zur Ankündigung schreiben zu müssen.

Und natürlich ist der Druck öffentlich angekündigte Termine einzuhalten deutlich größer. Damit steigt die Wahrscheinlichkeit, dass wir die monatlichen Benutzertreffen an jedem ersten Dienstag im Monat (17 bis 19 Uhr) in diesem Jahr auch langfristig an ihrem angestammten Termin durchhalten können. Also, einfach auf www.museum-digital.org vorbeischauen und nach dem nächsten „Monthly user meet-up“ suchen. Dort ist der Link zum Treffen schon festgelegt.