Einleitung

Diskussionen über die Digitalisierung in Museen werden in Deutschland seit Jahrzehnten geführt. Der Aufbau von Datenbanken zur Bestandserschließung geht in vielen Häusern mindestens bis in die 1990er Jahre zurück. Die Nutzung digitaler Mittel für die Öffentlichkeits- und Vermittlungsarbeit in Museen ist seit spätestens Mitte der 2000er Jahre nicht mehr zu vermeiden. Und mit der Verbreitung des World Wide Web wurde klar, dass Interoperabilität und Verknüpfbarkeit in Zukunft relevante Themen sein würden.

Die personelle Infrastruktur der Museen und in breiteren, museumsübergreifenden Infrastrukturen und Institutionen (Museumsverbände, den Landesstellen für Museen, etc.) wurde dementsprechend in den letzten Jahren zunehmend angepasst. Gerade größere Einrichtungen haben heute Social Media Manager, verschiedene Rollen für die digitale Sammlungsarbeit, etc. In Einklang damit gab es seit ca. 2015 den Druck, digitale Strategien in den Museen zu entwickeln. Diese Entwicklungen sind an sich sinnvoll und richtig.

Sie bleibt nichtsdestotrotz unvollständig. Einerseits ist die Museumslandschaft extrem divers, und besonders viele kleinere Einrichtungen haben bis heute keine dezidierte Digitalstrategie. Andererseits greift das Digitale auf alle Lebensbereiche über: Kann es eine Digitalstrategie geben, die nicht eine allgemeine Museumsstrategie darstellt? Und, sollte das im Konkreten für korrekt befunden werden: Wie sorgt man dafür, dass die Strategie auch tatsächlich auf der operativen Ebene verfolgt und umgesetzt wird?

Welchen Nutzen haben die vielen einzelnen Strategien, wenn es keine stringente, übergreifende Strategie gibt? Auf welchem Grund sollen die digitalen Bemühungen gedeihen, wenn es kein passendes Ökotop gibt? Real gibt es auch heute schon eine Fülle von Angeboten für die digitale Arbeit von und in Museen – Hardware, Infrastrukturen, Austauschforen, Hilfsangebote. Diese strategisch zu sortieren, ein gemeinsames Ziel zu formulieren und Reibungsverluste zu reduzieren, das sollte gerade heute, in Zeiten knapper Kassen, im allgemeinen Interesse sein.

Im Folgenden wird versucht, einen Entwurf für eine derartige Zielvorstellung anhand eines „digitalen Idealmuseums“ zu skizzieren, wichtige Hürden und Vorschläge für den Umgang und die Überwindung dieser zu benennen. Die hier formulierten Überlegungen stützen sich auf die langjährige praktische Erfahrungen von museum-digital als offener, kooperativ entwickelter Infrastruktur für die Erschließung, Verwaltung und Publikation von Museumsdaten.

Das Digitale Idealmuseum

Der zentrale Wissensspeicher des digitalen Idealmuseums ist seine Museumsdatenbank. In dieser werden die Objekte sowie alle standardisierbaren und planbaren Vorgänge im Museum abgebildet und verzeichnet. Hier wird für jedes Objekt und jeden Vorgang eine eindeutige Kennung generiert, mit der diese in allen Tätigkeitsbereichen des Museums klar und eindeutig referenziert werden können.

Zu den vom Museumsteam sauber erfassten Objekt- und Sammlungsdaten gesellen sich automatisch erfasste und in die Datenbank übermittelte Daten von Klimasensoren und aus dem mit QR-Codes kostengünstig umgesetzten Standort-Tracking. Besucherzahlen werden von den in den Ausstellungsräumen eingebauten Lichtschranken automatisch in die Datenbank übermittelt.

Ein Display im Foyer des Museums präsentiert ein Dashboard, in dem Besuchern die Aktivitäten des Museums transparent dargestellt werden. Besucher erhalten einen Überblick über den Fortschritt der Erschließungsarbeit, kommende Veranstaltungen und Ausstellungen werden angekündigt, es gibt eine Liste der neuesten Veröffentlichungen der Mitarbeiter des Museums. Eine Anzeige informiert über die Verfügbarkeit von Plätzen im Museumscafé und von Toiletten.

Die so präsentierten Daten werden direkt aus der Museumsdatenbank bezogen. Ebenso können vollautomatisch Listen und Berichte für Fördermittelgeber, Beirat und Trägerinstitutionen erstellt werden. Mitarbeitende des Museums sehen für sie relevante Aufgaben und Termine aus der Museumsdatenbank automatisch im Kalender auf ihren Endgeräten.

Leihverkehre und Ausstellungen sind in der Datenbank erfasst. Vordrucke für z.B. Leihverträge und eine Übersicht über alle im Rahmen des jeweiligen Vorgangs erstellten Dokumente – gekennzeichnet mit der durch die Datenbank generierten ID – können in dieser generiert und eingesehen werden. Über offene Standards wie EODEM können die Objektdaten verliehener Objekte automatisch, schnell und verlustfrei an Leihnehmer übermittelt und in deren Datenbanken übertragen werden.

Die Zusammenarbeit mit externen Kuratierenden, Ausstellungsplanern und Gestaltern wird durch eine feingliedrige Rechteverwaltung und eingeschränkten Zugriff auf die Datenbank vereinfacht. Mit einem Nutzerkonto mit rein lesendem Zugriff erhalten sie Einsicht in die Sammlung und können allgemeine wie ausstellungsspezifische Texte und Objektbeschriftungen direkt aus der Datenbank beziehen – oder diese direkt in der Datenbank kollaborativ mit den Mitarbeitenden des Hauses erstellen.

Für die Öffentlichkeitsarbeit des Hauses ist die Museumsdatenbank, nebst einem ggfs. vorhandenen und eng mit ihr verzahntem Digital Asset Management-System, ebenfalls eine zentrale Quelle. Beispielobjekte und Bilder für Social Media-Posts und Newsletter sowie Übersichten über die Arbeit des Hauses finden sich zuallererst in der Datenbank. Gleichzeitig übernimmt eine standardkonforme Speicherung und Publikation einige Aufgaben vollständig: Die Listung von Veranstaltungen und Ausstellungen bei Google geschieht etwa vollautomatisch mithilfe eingebetteter JSON-LD-Metadaten bei der Publikation auf der eigenen Webseite.

