museum-digital:blog - Neue Features

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.

Ein kleines Tool zur Konkordanzprüfung bei Importen

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

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

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

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

Ein kleines neues Tool

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

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

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

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

info

License

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

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

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

musdb

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

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

Frontend

Neue Implementation von getrennten Maßangaben ist auch hier umgesetzt

Import

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

nodac

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

info

AI Use

Post image generated using AI.

tip

tip

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

Versionierung & Transfer zwischen Datenfeldern

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

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

Versionierung

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

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

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

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

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

“Feldweise transferieren”

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

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

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

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

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

tip

tip

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

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.

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

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

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

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

Die Dokumentation kann hier abgerufen werden:

md:term
frontend (via the global portal)

info

License

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

Vereinfachter Workflow für die Arbeit mit Leihobjekten mit EODEM

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

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

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

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

EODEM-Daten exportieren

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

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

Einfach importieren?

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

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

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

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

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

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

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

Ein Blick in die Zukunft

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

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

info

License

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

Ein Kalender heißt feste Termine

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

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

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

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

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

info

License

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

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

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.

Standorte und mehr - Objektdaten per QR-Code updaten

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

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

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

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

Standorte per QR-Code eintragen, in musdb

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

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

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

Umsetzung

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

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

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

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

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

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

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

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

Danksagung

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

info

License

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

IIIF und museum-digital

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

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

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

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

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

Einschränkungen der IIIF-Umsetzung bei museum-digital

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

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

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

IIIF Collections

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

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

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

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

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

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

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

info

License

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

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.

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.

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.

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.

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.

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

Inhalte aus museum-digital über externe Repositorien finden

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

Heute gibt es im Blog einmal wieder eine rein technische Neuerung zu berichten. Mit dem seit heute öffentlich verfügbaren Resolver können Inhalte einer Instanz von museum-digital leichter mit anderen Repositorien integriert und verknüpft werden.

Getting Started

Zum Benutzen der neuen Funktion muss an die URL der Startseite nur “/resolver” angehängt werden. Der Einfachheit halber folgen Beispiele aus der deutschlandweiten Instanz von museum-digital. Hier kann der Resolver also unter https://nat.museum-digital.de/resolver/ aufgerufen werden.

Unter dieser URL findet sich eine kurze Anleitung für die Benutzung.

Listen der verknüpften Repositorien aufrufen

An die gebene Basis-URL kann nun der gewünschte Daten-Typ angehängt werden. Verfügbar sind derzeit Institutionen (institution), Objekte (object), Akteure (actor), Orte (place) und Schlagworte (tag). Durch Anhängen des entsprechenden Typs kann eine Liste von passenden, verlinkten Repositorien aufgerufen werden.

Für Orte sind derzeit etwa Verknüpfungen zu und über die folgenden Repositorien verfügbar:

geonames
gnd
nomisma
pleiades
Website
wikidata

Diese Liste kann unter https://nat.museum-digital.de/resolver/place gefunden werden.

Beacon-Datei / Konkordanzliste generieren

