museum-digital:blog - Technik/Design

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.

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

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

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

Etwas geschmälert wird der Nutzen leider dann doch oft durch die schlechte tatsächliche Zugänglichkeit der Inhalte. Selbst wenn die Quellen frei erreichbar sind, bedeutet die oft schlechte Texterkennung, dass sie nicht systematisch durchsuchbar sind. Im kleinen ist das verkraftbar: Suche ich in von - je band - immerhin meist drei parallel verfügbaren Ausgaben von Naglers Künstlerlexikon nach einem Eintrag, ist die Chance hoch, dass ich ihn nur beim manuellen Durchblättern finde. Durch den alphabetischen Aufbau ist das leicht getan.

Wenn ich aber die Quelle noch nicht kenne, bzw. nicht weiß, ob ich bei Nagler, oder z.B. in einem Lexikon speziell nur für Kupferstecher suchen soll, dann summiert sich die Arbeit. Abhilfe schüfe eine bessere OCR und eine Aufbereitung in einer für Suchmaschinen gut lesbaren Form. Und was können Suchmaschinen besser lesen als Webseiten?

Also: resources.museum-digital.org!

Motivation: Vokabulararbeit

Ein zentraler Bestandteil der Arbeit im Hintergrund von museum-digital ist die Vokabulararbeit. Die eindeutige Bestimmung, in-Beziehung-Setzung und Anreicherung von Begriffen zu Akteuren, Orten, Schlagworten / Konzepten und Zeiten. Entsprechend oft wünscht man sich - besonders für weniger bekannte Entitäten - Nachschlagewerke. Und umso hilfreicher sind einfach und bedenkenlos zugängliche und nachnutzbare, gemeinfreie Nachschlagewerke. Diese haben in ihrer Masse zudem oft den Vorteil, das aus heutiger Sicht weniger Relevante Einträge aufgeführt werden, die zur Zeit der Veröffentlichung noch als der Nennung wert eingeschätzt wurden.

Dazu kommt, dass gerade in der Vokabulararbeit oft nur wenig Kontext vorhanden ist. Die beste Kenntnis oder zumindest den besten Zugang zu den Objekten haben schließlich die Museen und nicht entfernt und meist ehrenamtlich arbeitende Vokabular-Redakteure. Umso nützlicher wäre es, Inhalte aus historischen Nachschlagewerken in der Breite durchsuchen zu können, ohne schon vorher wissen zu müssen, welches Nachschlagewerk man nun heranziehen muss.

Es ist also in unserem unbedingten Interesse, mehr der eigentlich schon verfügbaren Quellen in der Breite schnell durchsuchen zu können. Am besten einfach mit Google (oder der Suchmaschine der Wahl). Dabei ist die Menge der besser verfügbaren Nachschlagewerke im Zweifelsfall wichtiger als 100%-ige Korrektheit - diese lässt sich, sobald man einen passenden Eintrag gefunden hat immer noch durch das zurateziehen der Scans herstellen.

resources.museum-digital.org

Als kleines Nebenprojekt im museum-digital-Kosmos soll resources.museum-digital.org nun also dazu dienen, historische Nachschlagewerke durch eine neu durchgeführte Texterkennung mit der heute verfügbaren Technik und eine Präsentation nach Web-Logik verfügbarer zu machen. Den Aufschlag machen dabei die 22 Bände vom schon erwähnten Neuen Allgemeinen Künstlerlexikon von Georg Kaspar Nagler. Die Grundlage bildeten dabei die im Internet Archive durch verschiedene Bibliotheken verfügbar gemachten und auf der Seite verlinkten Scans der Bände.

Wichtig dabei war von Anfang an, dass eine rein automatische Bearbeitung gut genuge Ergebnisse für eine Präsentation bieten sollte, und das die Präsentation der fast zwangsläufig imperfekten, automatisch generierten Daten einerseits an sich schon gewinnbringend und andererseits manuell verbesserbar sein sollte. Dazu war und bleibt es wichtig, die rein maschinell erstellten Transkriptionen als eben solche zu Kennzeichnen.

Ansatz: Hin zur neuerlich durchgeführten Texterkennung

Um halbwegs leserliche und verwertbare Textvorlagen für die Erstellung der Seite zu bekommen, versuchten wir zuerst, mit der bestehenden OCR zu arbeiten. Diese war im Falle Naglers oft gut genug, um die grobe Struktur des Werkes abzubilden, beinhaltete aber soviele Fehler, dass schon eine regelbasierte Aufspaltung der Einträge (eigentlich im konkreten Fall recht leicht, da fast jeder Eintrag mit “<Nachname>, <Vorname>,” anfängt) deutlich unzuverlässig wurde. Der Versuch eine LLM-basierten Korrektur der OCR half etwas, aber nicht in einem zufriedenstellenden Maße.

Vorgehen: Neue OCR

Stattdessen sollte es also eine gänzlich neue OCR sein. Glücklicherweise bieten die Uploads im Internet Archive neben den PDFs wenig komprimierte .jp2-Versionen der einzelnen Seiten eines Buches zum Download an, die eine fast ideale Basis für das weitere Vorgehen boten. Für eine bessere Interoperabilät mit verschiedenen Programmen wandelten wir diese ohne weitere Kompression in .png-Dateien.

Grob sollten die einzelnen Scans nun mit Tesseract transkribiert und in der Folge mit dem multimodalen LLM Qwen3-VL, später Qwen3.5, gegengeprüft werden.

Es ist - zumindest in interessierten Kreisen - fast schon eine Binsenweisheit, dass Tesseract mit entsprechend vorbereiteten Bilddateien deutlich besser umgehen kann als mit anderen. Idealerweise sollten Scans mindestens 600 DPI haben (bzw. eine entsprechende Pixelzahl bieten - im Schlimmstfall kann selbst ein naives Hochskalieren der Bilder zu besseren Ergebnissen führen) und Schwarzweiß oder in Graustufen gehalten sein. Entsprechend werden die Scans in einer Arbeitskopie den Vorgaben angepasst und dann mit Tesseract OCR-ed.

Im nächsten Arbeitsschritt werden einzelnen Scan-Seiten gemeinsam mit den Ergebnissen von Tesseract als Vorlage an das KI-Modell übergeben.

Wichtige Erkenntnisse dabei gibt es zweierlei: Besonders bei unsauber gescannten Seiten bietet Qwen3.5 oft bessere Ergebnisse als ein nicht nachtrainiertes Tesseract. Es passiert allerdings relativ häufig, dass ganze Seitenbereiche (z.B. Absätze) einfach “übersehen” werden. Das lässt sich durch die Mitgabe auch einer mit Schreib- oder Lesefehlern gespickten Vorlage umgehen. Zweitens erziehlt Qwen3.5 bessere Ergebnisse mit den nicht nachbearbeiteten Bilddateien (mehrfarbig, nicht verstärkter Kontrast / wenig Tonwertkorrektur, etc.) als mit den für Tesseract optimierten.

In diesem Arbeitsschritt kam es hin- und wieder zu deutlichen Zeitüberschreibungen. Wo ein üblicher Scan vielleicht 5 Sekunden brauchte, brauchten einzelne mehrere Stunden. Hintergrund waren besonders unsaubere Scans (bzw. Nachbearbeitungen beim ursprünglichen Ansatz, Qwen3.5 mit den nachbearbeiteten Scans arbeiten zu lassen): Hier ergab die OCR mit Tesseract schon nur ein Durcheinander, und auch mit Qwen3.5 konnten keine Ergebnisse erzielt werden. Abhilfe schaffte das Einführen eines Timeouts. Nach zwei Minuten wird die Abfrage abgebrochen und Qwen3.5 um eine selbstständige OCR der Seite angefragt. Ergibt auch das keine Ergebnisse, wird die Seite übergangen.

Die so erstellte, maschinell nachgeprüfte OCR der Einzelseiten wird nun mit einem Script in eine JSON-Datei zusammengefasst und in die einzelnen Einträge aufgespalten. Die Erkennung von einzelnen Einträgen ist dabei kontextabhängig. Im Falle von Nagler war der Beginn der Einträge durch die Nennung der Namen verhältnismäßig einfach durchführbar.

Mehr Sinn erkennen

Eine gute Webseite präsentiert nicht nur Daten, sondern verlinkt diese intern wie extern. Je mehr Sinn also (automatisch) aus den einzelnen Einträgen gezogen werden kann, desto besser lassen sich die Einträge präsentieren - und später suchen.

Statt also die einzelnen Einträge einfach so im Web wiederzugeben, werden sie erst einmal einer Named Entity Recognition mit GLiNER2 unterzogen, um im Eintrag genannte Personen, Orte, Zeiten, Berufe und Kunstrichtungen zu erkennen.

Um falsch erkannte oder nach Ansicht von museum-digital kategorisch falsch zugeordnete Entitätsnamen (z.B. die Person “Prinzessin”) zu filtern, werden die so erkannten Begriffe mit der Reconciliation API von md:term abgeglichen. In der Folge werden nur solche Begriffe als verknüpfte Entitäten weiterverwertet, die bei museum-digital schon bekannt sind.

Zuletzt werden zumindest in Naglers Fall auch die Titel der Einträge reconciled. In diesem Fall gegen Wikidata, da dieses einerseits mehr der Namen kennen dürfte, und die verfügbaren Reconciliation APIs andererseits weniger kritisch mit der Verfügbarkeit oder Abwesenheit von Lebensdaten umgehen. Sollte Wikidata einen Treffer abwerfen, wird über die entsprechende BEACON-Datei nach demselben Eintrag in museum-digital gesucht.

Verfügbar machen

Die so gewonnenen Daten werden in den letzten Arbeitsschritten in einfach menschlich bearbeitbare Markdown-Dateien überführt, aus denen schlussendlich mithilfe des Seiten-Generators Zola eine Webseite generiert wird. Die verschiedenen Zwischenschritte, die Scripte zur Named Entity Recognition und Reconciliation, sowie die Markdowndateien finden sich zur freien Nachnutzung und für Korrekturen auf Codeberg.

Eine Suche hat resources.museum-digital.org selbst nicht. Gerade in Anbetracht der Schwierigkeiten, die wir in den letzten Monaten mit Serverauslastung und Resourcenverbrauch hatten, soll die Seite im laufenden Betrieb keine erhöhten zusätzlichen Kosten oder Aufwände benötigen - und ohne Suchfunktion können wir sie trotz ihrer Größe sehr einfach und quasi ohne Wartungsaufwand als statische Seite hosten. Andererseits ist das Ziel ja gerade eine Verbesserung der Auffindbarkeit durch Suchmaschinen, wofür es eine Suche als Bestandteil der Webseite selbst fast nicht mehr bräuchte.

Fazit

Auch wenn das Ausprobieren verschiedener Ansätze einige Zeit gebraucht hat, haben wir jetzt einen Workflow, um historische Nachschlagewerke fast ohne menschlichen Aufwand deutlich besser durchsuchbar verfügbar machen können. Alle eingesetzten KI-Tools laufen lokal, verursachen also außer dem Strom keine weiteren Kosten. Die Ergebnisse können sich - gemessen an Aufwand und Erwartung - sehen lassen. Zum Start macht die Seite 33000 Einträge aus Naglers Künstlerlexikon besser verfügbar.

Das Nachschlagen - und das Lob für das Scannen! - der tatsächlichen Quellen bleibt dabei unerlässlich. Ensprechend verlinkt jede Unterseite von resources.museum-digital.org die je relevante Quelle (d.h. auch den konkreten Scan) prominent.

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

Danksagung

Danke an Felix Schenke, dessen Berichte über seine eigenen Arbeiten an der OCR von Handschriften viele Ansätze aufzeigten, die im Rahmen der Arbeit an resources.museum-digital.org hilfreich waren.

info

AI Use

(Post image AI-generated)

info

License

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

Stand der Entwicklung, November 2025

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

Frontend