Die Publikation der Sammlungsdaten erfolgt vollständig automatisiert. Mit einem einfachen Freigabefeld entscheiden Mitarbeitende, ob ein Datensatz beim einmal täglich automatisch angestoßenen Abgleich der Daten veröffentlicht werden soll oder nicht. Ziel des Abgleichs ist eine einzige primäre Publikationsplattform, etwa die Webseite des Museums. Durch saubere Datenerfassung, die Verwendung von Normdaten und eine eng abgestimmte Synchronisations-Routine kann der Abgleich der Daten ohne weitere menschliche Intervention geschehen.

Die primäre Publikationsplattform dient nicht nur der direkten Ansprache der Öffentlichkeit, sondern auch als Ausgangspunkt für die Weitergabe an fachspezifische Portale wie das Graphikportal oder spartenübergreifende wie die Deutsche Digitale Bibliothek und Europeana. Offene Schnittstellen wie OAI-PMH und die Verwendung offener, weit verbreiteter Austauschstandards wie LIDO ermöglichen eine regelmäßige, vollautomatische Übernahme und Aktualisierung der Daten durch die Portale, ohne zusätzlichen Aufwand für das Personal des Museums.

Eine Publikation unter offenen Lizenzen und das Angebot offener Schnittstellen erlauben eine reibungslose und vielfältige Nachnutzung durch Forschung, Bildung, Kulturvermittlung und die Kreativindustrie. So können neue und vom Museum selbst möglicherweise unvorhergesehene Potentiale geschöpft werden, die dem Museum Reichweite und neue Erkenntnisse bieten können.

Das digitale Idealmuseum existiert in der beschriebenen Form wahrscheinlich noch nirgends. Und das, obwohl die meisten beschriebenen Konzepte und Methoden Jahre und Jahrzehnte alt und in anderen Bereichen wohl etabliert sind. Eine derartige, stringend um einen zentralen Wissensspeicher aufgebaute Struktur wäre beliebig erweiterbar und schon eine partielle Nachbildung der oben beschriebenen Struktur könnte deutliche Arbeitserleichterungen, eine bessere Nachvollziehbarkeit und Krisenfestigkeit für Museen bedeuten.

Im Folgenden werden die grundlegenden organisatorischen Anforderungen für die Etablierung vergleichbarer Strukturen beschrieben. Eine sicher unvollständige Auflistung der realen Hindernisse zur Schaffung einer solchen leitet im Anschluss zum abschließenden Entwurf einer Strategie für eine weitere Verbreitung und Schaffung effizienterer, digitaler Strukturen – im einzelnen Museum wie darüber hinaus – über.

Anforderungen

Der zentrale Wissensspeicher des digitalen Idealmuseums ist seine Museumsdatenbank.

Der hier gewählte Begriff der Museumsdatenbank ist gezielt überspitzt. Der in der Wahl des Begriffs formulierte Anspruch, eine zentrale Zusammenführung des Wissens und der Aktivitäten eines Museums zu erreichen, ist aber essentiell. Nur so lässt sich eine wirklich eindeutige und stabile Referenzierbarkeit schaffen. Nur so können skalierbar, abteilungsübergreifend und nachhaltig Übersichten erstellt werden. Und nur so lässt sich zumindest ein Mindestmaß an grundsätzlicher Strukturgleichheit der Daten sicherstellen, das zukünftige Automatisierungen deutlich vereinfacht. Grundsätzlich gilt, dass eine möglichst weitgehende Einschränkung der Zahl verschiedener Anwendungen in einem Museum (wie auch sonst) sowohl für eine einfachere Administration der Systeme als auch für eine bessere Zugänglichkeit für die oft nicht technisch ausgerichteten Mitarbeitenden sorgt.

Eine einzige, zentrale und gemeinsame Datenbank bedeutet, dass alle Mitarbeiter in irgendeiner Form mit demselben System arbeiten. Es bedeutet das oft geforderte Aufbrechen von Informations-Silos und eine zunehmende Transparenz des Arbeitens zwischen den Mitarbeitenden. Auf institutioneller Ebene ist dies lohnend und viel besprochen. Auf persönlicher ist dafür gerade in großen und größeren Museen ein grundlegendes Umdenken nötig. Befürchtungen, dass zunehmende Informationen über den eigenen Zuständigkeitsbereich zu einem verstärkten, uninformierten Hinterfragen der eigenen Entscheidungen führen, können und müssen mit besserer Kommunikation und Vertrauen zwischen Mitarbeitenden und Abteilungen beantwortet werden. Eine effektive Digitalisierung kann nur mit den Mitarbeitenden des Museums und nicht gegen diese geschehen.

Andererseits gibt es getrennte Systeme, bei denen eine Trennung tatsächlich sinnvoll sein kann. Eine enge Integration von Personaldaten, Lohnabrechnungen und Sammlungsdaten ist rechtlich sicherlich problematisch, praktisch nicht von Vorteil und schon an sich dystopisch. Die Verwaltung und Bearbeitung von beliebigen Dokumenten etwa zu einer Ausstellung wird von den jeweils darauf spezialisierten Anwendungen – Dateimanagern und Office-Anwendungen – besser und effektiver erledigt, als das mit einer Museumsdatenbank möglich wäre. Eine Anbindung dieser Dokumente an die Datenbank ist aber gerade im Fall von Ausstellungen naheliegend. Welche Arbeitsbereiche es in einem gegebenen Museum gibt und welche tatsächlich logisch grundlegend abgetrennt arbeiten sollen, sollte frühestmöglich besprochen und festgelegt werden.

