museum-digital:blog - musdb

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.

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.

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.

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.

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.

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.

3D-Digitalisate in md auch für kleine Museen - Ein Erfahrungsbericht

2024-11-19T00:00:00+00:00

Ein Beitrag von Marleen Schindler, wissenschaftliche Mitarbeiterin am Sorbischen Institut Bautzen

Wenn Exponate aus kleinen Heimatstuben oder umfangreichen städtischen Sammlungen unabhängig von Zeit und Ort von Interessierten bequem von zu Hause gefunden und interaktiv von allen Seiten betrachtet werden können, ist das sicher ein großer Mehrwert für eine nutzerfreundliche Museumslandschaft. Möglich wird das beispielsweise durch 3D-Digitalisierung und Veröffentlichung von Objekten über museum-digital. Doch 3D-Projekte schrecken ab, benötigen sie doch oft Zeit und Ressourcen, die in den meisten Museen nicht fest eingeplant sind. Besonders finanzielle Fragen stehen den ersten Schritten auf dem Weg zu 3D-digitalisierten Objekten oft im Wege. Müssen Sie aber nicht!

Niedrigschwellige 3D-Lösungen

Inzwischen gibt es gute Lösungen, um mit wenig finanziellem Aufwand 3D-Modelle von Objekten zu erstellen und sie zu veröffentlichen. Ein möglicher Weg soll hier knapp skizziert werden und dabei aufzeigen, dass 3D Technik durch museum-digital niedrigschwellig zugängig ist.

Im Rahmen eines Drittmittelprojektes zur fotografischen Erfassung der Sammlung von Lotar Balke stand das Sorbische Institut Bautzen vor einem ähnlichen Problem. Etwa 2000 Sorbische Ostereier sollten fotografiert und mit Hilfe von museum-digital Schritt für Schritt dokumentiert werden (Ostereiersammlung, in Bearbeitung). Die so geschaffenen Metadaten sollen zukünftig in das Sorbische Kulturregister fließen. Die Anschaffung teurer 3D-Technik war im Projekt jedoch nicht vorgesehen. Trotzdem hielten wir es in Hinblick auf die Entwicklungen im Bereich 3D-Digitalisierung für sinnvoll, zumindest einige dreidimensionale Digitalisate anzufertigen und Workflows zu erproben.

Teure Technik – woher nehmen, wenn nicht stehlen?

Der Markt für 3D-Technik ist in den letzten Jahren stark gewachsen und die verschiedenen angebotenen Geräte reichen über kostengünstige 360 Grad Kameras für Social Media-Anwendungen bis hin zu professionellen Großgeräten für mehrere zehntausend Euro. Die Mitarbeitenden musealer Sammlungen sehen sich damit einem unübersichtlichen Angebot verschiedener Ansätze zur dreidimensionalen Abbildung der physischen Welt gegenüber. Um sich intensiv in die dahinterstehende Technik einzuarbeiten und informierte Entscheidungen zu den eigenen Bedarfen zu fassen, reicht oft die Zeit nicht aus. Trotzdem werden die Anforderungen an die Digitalisierungsvorhaben von Museen und Archiven immer höher.

Umso erfreulicher ist es, dass in urbanen Räumen nach und nach Orte entstehen, die den Zugang zu moderner Technik vereinfachen. Diese Orte laufen oft unter englischen Namen, die auf den Mitmach-Charakter verweisen. So gibt es in Dresden einen Makerspace, in Cottbus das CreativeOpenLab (COLab), in Bautzen den Coworking- und Makerspace Tagwerk. Ihr Ziel ist es, Menschen kostenlos oder für wenig Geld zu ermöglichen, Projekte selbst umzusetzen, für die andernfalls teure Geräte angeschafft werden müssten. Von den Trägerinstitutionen wird ein gemeinsam genutzter Maschinenpark aufgebaut. Das fördert Nachhaltigkeit und Skillsharing im Gegensatz zu individuell angeschaffter Technik.

Im Makerspace der SLUB Dresden gibt es mehrere 3D-Scanner, die nach einer digitalen Arbeitsschutzschulung und einer technischen Einweisung vor Ort von den Nutzer:innen der SLUB kostenlos verwendet werden können. Die technische Einweisung vermittelt wichtige Grundkenntnisse zum Thema 3D-Scan und bietet die Möglichkeit, unter Anleitung eigene Objekte zu scannen und am Computer nachzubearbeiten. Für unsere Ostereier wurde uns der 3D-Scanner Artec Spider empfohlen. Dabei handelt es sich um ein handgehaltenes Gerät, das besonders für kleine Objekte geeignet ist und Details sehr gut abbilden kann. In vier Sitzungen konnten ohne weitere Vorkenntnisse 16 3D-Scans von Sorbischen Ostereiern unterschiedlicher Größe angefertigt werden. Dabei wurde der Scanner zusammen mit dem zugehörigen Drehteller genutzt. Das Ei wurde mit einem Ständer mittig auf dem Teller platziert. Beim Start des Scans beginnt dieser Teller automatisch, sich zu drehen und der Scanner muss nur noch gleichmäßig von oben nach unten bewegt werden. Am Computer kann in Echtzeit nachverfolgt werden, welche Bereiche gerade erfasst werden.

Um ein vollständiges Modell zu erhalten, ist es je nach Objekttyp bei dieser Scanmethode notwendig, mindestens zwei Aufnahmen zu machen und das Objekt zwischendurch auf die zuvor nicht sichtbare Seite zu drehen. So können die zwei Aufnahmen am Computer zu einem kompletten Modell zusammengefügt werden. Die Nachbearbeitung am Computer ist damit unbedingt notwendig und ist im Vergleich zum Scan, der nur etwa fünf Minuten benötigt, relativ zeitaufwändig. Für die Ostereiermodelle wurde eine halbe bis etwa eine Stunde Zeit für die Nachbearbeitung pro Ei benötigt. Danach kann das Modell im benötigten Format exportiert und gespeichert werden.

Verarbeitung von 3D-Daten

Wer noch nie zuvor mit 3D-Dateien gearbeitet hat, steht an dieser Stelle vor einer herausforderungsvollen Frage: welches Dateiformat brauche ich überhaupt? Für den Upload bei museum-digital wird ein .zip-Archiv verwendet. Darunter versteht man ein komprimiertes Dateiformat, in dem mehrere Dateien (wie mit einem Reißverschluss, engl. „zipper“) zusammengefasst werden können. Darin muss mindestens eine obj. Datei enthalten sein. Das „Object“-Format ist derzeit eines der Standard-Formate für 3D-Modelle. Meist werden darin nur die 3D Informationen gespeichert, nicht aber die Oberflächenfarbe des Objektes, die sogenannte Textur. Texturen werden dann separat in Form eines Bildes im .jpeg-Format abgespeichert. Um 3D-Datei und Textur zusammenzubringen bedarf es des Mappings, also einem Vorgang, der das zweidimensionale Bild über das dreidimensionale Objekt legt. Man kann sich das vorstellen, als würde man einen Teig in Frischhaltefolie einpacken. Dazu werden allerdings zusätzliche Informationen benötigt, die separat in einer .mtl-Datei (material template library) gespeichert werden.

Damit die Verarbeitung funktioniert, sind in den Dateien Bezüge zueinander eingeschrieben. Verändert man nachträglich die Dateinamen, ist es wichtig, auch die Bezüge in den Dateien zu ändern. Andernfalls laufen die Befehle ins Leere und man wundert sich, warum man auf einen schwarzen Bildschirm schaut, anstatt das 3D-Modell zu sehen. Das Ändern der Bezüge lässt sich einfach im Texteditor erledigen. Sowohl die .mtl- als auch die .obj-Datei lassen sich damit öffnen. Angezeigt werden dann plain text Informationen, die zwar wenig verständlich, aber menschenlesbar sind. Meist gleich zu Beginn werden die Bezugsdateien ausgezeichnet, deren Namen man einfach ändern kann. Wenn alle Bezüge stimmen, kann das .zip-Archiv erstellt werden. Unter Windows funktioniert das einfach per Rechtsklick und „komprimieren in…“. Das Archiv bekommt automatisch den Namen der ersten ausgewählten Datei und sollte unbedingt mit dem Namen der .obj-Datei übereinstimmen.

Veröffentlichung mit museum-digital

Für die Veröffentlichung über museum-digital wird das Objekt wie gewohnt angelegt und mit Basisdaten versehen. Anschließend wird im Reiter „Ansicht“ die Schaltfläche „3D-Objekt“ ausgewählt. Eine Eingabemaske öffnet sich und man erhält die Möglichkeit, eine Datei vom lokalen Speicher auszuwählen. Hierfür sollte das zip-Archiv verwendet werden. Je nach Hardware und Internetverbindung kann es einen Moment dauern, bis der Upload und die Verarbeitung fertiggestellt sind. In jedwedem Fall zeigt sich, wenn man alles richtig gemacht hat, das fertige 3D-Modell vor schwarzem Grund. Es kann in alle Richtungen gedreht und vergrößert werden. So werden es auch die Nutzerinnen und Nutzer von museum-digital sehen. Am linken Seitenrand können außerdem Informationen zum Rechtestatus des Modells eingestellt werden. Ratsam ist auch die Wahl eines geeigneten Vorschaubildes. Der Upload funktioniert ähnlich wie bei herkömmlichen Fotos. Eine einfache Lösung für ein ansprechendes Vorschaubild könnte zum Beispiel ein Screenshot des 3D-Modells im Viewer von museum-digital sein. Fotos des Objektes sind nur dann als Vorschaubild zu empfehlen, wenn sie nicht ohnehin als Ansichten zusätzlich zum Modell zur Verfügung stehen. Ist das hingegen der Fall, kann man das 3D-Modell in der Vorschauansicht nicht deutlich genug von den anderen Fotos unterscheiden, denn es wird dort gemeinsam mit den Fotos angezeigt.

Last but not least: Vernetzen!

Wenn das fertige 3D Modell veröffentlicht ist, darf man gern ein bisschen stolz sein – und es unbedingt auch zeigen! Der 3D-Viewer, den museum-digital kostenfrei und niedrigschwellig zur Verfügung stellt, ist ein großer Gewinn, wenn es darum geht, museale Sammlungen digital verfügbar zu machen. Ermutigen Sie gern auch andere Institutionen, die Technik auszuprobieren und geben Sie Ihre Erfahrungen weiter. Natürlich bleiben auch Probleme bei der Erprobung neuer Workflows nicht aus. Bei Fragen oder technischen Herausforderungen steht Ihnen das Team von museum-digital gern unterstützend zur Seite. Auch die Vernetzung mit anderen Institutionen, die bereits 3D-Modelle veröffentlicht haben, kann helfen, Schwierigkeiten aus dem Weg zu räumen. Damit die Angebote genutzt werden, können Sie Ihre Besucherinnen und Besucher auf Ihre digitalen Angebote aufmerksam machen und zum Stöbern auf Ihren Plattformen einladen.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Digitalisierungsprojekt des Historischen Museums der Pfalz, Speyer