Verknüpfte Objekte auf Quellen-Seiten sind jetzt sortiert nach Position in Quelle
- Damit ergibt sich quasi automatisch ein Register für die Quelle
Ziel-URL bei Nutzung des unspezifischen Suchschlitzes für Objekte auf neues Format umgezogen
OAI-PMH-Schnittstelle
- Standartisierter Zugang für Aggregatoren, um Daten vieler Objekte abzurufen
- Bisher unterstützte Objekt-Metadatenformate:
  - LIDO
  - OAI-DC (Pflicht)
- Siehe auch: Blogpost dazu auf Englisch
PDFs werden außerhalb der Standardsprache einer Instanz nur noch bei niedriger Ressourcen-Auslastung generiert
- Der Großteil der “Benutzer” von museum-digital sind derzeit tatsächlich offensichtliche KI-Crawler. Blocken ist schwer bis unmöglich, und ihnen Inhalte zu liefern auch im Sinne der freien Verfügbarmachung von Kulturdaten. Andererseits konkurrieren sie auf dem Server mit realen Menschen. Gerade das Generieren von PDFs ist rechenintensiv und ein Abschalten der Funktion bei hoher Auslastung des Servers bringt relativ wenige negative Konsequenzen (dieselben Daten finden sich auch auf Objektseiten). Dadurch, dass die Sprache beim Blocken der Funktionalität berücksichtigt wird, ist die Wahrscheinlichkeit, dass tatsächliche Nutzer in Mitleidenschaft gezogen werden, weiter beschräkt.
Sammlungsspezifische ISIL-IDs werden jetzt auch in der LIDO-Schnittstelle berücksichtigt
Alternative Nummern eines Objektes werden jetzt auf Objektseiten dargestellt
- Ist in den Einstellungen für das Museum das Schema / die Art der weiteren Nummer hinterlegt, kann eine Erklärung dazu in einem Tooltip abgerufen werden

musdb

Objektsuche
- Type-Ahead-Suche für Sprache (des Inhalts eines Objektes)
- Suche nach Bearbeitungsstatus von Objekten
Stapelverarbeitung von Bearbeitungsstatus (offen, gesperrt, archiviert, etc.)
Parameter des Volltext-Such-Indexes angepasst, um Kofferworte besser zu unterstützen

Importer

Kern

Dry-Run-Modus hat neue Funktion, alle bisher nicht gemappten Werte zu sammeln und gemeinsam anzuzeigen
- Damit können sie in der Folge einfacher und stapelweise über concordance.museum-digital.org gemappt werden
Unterstützung für Import alternativer Nummern von Objekten
Unterstützung für Import der Hierarchie von Räumen

Parser

AdlibXml
- Alternative Nummern werden jetzt ins entsprechende Feld importiert
CsvXml
- Alternative Nummern werden jetzt ins entsprechende Feld importiert
CsvLocations
- Neuer CSV-basierter Parser zum Import von Ortshierarchien
ImageByInvno
- Neue Einstellung: Append Chars (zum Hinzufügen regulärer Suffixe von Inventarnummern)

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, August 2025

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

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

Entwicklung

musdb

Tool zur KI-gestützten Erkennung von Bildinhalten (Schlagworte -> Abgebildetes)
- Muss explizit für eine Sammlung aktiviert werden, über einen neuen Schalter in der Seitenspalte der Sammlungs-Bearbeitungs-Seite
- Nutzbar als Auswahlliste im Verschlagwortungs-Overlay auf der Objekt-Bearbeitungs-Seite
- Siehe auch den Blog-Beitrag
Inhalte im Feld “Ausgabe” bei Literatur können jetzt bis 50 Zeichen lang sein
Hochgeladene PDFs können jetzt bis 40 MB groß sein
Neue Kommandozeilen-Option, um alle Rechte eines Accounts auf den rollenbasierten Standard zurückzusetzen
Neuer Ereignistyp: “Verändert”

nodac

KI-generierte Vorschläge für Definition und übersetzte Namen bei Schlagworten
- Sichtbar rechts in der Seitenspalte (großer Bildschirm)
- Besonders auch genutzt und hilfreich, um Duplikate zu finden

Vorträge

Posterpräsentation auf der CoRDI 2025 (Archivversion) in Aachen, 27.8,2025: “To Educate or to Enforce - The Case for Underhanded Methods to Improve Research Data”
- PDF
- Abstract / Zenodo

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, Oktober 2025

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

Entwicklung

Frontend

Anzeige der Transkriptionen auf Objektseite grundsätzlich überarbeitet
- Titel wird ausgegeben
  - Falls nicht vorhanden werden weiterhin Art (Original vs. Übersetzung) als Ersatz für den Titel genutzt
- Transkriptionen sind sortiert nach Titel
- Kachel-Darstellung deutlich verbessert
  - Probleme mit horizontalem Scrolling sind gelöst
  - Bei nur einer Transkription ist diese auf gesamter Breite dargestellt
  - Bei mehr als 2 Transkriptionen sind die jeweiligen Inhalte by default eingeklappt, lassen sich aufklappen
Stapelweises Abfragen von Objektmetadaten über die API
- Bisher verfügbare Formate: JSON, LIDO
- API-Dokumentation
- Siehe auch: Blog-Post dazu auf Englisch
Punkte in Gleitkommazahlen bei Maßangaben auf Objektseite sind bei Anzeige in Deutsch durch Komma ersetzt
Sammlungsspezifische ISIL-Nummern werden in LIDO-API genutzt

musdb

Titel / Name von Transkriptionen kann nun erfasst werden
ISIL-Nummern pro Sammlung
Setzen von Objektart über Verbesserungsvorschläge setzt den Bezug jetzt korrekt als Objektart
Zusätzliche Formen von Objekten in der Liste verfügbar
- Z.B.: Rund, rechteckig
Suche nach Objektgruppen ohne/mit übergeordneten Objektgruppen

Vorträge etc.

08.10.2025: Vortrag auf der Herbsttagung der Fachgruppe Dokumentation des Deutschen Museumsbundes: “Interoperabilität schaffen - Geschichten aus 1001 Importen”
- PDF
- ODP
14.10.2025: Vortrag auf einer Tagung des Projektes CiVers (Citation of Versioned Web Pages by PID)
- PDF
- ODP
17.10.2025: museum-digital Usertagung 2025

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, September 2025

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

Entwicklung

Frontend

Objekte, die mit einer Quelle verlinkt sind (als Referenz auf die Quelle oder in der Quelle referenziert), werden jetzt auf der Seite der Quelle gelistet
- Beispiel: Quelle: “Novalis Schriften. Die Werke Friedrich von Hardenbergs. Historisch-kritische Ausgabe. Erster Band: Das dichterische Werk. 3. Auflage”
Anzeige von Notizen, Status & Typ für Transkription ist jetzt auf der Objektseite implementiert
Neue Typen zur Klassifikation von Beziehung von Objekt zu Schlagwort
- Taxon
- Thema
- Erwähntes (Analog zu “abgebildetes”)
Dependencies
- OpenLayers auf Version 10.6 geupdatet

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

musdb

Verhinderung von Umbenennen von Vokabulareinträgen zu geblacklisteten Begriffen
- Zuvor konnte man “Unbekannt” anlegen, wenn man einen neuen Begriff angelegt und den neuen Begriff in der Folge zu “Unbekannt” umbenennt
Seitenspalte / Filter für Suche nach Objektgruppen
Neue Typen zur Klassifikation von Beziehung von Objekt zu Schlagwort
- Taxon
- Thema
- Erwähntes
Neue APIs: Alle mit Objekten des Museums verlinkten Vokabulareinträge
Dependencies
- OpenLayers auf Version 10.6 geupdatet

Importer

Kern
- Deakzessionen importieren ist jetzt implementiert
- Empfänger eines Deakzessions-Vorgangs kann jetzt als Bezug zum Adressbuch gesetzt werden
Parser
- CSVXML: Deakzessionen importieren ist jetzt möglich
- ImageByInvno: Option für Zuordnung alle Buchstaben vor einer gegebenen Komibination zu ignorieren

CSVXML

Neue Felder: tag_related_identifier_type, tag_related_identifier

Vorträge etc.

Vortrag “Von museum-digital zum eigenen Online-Katalog” bei der AG Digitalisierung des Museumsverbands Rheinland-Pfalz
- Folien als PDF
- Folien als ODP zur Nachnutzung

info

AI Use

Post image generated using AI.

info

License

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

Automatische Erkennung von abgebildeten Elementen

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

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

Mit einem neuen KI-Feature zur Bildklassifikation, das ab Donnerstag Nacht bereit stehen wird, versuchen wir aus unseren Fehlern zu lernen. Bevor dieses vorgestellt wird aber seien die damaligen Fehler besprochen.

Bildklassifikation, Versuch 1

Im ursprünglichen Anlauf zur Bildklassifikation wurden alle Abbildungen zu allen Objekten entweder beim Upload oder über eine gezielt dazu eingerichtete Seite klassifiziert.

Die Abbildungen wurden dabei an ein KI-Modell übergeben, und seine (englischen) Ausgaben mit dem Schlagwort-Katalog von museum-digital abgeglichen. Die gefundenen Schlagworte wurden dann als Schlagwort-Vorschläge angeboten.

KI braucht passende Hardware

KI-Tools arbeiten am besten auf Grafikkarten. Das, was ein herkömmlicher Webserver nicht hat, ist eine Grafikkarte. Also entschieden wir uns für den offensichtlich klugen Weg: Mithilfe von Tensorflow.js wurden die Berechnungen auf die Geräte der gerade eingebenenden User ausgelagert.

Gut: Die Berechnungen liefen nicht mehr auf der ungeeigneten Server-Hardware. Schlecht: Wer einen durchschnittlichen PC in einem kommunalen Museum kennt, sollte wissen, dass er vielleicht eine Grafikkarte haben mag - aber dann höchstwahrscheinlich auch nur eine Office-Grafikkarte aus dem untersten Preissegment. Und vor allem 2021 waren die meisten Laptops nicht besser für KI-Anwendungen geeignet, als die Server-Hardware von museum-digital. Ergo: Die Berechnungen zur Bildklassifikation dauerte lange(!).

Workflows

Schlimmer noch: Die Berechnungen zur Bildklassifikation waren blockierend. D.h., dass man in dem Browserfenster, in dem die Berechnungen ausgeführt wurden, nicht weiter arbeiten konnte. Dadurch, dass die Bildklassifikation in den Objekt-Ersterfassungs-Workflow eingebaut war, verlangsamte sie diesen deutlich.

In der Reflexion lässt sich feststellen, dass, solange keine wirklich gute Hardware zur Verfügung steht, KI-Anwendungen zu Anfang oder zu Ende des Erschließungsprozesses und von diesem getrennt / im Hintergrund eingesetzt werden sollten. Zu Anfang der Erschließung, wenn nur die Inventarnummer und hoffentlich ein Bild vorliegen, kann z.B. Bilderkennung nützlich sein, um Eingabehilfen und Vorschläge zu generieren. Die erratische Natur von KI - meistens richtig, mal falsch, und bei jedem Durchlauf unterschiedlich - spielt somit keine Rolle, weil es sich nur um später von Menschen nachbearbeitete, akzeptierte oder abgelehnte Vorschläge handelt.

Zu Ende des Erschließungsprozesses kann KI sinnvoll eingesetzt werden, um einerseits auf Basis der vorliegenden Daten zusätzliche Datenfelder zu befüllen (KI-generierte Objektbeschreibungen mit Zwischenspeicherung) oder zusätzliche Funktionen, die naturgemäß schwammigen Kategorien folgen anzubieten (Sortierung nach Ästhetik von Thumbnails).

Der Einsatz von KI-Tools in Echtzeit, wie er im ursprünglichen Bildklassifikations-Tool erwartet wurde, kann mit entsprechend guter Hardware sinnvoll sein. Die im Juni vorgestellte, in Zusammenarbeit mit dem Zuse-Institut und digiS testweise bereitgestellte, Erstellung von Objektbeschreibung auf Basis bestehender Metadaten ist ein gutes Beispiel. Im Zuse-Institut kommt hierzu eine Nvidia GH-200 zum Einsatz. Der Preis der Hardware alleine übersteigt das Jahresbudget vieler Museen.