Zu guter Letzt ist ein Datenbankdesign nötig, das eine Integration der vielen verschiedenen Funktionalitäten ermöglicht. Dies bedeutet einerseits – auf Ebene der konkreten Datenbank – das grundlegende Felder für die verschiedenen Entitäten und Prozesse definiert werden müssen. Andererseits erfordert das Ziel der Integration, dass die Datenbanksoftware entweder eine API liefert, Exporte idealerweise in nicht museumsspezifischen Formaten ermöglicht oder die Daten zumindest in einer niedrigschwellig zu nutzenden Form abspeichert.

Zu den sauber erfassten Sammlungsdaten […]

Die Vollständigkeit und Einheitlichkeit von Sammlungsdaten ist nicht zuletzt durch die in vielen Museen mittlerweile entscheidende Rolle von Digitalisierungsprojekten für die Erschließungsarbeit durchwachsen. Mit der Festlegung allgemeiner, museumsweiter „Hausregeln“ sowie ggfs. projekt- oder (teil-)sammlungsspezifischer Regeln für die Erschließung lassen sich trotz der Diversität der erfassten Daten grundlegende Erwartungsmaßstäbe definieren, auf deren Basis in der Folge gut weitergearbeitet und automatisiert werden kann. Um allerdings überhaupt sinnvolle und langfristig gültige Regeln zu definieren, braucht es in den Museen ein gutes Verständnis der Relevanz und Logik von Inventarisierung und Erschließung.

Eine besondere Schwierigkeit, sowohl bezüglich der Sauberkeit als auch der Einheitlichkeit der Daten, ergibt sich oft durch projektspezifische Anforderungen an die Erfassung. Die Versuchung, eigene, projektspezifische Datenbanken (oder Excel-Tabellen) zu schaffen, ist groß. Um die vollen Vorzüge der Digitalisierung im Museum zu gewährleisten, sollten solche museumsinternen Sonderwege unbedingt vermieden werden. Eine später immer wieder notwendige Migration der projektspezifischen Daten in die zentrale Datenbank ist teuer und kompliziert.

Durch eine eng abgestimmte Synchronisations-Routine, saubere Datenerfassung und die Verwendung von Normdaten kann der Abgleich der Daten ohne weitere menschliche Intervention geschehen.

Eine vollständig automatisierte Weitergabe von Daten aus einem in ein anderes System besteht grundsätzlich aus drei Aspekten. Zuerst müssen die relevanten Daten vom Ursprungssystem ausgespielt werden, dann müssen sie zum gegebenen Zielsystem gelangen, und schließlich müssen sie dort eingelesen werden können. Sowohl das Ursprungssystem als auch das Zielsystem müssen dazu entsprechende Schnittstellen bieten. Dies betrifft die Anbindung externer Datenbanken¹ an die zentrale Museumsdatenbank ebenso wie den Abgleich von Daten aus der Datenbank des Hauses mit z.B. dem museumseigenen Online-Katalog oder zwischen jenem und museumsübergreifenden Portalen.

Der mittig liegende Arbeitsschritt des Transportes und ggfs. der Transformation der Daten um sie ins Zielsystem zu integrieren kann dabei – wie im Fall des automatischen Bezugs von Normdaten z.B. aus der GND meist der Fall – direkt im Ursprungs- oder Zielsystems integriert sein. Durch die Vielzahl der zur Verfügung stehenden Systeme ist die Notwendigkeit der Schaffung einer museumsspezifischen Integration oft gegeben und verständlich. Bisher sind es oft Mitarbeiter des Museums, die die Integration händisch durchführen, etwa indem sie Exporte auslösen, Tabellenspalten umbenennen oder Exportdaten vor einer Weitergabe anreichern. Gerade Formatanpassungen und Anreicherungen müssen so bei jeder Aktualisierung der Daten von neuem durchgeführt werden.

Um einen regelmäßigen, automatischen Abgleich zu ermöglichen, muss dieser Arbeitsschritt entweder automatisiert oder in Ex- oder Import (d.h. in Ursprungs- oder Zielsystem) integriert werden. Eine nachhaltige und für Museen langfristig realistisch wartbare Integration verlangt stabile Schnittstellen, da jede Anpassung der Schnittstellen auch eine Anpassung der damit interagierenden Komponenten bedeuten kann.

Da bei jeder Anpassung der Ex- oder Importschnittstellen eine Anpassung museumsspezifischer / Anbindungen notwendig sein kann, verlangt e

Die Bereitstellung von Schnittstellen, die händische Formatanpassungen überflüssig machen, ist in vielen Fällen sinnvoller bei der Ursprungs- oder Zielsoftware angesiedelt als in einem nicht vollständig automatisierten Zwischenschritt. Ist die Bereitstellung eines Export- oder Importformats Teil eines der Systeme, so kann eine entsprechende Entwicklung vielen Museen zu gute kommen. Dies setzt allerdings eine museumsübergreifende Einheitlichkeit der Formate – zumindest innerhalb eines Programms – voraus, die nicht jede übliche Sammlungsmanagement-Lösung bietet.

Gerade die Weitergabe an nicht museumsspezifisch angepasste Anwendungen und Portale profitiert massiv von eindeutigen, institutions-übergreifend gültigen Referenzierungen von zentralen Begriffen wie etwa Ortsangaben. Diese lassen sich durch die Verwendung übergreifender Terminologien und Normdatenkataloge herstellen. Die Anreicherung von z.B. Ortsangaben mit Normdaten geschieht nicht zuletzt durch die bessere Verfügbarkeit entsprechender Software (wie z.B. OpenRefine) derzeit zunehmend manuell im Zwischenschritt. So sehr dies einen Gewinn gegenüber der vollständigen Abwesenheit von Normdatenbezügen darstellen mag, so sehr stellt es bei einer irgendwann nötigen Aktualisierung der Daten Schwierigkeiten dar. Und umso mehr verunmöglicht es eine wirkliche Automatisierung des Datenaustausches.

