museum-digital:blog - jrenslin

musdb reimagined - Aktueller Stand und Zeitplan

2026-09-14T00:00:00+00:00

Im Mai 2026 haben wir eine umfangreiche Überarbeitung des musdb-Benutzerinterfaces angekündigt. Nun nimmt sie zunehmend Gestalt an, und wir können einen konkreten Zeitplan verkünden.

Umfang und Gründe der Überarbeitung

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

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

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

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

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

Eine kleine Vorschau

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

Einzelne Menüpunkte lassen sich jetzt direkt aus der Navigation heraus in den Schnellzugriff schalten oder wieder entfernen.

Neue Filteroptionen

Ein kurzer Screencast aus der kommenden Version von musdb. So wie bereits im alten Design von musdb begonnen erhalten nun auch viele Eintragsarten neben den Objekten viele neue Filterfunktionalitäten.

Drei Anzeigemodi für Übersichten

Alle Übersichtsseiten werden einer uniformen Anzeigelogik folgen. Übersichten können als Grid, als Liste oder als Tabelle dargestellt werden.

Die Infrastruktur für Stapelverarbeitung bei allen Übersichtsseiten

Alle Übersichtsseiten sind jetzt mit der Infrastruktur für das Auswählen und Stapelverarbeiten von Einträgen ausgerüstet. So lassen sich beispielsweise schon jetzt stapelweise Objektgruppen und Sammlungen veröffentlichen oder verstecken. Andere Übersichtsseiten haben bisher keine an die Auswahl gebundenen Stapelverarbeitungsfunktionen - durch die gemeinsame Infrastruktur ist das bedarfsgerechte Implementieren solcher nun allerdings sehr einfach.

Interaktive Übersichten

Hier wird gezeigt, dass alle Übersichtsseiten zu publizierbaren Arten von Datensätzen (Sammlungen, Objekte, Objektgruppen, Ausstellungen, Veranstaltungen / Termine) an einem uniformen Platz eine Anzeige des Publikationsstatus jedes gelisteten Eintrags haben. Durch einen Klick auf den Publikationsstatus können die Einträge direkt aus der Liste heraus versteckt bzw. publiziert werden.

Und wann kommt den nun das Update?

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

14.09.2026	Blog-Post
28.09.2026 - 04.10.2026	Auf dem Dashboard von musdb wird ein Overlay erscheinen, dass auf die neue Benutzeroberfläche hinweist. Es verlinkt die neue Version als Alternative.
30.10.2026	Vortrag zur neuen Benutzeroberfläche bei der museum-digital-Usertagung. Die neue Oberfläche wird bis dahin vollständig sein.
01.11.2026	Der Login-Workflow wird dahingehend abgeändert, dass er primär zur neuen Benutzeroberfläche weiterleitet. Dort erscheint nun ein Overlay, das auf die Änderung hinweist und für einige Zeit den Weg in die alte Benutzeroberfläche weist.
02.11.2026 (1 PM)	Einführungsveranstaltung (Deutsch)
06.11.2026 (1 PM)	Einführungsveranstaltung (Englisch)
16.11.2026 (10 AM)	Einführungsveranstaltung (Deutsch)
22.11.2026	Der Dialog auf dem Dashboard wird gemeinsam mit der alten Benutzeroberfläche entfernt.

info

AI Use

(Post image generated using Anima Base v1)

info

License

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

Folien: Die KI beschreibt mein Objekt? – Anwendungsszenarien und Ausblicke für die Museumsdokumentation in Zeiten von KI

2026-03-17T00:00:00+00:00

Mittlerweile ist der gleichnamige Vortrag aus dem Virtuelles DH-Kolloquium an der BBAW am 16.02.2026 lange vergangen. Dafür gibt es die Folien, die vielleicht einige nach wie vor interessieren könnten.

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

info

License

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

Gemeinfreie Nachschlagewerke verfügbarer machen: resources.museum-digital.org

2026-03-17T00:00:00+00:00

Über die letzten Jahrzehnte wurden abertausende gemeinfreie Werke von Bibliotheken und Initiativen wie dem Internet Archive und Google Books gescannt und im Netz verfügbar gemacht. Das ist an sich eine Arbeit von unschätzbarem Gewinn.

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.

Screenshot des Eintrags zu Johann Baptist Cacchi in resources.museum-digital.org.

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.

info

AI Use

(Post image AI-generated)

info

License

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

Versuch einer Blaupause zur strategischen Digitalisierung in und von Museen

2026-03-17T00:00:00+00:00

Dieser Blog war einmal als Austauschforum gedacht, nicht als Verlautbarungsplattform. Und das sollte er im Idealfall wieder werden. Hier also ein kleiner Debattenbeitrag als Crosspost aus meinem persönlichen Blog.

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.

Exemplarische Skizze einer strukturierten Digitalinfrastruktur im Museum

Anhänge

1: Roadmap

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
Bestandsaufnahme der im Haus vorhandenen technischen Systeme und Aufgaben; erster Entwurf einer Übersicht, bei welchen eine Anbindung an einen zentralen Wissensspeicher sinnvoll sein kann
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.
Anschaffung, Konfiguration der nötigen Hard- und Software
Schaffung von nachhaltiger Akzeptanz
1. Automatisierung und Integration von Systemen auf technischer und prozedualer Ebene
2. Kontinuierliche Ermittlung und Beseitigung von Hemmnissen
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.

Exemplarische Skizze einer strukturierten Digitalinfrastruktur im Museum; vereinfacht mit museum-digital

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.

info

AI Use

(Post image AI-generated using Z-Image)

info

License

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

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

Aktualisierung der Nutzungsbedingungen von musdb & museum-digital in Deutschland

2026-01-12T00:00:00+00:00

Auf der letzten Usertagung des museum-digital e.V. war eine anstehende Aktualisierung der Nutzungsbedingungen von musdb und museum-digital für teilnehmende Institutionen und ihre Mitarbeitenden in Deutschland angekündigt worden. Nachdem sich diese durch die technischen Schwierigkeiten des letzten Monats verzögert haben, sollen die neuen Nutzungsbedingungen nun zum Mittwoch, den 14. Januar, eingeführt werden. Bestehende Nutzer werden sie beim Login sehen und aufgefordert, sie nach einer gründlichen Lektüre zu akzeptieren (bzw. ihr Konto zu löschen).

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.

info

AI Use

(Post image AI-generated using Z-Image)

info

License

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

Stand der Entwicklung, November 2025

2025-12-03T00:00:00+00:00

Frontend

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)

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, August 2025

2025-11-25T00:00:00+00:00

Nachdem die Posts zu den monatlich neuen Entwicklungen um museum-digital in letzter Zeit ausgeblieben sind, soll die Serie nun fortgeführt werden. Hier also der erste von drei Beiträgen zu den letzten Monaten.

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

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, Oktober 2025

2025-11-25T00:00:00+00:00

Entwicklung

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

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, September 2025

2025-11-25T00:00:00+00:00

Entwicklung

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

Auf Quellen-Seiten werden jetzt alle Objekte aufgelistet, die in der Quelle referenziert werden oder sich selbst auf die Quelle beziehen.

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

info

AI Use

Post image generated using AI.

info

License

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

Automatische Erkennung von abgebildeten Elementen

2025-08-27T00:00:00+00:00

Im Januar 2021 haben wir im Rahmen von museum-digital unser erstes KI-gestütztes Feature veröffentlicht. Entweder über eine eigene Seite oder eingebettet in den Objekt-Upload-Workflow wurden Bilder klassifiziert und in Tags für Schlagworte umgewandelt. Seit ca. einem Jahr toure ich durch die Lande, und erkläre, warum dieser Anlauf falsch lag.

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.

In der linken Seitenspalte gibt es eine neue Option “Ikonographische Bilderkennung aktivieren”.

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.

Über die Seitenspalte können die Vorschläge akzeptiert oder abgelehnt werden. Akzeptierte Vorschläge werden direkt korrekt als abgebildete Schlagworte verknüpft.

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.

info

License

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

Stand der Entwicklung, Juni & Juli 2025

2025-08-21T00:00:00+00:00

Juni und besonders Juli waren mal wieder langsam wirkende Monate in der Entwicklung von museum-digital.

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

info

AI Use

Post image generated using AI.

info

License

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

Hindi

2025-07-13T00:00:00+00:00

Nach Kannada, Tamil und Telugu können die öffentlichen Portale von museum-digital nun auch in Hindi durchsucht und genutzt werden. Wie immer: Vielen Dank an alle Beteiligten!

info

Image credits

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

info

License

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

తెలుగు

2025-07-02T00:00:00+00:00

Nachdem wir letzte Woche die frohe Kunde der Übersetzung der öffentlichen Portale von museum-digital in Tamil verbreiten konnten, kommt diese Woche die Übersetzung in Telugu.

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

info

Image credits

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

info

License

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

Tamil

2025-06-23T00:00:00+00:00

Ab heute sind die öffentliche Portale von museum-digital in Tamil verfügbar. Danke an alle, die das möglich gemacht haben!

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.

info

Image Credits

“Tamil Community - Worldwide.PNG” von Coppercholride, via Wikimedia Commons, lizensiert unter Creative Commons Attribution-ShareAlike 3.0 Unported.

info

License

This content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported.

KI & Objektbeschreibungen

2025-06-19T00:00:00+00:00

Objektbeschreibungen sind ein großer Gewinn bei der Publikation von Objektdaten. Während Schlagworte, Ortsbezüge und Ereignisse einen detaillierten und uniformen Blick auf die Daten liefern, erlauben Objektbeschreibungen im Idealfall nuanciertere Beschreibungen von Details. Und vor allem bieten sie als Prosatexte eine oft einfacher verständliche, weniger “datenförmige” Sicht auf die Objekte, die sowohl im Sinne der Barrierefreiheit als auch für Suchmaschinen nützlich ist.

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.

Vorschau der Vorschläge. Per Klicken lässt sich der Passendste auswählen.

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!

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, März 2025 & April 2025

2025-06-08T00:00:00+00:00

Frontend

Ü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

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, Mai 2025

2025-06-08T00:00:00+00:00

Frontend

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. <a href="https://de.handbook.museum-digital.info/musdb/API/index.html#/actor/actorSearchLinkedToObjects">/actor/search_linked_to_objects/{term}</a> , <a href="https://de.handbook.museum-digital.info/musdb/API/index.html#/actor/actorSearch">/actor/search/{term}</a> 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

info

AI Use

Post image generated using AI.

info

License

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

Volltextsuche oder Buchstaben-Suche nach Inventarnummern in musdb?

2025-03-30T00:00:00+00:00

Sucht man nach “rennen”, möchte man Einträge (Objektbeschreibungen, Blog-Posts, etc.) finden, die Begriffe wie “gerannt” oder “[ich] renne” enthalten. Sucht man nach einer Inventarnummer “*1”, möchte man alle Inventarnummern erhalten, die exakt auf die Zahl 1 enden. Im ersten Fall geht es um eine Volltextsuche, idealerweise unter Berücksichtigung von Flexionen, Kofferworten, etc. Die exakten Buchstaben sind untergeordnet - “renne” beinhaltet nicht “rennen, und ist trotzdem ein guter Treffer. In Beispiel der Inventarnummer geht es tatsächlich nur um die Buchstaben. Das Einbringen eines Verständnisses von Flexionen wäre hier fehl am Platz. Abstrakt ausgedrückt: Objektbeschreibungen sind Zeichenkombinationen und Text - und besonders als Text interessant. Inventarnummern sind Zeichenketten, und als solche interessant.

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.

info

AI Use

Post image generated using AI.

info

License

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

Kannada

2025-03-25T00:00:00+00:00

Es wird viel über die FAIR-Prinzipien gesprochen - die Veröffentlichung von Daten in auffindbarer und barrierefreier Form. Logischerweise sollten die Daten, um auffindbar und zugänglich zu sein, zumindest in der Sprache der Nutzer beschrieben sein, auch wenn sie selbst nicht übersetzt sind. Und das bedeutet, dass, bevor Objektinformationen mehrsprachig werden, Plattformen (mehr) mehrsprachig werden sollten - und dabei vor allem auch Sprachen berücksichtigen sollten, die vielleicht nicht in der ersten Reihe der Sprachen stehen, die vom nächstbesten Large Language Model für die Übersetzung abgedeckt werden.

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.

info

License

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

Stand der Entwicklung, Februar 2025

2025-03-25T00:00:00+00:00

Der Februar 2025 war in der Entwicklung von museum-digital ein eher ruhiger Monat. Während unter der Haube nicht wenig geschah, sind direkt ersichtliche Änderungen vor allem Bugfixes. Hier, wie immer, in Listenform:

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.

info

AI Use

Post image generated using AI.

info

License

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

Das Importieren automatisieren

2025-03-08T00:00:00+00:00

Viele Museen importieren ihre Daten zu museum-digital. Wie auch die allgemeine Benutzung von museum-digital gibt es dabei eine Reihe von Gründen und Motivationen.

Museen, die bisher ein anderes Tool zum Sammlungsmanagement genutzt haben migrieren ihre Daten einmal mit Hilfe des Importtools - oft mit dem generischen CSVXML-Import - um dann in musdb weiterzuarbeiten. Museen, die ein anderes Sammlungsmanagement-System haben und damit zufrieden sind nutzen museum-digital rein zur Publikation und fallen dabei in zwei bis drei Kategorien. Die wahrscheinlich größte Gruppe sind dabei Museen, die zum Abschluss eines Digitalisierungsprojektes die im Rahmen des Projektes digitalisierten Bestände importieren und dann gesammelt publizieren. Andere, oft eher größere Institutionen wie das Landesmuseum Württemberg oder die Staatlichen Schlösser und Gärten Hessens importieren und veröffentlichen regelmäßiger um die neuesten gut erfassten Objekte auch unabhängig von Projektkontexten schnell publiziert zu sehen. Dazu kommen Institutionen wie die in den Interaktiven Katalogen des Münzkabinetts arbeitenden Münzsammlungen, die eine eigene primäre Publikationsplattform betreiben und für einen regelmäßigen Datenabgleich daraus importieren.

Zu guter Letzt gibt es Häuser, die zwar direkt in musdb erfassen, aber schlicht zu viele Bild-Digitalisate erstellen, als das ein manueller Upload Sinn machen würde - etwa das Freie Deutsche Hochstift in Frankfurt mit seiner Handschriftensammlung. Hier werden die Bilder entsprechend ihrer Dateinamen zu den bestenfalls schon bestehenden Objektdatensätzen importiert.

Für alle, die regelmäßig und immer wieder mit denselben Methoden bzw. im selben Format importieren, macht es Sinn zu lernen, wie man Importe selbst durchführt.

Importe selbst durchführen

Für das eigenständige Importieren von Objektdaten zu museum-digital steht eine WebDAV-Schnittstelle zur Verfügung. Grob funktioniert der Upload dann wie mit einem Netzwerklaufwerk (bzw. ist genau das) - man verbindet sich und bekommt Zugriff auf einen Ordner.

In diesem befinden sich zwei leere Unterordner, einer für Metadaten und einer für Mediendateien. Nun können die Objektdaten hochgeladen werden. Zuletzt muss man dem Server mitteilen, dass der Upload bereit steht und welche Einstellungen für den Import genutzt werden sollen. Das passiert über eine Konfigurationsdatei. Mehr dazu im Handbuch.

Einerseits ermöglicht das Prozedere Usern einen - einmal probiert - halbwegs einfachen und stabilen Import. Andererseits ist es bei häufigen und regelmäßigen Importen doch weiter mit manueller Arbeit verbunden. Man muss sich eben erstmal verbinden, Uploads auswählen und hochladen, und die Konfiguration erstellen (oder kopieren). Bei großen Datenmengen kann die notwendigerweise chronologische Abfolge der Arbeitsschritte zudem aller Vereinfachung zum Trotz einen nicht zu verachtenden Zeitaufwand bedeuten.

In anderen Worten: Da ist Raum für weitere Automatisierung.

Automatisieren

Gesagt, getan. Mit einem neuen Upload-Tool (erst einmal unkreativ museum-digital:uploader genannt) lässt sich der Upload einfacher gestalten und/oder weiter automatisieren.

Das Tool basiert auf der Annahme, dass man als Museum nur eine Art von Import regelmäßig durchführen möchte - die Einstellungen für den Import also stabil bleiben. Entsprechend beginnt die Nutzung des Tools mit der Konfiguration.

Hier wird neben der ID der Institution, der Mailadresse der importierenden User und dem Importformat auch nach einem Ordner für die Uploads gefragt. Dieser wird in der Folge regelmäßig überprüft. Befinden sich darin Metadaten-Dateien (XML, JSON, CSV) und/oder Mediendateien, so wird ein Import initiiert. Dazu werden die Dateien hochgeladen und die Importkonfiguration auf Basis der Anfangs einmal eingegebenen Einstellungen generiert. Zuletzt werden die Dateien aus dem Ordner gelöscht. Dabei werden sowohl auf lokaler Seite als auch auf dem Server Checks durchgeführt, damit der Upload nicht durchgeführt werden kann, wenn die Ordner gerade noch befüllt werden (etwa lokal erst vor 20 Sekunden ein neu hereinkopiertes Bild vorliegt oder auf dem Server noch ein vorheriger Upload geplant ist).

Damit sich das Tool möglichst flexibel genutzt werden kann, kann es sowohl über Kommandozeilen-Parameter als auch über ein browserbasiertes Interface genutzt werden. Ersteres könnte etwa bei Nutzung eines externen, regelmäßigen Aufrufs genutzt werden. Das Browser-Interface andererseits kommt sowohl mit einer Möglichkeit zum manuellen Anwerfen des Uploads als auch mit einem eingebauten Scheduler, der die Prüfung des Ordners und das etwaige Uploaden alle drei Stunden automatisch durchführt.

Somit ist mit dem Tool der einzige verbleibende Schritt zum vollständig automatisierten Datenabgleich. Für die Häuser, die über einem festgelegten Schema Bild-Digitalisate importieren um sich den manuellen Upload zu sparen heißt das ein einfaches Kopieren der Dateien in den Ordner. Ggfs. schwieriger wird es für die, die häufiger aus einem hausinternen Sammlungsmanagement-System (CMS) importieren. Wie leicht - und ob - sich daraus automatisiert Exporte erstellen lassen, hängt vom jeweiligen CMS und seinen Schnittstellen ab. Es wäre interessant, hier mehr über die Möglichkeiten der einzelnen CMS zu erfahren.

Code-Signing, Windows, Leiden

Schon beim ersten Ideensammeln zum Uploader standen ein paar Grundanforderungen fest.

Der Uploader muss auf einem lokalen Rechner genutzt werden können.
Er muss unabhängig von der Wahl des Betriebssystems eingesetzt werden können. Während der überwiegende Teil der Museen Windows nutzt, sind MacOS-Systeme doch immer wieder anzutreffen. Und die Entwicklung geschieht primär unter Linux.
Alle nötigen Ressourcen für das Programm müssen entweder im Programm enthalten oder über das Netz nachgeladen werden. Die Bedingungen in vielen Museen sind nicht so, dass man sich auf Ordnerstrukturen verlassen könnte, oder als das das zusätzliche Installieren eines Interpreters nicht eine große zusätzliche Hürde darstellen würde.
Das Programm muss stabil sein. Im Idealfall sollte es einmal eingerichtet quasi unsichtbar im Hintergrund arbeiten.

Für die Wahl der Programmiersprache heißt das, dass es eine kompilierte Sprache brauchte, deren Compiler Cross-Compilation (also das Kompilieren von Programmen für ein Betriebssystem unter einem Anderen) unterstützt. Die Wahl fiel auf Go. Die Implementation gestaltete sich damit sehr angenehm, sodass die erste volle Release-Version jetzt zum Download zur Verfügung steht. Die Anwendung ist nach GPL 3 lizensiert, kann also frei weiterentwickelt werden (solange man die eigenen Anpassungen auch wieder teilt).

Unter anderem durch die Wahl der Programmiersprache tauchen aber an anderen Stellen Schwierigkeiten auf. Unter Linux läuft das Programm flüssig - unter Windows blockiert der Windows Defender SmartScreen die Benutzung. Und so eröffnet sich eine ganz neue Problemklasse.

Zur Abwehr von Malware blockiert der SmartScreen Anwendungen, die a) verdächtig aussehen, b) nicht von einer vertrauenswürdigen Stelle signiert sind und/oder c) noch keine breite Verwendung haben. Wie genau die verschiedenen Aspekte zusammenspielen ist nicht öffentlich bekannt.

Da das Programm neu ist, ist klar, dass es noch keine breite Benutzerbasis hat. Und mit seiner Zielgruppe und seinem Zweck wird es die wohl auch nie bekommen.

Dass Go-Programme von Microsoft als “verdächtig” eingeschätzt werden ist ein so bekanntes Problem, dass es dazu einen eigenen Eintrag im FAQ der Programmiersprache gibt. Auch daran scheint sich wenig ändern zu lassen.

Bleibt ein Zertifikat: Die zum Signieren von Programmen für Windows nötigen Zertifikate werden in einer Struktur ausgegeben, die sehr an die Vergabe von TLS-Zertifikaten vor 20 Jahren erinnert (und tatsächlich sind dabei dieselben Firmen vertreten). Man beantragt ein Zertifikat und wird kurz überprüft - je nach Art des Zertifikats muss man eine Kopie eines Ausweisdokuments einsenden oder Nachweisen, dass man eine seit mehreren Jahren registrierte Firma/Organisation ist. Dazu muss man - wieder unterschiedlich je nach Anbieter und Zertifikatstyp - einige hundert Dollar zahlen (z.B. hier). Dazu bieten alle außer dem “größten” Zertifikatstyp (EV) keine Garantie, dass die Warnungen damit vermieden werden können. Schon vor dem Hintergrund jedes einzelnen dieser Aspekte ist das Signieren der Anwendung keine Option. Falls jedoch jemand ein Zertifikat hat und zur Verfügung stellen möchte, wären wir darüber froh.

Einen Ausweg - oder zumindest einen Schritt dahin - könnte es doch geben. Microsoft bietet einen Service an, bei dem man sein Binary hochladen und sich über fälschliche Kategorisierungen beschweren kann. Um diesen zu nutzen braucht man einerseits ein Benutzerkonto (warum ist nicht ersichtlich, aber immerhin ist die Hürde gering), andererseits die Fehlermeldungen / Warnungen, über die man sich beschweren möchte. Und das heißt dann doch wieder, dass man einen Windows-Rechner braucht, um die richtigen Fehlercodes zu ermitteln. Cross-Compilation funktioniert heute also technisch eigentlich problemlos - eine cross-compilation tatsächlich nutzbarer und verteilbarer Programme bleibt schwierig.

So oder so führt wohl mittelfristig kein Weg an einer Meldung bei Microsoft vorbei. Ob das ausreicht, damit das Programm ohne Warnungen genutzt werden kann, bleibt unklar. Auch dazu hält sich Microsoft bedeckt, und es gibt verschiedene Erfahrungsberichte. Aber immerhin scheint es die wahrscheinlich zu erhöhen, dass es (zumindest innerhalb eines Releases) problemlos genutzt werden kann.

info

License

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

Stand der Entwicklung: Dezember 2024 und Januar 2025

2025-02-14T00:00:00+00:00

In Anbetracht mangelnder Zeit, hier einmal wieder ein kurz gehaltenes Change Log für Dezember 2024 und Januar 2025.

Dezember 2024

Frontend

Datumsangaben in Transkriptionen (TEI) werden geparst, unabhängig davon, ob when="" oder when='' genutzt wurde
Notizen zu Markierungen werden jetzt auf Objektseiten dargestellt
Das fehlte bisher und ist jetzt über ein Tooltip umgesetzt, das beim Überfahren der Markierung erscheint - analog zur Anzeige von Ereignis-Anmerkungen.

musdb

Namen und Beschreibungen von Ausstellungen und Objektgruppen können jetzt übersetzt werden
Versionierung
Log von “aktuellen Aufenthalten” eines Objektes kann als CSV-Datei exportiert werden
Hochgeladene Objekt-Abbildungen können nun stapelweise versteckt oder veröffentlicht werden (Umsetzung analog zu dem hier beschriebenen, nur eben im Bilder-Menü)
API erweitert
- (Neue Funktionen)
- Objekt-Maße übertragen
- Bilder und Resourcen zu einem Objekt auflisten
- Bild-Metadaten
- Objektbilder veröffentlichen / verstecken

Januar 2025

Frontend

Sortierung nach “Ästhetik” der Objekt-Thumbnails (Dazu folgt noch ein eigener Blog-Post)

musdb

Angleichung der maximalen Feldlänge für Notiz zu Öffnungszeiten ist jetzt konsistent durchgesetzt (UI vs. DB)
Problem beim Wechseln zwischen Institutionen bei Konsistenzchecks behoben
Literatur kann jetzt nach Herausgeber durchsucht werden
Stapelweises umschreiben aus einem Freitextfeld in ein anderes

Importer

Kern
- Automatische Transformation von Lebensdaten bei Akteuren
  - Todesjahr “01.01.2012” wird jetzt “2012”, statt wie bisher 01.01
- “?” und “(?)” werden vom Anfang und Ende von importierten Schlagworten entfernt
- Verschiedene Arten von Klammern in Schlagwortnamen werden zu regulären Klammern umgewandelt
Parser
- Striktere interne Umsetzung von Settings, alle Importe können jetzt das start_at-Setting umsetzen
  - Das ist vor allem für das wiederholte Durchführen von Importen, die wegen neuen, bisher noch nicht abgedeckten Elementen abbrechen, und sonstiges Debugging, wichtig.
- Neue Parser:
  - MODS (v.a. Bibliotheksdaten)
  - Parser für Exporte aus Faust für das Händel-Haus
  - Parser für XML-Dumps aus MuseumPlus Classic (MsSQL > XML-Export pro Tabelle > Import)
  - Bugfixes
    - Feld “Verwender” in Primus-Parser war auf Herstellungsereignisse gemappt
    - Material / Technik werden im Parser für BeeCollect-Exporte für die Industriemuseen Sachsen jetzt korrekt importiert
“Frontend”
- CLI hat jetzt auch Optionen für das Abschalten des Imports einzelner Bereiche
- Hilfe-Text für Kommandozeilen-Tool

nodac

Aufspaltung von Schlagworten erkennt jetzt auch Schlagworte, die in Orte, Zeiten, etc. aufgespalten werden sollten
- Bsp.: “Helm; Berlin” > Schlagwort “Helm” + Ort “Berlin”
Bei Suche nach Schlagworten mit zweideutigen Namen werden jetzt sowohl Schlagworte als auch allgemein zweideutige Begriffe berücksichtigt
Zeiten können jetzt direkt von der Zeit-Bearbeitungsseite aus mit anderen zusammengeführt werden

info

AI Use

Post image generated using AI.

info

License

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

750000!

2025-02-13T00:00:00+00:00

Mit leichter Verspätung hier eine frohe Nachricht: Seit vorgestern, 11.2.2025, sind mehr als 750.000 Objekte über museum-digital:deutschland publiziert!

info

License

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

Ein kleines Tool zur Konkordanzprüfung bei Importen

2025-01-23T00:00:00+00:00

Wenn man einen Import in museum-digital durchführt – insbesondere bei der Migration von Inventarisierungsdaten – besteht die Möglichkeit, dass Fehler aufgrund nicht übereinstimmender Einträge auftreten. Das Importtool stellt fest, dass versucht wurde, einen bisher noch unbekannten Wert in ein kontrolliertes Feld in Musdb zu importieren. Häufig treten Probleme etwa bei Akteursrollen und Eingangstypen auf.

Ein Beispiel: Die bisherige Datenbank eines Museums verwendete Akteurrollen statt einer Ereignisstruktur um auszudrücken wer ein Objekt erstellt hat. Das Museum hat entsprechend eingetragen, dass ein gegebenes Objekt Objekt einen verknüpften Akteur X hat, der als „Haupthersteller“ mit dem Objekt verknüpft ist, und eine verknüpfte Zeit Y, die als „Herstellungszeit“ gekennzeichnet ist. Beim Import werden diese Rollen („Haupthersteller“ und „Herstellungszeit“) dann in die Ereignistypen von museuem-digital übersetzt, um ein Ereignis zu bilden: Das Objekt wurde von Akteur X zum Zeitpunkt Y hergestellt. Dies funktioniert, weil die Begriffe „Haupthersteller“ und „Herstellungszeit“ dem Ereignistyp “Herstellung” zugeordnet sind.

Wenn einem Begriff noch kein entsprechender Wert einer kontrollierten Liste in museum-digital zugeordnet ist, bricht der Importer den Import beim ersten Auftauchen des Begriffs in einem der kontrollierten Felder schlicht ab. Einerseits ist das gut, um unnötigen Ressourcenaufwand für einen Import der ohnehin nicht abgeschlossen werden kann, zu sparen. Andererseits ist es mühsam. Noch nicht zugeordnete Einträge erkennt man so immer nur einzeln.

Ein kleines neues Tool

Ein kleines neues Tool, concordance.museum-digital.org, macht den Vorgang etwas weniger mühsam. Benutzer können alle Importdaten eines bestimmten Felds (z. B. der Schauspielerrollen) zeilenweise hochladen und prüfen, ob sie bereits in den Konkordanzlisten zugeordnet wurden oder nicht.

Für bisher nicht zugeordnete Einträge besteht nun die Möglichkeit, diese über die Oberfläche des Werkzeugs einem der bei museum-digital erlaubten Feldinhalte zuzuordnen und schlussendlich die Codezeilen zu generieren, die für eine Aufnahme in die Konkordanzlisten nötig sind.

Während das einfache Überprüfen und Erweitern der relevanten Open-Source-Listen auch für nicht technisch versierte Nutzer trivial sein sollte, ist dieser Weg sicherlich bequemer. Wichtig ist auch, dass der Import nicht mehr mehrmals ausgeführt werden muss, bis keine Fehler mehr auftreten, die durch nicht übereinstimmende Einträge verursacht werden. Und, nun ja, es ist sicherlich auch bequemer, Werte in normaler menschlicher Sprache abzugleichen, als die internen IDs der Zielwerte zur Bestimmung von Entsprechungen zu nutzen.

Der Code des Konkordanz-Prüfers kann, MIT-lizensiert, hier gefunden werden.

info

License

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

Stand der Entwicklung, November 2024: "Echte" getrennte Maßangaben und eine bessere Erkennung von Schlagworten, Orten, etc.

2025-01-13T00:00:00+00:00

musdb

Grundlegende Reimplementation der Erfassung von getrennten Maßangaben (Reiter “Zusatz”)
- Die Auswahl der Messgrößen (Breite, Länge, etc.) ist jetzt über eine kontrollierte Liste umgesetzt, die leicht erweitert werden kann. Auch abgestufte / spezifizierte Messgrößen können festgehalten werden (z.B. “Breite des Sockels”).
- Neu sind die Möglichkeit, die Exaktheit einer Messung und Notizen zu dieser Festzuhalten
Auswahl der “Räume” beim Festhalten eines aktuellen Aufenthalts eines Objektes ist jetzt alphabetisch sortiert
Eindeutige Identifikatoren für Beziehungen zwischen Schlagwort und Objekt werden erkannt und automatisch ausgewertet (“Apfel (Motiv)” –> “Apfel” + “Abgebildetes”)
Äquivalenz von Abgebildetes mit Dargestellter Person oder Dargestellter Ort ist jetzt in Autokorrekturen abgebildet (Berlin (Motiv) –> 1. Schlagwort wird zu Berlin + Abgebildetes –> 2. Berlin ist Ort –> Ereignis: Wurde abgebildet, wer: Berlin)

Screenshot der neuen Implementation der Sektion “getrennte Maßangaben” auf dem Reiter “Zusatz” von Objekt-Bearbeitungsseiten. Getrennte Maßangaben werden jetzt als wiederholbare Gruppe von Feldern angezeigt, bei denen eine Zeile eine Messung abbildet. Eine neue Messung kann über das “Plus”-Symbol (+) unten rechts hinzugefügt werden.

Frontend

Neue Implementation von getrennten Maßangaben ist auch hier umgesetzt

Import

Import von getrennten Maßangaben nutzt neu Implentation der getrennten Maßangaben (siehe musdb)
Eindeutige Identifikatoren für Beziehungen zwischen Schlagwort und Objekt werden erkannt und automatisch ausgewertet (Schlagwort: “Apfel (Motiv)” wird automatisch korrigiert zu Schlagwort: “Apfel” + Bezug zwischen Objekt und Schlagwort: “Abgebildetes”)
Äquivalenz von Abgebildetes mit Dargestellter Person oder Dargestellter Ort ist jetzt in Autokorrekturen abgebildet (“Berlin (Motiv)” –> 1. Schlagwort wird zu Berlin + Abgebildetes –> 2. Berlin ist Ort –> Ereignis: Wurde abgebildet (Ort), was: Berlin)
Verknüpfung von Objekt zu Objekt war bisher über Weblink, jetzt wird über den extra für Objekt-Objekt-Bezüge vorgesehenen Datentyp verknüpft (d.h.: Verknüpfte Objekte werden beim Veröffentlichen erst angezeigt, wenn beide Objekt-Datensätze sichtbar sind)

nodac

Beim Zusammenführen von zwei Vokabulareinträgen werden jetzt auch Ausstellungen, Sammlungen etc. in den verknüpften Instanzen berücksichtigt und umgeschrieben
- Bisher wurde schon auf deren Existenz geachtet. Ein Umschreiben war dabei jedoch nicht implementiert, sodass das Zusammenführen nicht vollständig durchgeführt werden konnte und weiterhin beide Einträge im Vokabular verblieben.
Ist ein Begriff als “Immer ein Schlagwort” markiert, so erscheint der Schalter “Diesen Eintrag ins Akteursvokabular transferieren” nicht mehr
Wenn zwischen Vokabularen verschoben wird, dann werden die Beziehungs- und Ereignistypen (Abgebildetes / Dargestellte Person / Dargestellter Ort) berücksichtigt und entsprechend umgeschrieben
- Ist bei einem Objekt etwa notiert, dass dieses das Schlagwort “Berlin” darstellt, wird beim Übertragen des Schlagworts “Berlin” in das Ortsvokabular aus dem Schlagwortbezug ein Bezug auf den “Abgebildeten Ort” “Berlin”.
Funktion “Begriff aufspalten” (Orte und Schlagworte) schlägt Ziele der Aufspaltung auf Basis der permanenten Umschreibungen vor
- Ist also etwa notiert, dass “Cöln” immer in “Köln” umgeschrieben werden soll, so erkennt das System automatisch, dass der Begriff “Cöln & Berlin” aufgespalten werden kann - in “Köln” und “Berlin”.
Kontextmenu in Übersichten (Rechtsklick auf einen Eintrag in der Tabelle) bietet direkten Zugriff auf verschiedene Funktionen

info

AI Use

Post image generated using AI.

tip

tip

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

Versionierung & Transfer zwischen Datenfeldern

2025-01-13T00:00:00+00:00

Das neue Jahr 2025 kommt mit zwei lange erwarteten neuen Features in musdb: Der detaillierten Versionierung von Objektdaten und einer Option zum stapelweisen Transferieren von Objektdaten aus einem Freitextfeld ins andere.

Versionierung

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

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

Die detaillierte Versionsgeschichte lässt sich über einen neuen Button ganz oben im Reiter “Datensatz” beim Bearbeiten eines Objektes öffnen.

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

Die Versionsgeschichte eines Objektes wird in einer Tabellenansicht im Overlay dargeboten. Bei einer Version im Vergleich zur vorherigen geänderte Werte sind gestrichelt umrahmt. Leere Zellen sind seitlich gestrichelt. Bei dem im Screenshot Dargestellten ist ganz oben die aktuellste Version zu sehen (leere Zelle beim Ende). Zwischen Zeile 2 und 3 wurde am 13.1.2025 um 8:04 Morgens das Wort "Portrait" dem Objektnamen hinzugefügt.

“Feldweise transferieren”

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

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

Ist ein Suchfilter für Objekte gesetzt, erscheinen rechts unten in der Seitenspalte verschiedene Optionen zum Export und zur Stapelverarbeitung. Neu dazugekommen ist die Option “Feldweise transferieren” ganz unten in der Liste.

Screenshot der neuen Option zum stapelweisen Transferieren von Objektdaten aus einem Freitextfeld zu einem anderen. Neben den Freitextfeldern zum Objekt können die beiden “Sonderquellen” “getrennte Maßangaben” und “getrennte Angaben: Material und Technik” ausgwählt werden, wie hier im Screenshot. Bei Feldweisen Transferieren kann in der Folge der Text im Zielfeld durch den Text aus dem Quell-Feld überschrieben werden, oder letzterer vor oder nach dem bisherigen Feldinhalt eingefügt werden.

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

tip

tip

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

Stand der Entwicklung Oktober 2024: Suche nach derzeit ausgestellten Objekten, Verknüpfung von Räumen und Erwerbungen zu Literatur

2024-11-05T00:00:00+00:00

Nachdem es in diesem Jahr hier im Blog sehr ruhig bezüglich der technischen Entwicklung von museum-digital war, versuchen wir ab jetzt die eh für die monatlich durchgeführten “Regionaladministratoren”-Runden erstellten Zusammenfassungen zu neuen Entwicklungen - durch Screenshots angereichert - hier zu veröffentlichen.

Diese sind in Form von Auflistungen gehalten, und so soll es nun auch hier sein.

Frontend

Features & Verbesserungen