Durch ein weiteres Anhängen des Names eines gegebenen Quell-Repositoriums aus dieser Liste kann nun eine Konkordanzliste zwischen den Einträgen bei museum-digital und den Einträgen aus der Quelle aufgerufen werden (Beispiel: https://nat.museum-digital.de/resolver/place/gnd).

Diese Konkordanzliste wird in Form einer Beacon-Datei generiert. Mehr zum Beacon-Format kann etwa hier gefunden werden.

Link Resolving

Die eigentliche Hauptfunktion des Resolvers (wie der Name schon sagt) besteht in der Vereinfachung des Verlinkens von Inhalten aus museum-digital über IDs aus externen Repositorien.

Hängt man also z.B. an die eben genannte URL eine GND-ID eines Ortes an, wird zur entsprechenden Ortsseite weitergeleitet. 4078337-6 entspricht in der GND Tokyo, https://nat.museum-digital.de/resolver/place/gnd/4078337-6 führt also zur Ortsseite von Tokio in der deutschlandweiten Instanz von museum-digital.

info

License

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

Mehr Mehrsprachigkeit

2019-09-22T00:00:00+00:00

Die Navigation der verschiedenen Programme und Seiten von museum-digital ist seit Jahren mehrsprachig. Namen und Beschreibungstexte von Objekten, Sammlungen und Museen lassen sich ebenso seit Jahren mehrsprachig erfassen. Die Mehrsprachigkeit bei museum-digital hatte jedoch lange ein großes Manko: Einträge aus den kontrollierten Vokabularen - also Akteure, Orte, Zeiten und Schlagworte - waren bis jetzt Einsprachig.

In den letzten Wochen haben wir uns verstärkt der Verbesserung der Mehrsprachigkeit von museum-digital gewidmet. Auch Einträge aus den kontrollierten Vokabularen sind jetzt übersetzbar oder werden zumindest in international verständlicher Form angezeigt. Übersetzungen von Objektinformationen sind leichter einzugeben. Und bald werden auch Themenseiten im “Themator” mehrsprachig.

Auch die Kachel für Suchergebnis-Inforrmationen bei Personen ist übersetzbar. Hier ist etwa der arabische Text zu Johann Wolfgang von Goethe zu sehen.

Mehrsprachigkeit von kontrollierten Vokabularen

Eine Schlagwort-Bearbeitungsseite in nodac. Im unteren mittigen Bereich finden sich die aus Wikipedia ausgelesenen Übersetzungen des Vokabulareintrags.

Seit knapp einer Woche können Einträge aus den kontrollierten Vokabularen von museum-digital von der “Normdatenredaktion” übersetzt werden. Übersetzungen können dabei entweder händisch eingegeben werden, oder halb-automatisch aus Wikidata ausgelesen werden.

Ist ein Begriff einmal mit Übersetzungen erfasst, können diese Übersetzungen jetzt auch in der Ausgabe angezeigt und genutzt werden. Dies hilft einerseits bei der Anzeige: Ist ein Objekt mit “Helm” verschlagwortet, erschien bisher das deutsche Wort “Helm” im Bereich für Tags, auch wenn der Benutzer English als Sprache gewählt hatte. Jetzt erscheint an der selben Stelle “helmet”. Weil sich die meisten Zeitbegriffe nicht ohne weiteres übersetzen lassen - erst recht nicht automatisiert - werden Zeitbegriffe in Jahreszahlen ausgedrückt, wenn ein Benutzer nicht die Standardsprache der Instanz benutzt.

Genauso wie die Tags, Orte, und Personeneinträge unten auf Objektseiten übersetzt werden, lassen sich auch die Info-Kacheln auf Suchergebnisseiten übersetzen. Hier erscheinen nun der Sprache des Benutzers entsprechende Titel und Beschreibungen.

Seit dieser Woche sind auch Suchen in der Sprache des Benutzers möglich. Hier wurde beispielsweise nach “helmet” gesucht.

Neben der Anzeige lassen sich die Übersetzungen aber auch für erweiterte Programmfunktionen benutzen. Bisher ist dies in der Suchfunktion der Fall: Benutzer können nun auch in der von ihnen gewählten (Navigations-)Sprache nach Objekten suchen. Bei englischer Navigationssprache werden also die Englischen und Deutschen übersetzungen überprüft. Um nach Köln zu suchen, kann man nun also auch nach “Cologne” suchen - gegeben, dass man die Seite in Englisch navigiert.

Leichter Übersetzen in musdb

Übersetzen ist einfacher, wenn man sieht, was man gerade übersetzt - natürlich. Dieser simplen Erkenntnis haben die Übersetzungsoberflächen für Basisinformationen zu Objekten, Sammlungen und Institutionen in musdb leider bisher keine Rechnung getragen. Übersetzer waren mit einer einfachen Oberfläche bestehend aus “Eingabeschlitzen” konfrontiert.

Um die Übersetzung zu erleichtern haben wir seit letzter Woche den “Inhalte wiederholen”-Button auch in die Übersetzungsoberfläche integriert. Damit lässt sich der “Haupteintrag” (also in deutschsprachigen Instanzen die deutschsprachigen Titel und Beschreibungen) in die jeweiligen Felder der Übersetzungsoberfläche überführen, sodass Übersetzer suksessive übersetzen und die deutschsprachigen Sätze durch die Übersetzung ersetzen können.

Die Übersetzungsseiten in musdb haben jetzt einen “Wiederholen-Button”, mit dem die entsprechenden Texte aus den Basis-Einträgen in ein Eingabefeld kopiert werden können.

Mehrsprachigkeit im Themator? Mehrsprachigkeit im Themator!

Gerade sind wir bei einer großflächigen Überarbeitung des Themators. Diese betrifft besonders die Eingabe, deren Code in die Jahre gekommen war und dringend einer Verbesserung bedurfte. Als kleines Schmankerl kommt auf Wunsch der Kollegen aus Ungarn und dem Ethnologischen Museum in Berlin mit dem nächsten Update des Themators aber auch die Übersetzbarkeit von Einträgen als neues Feature.

Alles in allem befindet sich museum-digital jetzt auf einem guten Weg komplett mehrsprachig zu werden. Besonders die mehrsprachige Suche ist ein lange gehegter und häufig diskutierter Traum. Alles, was es jetzt noch braucht, sind die mehrsprachigen Inhalte selbst.

info

License

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

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.

Die "Graphennavigation": Netzwerke und Verbindungen in museum-digital erkennen

2019-05-09T00:00:00+00:00

Im letzten Jahr haben wir einige Features in museum-digital eingeführt, die relativ schwer zu finden sind und bisher nie in einem größeren Rahmen besprochen wurden. Die schwere Findbarkeit ist bis zu einem gewissen Grad Absicht: Auch wenn neue Visualisierungen und Zusatzfunktionen sinnvolle Ergänzungen darstellen, geht es bei Objektseiten doch primär um Objekte, bei Institutionsseiten um das jeweilige Museum, etc. Davon sollen zusätzliche Funktionen nicht ablenken.

Dass diese Zusatzfunktionen bisher weder im Blog noch im Handbuch besprochen wurden soll sich nun suksessive Ändern. Als Erstes nun soll es um die “Graphennavigation” gehen.

Wie erreiche ich die Graphennavigation?

Die Graphennavigation kann von den Seiten einer gegebenen Einzelentität (etwa eine Objektseite, eine Museumsseite, eine Sammlungsseite) aus erreicht werden. Auf diesen Seiten findet sich in der jeweiligen Options-Sidebar ein Link zur Graphennavigation. Auf Objektseiten findet sich dieser Link sowohl oben neben dem Titel als auch unten im Optionen-Bereich.

Weg zur Graphennavigation auf Objektseiten: Oben rechts neben dem Bread-Crumb findet sich ein Button zum öffnen der Graphennavigation

Auf Institutionsseiten findet sich der Link zur Graphennavigation in der rechten Seitenspalte.

Die Graphennavigation

Die “Graphennavigation”

Die Graphennavigation dient einer graphischen Darstellung der Verknüpfungen zwischen den verschiedenen Einträgen und Eintragstypen. Öffnet man etwa auf einer Objektseite die Graphennavigation, erscheinen die mit dem Objekt verknüpften Personen, Schlagworte, Orte, Objektgruppen, etc. als jeweils entsprechend eingefärbte Knotenpunkte. Durch einen Klick auf einen Eintrag, lassen sich die mit diesem verknüpften Daten nachladen. In der Seitenspalte am rechten Bildschirmrand finden sich standardmäßig Details zum derzeit fokussierten Datenpunkt.

Oben in der Seitenspalte gibt es weitere Reiter: “Was”, “Optionen” und “Verstecken”. Unter “Was” erreicht man eine kurze Einführung in die Benutzung der Graphennavigation. Mit “Verstecken” kann die Seitenspalte ein- und ausgeblendet werden.

Unter “Optionen” gibt es eine Reihe von Schiebern, mit denen die Sichtbarkeit der verschiedenen Eintragstypen an- und ausgeschaltet werden kann. Mit dem Schieber hinter “Objekt” können beispielsweise alle Objekt-Datenpunkte unsichtbar geschaltet werden. Dies ist besonders hilfreich, wenn durch Weiterklicken eine Vielzahl von Einträgen sichtbar gemacht wurden.

Unter den Schiebern finden sich zwei Buttons. Mit dem Ersten lässt sich die Ansicht auf den gerade ausgewählten Datenpunkt fokussieren - gerade wenn viele Daten dazugeladen wurden kann es ohne diesen Schalter manchmal schwer werden, den gerade Gewählten wiederzufinden.

Die “Graphennavigation” lässt sich über die rechte Seitenspalte anpassen. Hier wurden etwa die normalen Kreise zur Symbolisierung der einzelnen Entitäten durch weitergehend beschriftete Boxen ersetzt.

Mit dem zweiten Button lassen sich die Datenpunkte als Boxen mit entsprechender Beschriftung statt Kreisen mit dem Typen entsprechenden Beschriftungen anzeigen. Einerseits wird das Netzwerk dabei leichter verständlich - weil aber die vollen Namen gerade bei Objekten oft lang sind kann diese Ansicht schnell unübersichtlich werden.

Zum Erstellen der Graphennavigation benutzen wir die JavaScript-Bibliothek vis.js.

info

License

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

md:term

2019-02-28T00:00:00+00:00

Dies ist ein alter Beitrag zu md:term aus meinem persönlichen Blog, der bisher hier nicht auffindbar war. Da mich in letzter Zeit häufiger Fragen zum maschinellen Auslesen der kontrollierten Vokabulare von museum-digital erreichen, veröffentliche ich ihn hier noch einmal. Auch wenn der Beitrag, ursprünglich geschrieben im Januar 2017, schon älter ist, sollte md:term doch im Blog von museum-digital vorgestellt sein.

Seit letzter Woche ist die neue API für die kontrollierten Vokabulare bei Museum-Digital online: md:term. Zusätzlich zur eigentlichen Schnittstelle bietet md:term einen Vokabularbrowser, mit dem Benutzer (ob Programmierer oder nicht) durch die Vokabulare navigieren können.

Kontrollierte Vokabulare bei Museum-Digital

Eine Suche nach dem Begriff Helm. Links sind Angaben zum Begriff zu finden.

Kontrollierte Vokabulare kommen bei Museum-Digital sowohl bei der Suche als auch bei der Bereitstellung von Kontextdaten zu Museumsobjekten zur Anwendung. Wer z.B. in der deutschlandweiten version von Museum-Digital nach Helm sucht, wird in der Seitenspalte links eine Liste mit unterbegriffen und verwandten Begriffen von Helm finden, die aus den internen kontrollierten Vokabularen gespeist wird. Ist nun ein Objekt ausgewählt, finden sich hinter den Namen von verknüpften Personen und Orten Schalter mit dem Buchstaben i. Klickt der Benutzer auf einen dieser Schalter, werden (so vorhanden) Daten aus den kontrollierten Vokabularen von Museum-Digital angezeigt - Beschreibungen, alternative Namen, Links zu z.B. Wikipedia - oder anhand dieser Daten aus anderen Quellen hinzugeladen - z.B. Karten im Fall eines verknüpften Ortes, auf denen der Ort mithilfe von bei Museum-Digital gespeicherter Koordinaten lokalisiert wird.

Kontrollierte Vokabulare sind also ein wichtiges, wenn auch relativ leicht zu übersehendes Element von Museum-Digital. Entsprechend wird viel Arbeit in die Moderation der Vokabulare gesteckt.

Informationen zu Friedrich IV. von Braunschweig-Lüneburg (1574-1648) werden, so angefordert, zur Objektseite Medaille von Johann Blum auf Herzog Friedrich von Braunschweig-Lüneburg und die Verhandlungen zum Westfälischen Frieden, 1646 hinzugeladen.

Während jeder Eingebende neue Begriffe hinzufügen kann, werden diese von einer ausgewählten Gruppe von Leuten moderiert, angereichert oder ggfs. mit existierenden Begriffseinträgen zusammengeführt.

Mittlerweile sind alleine in den deutschsprachigen kontrollierten Vokabularen - unterteilt in Personen, Orte, Zeiten und Schlagworte - über 55000 moderierte Begriffe vorhanden, die sicherlich nicht nur für die Verwendung bei Museum-Digital nützlich sein können. Das Schreiben einer öffentlichen und generell nutzbaren Schnittstelle ist eine logische Konsequenz hiervon.

md:term

Daten aus den kontrollierten Vokabularen sind bei md:term in bisher drei Formaten abrufbar: Einer im Webbrowser betrachtbaren und navigierbaren HTML-Version, in JSON und SKOS, die als leicht maschinenlesbare Formate die Benutzung durch externe Programierer erleichtern.

Ein wichtiger Teil von md:term ist hierbei die Umbenennung von Variablen. Während museum-digital ursprünglich in Deutschland entstanden ist und in der Datenbank entsprechend deutsche Namen verwendet werden, wird es mittlerweile beispielsweise auch in Ungarn eingesetzt. Damit die Benutzung der kontrollierten Vokabulare auch durch nicht deutschsprachige Programmierer möglich ist, werden die Variablennamen mit englischen Entsprechungen überschrieben.

Ebenfalls auf internationale Benutzbarkeit ausgerichtet, bietet die HTML-Version deutsche und englische Übersetzungen von feststehenden (also nicht nur zu einem einzelnen Datensatz gehörenden) Texten, z.B. Überschriften und der Navigation. Dies kann in Zukunft leicht um zusätzliche Sprachen erweitert werden.

Daten von md:term abfragen

Zur Abfrage von md:term in JSON und SKOS muss die ID eines Eintrags in der entsprechenden Datenbank bekannt sein. Ist dies der Fall, wird eine Abfrage in der URL nach dem Format https://term.museum-digital.de/Name der Vokabularversion (z.B. md-de)/Typ des Eintrages/ID/format durchgeführt. Zum Beispiel:

$ curl https://term.museum-digital.de/md-de/place/13384/json
{
    "id": "13384",<br>"name": "Abtstra\u00dfe (Brandenburg an der Havel)",
    "class": "Stra\u00dfe",
    "tgn": "",
    "geonames": "",
    "latitude": "52.406989561274",
    "longitude": "12.564392566637",
    "zoom": "16",
    "note": "Stra\u00dfe in Brandenburg an der Havel",
    "synonyms": [],
    "references": [],
    "broader": {
        "": [{
            "name": "Brandenburg an der Havel",
            "broader_id": "246"
        }]
    },
    "narrower": []
}

Aus den Abfrageergebnissen kann man IDs für weitere Abfragen finden, der Ort im Beispiel, die Abtstraße (Brandenburg an der Havel) mit der ID 13384 ist Brandenburg an der Havel mit der ID 246 untergeordnet.

Eine Suchfunktion ist bisher nur in der HTML-Ausgabe vorhanden. Gibt es ein im Namen perfekt übereinstimmendes Suchergebnis oder nur ein einziges bei einer loseren Entsprechung, wird direkt auf den entsprechenden Eintrag umgeleitet. Gibt es zwei oder mehr, so werden dem Benutzer die möglichen Suchergebnisse mit Titel und, so vorhanden, Beschreibung aufgelistet.

Ist man so zum gewünschten Eintrag gelangt, ist über der Ausspielung der Daten ein Feld mit der Abfrage-URL und - direkt darunter - Links zum Eintrag in alternativen Formaten zu finden.

Screenshot aus md:term. Zeigt eine Ortsansicht.

[Originalbeitrag: https://www.jrenslin.de/post/40]

info

License

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

Mehr als nur ein neues Gewand für museum-digital

2018-05-20T00:00:00+00:00

Viele kleine Verbesserungen und die Suche nach einem geeigneten Platz für die Datenschutzerklärung haben uns erwogen das Design von museum-digital grundsätzlich zu überarbeiten. Das Layout wurde weiter an verschiedene Geräte und Bildschirme angepasst. Am auffälligsten ist vielleicht, dass die Startseite jeder Version - die stets recht leer war - nun von einem großen Bild eingenommen wird (keine Angst, es geht darunter weiter). Die großen Objektabbildungen rotieren und beim nächsten Aufruf kann eine andere erscheinen. Überarbeitet wurden insbesondere die Anzeigeseiten für einzelne Objekte, wo sich jetzt Zitierlinks finden und klarer erkennbar wird, wie die angebotenen Informationen verwendet werden können. Eine Überarbeitung hat auch die “Gezielte Suche” erfahren, es gibt jetzt wesentlich mehr Felder, in denen gezielt gesucht werden kann. Neu gestaltet wurden auch die Seiten zu Museen und Sammlungen … Schauen Sie selbst!

museum-digital - Suche in allen beteiligten Museen

2011-04-25T00:00:00+00:00

Der Wunsch nach einer übergreifenden Suche nach Objekten in allen an museum-digital beteiligten Museen wurde mehrfach geäußert. Es gibt diese Suchmöglichkeit ab sofort!
Im Wesentlichen bleibt Alles wie es war - die regionalen Datenbanken bleiben der Kern von museum-digital. Aus diesen Datenbanken speist sich jetzt jedoch zusätzlich eine übergeordnete Datenbank, welche die Suche und Anzeige von Objekten aus zunächst 173 Museen ermöglicht. Die “Suche in allen beteiligten Museen” ist erreichbar über die Startseite von museum-digital (Suchschlitz und Link in der rechten Spalte) oder auch direkt über www.museum-digital.de/nat.

museum-digital wird "büchertauglich"

2010-09-01T00:00:00+00:00

Schon bisher war es bei museum-digital möglich ein Museumsobjekt durch unendlich viele Abbildungen darzustellen. Was fehlte, war eine übersichtliche Navigation zwischen den einzelnen Ansichten. Ein Hin- und Herklicken zwischen großer Ansicht und Thumbnail-Übersicht auf der Objektanzeigeseite war nötig. Jetzt werden die großformatigen Ansichten gemeinsam mit einer Übersicht aller Ansichten des betreffenden Objektes angezeigt, wie beispielsweise hier. Wenn zu einem Objekt sehr viele Ansichten vorliegen, dann erscheint eine eigene Navigationsleiste mit Schaltern für “vor” und “zurück” (Beispiel: hier). Umfangreiche Dokumente oder ein vollständig eingescanntes Buch (Beispiel: hier) lassen sich damit endlich übersichtlich publizieren.

Besser finden ... "Gezielte Suche" bei museum-digital

2010-08-30T00:00:00+00:00

Ab sofort gibt es neue Möglichkeiten etwas bei museum-digital zu finden. Die Rubrik “Objekte” ist um eine “Gezielte Suche” erweitert worden (Beispiel: hier). Dort ist es jetzt möglich Objekte nach jenem zu finden, mit dem sie in Beziehung stehen. Das sind z.B. Personen/Institutionen, Orte oder Zeitbegriffe. Beispielsweise lassen sich jetzt, durch Auswahl eines Personennamens, alle Objekte finden, die etwas mit dieser Person, etwa einem Maler, zu tun haben. Die Suche läßt sich durch Auswahl einer einzelnen Objektart (z.B. “Gemälde”) oder durch Eingrenzung der Art der Beziehung zwischen Objekt und Person (z.B. “gemalt”) weiter eingrenzen. Diese Suchmöglichkeiten werden noch weiter ausgebaut werden, so dass Über- und Unterbegriffe berücksichtigt werden können. Aber auch jetzt schon steht damit Allen, die gezielter suchen ein nützliches Werkzeug zur Verfügung.

Nutzung von Linked Data bei museum-digital (III)

2010-07-27T00:00:00+00:00

Eine kleine Erweiterung hat - in allen Versionen von museum-digital - jenes Fenster erfahren, welches zusätzliche Informationen und eine Karte zu Herstellungsorten, Fundorten, … enthält. Dieses Fenster öffnet sich, wenn man hinter der entprechenden Ortsangabe auf das Wort “Info” klickt. Bisher enthielt das Fenster nur eine Karte von OpenStreetMap. Jetzt erscheinen rechts neben dieser Karte einige Angaben zum jeweiligen Ort (Einwohnerzahl, Geokoordinaten, Hierarchie und alternative Ortsnamen - auch in mehreren Sprachen). Ein Beispiel mag eine Stadtansicht von Salzwedel aus dem Johann-Friedrich-Danneil-Museum sein (hier). Klickt man hinter “[Ortsbezug]… Salzwedel” auf das Wort “Info”, so öffent sich das entsprechende Fenster. Die Daten des Webservices von geonames werden gelesen und in neuer Zusammenstellung präsentiert. Der Link zu den Normdaten des TGN wurde ebenfalls in dieses Fenster verlegt. Bisher funktioniert diese Erweiterung nur bei einigen Orten - es werden bald mehr. Dort, wo diese Ergänzung noch nicht eingerichtet ist erscheinen wie bisher “[Karte]”, “[GeoNames]”, “[TGN]” hinter den Ortsnamen. Mit dieser Erweiterung vereinfacht sich die Darstellung und es erscheint nur noch “Info”.

Nutzung von Linked Data bei museum-digital (II)

2010-07-01T00:00:00+00:00

Ab sofort erscheinen in den kleinen Fenstern, die sich dann öffnen, wenn man hinter einen Herstellernamen, Nutzernamen, … auf das Wort “Info” klickt, nicht nur die Angaben der gnd, sondern auch die jeweils ersten Absätze der entsprechenden Wikipedia-Artikel in mehreren Sprachen. Für diese Darstellung wird die dbpedia genutzt. Wie bei den Angaben aus der gnd wird auch hier das entsprechende RDF-File ausgelesen und in neuer Zusammenstellung präsentiert. Unter den dort vorhandenen Angaben findet sich oft auch ein Hinweis auf eine Abbildung zur entsprechenden Person bei wikimedia. Ist dies der Fall, so wird diese Abbildung ebenfalls in das Fenster für Personenangaben eingebunden. Als Beispiel mag das Gemälde “Lesende Magdalena” des Anton Graff dienen (hier). Klickt man auf das Wort “Info” hinter dem Malernamen so öffnet sich ein Fenster mit den Angaben der gnd, einem Bild des Malers und Wikipedia-Auszügen in sechs Sprachen. Es zeigt sich, dass diese Auszüge durchaus unterschiedlich sind - nicht nur in der Sprache. Die Nutzung der dbpedia erfolgt vollautomatisch und verlangt keine Eingaben oder Bearbeitungen.

Nutzung von Linked Data bei museum-digital

2010-06-30T00:00:00+00:00

Ab sofort werden in allen Versionen von museum-digital die weiterführenden Angaben zu Herstellern, Nutzern, … direkt aus der GND (PND) der Nationalbibliothek bezogen. Es werden dazu die RDF-Ausspielungen der GND-Datensätze ausgelesen und bei museum-digital in einem eigenen Fenster neu zusammengestellt und ausgespielt. Als Beispiel mag das Gemälde des Michiel van Miereveld geben, welches Luise de Colligny zeigt (hier). Klickt man dort auf “Info” hinter dem Namen des Malers oder der Dargestellten öffnet sich dieses Fenster mit den Angaben der DND. Vorteil dieser Lösung ist, dass sie stets aktuell ist. Korrigiert die Nationalbioliothek ihre Angaben so sind die Korrekturen sofort auch bei museum-digital sichtbar.

Startseite von www.museum-digital.de neu gestaltet

2010-05-03T00:00:00+00:00

Die Startseite von www.museum-digital.de wurde - zunächst versuchsweise - neu gestaltet. Die rechte Spalte gibt jetzt stets Auskunft über die zuletzt eingefügten Objekte in irgendeinem der einzelnen Portale. Von dieser Seite aus besteht jetzt auch die Möglichkeit, die neuesten Objekteingaben der jeweiligen Portale einzeln als RSS-Feed zu abonnieren (in der linken Spalte). So kann man über Neuzugänge immer auf dem laufenden bleiben.

Zweistufiges Suchen jetzt möglich

2010-01-17T00:00:00+00:00

Wenn man bisher bei museum-digital ein Objekt gefunden hatte, dann erschienen am linken Rand der Ausgabeseite Links auf Objekte, die in gewisser Weise ähnlich sind (gemeint ist Ähnlichkeit in Gebrauch und Genese, weniger in der physischen Manifestation). War zum Beispiel das gefundene Objekt in Magdeburg hergestellt worden, so erschien auf der linken Seite ein Link zur Seite aller Objekte, die in Beziehung zu “Magdeburg” stehen. Diese Seite war jedoch unspezifisch. Soll heißen, es wurden Objekte, die in irgendeiner Beziehung zu Magdeburg stehen aufgeführt. Jetzt ist es möglich von dieser Seite aus die Beziehungsart weiter einzugrenzen, also eine Seite der Objekte, die in Magdeburg “hergestellt” wurden aufzurufen, aber ebenso eine Seite der Objekte, die in Magdeburg “genutzt” oder eine Seite mit Dokumenten, die in Magdeburg “ausgefertigt” wurden. In gleicher Weise konnte man vorher schon alle Objekt in Beziehung zu z.B. Johann Wilhelm Ludwig Gleim finden. Jetzt kann man die Objekte, die ihn “zeigen” von den Briefen, die er “empfangen” oder “verfasst” hat, trennen.

Eingrenzung der Suche bei museum-digital:sachsen-anhalt möglich

2009-10-05T00:00:00+00:00

Ab sofort ist es möglich, bei museum-digital:sachsen-anhalt Objekte aus einem einzelnen Museum (Beispiel: Museum Schloss Bernburg) oder aus einer einzelnen Sammlung (Beispiel: Porträtsammlung Freundschaftstempel des Gleimhauses in Halberstadt) zu suchen. Auch die Navigation in der linken Spalte ist angepasst.

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