Abstract

Spätestens mit dem Aufkommen und der Popularisierung von KI-Chatbots wie ChatGPT hat die Diskussion um die Möglichkeiten des Einsatzes von Künstlicher Intelligenz auch die Museumsdokumentation erreicht.

In diesem Vortrag wird auf Basis eines generalisierten Lifecycles von Erschließungsdaten zu Museumsobjekten erst ein kurzer Überblick über bisherige Einsatzszenarien von KI mit dem Versuch einer Klassifikation präsentiert. Im Folgenden werden zwei im Rahmen der Initiative
museum-digital entwickelte Einsatzszenarien im Detail beleuchtet.

museum-digital (https://www.museum-digital.org/) wurde 2009 in Bitterfeld von Museen gegründet, um gemeinsam die Bestände der Museen im Netz zu präsentieren. Ausgehend von der Publikation erweiterten sich die Aktivitäten und Softwarelösungen bald in andere, verwandte digitale Arbeitsfelder von Museen, besonders das Sammlungsmanagement und die Erstellung digitaler Ausstellungen. Heute arbeiten ca. 1700 Museen primär aus Deutschland, Ungarn und der Ukraine mit museum-digital, von denen bisher 1231 Objekte über die Plattformen veröffentlicht haben.

Die beiden Werkzeuge im Fokus des Vortrages sind Versuche, die  Erschließungsarbeit der Museen weiter zu vereinfachen. Einerseits werden hierzu etwa bei Gemälden, Graphiken und Fotographien abgebildete Elemente automatisch erkannt und zur Verschlagwortung auf Basis des entsprechenden kontrollierten Vokabulars von museum-digital vorgeschlagen. Zentrale Fragen waren bei der Implementation einerseits die Anbindung bisher nicht auf die Arbeit mit Normdaten und kontrollierten Vokabularen ausgericheter Modelle an ein kontrolliertes Vokabular und die Frage, wie eine Klassifikation im Rahmen einer finanziell und in Bezug auf die zur Verfügung stehenden (Server-)Hardware stark eingeschränkten Community-Initiative umgesetzt werden können.

Das zweite hervorgehobene Werkzeug synthetisiert auf Basis bestehender, strukturierter Objektmetadaten Prosa-Objektbeschreibungen, die sowohl im Sinne der Barrierefreiheit als auch für die Auffindbarkeit der Objekte (besonders durch Suchmaschinen) bei museum-digital für die Publikation von Objekten verpflichtend vorausgesetzt werden. Hierzu werden die strukturierten Objektdaten auf Anfrage der Nutzenden in eine Prompt-Vorlage eingefügt. Auf Basis der Objektart werden ausgewählte, vorher als gut bewertete Beispielobjektbeschreibungen möglichst ähnlicher Objekte mitgegeben (Few-Shotting). Um Nutzende zu einer tatsächlichen kritischen Auseinandersetzung der generierten Texte zu bewegen, werden je drei, von verschiedenen Large Language Models generierte, Vorschläge generiert und angezeigt. Ist einer ausgewählt, werden Nutzende aufgefordert, den Text zu redigieren. Das Tool entstand experimentell im Rahmen einer Kooperation des Freien Hochstifts, des Zuse-Instituts Berlin, digiS‘ und von museum-digital. In diesem Kontext wurde für das Werkzeug ein engmaschiges Logging der generierten Daten und der Nutzerinteraktion implementiert, das tiefere Auswertungen zulässt – etwa, inwiefern die Texte tatsächlich redigiert wurden, und ob bestimmte Modelle, Textlängen, etc. von den Nutzenden präferiert wurden.

Der Vortrag schließt mit einem Ausblick auf die weiteren Potentiale und die durch die durch dank KI veränderte Umgebung aufgekommenen neuen Herausforderungen in der (digitalen) Erschließung und Publikation von Museumsbeständen.

Folien

• Als ODP-Datei

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.

Vorschläge machte musdb andererseits bisher vor allem auf Basis der zuletzt getätigten Eingaben: Soll etwa ein Objekt etwa verschlagwortet werden, werden in einer Seitenspalte die zuletzt benutzten Schlagworte angezeigt. Die Annahme, dass üblicherweise ähnliche Objekte nacheinander eingegeben werden, ist zwar naheliegend und meist richtig, aber es gibt viele weitere gute Optionen, um automatisch Vorschläge anzubieten.

Mit dem Entwicklungen der letzten beiden Monate sind wir in der Entwicklung einen großen paradigmatischen Schritt gegangen: Das System erkennt – bei einer gegebenen Liste von Fällen – behebbare Unvollständigkeiten, und schlägt zusammen mit der Nachricht direkt eine Lösung vor.

Verbesserungsvorschläge

Die Verbesserungsvorschläge für Objekte sind auf zweierlei Wegen erreichbar: Gibt es einen Vorschlag zu einem Objekt, das man gerade bearbeitet, erscheint der Hinweis darauf aber natürlich auch direkt beim Objekt (direkt neben der Überschrift). Spannender ist aber die allgemeine Liste für die schnelle Abarbeitung der Vorschläge, die jetzt über die Navigation in musdb erreicht werden kann.

Die so erreichte Liste ist optimiert, um ein Abarbeiten der Vorschläge so niedrigschwellig wie möglich zu ermöglichen: Jeder Vorschlag bildet eine Zeile und kann akzeptiert (und ausgeführt) oder verworfen werden. Um zu akzeptieren oder zu verwerfen, kann man entweder wie gehabt die entsprechenden Buttons klicken oder man wischt den Eintrag – grob analog zu z.B. Tinder – nach links (verwerfen) oder rechts (akzeptieren). Ist kein Touchscreen in Reichweite kann der oberste Eintrag der Liste über die Tasten „-“ und „+“ verworfen bzw. akzeptiert werden.

Und was schlägt musdb da vor?

Verbesserungsvorschläge die so angeboten werden sollen müssen natürlich mindestens fast sicher sein, daher deckt die Funktion bisher nur eine kleine Anzahl an Fällen ab:

• Objektart als Schlagwort
  Das Feld für Objektarten ist bei museum-digital nicht kontrolliert, einerseits weil die Kategorisierung über Schlagworte breitere Suchmöglichkeiten bietet, andererseits weil viele Objekte bei museum-digital über Importe erfasst werden und etwaigen Vorgaben sicher widersprechen würden. Beim Neu-Eingeben ist die Benutzung von erkennbaren Objektarten aus der Schlagwortliste aber unbedingt sinnvoll – und genauso das Verschlagworten des Objektes mit seiner Objektart. Ist ein Objekt z.B. ein Stein, schlägt musdb vor, auch das Schlagwort „Stein“ mit dem Objekt zu verknüpfen.
• Dargestellte Person in Selbstportraits
  Ein immer wieder auftretendes Problem, ist das die auf einem Gemälde oder einer Fotografie abgebildete Person nicht gesondert als „Dargestellte Person“ erfasst wird. Dabei sind gerade diese Daten besonders interessant für interessante Weiterentwicklungen (von Visualisierungen bis zur automatierten Bilderkennung)!
  Ein Sonderfall, in dem die Person implizit bekannt ist, sind Selbstportraits. Ist das Objekt ein Selbstporträt, und ist ein Maler oder Fotograf bekannt, schlägt musdb vor, dieselbe Person auch als dargestellte Person zu verknüpfen.
• Fehlende Sprach-Angaben bei Schriftwerken
  Ein recht neues Eingabefeld bei museum-digital, aber ein umso gebräuchlicheres im Umgang mit Texten ist die Sprache: „Ist der vorliegende Text in Deutsch oder Russisch verfasst?“ Die Erfassung der Sprache macht bei allen Text-Objekten unbedingt Sinn, ist aber natürlich bei anderen Objekttypen kontraproduktiv. Eine Steinaxt hat – natürlich – keine Sprache.
  Deshalb prüft musdb erst, ob ein Objekt verfasst wurde (also ein Ereignis „verfasst“ verknüpft ist). Ist das der Fall, wird es sich wohl um ein Objekt mit Text handeln – und musdb kann die Sprache, in der der oder die Eingebende das Programm benutzt, als Sprache des Textes vorschlagen. Achtung: Dieser Vorschlagstyp ist der uneindeutigste der bisher vorhandenen.
• Präzisierung von Ereignisangaben
  Viele vorhandene Ereignisangaben lassen sich naheliegend auf Basis der Objektart spezifizieren: Wurde ein Gemälde „hergestellt“, oder wurde es nicht eher „gemalt“? Wurde ein Foto „hergestellt“? Wahrscheinlich wurde es eher „aufgenommen“.
  Ist ein solcher Fall identifizierbar, schlägt musdb vor, die Angabe zu spezifizieren.
  

Vorgeschlagene Ereignistypen nach Objektart

Mit verschiedenen Arten von Objekten passieren verschiedene Ereignisse. Gemälde werden gemalt, haben aber bestimmt nicht gelebt. Amoniten haben gelebt und wurden (wenn sie heute im Museum sind) zu irgendeinem Zeitpunkt gefunden, wurden aber bestimmt nicht verfasst.

Auch wenn das Feld „Objektart“ bei museum-digital nicht kontrolliert wird, können wir doch mit vielen der gebenen Objektarten umgehen, indem wir die Hierarchie des Schlagwortkatalogs zu Hilfe nehmen. Ist als Objektart „Carte-de-Visite“ angegeben, kann derselbe Begriff (auf Basis des gleichen Namens) im Schlagwortkatalog von museum-digital gefunden werden. Das Schlagwort „Carte-de-Visite“ ist dem Begriff „Fotografie (Lichtbild)“ untergeordnet – und so lässt sich aus den Daten schließen, dass es sich beim Objekt um eine Fotografie handelt.

Weil Fotografien nun eben vor allem „Aufgenommen“ werden, für sie „Vorlagen erstellt“ werden, und sie oft Orte oder Personen abbilden, lässt sich dieses Wissen nutzen, um die naheliegenden Ereignistypen ganz oben in der Liste der Ereignistypen (beim Anlgen eines neuen Ereignisses) vorzuschlagen. So sind sie leichter erreichbar und können hoffentlich zu einer schnelleren – aber genauso richtigen – Erfassung beitragen.

Bilderkennung

Nachdem die logischen Schlüsse, die sich aus dem Zusammenspiel von kontrollierten Vokabularen und Objektdaten schließen lassen nun wesentlich weitergehend auch in (Verbesserungs-)Vorschlägen niederschlagen, stellt sich die Frage, was der nächste Schritt für bessere Vorschläge an mehr Stellen ist. Naheliegend, weil zunehmend gut erforscht und zunehmend auch im alltäglichen Einsatz ist dabei Bilderkennung (bzw. Bild-Klassifikation). Und auch im Museumssektor ist sie hin und wieder pressewirksam für die Verschlagwortung von Bildern und Objekten eingesetzt worden. Warum dann also nicht bei museum-digital?

Um automatische Bilderkennung sinnvoll einsetzen zu können, müssen allerdings zuerst einmal Bilder vorhanden sein, die dann im Folgenden klassifiziert werden können. Deshalb ermöglicht die Objekt-Eingabeseite jetzt direkt das Hochladen von Bildern zum Objekt.

Wird an dieser Stelle ein Objektbild angefügt, wird gleich ein Versuch Schlagworte vorzuschlagen, unternommen. Bisher sind die Resultate meist noch nicht gut. Aber so steht zumindest einmal die richtige Architektur, um Bilder, künstliche Intelligenz und ihr Zusammenwirken bei Erleichterung der Inventarisierung wesentlich mehr (oder überhaupt erst einmal) einzusetzen.

Bisher werden zur Bild-Klassifikation generische Modelle für browserbasierte Bilderkennung verwendet (mobilenet und coco-ssd). Alleine ein spezifisches Weiter-Training der Modelle auf Basis der bei museum-digital vorhandenen Daten sollte schon wesentliche Fortschritte mit sich bringen.

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