Die Wahl des Modells sei weise getroffen

Weil eben die Hardware unzureichend war und wir eine Bildklassifikation in Echtzeit ermöglichen wollten, waren wir bei der ursprünglichen Bildklassifikation auf kleine, sehr effiziente Modelle angewiesen. Nach einigem Suchen endeten wir bei MobileNet.

MobileNet kommt zwar prinzipiell aus dem richtigen Bereich (Objekterkennung), hat aber offensichtlich sehr anders gelagerte Trainingsdaten. Straßenschilder und Tiere werden auch bei der vorliegenden, mittlerweile veralteren Version recht stabil erkannt. Anderes eher nicht.

Dass ein Modell mit einen der Verschlagwortung im Museumsbereich näheren ursprünglichen Einsatzgebiet bessere Ergebnisse geben sollte, bedarf eigentlich keiner größeren Erläuterung.

Für welche Objekte eignet sich Bildklassifikation?

Die ursprüngliche Bilderkennung hat also technische und organisatorische Probleme. Aber sie hat inhaltliche: Bilderkennung erkennt eben Bilder. Objekte sind Objekte. Eine annähernd deckungsgleiche Übereinstimmung zwischen Bild und Objekt kann vorliegen, muss aber nicht. Meist lässt sich das an Objektarten festmachen: Beschreibt man den Scan einer frühen Fotografie oder eines Ölgemäldes, beschreibt man gleichzeitig das Objekt. Beschreibt man das Foto eines Schranks, hat man wahrscheinlich deutlich weniger über das Objekt selbst und dafür mehr über die Umstände des Fotografierens gesagt.

Auch eine relativ naive, nicht spezifisch auf Objektabbildungen nachtrainierte Bilderkennung kann im Museumsbereich also sinnvoll sein, ihr Nutzen ist aber Kontextabhängig.

Der zweite Anlauf: Bilderkennung für abgebildete Elemente

Ab Donnerstag wird nun eine neue Funktion zur automatisierten Bilderkennung zur Verfügung stehen, die vor dem Hintergrund der Fehler des ersten Anlaufs spezifischer agiert und (hoffentlich) sinnvoller in bestehende Workflows integrierbar ist. Ziel ist die Erkennung von Bildinhalten spezifisch für solche Objekte, bei denen Bild und Objekt annähernd deckungsgleich sind.

Da dies eben nicht alle Objekte sind, muss das Feature spezifisch aktiviert werden. Dies ist über eine neue Einstellung auf Ebene von Sammlungen möglich.

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

Wird ein neuer Objektdatensatz erstellt, der einer Sammlung mit aktivierter Bilderkennung zugeordnet ist, und zu dem ein Bild vorliegt, so wird dieses später automatisiert mit Vorschlägen aus der Bilderkennung angereichert.

Hierzu wird die reguläre Suchfunktion genutzt, um relevante Objekte und ihre primären Abbildungen zu identifizieren. Diese werden auf lokale Entwicklungs-Maschinen (PC mit Grafikkarte - aber aktuellen, besseren Consumer-Modellen) heruntergeladen und dort ausgewertet. Die so generierten Schlagworte werden auf den Schlagwort-Katalog gemappt und zurück zum Server geschickt.

Ist das einmal geschehen, erscheinen sie als Liste von Checkboxen in der rechten Seitenspalte des Schlagwort-Overlays.

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

Auswahl des Modells

Dadurch, dass homogenere und stärkere Hardware zur Verfügung steht, können auch größere Modelle eingesetzt werden. Für das neue Feature kommt dabei Joycaption zum Einsatz. Dieses stammt aus dem Umfeld der Open-Source-Bildgenerierung und wurde gezielt für das Beschreiben von Bildern erstellt. Es unterstützt dabei sowohl Prosa- als auch schlagwortartige Beschreibungen.

Ein wichtiger Vorteil des Modells ist, dass es unzensiert ist, während kommerzielle Modelle bei möglicherweise problematischen Inhalten zunehmend eingeschränkt sind. So werden zuverlässig auch z.B. Aktzeichnungen erkannt und beschrieben.

Schlagworte

Joycaption verschlagwortet teils spezifischer als wir das im Rahmen von museum-digital getan hätten. “Schwarzes T-Shirt” wäre etwa bisher nicht als Schlagwort zugelassen gewesen, ist aber im Sinne der Beschreibung visueller Elemente sinnvoll zuzulassen. “Schwarzes T-Shirt mit einem Ärmel” wäre allerdings sehr spezifisch. Um die Ausgaben des Modells mit dem Schlagwortkatalog zusammenzubringen haben wir also für ca. 20000 Objekte Beschriftungen erstellt und die daraus resultierenden ca. 6000 Schlagworte auf die bestehenden Vokabulare gemappt.

Wo es bisher keine Entsprechung gab (und der Begriff nicht grundsätzlich unerwünscht ist [“Ohne Menschen”]), wurde ein neues Schlagwort angelegt. Gerade bei Begriffen wie dem “schwarzen T-Shirt” sind die Begriffe denkbar einfach zu definieren: Ein T-Shirt, das Schwarz gefärbt ist. Entsprechend wurden die so neu eingerichteten Schlagworte automatisiert mit durch das LLM Gemma3 generierte Beschreibungen und deutsche Übersetzungen angereichert, die derzeit gesichtet und bereinigt werden. In diesem Arbeitsschritt werden auch überspezifische Begriffe wie “Schwarzes T-Shirt mit einem Ärmel” mit unspezifischeren Begriffen (“schwarzes T-Shirt”) zusammengeführt, sodass diese unspezifischeren Begriffe stabiler erkannt werden.

Workflows

Durch die nachgelagerte Arbeitsweise - erst Bildupload, dann warten, dann Verschlagwortung- macht der Einsatz der neuen Funktion besonders Sinn, wenn man institutionell einen arbeitsteiligen Workflow hat. Werden Objekte in einem Arbeitsgang von Inventarnummer bis Publikation erfasst, bietet das Tool wahrscheinlich wenig Mehrwert.

API: Wer kann berechnen?

Alle für die Bildklassifikation genutzten Abfragen auf dem Server sind, ebenso wie die Schnittstelle zum Eintragen der Ergebnisse der Klassifikation, auch über die API von musdb verfügbar.

Derzeit werden die API-Abfragen über die administrative Kommandozeile durchgeführt - eine Übersetzung hin zu einer Durchführung mithilfe der Webschnittstelle wäre aber ein leichtes und ist in der bestehenden Implementation schon mitgedacht. Hiermit könnten einzelne Museen die Berechnungen spezifisch für ihre eigenen Objekte durchführen und zeitlich unabhängiger agieren. Bei Interesse: Einfach schreiben. Der Aufwand hielte sich wie gesagt in Grenzen.

info

License

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

Stand der Entwicklung, Juni & Juli 2025

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

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

Die allgemeine Entwicklung dieses Jahr deutet auf weniger kleinere Entwicklungen in den Kernbereichen, aber dafür größeren / aufwendigeren einzelnen neuen Features. Siehe etwa die Versionierung in musdb aus dem Januar, das Tool zur Import-Automatisierung im März (andere nennen es Hotfolder), die Sortierung nach ästhetischem Score im öffentlichen Bereich, ebenfalls im März, oder die Funktion zur KI-gestützten Generierung von Objektbeschreibungen im Juni. Diese Tendenz setzt sich erst einmal fort.

Juli

Frontend

Übersetzung nach Hindi und Telugu
Untergruppierung von Schlagworten, falls mehr als 10 gesetzt sind
Die Beziehung in zwischen einem Objekt und seinen Schlagworten kann in musdb klassifiziert und spezifiziert werden. Mögliche Beziehungs-Typen sind etwa “Objektart”, “Material”, “Technik”, und “Abgebildetes”. Gerade bei “Abgebildetes” kann, bei entsprechenden Objekten und entsprechend ausführlicher Erfassung, eine hohe Menge von Schlagworten verknüpft werden. Um die Übersichtlichkeit zu wahren, werden die Schlagworte auf einer Objektseite nach ihrem Beziehungs-Typ gruppiert, sobald mehr als zehn Schlagworte mit dem Objekt verknüpft sind.

musdb

Neue Features

Export-Option für LIDO, wie es vom Koloniale Kontexte-Portal der Deutschen Digitalen Bibliothek erwartet wird

Verbesserungen & Änderungen

Mindestlänge für Volltextsuch-Begriffe sind jetzt in der Benutzeroberfläche (Suche verfeinern) sichtbar
Volltext-Suchbegriffe in musdb müssen, damit der Suchserver nicht überlastet wird, mindestens zwei Zeichen lang sein. Bisher wurden Suchparameter mit kürzeren “Suchbegriffen” schlicht ignoriert. Seit Juni ist ein Abschicken einer entsprechenden Abfrage über die erweiterte Suche nicht mehr möglich - dass zwei Zeichen das Mindestmaß sind, wird schon im Suchdialog kommuniziert.
Rezeptionsgeschichte: Angaben für Position in Quelle können jetzt bis 40 Zeichen lang sein
Transkriptionen
- können jetzt 4000000 Zeichen lang sein
- Neue Felder: Notiz, Status, Zielsetzung

Bugfixes

Fehler beim Stapelweisen verstecken von Feldern vom Reiter Zusatz korrigiert

Juni

Frontend

Performance-Verbesserungen
- Objekt-Suche kann ohne Verbindung zu Such-Server arbeiten (falls keine Volltextsuche durchgeführt werden soll)
- Suche nach Zeit und Zeit vor/nach ignoriert Zeit vor/nach, falls Zeitbegriff spezifischer ist
Verbesserungen beim Löschen von PDF-Dateien
Übersetzung: Tamil

musdb

Neue Features

Empfänger für Deakzession kann aus dem Adressbuch heraus verknüpft werden
KI-generierte Objektbeschreibungen auf Basis anderweitiger Metadaten

Verbesserungen

Objekt-Suche kann ohne Verbindung zu Such-Server arbeiten (falls keine Volltextsuche durchgeführt werden soll)

Importer

CSVXML-Parser ergänzt um
- neue Ereignistypen
- Markierungen
Automatisch generierte Objektgruppe für alle Objekte aus einem Import: Beschreibung kann festgelegt werden (per Settings)

nodac

Auswählbare (Navigations-)Sprachen sind jetzt auf die, in denen tatsächlich eine Übersetzung vorliegt, beschränkt

info

AI Use

Post image generated using AI.

info

License

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

Hindi

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

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

info

Image credits

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

info

License

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

తెలుగు

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

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

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

info

Image credits

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

info

License

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

Tamil

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

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

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

info

Image Credits

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

info

License

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

KI & Objektbeschreibungen

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

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

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

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

KI-generierte Beschreibungstexte

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

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

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

Gedanken

Drei Vorschläge

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

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

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

Das Generieren dauert lange!

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

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

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

Kooperation: Hardware & Auswertung

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

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

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, März 2025 & April 2025

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

Frontend

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

musdb

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

Importer

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

info

AI Use

Post image generated using AI.

info

License

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

Stand der Entwicklung, Mai 2025

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

Frontend

Neue Features

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

Verbesserungen

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

musdb

Neue Features

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

Verbesserungen

Panorama für Tour von Ausstellung / Institution wird jetzt auf 2400 px Höhe statt 1400 px heruntergerechnet
APIs zur Suche nach Einträgen in den kontrollierten Vokabularen sind jetzt über den zentralen API-Endpunkt verfügbar
Siehe z.B. <a href="https://de.handbook.museum-digital.info/musdb/API/index.html#/actor/actorSearchLinkedToObjects">/actor/search_linked_to_objects/{term}</a> , <a href="https://de.handbook.museum-digital.info/musdb/API/index.html#/actor/actorSearch">/actor/search/{term}</a> etc.

Bugfixes

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

Importer

Neue Features

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

Verbesserungen

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

Bugfixes

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

nodac

Neue Features

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

CSVXML

Verbesserungen

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

info

