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)

Etwas geschmälert wird der Nutzen leider dann doch oft durch die schlechte tatsächliche Zugänglichkeit der Inhalte. Selbst wenn die Quellen frei erreichbar sind, bedeutet die oft schlechte Texterkennung, dass sie nicht systematisch durchsuchbar sind. Im kleinen ist das verkraftbar: Suche ich in von – je band – immerhin meist drei parallel verfügbaren Ausgaben von Naglers Künstlerlexikon nach einem Eintrag, ist die Chance hoch, dass ich ihn nur beim manuellen Durchblättern finde. Durch den alphabetischen Aufbau ist das leicht getan.

Wenn ich aber die Quelle noch nicht kenne, bzw. nicht weiß, ob ich bei Nagler, oder z.B. in einem Lexikon speziell nur für Kupferstecher suchen soll, dann summiert sich die Arbeit. Abhilfe schüfe eine bessere OCR und eine Aufbereitung in einer für Suchmaschinen gut lesbaren Form. Und was können Suchmaschinen besser lesen als Webseiten?

Also: resources.museum-digital.org!

Motivation: Vokabulararbeit

Ein zentraler Bestandteil der Arbeit im Hintergrund von museum-digital ist die Vokabulararbeit. Die eindeutige Bestimmung, in-Beziehung-Setzung und Anreicherung von Begriffen zu Akteuren, Orten, Schlagworten / Konzepten und Zeiten. Entsprechend oft wünscht man sich – besonders für weniger bekannte Entitäten – Nachschlagewerke. Und umso hilfreicher sind einfach und bedenkenlos zugängliche und nachnutzbare, gemeinfreie Nachschlagewerke. Diese haben in ihrer Masse zudem oft den Vorteil, das aus heutiger Sicht weniger Relevante Einträge aufgeführt werden, die zur Zeit der Veröffentlichung noch als der Nennung wert eingeschätzt wurden.

Dazu kommt, dass gerade in der Vokabulararbeit oft nur wenig Kontext vorhanden ist. Die beste Kenntnis oder zumindest den besten Zugang zu den Objekten haben schließlich die Museen und nicht entfernt und meist ehrenamtlich arbeitende Vokabular-Redakteure. Umso nützlicher wäre es, Inhalte aus historischen Nachschlagewerken in der Breite durchsuchen zu können, ohne schon vorher wissen zu müssen, welches Nachschlagewerk man nun heranziehen muss.

Es ist also in unserem unbedingten Interesse, mehr der eigentlich schon verfügbaren Quellen in der Breite schnell durchsuchen zu können. Am besten einfach mit Google (oder der Suchmaschine der Wahl). Dabei ist die Menge der besser verfügbaren Nachschlagewerke im Zweifelsfall wichtiger als 100%-ige Korrektheit – diese lässt sich, sobald man einen passenden Eintrag gefunden hat immer noch durch das zurateziehen der Scans herstellen.

resources.museum-digital.org

Als kleines Nebenprojekt im museum-digital-Kosmos soll resources.museum-digital.org nun also dazu dienen, historische Nachschlagewerke durch eine neu durchgeführte Texterkennung mit der heute verfügbaren Technik und eine Präsentation nach Web-Logik verfügbarer zu machen. Den Aufschlag machen dabei die 22 Bände vom schon erwähnten Neuen Allgemeinen Künstlerlexikon von Georg Kaspar Nagler. Die Grundlage bildeten dabei die im Internet Archive durch verschiedene Bibliotheken verfügbar gemachten und auf der Seite verlinkten Scans der Bände.

Wichtig dabei war von Anfang an, dass eine rein automatische Bearbeitung gut genuge Ergebnisse für eine Präsentation bieten sollte, und das die Präsentation der fast zwangsläufig imperfekten, automatisch generierten Daten einerseits an sich schon gewinnbringend und andererseits manuell verbesserbar sein sollte. Dazu war und bleibt es wichtig, die rein maschinell erstellten Transkriptionen als eben solche zu Kennzeichnen.

Ansatz: Hin zur neuerlich durchgeführten Texterkennung