2021-02-27T00:00:00+00:00

In einem langfristigen Projekt werden Gemälde und Zeichnungen aus den Sammlungen des Historischen Museums der Pfalz in Speyer von Künstlern der Region mit Unterstützung des Landes Rheinland-Pfalz digitalisiert und der Öffentlichkeit über „museum-digital“ zur Verfügung gestellt. Worin liegt die Bedeutung dieser Maßnahme?

von Wolfgang Leitmeyer, Abteilungsleiter Sammlungen

**Von der Relevanz alter Zeichnungen** --------------------------------------

27. Februar 2021. Die Pandemie ruft zum Jahresbeginn recht unerwartete Effekte hervor. Geschäfte, Restaurants, Museen, Ämter, Fitnessinstitute und viele andere Orte des öffentlichen Lebens bleiben geschlossen. Zugleich steigt der Absatz von Outdoor-Produkten im Internet… zum Beispiel von Wanderschuhen. Offenbar finden viele Menschen zurück zu den primären Fortbewegungsformen in der Natur. Was bleibt Ihnen auch übrig, die Museen haben schließlich noch immer geschlossen. Während der ersten Sonnentage haben die Seen, Flüsse, Wälder hohe Besuchsfrequenzen. In der Pfalz sind es die Burgen, der Pfälzerwald, die Weinanbaugebiete und die Rheinpromenaden, die zu Besuchen motivieren.

Vor fast genau 200 Jahren, im Mai 1821, wanderte auch der Künstler Friedrich Christian Reinermann von Burg zu Burg in der Pfalz. Er hatte allerdings keine Wahl. Die Überwindung auch großer Strecken zu Fuß war die geläufige Form der Fortbewegung für die ärmeren Schichten der Bevölkerung. Heinrich Jakob Fried, Jakob Wilhelm Roux, aber auch Peter Gayer, der erste Archivar der Pfalz – sie alle reisten in den 20er Jahren des 19. Jahrhunderts zu Fuß und hinterließen Zeichnungen von Orten, die viele von uns in den letzten Tagen vielleicht gerade besucht haben.

[1] Burg und Ort Elmstein (Verbandsgemeinde Lambrecht) im Landkreis Bad Dürkheim

In den letzten 200 Jahren veränderte sich das Gesicht der Städte und Landschaften mehr als jemals zuvor. Fried, Roux, Reinermann und Gayer würden staunen, wenn sie ihre alten Wege nochmals gehen dürften. Umgekehrt fehlt uns heute ein genaues Bild der Welt, bevor es Joseph Nicéphore Niépce 1826 gelang, das allererste Foto aufzunehmen. Wir sind auf die Darstellungen von Künstlern angewiesen, um einen Zugang zu der Welt unserer Ururgroßmütter und Ururgroßväter zu finden. Wenn Sie sich fragen: „Wie hat sich der Ort, wo heute mein Haus steht, wo sich heute unser Marktplatz und vieles andere befindet, in den letzten 200 Jahren verändert?“, so kann Ihnen vielleicht der Blick in eine Datenbank wie „museum-digital“ weiterhelfen. Je mehr bildliche Zeugnisse verfügbar sind, desto mehr Nahrung wird Ihre Phantasie finden und vielleicht auch Ihre Neugierde. **Beispiel Speyer** -------------------

Die Beseitigung der Stadtbefestigung und vieler Ruinen zu Beginn des 19. Jahrhunderts war das Ergebnis eines langen und schmerzhaften Prozesses seit dem großen Stadtbrand von 1689. Die Maßnahmen veränderten das Gesicht der Stadt dauerhaft. Heute sind die Zeichnungen von Peter Gayer (1793–1836) häufig die einzig verfügbaren Quellen zu vielen architektonischen Zeugnissen der Stadt sowie der pfälzischen Geschichte. Darin liegt die Relevanz seiner Veduten für die Stadt, aber auch für die Region.

*\[2\] Die Klosterkirche des Klosters „Zum Heiligen Grab“ in Speyer*

**Peter Gayer und die Zeugen der Vergangenheit** ------------------------------------------------

„Die alten Ruinen haben schon viel zu lange die Zugänge zu dieser Stadt verunstaltet und könnten wegen Steinschlags gefährlich werden. Das Terrain innerhalb dieser Gemäuer ist Lagerstätte für alles, was man sich vorstellen kann, das die Augen beleidigt und mit seinem Geruch die Passanten belästigt. Es erscheint mir, dass der Wert dieser Steine nicht nur für den Abriss, sondern auch für den Wiederaufbau von Häusern ausreicht.“

Quelle: „Verschönerung der Straßen der Stadt durch Entfernen der alten Gemäuer“, Archiv der Stadt Speyer Bestand 2 Nr. 163

In Speyer begann um 1800 eine Zeitenwende: Die Stadt war nun eine Grenzstadt der Französischen Republik, das Arrondissement Spire gehörte zum neuen Département Mont-Tonnère. Die vorangestellten Zeilen des Unterpräfekten Edmond Marie Amable Verny stammen aus einem Memorandum an Georg Friedrich Hetzel vom 26. Juli 1809. Er offenbarte dem neuen Bürgermeister darin seine Gedanken zur Verschönerung der Stadt.

Verny kannte natürlich das Geheimnis der lästigen Gemäuer in Speyer, an welchen sein ästhetisches Empfinden Anstoß nahm: Am Pfingstdienstag, den 31. Mai 1689, abends um 18 Uhr, hatten die verbliebenen Einwohner der Freien Reichsstadt Speyer eine Apokalypse erlebt. Was der Dreißigjährige Krieg nicht vermocht hatte, geschah nun innerhalb von drei Tagen. Am 2. Juni lagen drei Stifte, fünf Klöster, acht Pfarrkirchen, 13 Kapellen, 14 Zunftstuben, 29 städtische Gebäude, 788 Bürgerhäuser sowie fast das gesamte Langhaus des Domes in Schutt und Asche – die Politik der verbrannten Erde hatte eine praktische Anwendung gefunden. Der Anspruch König Ludwigs XIV. auf linksrheinische Reichsterritorien provozierte einen Konflikt, der sich letztlich an den Streitigkeiten um das Erbe des Kurfürsten Karls II. von der Pfalz entzündete. Als Reaktion auf die vorrückenden Kräfte der Großen Wiener Allianz verwüsteten französische Truppen systematisch die Pfalz und angrenzende Gebiete. Zahlreiche Dörfer, Burgen, Festungen, Kirchen, aber auch ganze Städte wie Speyer, Worms, Mannheim und Heidelberg wurden zerstört.

Der Wiederaufbau Speyers vollzog sich schleppend, zumal die Stadt auf französischen Befehl bis zum Friedensschluss von Rijswijk im Jahr 1697 nicht bewohnt werden durfte. Noch siebzig Jahre später war ein Drittel der Stadt zerstört. Steinerne Relikte zeugten von der großen Vergangenheit Speyers, das auch wirtschaftlich am Boden lag. Immerhin erhoben sich im Jahr 1772 wieder 767 Wohngebäude, 32 kleine Häuschen und 124 Hütten, die Arme in den Ruinenstätten errichtet hatten.

[3] St. Peter in Speyer

Der Anblick antiker Ruinen hatte schon mehr als zwei Jahrhunderte zuvor in Italien Humanisten und Künstler fasziniert. Auch in Speyer empfand man angesichts der zerfallenden Gemäuer zuweilen Begeisterung. Meistens waren es durchreisende Künstler und Literaten, die ihrer Freude an den Zeugnissen der Vergangenheit Ausdruck verliehen. In den „Briefen eines reisenden Franzosen über Deutschland“ rühmte Kaspar Risbeck 1783 die außerordentlich schönen Ruinen und die malerische Wirkung der zerstörten Stadt. Als Sophie de La Roche mit ihrer Familie 1780 nach Speyer zog, begeisterte sie ihren empfindsamen literarischen Zirkel für die Stadt. Es entstand der Plan, eine Mappe mit Kupferstichen und einigen Texten herauszugeben – eine Aufgabe, die der Landschaftsmaler und Zeichner Jean Francois Gout übernahm. Weitere Künstler wie Franz Stöber und Johannes Ruland folgen seinem Beispiel.

[4] Retscherruine und Margarethenkapelle in Speyer

Mit dem Ende der französischen Zeit kam ab 1816 die bayerische Administration nach Speyer und mit ihr der Beamte Peter Gayer. Er trat seinen Dienst als zweiter Registrator bei der bayerischen Regierung des Rheinkreises an, seine Aufgabe war die Verwaltung des Schriftguts. Schriftzeugnisse zu bewahren und ihre Auffindbarkeit zu gewährleisten, gehörte zu seinen Kernaufgaben. Diese verantwortungsvolle Tätigkeit qualifizierte ihn bereits im Jahr 1820 zur Übernahme der Leitung des neu entstandenen Kreisarchivs. Das Interesse an der Geschichte lag durchaus im Trend der Zeit. Nachdem Freiherr vom Stein 1819 den ersten Historischen Verein ins Leben gerufen hatte, war es König Ludwig I. von Bayern selbst, der die Spitzen des Staates und der Gesellschaft 1827 zur aktiven Beschäftigung mit der Kultur der Vergangenheit aufrief. Selbstredend war Gayer zwei Mal, 1827 und 1834, Gründungsmitglied des Historischen Vereins der Pfalz. Die Rückbesinnung der Bürger, die sich seit vielen Jahren mit der Beseitigung von Ruinen beschäftigt hatten, auf die große Vergangenheit der Reichs- und Kaiserstadt lag auf der Hand. Die Städte als Spiegelbild bürgerlichen Selbstbewusstseins begannen sich im Verlauf des 19. Jahrhunderts weit mehr zu verändern, als je zuvor. Man benötigte Platz für eine schnell zunehmende Einwohnerschaft, für Manufakturen, später für Fabriken, für Straßen, für eine verbesserte Infrastruktur und für Mobilität. Die Stadtbewohner kultivierten durchaus ein gewisses Interesse an der Vergangenheit, entledigten sich zugleich aber auch der alten Zeugnisse, wenn sie ihren Interessen entgegenstanden, ohne darin einen Konflikt zu sehen. Ein Beispiel dafür mag der Abriss der Ruine von St. Nikolaus nördlich des Domes im Jahr 1825 sein, an deren Stelle im folgenden Jahr die Antikenhalle erbaut wurde, deren einziger Zweck in der Erhaltung und Pflege von Zeugnissen der Vergangenheit – in diesem Fall von römischen Bodenfunden – bestand.