AI Use

Post image generated using AI.

info

License

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

Volltextsuche oder Buchstaben-Suche nach Inventarnummern in musdb?

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

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

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

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

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

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

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

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

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

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

In der Praxis:

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

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

Entgegen der Logik oder Umgang mit Unvollkommenheit

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

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

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

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

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

info

AI Use

Post image generated using AI.

info

License

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

Kannada

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

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

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

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

info

License

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

Stand der Entwicklung, Februar 2025

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

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

Frontend

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

musdb

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

Importer

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

Autouploader

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

info

AI Use

Post image generated using AI.

info

License

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

Das Importieren automatisieren

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

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

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

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

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

Importe selbst durchführen

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

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

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

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

Automatisieren

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

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

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

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

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

Code-Signing, Windows, Leiden

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

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

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

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

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

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

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

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

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

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

info

License

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

Stand der Entwicklung: Dezember 2024 und Januar 2025

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

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

Dezember 2024

Frontend

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

musdb

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

Januar 2025

Frontend

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

musdb

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

Importer

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

nodac

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

info

AI Use

Post image generated using AI.

info

License

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

Ein kleines Tool zur Konkordanzprüfung bei Importen

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

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

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

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

Ein kleines neues Tool

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

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

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

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

info

License

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

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

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

musdb

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

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

Frontend

Neue Implementation von getrennten Maßangaben ist auch hier umgesetzt

Import

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

nodac

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

info

AI Use

Post image generated using AI.

tip

tip

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

Versionierung & Transfer zwischen Datenfeldern

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

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

Versionierung

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

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

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

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

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

“Feldweise transferieren”

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

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

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

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

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

tip

tip

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

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

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

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

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

Frontend

Features & Verbesserungen

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

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

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

Bugfixes

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

musdb

Features & Verbesserungen

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

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

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

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

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

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

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

Bugfixes

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

Importer

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

files.museum-digital.org

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

info

AI Use

Post image generated using illustriousXL_smoothftSPO.

tip

tip

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

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.

Re-Design des Frontends - Version 2024

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

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

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

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

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

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

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

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

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

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

info

License

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

EODEM Version 1.0 veröffentlicht

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

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

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

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

info

License

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

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.

EODEM - Objektdaten bei Leihverkehren effizienter austauschen

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

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

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

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

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

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

Wie kann ich EODEM in musdb benutzen?

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

EODEM importieren

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

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

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

EODEM-Daten exportieren

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

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

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.

In musdb and darüber hinaus

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

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

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

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

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

info

License

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

Kommendes größeres Update in musdb

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

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

info

License

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

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

Referenzierbare Karten in der Ausgabe und in musdb

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

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

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

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

info

License

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

Archivalien zur Industriegeschichte digitalisieren und sichtbar machen

2022-06-23T00:00:00+00:00

Ein Beitrag des Museumsverbands des Landes Brandenburg e. V.

Das Land Brandenburg ist ein Land der Industriekultur. Zahlreiche Technik- und Industriemuseen, aber auch Stadt- und Regionalmuseen, erzählen in ihren Ausstellungen und museumspädagogischen Angeboten über die industrielle Entwicklung des Landes seit der zweiten Hälfte des 19. Jahrhunderts. Neben eindrucksvollen Denkmälern und Objekten, bewahren die Museen oft umfangreiche archivalische Bestände der brandenburgischen Industriegeschichte. Hierzu gehören Dokumente, Briefwechsel, Fotos, Konstruktionspläne, Brigadetagebücher, Filme, Töne usw..

Mehr als 6500 digitalisierte Archivalien

Eine erste zusammenfassende Übersicht zu den Beständen von 20 Museen gab der Museumsverband im Jahr 2012 heraus. Diese Übersicht bot einen ersten Einblick in die Vielfalt und den Umfang der Überlieferung, zeigte aber auch, dass die archivgerechte Ordnung und Strukturierung der Bestände, ihre sachgerechte Lagerung sowie ihre Erfassung noch in den Anfängen steckte. In den folgenden Jahren bemühten sich die Museen punktuell um eine Verbesserung der Lage. Damit die Archivalien aber langfristig erhalten, sichtbar und nutzbar sind, fehlt nach wie vor in vielen Museen die archivgerechte Ordnung, Strukturierung und digitale Erfassung der Bestände sowie eine flächendeckende Übersicht darüber, zu welchen Industriezweigen und Betrieben eine Überlieferung in den Museen vorhanden ist.

Das im Jahr 2021 vom Museumsverband Brandenburg durchgeführte Verbund-Digitalisierungs-Projekt „Industriearchive digitalisieren und sichtbar machen“ hat hierfür nun eine nachhaltige Basis geschaffen. An dem Projekt beteiligten sich 21 Museen. Es wurden über 6500 Archivalien digitalisiert sowie neue Features für die Erfassung, Präsentation und Datenweitergabe von Archivalien in museum-digital.de entwickelt und implementiert sowie eine Visualisierung der Archivalien mit dem Vikus-Viewer der FH-Potsdam veröffentlicht. Darüber hinaus fand für die Projektteilnehmer*innen ein Workshop zum Umgang mit Archivalien statt. Das Projekt wurde in enger Kooperation mit dem Berlin-Brandenburgischen Wirtschaftsarchiv und der Landesfachstelle für Archive und Öffentliche Bibliotheken Brandenburg durchgeführt.

Digitalisierung

Die archivalische Überlieferung zur brandenburgischen Industriegeschichte in den Museen ist sehr heterogen. Dies bezieht sich sowohl auf den Umfang als auch auf die Bestandsart, die von großformatige Plänen und Karten über Flyer und Kataloge, gebundenes Schriftgut wie Musterbücher, Betriebschroniken oder Brigadetagebücher, Fotografien, Betriebszeitschriften bis hin zu Videos und Tönen reicht. Ziel des Projekts war es, möglichst jede Bestandsart exemplarisch zu digitalisieren, was auch gelungen ist. Ein Schwerpunkt stellten dabei Karten und Pläne dar, die wegen ihrer meist großen Formate Museen bei der Digitalisierung vor Probleme stellen.

Technische Zeichnung, Stahlgittermast (Mast 17) auf dem Funkerberg Königs Wusterhausen, Sende und Funktechnikmuseum Königs Wusterhausen, CC BY-NC

1) Technische Zeichnung, Rückspiegel eines Motorollers, VEB Industriewerke Ludwigsfelde, Museum für Stadt und Techik Ludwigsfelde, CC BY-NC-SA; 2) Bauplan, Zweiflammrohrkessel, VEB Brauerei und Hefefabrik Pritzwalk, Museumsfabrik Pritzwalk, CC BY-NC

Die Digitalisierung wurde in der Regel über externe Fachfirmen organisiert. Zwei Museen realisierten die Digitalisierung hausintern. Bei der Patentpapierfabrik Hohenofen lagen bereits Digitalisate von teilweise stark beschädigten Plänen vor, deren Lesbarkeit durch die Schäden (dunkle Auflagerungen, Falzmarken, Deformationen und Verfärbungen) stark beeinträchtigt war. Exemplarisch wurde hier erprobt, wie solche Pläne digital wieder aufbereitet werden können.

Neue Funktionen in museum-digital

Die Plattform museum-digital.de hat sich inzwischen als der zentrale Präsentationsort von Kulturgut brandenburgischer Museen entwickelt. Immer mehr Museen entschließen sich außerdem dazu, museum-digital auch als Inventarisierungssoftware zu nutzen. Der Fokus der Plattform auf museale Objektbestände machte bisher die Erfassung und Präsentation archivalischer Bestände schwierig, vor allem wenn es um die Gliederung von Beständen (Tektonik), das Erfassen zusammenhängender Konvolute oder die Präsentation mehrseitigen Schriftguts ging. Im Zuge des Projekts konnte museum-digital in diese Richtung weiter ertüchtigt werden. Zum einen ist es nun mit der Hierarchisierung von Sammlungen möglich Tektoniken abzubilden. Eine neue Funktion ermöglicht das Verschlagworten von Sammlungen, womit eine museumsübergreifende Auflistung von Archivbeständen in einer Art Findbuch möglich ist.

“Findbuch” zur Industriegeschichte Brandenburgs auf museum-digital

Zum anderen wurde mit Mirador ein IIIF-Viewer implementiert, der das „Durchblättern“ mehrseitiger Dokumente wie z. B. Betriebszeitungen, Musterbücher, gebundene Betriebschroniken oder anderes mehrseitiges Schriftgut am Bildschirm wesentlich komfortabler macht.

Mirador-Viewer

Damit zukünftig Daten an das Archivportal-D weitergegeben werden können, können Daten aus museum-digital nun im passenden Format ausgegeben werde. Eine EAD-Schnittstelle folgt.

Visualisierung mit dem Vikus Viewer

Die Präsentation archivalischer Bestände erscheint auf Grund des meist unspektakulären Erscheinungsbilds der Archivalien wenig attraktiv. Mit dem vom UCLAB der FH-Potsdam entwickelten Vikus Viewer existiert seit 2018 eine Open Source-Lösung, die hier Abhilfe schafft. Ein Teil der im Projekt digitalisierten Bestände (550 Digitalisate) wurde mit dem Vikus Viewer visualisiert. Die chronologisch geordneten Archivalien lassen sich hier intuitiv nach Schlagworten (Orten, Industriezweigen, Bestandsart) filtern und das alles in sehr ansprechender Art und Weise.

Ausblick

Die Verbund-Digitalisierungsprojekte des Museumsverbands sollen Grundlagen für eine eigenständige Bestandsdigitalisierung in den Museen schaffen. Ein wesentliches Element des Industriearchive-Projekts war neben der exemplarischen Digitalisierung der Teilbestände die Erstellung der Gutachten zur Bestandsentwicklung, aus denen bereits erste neue Förderprojekte hervorgegangen sind. Die digitalisierten Bestände sind bei museum-digital erfasst und speisen bereits das digitale „Findbuch“ zur Industriegeschichte Brandenburgs auf museum-digital. Die Museen sind eingeladen, weitere zu diesem Thema gehörende Bestände zu digitalisieren und das Findbuch sukzessive zu erweitern. Auch der Vikus Viewer ist nicht als abgeschlossenes Projekt gedacht. Weitere Bestände können hier mit Unterstützung des Museumsverbands hochgeladen werden mit dem Ziel, einen repräsentativen Querschnitt über die Archivbestände zur Industriegeschichte in brandenburgischen Museen zu zeigen.

Der Blogbeitrag ist Teil der Reihe „Brandenburgische Museen digital“ und wird redaktionell vom Museumsverband des Landes Brandenburg e.V. betreut. www.museen-brandenburg.de/aktivitaeten/projekte/digitalisierung/

Objekte über die API von musdb verwalten

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

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

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

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

Ein Anfang: Objekte per API updaten

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

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

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

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

Nächste Schritte

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

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

info

License

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

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

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

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

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

info

License

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

Importe kann man jetzt selbst machen

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

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

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

Wie importieren?

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

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

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

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

Angekommen auf dem Netzwerklaufwerk: Importdaten hochladen

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

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

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

Importdaten hochladen

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

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

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

Den Import konfigurieren

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

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

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

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

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

Der Import findet statt

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

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

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

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

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

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

Der Importer besteht grundlegend aus vier Arten von Scripten:

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

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

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

Und für wen ist das sinnvoll?

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

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

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

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

info

License

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

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

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

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

Das Handbuch bei GitHub

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

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

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

Seitenspezifische Hilfelinks in musdb

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

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

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

Das neue Feld “Danksagung”

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

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

info

License

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

Was tun mit Bildern? Anschauen!

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

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

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

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

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

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

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

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

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

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

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

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

info

License

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

Standorte und mehr - Objektdaten per QR-Code updaten

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

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

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

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

Standorte per QR-Code eintragen, in musdb

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

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

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

Umsetzung

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

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

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

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

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

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

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

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

Danksagung

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

info

License

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

IIIF und museum-digital

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

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

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

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

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

Einschränkungen der IIIF-Umsetzung bei museum-digital

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

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

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