Um halbwegs leserliche und verwertbare Textvorlagen für die Erstellung der Seite zu bekommen, versuchten wir zuerst, mit der bestehenden OCR zu arbeiten. Diese war im Falle Naglers oft gut genug, um die grobe Struktur des Werkes abzubilden, beinhaltete aber soviele Fehler, dass schon eine regelbasierte Aufspaltung der Einträge (eigentlich im konkreten Fall recht leicht, da fast jeder Eintrag mit „<Nachname>, <Vorname>,“ anfängt) deutlich unzuverlässig wurde. Der Versuch eine LLM-basierten Korrektur der OCR half etwas, aber nicht in einem zufriedenstellenden Maße.

Vorgehen: Neue OCR

Stattdessen sollte es also eine gänzlich neue OCR sein. Glücklicherweise bieten die Uploads im Internet Archive neben den PDFs wenig komprimierte .jp2-Versionen der einzelnen Seiten eines Buches zum Download an, die eine fast ideale Basis für das weitere Vorgehen boten. Für eine bessere Interoperabilät mit verschiedenen Programmen wandelten wir diese ohne weitere Kompression in .png-Dateien.

Grob sollten die einzelnen Scans nun mit Tesseract transkribiert und in der Folge mit dem multimodalen LLM Qwen3-VL, später Qwen3.5, gegengeprüft werden.

Es ist – zumindest in interessierten Kreisen – fast schon eine Binsenweisheit, dass Tesseract mit entsprechend vorbereiteten Bilddateien deutlich besser umgehen kann als mit anderen. Idealerweise sollten Scans mindestens 600 DPI haben (bzw. eine entsprechende Pixelzahl bieten – im Schlimmstfall kann selbst ein naives Hochskalieren der Bilder zu besseren Ergebnissen führen) und Schwarzweiß oder in Graustufen gehalten sein. Entsprechend werden die Scans in einer Arbeitskopie den Vorgaben angepasst und dann mit Tesseract OCR-ed.

Im nächsten Arbeitsschritt werden einzelnen Scan-Seiten gemeinsam mit den Ergebnissen von Tesseract als Vorlage an das KI-Modell übergeben.

Wichtige Erkenntnisse dabei gibt es zweierlei: Besonders bei unsauber gescannten Seiten bietet Qwen3.5 oft bessere Ergebnisse als ein nicht nachtrainiertes Tesseract. Es passiert allerdings relativ häufig, dass ganze Seitenbereiche (z.B. Absätze) einfach „übersehen“ werden. Das lässt sich durch die Mitgabe auch einer mit Schreib- oder Lesefehlern gespickten Vorlage umgehen. Zweitens erziehlt Qwen3.5 bessere Ergebnisse mit den nicht nachbearbeiteten Bilddateien (mehrfarbig, nicht verstärkter Kontrast / wenig Tonwertkorrektur, etc.) als mit den für Tesseract optimierten.

In diesem Arbeitsschritt kam es hin- und wieder zu deutlichen Zeitüberschreibungen. Wo ein üblicher Scan vielleicht 5 Sekunden brauchte, brauchten einzelne mehrere Stunden. Hintergrund waren besonders unsaubere Scans (bzw. Nachbearbeitungen beim ursprünglichen Ansatz, Qwen3.5 mit den nachbearbeiteten Scans arbeiten zu lassen): Hier ergab die OCR mit Tesseract schon nur ein Durcheinander, und auch mit Qwen3.5 konnten keine Ergebnisse erzielt werden. Abhilfe schaffte das Einführen eines Timeouts. Nach zwei Minuten wird die Abfrage abgebrochen und Qwen3.5 um eine selbstständige OCR der Seite angefragt. Ergibt auch das keine Ergebnisse, wird die Seite übergangen.

Die so erstellte, maschinell nachgeprüfte OCR der Einzelseiten wird nun mit einem Script in eine JSON-Datei zusammengefasst und in die einzelnen Einträge aufgespalten. Die Erkennung von einzelnen Einträgen ist dabei kontextabhängig. Im Falle von Nagler war der Beginn der Einträge durch die Nennung der Namen verhältnismäßig einfach durchführbar.

Mehr Sinn erkennen