Möglicherweise war der Archivar Gayer nicht erfreut von den radikalen Veränderungen, die sich ringsum in Speyer vollzogen. Immerhin wurden zwischen 1819 und 1826 große Teile der Stadtbefestigung, die Ruinen vieler Kirchen, Klöster und Profanbauten beseitigt. So machte er es sich zur Aufgabe, das verschwindende architektonische Kulturgut der Pfalz in zahlreichen Veduten-Zeichnungen, ganz im Sinne der romantischen Kunst seiner Zeit, zu dokumentieren. Seine favorisierte Technik war die Bleistiftskizze, vor allem aber die Federzeichnung, die er mit Pinsel und Sepia – dem transparenten Farbstoff aus dem Sekret der Tintenfische – übermalte. Gayer interessierte sich nicht nur für Speyerer „Gemäuer“, sondern bereiste auch viele Orte der Region. Systematisch trug er präzise Ansichten von Burgen- und Kirchenruinen der Pfalz zusammen.

[6] St. Amandus Worms

*\[7\] Die Burgruine Neuscharfeneck bei Ramberg, \[8\] Die Burgruine Grävenstein bei Merzalben*

Die figürliche Staffage, die auf kaum einem seiner Werke fehlen durfte, zeigt dabei häufig Menschen aus ärmeren Bevölkerungsschichten. Landarbeiter, Wäscherinnen, Handwerker und viele andere Gestalten bilden ein belebendes Element seiner Darstellungen. Nur wenige Jahre vor der Erfindung der Fotografie wurde er zum aufmerksamen Beobachter und Dokumentar zahlreicher Architekturzeugnissen der Pfalz, die nach und nach verschwanden oder baulich verändert wurden. Eines der Ziele seines kurzen Lebens hat Gayer – er verstarb im Alter von nur 43 Jahren in Speyer – sicherlich erreicht: Seine Zeichnungen bewahren viele architektonische Zeugnisse der pfälzischen Geschichte für die Nachwelt. --- ### **Sepiazeichnungen von Peter Gayer im Bestand des Historischen Museums der Pfalz (Auswahl)**

Burg und Ort Elmstein (Verbandsgemeinde Lambrecht) im Landkreis Bad Dürkheim
Die Klosterkirche des Klosters „Zum Heiligen Grab“ in Speyer
St. Peter in Speyer
Retscherruine und Margarethenkapelle in Speyer
Die Ruinen von Nikolauskapelle und Domstaffelturm in Speyer
St. Amandus in Worms
Die Burgruine Neuscharfeneck bei Ramberg
Die Burgruine Grävenstein bei Merzalben

Fotografen: Peter Haag-Kirchner und die Ehrenamtsgruppe des Historischen Museums der Pfalz. Rechtestatus: CC-BY-NC-ND.

PuQi - Verführung zu Qualität

2021-01-22T00:00:00+00:00

Qualität * Rahmen * Publikation * Ermittlung * Visualisierung * Wirkung * Würdigung

Qualität

„Nachdem fast alle Kulturepochen einzelne Ansätze dazu gesehen haben, kann man es als eine Grundrichtung der modernen Wissenschaft bezeichnen, … dass sie die den Dingen anhängenden Qualitäten als quantitative, also relative Bestimmungen auszudrücken sucht …“¹

Was Georg Simmel bereits um 1900 für die – damals – moderne Wissenschaft postulierte ist heute allgemein: Vergleichendes Messen ist übliche Grundlage für Bewertungen und Entscheidungen des Alltags (nicht nur von Wissenschaftlern).

Eine Auffassung von Qualität als Bestimmtheit einer Sache², ist dabei nicht vollkommen ungebräuchlich geworden. Es lässt sich noch erahnen, was Johann Nepomuk Visino ausdrücken wollte, als er, Feldkaplan in der Armee Ottos I. von Griechenland, den Blutacker in Jerusalem um 1840 beschrieb: „… Man findet hier viele Scherben zerbrochenen Töpfergeschirres, die wohl einem hohen Alterthume angehören mögen, und von vorzüglicher Qualität sind.“³

Im Alltag hat sich ein Verständnis von „Qualität“ durchgesetzt, das sich etwa in der DIN-Norm 55350 findet. Demnach ist Qualität „die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.“⁴

Der PublikationsQualitätsindex (PuQi) für Museumsobjektinformationen, der hier vorgestellt wird ist ein einfaches Messverfahren ganz in diesem zweiten - reduzierten - Sinne, er kann (und will) Qualität nicht allumfänglich ermitteln, sondern nur versuchen „relative Bestimmung auszudrücken“. Welche Museumsobjektinformation ist in Hinsicht auf Online-Publikation⁵ höher zu bewerten als andere? Wie jedes Messverfahren ist auch der PuQi in seinem praktischen Einsatz gebunden an Rahmenbedingungen. Das zugrundeliegende Verfahren dagegen ist verallgemeinerbar. Doch der PuQi ist mehr als nur ein Messverfahren, er ist zugleich ein Ratgeber zur Qualitätssteigerung – der seit einigen Jahren im Einsatz ist und dessen Wirken deshalb beschrieben werden kann. Das folgende schildert also die Rahmenbedingungen, das Messverfahren des PuQi sowie die entfaltete Wirkung. Anlass für die Schilderung ist die Hoffnung auf eine Diskussion der angewandten Kriterien, auf adaptierte Implementationen und generell auf eine Hebung der Qualität von Museumsobjektinformationen im Internet.

Rahmen

Der PuQi ist integrativer Teil der Softwaresuite „museum-digital“. Die dahinter stehende Initiative aus Museen, Museumsverbänden und -ämtern beschreibt museum-digital als „ein Vorhaben, in welchem versucht wird, Wege zu finden und Werkzeuge zu entwickeln, mit denen die Online-Publikation von Objekt-Informationen für alle Museen leicht möglich wird. Es wird ein System entwickelt, … das von allen Museen genutzt werden kann, egal auf welche Weise sie im Museum selbst die Informationen zu ihren Objekten verwalten. … Die Informationen zu Museumsobjekten werden bei museum-digital angereichert und in eine Form gebracht, die eine Einbindung in Portale (europeana, Deutsche Digitale Bibliothek (DDB), …) ermöglicht - sofern es vom betreffenden Museum gewünscht wird.“⁶

(de.about.museum-digital.org, 12.11.2020)

Alle Software-Entwicklung geschieht bei museum-digital auf Anregung und unter Einbezug der beteiligten Museen. Bisweilen entstehen jedoch auch bei den Software-Entwicklern Ideen, die umgesetzt, geprüft und akzeptiert oder verworfen werden – der PuQi gehört in diese Kategorie. Doch der Reihe nach:

Museum-digital wurde im Februar 2009 von der AG Digitalisierung des Museumsverbandes Sachsen-Anhalt ins Leben gerufen. Ursprünglich war es das einzige Ziel Museumsobjektinformationen auf einfachste Weise ins Netz zu bringen. Sehr schnell aber wurde dieses Ziel erweitert um „effektiv“ ins Netz zu bringen, worunter vor allem die Auffindbarkeit, das Ranking in den Katalogen der Suchmaschinen, verstanden wurde – mit wenig Aufwand von Vielen gefunden werden. Es mussten Trefferseiten konzipiert werden, auf deren Gestaltung die beteiligten Museen großen Einfluss nahmen und nehmen. Die Trefferseiten und die Plattform museum-digital wurden seitdem mehrfach überarbeitet.

Häufiger Gegenstand der Diskussion war und ist die Entwicklung von Suchalgorithmen auf den Seiten von museum-digital selbst. Ebenfalls wurde von Anfang an über die Weitergabe an Fachportale einerseits und allgemeine Portale wie die europeana oder die DDB diskutiert. Schließlich war den beteiligten Museen schon mit dem Veröffentlichen der ersten Objekte auf der museum-digital Plattform ersichtlich, dass die Datenanreicherung einen hohen Stellenwert hat, weshalb im Hintergrund eine Normdatenredaktion aktiv ist und Anreicherungen wie auch Übersetzungen kontrollierter Begriffe leistet.

Weil sich zeigte, dass viele Museen keine Inventarisierungssoftware besaßen (oder diese nicht nutzen) wurde schon gegen Ende 2009 begonnen museum-digital zu einer von Museen bestimmten Inventarisierungssoftware weiterzuentwickeln. Im Laufe der letzten Jahre wuchs die Zahl der beteiligten Museen ständig an und es kamen stetig neue Features hinzu. Einen Sprung machte die Software-Entwicklung 2014 als durchgehende Mehrsprachigkeit zum Leitprinzip erhoben wurde. Aktuell wird die Software von ca. 970 Einrichtungen genutzt, die ca. 1,5 Millionen Objektdatensätze damit verwalten von denen ca. 730.000 publiziert sind.⁷

Zu den Grundsätzen von museum-digital gehört es, dass Verfügungsgewalt über Objektinformationen stets bei den Einrichtungen selbst liegt. Es sind die Museen, die bei jedem Objektdatensatz entscheiden, ob sie diesen der Allgemeinheit, ausschließlich Fachwissenschaftlern oder keinem Außenstehenden zugänglich machen.⁸ Es zeigte sich von Anfang an, dass die Maßstäbe für diese Entscheidung sehr unterschiedlich gesetzt wurden. Einigen war es daran gelegen möglichst schnell möglichst viele Objekte ins Netz zu stellen, anderen dagegen ging es darum ausschließlich möglichst korrekte und gründlich recherchierte Information zu veröffentlichen. Dies war der Ausgangspunkt für die Entwicklung des PuQi.

Publikation

Um den Bezugsrahmen zu bestimmen (Simmels „relative Bestimmungen“) wurde als erstes „Publikation“ hinterfragt. Der gerade geschilderte Rahmen zeigt, dass verschiedene Arten von Publikationsmöglichkeiten und -absichten genutzt und angestrebt werden. Fünf Hauptadressaten und -kanäle für publizierte Objektinformationen wurden identifiziert: Jedermann und Fachwissenschaftler im allgemeinen Internet, Nutzer der Plattform museum-digital, Social Media Nutzer, Fachwissenschaftler in Fachportalen und allgemeine Portale. Die anzulegenden Maßstäbe wären jeweils verschieden, etwa die Auffindbarkeit im Netz, die Vernetzung mit anderen Objekten, die Reichweite, die Wissenschaftlichkeit, die Importierbarkeit.

Daraus ergibt sich folgende Tabelle:

Ziel der Publikation	Mögliche Maßstäbe
Allgemeines Internet	Auffindbarkeit (Optimierung für Suchmaschinenalgorithmen) Multilingualität (allgemein) Zufriedenheit der Nutzer
Plattform Museum-digital	Verknüpfung mit anderen Objekten der Plattform Anreicherung mit Normdaten (allgemein) Multilingualität (allgemein) Zufriedenheit der Nutzer
Social Media Kanäle	Reichweite Automatische Weitergabe Verlinkungsmöglichkeiten
Fachportale	Ausreichender Gehalt Wissenschaftliche Fundiertheit Anreicherung mit Normdaten (entsprechend dem Portal) Multilingualität (je nach Portal) Aufsplitterung nach vielen verschiedenen Feldern Weitergabe in Standardformat Lido
Allgemeine Portale	Anreicherung mit Normdaten (entsprechend dem Portal) Multilingualität (je nach Portal) Aufsplitterung nach verschiedenen Feldern Weitergabe in Standardformat Lido