Um eine Automatisierbarkeit herzustellen, sollten Anreicherungen entweder direkt im Ursprungssystem oder automatisch beim Import ins Zielsystem geschehen. Der Nutzen einer Anreicherung im Ursprungssystem ist offensichtlich – ist eine Anreicherung im Ursprungssystem schwieriger als eine Anreicherung in einem Zwischenschritt des Datentransfers, sollte primär auf eine Verbesserung des offenbar verbesserungswürdigen Ursprungssystems hingewirkt werden.

Andererseits erlauben es die in vielen Museen verfügbaren Mitarbeiterzahlen oft nicht, eine Anreicherung aller Sammlungsdaten des Hauses in einem realistischen Zeitraum umzusetzen, ohne die Arbeit der Institution zu lähmen. Dies macht einen pragmatischen Umgang mit imperfekten Daten an möglichst zentraler Stelle (und das heißt meist im Zielsystem) sinnvoll.

Selbst ohne zugehörige ID ist die Wahrscheinlichkeit, dass die Zeichenkette „Berlin“ – in einem deutschen Museum, das deutschsprachig formulierte Daten in ein primär deutschsprachiges Portal importieren möchte – die deutsche Hauptstadt bezeichnet extrem hoch. Eine Zuordnung kann hier automatisch auf Basis des Namens geschehen, ohne dass es eine substanzielle Gefahr einer Verfälschung der Daten gäbe. Wäre das Museum in Ohio, oder wäre die Zeichenkette „Frankfurt“ gäbe es eine deutlich größere Gefahr der Verfälschung. Ein pragmatischer Umgang heißt also einerseits, eindeutige Begriffe zu akzeptieren und wo möglich automatisch passend zuzuordnen. Andererseits heißt es auch, negativ abzuwägen, wo dies angemessen ist. Solche Abwägungen sind aber bei zentralen Portalen mit entsprechender Expertise und Infrastruktur deutlich sinnvoller anzusiedeln als bei jedem einzelnen Museum. Auch, weil manche Abwägungen so nur einmal, statt tausende Male und für jedes Museum neu gemacht werden müssen.

Der generelle Ansatz pragmatischer Abwägungen und einer möglichst starken Automatisierung des Zielsystems ist hier primär am Beispiel des Datenaustauschs mit Portalen beschrieben, gilt aber ebenso für alle anderen Systeme. Und sei es zwischen dem Klimasensoren aus Ursprungssystem und der museumseigenen Datenbank als Ziel.

Realitäten und die Diversität der Hindernisse

Alleine in Deutschland gibt es nach Zählung des Instituts für Museumsforschung circa 7000 Museen. Von kommunal getragenen Museen zu Privatmuseen, von Kunstmuseen zu Naturkundemuseen, von kleinen Heimatmuseen zu Landes- und Bundesmuseen mit hunderten Mitarbeitern und mehreren Standorten versteckt sich in dieser Zahl eine enorme Spannbreite von verschiedenen Erfahrungen.

Durch die Diversität der Museen, sind notwendigerweise auch die konkret denkbaren Ziele der Digitalisierung in einem konkreten Museum, die Ausgangsbedingungen und Hindernisse divers und schwer zu verallgemeinern. Manche Probleme betreffen alle Arten von Museen, sind aber nicht notwendigerweise in jedem Museum kritisch.

Kenntnisse

Um von einer groben Gesamtstrategie in konkretere strategische und taktische Erwägungen überleiten zu können, sind eine gute Kenntnis der Ausgangssituation, von Best Practices und die Entwicklung konkreter Ziele und Zwischenziele entscheidend.

Gerade im Fall der Sammlungen können die meisten Museen aber selbst grundlegende, naheliegend erscheinende Fragen nicht exakt beantworten. Besonders die Gesamtzahl der von einem Museum gesammelten Objekte – so nützlich sie für die Festlegung von Kennzahlen und Meilensteinen wäre – können die wenigsten exakt beziffern. Über die Jahrzehnte wurden Konvolute entgegengenommen und angekauft und nicht aufgeschlüsselt und einzeln inventarisiert, ein konkretes Sammlungskonzept wurde erst spät oder nie festgelegt und verbindlich niedergeschrieben, die Entscheidung zum Umgang mit Konvolutobjekten (ist eine Zeichenmappe mit 12 lose eingelegten Blättern ein Objekt, ein Objekt mit 12 Unterobjekten, oder 13 Objekte?) hing jahrzehntelang von einzelnen, wechselnden Mitarbeitern ab.

Um also eine Gesamtzahl auch nur schätzen zu können, bedarf es erst einmal Festlegungen zur praktischen Definition des Objekt- und Sammlungsbegriffs innerhalb des Museums. Um zu ermitteln, wie weit die (digitale oder analoge) Inventarisierung der Sammlung fortgeschritten ist, braucht es eine Bestimmung dessen, was als inventarisiert gilt. Es braucht Grundkenntnisse der Inventarisierung und des Sammlungsmanagements. Gerade in Westdeutschland, wo die Museologie als eigenes Studienfach eine eher geringere Bedeutung hat, aber auch allgemein durch Personalfluktuation und die oft große Zahl von fachfremden ehrenamtlich Mitarbeitenden in Museen, gilt es diese regelmäßig zu vermitteln.

Mithilfe von Gesamtzahlen lassen sich KPIs leichter bestimmen, Meilensteine definieren, und ein leichter Fortschritt projezieren. Es ist also nützlich, Gesamtzahlen auch nur Schätzungsweise festzulegen, auch wenn der schätzungsweise Charakter der Zahlen dabei niemals unerwähnt bleiben sollte. Damit solche Schätzungen einen Nutzen entfalten können, müssen sie aber klar und für die gesamte Institution einsehbar und verbindlich festgelegt werden.