Eine gute Webseite präsentiert nicht nur Daten, sondern verlinkt diese intern wie extern. Je mehr Sinn also (automatisch) aus den einzelnen Einträgen gezogen werden kann, desto besser lassen sich die Einträge präsentieren – und später suchen.

Statt also die einzelnen Einträge einfach so im Web wiederzugeben, werden sie erst einmal einer Named Entity Recognition mit GLiNER2 unterzogen, um im Eintrag genannte Personen, Orte, Zeiten, Berufe und Kunstrichtungen zu erkennen.

Um falsch erkannte oder nach Ansicht von museum-digital kategorisch falsch zugeordnete Entitätsnamen (z.B. die Person „Prinzessin“) zu filtern, werden die so erkannten Begriffe mit der Reconciliation API von md:term abgeglichen. In der Folge werden nur solche Begriffe als verknüpfte Entitäten weiterverwertet, die bei museum-digital schon bekannt sind.

Zuletzt werden zumindest in Naglers Fall auch die Titel der Einträge reconciled. In diesem Fall gegen Wikidata, da dieses einerseits mehr der Namen kennen dürfte, und die verfügbaren Reconciliation APIs andererseits weniger kritisch mit der Verfügbarkeit oder Abwesenheit von Lebensdaten umgehen. Sollte Wikidata einen Treffer abwerfen, wird über die entsprechende BEACON-Datei nach demselben Eintrag in museum-digital gesucht.

Verfügbar machen

Die so gewonnenen Daten werden in den letzten Arbeitsschritten in einfach menschlich bearbeitbare Markdown-Dateien überführt, aus denen schlussendlich mithilfe des Seiten-Generators Zola eine Webseite generiert wird. Die verschiedenen Zwischenschritte, die Scripte zur Named Entity Recognition und Reconciliation, sowie die Markdowndateien finden sich zur freien Nachnutzung und für Korrekturen auf Codeberg.

Eine Suche hat resources.museum-digital.org selbst nicht. Gerade in Anbetracht der Schwierigkeiten, die wir in den letzten Monaten mit Serverauslastung und Resourcenverbrauch hatten, soll die Seite im laufenden Betrieb keine erhöhten zusätzlichen Kosten oder Aufwände benötigen – und ohne Suchfunktion können wir sie trotz ihrer Größe sehr einfach und quasi ohne Wartungsaufwand als statische Seite hosten. Andererseits ist das Ziel ja gerade eine Verbesserung der Auffindbarkeit durch Suchmaschinen, wofür es eine Suche als Bestandteil der Webseite selbst fast nicht mehr bräuchte.

Fazit

Auch wenn das Ausprobieren verschiedener Ansätze einige Zeit gebraucht hat, haben wir jetzt einen Workflow, um historische Nachschlagewerke fast ohne menschlichen Aufwand deutlich besser durchsuchbar verfügbar machen können. Alle eingesetzten KI-Tools laufen lokal, verursachen also außer dem Strom keine weiteren Kosten. Die Ergebnisse können sich – gemessen an Aufwand und Erwartung – sehen lassen. Zum Start macht die Seite 33000 Einträge aus Naglers Künstlerlexikon besser verfügbar.

Das Nachschlagen – und das Lob für das Scannen! – der tatsächlichen Quellen bleibt dabei unerlässlich. Ensprechend verlinkt jede Unterseite von resources.museum-digital.org die je relevante Quelle (d.h. auch den konkreten Scan) prominent.

Danksagung

Danke an Felix Schenke, dessen Berichte über seine eigenen Arbeiten an der OCR von Handschriften viele Ansätze aufzeigten, die im Rahmen der Arbeit an resources.museum-digital.org hilfreich waren.

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

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

Image credits: „Devanagari_letters.svg“ is licensed under Creative Commons Attribution-Share Alike 4.0 International, by बडा काजी, and retrieved via Wikipedia Commons.

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

Wie immer: Vielen Dank, an alle, die das ermöglicht haben!

Image credits: „Telugu consonants.svg“ von Psiĥedelisto, lizensiert unter CC BY-SA 4.0, via Wikimedia Commons

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