Die Aufschlüsselung zeigt, dass es nahe liegt für jeden dieser Kanäle oder Adressaten der Publikation einen gesonderten Index anzulegen – was sich gut im Internet finden lässt, das lässt sich (in der gleichen Form) möglicherweise nicht gut an Portale weitergeben.

Sie zeigt auch, dass die möglichen Maßstäbe über die Publikationskanäle hinweg ähnlich sind, sich zum Teil wechselseitig bedingen, aber für jeden Kanal von verschiedener Relevanz sind:

Zufriedenheit der Nutzer
Auffindbarkeit (für Suchmaschinenroboter und menschliches Suchverhalten)
Inhaltsreichtum und Korrektheit
Nachnutzbarkeit durch Portale (über Einhaltung von Standards und Anreicherung)

Der Übersichtlichkeit und Verständlichkeit wegen wurde beschlossen auf eine feine Granularität, die einen Index für jeden Kanal ermittelte, zu verzichten und nur einen einzigen Index zu bilden, der die einzelnen Maßstäbe in angemessener Gewichtung - unter Einbezug aller Kanäle - berücksichtigt. Da die Social Media Kanäle automatisch bedient werden und von den Museen über ihre Eingaben kaum beeinflusst werden können wurden sie außen vorgelassen.

Damit war der PuQi grob umrissen: Ein Index für jedes Objekt, der einzelne Maßstäbe in angemessener Gewichtung berücksichtigt – ein Index, der den Eingebenden bei der Entscheidungsfindung (veröffentlichen oder nicht) hilft.

Die Maßstäbe, auch das zeigt die obige Tabelle, waren relativ vage und zum Teil schwer in Messwerte umzusetzen. Manche, wie etwa „Auffindbarkeit“ ließen sich vor einer tatsächlichen Veröffentlichung nur grob antizipieren und wieder andere, wie z.B. „Zufriedenheit der Nutzer“ waren sehr subjektiv und situationsbedingt, doch auch hier ließ sich grob antizipieren. Ob z.B. ein „ausreichender Gehalt“ für die Veröffentlichung in einem Fachportal gegeben ist, das hängt in hohem Maße von den Anforderungen des Fachportals und letztlich auch vom Kenntnisstand zum jeweiligen Objekt ab. Die Frage lautete deshalb: Was konnte überhaupt gemessen werden um festzustellen in welchem Maße ein bestimmter Maßstab erfüllt war oder nicht?

Allen vorhandenen Angaben zu Museumsobjekten lagen verschiedene Absichten zugrunde. Es war klar, dass Angaben, die ausschließlich die Inventarisierung von Museumsobjekten betreffen, selbst aber niemals veröffentlicht werden, unberücksichtigt bleiben müssen. Ebenso sollten Qualitätsvorgaben, die vom Rahmen bestimmt werden unberücksichtigt bleiben. Ein Beispiel sind „Objekttitel“. Das Vorhandensein dieses Merkmals brauchte nicht berücksichtigt zu werden, denn die Software verlangt hier zwingend eine Eingabe um Speichern zu ermöglichen. Eine andere solche Vorgabe der Software ist etwa eine Mindestanzahl von 25 Zeichen in der Objektbeschreibung – ohne, oder mit zu kurzer Objektbeschreibung – lassen sich Objektdatensätze nicht speichern.

Die Suche nach messbaren Größen war dennoch nicht ohne Erfolg. In manchen Fällen war das Vorhandensein feststellbar, in anderen die Häufigkeit, in wieder anderen die Vollständigkeit oder der Umfang. Es wäre also möglich ein Merkmal (etwa: Objektmaße) nach einem angepassten Bewertungsschema (etwa: Vorhandensein) zu beurteilen. Sodann dieses Urteil in Zahlen zu übersetzen (etwa: Vorhanden =0) und in der Wahl der Zahlenwerte die Gewichtung zu berücksichtigen (etwa: Fehlende Maßangaben (1) beeinträchtigen die Möglichkeiten der Nutzer die Umfänglichkeit des beschriebenen Objektes zu ermessen, (2) sind für Auffindbarkeit im Internet weniger wichtig, (3) haben keinen Einfluss auf die Verknüpfung mit anderen Objekten auf der Plattform von museum-digital, (4) werden von Fachportalen und allgemeinen Portalen nicht vorausgesetzt, … Abwägung: Eintrag für den Index -5 für Fehlen, 0 für Vorhandensein).

Selbstverständlich lässt sich auf diese Weise nicht ermitteln ob die eingetragenen Werte korrekt und verständlich sind! Ebenso selbstverständlich ist der Einfluss den ein Merkmal auf den Gesamtindex nimmt eine Größe, die sich nicht absolut, sondern aus der relativen Gewichtung der einzelnen Merkmale zueinander als antizipierte Relevanz für alle beabsichtigten Kanäle der Publikation ergibt. Die Gewichtung einzelner Merkmale selbst wurde in vielen Gesprächen mit Nutzern und Kollegen erarbeitet.

Das gewählte Verfahren ist einfach: Merkmal festlegen, dessen Erfüllungsgrad bestimmen, dem Merkmal eine Relevanz zuweisen, hieraus eine Maßzahl ableiten, diese Maßzahlen addieren und so einen Indexwert erhalten.

Das gesamte Verfahren basiert ausschließlich auf mess- und zählbaren Größen – Korrektheit, Vollständigkeit, Verständlichkeit müssen unberücksichtigt bleiben. Es kann deshalb kein Wert ermittelt werden, der als Mindestmaß gesetzt werden könnte und erlaubte softwaretechnisch eine Veröffentlichung zu verhindern, sollte er nicht erreicht werden.

Doch: Bei der Ermittlung des PuQi werden für verschiedene Merkmale die Erfüllungsgrade ermittelt. Hieraus lassen sich Hinweise ableiten, die den Eingebenden sagen, wo Verbesserungen hinsichtlich der PublikationsQualität möglich erscheinen. Für jedes Objekt wird bei museum-digital ein PuQi-Wert ermittelt, der nach jeder Änderung des Datensatzes neu berechnet wird. Die Wirkung jeder Änderung wird durch den PuQi sofort visualisiert. Dies beeinflusst das Eingabeverhalten und hierin liegt die Wirkung des PuQi selbst. Dazu später mehr. Zunächst soll die Ermittlung des PuQi für die einzelnen Merkmale aufgezeigt werden.

Ermittlung

Als einführendes Beispiel sei die Ermittlung eines Qualitätsfaktors für das Merkmal „Objekttitel“ beschrieben:

Bei einem Objekttitel ist, wie bereits gezeigt, dessen Vorhandensein nicht relevant - Objekte ohne Titel lassen sich in museum-digital nicht speichern. Was sich in diesem Beispiel messen lässt, das ist die Anzahl von Worten im Objekttitel (die meisten Museumsobjekte haben keine festgelegten Titel, weshalb die Titel von den Museen selbst vergeben werden).

Liegt diese Anzahl über einem festgesetzten Wert (aktuell: 10 Worte), dann ist davon auszugehen, dass hier möglicherweise versucht wurde eine Objektbeschreibung als Titel umzusetzen. Die Übersichtlichkeit der Darstellung im Internet leidet - der Nutzer kann sich an den Titel des Objektes nicht sehr gut erinnern. Hierfür wurde ein Bewertungsfaktor von (aktuell) -5 festgesetzt.

Besteht hingegen der Objekttitel aus einem einzigen Begriff (z.B. „Buch“) so erscheint er ohne rechte Aussagekraft für den Nutzer, weshalb er mit einem Bewertungsfaktor von (aktuell) -3 bedacht wird.

Gerade bei Objekttiteln, die als einzelner Begriff eingetragen werden, aber auch darüber hinaus, kann es zu häufigem Gebrauch der gleichen Objekttitel für viele Objekte kommen. Dies senkt die Übersichtlichkeit der Darstellung - nicht unbedingt auf einer Einzelobjektseite - wohl aber auf Trefferseiten, auf denen dann viele Objekte den gleichen Namen tragen. Auch hier kann sich der Nutzer später weniger gut an ein ganz bestimmtes Objekt auf dieser Übersichtsseite erinnern. Die Duplizität von Objekttiteln wird (aktuell) mit einem Bewertungsfaktor von -5 quittiert.

Erwartet werden also 2-9 Worte als Objekttitel, die bestenfalls nicht zugleich für andere Objekte gebraucht werden.

Um im Folgenden eine übersichtliche Darstellung geben zu können lässt sich das Gesagte in ein Schema einpassen:

Merkmal: Objekttitel
Optimum: 2-9 Worte als Zielvorgabe, keine Mehrfachverwendung
Erläuterung: (gerade geschildert)
Messung: Wortanzahl, Duplizität
Bewertung: Zu wenige Worte => -3, Zu viele Worte => -5, Duplizität liegt vor => -5

Merkmal: Objektart
Optimum: 1-2 Worte als Zielvorgabe
Erläuterung: Das Fehlen von Angaben zur Objektart kann nur direkt nach einem Import vorliegen, bei Eingaben ist das Speichern eines Datensatzes ohne Angabe der Objektart unmöglich. Objektart (objectType) wird vom Lido-Datenaustauschformat als Pflichtfeld definiert.⁹ Wer seine Objekt-Informationen an Portale wie die Deutsche Digitale Bibliothek geben möchte, der muss die Informationen in Lido exportieren. Ist das Feld Objektart nicht ausgefüllt, so ist eine Weitergabe (und damit eine erweiterte Publikation) nicht möglich. Es sollte ein allgemeiner Begriff verwendet werden, der die Art zu der das Objekt gehört kennzeichnet. Werden sehr viele Worte eingegeben ist es wahrscheinlich, dass es sich nicht um eine grobe Einordnung handelt, die an dieser Stelle aber sinnvoll ist, weil sie es so den Portalen ermöglicht sogenannte Facetten für dieses Feld zu bilden. Die Worthäufigkeit findet an dieser Stelle aktuell nicht Eingang in den PuQi führt jedoch zu einem Hinweis.
Messung: Vorhandensein, Worthäufigkeit
Bewertung: Feld ist leer => -20, Worthäufigkeit ist größer 2 => Hinweis in PopUp (s.u.)