Das Problem fehlender Inventarisierungskenntnisse betrifft primär kleinere Museen. In größeren, oft direkt forschungsorienterten Institutionen gibt es ein artverwandtes Dilemma: Durch die konkreten Anforderungen von Materialgattungen und Projekten ist es hier oft naheliegend, material-, sammlungs- oder projektspezifische Datenbanken oder Datenschemata zu erstellen und Parallelstrukturen zu entwickeln. Aus reiner Forschungsperspektive ergibt dies oft Sinn – aus Perspektive der nachhaltigen Arbeit in der gesamten Institution verhindert es Transparenz und die Hebung positiver Synergieeffekte. Umso wichtiger sind hier also frühe und verbindliche Absprachen zwischen den Abteilungen oder zwischen Fachabteilung und Mitarbeitenden im Projekt. So können pragmatische Entscheidungen ohne folgende Animositäten getroffen werden, die ihrerseits der Bildung von Synergieeffekten entgegenstehen würden. Auch wenn Pragmatismus oft ein kleines Abweichen von fachlich korrekten Termini benötigt: Gibt es etwa wirklich einen Unterschied zwischen einer Signatur und einer Inventarnummer oder bezeichnen beide Begriffe – in verschiedenen Disziplinen – doch dasselbe?

Gerade in kleineren und mittleren Museen ergeben sich weitere Probleme aus der je nach konkreter Person oft stark divergierenden Kenntnis von Erschließungssystemen, starker Personalfluktuation, und der Seltenheit einer schriftlichen Dokumentation der eigenen Arbeitsweise. Statt die Digitalisierung strategisch zu gestalten preschen einzelne motivierte Mitarbeitende voran, etablieren in sich sinnvolle, aber wenig dokumentierte projekt- oder personenspezifische Datenbanken. Durch die fehlende Dokumentation und Einbindung in ein übergeordnetes, geplantes Gesamtsystem müssen diese Datenbanken später entweder mühsam und kostspielig migriert oder verworfen werden. Dies gilt umso mehr, wenn die ursprünglichen Ersteller des Systems nicht mehr zur Verfügung stehen und – so die Stellen überhaupt nachbesetzt werden – ihre Nachfolger ein anderes Aufgabenprofil und andere Kenntnissen und Motivationen haben.

Show, don’t tell – Sichtbarkeit der Vorteile eines strukturierten Arbeitens

Digitalisierung kann ohne die Unterstützung derer, die sie primär betrifft, nicht erfolgreich und nachhaltig geschehen. Dies gilt umso mehr für eine strukturierte, nachhaltige Digitalisierung.

Menschen von den Potentialen der Digitalisierung zu überzeugen gelingt am leichtesten, wenn diese einerseits intuitiv, nachvollziehbar und einfach umzusetzen, und Vorzüge andererseits direkt spürbar sind.

Eine einfache, strukturierte und nachhaltige Datenerfassung zu ermöglichen ist eine Aufgabe für Softwareanbieter wie Institutionen. Etablierte Designpatterns wie Drag- and Drop, sinnvolle Vorschläge, oder die Möglichkeit, Eingaben zu wiederholen, können direkt als Teil der Datenbank implementiert werden und die Arbeit deutlich erleichtern. Hemmnisse wie eine fehlende Netzwerkanbindung in denkmalgeschützten Depoträumen liegen in der Verantwortung der Museen selbst oder ihrer Träger. Sie zu beseitigen ist essentiell und fast immer kostentragend – die durch die Beseitigung derartiger Hemmnisse entfallenden Reibungsverluste (auch bezüglich der Arbeitszeiten) wiegen Investitionen in Netzwerkinfrastruktur fast immer schnell wieder auf – und Betriebsklima und Akzeptanz von Digitalisierungsmaßnahmen gewinnen deutlich.

Einige Vorzüge der strukturierten und allgemeinverbindlichen Datenerfassung sind ihr inhärent und sofort spürbar. Der Gewinn, wenn über verschiedene Sammlungen hinweg gesucht werden kann, ist merklich und braucht keiner weiteren Erklärung. Wenn in einer Datenbank nach verschiedenen Datenfeldern gefiltert oder sortiert werden kann, ist der Vorteil gegenüber einem analogen Zettelkasten offensichtlich. Die Möglichkeit zur ortsungebundenen Arbeit mit webbasierten Systemen ist sofort einleuchtend.

Aber auch diese Vorteile relativieren sich über die Zeit und zeigen nur einen kleinen Teil der Potentiale auf. Umso wichtiger ist es, frühzeitig auch unerwartete Synergieeffekte zu zeigen. Immer sichtbare Visualisierungen, automatisch erzeugte Berichte, oder frühzeitig implementierte Integrationen und Automatisierungen können hier von großer Hilfe sein. Ob dies direkt als Teil der Benutzeroberfläche eines zentralen Datenbanksystems im Museum umgesetzt werden kann, liegt nicht zuletzt wieder daran, wie sehr die Datenbank an das Museum oder Teilbereiche angepasst ist. Je weiter verbreitet eine Konfiguration oder eine Datenbank, desto leichter lassen sich allgemeingültige Lösungen schaffen und desto kostengünstiger sind sie.

Arbeitskraft

Das größte und offensichtlichste Hemmnis der Digitalisierung im Museum, das alle Museen betrifft, ist die Verfügbarkeit von Arbeitskraft. Dies betrifft sowohl die inhaltliche Arbeit mit Objekten, Planung von Ausstellung, etc., als auch technische Unterstützung etwa zur Implementation von Integrationen und Automatisierungen.

Dass eine Person nicht hunderttausende Objekte innerhalb eines Jahres bis in ihre Tiefe ergründen und digital erschließen kann, ist offensichtlich. Ein realistischer Umgang mit Erwartungen und ein abgestimmtes Planen von Projekten zur Schaffung von Synergieeffekten (etwa die Beantragung von Projektmitteln zur Erschließung einer Teilsammlung in den Jahren vor der dazu geplanten Ausstellung) sind naheliegend.

Technische Lösungen können die Arbeit deutlich effizienter und nachhaltiger machen. Bestimmte Teilaspekte der Arbeit bleiben zwangsläufig aufwändig, insbesondere Rechercheaufgaben in historischen Quellen.