Einige Verbesserungen bei Hintergrundscripten, v.a. besseres Handling von Timeouts beim Errechnen der “Ähnlichen Objekte” in sehr großen Instanzen
Beitragende, verknüpfte Orte und Zeiten zu einer Objektgruppe werden jetzt alphabetisch nach Namen sortiert aufgelistet
Tabellenköpfe für Ereignis-Komponenten (wer, wann, wo) werden im A4-PDF nur noch angezeigt, wenn auch Inhalt für die Zeile vorhanden ist
Neue Suchoption für Objektsuchen: “Ist derzeit ausgestellt”
Links zum Themator nutzen jetzt das neue URL-Schema des Themators
(https://themator.museum-digital.de/t/690 statt https://themator.museum-digital.de/ausgabe/showthema.php?m_tid=690&tid=690)

Die neue Filteroption “Derzeit ausgestellt” im Overlay für die erweiterte Suche nach Objekten im Frontend von museum-digital.

Die Mitwirkenden einer Objektgruppe werden jetzt alphabetisch nach Namen sortiert angezeigt.

Bugfixes

Fehler beim Suchen nach kontrollierten Listen-Begriffen, die mehrere Leerzeichen beinhalteten, über das “Suche verfeinern”-Overlay (Suche nach Lizenz “Public Domain Mark”)
Exaktheits-Einstellung im “Suche verfeinern”-Overlay wurde nicht übertragen
Einfache Einbettung eines Objektes (analog z.B. zu Youtube-Videos; erreichbar über das “Zitieren”-Menü einer Objektseite) hatte diverse Fehler / funktioniert jetzt wieder

musdb

Features & Verbesserungen

In der API-Dokumentation von musdb gibt es jetzt einen Hinweis, dass auch das Frontend eine API hat
- Frontend-API
  - Für die Nutzung der API des Frontends muss man sich nicht authentifizieren
  - Die API des Frontends ist tendenziell schneller und einfacher zu nutzen
  - Ist nur lesend
- musdb-API
  - Kann mehr: Kann auch nicht öffentliche Bestände und Felder / Datentypen sehen
  - Ist sehr viel feingliedriger (mehr Aufrufe für dieselben Daten, dafür bekommt man ggfs. genau die Daten, nach denen man sucht, statt gleich das ganze Objekt)
  - Kann schreiben
Vorschlagslisten bei Suche nach Vokabularbegriffen in der Seitenspalte der Objekt-Suchseite überarbeitet
- Tooltips erscheinen beim Überfahren
- Implementation in Vanilla JS, ausbauen von jQuery
  (das bedeutet eine deutlich bessere Performance der Suchergebnisliste im Listenformat, weil jQuery nicht mehr geladen werden muss)

Die Vorschlagslisten für Orte, Zeiten, Personen und Schlagworte in der Schnellsuche der Objekt-Suchmaske wurden “unter der Haube” grundsätzlich überarbeitet. Sichtbarer Gewinn ist vor allem, dass jetzt Erläuterungen direkt beim Überfahren der Begriffe aus der Liste erscheinen.

Benutzerseite / Login
- Log der Logins jetzt auch mit IP und User-Agents
- Login per im Browser persistierten Login (“Remember me”) wird geloggt und angezeigt
- Alle per Cookie dauerhaft eingeloggten Browser werden nach Passwortwechsel zu einem neuen Login gezwungen
- Neue Option, um alle gemerkten Logins auf anderen Geräten zu invalidieren (Browser muss neu eingeloggt werden

Über das “Login log” in den Kontoeinstellungen lässt sich nachvollziehen, wann und in welchem Zusammenhang auf das eigene Benutzerkonto in musdb zugegriffen wurde. So lassen sich etwa Übernahmen des Kontos durch Dritte erkennen. Neu angezeigt werden die beim Login verwendete IP-Adresse, der User-Agent (Kennung des Browsers) sowie, ob der Browser über ein dauerhaftes Login-Cookie automatisch eingeloggt wurde (“Remember me”).

Ein neuer Button in der Toolbar der Kontoeinstellungen in musdb erlaubt das ausloggen aller dauerhaft eingeloggten Browser / Geräte aus dem eigenen Konto.

Objekt
- Mehr Restriktionen für Publikation von Objektdatensätzen.
  Es kann nicht mehr veröffentlicht werden, wenn:
  - … der Objektname der Objektbeschreibung gleicht
  - … die Beschreibung die Zeichenkette “lorem ipsum” beinhaltet
- Beim Depublizieren / Verstecken von Objektdatensätzen werden die mit dem Bild verknüpften Abbildungen umbenannt (und so Links zu den Bildern invalidiert). Beim erneuten Publizieren wird das rückgängig gemacht, sodass die Links wieder funktionieren.
- Räume werden jetzt beim Verknüpfen als eigentlicher Standort alphabetisch aufgelistet
Literatur
- Erwerbungen können jetzt mit Literatur verknüpft werden
  - Darüber z.B. auch Vorbesitzer etc.
- Räume (eigentlicher Standort) können mit Literatur verknüpft werden

Über den neuen Reiter “Verwaltung” auf der Literatur-Bearbeitungsseite lassen sich Standort und Zugangszusammenhang des Literatureintrags verknüpfen. Dies kann nützlich sein, falls das Literaturmodul auch zum Verwalten der Museumsbibliothek verwendet wird.

Bugfixes

Overlay zur Einstellung von Suchen nach Objekten: Mehrwortige Suchbegriffe wurden in mehrere Suchen umgewandelt, statt als Kette von Worten gesucht zu werden (“roter Helm” > “roter” UND “Helm” statt “roter Helm”)
Fehler beim Suchen nach kontrollierten Listen-Begriffen, die mehrere Leerzeichen beinhalteten, über das “Suche verfeinern”-Overlay (Suche nach Lizenz “Public Domain Mark”)

Importer

Verknüpfung zwischen Literatur und Räumen (eigentlicher Standort) sowie Erwerbungen ist im Kern implementiert
ImageByInvno-Parser (Zuordnung von Abbildungen zu Objekten per im Dateinamen enthaltenen Inventarnummern) kann jetzt auch PDFs importieren

files.museum-digital.org

Kleines Script hinzugefügt, um PDF-Metadaten auf Basis einer kleinen XML-Datei zu setzen. Siehe z.B.: https://files.museum-digital.org/de/Praesentationen/2024-10-18_md-deutschland-eV-stellt-sich-vor_Usertreffen_MA.xml

info

AI Use

Post image generated using illustriousXL_smoothftSPO.

tip

tip

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

Einladung zur museum-digital Usertagung 2024

2024-09-09T00:00:00+00:00

Der museum-digital Deutschland e.V. veranstaltet am 18. Oktober 2024 zum zweiten Mal eine bundesweite museum-digital Usertagung. Sie richtet sich an alle Nutzer:innen von museum-digital. Aber auch Interessierte, die bisher noch nicht mit museum-digital arbeiten sind herzlich eingeladen. Es wird Informationen zu den Neuerungen bei museum-digital geben sowie Projektberichte von aktiven Usern. Die Veranstaltung ist kostenfrei und findet online statt. Im Anschluss findet die Mitgliederversammlung für die Mitglieder des Vereins statt. Die Usertagung bietet eine Plattform, bei der Museen ihre Arbeit mit museum-digital vorstellen und sich austauschen können.

Anmeldung Bitte melden Sie sich an unter: https://verein.museum-digital.de/anmeldung/

Programm

9.30 Begrüßung & Einführung

Der Verein museum-digital stellt sich vor Miriam Anders, Museumsverband Rheinland-Pfalz & Arne Lindemann, Museumsverband Brandenburg

9.45 Nutzungsmöglichkeiten von museum-digital

Von Ahnenforschung bis Zeitungsartikel: Museum-digital als Ausgangspunkt für Kooperationen und Recherchen, ein Überblick Anne-Katrin Koch, Museumsverband Rheinland-Pfalz & Sarah Wassermann, Museumsverband Brandenburg

VORLÄUFIGER TITEL: Der Einsatz von museum-digital im FHXB Friedrichshain-Kreuzberg Museum Jana König & Teresa Schenk*,* FHXB Friedrichshain-Kreuzberg Museum

10.30 Das neue museum-digital Frontend und Ausblick Joshua R. Enslin, Freies Deutsches Hochstift, Hessen

11.00 Pause

11.15 Projektvorstellungen

Neue Biographien auf dem Berlin-Brandenburgischen Künstlerlexikon Iris Berndt, Berlin-Brandenburgisches Künstlerlexikon

Brandenburg-sammelt: eine regionale Sammlungsseite mit Hilfe der museum-digital-Schnittstelle – die Umsetzung Sarah Wassermann, Museumsverband Brandenburg

3D-Modelle als Medienobjekte in museum-digital einbinden
Marleen Schindler, Sorbisches Institut / Museum Sorbische Webstube Drebkau

12.00 Möglichkeiten der Datenmigration

Voraussetzungen für den Datentransfer von Primus zu museum-digital
Susanne Opfermann, Landesstelle für Museen Baden-Württemberg

VORLÄUFIGER TITEL: museum-digital als Onlinekatalog
Noreen Klingspor, Landesmuseum Württemberg

Datenmigration zu museum-digital im Alliiertenmuseum. Ein Erfahrungsbericht
Florian Pauls, Alliiertenmuseum Berlin

13.00 Verabschiedung

Wer benutzt eigentlich musdb? Und wofür genau?

2024-06-16T00:00:00+00:00

In seiner zuletzt ausgewerteten und veröffentlichten Umfrage fragte das Institut für Museumsforschung (Berlin) Museen in Deutschland, ob sie kontrollierte Vokabulare und Normdaten verwenden. 416 der 3059 Museen, die den Zusatzfragebogen mit dieser Frage beantwortet haben, gaben an, dass sie Normdaten verwenden. Die Umfrage wurde 2021 durchgeführt.

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

Etwas stimmt sichtbar nicht mit unseren Zahlen.

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

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

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

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

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

Eine Kleine Umfrage

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

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

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

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

Wofür werden die Daten verwendet?

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

info

License

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

Server-Fehler am 6.3.2024

2024-03-06T00:00:00+00:00

Am 6.3.2024 zwischen 9:54 und 10:34 war museum-digitals zentraler Server aufgrund eines Fehlers bei den Switches im Rechenzentrum unseres Hosters, Hetzner, nicht zu erreichen. Details zum Vorfall können bei Hetzner nachvollzogen werden.

Um 10:34 war der Fehler durch die Techniker im Rechenzentrum erkannt und behoben. Folgefehler bei anderen Systemen von museum-digital aufgrund der Unerreichbarkeit traten nicht auf, sodass jetzt alle Systeme wieder voll funktional und erreichbar sind.

Während die Netzwerktechnik beim Hosting-Provider außerhalb unseres Einflussbereiches steht, gibt es eine Reihe von Möglichkeiten, die aus vergleichbaren Fehlern entstehenden Probleme zu reduzieren, etwa durch das redundante Vorhalten von Servern um im Notfall auf ein Hosting anderswo wechseln zu können, oder zumindest die Nutzung eines vorgeschalteten Cache-Servers, mit dem häufiger abgerufene, öffentliche Seiten weiterhin erreichbar blieben. Wir werden diese genauer evaluieren um in Zukunft vergleichbaren Problemen schneller begegnen und die daraus erwachsenden Schäden eingrenzen zu können.

Re-Design des Frontends - Version 2024

2024-01-08T00:00:00+00:00

In der Nacht von Dienstag auf Mittwoch verteilen wir ein großes Re-Design des Frontends. Mehr zu den Hintergründen zu lesen und Screenshots zu sehen gibt es hier im Blog auf English.

museum-digital:qa für XML-Konvertierungen

2024-01-07T00:00:00+00:00

Vor einigen Monaten habe ich museum-digital:qa hier und anderswo als ein Tool vorgestellt, das zentrale Funktionalitäten des Importtools von Museum-Digital nutzt und umfunktioniert, um von beliebigen Benutzern hochgeladene Daten auszuwerten und dem Uploader die auch musdb vorhandenen Qualitätsprüfungen zur Verfügung zu stellen - ganz unabhängig vom genutzten Sammlungsverwaltungssystem. Das wirkliche Potenzial des Tools zeigt sich hingegen erst, wenn man nur den ersten Teil dieser Aussage für sich genommen betrachtet: museum-digital:qa kann Daten aus jedem Format auswerten, das auch für den Import in Museum-Digital verwendet werden kann, um etwas mit den Daten zu machen. Qualitätsprüfungen sind in diesem Sinne nur eine Einsatzmöglichkeit von museum-digital:qa.

Ausgehend von diesem Hintergrund gibt es nun einen zweiten Anwendungsfall für museum-digital:qa: Es kann nun als Werkzeug zum Konvertieren eingesetzt werden. Wie gewohnt können die meisten für den Import in museum-digital unterstützten Formate zum Hochladen von Daten verwendet werden – z.B. eine einfache CSV-Struktur, die wir regelmäßig zum Importieren von Daten verwenden, die zuvor in Tabellenkalkulationsprogrammen gehalten waren – die dann in diejenigen XML-Formate konvertiert werden, in die Benutzer ihre Objektdaten in musdb exportieren können (wobei wiederum Code aus musdb nachgenutzt wird).

Derzeit werden das Konvertieren nach LIDO (beide Versionen 1.0 und 1.1) und EODEM unterstützt. Vor allem Letzteres könnte interessant sein: EODEM ist eine kürzlich veröffentlichte Erweiterung von LIDO, die einen deutlich vereinfachten Datenaustausch zwischen verschiedenen Institutionen im Rahmen von Leihverkehren ermöglichen soll. Das ausleihende Museum exportiert die Daten der für den Leihverkehr relevanten Objekte aus seinem Sammlungsverwaltungssystem in EODEM; das leihende Museum importiert es dann und hat sofort alle relevanten Informationen in seinem jeweiligen Sammlungsmanagementsystem - ohne dass die Daten, wie bisher oft üblich, von Hand abgeschrieben werden müssen. Der Nutzen von EODEM in der Praxis hängt jedoch davon ab, inwieweit es von den verschiedenen Sammlungsverwaltungssystemen unterstützt wird.

Inden es eine Möglichkeit zur Konversion aus vielen Formaten hin zu EODEM bietet kann museum-digital:qa also hoffentlich dazu beitragen, die Vorteile von EODEM auch solchen Museen zugänglich zu machen, deren Sammlungsmanagementsoftware den Export in den Standard noch nicht unterstützt.

info

Image Credits

Bell Telelphone crew with a dog*, ca. 1892

info

License

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

Eine Million Objekte mit museum-digital veröffentlicht

2023-11-19T00:00:00+00:00

Seit gestern sind mehr als eine million Objekte von Museen weltweit über museum-digital veröffentlicht. Herzlichen Glückwunsch und vielen Dank an alle, die das möglich gemacht haben!

Alle diese Objekte können gemeinsam über museum-digital:global abgerufen und durchsucht werden.

Datenqualitäts-Checks wie in musdb: Jetzt für alle

2023-10-12T00:00:00+00:00

Auf der gestrigen Herbsttagung der Fachgruppe Dokumentation des Deutschen Museumsbunds wurde ein neuer Webservice aus dem Umkreis museum-digital vorgestellt: museum-digital:qa.

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

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

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

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

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

info

License

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

EODEM Version 1.0 veröffentlicht

2023-09-04T00:00:00+00:00

Die jahrelangen Arbeiten am EODEM-Standard haben Früchte getragen: Seit dem 1.9.2023 ist die erste stabile Version, Version 1.0. von EODEM offiziell released. EODEM ist als LIDO-Profil implementiert und erleichert Museen den Austausch von Objektdaten untereinander - besonders im Kontext von Leihverkehren. Herzlichen Glückwunsch!

museum-digital:musdb unterstützt EODEM seit Februar, aber es wird umso nützlicher, je mehr andere Sammlungsmanagementsysteme den Standard unterstüzen. Passend zum Release der Version 1.0 unterstützt jetzt auch museumPlus EODEM, sodass Objektdaten einfach mit Partnerinstitutionen, die museumPlus nutzen, ausgetauscht werden können.

Mehr zu EODEM kann man auf der Seite des Projektes lesen.

info

License

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

Erste museum-digital User-Tagung des museum-digital Deutschland e.V.

2023-09-01T00:00:00+00:00

Im Oktober 2021 wurde der museum-digital Deutschland e.V. gegründet. Dieser veranstaltet am 17.10.2023 seine erste Tagung mit anschließendem Mitgliedertreffen.

Hier die Ankündigung der Veranstaltung von Seiten des Vereins:

Der museum-digital Deutschland e.V. veranstaltet die erste landesweite museum-digital Usertagung. Sie richtet sich an alle museum-digital User. Aber auch Interessierte, die bisher noch nicht mit museum-digital arbeiten sind herzlich eingeladen. Es wird Informationen zum aktuellen Stand von museum-digital geben sowie Projektberichte von aktiven Usern. Die Veranstaltung ist kostenlos und findet online statt. Im Anschluss wird es eine Mitgliederversammlung für die Mitglieder des Vereins geben. Die Usertagung soll in Zukunft regelmäßig eine Plattform bieten, bei der Nutzerinnen und Nutzer Projekte vorstellen und sich austauschen können.

Anmeldung Bitte melden Sie sich an unter: https://verein.museum-digital.de/anmeldung/

Programm

Moderation: Andrej Quade, Museumsverband Mecklenburg-Vorpommern

9.30 Begrüßung & Einführung

Wo kommen wir her, wo wollen wir hin? Eine kurze Geschichte zu museum-digital und die Gründung des Vereins
Miriam Anders, Museumsverband Rheinland-Pfalz & Dr. Arne Lindemann, Museumsverband Brandenburg

10.00 Aktuelles & Wissenswertes

museum-digital in Zahlen & Fakten
Anne-Katrin Koch, Museumsverband Rheinland-Pfalz und Dr. Sarah Wassermann, Museumsverband Brandenburg

Wie kann ich museum-digital für statistische Auswertungen nutzen? Dr. Stefan Rohde-Enslin, Institut für Museumsforschung, Berlin

„Fürst Pückler richtet sich ein“- md:story als Ausgangspunkt für eine gelungene Kooperation zwischen Uni und Museum Dr. Simone Neuhäuser, Stiftung Fürst-Pückler-Museum Park und Schloss Branitz, Prof. Dr. Nadja Horsch, Fachbereich Kunstgeschichte, Universität Leipzig

11.00 Pause

11.15 Projektbeispiele & Anwendungsmöglichkeiten

Eine Erlebnis App für das Schloss Wernigerode. Vorstellung einer Web-App basierend auf TYPO3, die dynamisch Objekte aus museum-digital in Raumzeichnungen erlebbar macht Christoph Wetzel/Daniel Frey, Schloss Wernigerode, Sachsen-Anhalt

Übersetzung von museum-digital ins Französische anhand der Oberrheinsammlung
Herr Dr. Ludgar Tekampe, Historisches Museum Speyer, Rheinland-Pfalz

Ein Portal für das museale Kulturerbe in Brandenburg über die museum-digital API Dr. Sarah Wassermann, Museumsverband Brandenburg

12.00 Neuerungen & Visionen Joshua R. Enslin, Freies Deutsches Hochstift, Hessen

12.30 Fragen & Austausch

13.00 Verabschiedung

Mehr unter: https://verein.museum-digital.de/event/erste-museum-digital-user-tagung/

API-Dokumentation für md:term und die "Ausgabe" von museum-digital

2023-08-17T00:00:00+00:00

md:term wurde um seine Schnittstellen gebaut. Die “Ausgabe” von museum-digital unterstützt eine vollwertige API, über die alles, was auch über die HTML-Ansicht abrufbar ist, maschinenlesbar abgerufen werden kann, seit knapp 2016. Zu einer vollständigen und vor allem systematischen Dokumentation der API hatten wir es aber bis jetzt nicht geschafft. Seit heute ist das anders: Nun stehen für beide Programme OpenAPI-Definitionen zur Verfügung.

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

Die Dokumentation kann hier abgerufen werden:

md:term
frontend (via the global portal)

info

License

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

Vereinfachter Workflow für die Arbeit mit Leihobjekten mit EODEM

2023-06-04T00:00:00+00:00

Seit einigen Monaten unterstützt musdb den EODEM-Standard zum Austausch von Objektinformationen im Rahmen von Leihverkehren. Die grundlegenden Entwicklungen dafür wurden bereits ausführlich in einem vorherigen Blogbeitrag behandelt. Zusammenfassend lässt sich sagen, dass der EODEM-Standard ein erhebliches Potenzial birgt, Kollegen, die sich mit Leihverkehren im Museum auseinandersetzen, viel Zeit und Arbeit zu ersparen, indem er eine nahtlose Interoperabilität von Objektinformationen zwischen verschiedenen Sammlungsverwaltungssystemen ermöglicht.

Der Erfolg und die weitere Verbreitung von EODEM hängen aber weiter von zwei kritischen Faktoren ab. Einerseits müssen Entwickler und Softwareanbieter EODEM-Import- und Exporttools in ihren Sammlungsverwaltungssystemen implementieren. Andererseits müssen die entsprechenden Funktionen zugänglich und einfach zu genug zu verwenden sein, dass sie auch tatsächlich genutzt werden.

musdb deckt die erste Bedingung wie gesagt bereits seit einigen Monaten ab. Die Zugänglichkeit aber war sicher – insbesondere für kleinere Museen mit weniger technisch versiertem Personal – noch ausbaufähig. Im letzten Monat haben wir daran gearbeitet, sie zu verbessern. Mittlerweile ist es möglich EODEM-Daten sowohl zu exportieren als auch zu importieren, ohne dass es spezielle Software abseits des Dateimanagers und eines Browser bräuchte. verwendet werden muss.

EODEM-Daten exportieren

Der Export von EODEM-Daten (v.a. bei ausgehenden Leihverkehren) ist im oben verlinkten Beitrag ausführlich beschrieben und war schon damals recht leicht zu benutzen. Sind die Objekte in musdb mit dem gegebenen Leihverkehr verknüpft, erscheint in der Seitenspalte links auf der Seite des Leihverkehrs ein Export-Button spezifisch für den Export der Objektdaten in EODEM.

Der einfachste Weg Leihobjekt-Informationen in EODEM zu exportieren ist, zur Seite eines Leihverkehrs zu navigieren. Hier kann man die Daten links in der Seitenspalte über “Objekte (EODEM)” exportieren.

Einfach importieren?

Das Importtool von Museum-Digital bietet eine große Auswahl an auswählbaren „Parsern“ (im Wesentlichen Formaten der zu importierenden Daten) und Einstellungen für viele davon. Es mag zum Importieren von fünf Objekten ohne verknüpfte Bilddateien oder von 50000 Objekten mit extern gespeicherten Bilddateien, die während des Imports heruntergeladen werden müssen, verwendet werden. Während der Import im ersten Fall in wenigen Sekunden abgeschlossen ist, kann letzterer abhängig von der Geschwindigkeit des externen Bild-Servers Stunden dauern.

Um Zeitüberschreitungen zu vermeiden und Benutzern die volle Flexibilität des Importers zu bieten - und dazu eine einfache Automatisierung zu ermöglichen -, funktioniert der Upload-Workflow bei Importen über das WebDAV-Protokoll. Hiermit wird der Import in einer Klartext-Konfigurationsdatei konfiguriert und die Importdaten können in entsprechende Ordner für Metadaten und Mediendateien hochgeladen werden. Abschließend prüft ein Skript alle vier Stunden, ob im jeweiligen Verzeichnis für ein Museum Importdaten vorhanden sind und importiert diese im Hintergrund. Dieser Prozess funktioniert hervorragend für große Importe und Migrationen. Für kleinere Importe ist er aber doch alles andere als zugänglich.

Da EODEM-Importe einem vordefinierten Standard folgen und einen klar umrissenen Anwendungsfall haben, konnten wir ein direktes Upload-Formular für EODEM-Importdaten direkt in der Seitenspalte der Bearbeitungsseite von Leihverkehren einbauen. Hier findet sich jetzt eine neue Upload-Box „EODEM-Daten importieren“. Klickt man darauf öffnet sich ein Overlay, mit dem die EODEM-XML-Dateien hochgeladen werden können. Anschließend werden die XML-Dateien in das übliche Importverzeichnis des Museums hochgeladen und die Konfiguration automatisch mit den gängigen Einstellungen für EODEM-Importe geschrieben.

Links in der Seitenspalte der Leihverkehrs-Bearbeitungsseite findet sich ein neuer Menüpunkt. Über dieses Feld lassen sich EODEM-Daten direkt über die Web-Oberfläche importieren.

Das Upload-Feld in der Seitenleiste ist nun aktualisiert und zeigt eine Meldung mit Einzelheiten zum verbleibenden Arbeitsablauf an: Man muss nur noch warten, bis die Importdaten verarbeitet wurden. Nach Abschluss des Imports erhält man eine E-Mail an die für das eigene musdb-Konto angegebene E-Mail-Adresse.

Wenn man nun sich die importierten Objektdaten ansieht, erkennt man schnell die Auswirkungen einer kleinen neuen Funktion. Der Importer bestimmt automatisch anhand der Inventarnummer, ob er Objekte aktualisieren oder neue hinzufügen soll. Wenn zwei Museen das gleiche Inventarnummernschema verwenden, könnte es damit dazu kommen, dass die Leihobjektinformationen die Daten eines anderen Objekts im Museum überschreiben. Um solche Fälle – so selten sie auch sein mögen – zu verhindern, wird der Inventarnummer des Leihobjekts automatisch die ID der Leihgabe vorangestellt.

EODEM-Importe können somit jetzt direkt über die Weboberfläche und mit minimaler Gefahr von Datenverlusten durch fälschliches Updaten durchgeführt werden. Die einzige Einschränkung besteht darin, dass auf diese Weise durchgeführte EODEM-Importe den Import von Objekt-Abbildungen nicht unterstützen, da hierfür eine zusätzliche Einstellung erforderlich gewesen wäre, um festzustellen, ob die Bilder zusammen mit den Importmetadaten gesendet wurden oder sich auf einem über das Internet zugänglichen Verzeichnis befinden Server - oder ob sie schlicht fehlen.

Ein Blick in die Zukunft

musdb deckt nun beides ab – EODEM-Importe und -Exporte sind nicht nur mehr implementiert und nutzbar, sondern sie sind mittlerweile hoffentlich auch sehr einfach zu nutzen. Die EODEM-Arbeitsgruppe steht weiterhin kurz vor der Veröffentlichung des endgültigen Standards und weitere Implementierungen sind für die kommenden Versionen einiger weiterer Sammlungsmanagementsysteme angekündigt.

Es ist wahrscheinlich, dass das Testen des EODEM-Imports mit realen Daten aus anderen Systemen aller Standardisierung zum Trotz noch einige weitere Anpassungen erfordern wird. Wir freuen uns auf solche Fälle und auf mehr Nutzer des EODEM-Standards, sowohl im Hinblick auf die Anbieter, die ihn unterstützen, als auch auf die tatsächlichen Museen, die davon profitieren können.

info

License

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

nodac auf YouTube vorgestellt

2023-04-01T00:00:00+00:00

Eine der größten Stärken von museum-digital ist es, dass die kontrollierten Vokabulare von allen vertretenen Museen zusammen benutzt (und erweitert) werden. So können diese zentral angereichert und z.B. auf Dubletten geprüft werden. Das spart an vielen Punkten doppelte Arbeit, führt zu einer verbesserten Interoperabilität und erlaubt ein allgemein höheres Niveau an Anreicherung als wenn ein Museum die Arbeit allein machte. Dazu ermöglicht es auch kleinen Museen die Verknüpfung ihrer Objekte mit Normdateien ohne sich in der wenigen verfügbaren Zeit mit den dahinterliegenden Konzepten beschäftigen zu müssen.

Durch die Zentralisierung wird die Terminologie-Arbeit aber eben auch ein versteckt. Hin und wieder berichten wir in Vorträgen oder hier im Blog aus der Vokabular-Arbeit oder nodac, dem Tool, mit dem die “Normdatenredaktion” die Vokabulare kontrolliert. Neben einigen Vortragsfolien im Dokumentenarchiv und einer Seite auf der allgemeinen Vorstellungsseite ist es aber recht schwer, weitere Informationen zur Arbeit der Normdatenredaktion und zu nodac zu finden.

Um etwas Licht ins Dunkel zu bringen, wird in den nächsten Tagen auf dem frisch eröffneten Youtube-Channel eine kleine Reihe von fünf Screencasts veröffentlicht, die nodac vorstellen. Der Fokus liegt dabei klar auf nodac als Werkzeug. Weil nodac aber auf Basis der Bedarfe der Normdatenredaktion entsteht, wird diese zwangsläufig auch ein wenig vorgestellt.

Die Videos erscheinen ab heute (1.4.2023) mit einem Abstand von zwei Tagen. Wer also alle fünf in einem Rutsch gucken möchte, muss sich damit noch bis zum 9. gedulden. An alle anderen, wie man so sagt: Like and subscribe.

https://www.youtube.com/playlist?list=PLlwIIHnjvD4fRhTJR-5xLe-NG-C_rVEhA

Detailverbesserungen bei der Objektsuche in musdb

2023-03-21T00:00:00+00:00

In der vergangenen Woche gab es ein sehr produktives Treffen zur Objektsuche in musdb mit Kollegen aus Ungarn. Besonders ging es um die Verbesserungen des User Interfaces. Nach dem Sprechen kommt bekanntlich das Machen, und so folgten bald die entsprechenden technischen Anpassungen.

Auch wenn es sich um Detailverbesserungen handelt, ist sind die Funktionen der Objekt-Übersichtsseite jetzt merklich einfacher zu nutzen und in ihrer Intention klarer erkennbar. Zusätzlich konnten wir für viele Museen ein lange vermisstes Feature einführen.

Deutlichere Beschriftungen

Die sichtbarste Änderung ist sicherlich die deutlich sichtbarere Beschriftung der Buttons der Suchseite. Bisher waren viele dieser Buttons nur über das HTML-Title-Attribut beschriftet. Damit erschienen beschreibende Tooltips, wenn man länger mit dem Mauszeiger über einem Element verweilte. Real führen Title-Attribute leider aber bei den meisten Nutzern schlicht dazu, dass die Beschriftungen übersehen werden.

Stattdessen erscheinen jetzt deutlich sichtbarere Tooltips, die auf die über die jeweiligen Elemente erreichbaren Funktionen hinweisen. Diese selbst implementierten Tooltips ermöglichen auch eine Differenzierung zwischen Überschrift und weiteren Ausführungen, sodass - wo sinnvoll - weitergehende Anleitungen eingefügt werden können.

Fährt man in musdb über einen Button auf der Seite für die Objektsuche, erscheint sofort ein Tooltip mit einer Beschriftung der Funktion und ggfs. weiteren Tipps.

Im Gegensatz zu den standardisierten Title-Attributen sind selbst implementierte Tooltips leider nicht von sich aus Barrierefrei. Das Script zur Anzeige der Tooltips setzt stattdessen das alternative und gezielt auf die Barrierefreiheit ausgerichtete aria-label-Attribut, sodass die Feldbeschriftung auch für Screenreader und andere Hilfsmittel lesbar ist.

Schnelle Sucheinstiege sind nur Einstiege

Früher war die Einstellung von Parametern für die Objektsuche in musdb primär über die Seitenspalte der Seite durchführbar. Darüber ließen und lassen sich die wichtigsten Attribute eines Objektes durchsuchen: Sammlung, ggfs. Objektgruppen und Ausstellungen, und die Bezüge zu Personen, Orten, Zeiten und Schlagworten. Mit der grundlegenden Überarbeitung der Suchfunktion Anfang 2022 kam eine neue Leiste zur Seite hinzu, über die deutlich detaillierter - und in hunderten weiteren Feldern - gesucht werden kann (“Suche verfeinern”).

Der vormals präferierte Bereich für die Einstellung von Suchparametern wurde damit zu einer Liste von Schnelleinstiegen. Da er aber nach wie vor prominent ist, ist es fast zu erwarten, dass die deutlich mächtigere Suchleiste darüber hin und wieder übersehen wird. Und das gerade weil man mit den Schnell-Einstiegen in der Seitenspalte schon sehr weit kommt.

Um neben den neuen Tooltips noch einmal darauf hinzuweisen, dass man auch die Suchleiste benutzen kann, und das diese die “primäre” Suchfunktion darstellt, gibt es jetzt Überschriften in der Seitenspalte. Der Bereich für die Schnelleinstiege ist angemessen mit “Schnelle Sucheinstiege” betitelt, während auch der Bereich für Exporte und Stapelverarbeitung eine Überschrift bekommen hat.

Die Überschrift “Schnelle Sucheinstiege” ordnet die Suchfunktionen der Seitenspalte ein.

Neue Such- und Sortieroption

Inventarnummern stellen immer wieder ein logisches Problem dar. Denn Inventarnummern sind genau genommen im Regelfall keine Nummern. Eine Inventarnummer wie “Hs-16231” beinhaltet eine Nummer (“16231”), aber eben auch noch einen nicht numerischen Präfix (“Hs-”). Damit lässt sich Hs-16231 in einer Datenbank nicht in einem Zahlenfeld speichern.

Was nach einem technischen Detail klingt hat reale Auswirkungen. Möchte man etwa eine Suchabfrage nach allen Inventarnummern zwischen “Hs-16200” und der “Hs-16300” definieren, so ist das mit Text-Feldern nicht (oder nicht zuverlässig) möglich. Genauso wird bei Zahlenfeldern “Hs-2” hinter und nicht vor “Hs-16231” sortiert. Um diese Such- und Sortieroptionen anbieten zu können braucht es Zahlenfelder.

Bestärkt durch das Gespräch mit den ungarischen Kollegen haben wir beschlossen, eine Konversion der Inventarnummern zu Zahlen zu implementieren, sodass die oben beschriebenen Such- und Sortieroptionen durchführbar werden. Dazu werden aus der Inventarnummer einfach alle nicht-numerischen Zeichen entfernt und die so ermittelte Zahl in ein zusätzliches Zahlenfeld im Suchindex gespeichert.

Dadurch ist die Funktion nur für Museen sinnvoll nutzbar, die in ihrem Inventarnummern-Schema nur eine Zahl benutzen. “Hs-16231” würde “16231”. Richtig so. Aber “Hs-12-16231” würde “1216231”, was natürlich nicht sinnvoll ist. Da die meisten Museen aber nur eine Zahl in ihren Inventarnummern haben, wird eine eigentlich sinnvolle Funktion so für eine Mehrzahl der Museen verfügbar. Die, die mehrere Zahlen-Abschnitte in ihren Inventarnummern haben, müssen sich im Gegenzug bewusst sein, dass die Benutzung der Funktion bei ihnen zu unerwarteten Such-Resultaten führen kann.

Die neue Such- und Sortieroption ist in den jeweiligen Auswahlfeldern als zusätzlicher Punkt “Inventarnummer (nur Zahlen)” gelistet. Die herkömmliche Suche nach der Inventarnummer funktioniert also weiterhin.

Zusätzlich zu den bestehenden Optionen Objekte nach ihren Inventarnummern zu durchsuchen und zu sortieren, besteht jetzt die Möglichkeit, sie nach dem Zahlenwert ihrer Inventarnummern zu suchen und zu sortieren.

Apropos: Neue Screencasts zu musdb auf Youtube

Die oben beschriebenen Verbesserungen der Suchfunktion gaben auch einen guten Anlass, um eine alte Serie neu zu beleben. 2018 hatte ich eine Reihe von Anleitungen zur Benutzung von musdb als Screencasts auf Youtube veröffentlicht. Neue Screencasts sind in Arbeit und werden über einen frisch eingerichteten Youtube-Kanal für museum-digital veröffentlicht. Den Einstieg macht eine Besprechung der Objektsuche in musdb. In den kommenden Wochen folgen Screencasts zur Stapelverarbeitung, zum Export von Objektinformationen und zur Merkliste.

info

License

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

Ein Kalender heißt feste Termine

2023-03-14T00:00:00+00:00

Im letzten Jahr haben wir eine Online-Reihe von monatlichen Benutzer-Treffen zur Vorstellung neuer Entwicklungen bei museum-digital und zur Diskussion von Fragen aus der Benutzer- und Interessiertenschaft ins Leben gerufen. Wie die Dinge so laufen, blieben wir für einige Monate beim festen Termin - jeden ersten Dienstag von 17 bis 19 Uhr - und dann irgendwann nicht mehr. Natürlich sind Terminkalender der Teilnehmer ein wichtiger Aspekt, aber nicht zu vernachlässigen war dabei das schlichte Fehlen einer vorher festgelegten URL für das kommende Treffen.

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

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

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

info

License

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

Aktualisierte Fassung der DFG-Praxisregeln zur Digitalisierung

2023-02-27T00:00:00+00:00

In der letzten Woche wurde eine aktualisierte Fassung der DFG-Praxisregeln zur Digitalisierung veröffentlicht. Die Praxisregeln werden in vielen Förderlinien für Digitalisierungsprojekte als Maßstab für die im Projekt geplanten Maßnahmen verwendet und dürften deshalb für viele Museen von Interesse sein.

Unable to display PDF file. Download instead.

Die Praxisregeln sind unter Creative Commons Attribution 4.0 International lizensiert und finden sich unter https://zenodo.org/record/7435724. Siehe: Altenhöner, Reinhard, Berger, Andreas, Bracht, Christian, Klimpel, Paul, Meyer, Sebastian, Neuburger, Andreas, Stäcker, Thomas, & Stein, Regine. (2023). DFG-Praxisregeln “Digitalisierung”. Aktualisierte Fassung 2022. Zenodo. https://doi.org/10.5281/zenodo.7435724

info

License

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

EODEM - Objektdaten bei Leihverkehren effizienter austauschen

2023-02-15T00:00:00+00:00

Es ist eine immer wiederkehrende Situation. Ein Museum leiht Objekte an ein anderes. Zusammen mit den Objekten wird eine Liste versendet, in der die wichtigsten Informationen zum Objekt und seiner Konservierung - von der Inventarnummer und dem Titel bis hin zur minimalen und maximalen zulässigen Temperatur - in einer Excel-Liste. Das empfangende Museum gibt die Daten nun händisch in die eigene Sammlungsdatenbank ein, um auch die geliehenen Objekte verwalten zu können. Das händische Kopieren aber kostet viel Zeit und lässt viel Raum für (Tipp-)Fehler.

Andererseits handelt es sich um eine klar definitierte Aufgabe, die immer wieder dem selben Muster folgend erledigt wird. Das heißt: Es ist eine fast ideale Aufgabe um automatisiert zu werden.

In den letzten Jahren hat sich eine Arbeitsgruppe im Rahmen von CIDOC zusammengefunden, um die Grundlagen genau für eine solche Automatisierung des Austauschs von Objektinformationen im Zusammenhang von Leihverkehren zu legen. Da offensichtlich nicht alle Museen dieselbe Sammlungsdatenbank benutzen, hieß dies zu aller erst einen offenen Standard - quasi eine gemeinsame Sprache, die den verschiedenen Programmen beigebracht werden kann - zu definieren.

Der so entwickelte Standard - EODEM, kurz für Exhibition Object Digital Exchange Model - ist mittlerweile weit genug gereift, dass er einer öffentlichen Betaphase verfügbar gemacht wurde. Wir haben erst sehr spät damit angefangen, uns ernsthaft damit zu befassen, aber es war merklich an der Zeit, einen Versuch zu unternehmen, Import- und Exportwerkzeuge für EODEM im musdb zu implementieren. Schon im November hatten wir ein entsprechendes Import-Feature veröffentlicht. Im Januar konnte der EODEM-Export gerade noch mit dem großen Update und Re-Design des Monats in musdb untergebracht werden.

Im Folgenden soll es zuerst darum gehen, wie man Objektinformationen in EODEM in musdb importieren und exportieren kann. Final folgen einige Anmerkungen zum allgemeinen Nutzen von EODEM zum jetzigen Zeitpunkt und in der näheren Zukunft.

Wie kann ich EODEM in musdb benutzen?

Wie Leihverkehre eingehend und ausgehend sein können, so gibt es auch zwei übliche Anwendungsfälle für EODEM-kodierte Objektinformationen. Das empfangende Museum kann durch den Import von EODEM-Daten viel Zeit sparen und Fehler umgehen, während die Kollegen im ausleihenden Museum den Leihnehmern niedrigschwellig viel helfen können, indem sie die Daten in EODEM exportieren.

EODEM importieren

Im Handbuch findet sich eine ausführliche Beschreibung des Importprozesses in musdb. Kurz zusammengefasst: Zuerst wird ein Passwort generiert, mit dem man mithilfe eines WebDAV-Clients Zugang zu einem Import-Ordner bei museum-digital erhalten kann. Dieser Ordner hat zwei Unterordner, in die man die Metadaten und (falls vorhanden) die zu importierenden Mediendateien hochladen kann. Dazu finden sich im Ordner eine Anleitung und eine Konfigurationsdatei, die man dem vorliegenden Import entsprechend anpassen kann. Benennt man die Konfigurationsdatei nun in import_config.txt um, dient dies dem Server als Indikator, dass ein Import durchzuführen ist. Der Server prüft die Import-Ordner regelmäßig (derzeit alle vier Stunden) auf das Vorhandensein von Importdaten und importiert, falls Importdateien (besonders die Konfigurationsdatei) gefunden werden.

EODEM wurde als “Application Profile” von LIDO 1.1 entwickelt, das heißt, das EODEM auf dem etablierten LIDO-Standard für den Austausch von Objektinformationen aufbaut und diesen um die für Leihverkehre relevanten Datenfelder erweitert. So ließ sich der EODEM-Import unkompliziert als Erweiterung in den bestehenden LIDO-Import integrieren. Möchte man also einen EODEM-Import durchführen, muss in der Konfigurationsdatei “Lido” als “parser” eingestellt werden.

Je nach dem, wie die Inventarnummern innerhalb eines Museums geformt werden, kann der Import von Objektdaten aus fremden Häusern zu einem Problem führen. Das Import-Tool bei museum-digital vergleicht die Inventarnummer der Objekte mit denen der schon erfassten Objekte. Gibt es bereits ein Objekt mit einer gegebenen Inventarnummer, wird dies als Zeichen genutzt, um den bestehenden Datensatz zu aktualisieren statt einen neuen Datensatz anzulegen. So wird normalerweise zwischen neuen Objekten und Updates unterschieden. Wird aber dieselbe Inventarnummer in beiden Häusern verwendet (offensichtlich für verschiedene Objekte), so würde der Server dies folgerichtig als Aufforderung zum Updaten sehen - und den eigenen Objektdatensatz mit den Daten des Leihobjektes überschreiben. Um diesem Problem zu begegnen bietet der LIDO-Parser jetzt eine zusätzliche Einstellung: prefix_inventory_numbers . Wird hier ein Wert (Beispielsweise die Referenznummer des Leihverkehrs, oder ein Kürzel des Namens des ausleihenden Museums) eingetragen, so wird dieser den in den Importdaten angegebenen Inventarnummern vorangestellt. Damit ist eine Kollision quasi ausgeschlossen und der Import auch fremder Objekte sollte problemlos durchgeführt werden können.

EODEM-Daten exportieren

Objektdaten können in musdb genauso wie in alle anderen unterstützten XML-Exportformate exportiert werden. So erscheint EODEM jetzt primär als zusätzliches Exportformat im Formular für Exporteinstellungen (weiter unten lassen sich hier z.B. auch einzelne Felder abwählen, die regulär bei EODEM-Exporten mit exportiert würden, aber im gegebenen Fall nicht exportiert werden sollen). Ist der Export den eigenen Wünschen entsprechend eingestellt, wird mit dem Klick auf den Abschicken-Button eine ZIP-Datei bereitgestellt, in der sich die Objektinformationen in EODEM finden. Dieses ZIP kann man nun dem empfangenden Museum schicken.

Um den Prozess weiter zu vereinfachen gibt es zusätzlich auf der Bearbeitungsseite für Leihverkehre einen neuen Button “Objekte (EODEM)” in der Rubrik “Exporte” in der Seitenspalte. Durch einen Klick darauf wird man gleich zum entsprechend vorkonfigurierten Exportdialog für das Exportieren aller Objekte aus dem gegebenen Leihverkehr geleitet.

In musdb and darüber hinaus

Wie schon gesagt haben wir uns erst sehr spät mit EODEM beschäftigt. Der Standard ist schon seit einigen Jahren in der Entwicklung, während wir erst gegen Ende 2022 ernsthaft begonnen haben, uns damit auseinanderzusetzen. (Der Arbeitsgruppe gebührt aller Dank für die Entwicklung von EODEM und das Erkennen der damit einhergehenden Potentiale!)

Andererseits ist musdb tatsächlich das erste System zum Sammlungsmanagement, das Import- und Exportfunktionen für EODEM-Daten ausliefert. Damit ist der Datenaustausch vorerst schon einmal für den Fall von Leihverkehren zwischen zwei Museen, die beide musdb als Werkzeug für die Inventarisierung und das Sammlungsmanagement verwenden, einsetzbar.

Allgemein ist die Benutzung eines Standards ist aber nur so sinnvoll, wie er weit verbreitet ist. Die Website der Arbeitsgruppe bietet eine Liste der Softwarelösungen, in denen Import- und / oder Exportfunktionen für EODEM geplant sind. Viele der großen Namen sind darauf zu finden und haben sich aktiv in die Entwicklung des Standards eingebracht, sodass eine baldige Implementation in einigen der weiter verbreiteten Programmen absehbar ist.

Andererseits gibt es natürlich noch viele andere Programme für das Sammlungsmanagement, die sich bisher nicht auf der Liste finden. Die Implementation an sich ist definitiv nicht schwer, wenn bereits ein LIDO-Import oder Export unterstützt wird und je mehr sich der Standard verbreitet, desto sinnvoller wird seine Benutzung. Es ist daher zu hoffen, dass bald noch deutlich mehr Implementationen folgen, und wir alle die Interoperabilität zwischen Sammlungsdatenbanken stärken und Zeit sparen können.

Beitragsbild: “Relief zweier sich die Hände reichenden Männer, Seebronn (?)“, CC BY-SA @ Landesmuseum Württemberg

info

License

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

Über Tausend Museen bei museum-digital

2023-02-12T00:00:00+00:00

Letzte Woche hat museum-digital einen wichtigen Meilenstein genommen - und es ist erst jetzt wirklich aufgefallen. Mittlerweile haben mehr als 1000 internationale Museen jeweils mindestens ein Objekt bei museum-digital veröffentlicht. Ihre Sammlungen können unter global.museum-digital.org gemeinsam durchsucht werden.

Kommendes größeres Update in musdb

2023-01-04T00:00:00+00:00

Am 11.1. wird musdb nach langer Zeit einmal wieder ein wirklich großes Update mit vielen neuen Funktionen und einem kleineren Re-Design erhalten. Eine Übersicht der bisher implementierten neuen Features lässt sich im Blog auf Englisch nachlesen.

info

License

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

Service Announcement: Bildserver heute zeitweise nicht verfügbar

2023-01-04T00:00:00+00:00

Der Server, über den Mediendateien in den öffentlichen Ausspielungen von museum-digital ausgeliefert werden, hat heute ein kritisches BIOS-Update bekommen und ist wegen des dadurch notwendigen Neustarts (heute 14:30) temporär nicht verfügbar. Links auf die Domain asset.museum-digital.org können damit derzeit nicht korrekt aufgelöst werden.

Konkrete Probleme in den öffentlichen Ausspielungen sollte es so jedoch nicht geben. Wir konnten rechtzeitig auf die Benutzung einer Rückfallebene umstellen.

info

License

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

musdb und Frontend in Französisch und Russisch übersetzt

2022-11-08T00:00:00+00:00

Im letzten Monat konnten wir die lange erwarteten französischen und russischen Übersetzungen für musdb und die Ausgabe von museum-digital freischalten. Und auch eine ukrainische Übersetzung ist derzeit in Arbeit. Vielen Dank an die Kollegen aus Speyer und Berlin-Karlshorst!

info

License

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

Wartungstag im ZIB 2022

2022-08-31T00:00:00+00:00

Vom 29.8.2022 bis 30.8.2022 fand der Wartungstag des Zuse-Instituts Berlin, wo der Server von museum-digital gehostet wird, statt. Das bedeutet, dass dieser Server abgeschaltet war.

In diesem Jahr waren wir auf den Wartungstag gut vorbereitet und museum-digital funktionierte trotz des temporär fehlenden Servers fast problemfrei weiter. Konkrete Probleme sind dabei nur durch einige fehlerhafte, zwischengespeicherte Links auf den Startseiten (die sich in fehlenden Bildern ausdrückten) einiger Instanzen entstanden. Da der Server auch unsere Brücke ins Backup-System von digiS, dem Landeszentrum für Digitalisierung in Berlin, ist, fehlten zudem für einen Tag die Backups in dieses (die Tages-Backups für den gestrigen Tag werden allerdings heute automatisch synchronisiert werden; mehr zum Backup und zur Infrastruktur findet sich auf museum-digital.org).

tip

tip

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

"Strict Modes"

2022-08-26T00:00:00+00:00

In meinem Inventarisierungsprogramm möchte ich abfragen können, welche Objekte an einem gegebenen Tag ins Museum gekommen sind. Oder in einem Monat. Klar.

In musdb war bisher nur die Erste der Fragen beantwortbar, wenn auch nicht perfekt. Die zweite Frage ließ sich bisher schlicht nicht beantworten, weil Datumsangaben (Eingangsdatum, Datum der Ermittlung des Versicherungswertes, etc.) als Freitextfelder gefasst sind. Dasselbe Problem trifft (getrennte) Maßangaben und Werte (z.B. den Versicherungswert).

Einerseits erlaubt dies die Angabe von anders nicht erfassbaren Angaben wie “ca. 2020” als Datumsangabe und erleichert so Importe wesentlich. Andererseits besteht mit der Speicherung in Freitextfeldern die Möglichkeit für verschiedene Mitarbeiter einer Institution, die Daten in verschiedenen, miteinander inkompatiblen Arten einzugeben – und die eigentlich notwendigen Suchoptionen “größer als” und “kleiner als” sind eben nicht möglich.

Eine konservative Lösung

In einer idealen Welt würden wir die Felder also schlicht in der Datenbank in Datums- bzw. Zahlenfelder konvertieren und die entsprechenden Feld-Typen im HTML der Bearbeitungsseite aktivieren (so würden moderne Browser z.B. für Datumsfelder eine Datumsauswahl anzeigen). Aber in einer idealen Welt würde eben auch niemand Werte wie “ca. 2020” als Zeitangabe eintragen, und Importdaten wären schon perfekt formuliert. Die Welt ist nicht perfekt.

Deshalb muss museum-digital beides können: Einerseits sollte eine Option bestehen, die Konsistenz der Daten sicherzustellen und “größer- und kleiner-Suchen” zu ermöglichen und andererseits sollten auch inkonsistente Werte eingetragen oder importiert werden können (in dem Fall eben auch zu Lasten der Suchbarkeit. Mit zwei neuen Features kann musdb nun beide Anforderungen abdecken.

Um die Suchbarkeit der Einträge zu ermöglichen, haben wir zuerst zusätzliche Felder im Suchindex für bereinigte Datums- und Zahlenangaben für die entsprechenden Werte angelegt. Um diese Felder mit validen und konsistenten Werten zu befüllen, versuchen wir, vorhandene Werte so weit wie möglich zu übersetzen. Wo das nicht möglich ist, sind die Objekte über die neuen größer-/kleiner-Suchen nicht suchbar (über die bestehende Volltextsuche aber natürlich weiterhin).

Die zweite neue Funktion sind Einstellungen auf der Museumsebene: Strict Modes. Sind diese aktiviert, werden die Felder für Datumsangaben und Zahlenwerte für Browser als solche gekennzeichnet, sodass nur valide und damit suchbare Werte eingetragen werden können. Allerdings werden schon vorhandene, aber “falsche” Daten damit nicht mehr angezeigt und beim nächsten Abspeichern gelöscht.

Die Strict Modes sollten also erst einmal unbedingt nur von Museen, die gerade erst mit der Inventarisierung mit musdb anfangen aktiviert werden. Mittelfristig planen wir Scripte bereitzustellen, die eine Bereinigung und Migration der Daten hin zu einer Benutzung der Strict Modes ohne Datenverluste erleichtern.

Updateprobleme

Das Update, um die beiden neuen Features bereitzustellen, haben wir heute (25.8.2022) morgen verteilt. Weil beim Update wie oben besprochen neue Felder im Suchindex angefügt wurden, mussten die Suchindexe von Grund auf neu generiert werden.

Dabei kam es leider in einigen Instanzen zu einem Fehler: Unlogische Datumsangaben wie “08.13.2022” wurden von unserem automatischen Bereinigungsscript als vermeintlich valide Datumsangaben akzeptiert, aber von der Such-Datenbank nicht. Durch die so entstandenen falschen Angaben wurde in den betroffenen Instanzen von musdb die Generierung der Suchindexe unterbrochen, und es konnten eben nur die Objekte, die vor dem fehlerhaften Eintrag eingegeben worden waren, gesucht werden.

Der Fehler konnte bis ca. 12 Uhr behoben werden, sodass die Suchindexe nun wieder problemlos generiert und aktualisiert werden können, und wir haben die Suchindexe der betroffenen Instanzen in der Folge neu generiert.

Da der fehlerhafte Teil der Bereinigungsfunktion ebenfalls für die automatische Bereinigung des Zeit-Vokabulars benutzt wird, gibt es auch dort jetzt eine stärkere Absicherung gegen solche unlogische Datumsangaben.

tip

tip

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

Monthly museum-digital user meetup (August 2022) / New features

2022-08-16T00:00:00+00:00

On Tuesday last week we had our first international user meetup. As proposed, we mainly discussed recent updates and new features before opening up the general discussion. In the process, we also wrote a list of the new features introduced with short notes on each. You can find it below.

The next monthly meetup is scheduled for Tuesday, September 6th 2022, 5 p.m. (this post will be updated with a link to the meeting about a week before the meeting, as we are currently trying to organize a meeting room at Zoom or a similar service).

Update: The meeting will take place at https://meet.jit.si/museum-digital-meetup-202209

Recent Updates and New Features

musdb

XML Export

Creating new export formats for XML exports (beyond the main export formats md:xml and LIDO 1.0) is now possible using XSL files stored in a new git sub-repository. This git sub-repository is open source. As registration on our main Gitea instance is however restricted, please send a mail before contributing.

In line with this, we have also improved the representation of uncertainty in our default LIDO 1.0 exports. As version 1.1 of the LIDO standard has been recently released, we have also begun working on a LIDO 1.1 export.

Note: The pre-generated exports available through the “quick export” option are and will still only generated for LIDO 1.0 and md:xml.

Required coordinates when adding new museums

This update is only relevant to regional administrators. Coordinates of the institution are now required for adding new institutions.

QR Codes

QR codes can now also be exported in SVG and EPS, the two primary vector graphics format for use on the web and professional print layouting.

Another important improvement on QR codes is a new page that simply lists all QR codes leading to the object editing pages of a given search result in musdb. This page offers the option to manually set the size of the QR codes, so that suitable QR codes for internal collection and location management can be printed in bulk in a less paper-consuming way.

Calendar

A calendar view for all the events in the museum (events, start and end of an exhibition, start and end of loans) is now available. It can be reached by hovering the mouse over the puzzle symbol in the navigation. On the calendar page, single calendars can be selected or deselected and one subscribed to using one’s external calendar programm (e.g. Outlook, Thunderbird, or a mobile phone’s calendar).

The calendar, and especially the possibility to subscribe to the calendars, is also a first step towards enabling users to set reminders on object pages as this makes much more sense if the reminders can be integrated with one’s regular calendar application.

The calendar view is built using TUI calendar.

Institution-wide Settings and Adding Objects

The page for institution-wide settings has been re-designed to make it easier navigatable. The table of contents is now always visible, and the section “links to the institution elsewhere on the web” has been moved to the institution page.

There however are also some new options on the page. On the one hand, users can now enable or disable the image categorization when uploading images directly when adding new objects (the image recognition is render blocking and often hurts performance more than it actually benefits the inventorization). On the other, it is now possible to add additional fields to be directly accessible upon adding new objects and to make these required. It thus, for example, becomes possible to require a location to be provided before it can be recorded in the system altogether.

Watch list

The watch list feature has been completely re-implemented. The watch list is now generated completely in the browser using easily cache-able data retrieved from APIs. This, first of all, makes the watch list much faster to load and much less of a burden on the server side.

But the new watch list also comes with some new features:

Users can now have multiple watch lists on the server
Users can share their currently active watch list with other users of the same museum
It is now possible to search objects by a watch list (or transfer the watch list into a search result). Thus, all batch editing and export functions available for object search results are now also available for watch lists. Obviously, this also allows for the watch list’s objects to be filtered by their place, collection, etc.
Objects can now be added to the watch list in bulk.

Object search

The map view of object search results now updates the URL with positions and zoom factor when one browses the map. One can thus share a link to the exact same position one is currently viewing to one’s colleagues.

API

The API can now be used to delete objects.

Design

Error messages are now visible for four seconds as opposed to the regular 2.4 seconds other feedback messages on inputs are visible.

Frontend

Similar to the referencable maps of object search results in musdb, “objects on a map” maps in the frontend are now also referencable. We have also added a legend of event types on the same map.

museum-digital.org

museum-digital.org, the general website introducing museum-digital, has been reworked on a new technical basis. It is now statically generated once a day, reducing server costs and increasing performance. There are also many new texts, some new features (such as FAQs) and banner pictures that make the page more attractive.

The contents of the page are licensed under CC BY 4.0 International and can be edited on GitHub (See the repositories for the English version of the site and the German version).

Importer

The parser for importing images by their file names now offers a setting option to mark a certain part of a file name as an indicator to import the given image file as a hidden / non-public image.

info

Post banner image credits

Courtesy NASA/JPL-Caltech.

info

License

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

Referenzierbare Karten in der Ausgabe und in musdb

2022-07-22T00:00:00+00:00

Die Weiterentwicklung von museum-digital wird sich absehbar erst einmal auf die internen Funktionen konzentrieren - aber auch in der Ausgabe tut sich langsam etwas. Deshalb sei heute eine sehr kurze Meldung erlaubt: Genaue Positionen auf den Kartenansichten für Objektsuchen in der Ausgabe und in musdb lassen sich jetzt direkt referenzieren.

Dafür wird die URL, sobald an eine neue Position auf der Karte navigiert oder gezoomt wird, angepasst. Die so in der URL vermerkte Position kann durch einfaches Kopieren mit anderen geteilt werden, sodass Gesprächspartner beim Klick auf den Link wieder dieselbe Position sehen.

Dazu konnten wir endlich einen lang und von vielen Seiten ausgedrückten Wunsch umsetzten: Es gibt jetzt eine Legende für die vielen verschiedenen Arten von Ereignistypen auf der “Objekte auf Karte”-Seite in der Ausgabe. Diese Legende ist über einen Klick auf das neu dazugekommene Fragezeichen-Symbol oben rechts auf der Karte erreichbar.

info

License

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

Objekte über die API von musdb verwalten

2022-06-20T00:00:00+00:00

Die öffentliche Programmierschnittstelle der Ausgabe von museum-digital ist seit langem im Einsatz um beispielsweise Objekte direkt aus museum-digital auf den Webseiten der entsprechenden Museen auszuspielen. Die API ist stabil und etabliert.

In musdb, unserem Inventarisierungs- und Verwaltungstool, war und ist die Situation schwieriger. Einerseits ist musdb bezüglich seines Funktionsumfangs schlicht ungleich größer. Andererseits verunmöglichen die Reiter-basierte Struktur der Benutzeroberfläche und die bisher an vielen Stellen leider noch zu enge Kopplung zwischen Benutzeroberfläche und zugrundeliegender Abfragelogik ein API-Design wie in der Ausgabe, wo sich die API durch das einfache Anfügen von &output=json (bzw. ?output=json) aufrufen lässt. An vielen Stellen lässt sich zwar genau das tun, aber die Ergebnisse sind zwangsläufig unvollständig und von der Benutzeroberfläche gefärbt.

Andererseits ist eine API gerade für musdb interessant. Wenn Museen ihr lokales Inventarisierungsprogramm der Wahl verwenden könnten, und die Updates sofort auch in musdb und den öffentlichen Seiten gespiegelt würden, wäre das ein großer Fortschritt. Bisher bräuchte es dafür die Importfunktion, dass heißt, dass selbst bei einer vollen Automatisierung des Synchronisationsablaufs immer eine Verzögerung im Updatefluss bliebe.

Ein Anfang: Objekte per API updaten

Ein erster Schritt in Richtung einer dedizierten API für musdb, die unabhängig von der Benutzeroberfläche benutzt werden kann, ist nun getan. Zumindest Objektinformationen sind nun über eine gezielt dafür eingerichtete API auslesbar und bearbeitbar. Weitere Funktionen kommen sobald ein Bedarf besteht.

Und wenn man einmal damit anfängt, macht man es natürlich am besten gleich sauber. Mit der neuen API wurde ein Umformulieren und Neusortieren von vielen grundlegenden Funktionen auf technischer Ebene notwendig, die uns eine gute Gelegenheit gegebenen hat, gleich automatische Tests für alle in der API benutzten Funktionen zu schreiben. Ihre jetzt bestehenden Funktionen bleiben also sicher stabil.

Andererseits lag es nahe, die API beim Bauen gleich mithilfe eines Standards wie OpenAPI maschinenlesbar zu beschreiben. Gesagt, getan. Eine in JSON gefasste OpenAPI-Beschreibung der API von musdb findet sich in jeder regionalen Instanz unter /musdb/api, also etwa unter https://hessen.museum-digital.de/musdb/api.

Mit der Verwendung von OpenAPI eröffnen sich auch all die Tools, die allgemein für mit OpenAPI beschriebene Schnittstellen existieren. Eine vollständige menschenlesbare API-Dokumentation findet sich nun also im Handbuch (weil die API immer an die jeweilige regionale Instanz gebunden ist, funktioniert die Ausprobieren-Funktion im Handbuch nicht; eine gleich geformte API-Übersicht mit funktionierender Ausprobieren-Funktion ist in musdb in der Navigation verlinkt).

Nächste Schritte

Auch wenn sich jetzt alle Objektinformationen über die Schnittstelle bearbeiten lassen, ist die neue API von musdb noch sehr unvollständig. Ein nächster Schritt wird also definitiv die Erweiterung der API mindestens um die direkt anliegenden Funktionalitäten sein - z.B. das Auflisten der verfügbaren Sammlungen, sodass man überhaupt erst einmal die IDs zum Verlinken von Sammlungen ermitteln kann.

Auf der anderen Seite ist die API-Dokumentation mit OpenAPI ein großer Fortschritt auch gegenüber der Dokumentation der API der Ausgabe. Es bleibt zu hoffen, dass wir bald dazu kommen, auch für die API der Ausgabe eine OpenAPI-Beschreibung bereitzustellen. Geplant ist es auf jeden Fall.

info

License

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

files.museum-digital.org: Dokumenten-Archiv zu museum-digital

2022-06-07T00:00:00+00:00

Über die Jahre wurden Präsentationen über museum-digital gehalten, Artikel und Anleitungen geschrieben. Damit all die so entstandenen Dokumente nicht ungenutzt auf den Festplatten derer, die sie erstellt haben, bleiben, sondern mindestens für das Nachvollziehen der Entwicklung von museum-digital zur Verfügung stehen, haben wir unter files.museum-digital.org ein Archiv eingerichtet.

Für den Anfang finden sich hier einige Präsentationen und die derzeit bei museum-digital genutzten Logos. Im Rahmen der Publikation im Archiv wurden viele der Präsentationen um eine explizite Lizensierung nach CC BY 4.0 erweitert.

info

License

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

Importe kann man jetzt selbst machen

2022-06-04T00:00:00+00:00

Bis letzten Monat war der Ablauf eines Importes bei museum-digital immer dadurch beschränkt, dass ein Mitglied des Technik-Teams involviert sein musste. Das war schon alleine deshalb der Fall, weil es bis dahin keine Option für User gab, die zu importierenden Daten auf den Server zu laden. Nach vielen Jahren konnten wir die Import-Funktion jetzt endlich auch für das eigenständige Durchführen von Importen durch Benutzer, die einen Zugang zu musdb haben, öffnen.

Die wichtigste Bedingung dafür war wie schon beschrieben, dass eine Möglichkeit geschaffen werden musste, die Importdaten überhaupt hochzuladen. Dies kann über eine neu eingerichtete WebDAV-Schnittstelle getan werden. WebDAV ist ein Protokoll, das grob analog zu FTP benutzt werden kann, und zum Beispiel auch für die Synchronisierung zwischen einem Rechner und einem Cloudspeicher wie Google Drive oder Nextcloud zum Einsatz kommt. Es hat den Vorteil, dass es auf HTTP (also das Standard-Protokoll, über das Webseiten aufgerufen werden) aufsetzt, und so auch in größeren Institutionen oder in solchen, deren IT von der jeweiligen Kommune gemanaged wird, nicht von Firewalls blockiert werden sollte. Zusätzlich gibt es selbst im Windows Explorer die Möglichkeit, sich mit WebDAV-Netzwerklaufwerken zu verbinden (siehe z.B. hier für eine Anleitung). Ein Upload sollte also protokollbedingt kein Problem darstellen.

Wie importieren?

Zugangsdaten zur WebDAV-Schnittstelle kann man in musdb bei den Einstellungen für das eigene Benutzerkonto erhalten (oben in der Navigation auf den eigenen Namen klicken, dann im Menü auf “Kontoeinstellungen”). Unterhalb der grundlegenden Tabelle für Logindaten findet sich hier ein neuer Reiter “WebDAV”. Öffnet man diesen “Reiter” erhält man eine kurze Erläuterung auf Englisch und einen Button “Generate WebDAV password”. Klickt man diesen, werden die Zugangsdaten mit einem automatisch generierten Password angezeigt. Das Password sollte gut gespeichert werden, weil es auf dem Server nur in gehashter - also gezielt nicht zurückberechenbarer - Form vorliegt.

Wenn man den Button “Generate WebDAV password” gedrückt hat, öffnet sich ein Dialog mit den Logindaten zur WebDAV-Schnittstelle.

Mit diesen Logindaten kann man sich über einen WebDAV-Client einloggen. Möchte man nur Ausprobieren, wie das Ganze funktioniert, bietet sich hier der jeweilige Dateimanager (also z.B. der Windows Explorer) an. Möchte man öfter selbst importieren, lohnt sich spezialisiertere Software wie z.B. WinSCP. Je nach Software muss die Angabe des Protokolls von davs:// zu https:// geändert werden.

Wichtig ist dabei anzumerken, dass die generierten Zugangsdaten immer nur Zugang zur Schnittstelle für die eigene “Heimat-Institution” geben. Für die meisten Benutzer ist das unproblematisch, aber für Benutzer, die Zugriff auf die Daten mehrerer Museen haben, bedeutet das, dass sie nur für das Haus, dem ihr Benutzerkonto primär zugeordnet ist, Importe durchführen können.

Angekommen auf dem Netzwerklaufwerk: Importdaten hochladen

Hat man sich mit einem WebDAV-Client und mit den eben bezogenen Logindaten zum Server verbunden, sieht man zwei Dateien und zwei Ordner.

.
├── import_config.sample.txt
├── IMPORT_IMG
├── IMPORT_XML
└── README.md

Der Zweck der Datei README.md sollte offensichtlich sein. Hier werden noch einmal die Ordnerstruktur und die folgenden Schritte beschrieben.

Importdaten hochladen

Die Ordner IMPORT_IMG und IMPORT_XML sind die Ordner, in die die zu importierenden Daten hochgeladen werden können. Das geschieht, wie schon von der Ordnerstruktur angedeutet, getrennt nach Dateitypen, wobei die Metadaten in den Ordner IMPORT_XML geladen werden, und Mediendateien in den Ordner IMPORT_IMG hochgeladen werden.

Datei ist zweierlei zu beachten: Einerseits sollte man sich von den Benennungen nicht verwirren lassen. Der Ordner IMPORT_XML ist für alle Metadaten-Dateien gut, sie müssen nicht unbedingt im XML-Format vorliegen. Andererseits sollten in diesen Ordnern keine weiteren Unterordner erstellt werden. Fast alle Import-Scripte (“Parser”) verlangen, dass die Daten direkt in den jeweiligen Ordnern liegen.

Die zu importierenden Daten werden nun also in die beiden Ordner hochgeladen.

Den Import konfigurieren

Im letzten Schritt muss dem Server mitgeteilt werden, was für eine Art von Daten dort importiert werden soll. Und, dass der Import überhaupt stattfinden soll. Das geschieht mit der Datei import_config.sample.txt. Öffnet man diese Datei in einem Texteditor (z.B. Notepad++ oder dem Windows Editor - auf keinen Fall MS Word), sieht man verschiedene Optionen, den Import einzustellen.

Verpflichtend sind dabei die Angabe einer Mailadresse, an die Nachrichten über den Fortschritt des Imports gesendet werden sollen (Achtung: Die Mailadresse muss einem Benutzerkonto in musdb, das mindestens die Benutzerrolle “Museumsdirektor” hat, zugeordnet sein), und die Angabe des “Parsers”, kurz gesagt, des nötigen Import-Formats.

Eine Liste der Import-Formate mit ihren Benennungen findet sich am Ende der Datei. So möglich, stehen hier auch die möglichen parser-spezifischen Einstellungen aufgelistet. So lässt sich etwa für den Parser “ImagesByInvno", also dem Importieren von Bildern nach einer im Dateinamen angegebenen Inventarnummer, einstellen, wie lang die Inventarnummer sein soll, oder ob die Inventarnummer über die ersten 10 (11, 12, 13, …) Buchstaben ermittelt werden soll, oder über ein Trennzeichen (überblicherweise ein Unterstrich) ermittelt werden soll.

Weitere allgemeine Einstellungen sind optional. So kann eingestellt werden, ob die Objekte gleich nach dem Import veröffentlicht werden sollen, oder ob sie alle in eine spezifische Sammlung importiert werden sollen. In der Datei finden sich zu jedem dieser Punkte relativ ausführliche Erläuterungen.

Ist die Import-Konfiguration soweit abgeschlossen, kann die Datei in import_config.txt umbennant werden. Das vorhandensein einer Datei mit diesem Namen auf der obersten Ebene des WebDAV-Laufwerks ist das Zeichen an den Server, dass importiert werden soll.

Der Import findet statt

Für das automatische Importieren prüft der Server alle vier Stunden, ob sich passende Importdateien in den WebDAV-Verzeichnissen befinden (also, Daten hochgeladen wurden, und eine Datei import_config.txt vorhanden ist). Ist das der Fall, läuft der Import ab.

Sobald es einen Fehler gibt wird der Import abgebrochen und eine Fehlermail an die in der Konfigurationsdatei angegebene Mailadresse und das Entwicklerteam gesendet. Fehler können z.B. bei einer bisher unbekannte Lizenzangabe vorliegen, aber auch schlicht unlogisch formulierte Daten betreffen. Bei Parsern mit Vollständigkeitsprüfung kann der Fehler auftreten, dass ein bestimmtes Datum bisher nicht vom Parser abgedeckt wird.

Im Fehlerfall werden die Importdaten dann in einem Ordner IMPORTS_FAILED verschoben. Sobald der Parser oder die Daten angepasst wurden, damit der Fehler nicht mehr auftritt, können sie von dort wieder an die richtige Stelle für ausstehende Importe (also die Ordner IMPORT_XML und IMPORT_IMG) verschoben werden.

Läuft der Import andererseits fehlerfrei durch, wird eine Benachrichtigungsmail an die oben angegebene Adresse gesendet.

Nötige Anpassungen für die Ermöglichung von benutzergesteuerten Importen

Damit all das möglich wurde, mussten wir den Importer großflächig anpassen. Gerade für die Konfigurierbarkeit von parserspezifischen Werten brauchte es auf Seiten der Parser eine grundlegend andere Architektur.

Der Importer besteht grundlegend aus vier Arten von Scripten:

Eine Repräsentation der grundlegenden importierbaren Datentypen (Objekte, Ereignisse, Bilder, Sammlungen) in Code
Scripte, die das Schreiben von Daten in die Datenbank übernehmen
Parsern, die den Ablauf eines Imports für die verschiedenen Arten von Importdaten und die Zuordnungen von Werten aus den Importdateien zu den bei museum-digital bestehenden Datentypen herstellen
Frontend-Scripten, die z.B. das Kommandozeilen-Interface bereitstellen

Von diesen waren bisher nur die Datentypen und Schreib-Scripte mit einem objektorientierten Ansatz geschrieben. Für die neue Möglichkeit selbst zu importieren, wurden auch die Parser und die Frontend-Scripte angepasst, sodass das ganze Importtool jetzt mithilfe eines objektorientierten Ansatzes geschrieben ist. Das hat u.a. auch den Vorteil, dass für alle vorhandenen Parser automatische Tests eingerichtet werden konnten, sodass z.B. Fehler, die durch Updates der Programmiersprache oder Änderungen an anderen Stellen entstehen, frühzeitig auffallen und gelöst werden können.

Der Anspruch automatisierte Tests für alle Aspekte des Importers zu haben führt allerdings auch dazu, dass nicht mehr alle bisher vorhandenen Parser verfügbar sind. Beim Überführen der Parser in die neue Architektur wurden solche Parser übergangen, die mit größerer Wahrscheinlichkeit nicht wieder gebraucht werden (z.B. der Parser für Museo, das alte Inventarisierungssystem der Museen der Lausitz, das seit längerem nicht mehr gepflegt wird und nicht mehr im Einsatz ist).

Und für wen ist das sinnvoll?

Wer kann also von der Möglichkeit, Daten selbst zu importieren, profitieren? Einerseits sind das Museen, die mit einem anderen Programm inventarisieren, aber ihre Daten mit museum-digital veröffentlichen und deren Daten schon einmal erfolgreich importiert wurden. In diesen Fällen ist davon auszugehen, dass das bestehende Importformat sich nicht weiter geändert hat und ein passender Parser bereitsteht.

Andererseits können Museen profitieren, die sehr viele Abbildungen für ihre Objekte haben, und bei denen der Upload mit dem regulären Bild-Uploadtool zuviel Zeit kosten würde. Im Freien Deutschen Hochstift / Frankfurter Goethe-Museum wird die Funktion etwa schon fleißig genutzt, um gescannte Handschriften zu den Metadaten-Datensätzen in musdb hochzuladen.

Für Museen, die das erste Mal importieren wollen, oder für solche, die Daten importieren möchten, für die es bisher noch keinen Parser gibt, macht der eigenständige Import andererseits keinen Sinn. In diesen Fällen weiterhin heißt es wie so oft: Einfach eine Mail schreiben, eine Lösung wird sich finden.

P.S.: Auch im Handbuch findet sich eine jeweils aktuelle Beschreibung des Import-Prozesses.

info

License

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

Kurznachrichten: Handbuch bei GitHub, Seitenspezifische Hilfelinks in musdb und das neue Feld "Danksagung"

2022-04-19T00:00:00+00:00

Das Handbuch von museum-digital hat eine Schwäche: Es ist - gemessen, an all den Funktionen die besonders musdb mittlerweile bietet - leider noch immer relativ leer. In der Hoffnung, dass sich das bald ändert und damit sich das bald ändert, gibt es ein paar kleine aber wichtige Änderungen im Handbuch.

Das Handbuch bei GitHub

Das Handbuch können Andere besser schreiben, als wir vom Kernteam von museum-digital. Ein gutes Handbuch für Benutzer kommt schließlich am Besten von anderen Benutzern. Deshalb ist das (deutschsprachige) Handbuch ab jetzt allgemein über GitHub bearbeitbar.

Mit der Umstellung der technischen Basis des Handbuchs auf mdbook Anfang des Jahres liegen alle Texte als Markdown-Dateien - also quasi als nur leicht formatierte Textdateien - vor, die problemlos mit einem Versionskontrollsystem verwaltet und verteilt bearbeitet werden können. Da GitHub mittlerweile wahrscheinlich die zentrale Stelle für die kollaborative Arbeit an vergleichbaren, versionierten Inhalten (von Handbüchern bis zum Hauptzweck, Programmen) ist, und die Meisten, die sich mit Versionierung auseinandergesetzt haben, wahrscheinlich schon ein GitHub-Konto haben, ist das Handbuch nun also zentral dort zu finden und wird dort gemeinsam mit allen, die mitmachen wollen, weitergeschrieben.

Auf jeder Seite des Handbuchs findet sich nun oben rechts ein Link zur äquivalenten Seite zur Bearbeitung, falls es Anmerkungen oder Ergänzungen gibt.

Seitenspezifische Hilfelinks in musdb

In der Navigation von musdb gibt es seit langer Zeit Links zum einigen Seiten des Handbuch. Bisher waren die hier verlinkten Seiten aber immer dieselben - egal, von welcher Seite aus man den Menüpunkt aufgeklappt hat.

Ab dieser Woche werden hier - soweit in der jeweiligen Sprache der Benutzer vorhanden - jeweils Links zu den passenden Seiten aus dem Handbuch zu finden sein. So finden sich die Antworten auf die Fragen, die während der Arbeit aufkommen, schneller - und musdb profitiert direkt von einem sich füllenden Handbuch.

Auf der Objekt-Übersichtsseite werden jetzt die passenden Seiten im Handbuch - z.B. zur Suchfunktion, zur Stapelverarbeitung, und zur Merkliste - angezeigt.

Das neue Feld “Danksagung”

Zu guter Letzt soll hier noch eine Neuerung Erwähnung finden, die ausnahmsweise nichts mit dem Handbuch zu tun hat: Auf dem Reiter “Zusatz” kann jetzt im neuen Feld “Danksagung” der Dank an Mitwirkende und Fördermittelgeber ausgedrückt werden.

Besonders wichtig ist das Feld für die gerade laufenden Projekte im Rahmen der Förderlinie Neustart Kultur. Damit die Angabe des Fördergebers nach den Vorgaben der Deutschen Digitalen Bibliothek im richtigen Feld weitergegeben werden kann (in unserem Fall lido:creditLine), muss die Angabe der Förderer in das Feld Danksagung eingetragen werden. Damit das, wo nicht eh schon geschehen, einfach umgesetzt werden kann, ist das Feld für die Stapelverarbeitung mit der Funktion “Globales Ändern” freigeschaltet.

info

License

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

Was tun mit Bildern? Anschauen!

2022-04-15T00:00:00+00:00

musdb ist eine mittlerweile eine volle Inventarisierungs-Software. Dass es aber ursprünglich einmal primär als Eingabeoberfläche zur Veröffentlichung von Museumsdaten entwickelt wurde, ist noch hin und wieder sichtbar.

Manchmal hilft es, eine Funktion anzuschauen, und die Intention dahinter noch einmal genau zu hinterfragen. Und so haben wir es bei den Seiten für einzelne Objektabbildungen in musdb getan.

Ursprünglich waren sie fast exklusiv mit dem Ziel entwickelt worden, die passenden Metadaten für eine Abbildung (also eine das Objekt zeigende Bild-, Video-, Audio- oder PDF-Datei; oder eine 3D-Repräsentation des Objektes) einzutragen. Entsprechend fanden sich eine kleine Voransicht zur Abbildung in einer Seitenspalte und zentral - und zentral auf der Seite Eingabefelder für das Bearbeiten der Metadaten der Abbildung.

Über die Jahre hatte sich der Fokus aber schon sichtbar gewandelt. Für intern gespeicherte Bilder waren Optionen, die Bilder zu drehen, mithilfe der IIIF-API für das Downloaden von Ausschnitten zurechtzuschneiden, und eine Informationssektion zu Bildgröße und primärer Farbe dazugekommen. Und nicht zuletzt wurden die (internen) Abbildungen mit einer eigenen Übersichtsseite durchsuchbar gemacht.

Statt also nur Metadaten zu bearbeiten, ging es also schon mehr und mehr darum, etwas über die Objektabbildung zu lernen.

Die alte Objektabbildungs-Seite: Zentral sind die Metadaten, rechts eine kleine Seitenspalte mit Voransicht

Das waren wichtige Schritte, aber gerade für Häuser, die mit musdb inventarisieren, ohne die Objekte gleich auch zu veröffentlichen, fehlte der eigentlich Naheliegendste: Natürlich will man die Objekte im Inventarisierungssystem auch richtig anschauen können.

Vor diesem Hintergrund haben wir die Seiten für Objektabbildungen neu gestaltet. Der zentrale Teil der Seite ist jetzt wo immer möglich eine Ansicht der jeweiligen Mediendatei, mit den entsprechenden, üblichen Zusatzfunktionen (z.B. ein Zoom bei Bildern). Die Metadaten können in der Seitenspalte bearbeitet werden, und die Optionen zum Bearbeiten, Herunterladen, etc. sind in einer mittigen Spalte zusammen gruppiert.

Die neue Abbildungsseite für intern gespeicherte Bilder: Links in der Seitenspalte können die Metadaten bearbeitet werden. Mittig finden sich die Bearbeitungsoptionen. Der Hauptteil der Seite (rechts) wird jetzt von der Abbildung selbst eingenommen.

So kann man die eigenen Objektabbildungen nun auch direkt in musdb gut anschauen. Für die Inventarisierung lange überfällig, hilft das aber natürlich auch den Institutionen mit Fokus auf die Veröffentlichung: Ohne eine Abbildung genau anschauen zu können, ist es schwer, sie gut zu beschreiben.

Vorschau eines 3D-Digitalisats in der Abbildungsbearbeitungsseite. Wie in der Ausgabe ist das 3D-Objekt zoombar, kippbar, etc.

info

License

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

Standorte und mehr - Objektdaten per QR-Code updaten

2022-04-03T00:00:00+00:00

Ein klassischer Anwendungsfall von Inventarisierungssystemen im Museum ist die Depotverwaltung. In welchem Depot liegt das Objekt; in welchem Raum; in welchem Regal?

Aber das händische Updaten der Datensätze im Inventarisierungssystem, jedes Mal wenn ein Objekt aus dem Depot genommen wird, ist müßig. Deshalb sind die Standortdaten der Objekte oft nicht vollständig oder nicht aktuell. Um dieses Problem zu lösen haben einige Museen Anbindungen zwischen ihrem Inventarisierungssystem und dem Depot über QR-Codes oder Barcodes geschaffen.

Ein Beispiel: Am Eingang eines Depots steht ein Barcode-Reader, mit dem ein Barcode an einem eingehenden Objekt gescannt wird. Weil der Barcode stationär ist, ist bekannt, um welches Depot es sich handelt - und das Objekt wurde ja gescannt. Mit den beiden Datenpunkten kann nun der Datensatz des Objektes im Inventarisierungssystem im Hintergrund und ohne weitere Aktionen eines Menschen aktualisiert werden.

Standorte per QR-Code eintragen, in musdb

Um eine ähnliche Arbeitsweise direkt mit Bordmitteln von musdb zu ermöglichen, haben wir den Umgang mit QR-Codes neu ausgearbeitet und erweitert.

Aufgrund der Logik von musdb muss die Perspektive allerdings “umgedreht” werden. Im obigen Beispiel wird vom Depot aus gedacht: Zuerst greift man zum Barcode-Scanner (“welches Depot?”); dann scannt man das Objekt (“welches Objekt?”). Weil es in musdb bisher keinen eigenen Datentyp für Räume, Regale, etc. gibt, und der Blickwinkel generell vor allem vom Objekt als kleinerer Einheit her getan wird, war unser Ziel-Szenario leicht anders gelagert. Zuerst muss das Objekt identifiziert werden, dann das Depot.

Es könnte also in etwa wie folgt aussehen: Ein Benutzer ist auf dem Handy in musdb eingeloggt und scannt den QR-Code einer Seite in musdb, der an einem Objekt angebracht ist. Damit ist geklärt, welches Objekt bewegt wird. Als nächstes wird ein QR-Code an der Depot-Tür, dem Regal, etc. eingescannt, der angibt, wohin das Objekt bewegt wird. Sind beide Datenpunkte bekannt, kann die Aktualisierung vom Handy automatisch vorgenommen werden.

Umsetzung

Bisher erschien auf in der Toolbar der Objekt-Bearbeitungsseite ein Link, um einen QR-Code zur öffentlichen Ausspielung der Objektdaten zu generieren, wenn das Objekt veröffentlicht. Jetzt erscheinen hier zwei Optionen: Eine Option zum Generieren eines QR-Codes für die Beabeitungsseite in musdb und, wie gehabt, ein QR-Code zum Generieren eines Links zur öffentlichen Seite, der nur erscheint, wenn das Objekt auch veröffentlicht ist. Um beide auch später sicher Unterscheiden zu können, ist das Logo von musdb in den QR-Code, der für die Bearbeitungsseite generiert werden kann, eingebettet.

Über die Toolbar am linken Bildschirmrand der Objektseite können QR-Codes für das Objekt generiert werden. Das hier gezeigte Objekt ist öffentlich, weshalb sowohl ein QR-Code für die öffentliche als auch ein QR-Code für die Bearbeitungsseite in musdb generiert werden können.

Mit dem QR-Code für die Objekt-Bearbeitungsseite in musdb lässt sich die eingangs skizzierte Frage “was wird bewegt” klären. Um die zweite Frage “wohin wird das Objekt bewegt” zu klären, kann man nun in das Feld “Standort (Aktuell)” (auf dem Reiter “Verbleib”) klicken und dort einen passenden Wert (etwa: “Depot 3; Regal 5”) eintragen.

Solange das Eingabefeld aktiv ist, erscheint am unteren rechten Bildschirmrand eine schwarze Überblendung, die Informationen über die Zeichenzahl der bisherigen Eingabe und die maximal erlaubte Zeichenzahl im Feld gibt. Unterhalb dieser Informationen finden sich mehrere Optionspunkte als Icons, etwa zum Öffnen der Textbaustein-Auswahl. Neu implementiert ist hier eine Option, die sich hinter einem QR-Code-Symbol versteckt. Klickt man auf das Symbol, erhält man einen QR-Code, der zum Aktualisieren eines gerade aufgerufenen Objekteintrages mit den eingegebenen Werten benutzt werden kann.

Ist das Feld aktiviert, und steht der richtige Wert darin, können über die schwarze Box unten rechts QR-Codes zum eintragen desselben Wertes in dasselbe Feld eingetragen werden.

Wichtig: Der QR-Code kann nur mit dem neu in musdb eingebauten QR-Code-Reader sinnvoll benutzt werden. Einerseits, weil er statt einer Adresse eine Anweisung (“Update”, “Feld: Standort (Aktuell)”, “Wert: Depot 3; Regal 5”) kodiert. Andererseits, weil die Anweisung ohne den dazugehörigen Kontext (“welches Objekt”) nutzlos ist. Auch gut zu wissen: Mit derselben Logik lassen sich natürlich nicht nur Standorte aktualisieren - man könnte theoretisch auch eine Objektbeschreibung per QR-Code eintragen. Deshalb lassen sich die Update-QR-Codes für alle Freitextfelder auf der Objekt-Bearbeitungsseite erstellen.

Über die Toolbar am linken Bildschirmrand der Objektseite in musdb lässt sich ein QR-Code-Reader öffnen.

Ausgestattet mit beiden QR-Codes - einer am Regal, einer am Objekt - lässt sich also jetzt das oben skizzierte Szenario nachspielen. Man navigiert mit dem Handy auf eine beliebige Objektseite in musdb und scannt mit dem eingebauten QR-Code-Reader den QR-Code am Objekt. Damit erreicht man die Seite des gerade bewegten Objektes. Hier öffnet man wieder den eingebauten QR-Code-Reader, und scannt den QR-Code am Regal. Beim Objekt wird nun automatisch das Regal als Standort eingetragen.

Danksagung

Der in musdb eingebaute QR-Code-Reader basiert auf der JavaScript-Bibliothek nimiq/qr-scanner. Vielen Dank!

info

License

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

IIIF und museum-digital

2022-03-16T00:00:00+00:00

Viele haben es schon gesehen, und das Feedback war durchweg positiv: Für viele Objekte konnten wir im letzten Monat eine neue Abbildungs-Betrachtungs-Seite bauen, die z.B. einen wesentlich besseren Zoom als bisher bietet. Möglich wird das mit Mirador - dem verwendeten Image Viewer - und unserer IIIF-Schnittstelle.

Die Gemäldesammlung der Stiftung Preußische Schlösser und Gärten als IIIF Collection

Das museum-digital überhaupt eine IIIF-Schnittstelle hat, und jetzt auch tatsächlich einen IIIF-Viewer einsetzt, ist berichtenswert, aber schnell erzählt. Besonders, weil beides gut dokumentiert und weit verbreitet ist. Hier also stattdessen die Webseiten von IIIF und Mirador.

Wer genau hinsieht, wird aber sehen, dass die IIIF-basierte Bildansicht bei weitem nicht bei allen Objekten zur Verfügung steht.

Einschränkungen der IIIF-Umsetzung bei museum-digital

IIIF bietet ein standardisiertes Format, um von einem Server über eine passend formulierte URL Bild-Metadaten, aber auch passend zugeschnittene oder vor-bearbeitete Bilddateien abzufragen. Diese Bildbearbeitung macht Sinn, um auch auf schlechter ausgestatteten Endgeräten arbeiten zu können und eine gut referenzierbare URLs zu erstellen, sie führt aber auch zu dem Problem, dass der IIIF-Server idealerweise alle Bilder hochaufgelöst vorhalten sollte.

Bei museum-digital können Museen Bilddateien hochladen - aber gerade größere Häuser betreiben ihre eigenen Bildserver und verlinken die dort gehosteten Bilddateien nur. In diesen Fällen liegen bei museum-digital nur Voransichten, sodass wir keine adäquate Bildbearbeitung auf Serverseite vornehmen können Entsprechend bieten wir für Objekte, die extern gehostete Abbildungen haben, keine IIIF-Manifeste an.

Dadurch, dass unsere IIIF-Implementation nur IIIF in der Version 2.1 unterstützt, das (noch) nicht mit PDFs, Videos, Audio-Dateien und 3D-Digitalisaten umgehen kann, die man aber auch bei museum-digital als Objekt-Abbildungen verknüpfen kann, sind Objekte, die z.B. eine Video-Abbildung haben, ebenfalls ohne IIIF-Manifest.

IIIF Collections

Ein besonders schönes Feature von IIIF sind IIIF Collections, mit denen viele einzelne Objekte / Manifeste zusammengruppiert werden können. Um die Mindestanforderungen für eine IIIF-Schnittstelle umzusetzen, waren IIIF Collections schon seit zwei Jahren implementiert - nur eben ohne die Auflistung der zur Collection gehörenden Objekte / Manifeste.

Seit heute sind diese Auflistungen sowohl für Sammlungen als auch Objektgruppen, die beide als IIIF Collections erreichbar sind, möglich. Aufgelistet werden, wie oben beschrieben, aber eben nur Objekte, die ausschlieslich bei museum-digital gehostete Bilder als Abbildungen haben.

Erreichbar sind die Repräsentationen von IIIF Collections wie immer bei IIIF über die passenden URLs:

https://brandenburg.museum-digital.de/apis/iiif-presentation/collection/c217

Diese URL beschreibt die Gemäldesammlung der Stiftung Preußische Schlösser und Gärten. Spannend ist dabei der letzte Abschnitt der URL: c217. Dadurch, dass die IIIF Collection-API bei museum-digital mit Institutionen, Sammlungen und Objektgruppen gleich drei verschiedene Arten von Einordnungen abdeckt, wird als erstes Zeichen des den jeweiligen Eintrag repräsentierenden URL-Abschnitts der Typ angegeben. Danach folgt die API. “c217” bedeutet also, dass es sich um die Sammlung mit der ID 217 geht.

Mit “i” als Kürzel werden “Institutionen” bezeichnet, mit “s” Objektgruppen bzw. Serien. Ein Beispiel einer Objektgruppe als IIIF Collection wäre also etwa:

https://hessen.museum-digital.de/apis/iiif-presentation/collection/s20

info

License

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

Ein neues Design für md:term

2022-02-02T00:00:00+00:00

Mit dem Wochenende haben wir seit langer Zeit das erste größere Update für md:term, den Vokabularbrowser von museum-digital, veröffentlicht. Es ist nun komplett neu designed, noch ein gutes Stück performanter, und bietet eine neu hinzugekommene Download-Funktion.

Zuerst aber ein Schritt zurück: Das Ziel von md:term ist, einen zentralen öffentlich referenzierbaren Ort für die kontrollierten Vokabulare von museum-digital zu bieten, und sie einerseits über eine gut erreichbare Schnittstelle leicht nachnutzbar und anderseits leicht durchsuchbar zu machen.

Der Wunsch nach einer Download-Funktion kam im Sinne der Nachnutzbarkeit auf: Für manche Zwecke ist es sinnvoller, gleich das ganze Vokabular in einem Rutsch herunterzuladen und auszuwerten, als die vorhandenen Einträge jeweils einzeln abzurufen. Deshalb bieten z.B. auch die Wikipedia und Wikidata alle Ihre Inhalte gebündelt zum Download an. Mit der neuen Download-Funktion lassen sich ebenso die zentralen Vokabulare (für Orte, Personen, Zeiten und Schlagworte) von museum-digital als ZIP herunterladen.

Ein Re-Design wurde so sowohl technisch als auch im Bezug auf das Design nötig. Auf technischer Seite musste der Code wesentlich modularer aufgebaut werden, damit wir dieselben Funktionen zum Aufbau der menschenlesbaren Seite wie für die Erstellung der ZIP-Dateien benutzen konnten. Das der Code so wesentlich leichter wartbar und erweiterbar wird, ist ein glücklicher Nebeneffekt.

Die menschenlesbare Anzeige bedurfte vor allem wegen der Seitenspalte einer Überarbeitung. Wo jetzt eine neue Download-Sektion verlinkt werden sollte, war nach dem vorhandenen Design schlicht kein sauber nutzbarer Platz. Eine nicht allzu große Änderung hätte vielleicht genügt, aber um ein allgemein besser mit der regulären “Ausgabe” von museum-digital harmonierendes Design zu finden, war es leichter, das Design noch einmal grundlegend neu zu implementieren. So zeigt sich md:term jetzt vor allem in Grautönen, und nutzt mit Source Sans Pro dieselbe Schriftart wie die anderen öffentlichen Seiten von museum-digital.

Die Seitenspalte ist jetzt in mehrere klar voneinander abgetrennte Unterbereiche unterteilt, mit einer eigenen Sektion für Links und den Wechsel der benutzten Sprache. Neu ist eine bei Orten, Schlagworten und Zeiten auf großen Bildschirmen dazugekommene zweite Seitenspalte, in der man direkt zu den übergeordneten und untergeordneten Begriffe navigieren kann. Bisher war diese Hierarchie recht weit unten auf den Seiten zu finden, sodass md:term jetzt sicher noch auch noch ein kleines Stück schneller navigierbar ist.

info

License

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

Eine Komplettüberarbeitung der Objektsuche in musdb und der Ausgabe von museum-digital - und ein neues Handbuch

2022-01-17T00:00:00+00:00

In den letzten Wochen hat sich technisch wieder viel bei museum-digital bewegt - bisher unsichtbar, weil es sich um die größte Überarbeitung einer schon vorher vorhandenen Funktion in musdb seit langen handelt.

Eine neue Suchfunktion in musdb bietet endlich die Möglichkeit, nach Ereignissen zu suchen (nicht nur ihren Bestandteilen), negative Suchen durchzuführen (z.B. “Objekte, die nicht aus Hamburg kommen”), “oder”-Suchen zu machen, und - mir persönlich seit langem ein Anliegen - Objekte mit Maßangaben größer oder kleiner als ein gegebener Wert zu suchen. Damit spiegelt die Objekt-Suchfunktion in musdb die Logik der hier noch nicht besprochenen, aber schon länger verfügbaren neuen Suchfunktion der Ausgabe von museum-digital.

Weil es sich aber um so eine einschneidende Überarbeitung handelt, war es umso dringlicher, die entsprechende Seite im Handbuch zu überarbeiten. Einmal dabei, haben wir die Gelegenheit genutzt, das Handbuch technisch auf ganz neue Beine zu stellen.

Die Handbuchseite zur neuen Suchfunktion in musdb kann hier gefunden werden.

Neues Handbuch

Warum also ein neues Handbuch? Der grundlegendste Grund ist die zugrundeliegende Software: Das alte Handbuch basierte auf einer selbst geschriebenen Software, die einerseits dem Anspruch eines Handbuchs nicht in allen Belangen entsprach, und andererseits in Ermangelung von Zeit schlicht nicht oft genug upgedatet wurde.

Das neue Handbuch wird mit der Software mdbook generiert, die etwa auch für die Benutzer-Dokumentation der Programmiersprache Rust zum Einsatz kommt. Damit kommen nützliche, vorher nicht vorhandene Features wie etwa eine Druckfunktion für das gesamte Handbuch und eine besser navigierbare Navigation.

Für die Bearbeitung des Handbuchs bedeutet der Wechsel der Software, dass das Handbuch jetzt in simplen Plain-Text-Dateien geschieht, statt wie bisher direkt auf dem Server mit einem Login und eigenen Editor. Dadurch, dass diese Plain-Text-Dateien auch auf dem lokalen Rechner bearbeitet werden, kann in Zukunft theoretisch jeder zum Handbuch beitragen.

Die neue Software hilft aber natürlich noch nicht, das bisher sehr unvollständige Handbuch auch tatsächlich zu schreiben, auch wenn die Arbeit jetzt auch mehr Schultern verteilt werden kann.

info

Beitragsbild

Zuccarelli, Francesco: Cicero entdeckt das Grabmal des Archimede / CC BY-NC-SA @ Stiftung Preußische Schlösser und Gärten Berlin-Brandenburg & Murza, Gerhard (1994)

info

License

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

Inventarisierungsdaten vom Sofa aus Verbessern: Verbesserungsvorschläge und Bilderkennung

2021-11-03T00:00:00+00:00

Eine der großen Stärken von musdb, dem Eingabe- und Inventarisierungstool von museum-digital, ist seit langer Zeit seine Fähigkeit, auf Inkonsistenzen und unvollständige Eingaben hinzuweisen. Mit dem “PuQi” (Publikations-Qualitäts-Index) wird darauf hingewiesen, wo Datensätze vervollständigt werden können, wo ein Beschreibungstext für die Publikation zu lang oder zu kurz ist etc. Der “Plausi” weist auf potenziell unlogische Bezüge hin: Wurde ein Gemälde von Caspar David Friedrich (geboren 1774) gemalt, kann es nicht vor 1774 versendet worden sein. Beide Tools machen die Qualität der Datensätze - ein Stück weit - quantifizierbar und suchbar. Aber sie sind passiv - sie helfen Probleme zu identifizieren, die dann behoben werden können, aber sie helfen nicht bei der konkreten Lösung der Probleme.

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

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

Verbesserungsvorschläge

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

Oben rechts in der Navigation, mit dem Überfahren des Puzzlestück-Symbols, lässt sich die Liste der Verbesserungsvorschläge finden

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

Der Vorschlag wurde akzeptiert

Und was schlägt musdb da vor?

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

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

Vorgeschlagene Ereignistypen nach Objektart

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

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

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

Über der Liste erscheinen passende Ereignistypen zum Objekt. Hier “Aufgenommen”, “Vorlagenerstellung”, und “Wurde abgebildet (Akteur)” für eine Fotografie.

Bilderkennung

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

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

Unten auf der Objekt-Eingabeseite lassen sich jetzt optional direkt Objektabbildungen (als JPEG-Dateien) hochladen. Der normale Weg bleibt jedoch die traditionelle, nachgelagerte Upload- und Verknüpfungsfunktion für Objektabbildungen, wo auch PDFs, Videos, und externe Mediendateien hinzugefügt werden können.

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

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

Ist eine Objektabbildung auf der Objekt-Eingabeseite zum Hochladen vorgemerkt, werden darauf basierende Schlagwortvorschläge unten rechts angeboten. Dass es sich bei einem Porträt um eine “Person” handeln könnte, wird schon einmal richtig erkannt. “Husarenaffe” und “Schutzumschlag” sind aber definitiv falsch.

info

License

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

Ein neues Dashboard für musdb

2021-06-13T00:00:00+00:00

In musdb haben wir seit langer Zeit ein Dashboard als Startseite, das Benutzern einerseits einen Überblick über die Inhalte der Datenbank verschaffen, und andererseits Zugang zu Zusatzfunktionen (etwa einer Validitätsprüfung für Links) gibt.

Viele dieser Funktionen mussten aber zuerst einmal freigeschaltet werden und wurden daher von vielen nicht gefunden (geschweige denn eingesetzt). Schlimmer noch, verursachte die monolithische Struktur der Seite eine langsame Ladezeit - ausgerechnet auf der Startseite. Um diese Probleme zu lösen, haben wir an einem neuen Dashboard gearbeitet. Durch eine schlankere Architektur lädt das neue Dashboard wesentlich schneller - und ein paar neue Funktionen sind durch die Überarbeitung auch dazugekommen.

Das neue Dashboard von musdb - Reiter “Kontrollierte Vokabulare”

Das neue Dashboard

Die erste und offensichtlichste Neuerung des neuen Dashboards ist, dass links eine immer sichtbare Seitenspalte zu sehen ist, die Zugang zu allen verfügbaren Funktionen des Dashboards bietet. Über die Seitenspalte können die folgenden Unterseiten angewählt werden:

Start

Auf der Startseite finden sich die grundlegendsten Funktionen des alten Dashboards. Ganz oben findet sich eine Übersicht der verfügbaren Datenbankinhalte, darunter Benachrichtigung der Administratoren und eigene Notizen. Abgeschließend gibt es Links zu anderen Seiten des Museums (Einstellbar auf der Seite “Einstellungen für das Museum”).

Datenbankinhalte des Hauses

Auf dieser Seite wird die Entwicklung der Datenerfassung innerhalb des Museums visualisiert. Mehrere Werte (etwa die Anzahl der erfassten Objekte und der veröffentlichten Objekte) können miteinander verglichen werden.

Damit die Visualisierung auch auf älteren Rechnern noch lädt, werden maximal Daten der letzten drei Jahre (also derzeit ab 1.1.2019) angezeigt.

Kontrollierte Vokabulare

Die Unterseite “Kontrollierte Vokabulare” bietet einen Überblick über den Anreicherungsstand der kontrollierten Vokabulare von museum-digital - sowohl allgemein als auch fokussiert auf das eigene Museum.

Hier finden sich Zahlen und Visualisierung zur Anzahl der überhaupt erfassten Akteure, Schlagworte, Zeiten und Orte; wieviele von diesen im eigenen Haus verknüpft sind; und wieviele bereits angereichert (also z.B. mit der GND verknüpft oder übersetzt) sind.

Fragen an Daten

Die Unterseite “Fragen an Daten” bietet Auswertungen von vorformulierte Abfragen, um die eigene (erfasste) Sammlung besser überblicken zu können. Bisher gestellte Fragen sind das Verhältnis von Akteuren verschiedener Geschlechter zu den erfassten Objekten, die Entfernung von mit Objekten verknüpften Orten zum Museum, und wieviele Beziehungen von Objekten zu Orten/Akteuren/Zeiten als unsicher markiert sind.

Online-Benutzung (auf Museumsebene)

Diese Unterseite bietet einen Überblick über die Entwicklung der Sichtbarkeit der Sammlung im Netz. Neben der simplen Aufstellung, wie viele Besucher die Daten des Hauses im letzten Monat aufgerufen haben, werden hier die Browsersprache der Benutzer und die Tageszeit, zu der die Seiten aufgerufen wurden, gezeigt (für diese Abfragen gilt immer nur der jeweils gestrige Tag).

Besucherstatistik

Mit der Besucherstatistik kann eine grundlegende Zählung der Besucher im Haus nach Ticket-Typen durchgeführt werden. Auf der Dashboard-Seite für die Besucherstatistik werden die so erfassten Daten übers Tag, Woche, Monat und Jahr dargestellt.

Letzte eigene Änderungen

Auf dieser Unterseite werden die letzten Bearbeitungen, die man selbst vorgenommen hat, aufgelistet. Bei Bearbeitungen von Objekten sind diese verlinkt, um ein schnelles Weitermachen an der Stelle, an der man vorher aufgehört hat, zu erleichtern.

(Öffentliche) Datenbankinhalte: Gesamte Instanz

Diese Unterseite visualisiert die öffentlichen Datenbankinhalte der gesamten Instanz von museum-digital (also z.B. museum-digital:sachsen-anhalt oder museum-digital:hessen) analog zur Unterseite für die Entwicklung der Datenbankinhalte des eigenen Hauses.

Online-Benutzung

Hier kann die Sichtbarkeit von museum-digital insgesamt nachvollzogen werden.

Werkzeuge

Die Unterseite “Werkzeuge” bietet einen Zugriff auf die schon vom alten Dashboard bekannten Funktionen zum Erstellen von QR-Codes, die Überprüfung von Links (bzw. die Korrektur für “tote” Links) und die Moderation von Kommentaren.

Mehr / Frage an

Auf dieser Unterseite gibt es weitere Infos zu den Ansprechpartnern für die gesamte Instanz von museum-digital und weiterführende Links zu anderen Diensten von museum-digital (z.B. dem Handbuch oder md:term).

Fazit

Auch wenn mit dem neuen Dashboard ein Verlust von Konfigurierbarkeit einhergeht, überwiegen die verbesserte Performance und die neuen Features sicher.

Möglich geworden ist beides erst durch einen Wechsel von Chartist zum wesentlich einfacher zu benutzenden chart.js für das Erstellen von Visualisierungen. Vielen Dank, chart.js!

info

License

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

Datenqualität bei der Erfassung von Personen

2021-05-05T00:00:00+00:00

Um die Vorzüge von Datenbanksystemen voll ausnutzen zu können, braucht es klar referenzierbare Einträge. Ein Fantasie-Beispiel: Ein Objekt wurde 1620 hergestellt von Max Mustermann, ein anderes hergestellt von Max Mustermann im Jahr 1950. Sicherlich wird das nicht derselbe Max Mustermann gewesen sein. Um zwischen den beiden Personen unterscheiden zu können, werden diese in einer Datenbank als eigener, selbstständiger Datensatz erfasst, der wiederum mit anderen Datentypen oder externen Datenbanken verknüpft werden kann.

Einerseits ermöglicht das eben die Unterscheidung zwischen verschiedenen, zuerst einmal ähnlich aussehenden Einträgen, und macht wirklich saubere verknüpfen und suchen nach z.B. Personen erst möglich. Andererseits bedeutet es eine Mehrarbeit und manchmal einen Perspektivwechsel.

museum-digital vereinfacht die Verknüpfung mit Personen durch die Benutzung eines von allen Teilnehmenden gemeinsam genutzten Vokabulars für Personen. Ist eine Personen schon aus einem anderen Museum bekannt, muss sie im eigenen Haus nicht neu erfasst werden. Im Idealfall ist der Eintrag auch schon mit z.B. der Wikipedia oder der Gemeinsamen Normdatei verknüpft. Damit die gemeinsame Benutzung der Personenliste aber funktioniert, braucht es eine minimale Datenqualität: Personen müssen mit Lebensdaten und einer Beschreibung von mindestens zehn Buchstaben erfasst werden.

Damit erzwingt das System zumindest bei der Ersteingabe von Personeneinträgen eine Recherche, die andernorts gerne vergessen wird - auch wenn sie dort ebenso sinnvoll wäre, gegeben, dass die Daten irgendwann in einen weiteren Kontext gesetzt werden sollen. Arbeit macht es natürlich trotzdem.
Unvollständig sind die automatischen Qualitätsprüfungen naturgemäß ebenfalls. Die Überprüfung, ob eine Beschreibung von 10 Buchstaben vorhanden ist, ist einfach - aber eine Überprüfung, ob es sich bei der Beschreibung um einen Blindtext handelt ist schwer.

Um also allen die Arbeit zu vereinfachen, den direkt eingebenden genauso wie der “Normdatenredaktion”, haben wir in den letzten Wochen Schritte unternommen, um die Eingabe von Personeneinträgen einfacher zu machen, und gleichzeitig das Erreichen einer höheren Datenqualität zu erleichtern.

Schnelleres erscheinen der Personenliste

Möchte man in musdb eine Person mit einem Objekt verknüpfen, wird einem zuerst eine durchsuchbare Liste der verfügbaren, dem eingegebenen Namensbestandteil entsprechenden Personeneinträge angezeigt. Leider war die Generierung der Liste lange Zeit eine der langsameren Funktionen im System. Je langsamer die Liste erscheint, desto attraktiver ist natürlich das Anlegen eines neuen Eintrags für eigentlich schon erfasste Personen, auch wenn so für die Redaktion Mehrarbeit entsteht.

Mit einem Neuschreiben der Listengenerierung konnten wir die Anzahl der benötigten Datenbankabfragen wesentlich generieren und die Generierungszeit der Liste von über 100 Millisekunden auf knapp vier Millisekunden reduzieren (den Benchmarks nach).

Ist die gesuchte Person schon erfasst, kann sie einfach aus der Liste ausgewählt werden. So wird eine doppelte Anreicherung vermieden, und die Verknüpfung und Suche von Objekten aus mehreren Museen über einen gemeinsamen Personeintrag möglich.

Besseres Erkennung von Vornamen und Nachnamen

Ist eine zu verknüpfende Person nicht aufgelistet, kann man Sie mit dem Drücken der Return-Taste neu einfügen und wird zuerst gefragt, ob es sich um eine Person, eine Institution, oder eine Sagengestalt handelt. Handelt es sich um eine Person, wird der angegebene Name in Vorname und Nachname aufgespalten.

Bisher wurde der eingegebene Name nach einer einfach Logik aufgespalten: Das letzte “Wort” des Namens (die letzte durch ein Leerzeichen abgetrennte Zeichenkette) wurde zum Nachnamen erklärt, der Rest zum Vornamen. “Luz Magsaysay” wäre also zu “Vorname: Luz”, “Nachname: Magsaysay” übersetzt. Hätte ein Benutzer versucht, “Magsaysay, Luz” einzugeben, wäre dies vom System als “Vorname: Magsaysay,”, “Nachname: Luz” interpretiert worden. Ein ähnliches Problem stellt sich bei anderen Sprachen: In Ungarisch werden Namen Prinzipiell in der Reihenfolge <Nachname> <Vorname> genannt.

Seit dieser Woche geschieht die Aufspaltung von Personennamen mit einer ausgeklügelteren Logik. Zuerst wird geprüft, ob der Benutzer eine Sprache wie z.B. Ungarisch benutzt, in der der Nachname zuerst genannt wird. In diesem Fall wird das erste “Wort” des eingegebenen Namens als Nachname verstanden, der Rest als Vornamen.

Benutzt der Benutzer musdb beispielsweise in Deutsch, wird überprüft, ob das erste “Wort” mit einem Komma beendet wird. Ist dem der Fall wird das erste “Wort” als Nachname interpretiert (nach Entfernen des Kommas), der Rest als Vorname.
Wird das Programm in Deutsch verwendet, und findet sich kein Komma am Ende des ersten “Wortes” gilt weiterhin die herkömmliche Logik: Das letzte “Wort” wird als Nachname genutzt.

Beschreibung? Wikipedia-Link!

Viele Personen sind bereits in anderen Repositorien erfasst - besonders Wikidata und den verschiedenen Sprachversionen der Wikipedia. Eine Funktion zum automatischen Laden von Informationen zum gebenen Eintrag aus Wikidata heraus gab es seit langem im Bearbeitungstool für die Vokabulare von museum-digital, nodac. Seit einigen Wochen können Eingebende in musdb diese Funktion selbst nutzen: Es gibt einen neuen Eingabeschlitz “Wikipedia-URL” auf der Personen-Eingabeseite.

Auf der Seite zur Erfassung von Personen gibt es einen neuen Eingabeschlitz ganz unten: “Wikipedia-URL”.

Ist dieser mit einer URL einer passenden Wikipedia oder Wikidata-Seite ausgefüllt, muss keine Personenbeschreibung mehr eingegeben werden. Stattdessen wird im Hintergrund die Wikidata-ID der Person aus der verlinkten Seite ausgelesen. Auf Basis dieser ID kann der neu angelegte Datensatz dann gleich tiefergehend angereichert werden: Lebensdaten und Verknüpfungen zu anderen Normdaten-Repositorien werden von Wikidata übernommen, und die Kurzbeschreibungstexte in den vorhandenen Übersetzungen aus den verlinkten Wikipedia-Instanzen kopiert.

Ohne, dass die Lebensdaten in musdb eingegeben werden mussten, konnte der Personeneintrag auf Basis von Wikipedia und Wikidata angereichert werden.

Eine kleine Hilfe beim finden der passenden URLs können vielleicht neue Links in der Toolbar geben: Mit diesen kann eine schnelle Suche in Wikidata und VIAF (und, falls der User das Programm in Deutsch benutzt, der deutschen Wikipedia und der GND), vorgenommen werden.

Insgesamt hoffen wir, dass sich so die Qualität der Daten schon bei der Eingabe verbessern lässt, und der Eingabeprozess trotzdem schneller und komfortabler wird.

info

License

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

Barrierefreiheit bei museum-digital

2021-04-23T00:00:00+00:00

Immer wieder stellt sich bei museum-digital - wie überall im Netz - die Frage der Barrierefreiheit. Als häufig öffentlich getragene Einrichtungen sollten sich Museen natürlich besonders um Fragen der Barrierefreiheit kümmern, und so haben auch wir bei museum-digital viel über das Thema nachgedacht.

In diesem Beitrag sollen die wichtigsten Design-Prinzipien und Methoden, die wir zur Sicherstellung einer zumindest ausreichenden Barrierefreiheit zusammengefasst werden.

Prinzipien

Eine wichtige Erkenntnis in unserer Befassung mit Barrierefreiheit war, dass eine gute Website, die nur aus HTML-Code besteht, quasi schon barrierefrei ist. Ein recht gutes Maß an Barrierefreiheit ist der Standard, und die Stärkung der Barrierefreiheit ist damit häufig nicht eine Verbesserung im eigentlichen Sinne, sondern nur die Unterlassung der Reduktion von Barrierefreiheit.

Daraus ergibt sich das erste und wichtigste Prinzip: Während besonders moderne Seiten mit Schnittstellen kommunizieren, um die graphische Oberfläche dann aus den einzelnen Daten im Browser zu generieren, werden alle essentiellen Daten einer Seite bei museum-digital in klassischem HTML ausgeliefert. Das bedeutet, dass man theoretisch auch ohne besondere Kenntnisse den ausgelieferten Seitenquelltext lesen könnte, und stellt sicher, dass die Seiten leicht automatisch verarbeitet werden können (sei das durch Screen Reader oder durch Google). Der Wechsel hin zu Schnittstellen, deren Rückgaben im Browser verarbeitet werden, ist aber alles andere als sinnlos: Für besonders komplexe Seiten oder weiterführende Informationen, die nicht bei jedem Seitenaufruf geladen werden müssen, ist es eine sinnvolle Maßnahme.
Das heißt für museum-digital: Essentielle Informationen einer Seite werden direkt über das HTML der Seite ausgeliefert, zusätzliche Auswertungen und Analyse-Tools können nachgeladen werden. So soll sichergestellt werden, dass alle Besucher die Inhalte der Seite möglichst einfach erreichen - Auswertungen und automatisch generierte Informationen sind nicht derart essentiell und haben entsprechend keine derart hohe Anforderung an die Barrierefreiheit.

Exemplarisch lässt sich das am Beispiel der Objektseite zeigen, etwa “hier”: Die Seite besteht grob aus 5 Seitenabschnitten.

Navigation
Seitentitel
Bild
Metadaten (Beschreibung, Ereignisse, Verknüpfungen)
Weiterführende Optionen der Seite
Ähnliche Objekte

Alle anklickbaren Links in der Navigation werden über das HTML der Seite ausgeliefert (und sind damit eben einfach erreichbar), während die Menüs zum Wechseln der Sprache und zum Suchen von Museen und Sammlungen nachgeladen werden. Die Links zur Museumsübersicht, zur Sammlungsübersicht, etc. sind essentiell, die Suche nach einzelnen Museen kann man auch von der Übersichtsseite für Museen aus durchführen, wo sie zu den essentiellen Bereichen der Seite gehört.

Der Seitentitel und das Bild sind essentielle, inhaltliche Informationen der Objektseite und werden deshalb über das Seiten-HTML ausgeliefert.

Der Bereich für Details zum Objekt (Beschreibung, Ereignisse, etc.) ist ebenso essentieller Inhalt und wird deshalb fast vollständig über das HTML der Seite ausgeliefert. Die einzige Ausnahme stellen hier die Tooltips dar, die beim Überfahren eines Schlagworts oder eines Ortseintrags mit der Maus erscheinen. Die Informationen innerhalb des Tooltips beziehen sich nicht spezifisch auf das Objekt, sondern auf das gerade überfahrene Schlagwort oder den gerade überfahrenen Ort - und sie sind über die jeweilige Schlagwortseite erreichbar. Weil sie a) nur auf Aufforderung erscheinen und b) keine ausschließlich auf dieser Seite verfügbaren Informationen zeigen, können die Tooltips nachgeladen werden, auch wenn das bedeutet, dass sie für Screen Reader nur schwer erreichbar sind.

Im Bereich der weiterführenden Optionen der Seite hängt die Art der Auslieferung hauptsächlich von der technischen Implementation ab. Der Link zur PDF-Ausgabe etwa ist ein simpler Link und wird bei jedem Seitenaufruf benötigt (ist immer sichtbar). Die Anzeige für die Entfernung des Users zum Museum, in dem sich das Objekt befindet, benötigt moderne Browser-Schnittstellen und kann daher auch nachgeladen werden.

Zu guter Letzt: Die ähnlichen Objekte. Die in diesem Abschnitt präsentierten Daten sind kein essentieller Aspekt des Objektes, sondern werden durch eine automatische Auswertung der Metadaten generiert. Dazu kommt, dass die Seite auch ohne diesen Seitenabschnitt problemlos benutzbar wäre und die Generierung des Abschnitts bis vor kurzem recht Rechenintensiv war. Aus all diesen Gründen wird dieser Seitenbereich nachgeladen und ist nicht direkt über das HTML der Seite lesbar.

Kontrastreiche Farbwahl und logische Anordnung der Elemente

Eine Ebene weniger technikfokussiert ist ein oft genannter und leicht zu verwirklichender Aspekt der Barrierefreiheit die Benutzung eines kontrastreichen Farbschemas. Beim Neudesign der Ausgabe war dahingehend die Barrierefreiheit ein wichtiger Grund für die Auswahl eines Designs mit fast ausschließlich schwarzer Schrift auf weißem Hintergrund.

Ähnlich verhält es sich mit der Anordnung der Elemente. Durch eine hoffentlich sinnvolle Reihenfolge der Informationen und die oben erläuterte Benutzung von klassischeren Web-Technologien bleibt die Seite durch die Benutzung der “Tab”-Taste navigierbar. Ist ein Link durch das Anwählen mit der Tab-Taste fokussiert, wird dies visuell hervorgehoben (siehe auch: “Easy Checks – A First Review of Web Accessibility” beim W3C).

API

Im weitesten Sinne heißt Barrierefreiheit auch die Ermöglichung einer maschinellen Auswertung der Seiteninhalte, für die die offene Programmierschnittstelle von museum-digital nicht unerwähnt bleiben sollte. Alle Seiten, die tatsächliche Inhalte präsentieren (Objekte, Sammlungen, Museen, Ausstellungen, etc.), sind neben der menschenlesbaren Ausgabe auch in einer JSON-Variante erreichbar. Die JSON-Ausgabe kann durch das Anfügen des URL-Parameters “&output=json” erreicht werden.

Falls also ein Feature fehlt oder nicht den Wünschen oder Nöten eines gegebenen Benutzers entspricht, wäre es damit technisch auch möglich, dass sich die Benutzer eine eigene Ausgabeoberfläche für museum-digital bauen.

Features

Einige Features von museum-digital lassen sich allgemein in den Bereich Barrierefreiheit einordnen.

Mit dem Dark-Mode lässt sich die Seite angenehmer in abgedunkelten Räumen benutzen. Der Dark Mode kann in der Ausgabe über die Navigation aktiviert werden, in musdb wird die systemweite Einstellung benutzt. Für Firefox-User unter Linux wie mich lässt sich der Dark-Mode durch das setzen von “ui.systemUsesDarkTheme” = “1” in about:config aktivieren.

Landmarks

Über die Benutzung von semantischem HTML in Kombination mit für die einfachere Navigierbarkeit und Auslesbarkeit ausgelegten HTML-Attributen (Accessible Rich Internet Applications) lässt sich das Springen innerhalb der Seite vereinfachen. Dies kann man etwa mit dem Browser Plugin “Landmarks” ausprobieren.

Tastensteuerung und Sprachsteuerung

museum-digital verfügt über eine dezidierte Tastensteuerung, über die man noch einmal schneller als mit Tabs oder der Maus bestimmte Seiten erreichen kann. Einige grundlegende Tastenkombinationen etwa zum Suchen nach Museen, Sammlungen, oder Objekten können hier gefunden werden.
Viele weitere Tastenkombinationen sind - inspiriert vom Text-Editor Emacs - erreichbar, wenn man STRG+e drückt. Am unteren Bildschirmrand öffnet sich eine Eingabezeile, mit der man den passenden Befehl auswählen kann. Alternativ kann man die Liste mit STRG+r “aufklappen”, um eine leichter überschaubare Liste der verfügbaren Kommandos zu bekommen.

Kontrolle ist besser

Gute Prinzipien bilden eine Basis, um weniger falsch und mehr richtig zu machen. Unvollständigkeiten, etwa beim setzen von passenden Landmarks, passieren aber immer wieder. Deshalb überprüfen wir neu angelegte Seiten mit den Browser-Plugins Lighthouse - einem generell sehr hilfreichen Tool zur Optimierung von Webseiten auch abseits der Barrierefreiheit - und WAVE.

Bild: Chrome mit Lighthouse

Eine Objektseite bei museum-digital:hessen wird mit Lighthouse überprüft. Rechts ist die Auswertung sichtbar.

info

License

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

"Schlauere" Eingabe von Vokabularbezügen

2020-09-21T00:00:00+00:00

Bei vielen Importen von Daten, sind wir mit Orten wie “Berlin ?” und Zeiten wie “ca. 1328” konfrontiert. Das Import-Tool von museum-digital kann schon seit längerer Zeit mit solchen Angaben umgehen: “Berlin ?” heißt, nach Lesart von museum-digital: “Berlin”, aber die Ortsangabe im Ereignis ist ungewiss.

Ähnlich verhält es sich bei Zeiten, die sehr verschieden Eingegeben werden können. Die übliche “Basis”-Schreibweise für Zeiten in der Datenbanktabelle für Zeiten ist das deutsche TT.MM.JJJJ, aber häufig werden Zeiten wie “15. Januar 1920” eingegeben oder importiert. In vielen Fällen lassen sich diese automatisch in die normalisierte Form umwandeln - was wir im Vokabularkontroll-Tool (nodac) schon länger tun.

Beide Funktionalitäten, das automatische Erkennen von Ungewissheit aus dem Import-Tool und das Normalisieren von Zeit-Angaben aus nodac, haben wir im Zuge einiger sehr großer Importe (dazu später vielleicht mehr) überarbeitet und in ein eigenes Modul verschoben, sodass wir sie auch ins eigentliche Eingabetool musdb einbauen konnten.

Erkennen von Ungewissheit und Zeiten in musdb

musdb kann also jetzt Ungewissheit auf Basis von Listen von bekannten Indikatoren erkennen. Bei Zeiten sind das beispielsweise “um “, “wohl um “, “circa “, “ca. “ oder “ca “ am Beginn des eingegebenen Zeitnamens und “(?)” oder “?” am Ende der Eingabe. Wird einer dieser Indikatoren erkannt, wird er aus dem Zeitnamen gelöscht und die Angabe als unsicher gespeichert. Analog funktioniert es bei Akteurs- und Ortsangaben.

Eingabe einer Ortsangabe mit Indikator für Unsicherheit.

Ist einer der Indikatoren für Unsicherheit Teil der Ortsangabe, werden Orte als ungewiss erkannt.

Besonders bei Zeiten ist, dass diese, so erkennbar, auch automatisch normalisiert werden können. Deutsche und ungarische Zeitgaben von einzelnen Tagen (15. Januar 1920) oder Monaten (Januar 1920) können so ausgelesen werden.

Eingabe einer ungewissen Zeit in normalisierbarer Form.

Screenshot: Zeiten werden normalisiert und als ungewiss erkannt, wo nötig und möglich.

Einher mit der Normalisierung geht in vielen Fällen auch eine automatische Übersetzung. Dies ist besonders wichtig für Zeit-Angaben vor 1000 n. Chr., bei denen wo möglich eine automatische Angabe dazu gemacht wird, ob die Zeit vor oder nach Christus ist. Bisher ist dies für Zeitspannen implementiert. “312 - 315” wird automatisch zu “312-315 n. Chr” in Deutsch umgewandelt und in “312-315 CE” auf English und “西暦312年から315年” in Japanisch übersetzt.

Leichteres Massen-Veröffentlichen und Verstecken von Objekten

Eine kleine Erweiterung an anderer Stelle, ist, dass die Objektauswahl jetzt zur Veröffentlichung oder zum Verstecken von Objekten genutzt werden kann.

Veröffentlichen und verstecken über die Objektauswahl. Die Schalter für das Verstecken sind oben rechts rot eingerahmt.

info

License

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

Mehr Stabilität und einige neue Features

2020-09-15T00:00:00+00:00

In den letzten Monaten waren wir bei der technischen Weiterentwicklung von museum-digital nicht untätig. Vor allem haben wir “unter der Haube” viele kleine Details verbessert und den Code aller Tools von md nachvollziehbarer und für Programmierer wie Rechner eindeutiger gemacht. Während die meisten dieser Änderungen rein technischer Natur sind und hoffentlich nicht auffallen, dürfte die Geschwindigkeit der (Objekt-)Suche vor allem im Eingabebereich von größeren regionalen Instanzen doch auch spürbar verbessert sein.

Aber auch ein paar sichtbarere, neue Features sind dazugekommen: Eigene veröffentlichbare Bereiche zur Erfassung von Markierungen (Stempel, Wasserzeichen, etc.), der Publikationsgeschichte des Objektes, und ob das Objekt selbst eine Referenz auf ein anderes Werk ist. Da das Feld für die Objektart bei museum-digital ein Freitextfeld ist, aber eine Kontrolle des Feldinhaltes oft naheliegend erscheint, gibt es bei diesem Feld jetzt eine Ausfüllhilfe. Als wahrscheinlich wichtigste Neuerung gibt es ab jetzt 10 neue Ereignistypen und die Möglichkeit - den Notwendigkeiten der (Provenienz-)Forschung gemäß - Quellenangaben für Ereignisse einzutragen.

Markierungen

Besonders für Kollegen aus der Kunstgeschichte sind nachträglich am Objekt angebrachte Markierungen - Stempel, Wasserzeichen, Signaturen, Gravuren, etc. - wichtig. Bisher konnten diese nur relativ unspezifisch im Feld “Beschriftung / Inschrift” verzeichnet werden. Um eine eindeutigere und uniformere Erschließung von Markierungen aller Art zu ermöglichen, haben wir einen neuen Eingabe- und Ausgabebereich für Markierungen eingeführt. Der Begriff “Markierungen” ist hierbei Möglichst allgemein gewählt, da das Feld auch für andere Arten von Museen, die mit Logos o.ä. arbeiten, interessant sein könnten.

In musdb, dem Eingabe- und Inventarisierungstool von museum-digital, lässt sich der neue Bereich für die Erfassung von Markierungen ganz unten auf dem Reiter “Zusatz” der Einzelobjekt-Seite finden. Ist noch keine Markierung verzeichnet, findet sich hier eine Akkordion-Leiste “Eine neue Markierung erfassen”. Diese lässt sich mit einem Klick öffnen, sodass die Eingabefelder für neue Markierungen sichtbar werden.

Eine ausgefüllte “Markierung”: Carl Morgensterns Signatur unten rechts auf einem Gemälde.

Möchte man nun eine Markierung eintragen, müssen zuerst einmal Art und Position aus den dafür vorgesehenen Listen ausgewählt werden. Danach lassen sich neben Maßangaben und dem Text der Markierung auch deren Erschaffer und etwaige in der Markierung vermerkte Daten erfassen. Letztere kommen aus den dafür vorgesehenen Vokabularen. Um also etwa eine Person einzutragen, klickt man ins Feld “Erschaffer” und beginnt den Namen zu tippen. Ist die gemeinte Person schon bekannt, erscheint ihr Name in einer Auswahlliste und kann durch einen Klick eingetragen werden. Ist die Person nicht bekannt, kann Sie über einen Klick auf das “+”-Symbol vor dem Eingabeschlitz eingetragen werden. Vorsicht: Für die Eingabe neuer Personen oder Zeiten an dieser Stelle öffnet sich ein neuer Tab, sie geschieht also getrennt von den vorherigen Eingaben.

Ist eine Markierung so eingegeben, ist sie auch öffentlich sichtbar (eine Möglichkeit Markierungen zu verstecken ist angedacht, aber noch nicht implementiert).

Markierungen in der Ausgabe von museum-digital (Oben links).

Referenzen und Rezeption

Mit dem Reiter “Rezeption” ist ein ganz neuer Reiter hinzugekommen, der die spezifische Beziehung von Objekten zu Publikationen abbildet. Während die “einfachen” Literaturangaben das Objekt unspezifisch mit Literatur zum Objekt, zum Kontext des Objektes, etc. verknüpfen, kann die Beziehung des Objektes zu Literaturquellen hier eindeutiger erfasst werden.

Graphisch und von der Benutzung her gesehen, grob wie der neue Bereich für Markierungen gestaltet, bildet der Bereich “Rezeption” die Veröffentlichungsgeschichte eines Objektes ab. Ist das Objekt etwa eine Fotographie oder ein Gemälde, die oder das in einem Ausstellungskatalog abgedruckt wurde, kann dies hier verzeichnet werden. Gleiches gilt für ein Fahrzeug, das in einem Magazin besprochen wurde, zumindest falls exakt das im Museum vorhandene Fahrzeug besprochen wurde (etwa bei Sonderanfertigungen). Das Gegenstück bildet der “Referenz”-Bereich, in dem vermerkt werden kann, wenn das Objekt selbst eine Referenz auf eine Publikation bildet. Ein offensichtliches Beispiel sind Illustrationen von oder zu Texten.

Reiter für Rezeption und Referenzen auf der Objekt-Bearbeitungsseite in musdb.

Wichtig zu beachten ist hierbei der Unterschied zwischen Literaturangaben im Literaturmodul und den hier genutzten “Quellen”. Das Literaturmodul ist auch für die Hausbibliothek vorgesehen ist, mit entsprechenden Datenfeldern wie “Signatur”, und entsprechend werden Einträge im Literaturmodul für jedes Museum einzeln gespeichert. Einerseits ermöglicht das eine breitere Eingabe von Daten, andererseits steht es einer uniformen und gemeinsamen Nutzung von Eingaben durch viele Museen entgegen. Deshalb wird hier das neue, zentral kontrollierte “Quellen”-Vokabular verwendet, das wesentlich stärker auf einheitliche Verknüpfungen ausgelegt ist und über das Vokabularkontroll-Tool zentral gesteuert wird.

Das Objekt selbst referenziert eine Textstelle. Hier: Goethes Werther.

Ausfüllhilfe für Objektart

Eine sehr kleine, aber vielleicht doch hilfreiche Verbesserung, ist die neue Ausfüllhilfe für die Angabe zur Objektart bei neu eingegebenen Objekten. Das Feld für Objektart ist bei museum-digital ein Freitextfeld, dessen Funktion weitestgehend durch Schlagworte erfüllt wird. Da es jedoch in vielen Museen gewünscht wird, nur eine kontrollierte Anzahl von Angaben zur Objektart zuzulassen, erscheinen jetzt Vorschläge für eine möglichen Eingabe, wenn man die Objektart eintippt.

Diese Vorschläge kommen aus dem zentralen Schlagwort-Vokabular, und lassen sich durch anklicken in das Feld eintragen. Wurde ein Schlagwort aus der Liste gewählt, wird das Objekt automatisch auch mit dem entsprechenden Schlagwort verknüpft.

JSON-LD für Einzelbildseite

Seit letzter Woche finden sich auf den Seiten einer einzelnen Objektabbildung JSON-LD-Metadaten für die Bestimmung von Bildlizenzen und Rechten. Während sich für die Museen nichts ändert, kann Google so besser mit den Bildern umgehen und kennzeichnet Sie als z.B. “Lizensierbar”.

Google erkennt Lizenzangaben zu Bilddateien jetzt besser.

Ereignisse: Neue Ereignistypen und Quellenangaben für Ereignisse

Die wahrscheinlich wichtigste - weil alltäglich sichtbare - Neuerung sind die neu angelegten Ereignistypen:

Zusammengefügt (für die finale Zusammenstellung eines Objektes, das aus mehreren Teilen besteht)
Versteigert
Gekauft
Besessen
Verkauft
Restauriert
Beschädigt
Zerstört
Verschollen
Herausgegeben (für Bücher und andere Publikationen, die einen Herausgeber haben)

Die meisten dieser neuen Ereignistypen beschäftigen sich mit Informationen, die für die Veröffentlichung und Nachvollziehbar-machung von Provenienzen wichtig sind. Hiermit geht museum-digital einen großen paradigmatischen Schritt, weil Provenienzinformationen bis jetzt bewusst nur in Freitextfeldern veröffentlichbar waren. Museen, die die neuen Ereignistypen verwenden wollen, sollten unbedingt (!) prüfen, ob sie die Informationen veröffentlichen dürfen und durch die Veröffentlichung keine Persönlichkeitsrechte Dritter verletzen - das ist wichtiger denn je, wenn Provenienzen leichter durchsuchbar sind.

Wenn die Ereignisse bei museum-digital aber schon einmal für Provenienzangaben fit gemacht werden, dann können wir auch einen Schritt weiter gehen und die für die Provenienzforschung fehlende Information - Quellen - erfassbar machen (Vergleich: “Leitfaden zur Standardisierung von Provenienzangaben” des Arbeitskreis Provenienzforschung e.V.). Basierend auf demselben Quellen-Modul, das für den Reiter zu Referenz- und Rezeption gebraucht wird, lassen sich ab jetzt auch Quellen für Ereignisse eingeben.

Um das zu tun, muss erst einmal ein Benutzer mit dem Level “Museumsdirektor” die Eingabe von Quellenverweisen für Ereignisse für das ganze Museum freischalten.

Die Möglichkeit, Quellenverweise für Ereignisse einzutragen, kann in den Einstellungen fürs Museum aktiviert werden.

Dies kann auf der Seite “Einstellungen für das Museum” im Eingabebereich getan werden. Ist die Eingabe von Quellenangaben für Ereignisse einmal aktiviert, erscheint bei allen Mitarbeitern des Museums ein neuer Bereich unten auf den Bearbeitungsseiten für Ereignisse (erreichbar, indem man bei einem einmal angelegten Ereignis auf den Namen des Ereignistyps klickt). Auch hier findet sich wieder ein Akkordion, das aufgeklappt werden kann, um neue Quellenangaben zu machen.

In der Ausgabe von museum-digital spiegelt sich die Möglichkeit, Quellenangaben zu machen zuallererst in einer Neugestaltung der Anzeige von Ereignis-Anmerkungen wieder. Ereignisanmerkungen erschienen jetzt gemeinsam mit etwaigen Quellenangaben in einem Tooltip, der durch überfahren eines “i”-Symboles hinter dem Ereignistyp auf einer gegebenen Objektseite zu finden ist.

Quellenangaben und Anmerkungen zu Ereignissen werden jetzt in einem Tooltip angezeigt.

Beitragsbild: Caravaggio: “Der ungläubige Thomas” (CC BY-NC-SA @ Stiftung Preußische Schlösser und Gärten Berlin-Brandenburg / Murza, Gerhard)

info

License

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

Mehrsprachige Zeitbegriffe

2020-06-10T00:00:00+00:00

Im letzten Jahr haben wir die Möglichkeit zur Übersetzung von Orten, Akteuren und Schlagworten in den kontrollierten Vokabularen von museum-digital eingeführt. Dies war die Grundlage für das Zusammenführen der deutschsprachigen und der ungarischen Vokabulare, die bis dahin getrennt erfasst wurden, in eine Datenbank - und schlussendlich für die Einrichtung der “globalen” Instanz von museum-digital.

Bisher nicht übersetzbar waren Zeitbegriffe, sodass deutsche und ungarische Zeitbegriffe, die z.B. denselben den selben Tag abbilden, bisher als zwei verschiedene Zeiten geführt werden mussten. Auch für “normale” Benutzer wirkt sich das dadurch aus, dass ungarische Zeitbegriffe in den Auswahllisten in der deutschsprachigen Eingabe in musdb und in der Auswahlliste für Zeiten in der erweiterten Suche der Ausgabe erscheinen.

Um an dieser Stelle Abhilfe zu schaffen, haben wir jetzt die Möglichkeit eingerichtet, auch Zeitbegriffe zu übersetzen und - so vorhanden - übersetzt anzuzeigen.

Die Bearbeitungsseite für Zeitbegriffe (hier “Vor 1721”) in nodac wurde um einen Bereich zur Übersetzung erweitert.

Beitragsbild: “Wanduhr (Kake Tokei), Japan, 19. Jahrhundert”, CC BY-SA @ Deutsches Uhrenmuseum / Deutsches Uhrenmuseum

info

License

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

OpenSearch: museum-digital direkt aus der Browser-Leiste durchsuchen

2020-06-05T00:00:00+00:00

OpenSearch ist ein offener Standard zur Beschreibung von Suchfunktionen auf Webseiten. Unterstützt eine Webseite OpenSearch, dann erkennen Browser das und bieten an, dass die Webseite als zusätzliche Suchmaschine installiert werden kann.

Besonders schön dabei ist, dass OpenSearch sich in nur wenigen Zeilen Code implementieren lässt. Dazu mehr weiter unten im Text. Zuerst die gute Nachricht: Die Ausgabe von museum-digital und musdb unterstützen OpenSearch jetzt für ihre jeweiligen Objekt-Suchfunktionen. Beide lassen sich jetzt also direkt aus der Browser-Such-Leiste heraus durchsuchen, genauso wie es Standardmäßig für Google und Wikipedia möglich ist.

Oben rechts erscheint ein grünes “+”-Symbol neben der Lupe der Browser-Suchfunktion.

Damit lässt sich die jeweilige Instanz von museum-digital als zusätzliche Suchmaschine im Browser installieren.

Weil musdb keine “einfache” Suche nach einen unqualifizierten, nicht näher beschriebenen Suchbegriff unterstützt, wird dort die Volltextsuche verwendet.

OpenSearch implementieren

Für die Implementation von OpenSearch braucht es nur zwei Bausteine. Einerseits eine einfache XML-Datei, die Informationen zur zu beschreibenden Suchfunktion in kurzer und knapper Form erhält. Hier wird etwa die Suche der weltweiten Instanz von museum-digital beschrieben:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <ShortName>md:global</ShortName>
  <Description>Search museum-digital: global</Description>
  <Tags>museums collections objects exhibitions</Tags>
  <Url type="application/rss+xml"
       template="https://global.museum-digital.org/search.php?navlang=en&sv={searchTerms}&output=rss"/>
  <Url type="text/html"
       template="https://global.museum-digital.org/search.php?navlang=en&sv={searchTerms}"/>
  <LongName>museum-digital</LongName>
  <Image height="64" width="64" type="image/jpeg">https://global.museum-digital.org/db_images_gestaltung/mdlogo-64px.png</Image>
  <Image height="16" width="16" type="image/vnd.microsoft.icon">https://global.museum-digital.org/favicon.ico</Image>
  <Query role="example" searchTerms="Tag" />
  <Developer>museum-digital</Developer>
  <SyndicationRight>open</SyndicationRight>
  <AdultContent>false</AdultContent>
  <OutputEncoding>UTF-8</OutputEncoding>
  <InputEncoding>UTF-8</InputEncoding>
</OpenSearchDescription>

Die wirklich interessanten Felder beschränken sich auf ShortName, Url, und Image, die jeweils für die entsprechende Instanz angepasst werden mussten. Ein Problem stellt dabei die Vorgabe dar, dass der ShortName nicht länger als 16 Buchstaben sein darf, sodass wir für den Anfang auf ein fest im Code stehendes “md” statt “museum-digital” zurückfallen mussten.

Ist die XML-Beschreibung der Suchfunktion einmal fertig geschrieben und aus dem Netz erreichbar, müssen nur noch alle Seiten auf die Suchfunktion verweisen. Ist, wie bei museum-digital, die Erstellung der Seiten-Metadaten für verschiedene Seiten in einer Funktion zusammengefasst, lässt sich das mit dem Einfügen einer einzigen Zeile erreichen:

<link rel="search" type="application/opensearchdescription+xml" href="https://global.museum-digital.org/opensearch/objects.xml" title="md:global" />

Zu beachten ist dabei, dass das title-Attribut denselben Wert haben muss, wie der vorhin im XML eingetragene ShortName.

Links

info

License

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

Überarbeitete Login-Seite in musdb

2020-04-22T00:00:00+00:00

Über das Wochenende haben wir die Login-Seite von musdb überarbeitet. Neben der offensichtlichen Login-Funktion bietet die überarbeitete Seite - zumindest auf großen Bildschirmen - eine Übersicht von neuen Blogbeiträgen und Statistiken von öffentlichen Datenbankinhalten. Die einzelnen Teile der überarbeiteten Login-Seite werden im folgenden anhand von Screenshots kurz erläutert.

Die überarbeitete Login-Seite von musdb in Gänze.

Seitenbestandteile

Oben links:
Bildschirmausschnitt zeigt den Login-Bereich auf der Login-Seite von musdb.

Unten links:
Bildschirmausschnitt, zeigt die Fußzeile / Links auf der Login-Seite von musdb. Die Fußzeile verlinkt relevante andere Seiten von museum-digital, etwa das Handbuch.

Oben rechts:
Sofern neue, für die jeweilige Instanz von museum-digital oder die Benutzung von musdb relevante, Blogeinträge vorhanden sind, werden diese oben rechts auf der Login-Seite eingeblendet.

Unten rechts:
Bildschirmausschnitt, zeigt den Bereich für Statistiken auf der Login-Seite von musdb.

Auf kleinen Bildschirmen

Um ein schnelles Laden auch bei eingeschränktem Datenvolumen oder langsamen Verbindungen auf Handys nicht zu erschweren, werden Hintergrundbild und zusätzliche Informationen nur geladen, wenn ein ausreichend großer Bildschirm zur Verfügung steht.

Die Login-Seite auf Handy-Bildschirmen. Zusätzliche Informationen wie das Hintergrundbild werden nicht geladen.

info

License

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

Abbildungen in musdb durchsuchen

2020-04-21T00:00:00+00:00

Über das Osterwochenende haben wir die Funktionen zur Verwaltung von Abbildungen in musdb wesentlich erweitert und verbessert. Eine Seite dazu ist im Handbuch bereits geschrieben, daher sei hier darauf verwiesen.

Update (12.10.2020): Link aktualisiert.

info

License

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

FAQ des Museumsverbandes RLP zu Museen und Coronavirus

2020-03-30T00:00:00+00:00

Der Museumsverband Rheinland-Pfalz hat einen kurzen und sicherlich nicht nur für rheinland-pfälzische Museen hilfreichen FAQ für den Umgang mit Coronavirus und Kontaktverbot veröffentlicht, der nach und nach vervollständigt wird. Finden lässt sich der FAQ auf der Webseite des Museumsverbandes.

Nachtrag (31.03.2020): Auch einige andere Museumsverbände und ihre Äquivalente veröffentlichen Informationen zum Umgang mit dem Coronavirus und seinen Auswirkungen:

Die Landesstelle für Museumsbetreuung (Baden-Württemberg) informiert über finanzielle Soforthilfen für Museen in Baden-Württemberg
Der hessische Museumsverband sammelt hier Links, besonders für Hessen

info

License

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

Rückgaben des Resolvers anpassen

2020-03-12T00:00:00+00:00

Im letzten Monat haben wir bei museum-digital den (auf technischer Seite) wahrscheinlich größten Schritt der letzten Jahre gemacht: Wir haben die ungarische Instanz in viele Teil-Instanzen aufgespalten und unsere kontrollierten Vokabulare in eine Datenbank zusammengeführt. Damit konnten wir eine globale Instanz einrichten, die zumindest im Bezug auf Suchfunktionen und Verschlagwortung vollständig mehrsprachig funktionieren kann. Einen Blogeintrag bleiben wir leider erst einmal schuldig, aber auch abseits dessen entwickelt sich museum-digital fort.

Damit es nicht untergeht, sollen hier zwei neue, zusätzliche Optionen zur Benutzung des Resolvers besprochen werden. Beide sind aber auch beim Aufrufen des Resolvers ohne weitere Parameter dokumentiert.

“Einfache” Beacon-(Konkordanz-)Listen

Eine traditionelle Beacon-Datei besteht neben ihrem “Kopf” aus einer Liste, grob gemäß CSV, in auf der einen Seite eines Trennzeichens jeweils eine ID aus einem Repositorium aufgelistet wird, und auf der anderen Seite des Trennzeichens die ID derselben Entität in einem anderen Repositorium. Mittlerweile ist eine alternative Form dazugekommen, in der nur noch die IDs verfügbarer Einträge aus dem “Quell-Repositorium” (etwa die GND) aufgelistet werden, und in der der “Kopf” der Datei Auskunft über eine URL gibt, die auf den richtigen Eintrag im lokalen Repositorium (hier eine Instanz von museum-digital), der über die ID im Quell-Repositorium aufgerufen werden kann, verweist.

Eine solche Liste kann nun über das Anfügen des GET-Parameters “beaconHideLocal” eingetragen werden. https://global.museum-digital.org/resolver/actor/gnd gibt eine Liste aller Akteure, die sowohl in der Gemeinsamen Normdatei (GND) als auch bei museum-digital erfasst sind, mit beiden IDs zurück. https://global.museum-digital.org/resolver/actor/gnd?beaconHideLocal=1 gibt im Gegensatz dazu eine “einfache” Beacon-Datei zurück, die alle GND-IDs auflistet, die Entsprechungen in museum-digital haben.

“No-Referral”: Text statt Weiterleitungen

Ein weiterer kleiner Zusatz ist das Hinzufügen einer Option, um Suchen nach einer ID direkt die URL, auf die weitergeleitet werden würde als Text zu bekommen. Je nach benutzter Programmiersprache kann so das automatische Arbeiten mit dem Resolver wesentlich erleichtert werden.

Ein Beispiel: Ruft man https://global.museum-digital.org/resolver/place/geonames/2950159 auf, wird man auf des Ortes weitergeleitet, der bei Geonames die ID 2950159 trägt (das ist Berlin). Diese Weiterleitung geschieht über HTTP-Header. Möchte man aber eigentlich nur die URL, auf die man weitergeleitet würde, erfahren, kann man jetzt https://global.museum-digital.org/resolver/place/geonames/2950159?noReferral=1 aufrufen und erhält nur diese als Text.

info

License

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

Textbausteine in musdb verwenden

2020-02-16T00:00:00+00:00

museum-digital hat viele eher versteckte Funktionen, die gezielt nicht übermäßig sichtbar sind, um den Fokus der Bearbeitenden nicht allzu sehr von der tatsächlichen Bearbeitung weg zu lenken. Eine davon ist die Textbaustein-Funktion in musdb, unserem Eingabe- und Inventarisierungs-Tool. Bisher war diese nur in einer Präsentation von 2018 beschrieben - deshalb dieser Blogpost.

Die Textbausteine in musdb werden auf Feld-Ebene festgelegt. Bevor die Textbaustein-Funktion benutzt werden kann, muss also erst einmal festgestellt werden, für welches Feld sie einzusetzen ist. Dafür reicht ein Klick in das gewünschte Feld - dieser führt gleichzeitig zum erscheinen eines Indikators am unteren rechten Bildschirmrand.

Der Feld-Indikator öffnet sich am unteren rechten Bildschirmrand, sobald ein Eingabefeld aktiv ist (etwa nach einem Klick ins Feld).

Dieser Indikator liefert einerseits Auskunft über Basisinformationen zum Feld und zur bisherigen Eingabe (Pflichtfeld oder nicht; Verhältnis von bisherigen Eingaben zur maximal erlaubten Anzahl von Buchstaben im Feld). Andererseits befinden sich ganz unten im Indikator Buttons für zusätzliche, Feld-spezifische Funktionen.

Großansicht des Feld-Indikators. Am unteren Rand befinden sich weiß hinterlegte Buttons. Das “Wiederholen”-Symbol (ganz links) führt zur Textbaustein-Funktion.

Ein Klick auf das Wiederholen-Symbol (im Screenshot ganz links) öffnet eine Seitenspalte für die Textbausteine. Alternativ kann man, wenn ein Feld angewählt ist, die Tastenkombination STRG+r verwenden, um die Textbaustein-Seitenspalte zu öffnen.

Die Textbaustein-Seitenspalte listet die verfügbaren Textbausteine auf. Am unteren Ende der Seitenspalte findet sich ein Eingabefeld um neue Textbausteine anzulegen.

Die nun am rechten Bildschirmrand erscheinende Seitenspalte besteht einerseits aus einer Liste der schon eingefügten Textbausteine, andererseits aus einem Eingabefeld um neue Textbausteine anzulegen. Mit einem Klick auf einen Textbaustein aus der Liste oder das Drücken der entsprechenden Nummer auf der Tastatur (während die Seitenspalte geöffnet ist) lässt sich ein Textbaustein in das vorher angesteuerte Eingabefeld kopieren.

Beim Neu-Anlegen von Textbausteinen ist zu beachten, dass pro Feld nur 9 Textbausteine gespeichert werden können. Diese Beschränkung fungiert gleichzeitig als Lösch- und Sortierfunktion: Wird ein neuer, zehnter Textbaustein angelegt, wird der älteste Vorhandene gelöscht und die Nummerierung entsprechend angepasst.

info

License

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

Alle Auswählen in der Objektauswahl in musdb

2020-02-12T00:00:00+00:00

Seit dem Wochenende haben wir bei museum-digital ein großes und lange angedachtes Projekt erledigt. Dazu später mehr. Unabhängig davon haben wir die “Objekte auswählen”-Funktion in musdb ein kleines bisschen verbessert. Über die Tastenkombination <STRG+a> lassen sich jetzt alle auf einer Übersichtsseite angezeigten Objekte auswählen. Um diese Tastenkombination nutzen zu können, muss man allerdings zuerst in den “Objekte auswählen”-Modus, indem man lange auf ein Objekt klickt.

info

License

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

Türkçe

2020-02-04T00:00:00+00:00

Die Ausgabe von museum-digital ist jetzt fast vollständig auf Türkisch übersetzt! Da die Mehrsprachigkeit von Schlagworten und Akteuren, Orten und Zeiten Übersetzungen in der Navigationssprache des Benutzers anzeigt, sind so jetzt auch die Schlagworte etc. erstmals auf Türkisch ausspielbar.

Ein Screenshot der Ausgabeseite von museum-digital in Türkisch. Zu sehen ist die Seite für die erweiterte Suche.

Beitragsbild: “Erwachendes Mädchen” von Eva Gonzalès, Kunsthalle Bremen - Der Kunstverein in Bremen (CC BY-NC-SA)

info

License

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

"Nicht mehr als 20": Maximale Anzahl von Bildern beim Upload

2020-02-03T00:00:00+00:00

Ein Feuerzeug ist ein Objekt. Mit einem oder vielleicht zwei Abbildungen. Ein Buch ist ein Objekt. Mit gegebenenfalls hunderten Abbildungen - einer pro Seite.

Um die Bearbeitung in letzterem Fall zu vereinfachen, bietet musdb die Möglichkeit mehrere Abbildungen gleichzeitig heraufzuladen. Beschränkt wird diese allerdings durch die maximale Größe von Dateiuploads und die maximale Anzahl von Dateien, die auf einen Schlag heraufgeladen werden können. Letzteres führte in letzter Zeit immer wieder zu Problemen, weshalb wir jetzt eine Warnung eingebaut haben.

Wichtig für das Verständnis ist hierbei, dass die meisten Tools von museum-digital in PHP implementiert sind. PHP hat (leider) die Tendenz, mit nicht korrekten Eingaben fehlerhaft weiterzulaufen, statt schlicht abzubrechen und eine Fehlerlösung zu erzwingen.

Im konkreten Fall von zu vielen gleichzeitig hochgeladenen Dateien trifft das besonders zu: Auch wenn 30 Bilddateien zum Upload ausgewählt sind, kommen überhaupt nur 20 (unsere derzeitige Servereinstellung für die maximale Anzahl von Dateien bei einem Uploadvorgang) bis zum Script, das den Upload entgegen nimmt, an. So wurden die 20 Bilder hochgeladen, die beim Script ankamen. Alle anderen nicht.

Das führt zu Verwirrung und vielleicht sogar fehlenden Daten. Damit das nicht passiert, haben wir eine Warnung eingebaut, die User davon abhält mehr als 20 Dateien gleichzeitig heraufzuladen.

info

License

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

"Treffer auflisten"-Funktion verbessert

2020-02-03T00:00:00+00:00

Auf Anregung der Kollegen aus Brandenburg haben wir einige Beschränkungen der “Treffer auflisten”-Funktion in musdb, die auch für den Excel-Export verantwortlich ist, ausgebaut - wo man einmal dabei ist - die Performance wesentlich verbessert.

Neu ist vor allem ein Button, um alle verfügbaren Spalten direkt in einem Spreadsheet zu exportieren. Dieser findet sich oben rechts neben dem Link zum bisherigen Spreadsheet-Export-Knopf zum Exportieren der gerade ausgewählten Spalten.

Beim Implementieren dieses Buttons fiel auf, dass bisher überhaupt nur 26 Spalten exportiert werden konnten (A-Z). Dieser Fehler wurde behoben. Ein zweites Problem stellte die Performance der Seite dar: Sie war im Rahmen der großen Überarbeitung von 2018 nicht verbessert worden, und so brach der Export bei größeren Filtermengen bald ab. Durch eine Optimierung vor allem der Datenbankabfragen ließ sich aber auch dieses Problem lösen. Quasi als Beifang haben wir dabei die Sortierung nach Akteuren und Orten korrigiert.

Eine kleine Verbesserung der Benutzeroberfläche ist, dass die Schalter für die Auswahl der angezeigten Spalten jetzt als Tabellenköpfe formatiert sind und beim Scrollen mit der Tabelle mitfahren. Tabellen mit mehr als 10 Spalten sind nicht mehr an die Bildschirmbreite als Maximalbreite gebunden.

Zu guter Letzt haben wir die Schlagworte in der “Treffer auflisten”-Funkion zugänglich gemacht.

Oben, als zweites von rechts befindet sich der “Alle Spalten exportieren”-Button.

info

License

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

Überarbeiteter Blog

2020-02-03T00:00:00+00:00

Während das Jahr 2018 bei museum-digital auf technischer Seite von großen, sichtbaren Verbesserungen gekennzeichnet war, war das Jahr 2019 von kleinen, wenig sichtbaren Veränderungen gekennzeichnet. Damit einher ging leider auch, dass viele kleine Veränderungen nicht ausreichend kommuniziert wurden - sowohl innerhalb Deutschlands, als auch mit den Benutzern in Ungarn und anderswo.

Statt darauf zu warten, dass sich genug Änderungen ansammeln, die dann zusammengefasst per Mail besprochen werden können, werden wir also in Zukunft versuchen, kurze Blogposts zu jeder merklichen Veränderung zu schreiben. Diese sollen auch ins Englische übersetzt, oder zumindest auf Englisch zusammengefasst werden, sodass Kollegen, die des Deutschen nicht mächtig sind, ebenfalls informiert sind.

Da Wordpress eine komfortablere Eingabeoberfläche - gerade auch fürs mobile Bloggen - und bessere Möglichkeiten für mehrsprachige Einträge bietet, als unser altes Blogsystem (Serendipity) das tat, haben wir uns entschieden umzuziehen.

Umzugsprobleme

Für die Migration von Serendipity zu Wordpress gibt es ein Import-Tool, dass auch nach 7 Jahren weiterhin relativ gut funktioniert: s9y-to-wp.

Perfekt war die automatische Migration aber leider nicht. User-Konten und damit die Information über die Autoren der alten Beiträge wurden leider nicht oder nicht korrekt übertragen. Manche Beiträge sind deshalb leider noch falsch attribuiert.

info

License

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

Mehrsprachigkeit in md:term

2020-02-02T00:00:00+00:00

Seit dem letzten Wochenende ist das letzte öffentliche Tool von museum-digital endlich auch vollständig mehrsprachig: md:term. md:term ist die zentrale öffentliche Ausgabe für unsere kontrollierten Vokabulare für Akteure, Orte, Schlagworte, und Zeiten.

Wichtig dabei ist die Programmierschnittstelle von md:term, die etwa in der “Graphennavigation” zum Einsatz kommt, und auch für externe Programmierer offen steht. Weil wir hier - wie auch sonst - im Sinne einer größeren Offenheit keine Authentifizierung für die Benutzung der API verlangen, gibt es leider keine vollständige Liste der Projekte, die md:term benutzen. Deshalb richtet sich dieser Blogeintrag vor allem an eben jene Benutzer der API.

Wie wird die Mehrsprachigkeit der Einträge implementiert und wie zeigt sie sich in md:term?

Wir haben die Mehrsprachigkeit als tatsächliche Übersetzungsfunktion implementiert, in dem Sinne, dass es eine Basis-Tabelle - in der Ausgangssprache, also Deutsch oder Ungarisch - und eine Übersetzungstabelle mit Übersetzungen in knapp 25 Sprachen, die aus Wikidata ausgelesen werden (soweit möglich). Ist eine Übersetzung in der vom User angeforderten Sprache vorhanden, wird der gegebene Eintrag beim Ausgeben durch den Eintrag aus der Übersetzungstabelle ersetzt.

Auch in den API-Ausgaben werden die Werte so ersetzt. Beim Aufrufen der API ist es deshalb ratsam, die Sprache explizit anzugeben.

info

License

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

Über

2020-01-30T00:00:00+00:00

museum-digital wurde Anfang 2009 in Bitterfeld als Initiative von Museen gegründet, die ihren Weg ins Netz gemeinsam bestreiten wollen. Ausgehend von der Publikation von Objektinformationen, ist das Projekt seitdem in Größe und Breite gewachsen.

musdb, unsere Eingabeoberfläche, ist zu einem eigenständigen Inventarisierungs- und Sammlungsmanagementprogramm gewachsen. Um Objekte verknüpfbar zu machen, verfügt museum-digital über eine eigene Datenbank von kontrollierten Vokabularen, die von den teilnehmenden Museen gemeinsam erstellt und kuratiert wird. Um einzelne Objekte auch in größere Kontexte einzubetten und entsprechend präsentierbar zu machen, haben wir den “Themator” entwickelt. In der “Ausgabe” von museum-digital wiederum sind heute nicht mehr nur Museen, Sammlungen, und Objekte zu finden, sondern auch Ausstellungen, Veranstaltungen, Objektgruppen, etc. Gleichzeitig ist die Zahl der Museen bei museum-digital auf über 600, besonders in Deutschland und Ungarn, gewachsen.

Trotz allem bleibt gleich:

Entwicklungen geschehen auf Basis des Feedbacks der Museen
museum-digital soll offen für alle Museen sein, d.h. die Benutzung soll möglich sein unabhängig von Größe, finanzieller Ausstattung, und technischem Vorwissen

Der Blog

Dieser Blog steht allen bei museum-digital teilnehmenden Museen offen. Hinzu kommen Beiträge des Entwicklerteams. Der Blog befasst sich zentral mit der Entwicklung (sowohl inhaltlich als auch technisch) von museum-digital. Beiträge zur Digitalisierung in Museen im allgemeinen sind jedoch immer willkommen.

Geschichte des Blogs

Der museum-digital-Blog existiert seit 2009. Die ersten 10 Jahre bis 2019 arbeitete er auf Basis der Software Serendipity, dann bis Oktober 2026 auf Basis von Wordpress.

Seit Oktober 2026 ist dieser Blog eine statisch generierte Seite auf Basis von Zola und dem Linkita-Theme.

Zum Einsatz kommen die folgenden Schriftarten:

Datenschutzerklärung

2020-01-30T00:00:00+00:00

Erklärung zum Schutz personenbezogener Daten

Gemäß der Datenschutzgrundverordnung sind wir verpflichtet den Webseitenbesucher zu Beginn des Nutzungsvorgangs über Art, Umfang und Zweck der Erhebung und Verwendung personenbezogener Daten zu unterrichten. In dieser Datenschutzerklärung erfahren Sie, welche Daten von uns erfasst werden, zu welchen Zwecken wir die Daten erfassen und was mit den erfassten Daten passiert. Da dies wichtig ist, sollten Sie sich die Zeit nehmen, diese Datenschutzerklärung sorgfältig zu lesen.

Zweck der Erhebung, Verarbeitung oder Nutzung Ihrer Daten

Ihre Daten benötigen wir:

Zur Optimierung unseres Angebots.
Für die Speicherung der Sprache in welcher wir ihnen die Inhalte anbieten.

Wir erheben Ihre Daten nur soweit dies notwendig ist. Ihre übersandten Daten werden nicht an Markt- oder Meinungsforschung weiter gegeben.

Datennutzung und Freiwilligkeit der Einwilligung

Alle personenbezogenen Daten, die von Ihnen an uns übermittelt wurden, werden nur für den Zweck verwendet, für die Sie uns die Daten zur Verfügung gestellt haben. Entfällt dieser Zweck so werden die Daten gelöscht. Sie können unsere Webseite besuchen, ohne dass wir persönliche Daten erheben. Ihre persönlichen Daten benötigen wir allerdings dann wenn Sie mit uns in Kontakt treten möchten z.B. durch eine Anfrage. Dies begründet dann auch die Rechtsgrundlage zur Datennutzung damit wir unseren Rechten und Pflichten aus der Geschäftsverbindung mit Ihnen nachkommen können, gemäß § 28 Abs.1 BDSG.

Ihre personenbezogenen Daten welche uns über unsere Webseite übersandt werden erheben, verarbeiten oder nutzen wir nur im Rahmen der gesetzlichen Bestimmungen. Ihre Einwilligung erfolgt auf freier Entscheidung und ohne Zwang und ist jederzeit widerrufbar.

Erfassung von allgemeinen Daten und Informationen

Der Server von museum-digital erfasst bei jedem Aufruf eine Reihe von allgemeinen Daten und Informationen in den Logfiles. Erfasst werden

der vom Aufrufenden verwendeten Browser,
das vom Aufrufenden verwendete Betriebssystem,
die Internetseite, von welcher der Aufrufende auf unsere Webseite gelangt ist,
die Unterwebseiten, welche vom Aufrufenden auf unserer Webseite angewählt werden,
das Datum und die Uhrzeit eines Zugriffs,
eine Internet-Protokoll-Adresse (IP-Adresse),
der Internet-Service-Provider des Aufrufenden und
sonstige ähnliche Daten und Informationen, die der Gefahrenabwehr im Falle von Angriffen auf museum-digital.de dienen.

Bei der Nutzung dieser allgemeinen Daten und Informationen zieht museum-digital keine Rückschlüsse auf die betroffene Person. Diese anonym erhobenen Daten und Informationen werden durch museum-digital statistisch ausgewertet. Die anonymen Daten der Server-Logfiles werden getrennt von allen eventuell durch eine betroffene Person angegebenen personenbezogenen Daten gespeichert.

Einsatz von Cookies

Um unseren Internetauftritt für Sie benutzerfreundlich zu gestalten und optimal auf Ihre Bedürfnisse abzustimmen, setzen wir in einigen Bereichen Cookies ein. Ein Cookie ist eine kleine Datei, die lokal auf Ihrem Computer gespeichert wird, sobald Sie eine Website besuchen. Ihr Browser bietet eine Funktion an, Cookies zu löschen (z.B. über Browserdaten löschen). Weitere Informationen dazu finden Sie in der Bedienungsanleitung bzw. in der Regel unter Einstellungen Ihres Internet-Browsers. Im Einzelnen wird bei jedem Abruf Folgendes gespeichert:

Die gewählte Sprachevariante der Webseite

Impressum

2020-01-30T00:00:00+00:00

Verantwortlichkeit

Im Blog von museum-digital können prinzipiell alle Museen, die bei museum-digital mitmachen, veröffentlichen. Wenden Sie sich daher bei Nachfragen zu konkreten Beiträgen - soweit möglich - an die jeweiligen Autoren und Museen. Im Zweifelsfalle verantwortlich ist:

Inhaber und Kontaktdaten

Stefan Rohde-Enslin
Lepsiusstr. 83
12163 Berlin
E-Mail: blog@museum-digital.de

Haftungsausschluss

Haftung für Links

Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.

Haftung für Inhalte

Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.

Rechtswirksamkeit dieses Haftungsausschlusses

Dieser Haftungsausschluss ist als Teil des Internetangebotes zu betrachten, von dem aus auf diese Seite verwiesen wurde. Sofern Teile oder einzelne Formulierungen dieses Textes der geltenden Rechtslage nicht, nicht mehr oder nicht vollständig entsprechen sollten, bleiben die übrigen Teile des Dokumentes in ihrem Inhalt und ihrer Gültigkeit davon unberührt.

Automatisch generierte Exporte teilen und veröffentlichen

2020-01-19T00:00:00+00:00

museum-digital ist für viele Museen ein Weg die eigenen Objekte in Portale wie die Deutsche Digitale Bibliothek und die Europeana zu bringen. Bisher bedeutete dies in der Praxis das händische Erstellen eines Exports, der bei jeder Aktualisierung der Daten im Zielportal per Mail verschickt werden musste.

Auch wenn es in musdb einen für die Datenweitergabe vorformulierten Export gibt, der nur ein paar Klicks benötigt, ist so bei jeder Aktualisierung der Daten im Zielportal eine gezielte Aktion des Museums nötig. Mit der Möglichkeit zum Teilen von täglich generierten Exporten kann das Aktualisieren der Daten in Portalen in Zukunft vereinfacht werden.

Um die neue Funktion zu nutzen, muss ein Benutzer mit der Benutzerrolle Museumsdirektor sie auf der Seite “Einstellung für das Museum” in musdb aktivieren (Schalter: “Weitergabe von XML-Dumps / automatischen Exporten”). Das Auswahlmenü verfügt über drei Einträge:

“Nein”
“Per Link”
“Öffentlich”

Wird der Wert auf “per Link” oder “öffentlich” geändert, wird ein Link zum Teilen der vorgenerierten Exporte generiert, der direkt unter dem Schalter angezeigt wird. Bei jeder Änderung der “Weitergabe”-Einstellung wird der Link neu generiert - und damit alte, schon geteilte Links unbrauchbar. Deshalb sollte man den Status zwischen “Per Link” und “Öffentlich” nicht zu häufig und nur nach vorsichtigem Abwägen ändern.

Mit dem so generierten Link lässt sich eine Seite mit täglich generierten Export-Dateien (bisher LIDO-Exporte für alle öffentlichen Objekte) in der Ausgabe von museum-digital öffnen. Steht der Weitergabe-Wert auf “Öffentlich”, ist diese Seite auch auf der Institutions-Seite des Museums öffentlich verlinkt.

Eine Beschränkung existiert bei dieser Funktion allerdings: Die teilbaren Exporte werden bisher immer mit der Voreinstellung für LIDO-Exporte erstellt.

info

License

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

Objekte auswählen / schnelle Stapelverarbeitung

2020-01-19T00:00:00+00:00

Und da saß einer an seinem Handy und wählte Fotos zum Versenden aus. In etwa so beginnt die Geschichte der neuen Funktion zur Auswahl und darauf basierenden Stapelbearbeitung in musdb. Wenn man auf dem Handy Stapelweise versenden kann, warum soll man dann nicht mit einer äquivalenten Design-Logik seine Objekte stapelweise verschlagworten können?

Bis zur letzten Woche bot musdb nur eine direkt filterbasierte Stapelverarbeitung. In Kürze: Nach dem Formulieren einer Suchanfrage kann man für alle gefundenen Objekte Aktionen (Zuordnen zu Objektgruppen, veröffentlichen und mehr) durchführen. Weil auf diese Art und Weise tausende Objekte mit einem Knopfdruck bearbeitet werden können und Fehler schnell tagelange Korrekturen nach sich ziehen, ist diese Funktion nur für Benutzer mit der Benutzerrolle “Museumsdirektor” verfügbar.

Die Auswahl-Funktion bietet jetzt eine weniger radikale Option zur Stapelverarbeitung und steht damit allen Benutzern mit Bearbeitungsrechten zur Verfügung.

Um die Auswahlfunktion zu nutzen muss man als eingeloggter Benutzer von musdb zuerst einmal zur Objektübersichtsseite im Bilderwand-Modus gehen. Eine etwaige Suche kann dabei gestellt sein, muss aber nicht.

Vordergründig ist alles wie gehabt. Durch einen Klick auf eine Objektabbildung oder Kachel lässt sich die Objektseite öffnen. Aber mit einem langen Klick mit leichter Mausbewegung (als zöge man das Objekt) lässt sich der Auswahlmodus öffnen.

Ist der Auswahlmodus einmal aktiviert, lassen sich weitere Objekte durch Klicks auf die entsprechende Abbildung oder Kachel markieren. Ausgewählte Objekte sind dabei durch ein farbig ausgefülltes Rechteck oben rechts erkennbar.

Mit dem Aktivieren des Auswahlmodus ist während dessen auch eine gelb gefärbte Menüleiste am oberen Fensterrand aufgetaucht. Über die hier angebotenen Menüpunkte lassen sich die ausgewählten Objekte zu Objektgruppen, Sammlungen und Ausstellungen zuordnen oder verschlagworten.

Sind die gewünschten Objekte einmal ausgewählt, lässt sich durch einen Klick auf “Schlagwort” ein Dialog öffnen. Mit dem in Dialog erschienenen Suchschlitz kann nun ein Schlagwort zur Verknüpfung suchen. Ein Klick auf den entsprechenden Listeneintrag verknüpft die ausgewählten Objekte mit dem Schlagwort.

Sind die Objekte erfolgreich verschlagwortet, bleibt der Auswahlmodus aktiviert, sodass die ausgewählten Objekte weiter verschlagwortet oder zugeornet werden können. Durch die Escape-Taste oder einen Klick auf das X am oberen rechten Fensterrand lässt sich der Auswahlmodus wieder verlassen.

P.S.: Weil es eh geplant war und den Auswahlmodus mit mehr Objekten in der Liste effektiver wird, haben wir die maximale Anzahl von Objekten, die in der Objektliste im Bilderwand-Modus angezeigt werden können, auf 200 erhöht (bisher: 120).

info

License

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

Statistiken und ein verbesserter Dark Mode

2020-01-13T00:00:00+00:00

An dieser Stelle sollte eigentlich zum ersten Mal Blogpost in Form eines Jahresrückblicks auf das Jahr 2019 und eines Ausblicks auf das kommende Jahr 2020 stehen. Aber wie das bei ehrenamtlichen Projekten so ist, gab es dann doch wichtigeres zu tun (unter anderem die Entwicklung eines Funktion, die den Rückblick erst in Gänze möglich macht). Und so wurde aus dem Blogpost, Arbeitstitel “Auf in die goldenen Zwanziger” erst einmal nichts.

Zum Jahresrückblick hätte auch die erstmalige Besprechung vieler Features gehört, die wir im letzten Jahr eingeführt aber leider nie öffentlich bekanntgemacht hatten. Auch, weil die allermeisten dieser Features eher neue Zugaben sind, die bestehende Arbeitsabläufe nicht verändern. Wie schon gesagt, wurde aus dem Jahresrückblick nichts, weil wir neue Features entwickelt haben. Um den “Berg” der unbesprochenen Features nicht noch weiter anwachsen zu lassen, sollen hier schon einmal die bisherigen Neuentwicklungen des neuen Jahres 2020 besprochen werden.

Konkret lassen sich die neuen Features in drei Bereiche unterteilen:

Neue Statistikfunktionen in Ausgabe und musdb
Verbesserter und erweiterter Dark Mode
Sortiermöglichkeit in den Ausstellungs- und Veranstaltungslisten in musdb

Der Dark Mode im Blog von museum-digital.

Neue Statistikfunktionen in Ausgabe und musdb

Instanzweite Statistik (Datenbankinhalte)

Das Feature, das einen “vollen” Jahresrückblick ermöglichen sollte, ist ein statistischer Überblick über die (öffentlichen) Inhalte einer gegebenen Datenbank - mit der Möglichkeit die Entwicklung der Datenbank nachzuvollziehen. Während wir auf dem Dashboard von museum-digital.org schon eine Übersichtsfunktion hatten, die Auskunft über die jeweils aktuellen Inhalte von museum-digital gab, fehlte bislang die Möglichkeit eine einzelne Instanz - wie etwa museum-digital:brandenburg - isoliert zu betrachten. Auch war es bislang nicht möglich, die Entwicklung über die Zeit zu vergleichen.

Seit November haben wir deshalb am Speichern des jeweils täglich aktuellen Zwischenstandes und der Darstellung als Teil jeder einzelnen Instanz von museum-digital gearbeitet. Das Ergebnis kann hier am Beispiel der deutschlandweiten Instanz gesehen werden (in jeder Instanz ist die Statistik unten in der Fußzeile verlinkt).

Die Inhalts-Statistik-Seite zeigt die verschiedenen Typen von Datensätzen als Kreis mit ihrer derzeitigen Anzahl und der Entwicklung.

Auf den ersten Blick besteht die instanzweite Statistikseite aus einer Reihe von Kreisen. Jeder Kreis behandelt eine bestimmte Art von Datensätzen (Museen, Sammlungen, Objekte, …) und gibt auf den ersten Blick Auskunft über die derzeitige Anzahl von öffentlichen Datensätzen dieses Types in der Datenbank der vorliegenden Instanz. Sollte sich die Zahl im letzten verglichenen Zeitinterval geändert haben, erscheint ein grüner oder roter Balken, der Auskunft über Zuwachs (grün) und Schrumpfen (rot) gibt.

Durch einen Klick auf einen der Kreise / Datensatztypen erreicht man eine tabellarische Auflistung

Durch einen Klick auf einen gegebenen Kreis erhält man eine tabellarische Auflistung der Datenbankinhalte zu gegebenen Zeitpunkten und ihrer Entwicklung. Standardmäßig sind die hier gewählten Zeitpunkte immer der Erste eines Monats im laufenden Jahr und der Erste Januar eines jeden Jahres seit Beginn der Zählung für die Zeit davor. Um eine einheitlichere Übersicht zu gewinnen, können die Vergleichsintervalle aber ganz unten auf der Seite auf Jährlich (immer der Erste jedes Jahres) oder Monatlich (der Erste jedes Monats) umgeschaltet werden.

Für tiefergehende Analysen können die vollen Statistiken (ab November 2019 täglich erhoben) im CSV-Format heruntergeladen werden und dann in LibreOffice Calc, Excel, oder ähnlichen Programmen weiterverarbeitet werden.

Weil wir die für diese Funktion zugrundeliegenden Daten erst seit November erheben, sind die Daten für die vorherigen Zeiten retrospektiv erstellte Schätzungen und sollten deshalb nur als beschränkt Aussagekräftig betrachtet werden. Zum Abschätzen einer Tendenz dient es aber allemal.

(Online-)Besucherstatistik für ein Museum

Ein häufiger geäußerter Wunsch aus den Museen war ein Überblick über die Anzahl der Benutzer, die die Inhalte eines gegebenen Museums betrachten. Auch diesen Wunsch konnten wir Ende des letzten Jahres zumindest bedingt endlich erfüllen.

Grundsätzlich werden für die Funktion die Anzahl der Benutzer pro Museum und pro Objektseite gespeichert. Die Logik dahinter ist die folgende: Ruft ein Benutzer eine Objektseite auf, wird zuallererst auf Basis des user-agents (ein von Browser übermittelter Wert, der angibt ob der Benutzer etwa Firefox oder Chrome benutzt) geprüft, ob es sich um einen Bot handelt.

Kommt der Seitenaufruf nicht von einem klar als solchem zu erkennenden Bot, wird die IP-Adresse des Benutzers gekürzt und auf Basis dieser gekürzten IP ein Hash-Wert erstellt. Dieser wird zusammen mit der ID der Objektseite und der auf die Stunde gerundeten Zeit in die Datenbank geschrieben, solange dieselbe Kombination von Werten noch nicht vorhanden ist. Weitere Daten des Benutzers werden nicht gespeichert oder zur Analyse herangezogen.

Auf diese Weise funktioniert die Zählung eher wie bei Besucherzählern auf Webseiten der 2000er-Jahre (“diese Seite haben 000530 Besucher aufgerufen”) als bei wie vollwertige Analytics-Tools. Alle Berechnungen erfolgen rein Serverseitig auf Basis eh beim Seitenaufruf mitbegebener Daten und wir unternehmen keine Versuche, Benutzer etwa durch Cookies bei wechselnden IP-Adressen weiter als denselben Benutzer zu identifizieren. Einerseits ist eine solche Zählung natürlich wesentlich leichter zu implementieren, andererseits arbeitet sie aber auch wesentlich (daten-)sparsamer als heutige Analyse-Tools.

Dadurch, dass die Zählung keinen Client-seitig ausgeführten Code verlangt, werden tendenziell zuviele Besucher gezählt (Google Analytics würde etwa Besucher, die einen rein textbasierten Browser benutzen, nicht zählen). Andererseits führen die Zählung auf Basis von (pseudonymisierten) Adressräumen anstatt von vollen IP-Adressen und das relativ lange Interval zu einer eher geringeren Zählung von einigartigen Benutzern. Wir hoffen, dass sich dies in etwa ausgleicht.

Um die Online-Besucher-Statistik nun verwenden zu können, muss ein Museum diese zuerst einmal freischalten. Dies bedeutet zwangsläufig auch eine Veröffentlichung. Diese Verknüpfung von Veröffentlichung und Benutzung erwächst aus der dezentralen Struktur von museum-digital: Die Besucherstatistik wird immer für ein Museum in einer Instanz angelegt.

Wenn das Museum etwa auch in der deutschlandweiten Instanz vertreten ist, dann existieren zwei voneinander getrennte Zählungen für dasselbe Museum. Damit das Museum auch die Zahlen aus der deutschlandweiten Instanz sehen kann (wo es keine Anmelde-Option gibt), müssen diese auch nicht eingeloggten Benutzern zugänglich gemacht werden - und das heißt eben allen.

Rechts in der Seitenspalte findet sich (so sie aktiviert ist) der Link zur Besucherstatistik.

Die Statistik-Seite selbst besteht aus drei Bereichen. Der erste Bereich ist eine tabellarische Übersicht. Im zweiten Bereich wird die Entwicklung des letzten Monats in einem Diagramm angezeigt. Der dritte Bereich listet die beliebtesten Objekte auf (insgesamt, in diesem Monat, und am jeweiligen Tag).

Die neue Seite für die (Online-)Besucherstatistik zeigt oben eine tabellarische Zusammenfassung.

Die neue Seite für die (Online-)Besucherstatistik zeigt im zweiten Abschnitt ein Diagramm der Besucherentwicklung in diesem Monat und darunter Listen der am häufigsten aufgerufenen Objektseiten.

Verbesserter und erweiterter Dark Mode

Eine Verbesserung auf ganz anderer Seite ist Verbesserung des Dark Modes.

Einerseits bezieht sich dies auf die Ausgabe von museum-digital, wo wir schon im Laufe des vergangenen Jahres einen Dark Mode implementiert hatten, der aber vom Benutzer aktiv angeschaltet werden musste. Jetzt wird - gegeben, dass ein aktueller Browser verwendet wird - geprüft, ob der Dark Mode systemweit aktiviert ist, und falls dem so ist, der Dark Mode auch für die Seite automatisch aktiviert.

Andererseits haben wir auch die meisten anderen Tools von museum-digital mit einem Dark Mode ausgestattet. Das relevanteste dieser Tools ist mit Sicherheit musdb, das hauptsächliche Eingabetool von museum-digital. Aber auch eher interne Tools wie unser Übersetzungstool verfügen jetzt über einen Dark Mode.

Alle gemein haben sie, dass sie im Gegensatz zum Dark Mode der Ausgabe direkt über die systemweite Einstellung aktiviert oder deaktiviert werden. Es gibt also anders als in der Ausgabe keinen eigenen Button, um den Dark Mode zu aktivieren oder zu deaktivieren.

Auch die Projektseite von museum-digital hat jetzt einen Dark Mode.

Der Dark Mode von musdb auf einer Objekt(-bearbeitungs)-Seite.

Die Objektübersicht in musdb bei aktivierten Dark Mode.

Sortiermöglichkeit in den Ausstellungs- und Veranstaltungslisten in musdb

Eine letzte kleine Verbesserung ist, dass die Listen von Ausstellungen und Veranstaltungen in musdb jetzt sortierbar sind.

Bei der Einrichtung der Veranstaltungs- und Ausstellungsbereiche war es uns ein besonderes Anliegen, auch ein öffentliches Archiv der vergangenen Veranstaltungen und Ausstellungen eines Museums zu ermöglichen, weil diese Information häufig - auch im Netz - schnell wieder gelöscht werden. Für die Öffentlichkeitsarbeit und Werbung sind vergangene Ausstellungen eben nicht wichtig oder werden sogar als kontraproduktiv gesehen (auch wenn das bei richtiger Auszeichnung nicht umbedingt wirklich so sein muss). Für die Forschung sind aber gerade auch die vergangenen Ausstellungen interessant.

Ist man einmal an die vermeintliche Uninteressant-heit von vergangenen Veranstaltungen und Ausstellungen gewöhnt, dann ist es naheliegend, diese auch bei museum-digital zu löschen. Das gilt natürlich erst recht, wenn die vergangenen Einträge das Auffinden der Aktuellen erschweren. Deshalb sind Funktionen zur “Findbarmachung” von Einträgen an dieser Stelle besonders wichtig.

Jetzt haben wir diese Funktion nachgerüstet. Durch einen Klick auf einen Titel aus dem Tabellenkopf wird nach dem gegebenen Wert sortiert. Danke an die Kollegen vom Kreismuseum Bitterfeld, die auf diese Verbesserung hingewirkt haben.

Durch einen Klick auf einen Titel im Tabellenkopf kann die Liste jetzt sortiert werden. Hier wurde die Liste nach dem Veranstaltungstitel absteigend sortiert.

info

License

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

Schlagworte verfeinern und Mehrsprachig eingeben

2019-12-12T00:00:00+00:00

Zur Verbesserung der Verschlagwortung bei museum-digital haben wir in den letzten Monaten zwei neue Funktionen in musdb, dem Eingabetool von museum-digital, eingeführt. Einerseits ist dies eine Funktion zur Verfeinerung von Schlagworten anhand der vom Normdaten-Team erstellten Hierarchien. Andererseits die Möglichkeit, Verknüpfungen mit Akteuren, Orten, Schlagworten auch in anderen Sprachen einzugeben.

Schlagworte verfeinern

Viele Objekte sind nicht so genau verschlagwortet, wie es möglich wäre. Ein Portrait ist ein Portrait. Und häufig fällt einem beim Eingeben schlicht nichts genaueres ein.

Handelt es sich um ein Portrait einer Frau, wäre der Begriff “Damenportrait” allerdings spezifischer. Eine spezifische Verschlagwortung würde suchen nach diesem konkreten Begriff ermöglichen, aber durch die im Hintergrund angereichterten Hierarchien würde das Objekt bei Suchen nach “Portrait” weiterhin gefunden. Kurz zusammengefasst: Eine so genaue Verschlagwortung wie möglich ist in eigentlich jedem Fall gut.

Wurde ein Objekt einmal als Portrait verschlagwortet, war das Spezifizieren des Begriffs bisher leider etwas mühsam. Man musste zuerst das genauere Schlagwort anhängen, und dann das ungenauere entfernen. Um die Spezifizierung zu vereinfachen, kann man jetzt in der Eingabeoberfläche mit einem Rechtsklick auf ein verknüpftes Schlagwort eine Seitenspalte öffnen. In dieser sind alle dem Schlagwort direkt untergeordneten Begriffe zu finden. Durch einen Klick auf einen Eintrag aus dieser Liste wird das ungenaue durch das genauere Schlagwort ersetzt.

Neben der Vereinfachung der Verschlagwortung bietet die Funktion so auch vielleicht eine Inspiration, falls man gerade nicht im eigenen Fachgebiet arbeitet.

Durch einen Rechtsklick auf ein Schlagwort in musdb öffnet sich eine Seitenspalte zum Verfeinern des Begriffs.

Vielen Dank an die Kollegen aus Ungarn, die uns auf dem Benutzertreffen in Budapest Anfang November zu dieser Funktion inspiriert haben.

Orte, Akteure und Schlagworte mehrsprachig eingeben

Eine weitere Verbesserung der Verschlagwortungsfunktionen ist die Möglichkeit, Orte, Akteure und Schlagworte in anderen Sprachen einzugeben. Wenn im Museum jemand arbeitet, der oder die nicht muttersprachlich Deutsch spricht, ist es hilfreich, auch “Cologne” statt “Köln” eingeben zu können.

Deshalb beachtet musdb bei der Verschlagwortung jetzt auch die allgemeine Umgebungssprache des Benutzers. Ist diese auf Englisch eingestellt, erkennt das System beim Eingeben von “Cologne”, dass Köln gemeint ist, und bietet auch “Cologne” in Auswahllisten für Orte an. Die deutsch-sprachigen Kollegen sehen dann “Köln” verlinkt, weil im Hintergrund gespeichert ist, dass beides Namen für dieselbe Stadt in Englisch bzw. Deutsch sind.

So wird auch Kollegen, die wenig oder gar kein Deutsch sprechen, die Möglichkeit gegeben, die Objektdaten weiter anzureichern.

info

License

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

Inhalte aus museum-digital über externe Repositorien finden

2019-12-11T00:00:00+00:00

Heute gibt es im Blog einmal wieder eine rein technische Neuerung zu berichten. Mit dem seit heute öffentlich verfügbaren Resolver können Inhalte einer Instanz von museum-digital leichter mit anderen Repositorien integriert und verknüpft werden.

Getting Started

Zum Benutzen der neuen Funktion muss an die URL der Startseite nur “/resolver” angehängt werden. Der Einfachheit halber folgen Beispiele aus der deutschlandweiten Instanz von museum-digital. Hier kann der Resolver also unter https://nat.museum-digital.de/resolver/ aufgerufen werden.

Unter dieser URL findet sich eine kurze Anleitung für die Benutzung.

Listen der verknüpften Repositorien aufrufen

An die gebene Basis-URL kann nun der gewünschte Daten-Typ angehängt werden. Verfügbar sind derzeit Institutionen (institution), Objekte (object), Akteure (actor), Orte (place) und Schlagworte (tag). Durch Anhängen des entsprechenden Typs kann eine Liste von passenden, verlinkten Repositorien aufgerufen werden.

Für Orte sind derzeit etwa Verknüpfungen zu und über die folgenden Repositorien verfügbar:

geonames
gnd
nomisma
pleiades
Website
wikidata

Diese Liste kann unter https://nat.museum-digital.de/resolver/place gefunden werden.

Beacon-Datei / Konkordanzliste generieren

Durch ein weiteres Anhängen des Names eines gegebenen Quell-Repositoriums aus dieser Liste kann nun eine Konkordanzliste zwischen den Einträgen bei museum-digital und den Einträgen aus der Quelle aufgerufen werden (Beispiel: https://nat.museum-digital.de/resolver/place/gnd).

Diese Konkordanzliste wird in Form einer Beacon-Datei generiert. Mehr zum Beacon-Format kann etwa hier gefunden werden.

Link Resolving

Die eigentliche Hauptfunktion des Resolvers (wie der Name schon sagt) besteht in der Vereinfachung des Verlinkens von Inhalten aus museum-digital über IDs aus externen Repositorien.

Hängt man also z.B. an die eben genannte URL eine GND-ID eines Ortes an, wird zur entsprechenden Ortsseite weitergeleitet. 4078337-6 entspricht in der GND Tokyo, https://nat.museum-digital.de/resolver/place/gnd/4078337-6 führt also zur Ortsseite von Tokio in der deutschlandweiten Instanz von museum-digital.

info

License

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

Mehr Mehrsprachigkeit

2019-09-22T00:00:00+00:00

Die Navigation der verschiedenen Programme und Seiten von museum-digital ist seit Jahren mehrsprachig. Namen und Beschreibungstexte von Objekten, Sammlungen und Museen lassen sich ebenso seit Jahren mehrsprachig erfassen. Die Mehrsprachigkeit bei museum-digital hatte jedoch lange ein großes Manko: Einträge aus den kontrollierten Vokabularen - also Akteure, Orte, Zeiten und Schlagworte - waren bis jetzt Einsprachig.

In den letzten Wochen haben wir uns verstärkt der Verbesserung der Mehrsprachigkeit von museum-digital gewidmet. Auch Einträge aus den kontrollierten Vokabularen sind jetzt übersetzbar oder werden zumindest in international verständlicher Form angezeigt. Übersetzungen von Objektinformationen sind leichter einzugeben. Und bald werden auch Themenseiten im “Themator” mehrsprachig.

Auch die Kachel für Suchergebnis-Inforrmationen bei Personen ist übersetzbar. Hier ist etwa der arabische Text zu Johann Wolfgang von Goethe zu sehen.

Mehrsprachigkeit von kontrollierten Vokabularen

Eine Schlagwort-Bearbeitungsseite in nodac. Im unteren mittigen Bereich finden sich die aus Wikipedia ausgelesenen Übersetzungen des Vokabulareintrags.

Seit knapp einer Woche können Einträge aus den kontrollierten Vokabularen von museum-digital von der “Normdatenredaktion” übersetzt werden. Übersetzungen können dabei entweder händisch eingegeben werden, oder halb-automatisch aus Wikidata ausgelesen werden.

Ist ein Begriff einmal mit Übersetzungen erfasst, können diese Übersetzungen jetzt auch in der Ausgabe angezeigt und genutzt werden. Dies hilft einerseits bei der Anzeige: Ist ein Objekt mit “Helm” verschlagwortet, erschien bisher das deutsche Wort “Helm” im Bereich für Tags, auch wenn der Benutzer English als Sprache gewählt hatte. Jetzt erscheint an der selben Stelle “helmet”. Weil sich die meisten Zeitbegriffe nicht ohne weiteres übersetzen lassen - erst recht nicht automatisiert - werden Zeitbegriffe in Jahreszahlen ausgedrückt, wenn ein Benutzer nicht die Standardsprache der Instanz benutzt.

Genauso wie die Tags, Orte, und Personeneinträge unten auf Objektseiten übersetzt werden, lassen sich auch die Info-Kacheln auf Suchergebnisseiten übersetzen. Hier erscheinen nun der Sprache des Benutzers entsprechende Titel und Beschreibungen.

Seit dieser Woche sind auch Suchen in der Sprache des Benutzers möglich. Hier wurde beispielsweise nach “helmet” gesucht.

Neben der Anzeige lassen sich die Übersetzungen aber auch für erweiterte Programmfunktionen benutzen. Bisher ist dies in der Suchfunktion der Fall: Benutzer können nun auch in der von ihnen gewählten (Navigations-)Sprache nach Objekten suchen. Bei englischer Navigationssprache werden also die Englischen und Deutschen übersetzungen überprüft. Um nach Köln zu suchen, kann man nun also auch nach “Cologne” suchen - gegeben, dass man die Seite in Englisch navigiert.

Leichter Übersetzen in musdb

Übersetzen ist einfacher, wenn man sieht, was man gerade übersetzt - natürlich. Dieser simplen Erkenntnis haben die Übersetzungsoberflächen für Basisinformationen zu Objekten, Sammlungen und Institutionen in musdb leider bisher keine Rechnung getragen. Übersetzer waren mit einer einfachen Oberfläche bestehend aus “Eingabeschlitzen” konfrontiert.

Um die Übersetzung zu erleichtern haben wir seit letzter Woche den “Inhalte wiederholen”-Button auch in die Übersetzungsoberfläche integriert. Damit lässt sich der “Haupteintrag” (also in deutschsprachigen Instanzen die deutschsprachigen Titel und Beschreibungen) in die jeweiligen Felder der Übersetzungsoberfläche überführen, sodass Übersetzer suksessive übersetzen und die deutschsprachigen Sätze durch die Übersetzung ersetzen können.

Die Übersetzungsseiten in musdb haben jetzt einen “Wiederholen-Button”, mit dem die entsprechenden Texte aus den Basis-Einträgen in ein Eingabefeld kopiert werden können.

Mehrsprachigkeit im Themator? Mehrsprachigkeit im Themator!

Gerade sind wir bei einer großflächigen Überarbeitung des Themators. Diese betrifft besonders die Eingabe, deren Code in die Jahre gekommen war und dringend einer Verbesserung bedurfte. Als kleines Schmankerl kommt auf Wunsch der Kollegen aus Ungarn und dem Ethnologischen Museum in Berlin mit dem nächsten Update des Themators aber auch die Übersetzbarkeit von Einträgen als neues Feature.

Alles in allem befindet sich museum-digital jetzt auf einem guten Weg komplett mehrsprachig zu werden. Besonders die mehrsprachige Suche ist ein lange gehegter und häufig diskutierter Traum. Alles, was es jetzt noch braucht, sind die mehrsprachigen Inhalte selbst.

info

License

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

Zwei neue Features und eine neue Sprache

2019-07-12T00:00:00+00:00

Gestern haben wir ein Update der Ausgabe von museum-digital verteilt, mit dem zwei neue Features und eine neue Sprachversion verfügbar werden: Ein Dark-Mode, eine Option zum Verfeinern von Suchanfragen, und Arabisch als Navigationssprache.

Ein Dark-Mode für die Ausgabe von museum-digital

Blaues Licht, besonders auch von Computer-Bildschirmen, führt Berichten zufolge zu Schwierigkeiten beim Einschlafen. Apple und Microsoft haben darauf reagiert, und jeweils einen “Dark-Mode” mit geringerem Kontrast und dunklen Farben in ihren Betriebssystemen implementiert. Eine - erfahrungsgemäß - sicherlich gute Option zur Schonung von Augen und Schlafrythmus.

Alternative, dunkle Farbschemata für Webseiten haben sich allerdings noch nicht weit durchgesetzt. Youtube bietet dieses Feature seit einiger Zeit an, aber fast alle großen Dienste verzichten darauf. Ebenso Museums-seiten und Portale.

Die Folge: Man sitzt am Abend vor dem Rechner, hat eine dunkle Seite aufgerufen oder arbeitet in einem dunkel gefärbten Programm. Man wechselt das Programm - ab ins Netz - und ruft den Browser der Wahl auf. Und fühlt sich erschlagen vom grellen, weißen Hintergrund der aufgerufenen Seite. Ich persönlich arbeite viel Nachts, und bin diesem Problem bei wahrscheinlich keiner Seite häufiger begegnet als bei der Ausgabe von museum-digital.

Der neue Dark-Mode der Ausgabe von museum-digital. Oben rechts in der Navigation findet sich ein Schalter, um den Dark-Mode aktivieren und deaktivieren zu können.

Der neue Dark-Mode von museum-digital schafft Abhilfe. Oben rechts in der Navigation, gleich neben dem Schalter zum Wechseln der Navigationssprache findet sich ein neuer Schalter mit der Option den Dark-Mode zu aktivieren. Mit einem Klick darauf wird der Hintergrund der Seite abgedunkelt und die Schrift weiß. Mit einem weiteren Klick lässt sich der Dark-Mode wieder deaktivieren.

Das Farbschema der dunklen Ausgabe ist grob an das GTK-Theme Arc-Dark angeleht.

Suchanfragen verfeinern

Eine erweiterte Suche hat museum-digital seit langem. Neu ist die “Suche verfeinern”-Option.

Hatte man eine Suchabfrage getätigt, erschien bisher nur oben der Text “Suche anpassen”, mit dem die Suchabfrage konkretisiert werden konnte. Das ist eine gute Basis, aber es lädt nicht dazu ein, benutzt zu werden. Dadurch, dass das Anpassen der Suche auch ein Abändern der schon gegebenen Suche anbietet, ist zudem nicht nicht klar, ob es für “eine andere Suche” oder “eine genauere Suche” verwendet werden sollte.

Deshalb nun also die neue “Suche verfeinern”-Option. Erreichbar ist sie durch einen Klick auf das “Lupe und +”-Symbol unten rechts in der Optionsleiste auf Suchergebnisseiten (im nächsten Screenshot grau hinterlegt). Als nächster Schritt wird ausgewählt, um was für einen Typ von Eintrag die Suchabfrage erweitert / verfeinert werden soll: Eine Person, ein Ort, eine Institution, usw.

Nachdem der Erweiterungstyp ausgewählt ist, erreicht man eine Liste aller Begriffe des gewählten, um die man die Suche erweitern kann. Hat man also z.B. Person/Institution gewählt, sind hier alle Akteure aufgelistet, mit denen mindestens ein Objekt aus der Treffermenge verknüpft ist. Mit einen Klick auf einen Eintrag aus dieser Liste wird man zurück zur Trefferseite der Suche - jetzt mit der weiter eingegrenzten Treffermenge - zurückgeleitet.

Der “Suche verfeinern”-Schalter befindet sich ganz rechts in der Options-Leiste auf Suchergebnis-Seiten.

Als erster Schritt zum Verfeinern der Suche muss ausgewählt werden, wonach weitergefiltert werden soll.

Durch einen Klick auf “Person/Institution” erreicht man eine Liste aller Personen, die mit den gesuchten Objekten verknüpft sind. Mit einem Klick auf einen Eintrag kann die Suchabfrage um den gegeben Akteur erweitert werden.

Kleines Designupdate für Mobilgeräte

Für Mobilgeräte bringt das Update eine kleine Designänderung: Statt das der Eingabeschlitz für die Suche eine eigene Zeile unter dem Seitentitel erhält, ist sie jetzt oben direkt neben dem Menü-Symbol zu finden.

Überfährt man das Menü-Symbol, sieht man, dass auch der Sprachschalter umgestaltet wurde: Statt, dass nur der Sprachcode der derzeit gebrauchten Navigationssprache angezeigt wird, ist der ausgeschriebene Name der Sprache hinter dem Sprachcode zu lesen.

Die erweiterte Such-Seite auf museum-digital:nat in der Handyansicht. Oben rechts neben der Navigation findet sich die Objektsuche, statt wie bisher eine eigene Zeile zu belegen.

Der Sprachwechler in der Navigation für die Mobilansicht trägt jetzt den ausgeschriebenen Sprachnamen.

Die Ausgabe von museum-digital in Arabisch

Zum Schluss noch eine besonders erfreuliche Neuigkeit: Die Ausgabe von museum-digital ist jetzt auch in Arabisch verfügbar. Vielen, vielen dank an die Übersetzerin Mariam Bachich!

info

License

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

Objektgruppenbilder

2019-07-07T00:00:00+00:00

Was ist eine Objektgruppe? Objektgruppen können fast alles sein, das mehrere Objekte zusammenfasst: Von Objekten aus einem archäologischen Fund bis zu solchen, die für einen bestimmten Export gebraucht werden. Am intuitivsten ist die Benutzung des Konzepts der Objektgruppe sicherlich dort, wo schon im Museum Objekte zusammengefasst werden. Fotoalben sind ein solches Beispiel, aber auch Altäre, Gemälde- und Skizzenserien. Fälle also, in denen mehrere Objekte ein “Meta-Objekt” ergeben.

Es ist gerade in diesen Fällen, in denen es Sinn ergibt, die Objekte nicht nur zusammen aufzulisten, sondern auch visuell in einen Kontext zu setzen. Deshalb gibt es seit diesem Wochenende die Möglichkeit, Bilder für Objektgruppen in musdb zu erfassen. Dies geschieht analog zum Hochladen von Bildern für Ausstellungen oder Veranstaltungen.

Ist ein Bild hochgeladen, erscheint es rechts des Beschreibungstextes der Objektgruppe auf der Objektgruppen-Seite in der Ausgabe.

info

License

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

Vorgestellte Objekte auf www.museum-digital.de (der deutschen Übersichtsseite)

2019-07-07T00:00:00+00:00

Sucht man nach “museum-digital.de”, oder gibt dasselbe in die URL-Leiste im Browser ein, erreicht man die deutsche Projekt-Übersichtsseite www.museum-digital.de (nicht zu verwechseln mit der internationalen Projektseite museum-digital.org oder der ungarischen Projektseite muzeumdigitar.hu).

Die Seite liefert eine Übersicht der verschiedenen regionalen und internationalen Instanzen von museum-digital, und der darauf jeweils vertreten Objekte, Sammlungen und Museen. Dazu kommen Links zu den zusätzlichen Tools (dem Themator und md:term) und Zähler der Museen, Sammlungen, und Objekte, die in der deutschlandweiten Instanz zu finden sind.

Und zu guter letzt finden sich ganz oben auf der Seite eine Auswahl von Objekten. Wir haben den Mechanismus zur Auswahl dieser Objekte in der letzten Woche geändert: Statt der neuesten Objekte, werden die Objekte mit dem höchsten PuQi-Wert angezeigt.

Warum die Logik ändern?

Weil die deutschlandweite Instanz (md:nat) nur einmal am Tag aktualisiert wird, bedeutet ein Errechnen der wirklich neuesten Objekte in deutschen Instanzen ein Abfragen jeder einzelnen Datenbank. Das heißt, statt eine Datenbank abzufragen wurden 18 abgefragt. Um bis zu 50 Objekte zu finden, wurden 180 (maximal 10 pro Instanz) abgefragt und mussten dann noch einmal neu sortiert und gefiltert werden. Kurz zusammengefasst: Das Auslesen der neuesten Objekte war inhärent ineffektiv und führte zu einer erhöhten Ladezeit und Code-Komplexität.

Eine langsame Ladezeit ist ein Hauptgrund für Besucher Seiten zu verlassen. Komplexer Code bedeutet eine erhöhte Fehler-Anfälligkeit.

Eine andere Logik war also so oder so vorzuziehen, aber warum der PuQi-Wert? Und was ist das eigentlich?

Der PuQi-Wert als Basis für die Auswahl

Was ist der PuQi-Wert?

Der “Publikationsqualitäts-Index” wird anhand der publizierbaren Angaben zum Objekt errechnet.

PuQi steht für “PublikationsQualitätsIndex”. Basierend auf der Anzahl der mit einem gegebenen Objekt verknüpften Abbildungen, Ereignisse, Literatureinträge, usw. wird ein numerischer Wert berechnet, der die geschätze Qualität der Angaben zum Objekt abbildet. Eine genauere, wenn auch leicht veraltete Auflistung der Kriterien kann im Journal Uncommon Culture nachgelesen werden.

Damit dieser Wert für die Suche nach Objekten genutzt werden kann, wird er in der Datenbank gespeichert. Diese Datenbankeinträge werden im Rahmen der Synchronisierung mit der deutschlandweiten Datenbank auch dort verzeichnet.

Der PuQi-Wert und die Startseite

Das heißt, dass wir die Liste der vermutlich qualitätsvollsten Objektbeschreibungen schon in der Datenbank haben. Eine perfekte Grundlage, um eine “Hall of Fame” der am besten erfassten Objekte zu bauen! Genau das haben wir mit der neuen Auswahl getan. Sortiert wird einfach nach dem PuQi-Wert.

Da die Daten direkt aus der deutschlandweiten Datenbank kommen, ist damit auch die Code-Komplexität und Ladezeit entscheidend reduziert (es braucht kein nachträgliches Filtern mehr, und nur noch eine Datenbankabfrage statt 18).

Analyse und Selbstkritik

Natürlich ist der PuQi-Wert nicht perfekt. Durch ein einfaches Zählen der verknüpften Bilder, Ereignisse, etc. kann echte Qualität nicht erkannt werden. Eine gute Objektbeschreibung kann sehr gut sein, es kommt auf den Kontext an. Wenige, aber gute, Objektabbildungen sind besser als viele mittelmäßige. Und er kann nicht erkennen, ob Literatureinträge wirklich mit dem Objekt zu tun haben oder nur entfernt Kontext liefern.

Andererseits ist ein guter PuQi-Wert bei manchen Objektarten leichter zu erreichen als bei anderen. Ein Buch hat viele Seiten, und damit viele Objektabbildungen. Bei Fotografien machen oft nur zwei Abbildungen Sinn: die Vorder- und die Rückseite. Während Kunstwerke oft gut dokumentiert sind, ist die Dokumentation der Geschichte einer konkreten Gabel oft schwerer.

Deshalb sind wir froh, dass die jetzt aufgeführten Objekte auch bei genauerem Hinsehen wirklich gut dokumentiert sind und viele verschiedene Objektarten und Museen vertreten sind. “Flachware” hat es beim PuQi sicherlich leichter, einen guten Wert zu erreichen, aber in der “Hall-of-Fame” finden sich auch Statuen und Uhren. Der PuQi ist also doch nicht allzu voreingenommen.

info

License

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

Den Bildern mehr Liebe

2019-07-03T00:00:00+00:00

Seit vielen Jahren schreiben wir in musdb IPTC-Metadaten in Objektabbildungen. Damit können Benutzer, die die Bilddateien heruntergeladen haben, auch nach dem Download noch Bildtitel, Beschreibung, und Angaben zur Herkunft auslesen. Auch die “Einzelbildseiten” in der Ausgabe lesen diese Metadaten aus, um Hintergrundinformationen zum Bild anzuzeigen.

Bisher beschränkten sich die Funktionalitäten rund um die Bilddateien allerdings darauf. Bilddateien wurden nach einer Zufallskombination von Buchstaben benannt; und die Bibliothek, mithilfe derer die IPTC-Daten eingetragen wurden war in die Jahre gekommen. Dass jetzt auch Google angefangen hat, Bildmetadaten auszulesen - wenn auch bisher nur, um Lizenzangaben anzuzeigen - hat dann den Ausschlag gegeben: Wir haben die Behandlung von Bilddateien in musdb grundsätzlich überarbeitet und verbessert.

Sprechende Dateinamen

Eine leider fast alltägliche Situation: Man erinnert sich an dieses Bild von letzter Woche. Es muss sich noch im wie immer viel zu vollen Ordner Downloads befinden. Es war eine Karte, also wird heruntergescrollt bis zum Buchstaben “K”, aber da ist keine Bild-Datei. Also sortiert man nach Dateinamen, und nach der gefühlt fünfzigsten Bildvorschau findet man sie schließlich: Die Bilddatei mit dem klangvollen Namen 181215495ad736f5566c0.jpg. Oh, hätte man sie nur mal wieder aufgeräumt. Oder die Datei nach dem Herunterladen gleich richtig benannt.

Objektseite der Karte “Saxonia Svperior” aus dem Kreismuseum Bitterfeld in museum-digital:sachsen-anhalt.

Nein. Das geht besser. Von Seiten der Webseite, von der man die Datei heruntergeladen hat. Das Objekt zur Bilddatei 181215495ad736f5566c0.jpg ist die “Karte ‘Saxonia Svperior’” aus dem Kreismuseum Bitterfeld. Besser wäre es gewesen, die Datei dem Objektnamen entsprechend zu benennen, sodass man sie auch im unaufgeräumten Downloads-Ordner findet. Auch Suchmaschinen liefert ein “sprechender Dateiname” nebenbei mehr verwertbare Kontextinformationen.

Seit diesem Wochenende machen wir es zumindest bei neuen Objektabbildungen besser. Der Objektname wird zur Basis des Dateinamens gemacht. Alle Sonderzeichen werden ersetzt oder entfernt, und Leerzeichen durch einen Bindestrich ersetzt. Bei potentiell doppelten Dateinamen wird “-2” (-3, -4, …) angefügt. Eine Zufallskombination von Buchstaben kommt nur noch zum Einsatz, wenn der Dateiname ansonsten leer wäre (etwa bei rein chinesischen Objektnamen, die nur aus nicht-lateinischen Zeichen bestehen). Würde die Karte also neu hochgeladen, hieße die Bilddatei karte-saxonia-svperior.jpg. Damit bestehende Verlinkungen und Indizierungen nicht gebrochen werden, gilt die “sprechende” Benennung allerdings nur für neue Objektabbildungen.

Bildmetadaten lesen

Beim Hochladen einer Objektabbildung in musdb müssen die Rechteinformationen noch vor dem tatsächlichen Heraufladen eingetragen werden. Bildtitel und Beschreibung können dann im Nachhinein vervollständigt werden. Standardmäßig entsprach der Bildtitel bisher dem Objektnamen, während die Bildbeschreibung leer war.

Arbeitet das Museum nun aber mit einem Digital Asset Management System, einer Bildverwaltungssoftware, oder mit einem externen Fotografen, dann ist es nicht unwahrscheinlich, dass die Bilddatei schon Informationen zu Rechten, Fotograf, Titel und Beschreibung beinhaltet. Diese noch einmal in musdb einzutragen wäre doppelte Arbeit.

Um diese doppelte Arbeit zu vermeiden, werden die Bildinformationen seit dem letzten Update direkt beim Hochladen ausgelesen. Sind ein Bildtitel und/oder eine Bildbeschreibung vorhanden, werden diese in die Datenbank übernommen. Ist ein Fotograf angegeben, der nicht dem “Standardfotografen” des Museums entspricht, wird auch diese Information in die Datenbank übernommen.

Bildmetadaten schreiben

Nach wie vor schreibt musdb Metadaten in die Bilddateien, nur eben jetzt ein bisschen mehr. Neue Datenfelder, die befüllt werden sind die URL unter der das Bild zu finden, die Kontaktdaten des Museums, Schlagworte und abgebildete Personen.

Kontaktinformationen, ausgelesen aus der Bilddatei selbst, können jetzt auf der Bildseite angezeigt werden.

Das Eintragen der Kontaktdaten des Museums als Ansprechpartner ist ein weiterer Schritt, um die Zuständigkeiten für Inhalte bei museum-digital klar zu kommunizieren. Da die Metadaten von Bilddateien auch auf den Seiten für einzelne Objektansichten angezeigt werden, erscheinen die Kontaktdaten so auch in ausführlicher Form neben der Bildansicht (auch wenn man dafür die Informationsseitenspalte anzeigen lassen und gegebenfalls herunterscrollen muss).

Weil Objektabbildungen, nun ja, das Objekt abbilden, gehen wir beim Schreiben der Bild-Schlagworte davon aus, dass diese zumindest in den allermeisten Fällen den Schlagworten der Objekte entsprechen. Anders verhält es sich bei den abgebildeten Personen. Damit Rückseiten, etwa von gescannten Fotos, nicht fälschlicherweise als Abbildungen einer Person gekennzeichnet werden, wird nur beim ersten Bild zu einem Objekt eingetragen, wer hier wahrscheinlich abgebildet ist.

Wichtig dabei für Nutzer von musdb ist, dass die Bildmetadaten nicht automatisch mit den Objektdaten synchronisiert werden. D.h., dass die eingetragenen Informationen dem Stand beim Hochladen entsprechen, nicht notwendigerweise dem letzten Stand der Bearbeitung der Objektinformationen. Um die Bildmetadaten auch im Nachhinein einzutragen, kann der dafür vorgesehene Button im Reiter “Resource” benutzt werden.

Update: Auf Anregung der Kollegen aus Ungarn, wird die Bild-ID nun hinten an Bild-Dateinamen von neuen Objekten angefügt. So können Museen einfach nach ihren Objektabbildungen suchen, während “normale” Benutzer weiterhin einen sprechenden Dateinamen haben.

info

License

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

museum-digital.org

2019-06-10T00:00:00+00:00

Bis zu dieser Woche gab es keine Seite, auf der museum-digital als ganzes vorgestellt wurde. Die deutsche Startseite, museum-digital.de, bot eine sehr grobe Einleitung in das, was wir tun und eine Übersicht über die verschiedenen Instanzen. Die Seite war zweisprachig in Deutsch und Englisch verfügbar, aber hätte aufgrund der Code-Struktur nicht ohne weiteres um weitere Sprachen erweitert werden können. Für museum-digital in Ungarn, MúzeumDigitár, gibt es eine eigene Seite, die jedoch auf die Aktivitäten in Ungarn fokussiert ist und entsprechend nur in ungarisch verfügbar ist.

Da wir schon vor einiger Zeit die Domain “museum-digital.org” gesichert hatten, bot es sich an, diese Lücke mit einer ausführlicheren Projektseite unter museum-digital.org zu schließen. Seit dieser Woche ist diese Projektseite online und öffentlich verfügbar. Zusätzlich zur Vorstellung des Projektes bietet die Seite ein paar Schmankerl, die sie auch für Leute, die mit dem Projekt gut vertraut sind, interessant machen sollten.

Startseite von museum-digital.org mit Karte aller teilnehmenden Museen.

Ein bisschen mehr als eine Vorstellungsseite

Der Hauptzweck von museum-digital.org ist es, die Arbeit bei museum-digital und die Tools, die wir über die Jahre entwickelt haben, vorzustellen. Darüber hinaus dient die Seite aber auch, verschiedene Aspekte und Instanzen von museum-digital zu verbinden.

Integration mit dem Blog

Regelmäßigen Lesern dieses Blogs mag es aufgefallen sein: Wir haben die Kategorien der Blogeinträge in den letzten Monaten vereinheitlicht und einige neue Kategorien (musdb, Ausgabe, etc.) eingeführt. Die neuesten Blogeinträge aus der passenden Kategorie können so unter der entsprechenden Seite auf museum-digital.org erscheinen. Gibt es etwa ein neues Feature in musdb, müssen wir dieses nur im Blog besprechen, damit es auch auf der Seite zu musdb auf museum-digital.org Erwähnung findet.

Damit diese Einträge immer ausreichend aktuell sind, wird der RSS-Feed der gegebenen Kategorie einmal am Tag automatisch ausgelesen.

Dashboard

Das Dashboard auf museum-digital.org zeigt wichtige Daten zur Entwicklung von museum-digital.

museum-digital.org bietet ein Dashboard, mit dem eine Übersicht über die Inhalte und den Status der deutschen und ungarischen Instanzen gefunden werden kann. Zahlen und Visualisierungen gibt es etwa zu:

Anzahl der öffentlichen Objekte, Museen, Sammlungen, Literatureinträge, etc.
Besucherentwicklung im letzten Monat
Angaben zur Qualität der Objekteinträge: Durchschnittlicher PuQi-Score aller öffentlichen Objekte, und durchschnittliche Länge der Objektbeschreibungen

Wie auch die “Graphennavigation” basieren die Visualisierungen im Dashboard auf der JavaScript-Bibliothek vis.js.

Gemeinsame Suche

Ein drittes besonderes Feature von museum-digital.org ist die integrierte Suche. Durch einen Klick auf das Lupen-Symbol in der Navigation aktiviert man die Suchfunktion. Im auffahrenden Overlay befinden sich neben dem Suchschlitz und dem (noch leeren) Resultatsbereich zwei Schalter: “museum-digital.org durchsuchen” und “Nach Objekten suchen”. Mit diesen kann der Suchmodus umgeschaltet werden.

Während die standardmäßig aktivierte Suche alle Inhalte von museum-digital.org - also v.a. die Beschreibungstexte durchsucht, sendet die Suche beim “Objekte durchsuchen” den Suchbegriff an die deutschlandweite und die ungarische Instanz und zeigt die Suchergebnisse aus beiden Instanzen untereinander im Ergebnisbereich an.

Auf APIs gebaut

Abseits der Beschreibungstexte und Bilder, werden die meisten Inhalte von museum-digital.org aus den APIs von unseren verschiedenen Tools und Seiten bezogen.

Die Karte aller teilnehmenden Museen auf der Startseite von museum-digital.org wird aus der JSON-Ausgabe der Institutionskarten der Ausgabe erstellt
Das Dashboard bezieht seine Daten aus der JSON-Ausgabe der Startseite der deutschen und ungarischen Instanzen
Die Suchfunktion von museum-digital.org basiert auf der API der Suche in der Ausgabe
Die thematischen Blog-Posts zu den einzelnen Seiten werden aus den entsprechenden RSS-Feeds des Blogs ausgelesen

Mit der API gebaut?

Apropos API: Die APIs der Ausgabe von museum-digital, und auch die von musdb, können nicht nur immer mehr. Sie werden auch immer mehr benutzt. Deshalb bietet museum-digital.org eine eigene Seite, auf der die öffentlichen, auf unseren APIs basierenden Tools vorgestellt und aufgelistet werden. Bisher sind dort zugegebenermaßen nur die von mir persönlich gebauten Tools zu finden, doch diese Liste dürfte bald wesentlich länger werden.

Liste von externen, auf der API basierenden, Tools.

Konsequente Mehrsprachigkeit

Die statischen Texte der meisten Tools von museum-digital sind konsequent mehrsprachig und werden über unser Übersetzungs-Tool kontrolliert. Ausgerechnet im Fall der deutschen Startseite (museum-digital.de) und des Handbuchs, also der beiden Seiten, die museum-digital.org wahrscheinlich am nächsten kommen, verhält es sich anders. museum-digital.de hat die Übersetzungen fest in die Seite einprogrammiert, sodass sie nicht ohne weiteres zu ändern sind. Das Handbuch wiederum ist mehrsprachig wie Wikipedia: Artikel können in allen Sprachen verfasst werden (oder auch nicht) und müssen dann im Nachhineineinander verknüpft werden. Das hat dazu geführt, dass die deutschen und ungarischen Handbuchseiten sehr unterschiedlich strukturiert sind (und entsprechend nicht sinnvoll miteinander verlinkt werden konnten) und die englisch-sprachige Version des Handbuchs noch fast leer ist.

Für eine Seite, die zwar mehrsprachig, aber doch einheitlich strukturiert und gestaltet sein sollte, hat es sich also, zumindest für Projekte im Rahmen von museum-digital, als besser erwiesen, die gleiche Vorgehensweise wie bei der Übersetzung der Ausgabe oder von musdb zu wählen. Die Struktur der verschiedenen Seiten ist fest geschrieben, aber die Texte selbst werden über das Übersetzungstool geschrieben. So müssen die Übersetzer nur die Texte übersetzen, können aber auf die Struktur keinen Einfluss nehmen.

Bisher ist auch museum-digital.org “nur” auf Deutsch und Englisch verfügbar. Weitere Sprachversionen hinzuzufügen stellt aber zumindest auf technischer Ebene kein Problem mehr dar.

Was kann da noch kommen?

museum-digital.org, wie wir es jetzt veröffentlichen, hat einige entscheidende Unterschiede zur Projektseite, wie sie am Anfang der Planung konzeptioniert war. Während beispielsweise die integrierte Suchfunktion über die verschiedenen Instanzen als “nice-to-have” maximal angedacht war und jetzt schon bei der Veröffentlichung dabei ist, fehlen noch einige der ursprünglich angedachten Seiten und Inhalte.

Eine Liste vergleichbarer Projekte und anderer relevanten Seiten zum Thema (etwa digitaltmuseum.no)
Die Landesmuseumsverbände, die einen großen Beitrag zum Entstehen von museum-digital beigetragen haben und beitragen, sollten vlt. noch klarer gewürdigt werden
Im Dashboard steht bisher der 29.02.2009 als Gründungsdatum. Im Laufe des Schreibens haben wir mehrere widersprüchliche Daten gefunden. Allen gemein ist, dass sie im ersten Halbjahr 2009 waren. Der konkrete Tag wäre aber noch in Erfahrung zu bringen.
Auf der Seite “Veröffentlichungen” haben wir eine Bibliographie zu museum-digital begonnen. Diese ist leider noch sehr unvollständig.

Anregungen und Hinweise zur Verbesserung von museum-digital.org sind herzlich willkommen!

Update (10.06.2019): Bilder und einige Ergänzungen im letzten Absatz eingefügt

info

License

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

Auch das geht: Die "Tour"

2019-05-29T00:00:00+00:00

Auch wenn museum-digital tatsächlich einen starken Objektfokus hat, impliziert der Name doch das allgemeine Ziel der Digitalisierung des Museums. Geht ein Besucher durch das Museum, so sieht er oder sie jedoch nicht nur die Objekte. Zum Museumsbesuch gehören ebenso die Anordnung der Objekte, die Architektur des Hauses, etc.

Versuche, den Gang durchs Museum digital zu erfassen und übers Netz abrufbar zu machen sind nicht neu. Leider sind solche digitalen “Touren” oft unabhängig von der restlichen Seite des Museums oder Portals und nicht allzu leicht zu finden.

Seit einiger Zeit können solche Touren auch bei museum-digital erstellt und veröffentlicht werden. Diese Funktionalität ist einerseits auf Institutionsebene verfügbar, wo etwa das Foyer gezeigt werden kann. Andererseits können Ausstellungen einzeln erfasst werden. Dies ist besonders für temporäre Ausstellungen gedacht, die so auch nach ihrem Ende betrachtet werden können. In der Ausgabe sind die Touren dann auf der jeweiligen Ausstellungs- oder Institutionsseite zu finden.

Eine Tour in musdb erstellen

In musdb, dem Haupt-Eingabetool von museum-digital, gibt es einen grafischen Editor für das erstellen vin Touren. Diesen erreicht man, indem man zur Bearbeitungsseite für eine Institution bzw. eine Ausstellung navigiert. Auf der gebenen Seite findet sich ein Button “Tour anlegen” (auf Institutionsseiten ganz unten; bei Ausstellungen rechts in der Seitenspalte). Durch einen Klick auf diesen Button wird eine neue Tour für die gebene Institution oder Ausstellung angelegt.

Bevor der Editor näher besprochen werden kann, müssen erst einmal einige grundlegende Konzepte erläutert werden. Als erstes: die Szene. Szenen sind die der Tour direkt untergeordnete Ebene. Stellt eine Tour also beispielsweise eine Ausstellung dar, entspräche eine Szene einem einzelnen Ausstellungsraum. Eine Szene hat immer einen Namen (etwa “Raum 1: 1920er Jahre”) und eine Bilddatei (also eine fotographische Aufnahme des Raums).

Das zweite grundlegende Konzept sind “Hotspots”. Hotspots sind als besonderes Markierte Orte innerhalb einer Szene (eines Raumes). Hotspots sind in zwei verschiedene Typen gruppiert. Einerseits gibt es Hotspots zum wechseln zwischen Szenen - mit einem Hotspot auf die Tür zum nächsten Raum könnte man zum Beispiel zur nächsten Szene/zum nächsten Raum navigieren -, andererseits gibt es Info-Hotspots, mit denen der gegebene Ort im Bild markiert werden und mit einem Info-Tooltip und ggfs. einem Link versehen werden kann. Letztere könnten zum Beispiel eingesetzt werden, um vom Objekt in einem Schaukasten auf die entsprechende Objektseite zu verlinken.

Hat man nun also den “Tour erfassen”-Button gedrückt, wurde automatisch eine neue Tour mit einer ersten Szene erstellt. Im nächsten Schritt muss eine Bilddatei (.jpg oder .png) für die neue Szene heraufgeladen werden. Ist dies getan, öffnet sich der Editor. Links findet sich eine Voransicht der Tour (um das Bild zu sehen muss bisher noch bei jedem Seitenaufruf der “Click to Load Panorama”-Button gedrückt werden), rechts findet sich eine Seitenspalte mit verschiedenen Optionen zur Bearbeitung der Tour.

In der Seitenspalte findet sich eine Sektion pro angelegter “Szene” (diese sind bei derzeit nicht angewählten Szenen eingeklappt) und eine für generelle Optionen. In Letzterer finden sich die Optionen “Bild entfernen” - etwa um das heraufgeladene Bild zu ersetzen -, “neue Szene hinzufügen”, “Tour löschen”, und “Zur Ausstellungs/Institutions-Seite zurückkehren”. In der obigen Sektion für die gerade ausgewählte Szene finden sich zwei Unter-Bereiche: Die generellen Szenenoptionen, und die Hotspots für diese Szene.

Im Bereich für generelle Szenen-Einstellungen kann der Name der Szene eingestellt werden. Mit den Feldern “haov” und “vaov” kann die Krümmung des Szenen-Bildes eingestellt werden. Eigentlich ist die Tour auf volle Panorama-Aufnahmen ausgelegt, aber so können auch kleinere Bildausschnitte verwendet werden.

Im Hotspot-Bereich sieht man - so vorhanden - eine Liste der schon für die Szene angelegten Hotspots und darunter die Optione, einen Bereich um einen neuen Hotspot anzulegen. Während die unteren Felder (Text, Typ, URL, Zielszene) selbstverständlich sein sollten, bedarf die Positionierung des Hotspots (Pitch, yaw) einer näheren Betrachtung. Links in der Tour-Vorschau findet sich genau in der Mitte des Bildes ein “+”-Symbol. Um einen Hotspot zu positionieren, muss das Bild bewegt werden, bis sich das “+”-Symbol an der für den Hotspot gewünschten Stelle befindet. Danach kann die Positionierung mit einem Klick in die Felder “Pitch” und “yaw” eingetragen werden.

Weitere Szenen können wie schon erwähnt im Seitenspalten-Bereich für allgemeine Optionen hinzugefügt und dann über Hotspots verknüpft werden. Beim Anlegen einer neuen Szene ist darauf zu achten, dass man beim ersten annavigieren der Szene das entsprechende Bild für die Szene heraufladen muss.

Danksagung

Für das Navigierbar-machen der Tour verwenden wir die JavaScript-Bibliothek Pannellum. Vielen Dank!

info

License

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

Info-Kacheln auf Such-Ergebnisseiten in museum-digital

2019-05-29T00:00:00+00:00

Sucht man bei Google, Bing, DuckDuckGo nach Berlin, erhält man neben relevanten Webseiten eine Kachel, mit zusammengefassten Informationen zu Berlin.

Sucht man bei museum-digital nach Berlin, erhält man neben relevanten Webseiten eine Kachel, mit zusammengefassten Informationen zu Berlin.

Diese “Info-Kachel” wurde bisher noch nicht öffentlich vorgestellt. Dies soll mit diesem Beitrag geschehen.

Die Info-Kacheln vorgestellt

Ein wichtiger Bestandteil der Arbeit bei museum-digital ist die Bearbeitung von kontrollierten Vokabularen für Personen, Orte, Zeiten und Schlagworte. Bearbeitete Einträge haben einen Beschreibungstext, sind, soweit möglich, mit anderen Vokabularen (z.B. der Gemeinsamen Normdatei) verknüpft. Orte und Schlagworte werden zusätzlich hierarchisiert, also als Unter- oder Oberbegriffe zu anderen vorhandenen Einträgen markiert. Ortseinträge werden desweiteren mit Geokoordinaten versehen.

Die so gesammelten Daten bilden die Basis für das Generieren der Infokacheln.

Der Karten-Reiter bei der Suche nach einem Ortseintrag (hier: Berlin)

Diese gibt es für Personen, Orte und Schlagworte, da die zusätzlichen Informationen zu Zeit-Einträgen (“19. Jahrhundert”, “1000-1100 n. Chr”) keinen ausreichenden Mehrwert bieten würden. Jede Info-Kachel hat eine Auswahl von Reitern, unter denen die Reiter “Überblick” und “Normdaten” immer vertreten sind. Auf dem Reiter “Überblick” können grundlegende Informationen wie die Kurzbeschreibung zur gegebenen Person oder zum gegebenen Ort oder Schlagwort abgerufen werden. Unter dem Reiter “Normdaten” können die Links zu verknüpften Normdatenkatalogen gefunden werden.

Entsprechend dem Typ des Gesuchten und der vorhandenen Daten können weitere Reiter erscheinen. Die wahrscheinlich am häufigsten auftretenden optionalen Reiter sind “Hierarchie” (bei Orten und Schlagworten) und “Karte” (bei Ortseinträgen). Mit dem Hierarchie-Reiter kann man zu verwandten - unter- oder übergeordneten und synonymen - Begriffen navigieren. Der Kartenreiter zeigt den jeweiligen gesuchten Ort auf einer Karte.

Ein besonderes Schmankerl ist bei einigen Personenseiten zu finden: Der “Genealogie”-Reiter. Mit diesen kann der Stammbaum der gegebenen Person visualisiert werden. Da die Daten dazu erst einmal erfasst sein müssen, ist diese Funktionalität bisher erst bei einigen wenigen Seiten von v.a. mittelalterlichen Adeligen zu finden, beispielsweise bei einer Suche nach Friedrich I. Barbarossa.

Die Genealogie-Kachel bei der Suche nach (ausgewählten) Personeneinträgen.

info

License

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

Schalter zum Sprach-Wechseln umgestaltet

2019-05-15T00:00:00+00:00

Eine intern öfter gestellte Frage war in der letzten Zeit, ob nicht bestimmte Elemente aus der Navigation einer gegebenen Instanz geschaltet werden könnten. In der brasilianischen Instanz gibt es keinen Themator, in der rheinland-pfälzischen bisher keine Veranstaltungen. Um allzuviele (undokumentierte) Einstellungsvariablen zu vermeiden, haben wir uns meist gegen eine größere Anpassbarkeit der Seitennavigation entschieden. Mit dem heutigen Tag hat sich das geändert: Die Navigationselemente können auf Instanzebene frei angeordnet werden.

Oben rechts findet sich der Sprach-Schalter.

Bei der Gelegenheit bot es sich an, die Navigation generell zu optimieren. Da sie sich nur äußerst selten ändert, kann sie zwischengespeichert werden. Das, zusammen mit einigen weiteren Optimierungen an der Seite sollte die Ladezeit im Vergleich zu vorher verringern. Ein einziges Element stand dem Zwischenspeichern bisher im Weg: der Schalter zum Wechseln der Navigations-Sprache. Dieser wurde also grundlegend überarbeitet und umgestaltet.

Der neue Sprachschalter

Der Schalter zum Sprachwechsel findet sich wie gehabt ganz oben rechts in der Seitennavigation. Statt dem ausgeschriebenen Namen der Sprache in einem einzeiligen Auswahlfeld erscheint dort jetzt der ISO 639-1 Sprachcode in einem leicht hervorgehobenen Kreis. Durch einen Klick auf den Sprachcode öffnet sich ein Dialog, mit dem die gewollte Sprache ausgewählt werden kann.

Der Dialog zur Auswahl der Navigationssprache.

Neben der allgemeinen Designverbesserung sollte diese Änderung auch in verschiedenen Browsern uniform aussehen. Bisher erschien z.B. im Firefox der für Auswahlmenüs typische “Aufklapper”.

P.S.

Reguläre Benutzer der Seite dürften das alte Design des Sprachschalters noch auf einigen Unterseiten sehen, da die Seiten im Browser zwischengespeichert werden. Um endgültig das neue Design zu sehen, hilft es einmal die Sprache zu einer anderen hin und wieder zu Deutsch zurück zu wechseln (ein Sprachwechsel setzt die von museum-digital angeregten Zwischenspeicher zurück).

info

License

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

Kontaktinformationen sichtbarer machen

2019-05-11T00:00:00+00:00

Wen frage ich, wenn ich bei weitere Informationen zu einem Objekt auf museum-digital habe? Wenn ich ein Bild verwenden möchte?

Museen haben bei museum-digital die Möglichkeit eine Kontaktadresse einzutragen. Und doch haben bisher viele Benutzer den entsprechenden Link ignoriert. Stattdessen wurde die Kontaktseite aufgerufen und ein Regionaladministrator kontaktiert - oft ohne eine Angabe, um welches Objekt es konkret geht.

Seit heute sind einige Änderungen online, mit dem Ziel die Museen und ihre Kontaktinformationen sichtbarer zu machen.

Institutionskachel auf der Objektseite

Auf Objektseiten wird das Museum des Objektes jetzt - zusätzlich zum bisherigen Link - über den Nutzungsinformationen in einer eigenen Kachel prominent angezeigt (siehe Screenshot oben). Falls eingetragen, findet sich in dieser Kachel auch ein Link, mit dem eine Mail mit vorformulierten Betreff ans Museum zu schicken. Durch die klare visuelle Abgrenzung und die Museumsabbildung sind die Kontaktinformationen jetzt hoffentlich leichter zu finden.

Kontaktinformation auf Bild- und Veranstaltungsseiten

Kontaktlink auf einer Bildseite.

Auf Bild- und Veranstaltungsseiten war die Kontaktadresse bisher noch nicht zu finden. Bei Veranstaltungsseiten ist sie jetzt wie üblich rechts in der Seitenspalte. Auf (Objekt-)Bildseiten findet sie sich in der dazuschaltbaren Informationsseitenspalte.

Kontaktinformationen zu besuchten Inhalten auf der Kontaktseite

Neben den generellen Kontaktdaten werden auch die Kontaktdaten zu vorherigen Einträgen auf der Kontaktseite angezeigt.

Um die Institutionskachel auf einer Objektseite zu finden muss man scrollen. Die Kontaktadressen auf Institutions-, Sammlungs-, und Veranstaltungsseiten sind in der Seitenspalte “versteckt”. Es kann also immer noch sein, dass Benutzer, die eigentlich eine Anfrage zu einem konkreten Inhalt stellen möchten, zur Kontaktseite navigieren.

Um die Wahrscheinlichkeit zu erhöhen, dass auch diese Benutzer ihre Anfrage direkt der jeweiligen Institution schicken, werden die zuletzt besuchten Seiten mit Kontaktinformationen unter den generellen Kontaktdaten zur Seite aufgelistet.

Ein kleiner Nebeneffekt: Browsing-Geschichte

Um diese Liste zu generieren müssen die zuletzt aufgerufenen Seiten des Benutzers gespeichert werden. Geloggt werden bei jedem Seitenaufruf: URL, Seitentitel, Vorschaubild (so vorhanden), Kontakt-Link (so vorhanden) und das Datum. Dies geschieht rein im Browser - die Browsing-Geschichte wird nie an den Server gesendet.

Die Browsing-Geschichte bleibt auch nach einem Schließen des Browsers vorhanden. Es verbleiben bis zu 50 Seiten im Speicher.

Mit diesen Daten kann so im Browser eine Geschichts-Navigation exklusiv für die gegebene Instanz von museum-digital erstellt werden. Über die Tastenkombination STRG+e gefolgt von STRG+g kann diese aufgerufen werden.

Die Geschichts-Navigation.

info

License

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

Die "Graphennavigation": Netzwerke und Verbindungen in museum-digital erkennen

2019-05-09T00:00:00+00:00

Im letzten Jahr haben wir einige Features in museum-digital eingeführt, die relativ schwer zu finden sind und bisher nie in einem größeren Rahmen besprochen wurden. Die schwere Findbarkeit ist bis zu einem gewissen Grad Absicht: Auch wenn neue Visualisierungen und Zusatzfunktionen sinnvolle Ergänzungen darstellen, geht es bei Objektseiten doch primär um Objekte, bei Institutionsseiten um das jeweilige Museum, etc. Davon sollen zusätzliche Funktionen nicht ablenken.

Dass diese Zusatzfunktionen bisher weder im Blog noch im Handbuch besprochen wurden soll sich nun suksessive Ändern. Als Erstes nun soll es um die “Graphennavigation” gehen.

Wie erreiche ich die Graphennavigation?

Die Graphennavigation kann von den Seiten einer gegebenen Einzelentität (etwa eine Objektseite, eine Museumsseite, eine Sammlungsseite) aus erreicht werden. Auf diesen Seiten findet sich in der jeweiligen Options-Sidebar ein Link zur Graphennavigation. Auf Objektseiten findet sich dieser Link sowohl oben neben dem Titel als auch unten im Optionen-Bereich.

Weg zur Graphennavigation auf Objektseiten: Oben rechts neben dem Bread-Crumb findet sich ein Button zum öffnen der Graphennavigation

Auf Institutionsseiten findet sich der Link zur Graphennavigation in der rechten Seitenspalte.

Die Graphennavigation

Die “Graphennavigation”

Die Graphennavigation dient einer graphischen Darstellung der Verknüpfungen zwischen den verschiedenen Einträgen und Eintragstypen. Öffnet man etwa auf einer Objektseite die Graphennavigation, erscheinen die mit dem Objekt verknüpften Personen, Schlagworte, Orte, Objektgruppen, etc. als jeweils entsprechend eingefärbte Knotenpunkte. Durch einen Klick auf einen Eintrag, lassen sich die mit diesem verknüpften Daten nachladen. In der Seitenspalte am rechten Bildschirmrand finden sich standardmäßig Details zum derzeit fokussierten Datenpunkt.

Oben in der Seitenspalte gibt es weitere Reiter: “Was”, “Optionen” und “Verstecken”. Unter “Was” erreicht man eine kurze Einführung in die Benutzung der Graphennavigation. Mit “Verstecken” kann die Seitenspalte ein- und ausgeblendet werden.

Unter “Optionen” gibt es eine Reihe von Schiebern, mit denen die Sichtbarkeit der verschiedenen Eintragstypen an- und ausgeschaltet werden kann. Mit dem Schieber hinter “Objekt” können beispielsweise alle Objekt-Datenpunkte unsichtbar geschaltet werden. Dies ist besonders hilfreich, wenn durch Weiterklicken eine Vielzahl von Einträgen sichtbar gemacht wurden.

Unter den Schiebern finden sich zwei Buttons. Mit dem Ersten lässt sich die Ansicht auf den gerade ausgewählten Datenpunkt fokussieren - gerade wenn viele Daten dazugeladen wurden kann es ohne diesen Schalter manchmal schwer werden, den gerade Gewählten wiederzufinden.

Die “Graphennavigation” lässt sich über die rechte Seitenspalte anpassen. Hier wurden etwa die normalen Kreise zur Symbolisierung der einzelnen Entitäten durch weitergehend beschriftete Boxen ersetzt.

Mit dem zweiten Button lassen sich die Datenpunkte als Boxen mit entsprechender Beschriftung statt Kreisen mit dem Typen entsprechenden Beschriftungen anzeigen. Einerseits wird das Netzwerk dabei leichter verständlich - weil aber die vollen Namen gerade bei Objekten oft lang sind kann diese Ansicht schnell unübersichtlich werden.

Zum Erstellen der Graphennavigation benutzen wir die JavaScript-Bibliothek vis.js.

info

License

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

Neue Liste zur Wahl der Ereignistypen in musdb

2019-04-28T00:00:00+00:00

Im letzten Jahr haben wir musdb, das Eingabe- und Inventarisierungstool von museum-digital, neu designed, stark erweitert und an vielen Stellen auch neu geschrieben. Eine Stelle, die auch beim Neudesign des letzten Jahres nicht wirklich elegant gelöst wurde, war bis heute die Auswahlliste für Ereignistypen beim Erstellen eines neuen Ereignisses.

Auswahlliste der Ereignistypen bis 28.04.2019

Die Schalter, mit denen der jeweilige Ereignistyp ausgewählt werden kann, waren als Buttons formattiert. Damit bei der wachsenden Liste genügend verschiedene Typen auf eine Seite passen, waren die Buttons allerdings schon im Vergleich zu normalen Buttons in der Höhe reduziert. Einerseits konnten wir so erreichen, dass die Auswahlfelder klar als solche markiert und von den Hilfstexten rechts abgehoben waren. Andererseits sah die Liste so weder ansprechend aus, noch ihr Design mit dem des restlichen musdb vollständig konsistent. Heute haben wir dieses Problem durch behoben.

Die neue Auswahlliste

Auswahlliste der Ereignistypen ab 28.04.2019

In der überarbeiteten Auswahlliste gibt es zuerst einmal eine Eingabe, mit dem die Liste für ein schnelleres Auswählen gefiltert werden kann. Darunter finden sich die schon bekannten Auswahlmöglichkeiten als Tabelle formatiert. Die Auswahlfelder sind statt als Buttons als linksstehende Tabellenköpfe formatiert. Durch die Hintergrundfarbe, die wir auch sonst für Buttons- und Aktionsfarben verwenden, sind die Auswahlfelder als solche markiert. Andererseits ist die Liste eine ganz neue Kategorie im Design, sodass sich das Problem der gebrochenen Konsistenz nicht stellt.

Zusätzlich zur Umformatierung zur eindeutigen Tabelle erscheinen jetzt die Ereignistyp-Symbole, die bisher schon in (Ereignis-)Zeitleisten in der Ausgabe verwendet werden, vor dem Namen des Ereignistyps. Für drei kürzlich eingefügte Ereignistypen gibt es deshalb seit heute auch entsprechende Symbole: “bemalt” (), “illustriert” (), und “wurde abgebildet (Ort)” ().

info

License

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

museum-digital übersetzen

2019-03-02T00:00:00+00:00

In nächster Zeit wird die Ausgabe von museum-digital vorraussichtlich in einige zusätzliche Sprachen übersetzt. Aus diesem Anlass möchte ich hier den Prozess des Übersetzens von museum-digital vorstellen.

Die Übersetzungen müssen derzeit an mehreren Stellen geschehen. Für alle Textstücke, die im serverseitig ablaufenden Code verwendet werden, haben wir ein eigenes Übersetzungstool. Zusätzlich gibt es (weniger) Übersetzungsvariablen, die in JavaScript-Dateien verwendet werden, die im Browser des Seitenbenutzers ausgeführt werden. Diese müssen noch direkt im JSON-Format bearbeitet werden.

Das Übersetzungstool

Zum Beginn des Übersetzens erhält jeder Übersetzer einen Account in unserem Übersetzungstool. Mit diesem Account sind dem Nutzer zwei Sprachen zugeordnet: Einerseits die Ausgangssprache, aus der heraus übersetzt wird, und andererseits die Zielsprache, in die Übersetzt wird.

Tabelle, in der die Übersetzungen bei museum-digital stattfinden.

Nach dem Einloggen erreicht man zuerst eine Übersicht der übersetzbaren Dateien, in Kacheln gruppiert nach ihrem Anwendungsfeld (“Backend”, “Frontend”). Jede Kachel enthält eine Liste von Dateinamen. Durch einen Klick auf einen dieser erhält man die Möglichkeit, die jeweilige Datei in einer Tabelle zu bearbeiten. Die Dateien sind dabei grob ihrem Anwendungszweck nach benannt: home.json im Bereich “Frontend” enthält Variablen, die auf der Startseite der Ausgabe von museum-digital verwendet werden.

Die Tabellen in denen nun eine Datei übersetzt wird sind immer gleich aufgebaut. In der linken Spalte steht der Name der jeweiligen Übersetzungsvariable. In der Mittigen steht der Inhalt der Variable in der Ausgangssprache. Rechts befindet sich ein Textfeld, in das die Übersetzung eingetragen werden kann. Direkt unter der Tabelle befindet sich ein “Save”-Button, mit dem die Übersetzungen dann auch final eingetragen sind.

Meine Übersetzungen sind nicht gleich sichtbar?

Screenshot des “Freischalt-Bereichs” für Administratoren im Übersetzungstool von museum-digital. Im unteren Bereich findet sich der Überblick über den Status der Übersetzungen, erstellt mithilfe von git.

Übersetzungen, die so gemacht wurden, sind nicht sofort sichtbar. Weil die Übersetzungsdateien auch HTML-Markup enthalten können, das falsch geschrieben die Darstellung der Seite stören könnte, haben wir eine Überprüfungsphase zwischengeschaltet.

Sind einige Dateien übersetzt, gibt der oder die Übersetzende einem Administrator bescheid. Dieser kann die neuen Übersetzungen dann in einem gesonderten Administrationsbereich freischalten. Technisch gesehen bedeutet das, dass die .json-Dateien in .php-Dateien überführt werden, die dann direkt durch das Programm aufgeführt werden können. Um einen Überblick über die Änderungen zu erhalten, werden diese dem Administrator im “Freischalt-Bereich” angezeigt.

Weitere Übersetzungen

Nach der Übersetzung mit unserem Übersetzungstool verbleiben einige Textstücke, die in browserseitig ausgeführtem Code verwendet werden. In diesem verwenden wir eine andere Struktur für das Laden der Übersetzungen: Statt immer nur die Sprache zu laden, die gerade benötigt wird, werden immer alle verfügbaren Sprachvarianten geladen. Statt in eigenen Dateien befinden sich die Übersetzungen in demselben Script, wie der Code, der sie verwendet. Deshalb können diese Textstücke bisher noch nicht mit dem Übersetzungstool übersetzt werden. Stattdessen müssen diese direkt im Code übersetzt werden.

Damit dies geschehen kann, sendet ein Administrator den Übersetzenden die jeweiligen Code-Schnipsel per Mail zu, in die die Übersetzung eingetragen werden muss. Nachdem diese zurückgeschickt und in den Code eingefügt wurden, ist die Übersetzung beendet.

info

License

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

md:term

2019-02-28T00:00:00+00:00

Dies ist ein alter Beitrag zu md:term aus meinem persönlichen Blog, der bisher hier nicht auffindbar war. Da mich in letzter Zeit häufiger Fragen zum maschinellen Auslesen der kontrollierten Vokabulare von museum-digital erreichen, veröffentliche ich ihn hier noch einmal. Auch wenn der Beitrag, ursprünglich geschrieben im Januar 2017, schon älter ist, sollte md:term doch im Blog von museum-digital vorgestellt sein.

Seit letzter Woche ist die neue API für die kontrollierten Vokabulare bei Museum-Digital online: md:term. Zusätzlich zur eigentlichen Schnittstelle bietet md:term einen Vokabularbrowser, mit dem Benutzer (ob Programmierer oder nicht) durch die Vokabulare navigieren können.

Kontrollierte Vokabulare bei Museum-Digital

Eine Suche nach dem Begriff Helm. Links sind Angaben zum Begriff zu finden.

Kontrollierte Vokabulare kommen bei Museum-Digital sowohl bei der Suche als auch bei der Bereitstellung von Kontextdaten zu Museumsobjekten zur Anwendung. Wer z.B. in der deutschlandweiten version von Museum-Digital nach Helm sucht, wird in der Seitenspalte links eine Liste mit unterbegriffen und verwandten Begriffen von Helm finden, die aus den internen kontrollierten Vokabularen gespeist wird. Ist nun ein Objekt ausgewählt, finden sich hinter den Namen von verknüpften Personen und Orten Schalter mit dem Buchstaben i. Klickt der Benutzer auf einen dieser Schalter, werden (so vorhanden) Daten aus den kontrollierten Vokabularen von Museum-Digital angezeigt - Beschreibungen, alternative Namen, Links zu z.B. Wikipedia - oder anhand dieser Daten aus anderen Quellen hinzugeladen - z.B. Karten im Fall eines verknüpften Ortes, auf denen der Ort mithilfe von bei Museum-Digital gespeicherter Koordinaten lokalisiert wird.

Kontrollierte Vokabulare sind also ein wichtiges, wenn auch relativ leicht zu übersehendes Element von Museum-Digital. Entsprechend wird viel Arbeit in die Moderation der Vokabulare gesteckt.

Informationen zu Friedrich IV. von Braunschweig-Lüneburg (1574-1648) werden, so angefordert, zur Objektseite Medaille von Johann Blum auf Herzog Friedrich von Braunschweig-Lüneburg und die Verhandlungen zum Westfälischen Frieden, 1646 hinzugeladen.

Während jeder Eingebende neue Begriffe hinzufügen kann, werden diese von einer ausgewählten Gruppe von Leuten moderiert, angereichert oder ggfs. mit existierenden Begriffseinträgen zusammengeführt.

Mittlerweile sind alleine in den deutschsprachigen kontrollierten Vokabularen - unterteilt in Personen, Orte, Zeiten und Schlagworte - über 55000 moderierte Begriffe vorhanden, die sicherlich nicht nur für die Verwendung bei Museum-Digital nützlich sein können. Das Schreiben einer öffentlichen und generell nutzbaren Schnittstelle ist eine logische Konsequenz hiervon.

md:term

Daten aus den kontrollierten Vokabularen sind bei md:term in bisher drei Formaten abrufbar: Einer im Webbrowser betrachtbaren und navigierbaren HTML-Version, in JSON und SKOS, die als leicht maschinenlesbare Formate die Benutzung durch externe Programierer erleichtern.

Ein wichtiger Teil von md:term ist hierbei die Umbenennung von Variablen. Während museum-digital ursprünglich in Deutschland entstanden ist und in der Datenbank entsprechend deutsche Namen verwendet werden, wird es mittlerweile beispielsweise auch in Ungarn eingesetzt. Damit die Benutzung der kontrollierten Vokabulare auch durch nicht deutschsprachige Programmierer möglich ist, werden die Variablennamen mit englischen Entsprechungen überschrieben.

Ebenfalls auf internationale Benutzbarkeit ausgerichtet, bietet die HTML-Version deutsche und englische Übersetzungen von feststehenden (also nicht nur zu einem einzelnen Datensatz gehörenden) Texten, z.B. Überschriften und der Navigation. Dies kann in Zukunft leicht um zusätzliche Sprachen erweitert werden.

Daten von md:term abfragen

Zur Abfrage von md:term in JSON und SKOS muss die ID eines Eintrags in der entsprechenden Datenbank bekannt sein. Ist dies der Fall, wird eine Abfrage in der URL nach dem Format https://term.museum-digital.de/Name der Vokabularversion (z.B. md-de)/Typ des Eintrages/ID/format durchgeführt. Zum Beispiel:

$ curl https://term.museum-digital.de/md-de/place/13384/json
{
    "id": "13384",<br>"name": "Abtstra\u00dfe (Brandenburg an der Havel)",
    "class": "Stra\u00dfe",
    "tgn": "",
    "geonames": "",
    "latitude": "52.406989561274",
    "longitude": "12.564392566637",
    "zoom": "16",
    "note": "Stra\u00dfe in Brandenburg an der Havel",
    "synonyms": [],
    "references": [],
    "broader": {
        "": [{
            "name": "Brandenburg an der Havel",
            "broader_id": "246"
        }]
    },
    "narrower": []
}

Aus den Abfrageergebnissen kann man IDs für weitere Abfragen finden, der Ort im Beispiel, die Abtstraße (Brandenburg an der Havel) mit der ID 13384 ist Brandenburg an der Havel mit der ID 246 untergeordnet.

Eine Suchfunktion ist bisher nur in der HTML-Ausgabe vorhanden. Gibt es ein im Namen perfekt übereinstimmendes Suchergebnis oder nur ein einziges bei einer loseren Entsprechung, wird direkt auf den entsprechenden Eintrag umgeleitet. Gibt es zwei oder mehr, so werden dem Benutzer die möglichen Suchergebnisse mit Titel und, so vorhanden, Beschreibung aufgelistet.

Ist man so zum gewünschten Eintrag gelangt, ist über der Ausspielung der Daten ein Feld mit der Abfrage-URL und - direkt darunter - Links zum Eintrag in alternativen Formaten zu finden.

Screenshot aus md:term. Zeigt eine Ortsansicht.

[Originalbeitrag: https://www.jrenslin.de/post/40]

info

License

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

Museum-Digital bei WDR 5 Quarks

2019-02-20T00:00:00+00:00

Gestern war museum-digital Thema eines Beitrags bei WDR 5 Quarks (Sektion: Hintergrund). Der Beitrag kann in der Mediathek des WDR angehört werden.

Update (Mai 2022): Link entfernt, weil der Beitrag leider depubliziert wurde.

info

License

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

Logos, Logos, Logos

2018-10-26T00:00:00+00:00

Anfang dieser Woche haben wir, wie einige Leser schon gesehen haben könnten, die Logos der internationalen Instanzen von museum-digital und das Logo, das im Handbuch angezeigt wird, angepasst.

Der Grund dafür ist simpel. Bisher gab es ein “Grund-logo”, das auf allen Instanzen benutzt wurde. Die einzigen Ausnahmen stellten das “bunte” Logo der deutschlandweiten Instanz und das Logo der Ungarischen dar. Regional strukturiert wie die Instanzen waren somit auch die Logos, was dazu führte, dass es kein Logo für museum-digital als übergreifendes Projekt gab (bisher hatten wir für diesen Zweck immer das Logo für die deutschlandweite Instanz benutzt, aber auch das ist ja eine starke regionale Eingrenzung). Das Logo für museum-digital findet zunächst seinen Platz im Handbuch.

Als zweiter Schritt wurde ein eigenes Logo für die internationalen Instanzen (abseits der Ungarischen) hinzugefügt. So wie die regionalen Instanzen in Deutschland dasselbe Logo mit verschiedenen Farben haben, haben auch die internationalen Instanzen ein in ihrer jeweiligen Farbe gefärbtes Logo. Das Logo ist nur leicht von dem bisherigen abgewandelt.

Die Logos können als Vektorgrafiken (unter CC-BY lizensiert) im Handbuch heruntergeladen werden.

info

License

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

md:cms - Erste Schritte

2018-07-15T00:00:00+00:00

Bei museum-digital haben wir viel Kraft und Zeit in die API gesteckt - aber auch nach mehr als einem Jahr fehlen Beispiele von Programmen, die die API benutzen. Das mag daran liegen, dass die API lange Zeit nicht vollständig öffentlich dokumentiert war, oder daran, dass sich die Uhren im Museumsbereich generell etwas langsamer drehen.

Andererseits gibt es unter den Museen bei museum-digital (und anderswo) immernoch relativ viele, die keine eigene Website haben. Damit fällt zumindest für diese Institutionen der offensichtlichste Anwendungszweck schon von vorne weg aus.

Auf Basis der API könnten Museen Voransichten ihrer Objekte auf ihrer Webseite einbinden - sei es thematisch zu einem Beitrag passend oder als “Objekt des Monats” o.ä. auf der Startseite. Sie könnten sich einen Veranstaltungs- oder Ausstellungskalender anzeigen lassen, mit den Ausstellungen und Veranstaltungen die bei museum-digital eingetragen sind. Oder sie könnten eine Suche nach Objekten aus ihren Sammlungen auf ihrer eigenen Webseite bereitstellen.

Um ein Beispiel für eine Anwendung der API zu liefern und gleichzeitig vielleicht (d.h. hoffentlich) den kleinen Museen, die noch keine eigene Webseite haben, zu helfen habe ich mich im Laufe des Monats daran gesetzt ein kleines Content Management System zu bauen, das Museen ermöglichen soll, möglichst einfach eine simple Webseite zu bauen, in die nach Bedarf und auf eine einfach Benutzbare Art und Weise Inhalte aus museum-digital einfließen gelassen werden können.

Bisher ist der Code nur für die bei museum-digital teilnehmenden Museen zugänglich oder auf Anfrage zu erhalten, aber es ist geplant das CMS mittelfristig Open Source zu stellen. Bis es soweit ist, hoffe ich eine Hand voll Museen finden zu können, die das CMS ausprobieren und Feedback liefern können.

Ziele

Um die beiden Hauptziele bei der Erstellung des CMS, eine einfache Benutzbarkeit und eine ausreichende Integration mit der API von museum-digital, zu erfüllen, muss das System einige Bedingungen erfüllen.

Einfache Installierbarkeit
- Installation per Kopieren von Dateien oder automatisierbar
- Wenige Abhängigkeiten (e.g. ohne, dass ein gesondertes Datenbanksystem benötigt wird)
Flexbilität
- Das System muss mit verschiedenen Instanzen von museum-digital umgehen können
- Themes: Das Design sollte einfach anpassbar und austauschbar sein
Einfache Bearbeitung
- WYSIWYG-Editor
- Einfache Integration mit museum-digital

Installation

Bei Seitenaufrufen werden wichtige Ordner und Dateien, soweit möglich, angelegt, wenn Sie noch nicht installieren. Auch data ist ein solcher Ordner: er existiert nicht, wird aber ggfs. beim ersten Seitenaufruf automatisch angelegt.

Um das CMS auf einem Server zu installieren, muss man die zip-Datei mit dem Code entpacken und die Inhalte auf den Server, auf dem es später laufen soll, heraufladen. Um in den Bearbeitungsbereich zu gelangen muss nun noch die Datei users.json.sample aus dem Unterordner appFiles in einen neuen Unterordner data kopiert werden und in users.json umbenannt werden. Damit ist der Standardbenutzer installiert.

Die Systemanforderungen sind relativ gering. Das CMS ist in PHP 7 geschrieben, dass auf den meisten Servern eh schon installiert ist. Weil einige Features von PHP 7 verwendet werden, die in PHP 5.X noch nicht verfügbar sind, sollte aber darauf geachtet werden, dass für den gegebenen Webspace / vHost etc. tatsächlich PHP 7 aktiviert ist.

Ansonsten wird ein SSL-Zertifikat benötigt, damit die Kommunikation mit dem Server besonders im Eingabebereich verschlüsselt ablaufen kann (einfach ausgedrückt: die Seite muss unter einer mit URL https:// abrufbar sein). Ist keine verschlüsselte Verbindung möglich, lässt das System keine Benutzer in den Eingabebereich.

Um Seiten zu bearbeiten empfielt es sich auch, einen halbwegs aktuellen Browser zu benutzen.

Seiten bearbeiten

Die Startseite des Eingabebereichs

Nach dem Einloggen im Eingabe-Bereich erscheint ein Willkommensbildschirm, mit einem kurzen Willkommenstext. Dieser Willkommenstext kann von Benutzern mit Adminrechten bearbeitet werden und bietet etwa die Möglichkeit, Regeln für das Schreiben von Beiträgen an einer für Bearbeitende oft gesehenen Stelle zu vermerken.

Links findet sich die Navigation mit Links zu den Bearbeitungsseiten für Seiten und fest stehende Seitenelemente. Klickt man auf “Seiten” erscheint eine Übersicht aller verfügbaren Seiten; mit einem Klick auf das + daneben werden neue Seiten angelegt.

Einzelne Seiten

Für einzelne Beiträge oder können jeweils ein Titel, der Seiteninhalt, die Position in der Seitenhierarchie / Navigation und der Status als Entwurf oder öffentlicher Artikel angegeben werden. Die Bearbeitung von Seiteninhalten erfolgt mithilfe des WYSIWYG-Editors TinyMCE. So können Inhalte formatiert und z.B. Bilder auch ohne HTML-Kenntnisse eingefügt werden.

Des weiteren können verschiedene Typen von Inhalten aus museum-digital über Platzhalter in den Text eingefügt werden. Um die Platzhalter zu generieren, findet sich am unteren Ende der rechten Seitenspalte ein Generator: Erst wird der Typ der Einbettung ausgewählt, dann zusätzliche URL-Parameter für die Auswahl eingegeben, dann kann mit einem Klick auf Generieren der Platzhalter generiert und in den Text kopiert werden.

Ein Beispiel: Um das Objekt Holzstelzsandalen, Syrien, Türkei als Vorschau-Kachel einzubetten, müsste man zuerst den Einbettungstyp Einzelobjekt (Kachel) auswählen. Danach muss man auf die URL der Objektseite bei museum-digital achten: https://st.museum-digital.de/index.php?t=objekt&oges=46083. Nach “index.php” folgen die URL-Parameter. t=objekt bedeutet, dass es sich hierbei um eine Objektseite handelt - das ist durch den Einbettungstyp schon implizit bekannt und deshalb weniger interessant. oges=4608 ist an dieser Stelle der entscheidende Parameter: Er besagt, dass das Objekt mit der internen Nummer 4608 gemeint ist. Entsprechend kann oges=4608 nun in den Schlitz für zusätzliche Parameter eingefügt werden. Mit einem Klick auf Generieren wird der Platzhalter ([singleObjectTile]{oges=46083}) generiert. Dieser kann durch kopieren frei im Text platziert werden.

Feste Seitenelemente

Auf eine ähnliche Art und Weise können auch feste Seitenelemente bearbeitet werden: Banner, Seitenspalte und Fußzeile. Ebenso wie bei den Hauptseiteninhalten kommt hier TinyMCE zum Einsatz, um die jeweiligen Elemente zu bearbeiten.

Es fehlen jedoch die Schalter für die Hierarchie und den Veröffentlichungsstatus. Um ein Seitenelement nicht anzuzeigen, kann das entsprechende Eingabefeld einfach leer gelassen werden.

Integration mit museum-digital

Die Integration mit museum-digital beschränkt sich nicht auf die genannten Einbettungen in normale Seiten. Zusätzlich zu diesen gibt es für die verschiedenen Arten von Einträgen bei museum-digital jeweils Spiegelseiten, mit den Detailinformationen aus museum-digital aber abgespeckter Funktionalität (es fehlen etwa die Social Media-Buttons und die Zitierfunktion). Wird das CMS von nur einer Institution benutzt, kann dies in den Seiteneinstellungen vermerkt werden, damit nicht auch die Inhalte anderer Institutionen verfügbar gemacht werden.

Die Suchfunktion des CMS bietet außerdem neben einer Volltextsuche in den Seiten selbst eine Suche in den Objekten des Museums (oder der Museen, auch mehrere sind möglich). Dies ist möglich durch ein Abfragen der Such-API von museum-digital.

Um die vielen Inhalte, die von museum-digital hinzugeladen werden, nicht bei jedem Aufruf der Seite neu abrufen zu müssen, besteht die Möglichkeit diese zwischenzuspeichern. Um den Server von museum-digital nicht übermäßig zu belasten und gleichzeitig die Ladezeit der eigenen Seite wesentlich zu verringern, lohnt es sich dieses Feature in den Seiteneinstellungen zu aktivieren.

Hilfetexte

Um dem Ziel einer möglichst einfachen und klaren Benutzbarkeit weiter näher zu kommen, gibt es hinter jedem Eingabefeld mit Ausnahme von Seitentiteln und Hauptinhalten ein Feld mit Hilfeinformationen. Dieses ist durch ein grau bzw. blau hinterlegtes Fragezeichen erkennbar. Beim überfahren mit der Maus wird der Hilfetext sichtbar.

Ebenso gibt auf jeder Seite des Eingabebereichs Schalter für Hilfetexte, die die ganze Seite betreffen. Diese finden sich immer oben ganz rechts auf der Seite.

Sicherheit

Gerade im technischen Bereich haben Museen oft nur wenige oder keine eigenen Kräfte, die sich z.B. um das Aufsetzen einer Webseite kümmern können. Umso mehr sollte ein CMS für Museumswebseiten Sicherheitsfeatures von Haus aus anbieten - und by default aktiviert haben. Gleichzeitig sollten diese möglichst wenig beim Bearbeiten der Seite ins Gewicht fallen.

Derzeit sorgen vor allem zwei Maßnahmen für eine erhöhte Sicherheit: Einerseits der Zwang zu HTTPS, das mittlerweile eigentlich ein Muss für Webseitenbetreiber ist, und andererseits die Implementation von Content Security Policies.

CSPs sind eine Maßnahme gegen Cross-Site-Scripting-Angriffe, also das Ausführen von externem Code auf der eigenen Seite, mit dem Daten von der eigenen Seite (z.B. Passwörter) an den Angreifer übertragen werden können. CSPs schützen dagegen, indem verschiedene Datenquellen und Typen von Datenquellen gezielt freigeschaltet werden müssen. Die Webseitenadministratoren können so etwa dem Browser des Benutzers mitteilen, dass Videos nur von der eigenen Seite oder https://youtube.com geladen werden können sollen, Bilder aber nur von der eigenen Seite.

Mehr Informationen dazu finden sich in den Hilfetexten hinter den entsprechenden Eingabefeldern in den Seiteneinstellungen. Um zu den Seiteneinstellungen zu gelangen, muss man als Administrator eingeloggt sein.

Weil CSPs bisher nur von relativ wenigen Seitenadministratoren implementiert werden, unterstützt das CMS sie von Haus aus. Falls der Administrator sie aber schon auf Server-Ebene umgesetzt hat, ist das dem Setzen durch das CMS vorzuziehen, deshalb ist dieses Feature abschaltbar.

Ein erster Schritt

Die Grundfunktionen zum Erstellen einer Museumsseite sind mit dem CMS auf seinem jetzigen Stand weitgehend abgedeckt. Dies gilt besonders für Museen, die museum-digital mit allen seinen Publikationsfunktionen benutzen und z.B. auch Ausstellungen und Veranstaltungen dort eintragen. Gleichzeitig fallen mir selbst schon bei kurzem Nachdenken einige Features ein, die wahrscheinlich relativ bald benötigt werden könnten. Dazu zählen etwa die Möglichkeit Seiten auch auf gleicher Ebene zu sortieren (also ihre Reihenfolge festzulegen) oder eine Blogfunktion.

Das Bestehende ist aber meiner Einschätzung nach schon ein erster stabiler Schritt. Ich würde mich über Tester, Anwender und Feedback freuen.

info

License

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

museum-digital und die Tastatur

2017-12-03T00:00:00+00:00

Eine kurze, aber erfreuliche Nachricht: Wir haben begonnen, an der Navigierbarkeit von museum-digital rein mit der Tastatur zu arbeiten. Auch wenn dies eher ein kleines Liebhaberprojekt sein mag, dürfte es gerade für die, die häufig mit museum-digital arbeiten eine willkommene Erleichterung sein.

Tastenkombinationen

Drückt man F1 während man auf einer der Instanzen von museum-digital surft, erscheint folgende Übersicht:

Left / Right

Previous / next image (only on image pages)

CTRL+Left / CTRL+Right

Previous / Next page (available on all paginated or ordered pages)

CTRL+I

Open image viewer (on object page)

CTRL+Y

Focus search for objects

CTRL+E / CTRL+R

Toggle overlay for searching for museums / collections

CTRL+0

Return to home page

CTRL+1 - CTRL+9

Open the first, second … entry in list (museum overview, collection overview)

F1

Show this help overlay

Der Hilfetext ist bisher in Englisch und wird in nächster Zeit wahrscheinlich noch nicht übersetzt werden, aber die kurzen Erläuterungen sollten trotzdem verständlich sein.

Mit den Cursortasten kann zwischen Bildansichten navigiert werden. Mit Cursortasten und gedrückter Steuerungstaste navigiert man generell zur nächten oder vorherigen Seite bei geordneten Seiten. Dazu gehören Suchergebnisse, aber auch die Museums- und Sammlungsübersichten. Auf Such- und Übersichtsseiten kann des weiteren mit der Steuerungstaste und den Zahlen 1-9 zum entsprechenden Eintrag der Liste navigiert werden.

Die andere Kategorie der bisher eingebauten Tastenkombinationen stellen solche dar, mit denen man einen schnellen Zugriff auf Suchfunktionen hat. Mit STRG+Y wird der Suchschlitz für Objekte, oben auf der Seite, fokussiert. Mit STRG+E und STRG+R haben Benutzer einen Schnellzugriff auf die Suche nach Museen bzw. Sammlungen.

Warum die Steuerungstaste

Wichtig beim Setzen der Tastenbelegungen war uns, dass möglichst wenige der Tasten unerwartet gedrückt werden und das unbedarfte Benutzer nicht überrascht werden. Deshalb sind außer für den speziellen Fall von Abbildungsseiten - dort sollte eine Navigierbarkeit per Cursortasten intuitiv verstehbar sein - und F1, das so oder so nicht häufig aus Versehen gedrückt wird, alle Tastaturbelegungen mit der Steuerungstaste verbunden.

Zusätzlich waren wir bemüht, im Browser gesetzte Tastenkombinationen nicht zu überschreiben. Daher kommt die etwas unintuitive Belegung von STRG+Y mit dem Fokussieren der Suche.

Ein erster Schritt

Das alles kann nur als erster Schritt bezeichnet werden. Aber nun, da der Code für spezifische Tastenbelegungen einmal da ist, ist es relativ leicht, neue hinzuzufügen. Also: Falls es Vorschläge für weitere, sinnvolle Ergänzungen gibt, sind Mails immer willkommen!

Das gilt bedingt auch für die Eingabeseite von museum-digital. Hier ist bisher nur das Navigieren zwischen den Bearbeitungsseiten für Objekte per STRG+Links und STRG+Rechts möglich. Mehr folgt bei Bedarf.

Zuerst erschienen auf jrenslin.de

info

License

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