Merkmal: Objektbeschreibung
Optimum: 901-1750 Zeichen, keine Doppelungen
Erläuterung: Nutzerbefragungen haben gezeigt, dass ein zu sehr kurzer Text häufig viele Fragen offenlässt und ein sehr langer Text ebenfalls schlecht bewertet wird. Aus diesen Befragungen hat sich eine Gruppierung nach Anzahl von Zeichen ergeben, die eine Bewertung nach 6 Güteklassen erlaubt. Gerade die Objektbeschreibungen sind für die Indizierung durch Suchmaschinen-Roboter sehr wichtig, es ist deshalb wichtig eine ausreichende Textmenge zu speichern. Als Optimum wurde eine Textmenge gewählt, die bei weit verbreiteten Einstellungen für Desktop-Computer etwas weniger als einen Bildschirm füllt. Bei gleicher Objektbeschreibung für mehrere Objekte führt dies bei Suchmaschinen zu einem niedrigeren Rang.
Messung: Zeichenanzahl, Duplizität
Bewertung:
Text ist zu kurz (1-50 Zeichen) => -10,
Text ist kurz (51-250 Zeichen) => -5,
Text hat befriedigende Länge (251-900 Zeichen) => +3,
Text hat sehr gute Länge (901-1750) => +6,
Text ist eher zu lang (1721-5000) => 0,
Text ist zu lang (mehr als 5000 Zeichen) => -6;
Duplizität liegt vor => -25

Merkmal: Material/Technik
Optimum: Es gibt eine Angabe
Erläuterung: Die Objekte und mit ihnen ihre Materialien und die zu ihrer Herstellung verwendeten Techniken sind zu verschieden komplex um einen bestimmten allgemeinen Textumfang als Optimum zu definieren. Dennoch: Eine Angabe zu Material und Technik ist wünschenswert und dient dem Nutzer zum Verständnis des Objektes.
Messung: Vorhandensein
Bewertung: Keine Angabe vorhanden => -5

Merkmal: Maßangaben
Optimum: Es gibt eine Angabe
Erläuterung: Bei je nach Anzeigegerät und –modus verschiedenen Skalierungen ist schwer aus dem Betrachten der Abbildungen von Objekten auf die Größe der Objekte zu schließen. Dies macht Maßangaben wichtig für den Nutzer, der nur mit Ihnen die Umfänglichkeit des jeweiligen Objektes ermessen kann. Eine optimale Textmenge zu definieren ist unmöglich, weil die Objektmaße sehr verschieden komplex beschrieben werden müssen oder können.
Messung: Vorhandensein
Bewertung: Keine Angabe vorhanden => -5

Merkmal: Sammlungszuordnung
Optimum: Es gibt mindestens eine Sammlungszuordnung
Erläuterung: Es ist einerseits gut, wenn die Nutzer eine Struktur innerhalb des Objektbestandes des Museums erkennen können – anderseits ist es wichtig Verlinkungen zu in Beziehung stehenden Objekten anbieten zu können, was den Nutzer zu Kontextinformationen führen kann, ihn aber vor allem leicht zu anderen Objekten des Museums dirigiert. Objekte können – bei museum-digital jedenfalls – zu mehreren Sammlungen gehören. Dies wird (aktuell) nicht berücksichtigt (einerseits ergeben mehr Sammlungszuordnungen auch mehr Verlinkungen, andererseits senkt dies die Übersichtlichkeit der Darstellung).
Messung: Vorhandensein
Bewertung: Keine Sammlungszuordnung vorhanden => -10

Merkmal: Objektgruppenzuordnung
Optimum: Es gibt mindestens eine Objektgruppenzuordnung
Erläuterung: Objektgruppen sind bei museum-digital beliebige Gruppierungen von Objekten. Eine Objektgruppe hat stets einen eigenen Titel und eine eigene Beschreibung. Über Objektgruppen (die wie hausinterne-Schlagworte-samt-Beschreibung wirken) ist es effektiv möglich die Nutzer zu inhaltlich in Beziehung stehenden Objekten zu leiten und sie so auf den Seiten der Objekte des Museums zu halten.
Messung: Anzahl
Bewertung: Für jede Objektgruppenzuordnung => +4

Merkmal: Schlagworte
Optimum: 3-9 Schlagworte
Erläuterung: Schlagworte führen zur gezielten Bildung von Übersichtsseiten und lenken zu anderen Objekten des Museums, aber auch zu denen anderer Museen, die in einem inhaltlichen Zusammenhang stehen. Schlagworte verleiten deshalb die Nutzer auf dem jeweiligen Portal zu verweilen und möglicherweise für sie Relevantes zu entdecken. Für die Suchmaschinenroboter und damit das Ranking in den Trefferseiten der Suchmaschinen sind Schlagworte gleichfalls wichtig. Wenige Schlagworte erzeugen wenige Übersichtsseiten. Zu viele Schlagworte lassen die Darstellung unübersichtlich werden. Letztlich kann eine Gruppe gut gewählter – und nicht zu zahlreicher - Schlagworte wie eine zweite Objektbeschreibung wirken.
Messung: Vorhandensein, Anzahl
Bewertung:
Kein Schlagwort vorhanden => -15,
Ein Schlagwort vorhanden => -10;
Zwei Schlagworte vorhanden => -5,
Drei bis neun Schlagworte: für jedes Schlagwort => +3,
Mehr als neun Schlagworte: für jedes Schlagwort => -3

Merkmal: Ereignisse
Optimum: Es gibt wenigstens ein Ereignis pro Objekt
Erläuterung: museum-digital basiert auf Lido, welches objektbezogene Ereignisse in den Vordergrund stellt. Solche Ereignisse bestimmen das Was-Wer-Wann-Wo eines Objektes, also z.B. seine Herstellung, seine Nutzung etc. Ereignisse bieten vielfache Bezüge und Einsprungstellen aus dem Netz wie auch vielfache Verlinkungen zu anderen Objekten innerhalb der jeweiligen Plattform. Die einzelnen Elemente dieser Ereignisse werden von der Normdatenredaktion angereichert und stehen in dieser Form den Suchmaschinenrobotern zur Verfügung, wie auch die Normdatenbezüge in externe Vokabulare (gnd, AAT, geonames, …) und die Mehrsprachigkeit der Begriffsbeschreibungen den Export und die effektive Veröffentlichung auf Portalen (sofern diese solche Features unterstützen) wesentlich steigert. Die Anreicherung der einzelnen Elemente ist nicht abhängig von den Eingaben der Museen, sondern von der Normdatenredaktion, deshalb wird die Reichhaltigkeit derselben nicht berücksichtigt.
Messung: Vorhandensein, Anzahl
Bewertung:
Kein Ereignis angelegt => -15,
Für jedes erfasste Ereignis => 5

Merkmal: Doppelte Entitätenbezüge
Optimum: Es gibt keine doppelten Bezüge zu Orten, Zeiten, Akteuren
Erläuterung: Es kann vorkommen, dass – über ein Ereignis - angegeben ist, das Objekt sei in einem bestimmten Ort hergestellt worden und das gleichzeitig der Ort über einen allgemeinen Bezug (analog zu Schlagwort) mit dem Objekt verknüpft ist. Dies führt zu redundanten Angaben in der Darstellung. Als schlechtes Verhalten (senkt die Übersichtlichkeit für die Nutzer) wird es (aktuell) mit Abzügen bedacht.
Messung: Anzahl
Bewertung: Für jeden doppelten Entitätenbezug => -50

Merkmal: Literaturangaben
Optimum: Es gibt mindestens eine Literaturangabe
Erläuterung: Literaturangaben (hier nur Angaben zu Literatur in analoger Form) reichern die Information für den Nutzer an. Die Umfänglichkeit und Vollständigkeit der Angaben kann nicht berücksichtigt werden, da die Handhabung von Literatureinträgen in Museen jeweils sehr verschieden ist.
Messung: Anzahl
Bewertung: Für jeden Literatureintrag => 2

Merkmal: Externe Verlinkungen
Optimum: Es gibt mindesten einen Hyperlink
Erläuterung: Externe Verlinkungen (einschließlich über das Internet erreichbarer Literatur) sind als Kontexthinweise im Interesse der Nutzer. Sie führen die Nutzer auf externe Seiten. Es ist zudem schwierig ihre Aktualität fortwährend zu überprüfen.
Messung: Anzahl
Bewertung: Für jede externe Verlinkung => 2

Merkmal: Zusatzdokumente
Optimum: Es gibt ein Hintergrunddokument zum Objekt
Erläuterung: Bei museum-digital können die Museen zu jedem Objekt passende Einzeldokumente heraufladen und diese mit den Objekten veröffentlichen. Die Objektdarstellung kann dadurch reicher werden.
Messung: Anzahl
Bewertung: Für jedes Zusatzdokument => 1

Merkmal: Objekt-Objekt-Verweise
Optimum: Es gibt einen Verweis auf ein anderes Objekt des Museums
Erläuterung: Objekt-Objekt-Verweise erscheinen als Verlinkungen, welche den Nutzer gezielt bei den Objekten des Museums halten und so die In-Kontext-Setzung des jeweiligen Objektes steigern.
Messung: Anzahl
Bewertung: Für jeden Objekt-Objekt-Verweis => 3

Merkmal: Ausstellungen
Optimum: Das Objekt ist als Teil einer Ausstellung bei museum-digital erfasst.
Erläuterung: Ist eine Ausstellung und die entsprechende Teilhabe des Objektes bei museum-digital erfasst, so führt ein Klick auf die entsprechende Stelle entweder von der Ausstellung zum Objekt oder umgekehrt und auf diese Weise zum Verweilen auf der Plattform und dem „Entdecken“ weiterer Objekte (derselben Ausstellung). Die jeweiligen Ausstellungsbeschreibungen bieten zumeist Kontext-Informationen zum Ausgangsobjekt.
Messung: Anzahl
Bewertung: Für jeden Ausstellungs-Verweis => 4

Merkmal: Übersetzung
Optimum: Für jedes Objekt liegt wenigstens eine Übersetzung in eine Fremdsprache vor
Erläuterung: Durch die Arbeit der Normdatenredaktion werden Orts, Akteurs und Zeitbegriffe ebenso übersetzt wie Schlagworte. Das Ausgabemodul von museum-digital ist mehrsprachig mit automatischer Sprachwahl beim Aufruf der Seite. Sind auch die Objektangaben übersetzt, so lassen sich Objektseiten die vollständig in einer anderen Sprache oder Schrift gehalten sind erzeugen. Suchmaschinen können die Inhalte auch in anderen Sprachen anbieten.
Messung: Anzahl von Übersetzungen
Bewertung: Für jede Übersetzung => 10

Merkmal: Transkription
Definiertes Optimum: Es gibt eine Transkription
Erläuterung: Transkriptionen lassen sich nicht zu jedem Objekt anbringen sie sind jedoch eine Art - dort, wo es passt - in übersichtlich strukturierter Form Text in fremden Schriften oder als Abschrift in maschinenlesbarer Form anzubieten. Dies können die Suchmaschinenroboter verarbeiten. Nutzer können Transkriptionen per „Copy and Paste“ oder im TEI-Format weiterverwenden. Fachportale können häufig mit Transkriptionen umgehen, allgemeine Portale dagegen selten.
Messung: Anzahl der Transkriptionen
Bewertung: Für jede Transkription => 10