Andere Aufgaben lassen sich mit technischer Hilfe und der vorausschauenden Entwicklung von Strategien und Infrastrukturen vollständig automatisieren. Gerade Aufgaben der Datenübertragung und Integration von Systemen sind meist wie oben beschrieben inhärent automatisierbar und können den Mitarbeitenden im Museum so nachhaltig abgenommen werden – solange Datenformate und Schemata stabil gehalten und Prozesse möglichst reibungslos gestaltet sind.

Die Kapazität zur Entwicklung von derartigen Integrationen unterscheidet sich zunehmend zwischen größeren bis großen und kleinen Museen. In Ersteren wurden seit 2015 zunehmend spezifisch für die Digitalisierung Stellen und so oft auch direkt Kapazitäten für die Programmierung von Integrationen geschaffen. Neben der Integration und Automatisierung erfordern die spezifischen Anforderungen größerer Museen – Koordination zwischen Abteilungen, Vermittlung und Mediation, Schaffung von Akzeptanz gegenüber allgemeinerer Transparenz – von den für Digitalthemen eingestellten Mitarbeitenden aber oft quasi die Aufgaben von Change Managern.

Kleinere Museen haben oft geringere Anforderungen und vor allem einfachere Strukturen – die Einbindung und Anzeige der Tageskarte des Museumscafés macht wenig Sinn, wenn es schlicht kein Museumscafé gibt. Bisher verschließen sich selbst leicht umzusetzende Automatisierungen vielen kleineren Museen, weil es keine passenden Ansprechpartner im oder für die Museen gibt. Für die Beauftragung kommerzieller Anbieter fehlen die Mittel, und der Aufbau entsprechender Stellenkontingente und Kapazitäten sind illusorisch. Ob Automatisierungen, die nicht Teil des bestehenden Datenbanksystems sind, geschaffen werden können, hängt allzu oft davon ab, ob sich willige und fähige Freiwillige finden.

Conclusio: Ein Entwurf

Wie können Museen also, gerade in Zeiten allgemeiner Verunsicherung und wirtschaftlicher Schwierigkeiten, die Vorzüge der Digitalisierung in volleren Zügen genießen, ihr strategisch begegnen, und dabei unterstützt werden?

Zuerst ist ein grundlegendes Bedenken und gemeinsames Erörtern der Rolle der Digitalisierung in den Museen nötig, mit allen potentiell betroffenen Mitarbeitenden – und das sind im Zweifelsfall schlicht alle. Ein frühes Sammeln der Befürchtungen und – wichtig – der Erwartungen und Hoffnungen macht es möglich, diese offen mit unterstützenden Institutionen und Dienstleistern zu besprechen und Lösungen und Umsetzungen früh zu planen.

Die Moderation eines solchen Prozesses erfordert selbst ein gutes Verständnis von digitaler Museumsarbeit. Gibt es in einem gegebenen Museum niemanden, der Museum und Digitales zusammenbringen und den Prozess moderieren kann, so gibt es auch heute schon Angebote der Museumsverbände und vergleichbarer staatlicher Stellen, ihn zu begleiten. Die Bündelung von Expertise in übergreifenden Strukturen macht gerade für kleinere Museen viel Sinn; noch hinken die Kapazitäten den Bedarfen aber oft hinterher.

Die Konkretisierung und Verbindlichmachung von gemeinsam getroffenen Grundannahmen und Zielvorstellungen sowie eine regelmäßige Reflektion und eine Offenheit zur Anpassung dieser, falls sie sich als unrealistisch herausstellen, ist wichtig.

Knapp 75 Jahre nach der Entwicklung der ersten Computer, über 30 Jahre nach dem Beginn des World Wide Web und ca. 20 Jahre nach dem Durchbruch von Smartphones steht so gut wie kein Museum dabei wirklich am Anfang. Zur Kommunikation wird gechattet, Mail ist verbreitet, Sammlungsdaten sind fast überall in irgendeiner Form digital erfasst (ob in einer sich regelmäßig wandelnden Excel-Tabelle oder in einer strukturierten Datenbank; oder in 15 verschiedenen). Die Ausgangssituationen sind dadurch nur diverser geworden, und die Diskussion muss sich vor allem um die Digitalisierung als strukturierten und strukturierenden Prozess und Gelegenheit zur Besserung der Arbeitssituation und Effektivität drehen. Dies erfordert umso mehr Expertise und im Fall von externen Unterstützenden Zeit und Fähigkeit, die Ausgangssituationen angemessen und in die Tiefe zu ergründen.

Ist eine Strategie mit konkreten Zielvorstellungen gefasst, gilt es diese Umzusetzen und dabei auch im Konkreten den gemeinsam festgelegten Vorgehensweisen zu folgen. Verbindlichkeit einzufordern und besprochenes Umzusetzen statt langfristig teurere, aber im konkreten scheinbar naheliegende Sonderwege zu gehen, ist ein Problem das mit der (inhaltlichen wie personellen und räumlichen) Größe eines Museums wächst. Ein Konzept oder eine Zuständigkeit für das Change Management existiert in größeren Häusern oft sinnvollerweise schon. Kapazitäten für die Entwicklung der fast notwendigerweise museumsspezifischen Integrationen bestehen zunehmend, und das Schreiben des oft sehr übersichtlichen Codes von Integrationen lässt sich heute mit KI-Unterstützung weiter vereinfachen.

In kleineren Museen ist der Aufbau eigener Kapazitäten zur Erstellung von Integrationen und Automatisierungen meist unrealistisch, während die Beschäftigung von kommerziellen Dienstleistern die Budgets gerade ehrenamtlich geführter Museen schnell übersteigt. Hier würde eine Bündelung und der Aufbau von geteilten Kapazitäten Sinn machen. Schon eine Person, die organisatorisch bei einem der Museumsverbände (oder vergleichbarer Institutionen von übergreifender Zuständigkeit) angesiedelt wäre, und jeweils für einige Tage in die Museen reist, um neben der Beratung konkrete Automatisierungen und Integrationen zu schaffen, könnte vielen Museen kostengünstig und effektiv helfen.