IIIF Collections

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

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

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

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

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

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

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

info

License

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

Ein neues Design für md:term

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

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

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

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

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

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

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

info

License

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

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

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

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

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

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

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

Neues Handbuch

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

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

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

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

info

Beitragsbild

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

info

License

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

Inventarisierungsdaten vom Sofa aus Verbessern: Verbesserungsvorschläge und Bilderkennung

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

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

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

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

Verbesserungsvorschläge

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

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

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

Der Vorschlag wurde akzeptiert

Und was schlägt musdb da vor?

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

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

Vorgeschlagene Ereignistypen nach Objektart

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

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

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

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

Bilderkennung

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

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

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

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

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

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

info

License

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

Ein neues Dashboard für musdb

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

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

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

Das neue Dashboard von musdb - Reiter “Kontrollierte Vokabulare”

Das neue Dashboard

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

Start

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

Datenbankinhalte des Hauses

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

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

Kontrollierte Vokabulare

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

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

Fragen an Daten

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

Online-Benutzung (auf Museumsebene)

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

Besucherstatistik

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

Letzte eigene Änderungen

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

(Öffentliche) Datenbankinhalte: Gesamte Instanz

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

Online-Benutzung

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

Werkzeuge

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

Mehr / Frage an

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

Fazit

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

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

info

License

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

Datenqualität bei der Erfassung von Personen

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

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

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

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

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

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

Schnelleres erscheinen der Personenliste

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

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

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

Besseres Erkennung von Vornamen und Nachnamen

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

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

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

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

Beschreibung? Wikipedia-Link!

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

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

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

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

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

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

info

License

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

Barrierefreiheit bei museum-digital

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

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

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

Prinzipien

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

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

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

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

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

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

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

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

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

Kontrastreiche Farbwahl und logische Anordnung der Elemente

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

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

API

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

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

Features

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

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

Landmarks

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

Tastensteuerung und Sprachsteuerung

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

Kontrolle ist besser

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

Bild: Chrome mit Lighthouse

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

info

License

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

PuQi - Verführung zu Qualität

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

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

Qualität

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

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

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

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

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

Rahmen

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

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

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

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

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

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

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

Publikation

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

Daraus ergibt sich folgende Tabelle:

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

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

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

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

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

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

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

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

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

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

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

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

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

Ermittlung

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Abwägung

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

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

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

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

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

Visualisierung

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

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

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

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

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

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

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

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

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

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

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

(Der PuQi in seinem Habitat - Beispiel)

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

Wirkung

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

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

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

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

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

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

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

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

Würdigung

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

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

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

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

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

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

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

⁴

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

⁵

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

⁶

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

⁷

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

⁸

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

⁹

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

¹⁰

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

"Schlauere" Eingabe von Vokabularbezügen

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

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

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

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

Erkennen von Ungewissheit und Zeiten in musdb

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

Eingabe einer Ortsangabe mit Indikator für Unsicherheit.

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

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

Eingabe einer ungewissen Zeit in normalisierbarer Form.

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

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

Leichteres Massen-Veröffentlichen und Verstecken von Objekten

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

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

info

License

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

Mehr Stabilität und einige neue Features

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

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

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

Markierungen

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

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

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

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

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

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

Referenzen und Rezeption

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

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

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

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

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

Ausfüllhilfe für Objektart

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

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

JSON-LD für Einzelbildseite

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

Google erkennt Lizenzangaben zu Bilddateien jetzt besser.

Ereignisse: Neue Ereignistypen und Quellenangaben für Ereignisse

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

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

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

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

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

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

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

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

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

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

info

License

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

Mehrsprachige Zeitbegriffe

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

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

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

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

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

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

info

License

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

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

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

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

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

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

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

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

OpenSearch implementieren

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

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

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

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

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

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

Links

info

License

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

Überarbeitete Login-Seite in musdb

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

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

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

Seitenbestandteile

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

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

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

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

Auf kleinen Bildschirmen

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

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

info

License

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

Abbildungen in musdb durchsuchen

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

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

Update (12.10.2020): Link aktualisiert.

info

License

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

Online-Ausstellungen erstellen mit md/story

2020-04-06T00:00:00+00:00

Digitale Ausstellungen haben in Zeiten der COVID-19-Pandemie Konjunktur. Aber auch sonst sind sie ein immer häufiger genutztes Mittel von Museen, die ihre Objekte virtuell in Szene setzen wollen. Eine einfache Möglichkeit, Ausstellungen für das Internet zu kuratieren, bietet das neue, kostenlose Ausstellungsmodul md/story. Das Modul fußt auf dem bereits etablierten Themenportal-Baukasten der Museumsplattform museum-digital, mit dem bereits eine Reihe Informationsportale zu historischen Themen entstanden sind. Das Modul md/story ist dafür optimiert, Ausstellungen nach dem Konzept des Scrollytellings zu erstellen. Das heißt, Nutzer*innen können sich in im Browser von oben nach unten durch eine Ausstellung scrollen. Entwickelt wurde das Modul in einem Projekt, an dem sich der Museumsverband Brandenburg, acht brandenburgische Museen sowie museum-digital beteiligten. Sichtbares Ergebnis dieser Kooperation ist die mit md/story erstellte Ausstellung „Kanope, Krokodil und Konigsstuhl. Globale Geschichten in brandenburgischen Museen“.

**Abwechslungsreiche Stories kreieren**

Das Format des Scrollytellings ist gut dazu geeignet, in einer digitalen Ausstellung eine zusammenhängende Geschichte zu erzählen, dabei fesselnde Spannungsbögen zu kreieren und damit bei den Besucher*innen Interesse für das Museum und seine Themen zu wecken – mit md/story übrigens mehrsprachig! Damit die Erzählung der Ausstellung abwechslungsreich gestaltet werden kann, lassen sich bei md/story eine Reihe verschiedener Visualisierungsmittel einbinden: natürlich digitale Objektbilder und Texte, aber auch Videos, Töne sowie horizontal drehbare - oder 3D-Ansichten von Objekten. Die Möglichkeit, Kapitel anzulegen, gibt einer Ausstellung eine Struktur, die auch über die seitlich eingeblendete Menüleiste visualisiert wird. Hiermit können die Nutzer*innen sich schnell und punktgenau durch die Ausstellung bewegen.

Karten, Zeitleisten und Co.

