Umfang und Gründe der Überarbeitung

musdb als Tool existiert fast seit dem allgemeinen Start von museum-digital 2009 oder 2010. Damals war es als Eingabetool für die Erfassung von publizierbaren Objektdaten gedacht. Seitdem haben sich die Ziele und der Einsatzbereich von musdb deutlich erweitert: Aus einem reinen Erfassungstool für die Publikation wurde ein vollumfänglichen Sammlungs- und Museumsmanagementsystem. Die grundlegende Architektur der Benutzeroberfläche blieb bei all dem fast konstant.

Viele neue Features wurden in diesem Rahmen hinzugefügt, aber meist so, dass sie abseitig genug positioniert waren, um bestehendende User nicht zu verwirren und etablierte Workflows nicht zu brechen. Das hieß auch, dass musdb zwar an sich gut, aber die Benutzeroberfläche über Jahre ohne klaren, langfristigen Plan ein systematisches ausarbeiten stabiler, universeller Bausteine wuchs.

Auch im weiteren Kontext hat sich seit 2009 viel getan. Web-Entwicklung hat sich gewandelt. Wir müssen uns nicht mehr um den Internet Explorer sorgen, die Browser-Kompatibilität ist viel besser und Web-Anwendungen können heute viel interaktiver sein. Um den vollen Nutzen dieser Fortschritte in der Entwicklung von musdb genießen zu können, ist eine grundlegende Änderung seiner Architektur notwendig.

Da die Architektur sich wandelt – weg von einer traditionellen Website mit vielen selbstständigen Unterseiten hin zu einer Single Page Application – ist der Rewrite tatsächlich genau das: Statt dass Seiten auf dem Server generiert und nur im Browser angezeigt werden, wird musdb’s Benutzeroberfläche vollständig im Browser generiert, und nur die jeweils relevanten Daten werden über die entsprechenden gut dokumentierten APIs abgerufen. Alleine eine im alten Design gegebene Funktionalität zu bewahren heißt damit schon, dass sie (oder zumindest ihre Präsentation) neu implementiert werden muss. Damit ist das Update auch die perfekte Gelegenheit, das Benutzerinterface zu streamlinen und zuvor ungenutzte oder übersehene Funktionalitäten genauer zu überdenken.

Auch wenn mit der kommenden Version auf technischer Ebene – zumindest bezüglich der Benutzeroberfläche – alles neu wird, heißt das nicht zwangsläufig, dass sich auf konzeptioneller Ebene allzu viel ändern muss. Die kommende Version von musdb wird das gleiche Grundgerüst von Seiten aufweisen – Listen, Bearbeitungsseiten und Seiten zum Hinzufügen neuer Einträge –, es bietet das gleiche Konzept von reiterbasierten Bearbeitungsseiten und behält – mit wenigen Ausnahmen – die gleichen Datenfelder und deren Reihenfolge bei.

Eine kleine Vorschau

Wo vieles gleich bleibt, kann es nicht schaden, einen kleinen Blick in die Dinge zu werfen, die sich ändern werden. Im Folgenden gibt es einige solcher Vorschauen mit kleinen Screencasts. Die meisten davon konzentrieren sich auf Übersicht- und Listen-Seiten, die bereits für die Veröffentlichung bereit sind.

Navigation

Neue Filteroptionen

Drei Anzeigemodi für Übersichten

Die Infrastruktur für Stapelverarbeitung bei allen Übersichtsseiten

Interaktive Übersichten

Und wann kommt den nun das Update?

Derzeit schreitet die Entwicklung reibungslos voran, und die nötigen Bausteine für fast alle Funktionalitäten stehen. Je nachdem, welche Features man nutzt, kann das neue UI das Alte bereits für die meisten gängigen Use Cases ersetzen. Damit alle weitverbreiteten Anwendungsfälle vollumfänglich abgedeckt sind muss jedoch zumindest die Objekt-Bearbeitungsseite vollständig fertig sein. Das sollte dann spätestens ab Ende
September der Fall sein. Im Folgenden stehen Vorträge und eine Phase an, in der beide Versionen nebeneinander genutzt werden können, um einen reibungslosen Übergang der alten zur neuen Benutzeroberfläche zu gewährleisten.

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

(Post image generated using Anima Base v1)

• 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.