Merkmal: Ist Referenz
Optimum: Es ist ein Werk verzeichnet auf welches das Objekt Bezug nimmt (etwa: Illustration zu Goethes Faust)
Erläuterung: Referenzen, d.h. Bezugnahmen durch das Objekt verweisen auf Kontexte und bieten so im Umkehrschluss jenen, die sich vor allem für die Kontexte interessieren eine Einsprungmarke auf die Plattform (im Beispiel: Jemand sucht in allgemeiner Suchmaschine zum Thema „Goethes Faust“). Referenzen bieten den Suchmaschinen (und damit den Nutzern) hervorragende Möglichkeiten der Kontextualisierung.
Messung: Anzahl von Referenznahmen
Bewertung: Für jede Referenz => 5

Merkmal: Rezeption
Optimum: Es gibt eine Rezeptionsangabe (etwa: Veröffentlicht in …, Besprochen in …)
Erläuterung: Angaben von Rezeptionen sind oft schon vorhanden und in der Sektion Literatur bedacht. Die Möglichkeit Rezeptionen separat und ausführlich zu erfassen wurde erst viel später geschaffen. Auch Rezeptionsangaben verbessern die In-Kontext-Setzung durch die Nutzer. Weil es potentiell unendliche viele Rezeptionen (z.B. zu einem Objekt wie der Nofretete) geben kann, muss hier die Bewertung einer einzelnen Rezeptionsangabe niedrig gehalten werden.
Messung: Anzahl der Rezeptionsangaben
Bewertung: Für jede Rezeptionsangabe => 1

Merkmal: Beschriftung
Optimum: Es gibt einen Eintrag zu einer Beschriftung des Objektes.
Erläuterung: An dieser Stelle werden – gesammelt in einem Feld - Texte erfasst, die auf dem Objekt angebracht sind. Diese Angaben dienen dem Nutzer zum weiteren Verständnis des Objektes.
Messung: Vorhandensein
Bewertung: Für eine Beschriftungsangabe => 3

Merkmal: Markierungen
Optimum: Es gibt zu einem Objekt die Angabe einer Markierung (Künstlersignatur etc.)
Erläuterung: Angaben zur Markierung ergänzen die Angaben zu „Beschriftung“ durch die genaue Angabe wo sich was in welcher Sprache angebracht findet. Sie dienen der weiteren Kontextualisierung der Objekte. Markierungen wurden erst später eingeführt, bis dahin wurden in oberflächlicherer Weise die Angaben (d.h. die Inhalte der Markierung) als Beschriftungen erfasst.
Messung: Anzahl von Angaben zur Markierung
Bewertung: Für jede erfasste Markierungsangabe => 3

Merkmal: Vergleichsobjekte
Optimum: Es gibt einen Hinweis auf Vergleichsobjekte (z.B. in anderen Museen)
Erläuterung: Ist ein Vergleichsobjekt – bestenfalls samt Verweis und URL – angegeben, so erlaubt diese Angabe dem Nutzer das Navigieren zu anderen Objekt (normalerweise in einem anderen Museum) und zu den dort zu findenden Kontextangaben und Beschreibungen. Angaben zu Vergleichsobjekten bereichern das Nutzererlebnis und die Vernetzung von Wissen. Für die Erfassung steht nur ein Feld mit unbegrenzter Länge zur Verfügung.
Messung: Vorhandensein
Bewertung: Für eine Angabe von Vergleichsobjekt(en) => 3

Merkmal: Detaillierte Objektbeschreibung
Optimum: Es gibt eine detaillierte Objektbeschreibung
Erläuterung: Eine die allgemeine Beschreibung eines Objektes ergänzende detaillierte Objektbeschreibung kann in einem separaten Feld erfasst werden. Diese zweite Objektbeschreibung kann privat oder öffentlich sein, sie kann bei museum-digital und/oder im Export weitergegeben werden. Eine solche Objektbeschreibung vergrößert, wenn sie öffentlich ist, den Informationsgehalt der Seite zum jeweiligen Objekt, sie bietet darüber hinaus die Möglichkeit eine besondere Zielgruppe in angepasstem Sprachgebrauch und Diktion zu erreichen.
Messung: Vorhandensein
Bewertung: Für eine detaillierter Objektbeschreibung => 5

Merkmal: Abbildungsanzahl
Optimum: Es gibt mehr als eine Abbildung oder Ressource zum Objekt
Erläuterung: Um veröffentlicht werden zu können muss jedem Objekt bei museum-digital wenigstens eine Abbildung oder digitale Ressource (Audio, Video, Text oder 3D) zugeordnet werden. Weitere zugeordnete Ressourcen erzeugen einen umfassenderen Eindruck vom Objekt. Für die Bewertung nicht-öffentlicher Objekte wird das Vorhandensein geprüft.
Messung: Anzahl, Vorhandensein
Bewertung:
Für jede zugeordnete Ressource => 3,
Für das Fehlen jeglicher Ressource => -5

Merkmal: Abbildungsgröße
Optimum: Abbildungen in bildschirmfüllender Größe oder größer
Erläuterung: Im Laufe der Zeit hat sich die Mindestgröße für heraufzuladende oder einbindbare Abbildungen bei museum-digital stets nach oben verschoben. Dies entspricht den Erwartungen der Nutzer. Die Museen waren zunächst sehr zögerlich größere Abbildungen ins Netz zu stellen. Wenige Museen waren hingegen von Anfang an bereit große Abbildungen zu veröffentlichen. Es ist eine Abwägungssache: Manche Objekte, wie beispielsweise historische Landkarten, verlangen zur vollständigen Erkennbarkeit nach großer Abbildung. Andererseits bedeuten sehr große Abbildungen auch ein erhöhtes Datentransfervolumen, nicht jeder, der mit einem Smartphone bei mittelmäßiger Verbindung eine Objektabbildung aufruft möchte warten bis 50 oder mehr Megabyte heruntergeladen sind.
Messung: Pixelanzahl kurze Seite
Bewertung:
Kurze Seite weniger als 600 Pixel => -5,
Kurze Seite 600-800 Pixel => -2,
Kurze Seite größer als 1280 Pixel => +1

Merkmal: Ressourcen und Rechte
Optimum: Offene Lizenzen und Angaben der Rechteinhaberschaft
Erläuterung: Der Rechtestatus einer Abbildung entscheidet über die Nachnutzbarbeit durch die Nutzer. Eine möglichst geringe Einschränkung ist angestrebt, dennoch gibt es viele Museen, die an dieser Stelle zurückhaltend sind und die Abbildungen als etwas betrachten, über das Sie selbst die Kontrolle behalten möchten. Die Weiternutzungsmöglichkeiten sind in Gruppen zusammengefasst:
(1) Weitgehend offene Lizenzen (CC0, Public Domain Mark, Orphan Work),
(2) offene Lizenz mit Namensnennung (CC BY) und
(3) weitgehend restriktive Lizenzen (RR-F, RR-P, RR-R)
Messung: Vorhandensein, Offenheit
Bewertung:
Für das Fehlen von Rechteangaben zu mindestens einer Ressource: -15
Für jede Ressource mit offener Lizenz => 2 pro Ressource,
Für jede Ressource mit offene Lizenz mit Namensnennung => 1,
Für jede Ressource mit restriktiver Lizenz => -1

Bewertungsbeispiel: Gibt es etwa für das Vorhandensein einer einzelnen Ressource (Merkmal: Abbildungsanzahl) 3 Punkte, so reduziert sich dieser Wert um einen Punkt, wenn eine restriktive Lizenz gewählt wurde. Der Eintrag der Ressource zum PuQi des Objektes beträgt +2 Punkte. Fehlen in diesem Beispiel Lizenzangaben und Nennung der Inhaberschaft zur Ressource so werden generell 15 Punkte abgezogen und es ergibt sich eine Kennzahl von -12 Punkte (+3 für Ressource vorhanden, -15 für das Fehlen von Rechteangaben).

Wird eine zweite Ressource in gleicher Weise diesem Objekt zugeordnet, so ergibt sich 2 x 3 = 6 Punkte für das Vorhandensein, 2 x -1 Punkte = -2 Punkte für die restriktive Lizenz, also eine Kennzahl von 6 – 2 = +4 Punkte. Wenn in diesem Beispiel Lizenz- und Inhaberangaben auch nur für eine Abbildung fehlen, so werden -15 Punkte angerechnet, was die +6 Punkte für das Vorhandensein der beiden Abbildungen nicht auszugleichen vermag. Insgesamt ergibt sich in diesem Fall eine Kennzahl von -9 Punkten als Eintrag der Ressourcen zum PuQi des Objektes. Erst mit dem Vorhandensein von 5 Ressourcen (5 x 3 Punkte = 15 Punkte) ist es theoretisch möglich das Fehlen von Lizenz- und Inhaberangaben auszugleichen.

Ein Fehlen von Rechteangaben wird aber, wie bereits angedeutet im Normalfall vom System unterbunden, in jedem Fall wird vor einer Veröffentlichung jedes Objektes geprüft und diese bei fehlenden Rechteangaben verhindert. Ebenso ist eine Veröffentlichung beim Fehlen jeglicher Ressourcen nicht möglich. Beide Fälle, das Fehlen jeglicher Ressourcen oder das Fehlen von Rechteangaben sind nur im internen Bereich von museum-digital relevant.

Merkmal: Metadaten und Rechte
Optimum: Offene Lizenzen und Angaben der Rechteinhaberschaft
Erläuterung: Analog zur Betrachtung bei Ressourcen gilt auch hier, dass der Rechtestatus der Metadaten über die Nachnutzbarbeit derselben entscheidet. Eine möglichst geringe Einschränkung ist angestrebt. Museum-digital erlaubt eine Veröffentlichung der Objektangaben ohne explizite Angabe von Metadatenrechten – in diesem Falle gilt die Lizenz CC BY-NC-SA und die jeweilige objektbesitzende Institution als Inhaber. Wie bei „Ressourcen und Rechte“ werden auch hier die Weiternutzungsmöglichkeiten in Gruppen zusammengefasst:
(1) Weitgehend offene Lizenzen (CC0, Public Domain Mark, Orphan Work),
(2) offene Lizenz mit Namensnennung (CC BY) und
(3) weitgehend restriktive Lizenzen (RR-F, RR-P, RR-R)
Messung: Vorhandensein, Offenheit
Bewertung:
Für das Fehlen von Angaben zur Metadatenlizenz = -15,
Für eine offene Metadatenlizenz => 2,
Für eine offene Lizenz mit Namensnennung => 1,
Für eine restriktive Lizenz => -1

Abwägung

Jene Merkmale, die bei museum-digital als so grundlegend definiert wurden, dass es unmöglich ist, einen Datensatz zu speichern, wenn sie nicht angegeben werden, sind in die Berechnung des PuQi kaum einbezogen. Es ist beispielsweise unmöglich einen Objektdatensatz ohne Angabe einer Inventarnummer zu speichern, ein – durch einen Import möglicher - leerer Eintrag für Objektart muss vor dem Speichern ausgefüllt werden, ebenso muss eine Mindesttextlänge von 25 Zeichen für die Objektbeschreibung gewahrt sein, um den Datensatz speichern zu können, wie auch das Feld Objekttitel zwingend ausgefüllt werden muss. Diese vier grundlegenden Merkmale korrespondieren im Wesentlichen zu den Pflichtfeldern des Lido-Austauschformats zur Weitergabe an Portale.¹⁰ Ein Mindestmaß an Publikationsqualität, wozu ja auch die Weitergabe an Portale zur Re-Publikation gerechnet werden muss, ist auf diese Weise schon von der Software vorgegeben.