Besonders in kleineren Museen bleibt das Onboarding neuer Mitarbeiter eine Herausforderung, der durch eine enger integrierte Arbeit der Beschäftigen mit denselben Systemen einerseits und einer verschriftlichen Strategie und der Dokumentation von Arbeitsschritten begegnet werden kann. Auch hier können die Museumsverbände als zentrale Stelle, die die Bedeutung und Logik der Maßnahmen erläutert und konkrete Vor-Ort-Beratung bietet, helfen.

Eine vollständige Automatisierung erfordert dabei aber einerseits die nötigen Grundlagen, die früh genug geplant sein sollten (etwa die Anbindung an Normdaten), und eine ausreichende Kontrolle über die eigenen Anwendungen und Systeme. Bietet die eigene Sammlungsdatenbank etwa schlicht keine dokumentierte offizielle Schnittstelle, so ist das Schaffen einer solchen unter Umständen mit enormen zusätzlichen Aufwänden und absehbarer Instabilität verbunden. Damit Integrationen und Automatisierungen nicht regelmäßig angepasst werden müssen, braucht es eine Stabilität der konfigurierten Datenbankschemata. All diese Aspekte, können, früh bedacht, in der Auswahl und Konzeption von Hard- und Software helfen.

Manche Komponenten entziehen sich zwangsläufig der Kontrolle einer gegebenen Institution – besonders museumsübergreifende Lösungen und Portale. Bei der Fortentwicklung dieser wäre es wichtig, die Reibungslosigkeit von Integrations- und Importprozessen in den Vordergrund zu stellen, ohne die angestrebte Qualität und Interoperabilität aufzugeben. Dies bedeutet einerseits eine stete Verbesserung der zentralisierten Dienste, die Schaffung naheliegender Autokorrekturlösungen bei Importen, und andererseits einen Willen, Prozesse und Strukturen zu vereinfachen. Korrektur- und Überprüfungsphasen in der Weitergabe zu Portalen machen etwa bei einem ersten Import unbedingt Sinn, sind aber bei Updates strukturell gleich gebliebener Daten eine unnötige Verkomplizierung des Prozesses, die einer vollständigen Automatisierung der Datenweitergabe im Weg steht.

Anhänge

1: Roadmap

1. Bestandsaufnahme der im Haus bestehenden Kapazitäten und etwaige Einholung externer Beratung und Unterstützung
   1. Falls nötig: Frühe Schulung bezüglich der Grundsätze eines effektiven Sammlungsmanagements
2. Bestandsaufnahme der im Haus vorhandenen technischen Systeme und Aufgaben; erster Entwurf einer Übersicht, bei welchen eine Anbindung an einen zentralen Wissensspeicher sinnvoll sein kann
3. Besprechung in zunehmend größer werdenden Gruppen bis zu einer Vollversammlung der Mitarbeitenden, Ermittlung von Bedarfen, Befürchtungen und Wünschen. Verbindliche Festlegung von Zielen auf taktischer und strategischer Ebene.
4. Anschaffung, Konfiguration der nötigen Hard- und Software
5. Schaffung von nachhaltiger Akzeptanz
   1. Automatisierung und Integration von Systemen auf technischer und prozedualer Ebene
   2. Kontinuierliche Ermittlung und Beseitigung von Hemmnissen
6. Effektiveres Arbeiten & regelmäßiges Feedback

2. museum-digital

museum-digital ist eine Initiative, die 2009 mit dem Ziel gegründet wurde, Museen zu ermöglichen, ihre Objekte kostenfrei und einfach gemeinsam zu publizieren. Bald zeigte sich, dass viele der teilnehmenden Museen keine dezidierte Sammlungsmanagement-Lösung hatten und die damals noch primär auf die Publikation ausgerichtete Eingabeoberfläche musdb als Ersatz für ein solches nutzten. Entsprechend wurde es – weiterhin eng mit der Publikation verzahnt – zu einem vollwertigen Sammlungsmanagement-Tool erweitert. Spätere Angebote beinhalten Tools zur Erstellung digitaler Ausstellungen, Qualitätsschätzung, und mehr.

Die Kombination eines immer hohen Stellenwertes der Publikation und Interoperabilität einerseits, und des Anspruchs möglichst kosteneffektiv zu arbeiten andererseits, erforderte frühe entsprechende Weichenstellungen. So benutzen alle Museen, die mit museum-digital arbeiten, eine gemeinsame Datenstruktur, eine zwar anpassbare, aber grundlegend einheitliche Benutzeroberfläche, und ein gemeinsames Set von kontrollierten, mit Normdateien verknüpften Vokabularen, die zentral für alle Museen gemeinsam angereichert und verbessert werden.

Die Erkenntnis, dass die Kernkompetenz von Museen in der Bewahrung, Beforschung und Vermittlung ihrer Sammlungen und nicht die Kenntnis technischer Details (z.B. von Austauschformaten) ist, führte zu einer frühen Betonung reibungsloser Prozesse: Die oben beschriebenen Automatisierungen zur Erkennung und automatisierten Bereiningung von Importdaten sind schon heute bei museum-digital weitgehend umgesetzt.

Museen können museum-digital nutzen, um ihre Bestände zu publizieren, zu verwalten, oder um beides zu tun. Ist letzteres der Fall, ergibt sich ein deutlich vereinfachtes Bild: Klimasensoren, Lichtschranken, etc. können direkt mit museum-digital verknüpft werden, die Publikation ist – solange die vom Gesamtsystem vorausgesetzten Qualitätsmaßstäbe eingehalten werden – immer nur einen Klick entfernt, und ein maschinenlesbarer Zugriff sowohl auf einzelne Datensätze wie für den massenweisen Abruf zum Zwecke der Synchronisation – etwa durch die Deutsche Digitale Bibliothek – sind über einfach zugängliche, gut dokumentierte und offene Schnittstellen möglich. Durch die museumsübergreifend einheitlichen Datenstrukturen und Schnittstellen lassen sich für ein Museum geschaffene Anbindungen zudem auch einfach von anderen Museen nachnutzen.

3. Die Deutsche Digitale Bibliothek