Eine Besonderheit von *md/story* ist die direkte Verbindung mit Funktionselementen von museum-digital. So lassen sich z.B. Karten mit Objektverteilungen oder Reiserouten von Personen sowie Zeitleisten zu ausgewählten Objekten in die Ausstellungen einbinden. Diese werden zunächst auf museum-digital angelegt und dann mit der Ausstellung verknüpft. Ein Beispiel hierfür ist [die Karte](https://themator.museum-digital.de/ausgabe/scrolltopic.php?m_tid=829&tid=829#topic832) in der Ausstellung „Kanope, Krokodil und Königsstuhl“, die die Route der Orientreise des Fürsten Herrmann zu Pückler-Muskau nachvollzieht. Die auf der Karte markierten Aufenthaltsorte Pücklers sind zum Teil mit Objekten verbunden, die er an diesen Orten erwarb.

Eintauchen in die Objektgeschichte

Neben der Präsentation von Objektbildern in der Ausstellung, lassen sich auch „Objektleisten“ in die Ausstellung integrieren, über die man vertiefend zur Objektanzeige von museum-digital gelangt. Ein Beispiel finden Sie hier. Mit einem Klick auf ein Objekt, stehen den Nutzer*innen dann viele weitere Informationen zum Exponat, mehrere Objektansichten sowie eine Lupe zur Betrachtung von Bilddetails zur Verfügung. Neu bei museum-digital ist die Funktion, Erklärtexte in die Objektbilder zu integrieren. Man markiert hierfür beim Erstellen der Ausstellung ein Teil des Objektbildes mit einem Rahmen und versieht diesen mit einem kurzen Text. Im Browser wird dieser Text angezeigt, wenn man mit dem Mauszeiger über den Rahmen fährt oder bei einem Touchscreen diesen antippt. Diese Funktion lässt sich ebenso über md/story einbinden, wie das Beispiel des Alexanderschlachtmosaiks in unserer Ausstellung zeigt.

**Mit dem Eingabetool alles in der eigenen Hand**

Der Aufbau der Ausstellungen erfolgt über das Eingabetool von md/story. Den Zugang zum Eingabebereich erhält ein Museum über museum-digital. Die Funktionen der verschiedenen Baukastenelemente des Tools sind selbsterklärend und machen das Kreieren einer Ausstellung einfach. Bei der Feinabstimmung in der Gestaltung steht der Support von museum-digital zur Verfügung. Für brandenburgische Museen ist hier die Geschäftsstelle des Museumsverbands Brandenburg Ansprechpartner. Anwender mit Grundkenntnissen in HTML oder CSS können aber auch selbst Hand anlegen.

Rückgaben des Resolvers anpassen

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

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

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

“Einfache” Beacon-(Konkordanz-)Listen

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

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

“No-Referral”: Text statt Weiterleitungen

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

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

info

License

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

Textbausteine in musdb verwenden

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

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

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

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

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

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

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

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

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

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

info

License

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

Alle Auswählen in der Objektauswahl in musdb

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

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

info

License

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

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

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

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

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

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

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

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

info

License

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

"Treffer auflisten"-Funktion verbessert

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

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

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

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

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

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

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

info

License

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

Mehrsprachigkeit in md:term

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

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

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

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

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

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

info

License

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

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.

museum-digital.org

2019-06-10T00:00:00+00:00

Bis zu dieser Woche gab es keine Seite, auf der museum-digital als ganzes vorgestellt wurde. Die deutsche Startseite, museum-digital.de, bot eine sehr grobe Einleitung in das, was wir tun und eine Übersicht über die verschiedenen Instanzen. Die Seite war zweisprachig in Deutsch und Englisch verfügbar, aber hätte aufgrund der Code-Struktur nicht ohne weiteres um weitere Sprachen erweitert werden können. Für museum-digital in Ungarn, MúzeumDigitár, gibt es eine eigene Seite, die jedoch auf die Aktivitäten in Ungarn fokussiert ist und entsprechend nur in ungarisch verfügbar ist.

Da wir schon vor einiger Zeit die Domain “museum-digital.org” gesichert hatten, bot es sich an, diese Lücke mit einer ausführlicheren Projektseite unter museum-digital.org zu schließen. Seit dieser Woche ist diese Projektseite online und öffentlich verfügbar. Zusätzlich zur Vorstellung des Projektes bietet die Seite ein paar Schmankerl, die sie auch für Leute, die mit dem Projekt gut vertraut sind, interessant machen sollten.

Startseite von museum-digital.org mit Karte aller teilnehmenden Museen.

Ein bisschen mehr als eine Vorstellungsseite

Der Hauptzweck von museum-digital.org ist es, die Arbeit bei museum-digital und die Tools, die wir über die Jahre entwickelt haben, vorzustellen. Darüber hinaus dient die Seite aber auch, verschiedene Aspekte und Instanzen von museum-digital zu verbinden.

Integration mit dem Blog

Regelmäßigen Lesern dieses Blogs mag es aufgefallen sein: Wir haben die Kategorien der Blogeinträge in den letzten Monaten vereinheitlicht und einige neue Kategorien (musdb, Ausgabe, etc.) eingeführt. Die neuesten Blogeinträge aus der passenden Kategorie können so unter der entsprechenden Seite auf museum-digital.org erscheinen. Gibt es etwa ein neues Feature in musdb, müssen wir dieses nur im Blog besprechen, damit es auch auf der Seite zu musdb auf museum-digital.org Erwähnung findet.

Damit diese Einträge immer ausreichend aktuell sind, wird der RSS-Feed der gegebenen Kategorie einmal am Tag automatisch ausgelesen.

Dashboard

Das Dashboard auf museum-digital.org zeigt wichtige Daten zur Entwicklung von museum-digital.

museum-digital.org bietet ein Dashboard, mit dem eine Übersicht über die Inhalte und den Status der deutschen und ungarischen Instanzen gefunden werden kann. Zahlen und Visualisierungen gibt es etwa zu:

Anzahl der öffentlichen Objekte, Museen, Sammlungen, Literatureinträge, etc.
Besucherentwicklung im letzten Monat
Angaben zur Qualität der Objekteinträge: Durchschnittlicher PuQi-Score aller öffentlichen Objekte, und durchschnittliche Länge der Objektbeschreibungen

Wie auch die “Graphennavigation” basieren die Visualisierungen im Dashboard auf der JavaScript-Bibliothek vis.js.

Gemeinsame Suche

Ein drittes besonderes Feature von museum-digital.org ist die integrierte Suche. Durch einen Klick auf das Lupen-Symbol in der Navigation aktiviert man die Suchfunktion. Im auffahrenden Overlay befinden sich neben dem Suchschlitz und dem (noch leeren) Resultatsbereich zwei Schalter: “museum-digital.org durchsuchen” und “Nach Objekten suchen”. Mit diesen kann der Suchmodus umgeschaltet werden.

Während die standardmäßig aktivierte Suche alle Inhalte von museum-digital.org - also v.a. die Beschreibungstexte durchsucht, sendet die Suche beim “Objekte durchsuchen” den Suchbegriff an die deutschlandweite und die ungarische Instanz und zeigt die Suchergebnisse aus beiden Instanzen untereinander im Ergebnisbereich an.

Auf APIs gebaut

Abseits der Beschreibungstexte und Bilder, werden die meisten Inhalte von museum-digital.org aus den APIs von unseren verschiedenen Tools und Seiten bezogen.

Die Karte aller teilnehmenden Museen auf der Startseite von museum-digital.org wird aus der JSON-Ausgabe der Institutionskarten der Ausgabe erstellt
Das Dashboard bezieht seine Daten aus der JSON-Ausgabe der Startseite der deutschen und ungarischen Instanzen
Die Suchfunktion von museum-digital.org basiert auf der API der Suche in der Ausgabe
Die thematischen Blog-Posts zu den einzelnen Seiten werden aus den entsprechenden RSS-Feeds des Blogs ausgelesen

Mit der API gebaut?

Apropos API: Die APIs der Ausgabe von museum-digital, und auch die von musdb, können nicht nur immer mehr. Sie werden auch immer mehr benutzt. Deshalb bietet museum-digital.org eine eigene Seite, auf der die öffentlichen, auf unseren APIs basierenden Tools vorgestellt und aufgelistet werden. Bisher sind dort zugegebenermaßen nur die von mir persönlich gebauten Tools zu finden, doch diese Liste dürfte bald wesentlich länger werden.

Liste von externen, auf der API basierenden, Tools.

Konsequente Mehrsprachigkeit

Die statischen Texte der meisten Tools von museum-digital sind konsequent mehrsprachig und werden über unser Übersetzungs-Tool kontrolliert. Ausgerechnet im Fall der deutschen Startseite (museum-digital.de) und des Handbuchs, also der beiden Seiten, die museum-digital.org wahrscheinlich am nächsten kommen, verhält es sich anders. museum-digital.de hat die Übersetzungen fest in die Seite einprogrammiert, sodass sie nicht ohne weiteres zu ändern sind. Das Handbuch wiederum ist mehrsprachig wie Wikipedia: Artikel können in allen Sprachen verfasst werden (oder auch nicht) und müssen dann im Nachhineineinander verknüpft werden. Das hat dazu geführt, dass die deutschen und ungarischen Handbuchseiten sehr unterschiedlich strukturiert sind (und entsprechend nicht sinnvoll miteinander verlinkt werden konnten) und die englisch-sprachige Version des Handbuchs noch fast leer ist.

Für eine Seite, die zwar mehrsprachig, aber doch einheitlich strukturiert und gestaltet sein sollte, hat es sich also, zumindest für Projekte im Rahmen von museum-digital, als besser erwiesen, die gleiche Vorgehensweise wie bei der Übersetzung der Ausgabe oder von musdb zu wählen. Die Struktur der verschiedenen Seiten ist fest geschrieben, aber die Texte selbst werden über das Übersetzungstool geschrieben. So müssen die Übersetzer nur die Texte übersetzen, können aber auf die Struktur keinen Einfluss nehmen.

Bisher ist auch museum-digital.org “nur” auf Deutsch und Englisch verfügbar. Weitere Sprachversionen hinzuzufügen stellt aber zumindest auf technischer Ebene kein Problem mehr dar.

Was kann da noch kommen?

museum-digital.org, wie wir es jetzt veröffentlichen, hat einige entscheidende Unterschiede zur Projektseite, wie sie am Anfang der Planung konzeptioniert war. Während beispielsweise die integrierte Suchfunktion über die verschiedenen Instanzen als “nice-to-have” maximal angedacht war und jetzt schon bei der Veröffentlichung dabei ist, fehlen noch einige der ursprünglich angedachten Seiten und Inhalte.

Eine Liste vergleichbarer Projekte und anderer relevanten Seiten zum Thema (etwa digitaltmuseum.no)
Die Landesmuseumsverbände, die einen großen Beitrag zum Entstehen von museum-digital beigetragen haben und beitragen, sollten vlt. noch klarer gewürdigt werden
Im Dashboard steht bisher der 29.02.2009 als Gründungsdatum. Im Laufe des Schreibens haben wir mehrere widersprüchliche Daten gefunden. Allen gemein ist, dass sie im ersten Halbjahr 2009 waren. Der konkrete Tag wäre aber noch in Erfahrung zu bringen.
Auf der Seite “Veröffentlichungen” haben wir eine Bibliographie zu museum-digital begonnen. Diese ist leider noch sehr unvollständig.

Anregungen und Hinweise zur Verbesserung von museum-digital.org sind herzlich willkommen!

Update (10.06.2019): Bilder und einige Ergänzungen im letzten Absatz eingefügt

info

License

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

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.

museum-digital übersetzen

2019-03-02T00:00:00+00:00

In nächster Zeit wird die Ausgabe von museum-digital vorraussichtlich in einige zusätzliche Sprachen übersetzt. Aus diesem Anlass möchte ich hier den Prozess des Übersetzens von museum-digital vorstellen.

Die Übersetzungen müssen derzeit an mehreren Stellen geschehen. Für alle Textstücke, die im serverseitig ablaufenden Code verwendet werden, haben wir ein eigenes Übersetzungstool. Zusätzlich gibt es (weniger) Übersetzungsvariablen, die in JavaScript-Dateien verwendet werden, die im Browser des Seitenbenutzers ausgeführt werden. Diese müssen noch direkt im JSON-Format bearbeitet werden.

Das Übersetzungstool

Zum Beginn des Übersetzens erhält jeder Übersetzer einen Account in unserem Übersetzungstool. Mit diesem Account sind dem Nutzer zwei Sprachen zugeordnet: Einerseits die Ausgangssprache, aus der heraus übersetzt wird, und andererseits die Zielsprache, in die Übersetzt wird.

Tabelle, in der die Übersetzungen bei museum-digital stattfinden.

Nach dem Einloggen erreicht man zuerst eine Übersicht der übersetzbaren Dateien, in Kacheln gruppiert nach ihrem Anwendungsfeld (“Backend”, “Frontend”). Jede Kachel enthält eine Liste von Dateinamen. Durch einen Klick auf einen dieser erhält man die Möglichkeit, die jeweilige Datei in einer Tabelle zu bearbeiten. Die Dateien sind dabei grob ihrem Anwendungszweck nach benannt: home.json im Bereich “Frontend” enthält Variablen, die auf der Startseite der Ausgabe von museum-digital verwendet werden.

Die Tabellen in denen nun eine Datei übersetzt wird sind immer gleich aufgebaut. In der linken Spalte steht der Name der jeweiligen Übersetzungsvariable. In der Mittigen steht der Inhalt der Variable in der Ausgangssprache. Rechts befindet sich ein Textfeld, in das die Übersetzung eingetragen werden kann. Direkt unter der Tabelle befindet sich ein “Save”-Button, mit dem die Übersetzungen dann auch final eingetragen sind.

Meine Übersetzungen sind nicht gleich sichtbar?

Screenshot des “Freischalt-Bereichs” für Administratoren im Übersetzungstool von museum-digital. Im unteren Bereich findet sich der Überblick über den Status der Übersetzungen, erstellt mithilfe von git.

Übersetzungen, die so gemacht wurden, sind nicht sofort sichtbar. Weil die Übersetzungsdateien auch HTML-Markup enthalten können, das falsch geschrieben die Darstellung der Seite stören könnte, haben wir eine Überprüfungsphase zwischengeschaltet.

Sind einige Dateien übersetzt, gibt der oder die Übersetzende einem Administrator bescheid. Dieser kann die neuen Übersetzungen dann in einem gesonderten Administrationsbereich freischalten. Technisch gesehen bedeutet das, dass die .json-Dateien in .php-Dateien überführt werden, die dann direkt durch das Programm aufgeführt werden können. Um einen Überblick über die Änderungen zu erhalten, werden diese dem Administrator im “Freischalt-Bereich” angezeigt.

Weitere Übersetzungen

Nach der Übersetzung mit unserem Übersetzungstool verbleiben einige Textstücke, die in browserseitig ausgeführtem Code verwendet werden. In diesem verwenden wir eine andere Struktur für das Laden der Übersetzungen: Statt immer nur die Sprache zu laden, die gerade benötigt wird, werden immer alle verfügbaren Sprachvarianten geladen. Statt in eigenen Dateien befinden sich die Übersetzungen in demselben Script, wie der Code, der sie verwendet. Deshalb können diese Textstücke bisher noch nicht mit dem Übersetzungstool übersetzt werden. Stattdessen müssen diese direkt im Code übersetzt werden.

Damit dies geschehen kann, sendet ein Administrator den Übersetzenden die jeweiligen Code-Schnipsel per Mail zu, in die die Übersetzung eingetragen werden muss. Nachdem diese zurückgeschickt und in den Code eingefügt wurden, ist die Übersetzung beendet.

info

License

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

md:term

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

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

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

Kontrollierte Vokabulare bei Museum-Digital

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

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

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

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

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

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

md:term

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

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

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

Daten von md:term abfragen

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

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

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

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

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

Screenshot aus md:term. Zeigt eine Ortsansicht.

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

info

License

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

Logos, Logos, Logos

2018-10-26T00:00:00+00:00

Anfang dieser Woche haben wir, wie einige Leser schon gesehen haben könnten, die Logos der internationalen Instanzen von museum-digital und das Logo, das im Handbuch angezeigt wird, angepasst.

Der Grund dafür ist simpel. Bisher gab es ein “Grund-logo”, das auf allen Instanzen benutzt wurde. Die einzigen Ausnahmen stellten das “bunte” Logo der deutschlandweiten Instanz und das Logo der Ungarischen dar. Regional strukturiert wie die Instanzen waren somit auch die Logos, was dazu führte, dass es kein Logo für museum-digital als übergreifendes Projekt gab (bisher hatten wir für diesen Zweck immer das Logo für die deutschlandweite Instanz benutzt, aber auch das ist ja eine starke regionale Eingrenzung). Das Logo für museum-digital findet zunächst seinen Platz im Handbuch.

Als zweiter Schritt wurde ein eigenes Logo für die internationalen Instanzen (abseits der Ungarischen) hinzugefügt. So wie die regionalen Instanzen in Deutschland dasselbe Logo mit verschiedenen Farben haben, haben auch die internationalen Instanzen ein in ihrer jeweiligen Farbe gefärbtes Logo. Das Logo ist nur leicht von dem bisherigen abgewandelt.

Die Logos können als Vektorgrafiken (unter CC-BY lizensiert) im Handbuch heruntergeladen werden.

info

License

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

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 und die Tastatur

2017-12-03T00:00:00+00:00

Eine kurze, aber erfreuliche Nachricht: Wir haben begonnen, an der Navigierbarkeit von museum-digital rein mit der Tastatur zu arbeiten. Auch wenn dies eher ein kleines Liebhaberprojekt sein mag, dürfte es gerade für die, die häufig mit museum-digital arbeiten eine willkommene Erleichterung sein.

Tastenkombinationen

Drückt man F1 während man auf einer der Instanzen von museum-digital surft, erscheint folgende Übersicht:

Left / Right

Previous / next image (only on image pages)

CTRL+Left / CTRL+Right

Previous / Next page (available on all paginated or ordered pages)

CTRL+I

Open image viewer (on object page)

CTRL+Y

Focus search for objects

CTRL+E / CTRL+R

Toggle overlay for searching for museums / collections

CTRL+0

Return to home page

CTRL+1 - CTRL+9

Open the first, second … entry in list (museum overview, collection overview)

F1

Show this help overlay

Der Hilfetext ist bisher in Englisch und wird in nächster Zeit wahrscheinlich noch nicht übersetzt werden, aber die kurzen Erläuterungen sollten trotzdem verständlich sein.

Mit den Cursortasten kann zwischen Bildansichten navigiert werden. Mit Cursortasten und gedrückter Steuerungstaste navigiert man generell zur nächten oder vorherigen Seite bei geordneten Seiten. Dazu gehören Suchergebnisse, aber auch die Museums- und Sammlungsübersichten. Auf Such- und Übersichtsseiten kann des weiteren mit der Steuerungstaste und den Zahlen 1-9 zum entsprechenden Eintrag der Liste navigiert werden.

Die andere Kategorie der bisher eingebauten Tastenkombinationen stellen solche dar, mit denen man einen schnellen Zugriff auf Suchfunktionen hat. Mit STRG+Y wird der Suchschlitz für Objekte, oben auf der Seite, fokussiert. Mit STRG+E und STRG+R haben Benutzer einen Schnellzugriff auf die Suche nach Museen bzw. Sammlungen.

Warum die Steuerungstaste

Wichtig beim Setzen der Tastenbelegungen war uns, dass möglichst wenige der Tasten unerwartet gedrückt werden und das unbedarfte Benutzer nicht überrascht werden. Deshalb sind außer für den speziellen Fall von Abbildungsseiten - dort sollte eine Navigierbarkeit per Cursortasten intuitiv verstehbar sein - und F1, das so oder so nicht häufig aus Versehen gedrückt wird, alle Tastaturbelegungen mit der Steuerungstaste verbunden.

Zusätzlich waren wir bemüht, im Browser gesetzte Tastenkombinationen nicht zu überschreiben. Daher kommt die etwas unintuitive Belegung von STRG+Y mit dem Fokussieren der Suche.

Ein erster Schritt

Das alles kann nur als erster Schritt bezeichnet werden. Aber nun, da der Code für spezifische Tastenbelegungen einmal da ist, ist es relativ leicht, neue hinzuzufügen. Also: Falls es Vorschläge für weitere, sinnvolle Ergänzungen gibt, sind Mails immer willkommen!

Das gilt bedingt auch für die Eingabeseite von museum-digital. Hier ist bisher nur das Navigieren zwischen den Bearbeitungsseiten für Objekte per STRG+Links und STRG+Rechts möglich. Mehr folgt bei Bedarf.

Zuerst erschienen auf jrenslin.de

info

License

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

museum-digital in neuem Gewand

2015-10-01T00:00:00+00:00

Teile von museum-digital wurden gründlich umgestaltet: Die Startseite und die zentrale Datenbank. Neben längst fälligen “optischen” Verbesserungen (größere Schrift vor allem) wurden einige Texte an die aktuelle Situation angepasst - mit den Jahren ändert sich ja doch so manches. Insbesondere aber wurden Startseite und zentrale Datenbank “responsive” gestaltet, d.h. sind jetzt ebenso auf Smartphones und Tabletts gut lesbar, wie auch auf Laptops und Tischrechnern.

Falamos Português - Bahasa Indonesia

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

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

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

museum-digital wird mehrsprachig

2015-02-25T00:00:00+00:00

In fast allen Versionen von museum-digital ist es jetzt möglich eine von mehreren Sprachvarianten auszuwählen. Die Sprachumstellungen betreffen die Erläuterungs- und Erklärungstexte - die inhaltlichen Angaben, Beschreibungen von Objekten zum Beispiel, werden nicht übersetzt. Die jetzt vorhanden Übersetzungen in Englisch, Italienisch, Ungarisch, Polnisch und Bahasa Indonesia haben Freunde von museum-digital, zumeist MuttersprachlerInnen erstellt. Danke dafür.

Der Sprachwahlschalter ist immer in der oberen Navigationsleiste rechts zu finden. Weitere Übersetzungen sind geplant.

Normdaten: "Grobsystematik" online verwendbar

2013-01-03T00:00:00+00:00

Nach der sog. “Möbeltypologie” und dem “Thesaurus zu Ackerbaugeräten …” ist jetzt auch die sog. “Grobsystematik” bei museum-digital online für jeden nutzbar gemacht worden. Wie die anderen Vokabulare kann auch diese über die rechte Spalte der Startseite von museum-digital.de aufgerufen werden (oder: hier). … Die “Grobsystematik” mit dem Untertitel ““EDV-gestützte Bestandserschließung in kleinen und mittleren Museen” teilt auf oberster Ebene die ca. 9000 enthaltenen Begriffe (Konzepte) in 62 separate Sachgruppen (Themen) - eine etwas andere Navigation war daher nötig.

Normdaten bei museum-digital

2012-12-22T00:00:00+00:00

Der neuer Menupunkt “Vokabulare” erläutert, wie bei museum-digital mit Normdaten umgegangen wird. Insbesondere in Zeiten von “Linked Data” und “Sematic Web” ist es wichtig die vorhandenen Objektinformationen mit Begriffen aus kontrollierten und allgemein zugänglichen Vokabularien zu verknüpfen und diese Verknüpfungen bei der Weitergabe der Informationen an Portale (Fachportale, europeana, ddb, …) zu berücksichtigen. Viele in Museen verwendete Vokabularien stehen jedoch noch nicht in geeigneter Form zur Verfügung! Für die Verwendung innerhalb von museum-digital (Inventarisierung und Suchfunktion) - und zugleich als allgemein nutzbare Referenz im Web - werden, wo nötig, solche Vokabularien jetzt bei museum-digital in leicht referenzierbarer Form publiziert.

Den Anfang macht die, wenig umfangreiche, sogenannte “Möbeltypologie” (ursprünglich herausgegeben vom Westfälischen Museumsamt und der Landesstelle für die nichtstaatlichen Museen Bayerns). Ausgangspunkt ist die überarbeitete Fassung, die bei www.museumsvokabular.de als PDF und als zusammengefasste XML-Datei verfügbar ist (unter Creative Commons-Lizenz). Museum-Digital ergänzt dieses Angebot durch eine navigierbare HTML-Darstellung in der jeder Begriff (Konzept) eine eigene offene URL erhält (hier). Die über eine Schnittstelle (API) zur Verfügung gestellte und auf den Seiten jeweils abrufbare SKOS-Datei ermöglicht die leichte Einbindung der Möbeltypologie in “Semantic Web”-Projekte - und eben auch in museum-digital selbst. Die Begriffe (Konzepte) der Möbeltypologie sind bereits weitgehend mit den passenden Konzepten bei museum-digital verlinkt (hier).

Library of Congress Subject Headings - 1000 sind "gemappt"

2012-12-17T00:00:00+00:00

Das “mapping” der Schlagworte von museum-digital schreitet voran. Jetzt sind schon für 1.000 Schlagworte aus museum-digital die Entsprechungen im Schlagwortkatalog der Library of Congress gefunden worden. Es zeigt sich, dass es für viele Begriffe der deutschen Sprache keine wirkliche 1:1 Entsprechung im (us-amerikanischen) Englisch gibt und dass es oft überhaupt nicht einfach ist den wirklich passenden unter den Begriffen des fremdsprachigen Kataloges zu finden.

Schon wenn sich zwei Personen auf Deutsch unterhalten kommt es häufig zu Mißverständnissen, weil Begriffe verschieden verstanden werden - im mehrsprachigen Kontext ist die Gefahr von Fehlinterpretationen um einiges größer! Soweit die bisherigen Erfahrungen …

Library of Congress Subject Headings - die ersten 500 sind "gemappt"

2012-12-10T00:00:00+00:00

Bei museum-digital wird zur Zeit an der Anreicherung kontrollierter Begriffe gearbeitet. Personen-, Zeit- und Ortsangaben werden mit sogenannten Normdaten verknüpft - ebenso die knapp 8000 Schlagworte. Die Schlagworte werden nach und nach mit der Gemeinsamen Normdatei der Bibliotheken (GND) und anderen Fachspezifischen Normvokabularen (wie z.B. mindat.org) verknüpft und zudem mit einer Erklärung und - wo möglich - mit einem Link zum passenden Wikipedia-Eintrag versehen. Zudem werden die Begriffe in eine streng polyhierarchische Ordnung gebracht und nach den üblichen Thesaurusregeln miteinander in Beziehung gesetzt. Sie stehen überdies jederzeit im SKOS- und JSON-Format zur Verfügung.

Die Verknüpfung mit Normvokabular macht natürlich auch beim Überspringen von Sprachgrenzen sehr viel Sinn. Die ersten 500 Begriffe aus dem museum-digital-Schlagwortkatalog wurden jetzt mit den entsprechenden Begriffen aus den “Library of Congress Subject Headings” und dem “Thesaurus of Graphic Materials” - den weltweit wohl bedeutendsten Begriffsverzeichnissen - verknüpft. Damit werden Objektinformationen, welche Museen aus museum-digital heraus an Portale geben um vieles wertvoller - vorausgesetzt, die Portale können mit diesen “Linked Data” etwas anfangen

LIDO I

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

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

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

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

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

Deutsches Schuhmuseum Hauenstein: Objekte mit museum-digital auf Museumswebseite

2012-06-26T00:00:00+00:00

Auch in die Webseite des Deutschen Schuhmuseums in Hauenstein (hier) ist nunmehr museum-digital:rheinland-pfalz eingebunden. In der Navigation der Seite findet sich ein Punkt “Digitales Museum” über den man direkt die Objekte des Museums erreichen kann (hier). Im erscheinen Fenster wird auch eine “Sammlungsübersicht” zugänglich. Hierüber kann man unter anderem zur Sammlung chinesischer “Gin Lien-Schuhe” gelangen.

Museum Pankow - Neue Ausstellung mit museum-digital verknüpft

2012-06-18T00:00:00+00:00

Gestern wurde im Museum Pankow eine neue Sonderausstellung eröffnet. Die Ausstellung trägt den Titel “Dinge des Lebens - Objekte aus den Sammlungen Pankow, Prenzlauer Berg und Weißensee”, sie läuft bis zum 7. April 2013. Gezeigt werden Dinge, die schlaglichtartig die Geschichte des heutigen Großbezirks und seiner Teile beleuchten. Das Museum Pankow hat museum-digital in die Konzeption und Gestaltung der Ausstellung eingebunden. Bereits das Plakat zur Ausstellung enthält einen QR-Code, welcher auf die Seiten des Museums bei museum-digital:berlin führt. Etliche der ausgestellten Objekte sind mit einem ebensolchen Code versehen - wer mit einem Smartphone durch die Ausstellung geht, kann sich auf diese Weise direkt die entsprechenden Objektinformationen von museum-digital:berlin holen.

Die Beschriftungen der einzelnen ausgestellten Objekte bestehen - auch aus Platzgründen - ausschließlich aus einer Nummer. Auf vier Terminals läuft eine Offline-Version von museum-digital - reduziert auf das Museum Pankow und die ausgestellten Objekte. Wählt ein Besucher hier die entsprechende Nummer so erhält er die zum jeweiligen Objekt erfassten zum Teil sehr ausführlichen Hintergrundinformationen und Querverweise auf andere Objekte. Die Informationen sind jeweils identisch mit jenen der Online-Version. Eine Vor- oder Nachbereitung des Ausstellungsbesuches ist auf diese Weise leicht möglich.

Es wurde sehr darauf geachtet, ein leicht zu bedienendes und zu verstehendes Objekt-Informationssystem zu entwickeln. Das scheint geklappt zu haben - die Besucher der Ausstellungseröffnung jedenfalls sind sofort und ohne weitere Erläuterungen damit zurecht gekommen.

Noch ein Wort zu den QR-Codes: Es hat sich gezeigt, dass die Lesbarkeit der QR-Codes vor allem von den Lichtverhältnissen und der Abbildungsgröße des Codes abhängt. Bei schlechten Lichtverhältnissen sollten die Codes größer sein. Dies führt an einigen Stellen dazu, dass die Codes größer sein müssten als die Objekte! Weil aber die Objekte und nicht die Codes im Zentrum der Ausstellung stehen wurde in diesen Fällen auf das Anbringen der Codes verzichtet.

Auch Fahrzeugmuseum Glöthe zeigt jetzt Objekte aus museum-digital auf eigener Seite

2012-04-13T00:00:00+00:00

Auch auf der Internet-Seite des Fahrzeugmuseums in Glöthe (Sachsen-Anhalt) sind jetzt die Objekte des Museums direkt aus museum-digital abrufbar gemacht. Es bleibt ja jedem Museum überlassen, wie und wo es die Darstellung seiner Objekte einbindet. Beim Fahrzeugmuseum hat man sich entschieden in die bereits bestehende Rubrik “Bilder” einen neuen Punkt zu integrieren: “Sammlung auf museum-digital”. Die Möglichkeiten für Museen die eigenen Objekte aus museum-digital in die eigene Seite einzubinden wurden weiter verfeinert. Auf den Museumsseiten kann jetzt nicht mehr nur ein Suchschlitz erscheinen sondern daneben auch ein Schalter “Sammlungsübersicht”. Über diesen Schalter sind auch die Sammlungsbeschreibungen aus museum-digital in die Webseite des jeweiligen Museums integrierbar.

Schloss Wernigerode, Objekte aus museum-digital auf Museumsseite

2012-04-04T00:00:00+00:00

Jetzt nutzt auch das Museum Schloss Wernigerode die Möglichkeit seine eigenen Objekte, die bei museum-digital veröffentlicht sind, automatisch auf der hauseigenen Internetseite zu zeigen. Seit wenigen Tagen ist unter www.schloss-wernigerode.de in der linken Spalte (Sektion: “Schloß”) der Menupunkt “Sammlungen” zu finden. Klickt man hierauf, so erscheinen die Objekte aus museum-digital (Direktlink). Die hier gewählte Einbindung über “iframe” ist besonders leicht zu realisieren.

Objektangaben aus "Primus" können jetzt direkt importiert werden

2012-03-06T00:00:00+00:00

Die Import-Möglichkeiten bei museum-digital wurden weiter verbessert. Bisher war es möglich Informationen zu Museumsobjekten aus Excel-Tabellen und aus den Inventarisierungs-Programmen “Adlib”, “MuseumPlus” und “Faust” zu importiert. Jetzt ist auch der Import direkt aus der neuen Version des Programmes “Primus” möglich.

Kreismuseum Bitterfeld: Objekte aus museum-digital auf eigener Seite

2012-02-17T00:00:00+00:00

Ein weiteres Museum nutzt seit kurzem die Möglichkeit seine bei museum-digital publizierten Objektinformationen in den eigenen Internetauftritt zu integrieren. Das Kreismuseum Bitterfeld hat seine Internetpräsenz neu gestaltet (hier) und einen Menupunkt “Objekte” eingeführt. Die hierdurch aufgerufenen Seiten entstehen automatisch bei museum-digital. Durch Klick auf “Home” in der Kopfzeile kommt man jederzeit zurück zu den anderen Seiten des Kreismuseums. Die neuesten Einträge des Museums sind historische Gesangbücher aus dem 18. Jahrhundert. Einmal bei museum-digital:sachsen-anhalt eingetragen sind sie sofort dort und auf den Seiten des Kreismuseums zugänglich. Einfacher geht es nicht.

museum-digital und Händelhaus. Praxisbericht erschienen

2011-12-18T00:00:00+00:00

Die neueste Ausgabe der Fachzeitschrift “Forum Musikbibliothek - Beiträge und Informationen aus der musikbibliothekarischen Praxis” (32. Jahrgang, 2011/3, Seite 240-247) enthält einen Praxisbericht über die Digitalisierung und Veröffentlichung wertvoller Notendrucke der Stiftung Händel-Haus in Halle/Saale. Der Bericht trägt den Titel “Die digitale Sammlung früher Händel-Notendrucke der Stiftung Händel-Haus und ihre Internetpräsentation über die Museumsplattform Museum-digital”. Der Artikel berichtet in Abschnitten über: 1. Die Sammlung, 2. Erstellung der Digitalisate, 3. Technik: Museum-digital, 4. Import nach Museum-digital und Metadaten, 5. Perspektiven und Fazit. Leider ist der Bericht nicht online verfügbar. Die Notendrucke sind auf den Seiten des Händel-Hauses und bei museum-digital zu finden.

museum-digital goes QR

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

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

Kleinigkeit ... (Literaturangaben zu Museumsobjekten)

2011-05-22T00:00:00+00:00

Eigentlich eine Kleinigkeit und kaum berichtenswert … aber: Die Literaturangaben zu den einzelnen Museumsobjekten bei museum-digital sind jetzt weitgehend überarbeitet und inhaltlich korrigiert worden. In der Ausgabeansicht erscheinen sie jetzt in alphabethischer Reihenfolge, wie es sich gehört …

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: ... goes facebook and twitter ...

2010-10-06T00:00:00+00:00

Seit kurzem erscheinen die bei museum-digital veröffentlichten Objektinformationen auch bei facebook (hier) und twitter (hier). Erste Gehversuche … Für die Besucher von Seiten einer museum-digital - Version wurde jeweils in der Fußzeile ein “Weitersagen”-Schalter eingebaut. So kann jeder, der möchte, ganz einfach ein Suchergebnis oder Informationen zu einem Objekt twittern oder an seine “Freunde” bei facebook weitergeben.

museum-digital: ... ein Stück vollständiger

2010-09-26T00:00:00+00:00

Bei museum-digital stehen (Museums-) Objekte im Vordergrund - in Text und Bild. Für manche Objekte ist es ratsam mehr als nur ein einzelnes Bild zur Verfügung zu stellen (Die Zahl der Fotografien pro Objekt ist bei museum-digital nicht begrenzt). Andere Objekte, insbesondere Briefe, Handschriften, Verträge und gedruckte Sachen lassen sich häufig nur mit mehreren Abbildungen vollständig darstellen. Hier kommt hinzu, dass diese Abbildungen in einer vorgegebenen Reihenfolge stehen (Seite 4 kommt z.B. normalerweise vor Seite 5).

Es war und ist kein Problem, sich solche Objekte bei museum-digital in Form von sinnvoll aneinandergereihten Bildern anzeigen zu lassen. Weil dies aber nur eine Reihe von Bildern war, mußte für den Download, beispielsweise eines mehrseiten Briefes, jedes Bild (Seite) einzeln heruntergeladen werden. Seit heute steht eine Download-Möglichkeit per PDF zur Verfügung. Damit lassen sich alle Ansichten zu einem Objekt in einer einzigen Datei speichern. Die erste Seite enthält stets die Objektbezeichnung, den Namen des entsprechenden Museums und den beschreibenden Text zum Objekt. Diese PDF-Dateien werden “on-the-fly” erstellt, weshalb sie immer aktuell sind. Sobald jemand durch Klick auf eines der Fotos in der Objektanzeige (Beispiel: hier) klickt, gelangt er zu den großen Ansichten (Beispiel: hier). An dieser Stelle erscheint auch das PDF-Symbol (im Beispiel: oben links). Ein Klick darauf …

museum-digital: Wieder ein Stück flexibler

2010-09-25T00:00:00+00:00

Die bei museum-digital:sachsen-anhalt schon testweise umgesetzte automatische Anpassung der Abbildungsgrößen an die Bildschirmfenstergrößen ist jetzt in allen Ausspielungen von museum-digital verfügbar. Auf diese Weise kann jeder, auch wenn er einen kleinen Bildschirm (oder ein kleines Bildschirmfenster) verwendet, um bei museum-digital zu schmökern, nach einem Klick auf eine Objektansicht (auf der Objektanzeigeseite) ein angepasstes großes Bild des entsprechenden Objektes erhalten. So kann man immer das Objekt als Ganzes sehen, egal wie groß das Bild ist - vorausgesetzt, auf dem Bild ist auch das ganze Objekt zu sehen. Durch Klick auf einen Schalter läßt sich das Bild in größtmöglicher Form und unabhängig von der Bildschirm- (oder Fenster-) größe anzeigen.

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.

Erste Kartenansichten bei museum-digital

2010-01-25T00:00:00+00:00

Nicht jeder kennt jeden Ort und mancher interessiert sich dafür, wo etwas geschah. Bei museum-digital sind jetzt die Orte zu Objekt-Ereignissen [z.B. Ort des Herstellens, Ort des Zeichnens, …] auf einer Karte abrufbar. Hinter der Anzeige der jeweiligen Ortsbezeichnung erscheint (jedenfalls für Orte in Deutschland) der Link zu einer Kartenansicht. Ein Klick darauf öffnet ein Fenster (Dank an highslide JS) in dem sich eine Karte (Dank an OpenStreetMap) mit dem jeweiligen Ort in der Mitte befindet.

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.

Normdaten der D-NB bei museum-digital::sachsen-anhalt

2009-09-27T00:00:00+00:00

Seit heute gibt es bei museum-digital:sachsen-anhalt zu “Akteuren”, d.h. Herstellern, Malern, Sammlern … von Objekten - soweit vorhanden die entsprechenden Personendaten der Deutschen Nationalbibliothek per Klick hinter dem Namen. Hier werden andere Schreibweisen des Namens, Lebensdaten und z.B. auch Bücher über die jeweilige Person aufgelistet. Zudem gibt es jetzt Internetlinks zu Akteuren. Ein Beispiel findet sich hier.

Verbesserte Anzeigekontrolle

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

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

Neue Suchmöglichkeit eingerichtet

2009-07-05T00:00:00+00:00

Eine neue Suchmöglichkeit wurde programmiert. Jetzt ist es möglich, alle Objekte, welche in Beziehung zu gleichen Personen / Institutionen, Zeiten oder Orten stehen von einem Objekt aus aufzurufen. Vorerst ist diese Möglichkeit nur bei museum-digital:sachsen-anhalt verwirklicht. Wenn man also auf ein Objekt gestoßen ist, welches 1920 hergestellt wurde, dann kann man von der Objektansicht aus alle Objekte aufrufen, die ebenfalls in Beziehung zu 1920 stehen. Viel Sinn macht diese z.B. Funktion bei Werken von Künstlern. Hat man eines gefunden - findet man auch die anderen.

Reiss-Engelhorn-Museen: Seiten neu gestaltet

2009-07-04T00:00:00+00:00

Die Seiten der Testversionen mit Objektdaten und Inventarisierungsfotos aus den Reiss-Engelhorn-Museen (Sammlung Fayencen) wurden gründlich umgestaltet. Sie haben jetzt ein eigenes Design. Die Begrenzungen der Funktionalitäten wurden behoben. Jetzt kann hier in gleicher Weise gesucht und gefunden werden, wie bei museum-digital:sachsen-anhalt. Die Texte der Seiten sind natürlich noch Platzhalter …

Einzelbild-Ansicht überarbeitet

2009-07-01T00:00:00+00:00

Die Einzelansicht einer Objektabbildung wurde mit einem Link zur Objektbeschreibung versehen. Nur so ist auch der “Rückweg” möglich. D. h. falls jemand durch Google oder auf anderem Wege direkt zu einer Einzelansicht gelangt, kann er nun auch die Objektinformationen zur Ansicht abrufen. Das war vordem nicht möglich. (Beispiel)