Einige Merkmale sind spezifisch für museum-digital, weil entsprechende Felder vorhanden sind, etwa die Merkmale „Transkription“, „Ist Rezeption“, „Markierung“ oder „Übersetzung“. Weil diese Merkmale aber durchaus die prinzipiellen Möglichkeiten effektiven Publizierens mitbestimmen werden sie hier einbezogen.

Auch wenn die Relevanz einzelner Merkmale von den Möglichkeiten der jeweiligen Software abhängig ist, so zielt der PuQi – in der Form, wie er hier umgesetzt ist – doch auf eine Abwägung allgemeinerer Art. Für die nicht mehrsprachige Deutsche Digitale Bibliothek etwa bedeutet es keinen Gewinn, wenn eine Objektbeschreibung übersetzt ist, für ein mehrsprachig arbeitendes Portal hingegen kann es von Bedeutung sein – für die Suchmaschinen-Optimierung ist es in jedem Fall ein bedeutendes Merkmal. Der PuQi hat nicht das Ziel die Effizienz einer Veröffentlichung bei museum-digital allein zu bewerten. Im Fokus steht vielmehr eine allgemeinere Effizienz, die auch die Suchmaschinen-Optimierung, die Weitergabe an Portale und die Zufriedenheit der Nutzer und deren Möglichkeiten eigener In-Kontext-Setzungen berücksichtigt.

Was der PuQi mit dem hier gewählten Verfahren nicht berücksichtigt, das ist die Tatsache, dass sich bestimmte Arten von Objekten per se besser für eine Publikation im Netz gut eignen, andere Arten weniger gut. Handelt es sich bei einem Objekt etwa um den Fußknochen eines Dinosauriers, so fällt es schwer mit Einträgen zu „Transkription“ zu Punkten – anders bei einem Papyrus oder Ostrakon. Handelt es sich um ein gut erschlossenes Fotoalbum, so liegt unter Umständen viel Information zu mehreren Herstellungsereignissen (der einzelnen Fotografien) vor – anders bei einem bronzezeitlichen Spinnwirtel. An dieser Stelle muss weitergedacht werden …

Jedes neu von der Software ermöglichte Merkmal muss überprüft werden, ob – und wie - es in den PuQi einbezogen werden soll. Bewertung und Gewichtung der Merkmale müssen von Zeit zu Zeit überprüft werden, etwa wenn es neue Kanäle gibt, oder bestimmte Kanäle häufiger bedient werden sollen als andere. Was sich aber gleichbleibt und was verallgemeinerbar ist, sich also auch in andere Software implementieren ließe, das ist das Verfahren des Bestimmens-Bewertens-Gewichtens selbst (auch wenn dort möglicherweise andere Kriterien mit anderen Bewertungen und Gewichtungen zum Zuge kommen).

Visualisierung

Der PuQi liefert auf die geschilderte Weise eine Punktezahl. Aus der abstrakten Zahl allein lässt sich wenig ableiten. Diese Zahl lässt sich aber in Relation zu einem (hypothetischen) Optimum setzen. Dieses hypothetische Gesamt-Optimum ergibt sich aus der Addition aller Punktzahlen für die Erfüllung des Optimums eines jeden Merkmals. Der PuQi Wert eines einzelnen Objektdatensatzes kann dann mehr oder weniger weit unter- oder oberhalb des Gesamt-Optimums liegen. Durch die Visualisierung der jeweiligen Distanz wird der PuQi für den Eingebenden oder Bearbeitenden nutzbar.

Bei museum-digital ist dies in folgender Weise umgesetzt: In großer Nähe zum Schalter für das Veröffentlichen (oder Verstecken) von Objekten erscheint in der Objekt-Bearbeitungsansicht stets ein farblich kodierter Balken von verschiedener Länge und Farbe. Ist der PuQi-Wert niedrig, so ist der Balken kurz und rot, ist der PuQi-Wert höher, so erscheint der Balken in einer mittleren Länge und blauen Färbung, ist hingegen der PuQi-Wert hoch, so bekommt der Balken eine große Breite bei grüner Farbgebung. Während die Balkenlänge den tatsächlichen Abstand zum Optimum berücksichtigt und sich mit jeder Änderung am Datensatz verlängert oder verkürzt, verändert sich die Farbkodierung in Blöcken:

0-50% des Optimums: rot,
51-80% des Optimums: blau,
Mehr als 80% des Optimums: grün.

Die Position des PuQi wurde mit Bedacht gewählt. Wer ein Objekt freischalten will, und seinen Blick auf den entsprechenden Schalter richtet, wird dabei auch den PuQi-Balken sehen. Die Farbkodierung soll einerseits ein schnelles Erkennen ermöglichen, andererseits aber einer Gewöhnung entgegenwirken. Der Balken soll „ins Auge springen“ ohne Aufdringlich zu sein.

Fährt der Museumsmitarbeiter mit dem Mauszeiger über den PuQi-Balken – was fast unweigerlich passiert, wenn sich der Mauszeiger in Richtung „Freischalten“ bewegt - so öffnet sich ein Pop-Up-Fenster in der Bildschirmmitte. Dieses Fenster enthält konkrete Hinweise in drei Rubriken:

„Allgemeines …“ (Rubrikentitel in blauer Farbe)
„Könnte eventuell verbessert werden …“ (Rubrikentitel in roter Schrift)
„Gut so …“ (Rubrikentitel in grüner Schrift)

Schon die Formulierungen der Rubrikentitel zeigen, dass hier eine Diktion gewählt wurde, die alle harsche Kritik vermeidet. In seinen Meldungen setzt der PuQi auf Anregung und Inspiration statt auf Beschimpfung und Verteufelung – dennoch gibt es ab und an auch Ausrufezeichen.

Die einzelnen Meldungen können, das wurde oben schon erwähnt, gegeben werden, weil zu jedem Merkmal der Grad der Entsprechung ermittelt wird - es ist deshalb möglich für jedes einzelne der zum PuQi beitragenden Merkmale eine Aussage zu treffen.

In die Rubrik „Allgemeines …“ fallen Merkmale, wenn ihr Grad der Entsprechung weder als wirklich gut noch als wirklich hinderlich für eine erfolgreiche Publikation eingeordnet wird. Hier finden sich zum Beispiel Aussagen wie „2645 Zeichen in der Objektbeschreibung. Das ist eher zu lang“ - der PuQi kann auch als Zeichenzähler dienen. Ein anderer möglicher Eintrag: „3 Begriffe im Feld ‚Objektart‘ – ist das wirklich so gemeint? (Ideal: Ein Begriff)“.

In die Rubrik „Gut so …“ fallen Merkmale bei denen das definierte Optimum erreicht oder übertroffen wurde. Eine Beispielaussage lautet: „3 Schlagworte/Bezüge eingegeben (Ideal: 3-9)“. Der PuQi legt mit dieser Formulierung nahe, dass man hier leicht etwas verbessern könnte. Bisweilen erfolgt aber auch einfach ein Lob: „1399 Zeichen in der Objektbeschreibung. Das ist sehr gut!“ Andere Beispiele aus der Rubrik, lauten „Dem Objekt wurde mindestens ein Ereignis zugeordnet“, „Dem Objekt wurde Literatur zugeordnet“ oder „Dem Objekt wurden mehrere Bilder zugeordnet“

In der Rubrik „Könnte eventuell verbessert werden …“ werden Merkmale genannt, die tatsächlich geändert werden sollten, etwa „Objektname besteht aus mehr als 10 Worten. Objektbeschreibung hat eigenes Feld!“ – das ist schon sehr deutlich. Ein anderes Beispiel: „136 Zeichen in der Objektbeschreibung. Das ist recht kurz!“, ein weiteres: „Es wurde nur ein Schlagwort/Bezug eingegeben (Ideal: 3-9)“ und ein abschließendes: „Feld ‚Maße‘ ist leer. Besser, wenn ein Hinweis dort steht“.

(Der PuQi in seinem Habitat - Beispiel)

Diese Beispiele mögen die Diktion der Meldungen des PuQi veranschaulichen, die dem Charakter eines Hinweis- und Ratschlaggebers entspricht: Ein freundlicher Helfer und Anreger. (Tatsächlich wurde schon bei der Erstellung des PuQi darauf geachtet, dass bei üblichem Eingabeverhalten sehr leicht ein Eintrag in der Rubrik „Gut so …“ erscheint.)

Wirkung

Der PuQi ist für den Eingebenden (oder Bearbeiter) eines Objektdatensatzes keine bloße Zahl, er ist ein farbiger Balken in einem Rahmen und zugleich ein PopUp-Fenster mit Hinweisen an die sich niemand halten muss, aber kann. Er gibt mehr Lob als Kritik. Erst in einer solchen Form konnte er seine Wirkung entfalten.

Als, vor nunmehr etlichen Jahren, die Entwickler der AG Digitalisierung im Museumsverband Sachsen-Anhalt – dem „Brain-Trust“ hinter museum-digital – zuerst die Idee einer Qualitätsbewertung in Hinsicht auf Publikation vorschlugen, überwog die Skepsis. Es herrschte Unbehagen darüber vor, dass Andere den Finger heben und Kritik an den Eingaben der Kollegen äußern könnten. Nichtsdestotrotz ließ man die Entwickler zunächst gewähren.

Alle Vergleiche zwischen den PuQi-Werten der Objekte eines Museums oder auch denen der Objekte mehrerer Museen geschehen ausschließlich über die Gesamtpunktzahl, den PuQi-Index selbst. Vergleiche auf Merkmalsebene finden nicht statt. An dieser Stelle wurde der Skepsis Rechnung getragen. Die anfängliche Skepsis hat auch bei der Wahl der Diktion eine große Rolle gespielt.

Bereits das erste Modell des PuQi, das in seiner Granularität noch wesentlich eingeschränkter war, wurde dann aber von den Kollegen der AG Digitalisierung akzeptiert. Man konnte, aber man musste sich ja nicht daran halten.

Es zeigte sich jedoch schon nach kurzer Zeit, dass die Kollegen der AG ebenso wie sehr viele andere Nutzer von museum-digital bei Neueingaben versuchten den PuQi-Balken stets in den grünen Bereich und bestenfalls auf volle Länge zu bringen. Einige KollegInnen begannen gar damit ihre früheren Objekteingaben mit dem PuQi zu überprüfen und entlang seiner Ratschläge zu verbessern - dies hat die Entwickler veranlasst zu ermöglichen, dass jedes Museum sich seine Objekte in der Sortierung nach PuQi-Werten aufruft. Jetzt ist es möglich die Objekte mit den geringsten PuQi-Werten leicht zu ermitteln und die Einträge zu verbessern.