Die Deutsche Digitale Bibliothek (DDB) hat sich seit ihrer Gründung zum zentralen Abschluss im Lebenszyklus von Daten aus der Bestandserschließung in deutschen Kulturerbeeinrichtungen entwickelt. Aus Perspektive der Museen bietet sie einerseits den Anschluss an weitere Kulturerbesparten – Bibliotheken und Archive – und andererseits an die Europeana als gesamteuropäische Plattform.

Dadurch, dass sie ein gesamtdeutsches Vorhaben ist, und dass viele Förderprogramme für Digitalisierung eine Datenlieferung an die DDB voraussetzen, bildet die Datenlieferung an die DDB eine vereinende Aufgabe – und damit einen (wenn auch kleinen) Identifikationspunkt – für alle, die mit der Digitalisierung in Museen in Deutschland befasst sind.

Schon unabhängig von ihrer konkreten Arbeit ist die Deutsche Digitale Bibliothek damit ein wichtiges strukturierendes Element im übergreifenden Ökosystem der Museumsdigitalisierung. Ihre Existenz bietet einen Fokuspunkt, an dem sich digitale Strategien ausrichten können.

Danke

Mein ausdrüklicher Dank gilt den verschiedenen Kollegen, besonders aus den Museumsverbänden, die verschiedene Entwürfe des vorliegenden Papiers gegengelesen und hilfreiche Anmerkungen beigesteuert haben.

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

1. Im Museum, wie übergreifend etwa die Gemeinsame Normdatei [GND], den Art and Architecture Thesaurus [AAT] oder geonames. ︎

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.

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.

Hintergrund der geänderten Nutzungsbedingungen ist primär der Übergang der Trägerschaft der deutschen Instanzen zum museum-digital Deutschland e.V. In diesem Rahmen haben wir mit anwaltlicher Hilfe daran gearbeitet, die Nutzungsbedingungen rechtssicherer und ausführlicher zu gestalten.

Im Rahmen der Aktualisierung der Nutzungsbedingungen sind ebenfalls einige technische Neuerungen hinzugekommen – es muss schließlich auch bei jedem Nutzer festgehalten werden, wer wann welchen Nutzungsbedingungen zugestimmt hat. Eine Liste der Nutzungsbedingungen, zu denen man zugestimmt hat, lässt sich nun entsprechend auf der Seite „Kontoeinstellungen“ in musdb einsehen.

Die aktualisierten Nutzungsbedingungen können jederzeit im Handbuch eingesehen werden.

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

Wie immer gilt, dass somit Nutzer, die Tamil als ihre Browser-Sprache eingestellt haben, automatisch Navigation und mehrsprachige Elemente in Tamil sehen. Alle Anderen, die eine gegebene Seite in Tamil benutzen möchten, können ihre Sprache über den Sprach-Wechler ganz oben rechts umstellen.

Image credits: „Tamil Community – Worldwide.PNG“ von Coppercholride, via Wikimedia Commons, lizensiert unter Creative Commons Attribution-ShareAlike 3.0 Unported.

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

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

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

KI-generierte Beschreibungstexte

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

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

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

Gedanken

Drei Vorschläge

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

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

Das Generieren dauert lange!

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

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

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

Kooperation: Hardware & Auswertung

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

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

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

Neue Features

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

Verbesserungen

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

musdb

Neue Features

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

Verbesserungen

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

Bugfixes

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

Importer

Neue Features

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

Verbesserungen

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

Bugfixes

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

nodac

Neue Features

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

CSVXML

Verbesserungen

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

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

musdb

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

Importer

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

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

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

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

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

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

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

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

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

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

In der Praxis:

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

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

Entgegen der Logik oder Umgang mit Unvollkommenheit

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

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

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

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

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

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

Frontend

• Bugfix: Detaillierte Beschreibung fehlte bisher in der Objekt-API, auch wenn sie auf „öffentlich“ gestellt war
• Übersetzung: Kannada

musdb

• Bugfix: Fehler bei Einrichtung von 2-Faktor Authentifizierung (per TOTP) gelöst
• Bugfix: Symbole für Bild-Dreh-Richtung waren vertauscht
• Feature: Wird das Generieren des PDF-Katalogs über die Seitenspalte einer Objektgruppen-Seite aufgerufen, wird die Reihenfolge der Objekte innerhalb der Objektgruppe zur Sortierung genutzt

Importer

• Bisher wurde kein Standardname für Ressourcen vergeben, jetzt wird – wie in musdb – der Objektname genommen, falls kein spezifischer Name für eine Ressource (Video, Audio-Datei, extern gehostete Bilder) angegeben wurde
• Der CSVXML-Parser kann jetzt mit mehreren Objekten pro Import XML-Datei umgehen

Autouploader

• Komplett neues Tool
• Man stellt Ordner ein, das Tool prüft, ob er Inhalte hat. Ist das der Fall, so werden die Inhalte zum Import hochgeladen und eine passende Import-Settings-Datei wird automatisch generiert. Siehe „Importe selbst durchführen„.
• Zweck: Automatisierter Upload für Museen, die häufiger dieselbe Art von Import durchführen. Fall: Museum hat Adlib, will immer wieder updaten. Zweiter Fall: Museum hat Reproanlage und immer wieder viele Bilder, die es uploaden will statt von Hand heraufladen. Voraussetzung dafür: Eindeutiges Dateibenennungs-Schema.
• Nicht interessant für Importe über CSVXML oder Datenmigration, wo eh entweder viele manuelle Anpassungen geschehen oder der Import nur einmal geschieht.
• Siehe den eigenen Blogpost dazu.
• Der Code des Tools ist unter GPL v3 lizensiert hier verfügbar.

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

Von daher ein großer Schritt zur besseren Auffindbarkeit und Zugänglichkeit von museum-digital: Das Frontend ist jetzt auch in Kannada verfügbar.

Benutzer, deren Browser auf Kannada als Hauptsprache eingestellt sind, sehen nun automatisch die Kannada-Übersetzung der Website-Navigation usw. Andere können die Navigation in Kannada über die Sprachauswahl oben rechts auswählen.

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