Der Wunsch, stets einen grünen Balken und ausschließlich Hinweise in der Rubrik „Gut so …“ zu erhalten, war bei einigen KollegInnen so groß, dass Sie versuchten „zu tricksen“ indem sie beispielsweise Herstellungsorte, die schon durch ein Herstellungsereignis mit dem Objekt verknüpft waren, erneut über einen allgemeinen Ortsbezug (wie Schlagwort) verknüpften. Um solchen „Tricks“ vorzubeugen wurden entsprechende „Strafpunkte“ eingeführt (s.o.). Nach kurzer Zeit waren solche Versuche nicht mehr festzustellen.

Die Neueingaben der Kollegen orientierten sich zunehmend am PuQi und wurden damit inhalts- und facettenreicher. Was ursprünglich nicht intendiert war, von den KollegInnen aber schnell erkannt wurde: Der PuQi lässt sich auch als Pfad oder Wegleiter einsetzen. Zuerst werden die nötigen Pflichtfelder (ohne die ein Speichern ja nicht möglich ist) ausgefüllt, dann wird der PuQi geprüft um zu sehen, was noch fehlt. Die Hinweise werden dann der Reihe nach abgearbeitet.

Dieses Verfahren hat sich als effektiv erwiesen. Es wird jetzt auch in Schulungen zum Umgang mit der Software empfohlen und erleichtert neu hinzukommenden Kollegen einerseits den Umgang mit der Software und andererseits das Erstellen publikationswürdiger Datensätze.

Würdigung

Auf der Startseite von www.museum-digital.de werden aktuell Voransichten zu 40 Objekten angezeigt. Dies ist die „Hall-of-fame“ der PuQi-Einträge. Etliche Museen sind sichtlich bemüht durch hohe PuQi-Werte mit ihren Objekten dort zu erscheinen und die erste Position einzunehmen. Der PuQi ist für viele der Nutzer von museum-digital zu einem festen Teil ihres Eingebens und Bearbeitens geworden. Die Qualität der Einträge ist – über alle Einträge hinweg gesehen - wesentlich gestiegen und seit der Einführung des PuQi gleichbleibend hoch. Es gibt mehr Literatureinträge, mehr Text in den Objektbeschreibungen, mehr Querverweise zu anderen Objekten, mehr Abbildungen pro Objekt – um nur ein paar Beispiele zu nennen

Anders, als zum Beispiel bei der europeana, wo ein „Tier“-System für Abbildungen und Metadaten eingeführt wurde, mit dem vor allem die Nachnutzbarkeit durch die Kreativwirtschaft beurteilt wird, ist der PuQi ein Versuch gleich mehrere Publikationskanäle und Publikationsabsichten zu berücksichtigen. Er ist zudem viel granularer als das System der europeana, was ihm erlaubt konkrete Hinweise zu geben.

Der PuQi liefert einen Zahlenwert, der nur bedingt absolute Aussagen über die tatsächliche Qualität in Hinsicht auf die Publikation von Museumsobjektinformationen erlaubt. Vieles ist Annahme oder lässt sich ohnehin nur grob erahnen, Nutzerzufriedenheit zum Beispiel - kein absoluter Wert zwar aber doch transparent in seiner Ermittlung. Der Index basiert auf Quantifizierungen der Nähe zu einem definierten Optimum eines Merkmals. Dieses Optimum ist zumeist über Befragung und Betrachtung definiert worden. Bei neuen Entwicklungen werden die Optima und die Merkmale angepasst um die Gewichtungen im Lot zu halten. Der Indexwert kommt als „harte“ Zahl daher, beruht aber auf vielen „weichen“ Faktoren. Qualität ist letztlich immer eine „relative Bestimmung“.

Der PuQi zeigt, dass sich Quantität und Qualität ergänzen können. Er ist ein Beispiel dafür, wie mit quantitativen Methoden Qualität erzeugt werden kann.

Simmel, Georg: Philosophie des Geldes. Leipzig, 1900, S. 60. In: Deutsches Textarchiv <http://www.deutschestextarchiv.de/simmel_geld_1900/84>, abgerufen am 08.11.2020.

„Das Seyn wird sich darin in den drey Bestimmungen setzen 1) als Bestimmtheit, als solche; Qualität; 2) als aufgehobene Bestimmtheit; Größe, Quantität; 3) als qualitativ bestimmte Quantität; Maaß“, Georg Wilhelm Friedrich Hegel, “Wissenschaft der Logik“, 1812, Seite 19

Johann Nepomuk Visino. Meine Wanderung nach Palästina. In Briefen an einen Geistlichen der Diozese Passau, Passau 1840, S. 392

⁴

Sinngemäß und kürzer in der aktuellen Version als DIN EN ISO 9000:2015 „Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“ (zitiert nach https://diq-zert.de/zertifizierungsstelle/qualitaet/was-ist-qualitaet/, 08.11.2020), die Norm DIN 55350 wird zur Zeit überarbeitet, vgl. Meldung der Deutschen Gesellschaft für Qualität vom 17. August 2020 „Aktualisierter Normentwurf E DIN 55350 erschienen“ (https://www.dgq.de/aktuelles/news/aktualisierter-normentwurf-e-din-55350-erschienen/, 08.11.2020)

⁵

Hier, wie im Folgenden ist ausschließlich die Publikation im Internet gemeint. Eine allumfassende Publikationsqualität, die auch analoge Medien einbezieht, zu ermitteln war nicht Absicht bei der Erstellung des PuQi.

⁶

https://www.museum-digital.de/, 08.11.2020

⁷

Jeweils aktuelle Zahlen zu den bei museum-digital publizierten Museen, Sammlungen und Objekte unter https://global.museum-digital.org/

⁸

Museum-digital ermöglicht einen vom jeweiligen Museum kontrollierten Zugang für „Visiting Scientist“. Auch dies ist genau genommen eine Möglichkeit der – sehr gezielten – Publikation im Internet. Diese Möglichkeit wurde in der Entwicklung des PuQi nicht gesondert berücksichtigt.

⁹

http://www.lido-schema.org/schema/v1.0/lido-v1.0-specification.pdf (12.11.2020)

¹⁰

Objektbeschreibungen sind in der Definition des Lido-Austauschformates (s.o.) keine Pflichtangaben.

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

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.

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

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.

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.

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.

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.

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.

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.

Falamos Português - Bahasa Indonesia

2015-09-24T00:00:00+00:00

Die brasilianischen Kollegen haben jetzt museum-digital vollständig ins Portugiesische übersetzt. Sowohl die öffentliche Anzeige als auch das Modul für die Erfassung und Bearbeitung von Informationen sind jetzt um eine Sprachversion reicher. Webseitenbesucher mit Browser-Einstellung “Portugiesisch” bekommen automatisch alle Seiten von museum-digital auf Portugiesisch zu sehen - alle anderen können jeweils oben rechts den Sprachwahlschalter anklicken. Übersetzt angezeigt werden natürlich nur Begriffe, die sagen, worum es geht. Informationen wie Bezeichnungen von Objekten oder Beschreibungen von Objekten werden nur dann übersetzt angezeigt, wenn Sie tatsächlich auch in Portugiesisch vorliegen.

Vollständig überarbeitet wurde auch die indonesische Version von museum-digital. Die öffentlichen Anzeigeseiten wurden neu übersetzt und es wurde nun erstmals auch das Modul für die Erfassung und Bearbeitung von Einträgen in allen Teilen ins Indonesische übersetzt.

LIDO I

2012-10-27T00:00:00+00:00

Eine kleine technische Weiterentwicklung macht es möglich: Ab sofort kann jedes Museum bei museum-digital seine Objektinformationen jederzeit im internationalen LIDO-Standard-Austauschformat exportieren. Dies ermöglicht die direkte Teilnahme an Portalen und Portalprojekten aller Art. Auf der anderen Seite wurde der automatische Import von Objektinformationen wesentlich verbessert. Es ist also möglich,

die im Museum vorhandenen Informationen automatisch in museum-digital hinein zu importieren,
sie dort automatisch anreichern zu lassen (mit z.B. Geo-Koordinaten für Orte und Personen-Nummern in der GND (früher PND)),
die Informationen - wenn nötig - publikationsgerecht zu überarbeiten und
sie schließlich an Portale weiterzugeben.

Natürlich kann jedes Museum auch weiterhin die bei museum-digital gespeicherten Objektinformationen in die eigene Webseite einbinden.

(LIDO steht für “Lightweight Information Describing Objects”, mehr dazu (in Englisch) unter www.lido-schema.org)

museum-digital goes QR

2011-07-02T00:00:00+00:00

Zu den einzelnen Objektansichten wird ab sofort bei museum-digital der entsprechende QR-Code (die Adresse der jeweiligen Internetseite) angezeigt. Wer auf seinem Handy ein entsprechendes App installiert (falls nicht vorinstalliert: Das gibt es meistens kostenslos, z.B. für Android-Handys den Barcode Scanner von ZXing Team oder Beetagg …), der kann damit den QR-Code vom Bildschirm abfotografieren und die Adresse der jeweiligen Webseite per SMS oder Mail weiterschicken. Gleichzeitig wurde für alle beteiligten Museen die Möglichkeit geschaffen sich zu den eigenen Objekten einen passenden QR-Code (in fast beliebiger Größe) auszudrucken und diesen im Museum neben den Objekten zu plazieren. Museumsbesucher können dann einfach den ausgedruckten Code, wie oben beschrieben, einscannen und sich die Objektinformationen von museum-digital auf das Handy holen. Ob das Angebot genutzt werden wird muss sich natürlich erst zeigen. Es gibt bereits etliche Museen, die QR-Codes in der (hausinternen) Objektpräsentation nutzen. Einen ausführlichen Bericht über Erfahrungen in der Anwendung gibt es vom Powerhouse-Museum in Sydney (hier). Nur zwei Beispiele für weitere Einsatzmöglichkeiten: Das British Museum setzt die Codes in der Museumspädagogik ein (hier) und das National Museum of Scotland hat Objekte einer Ausstellung mit vielen weiterführenden Informationen angereichert, die über QR-Codes abrufbar sind (hier).

Verbesserte Anzeigekontrolle

2009-07-10T00:00:00+00:00

Seit heute ist die Kontrolle der Anzeige von Objektangaben bei museum-digital:sachsen-anhalt wesentlich leichter zu handhaben. Quasi per Mausklick lassen sich jetzt einzelne Objekte aus der Anzeige herausnehmen. Nötig wurde dies, weil doch immer wieder Informationen gefunden werden, die es ratsam erscheinen lassen eine erneute Prüfung der Rechtefragen durchzuführen. Das entsprechende Objekt kann jetzt während einer solchen Prüfung zeitweilig ausgeblendet werden. Das wurde sogleich umgesetzt - die Zahl der angezeigten Objekte sank (einige Rechte sollen erst geprüft werden).