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

Entwicklung

musdb

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

nodac

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

Vorträge

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

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

Neue Features

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

Verbesserungen

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

musdb

Neue Features

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

Verbesserungen

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

Bugfixes

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

Importer

Neue Features

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

Verbesserungen

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

Bugfixes

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

nodac

Neue Features

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

CSVXML

Verbesserungen

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

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)

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)

• 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

• 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

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

Beitragsbild generiert mit illustriousXL_smoothftSPO

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

Seit 2012 arbeitet der Museumsverband Brandenburg (MVB) eng mit museum-digital als Objekteingabe- und Veröffentlichungstool für Museen zusammen. In zahlreichen Digitalisierungsprojekten haben wir auf der Grundlage von md zusammen mit den Brandenburger Museen Objekte digitalisiert und veröffentlicht. Mittlerweile sind 133 Museen und über 28.800 Objekte auf https://brandenburg.museum-digital.de/ einsehbar.

Eine im Jahr 2022 vom MVB in Kooperation mit dem Ministerium für Wissenschaft, Forschung und Kultur (MWFK) durchgeführte Evaluation zeigte jedoch, dass die Digitalisate auf md bisher nur begrenzt landesrelevante Themen abbilden. Im Gesamtblick scheint die digitale Präsentation des brandenburgischen Kulturerbes noch zu sehr ein Flickenteppich der relevanten Fragen und Schwerpunkte der Landesgeschichte und Gegenwart. Es bestand der Wunsch nach der Möglichkeit, anhand einzelner Objekte und Sammlungen überblickshaft Themen herauszustellen und sichtbar zu machen. Auch die Möglichkeit einer niedrigschwelligen, partizipativen Erkundung der Sammlungen wollten wir erproben.

So entstand die Idee eines separaten Portals, in dem diese Möglichkeiten gegeben sind, aber auf die Daten aus museum-digital zurückgegriffen wird. Hierfür bietet md eine Datenschnittstelle (API) an, damit Museen ihre Bestände auf einer eigenen Webpräsenz mit eigener Gestaltung präsentieren können. Mit Hilfe einer Förderung des MWFK und in Zusammenarbeit mit einer Webagentur konnten wir im letzten Jahr die Plattform www.brandenburg-sammelt.de aufbauen, die seit dem 15. April online ist.

Die Umsetzung

Die Seite bietet verschiedene Zugänge: Die „Heroes“ sind besonders interessante oder kuriose Objekte, die hervorgehoben werden. Ganz wie bei der TV-Show „Dings vom Dach“ können sie näher erkundet und ihre Funktionen erraten werden. Die „Highlight-Sammlungen“ präsentieren stetig wechselnde Beispiele besonderer Sammlungen aus den Museen. Im „Entdecker-Modul“ laden Begriffswolken und Einstiegsfragen zum Erkunden der Sammlungen ein. Wer hätte zum Beispiel gedacht, dass sich auch zum Lieblingsgetränk „Cola“ Objekte finden lassen? Und wer wusste, dass es so viele tolle Fotografie-Sammlungen in Brandenburg gibt? So werden assoziative Einstiege ermöglicht und die Nutzer*innen zum Erkunden der Sammlungen angeregt. Darüber hinaus kann man auf einer separaten Seite spezifische Themen erkunden, wie „Spiele und Spielzeug im Wandel der Zeit“ oder „Bräuche in Brandenburg“. Darüber hinaus gibt es auch eine allgemeine Suche, in der über Volltext- oder Schlagwortsuche Objekte aus den Sammlungen gefunden werden können.

Begleitend zur Umsetzung haben wir einen User-Test mit Freiwilligen durchgeführt, um Feedback zur Nutzbarkeit zu erhalten. Die Erkenntnisse fließen in den weiteren Ausbau der Plattform dieses Jahr ein.

Das Portal als Arbeitstool

Neben der gezielten Aufbereitung der Inhalte ist es ein weiteres Ziel der Plattform, die Museen zur Verbesserung ihrer Metadaten (z.B. ansprechende Abbildungen, interessante Objektbeschreibungen und gute Verknüpfung zu Ereignissen und Schlagworten) zu motivieren. Es ist ein Schlagwort-Marathon geplant, in dem zusammen mit den Museen die Verschlagwortung zu bestimmten Themengebieten verbessert wird. Das schafft zugleich Aufmerksamkeit und Bewusstsein bei den Museen für das Thema allgemein und soll langfristig zu einer besseren Datenqualität führen.

Zudem sollen inhaltliche Fehlstellen aufgezeigt und gezielt angegangen, sowie Kooperationsprojekte gefördert werden. In den vergangenen Jahren wurden hier sehr gute Erfahrungen mit regionalen Verbundprojekten gemacht. Über die Plattform brandenburg-sammelt.de können solche Verbundthemen nun noch besser präsentiert werden. So wird die Seite in diesem Jahr noch um ein Regionen-Modul ergänzt, in dem die Inhalte bestimmter Themen auf einer Karte strukturiert dargestellt werden können. Hiermit soll die Vernetzung der Museen und die Möglichkeit der Präsentation regionaler Verbünde ausgebaut werden.

Mitmachen und Unterstützen!

Die Plattform versteht sich als ein gemeinschaftliches Projekt der Museen in Brandenburg, in dem die Ideen und Themenvorschläge aller Beteiligten gefragt sind. Nur wenn brandenburg-sammelt.de in der Bevölkerung bekannt ist, kann diese die Plattform auch aktiv nutzen. Auch hier sind wir auf Ihre Unterstützung angewiesen. Teilen Sie die Informationen und den Link zu brandenburg-sammelt.de daher gerne und geben Sie uns Feedback. Wir entwickeln die Seite dieses Jahr weiter und freuen uns über Ihre Rückmeldungen.

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)

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.

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

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.

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

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.

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

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.

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

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

Andererseits gibt es unter den Museen bei museum-digital (und anderswo) immernoch relativ viele, die keine eigene Website haben. Damit fällt zumindest für diese Institutionen der offensichtlichste Anwendungszweck schon von vorne weg aus.

Auf Basis der API könnten Museen Voransichten ihrer Objekte auf ihrer Webseite einbinden – sei es thematisch zu einem Beitrag passend oder als „Objekt des Monats“ o.ä. auf der Startseite. Sie könnten sich einen Veranstaltungs- oder Ausstellungskalender anzeigen lassen, mit den Ausstellungen und Veranstaltungen die bei museum-digital eingetragen sind. Oder sie könnten eine Suche nach Objekten aus ihren Sammlungen auf ihrer eigenen Webseite bereitstellen.

Um ein Beispiel für eine Anwendung der API zu liefern und gleichzeitig vielleicht (d.h. hoffentlich) den kleinen Museen, die noch keine eigene Webseite haben, zu helfen habe ich mich im Laufe des Monats daran gesetzt ein kleines Content Management System zu bauen, das Museen ermöglichen soll, möglichst einfach eine simple Webseite zu bauen, in die nach Bedarf und auf eine einfach Benutzbare Art und Weise Inhalte aus museum-digital einfließen gelassen werden können.

Bei museum-digital haben wir viel Kraft und Zeit in die API gesteckt – aber auch nach mehr als einem Jahr fehlen Beispiele von Programmen, die die API benutzen. Das mag daran liegen, dass die API lange Zeit nicht vollständig öffentlich dokumentiert war, oder daran, dass sich die Uhren im Museumsbereich generell etwas langsamer drehen.

Andererseits gibt es unter den Museen bei museum-digital (und anderswo) immernoch relativ viele, die keine eigene Website haben. Damit fällt zumindest für diese Institutionen der offensichtlichste Anwendungszweck schon von vorne weg aus.

Auf Basis der API könnten Museen Voransichten ihrer Objekte auf ihrer Webseite einbinden – sei es thematisch zu einem Beitrag passend oder als „Objekt des Monats“ o.ä. auf der Startseite. Sie könnten sich einen Veranstaltungs- oder Ausstellungskalender anzeigen lassen, mit den Ausstellungen und Veranstaltungen die bei museum-digital eingetragen sind. Oder sie könnten eine Suche nach Objekten aus ihren Sammlungen auf ihrer eigenen Webseite bereitstellen.

Um ein Beispiel für eine Anwendung der API zu liefern und gleichzeitig vielleicht (d.h. hoffentlich) den kleinen Museen, die noch keine eigene Webseite haben, zu helfen habe ich mich im Laufe des Monats daran gesetzt ein kleines Content Management System zu bauen, das Museen ermöglichen soll, möglichst einfach eine simple Webseite zu bauen, in die nach Bedarf und auf eine einfach Benutzbare Art und Weise Inhalte aus museum-digital einfließen gelassen werden können.

Bisher ist der Code nur für die bei museum-digital teilnehmenden Museen zugänglich oder auf Anfrage zu erhalten, aber es ist geplant das CMS mittelfristig Open Source zu stellen. Bis es soweit ist, hoffe ich eine Hand voll Museen finden zu können, die das CMS ausprobieren und Feedback liefern können.

Ziele

Um die beiden Hauptziele bei der Erstellung des CMS, eine einfache Benutzbarkeit und eine ausreichende Integration mit der API von museum-digital, zu erfüllen, muss das System einige Bedingungen erfüllen.

• Einfache Installierbarkeit
  • Installation per Kopieren von Dateien oder automatisierbar
  • Wenige Abhängigkeiten (e.g. ohne, dass ein gesondertes Datenbanksystem benötigt wird)
• Flexbilität
  • Das System muss mit verschiedenen Instanzen von museum-digital umgehen können
  • Themes: Das Design sollte einfach anpassbar und austauschbar sein
• Einfache Bearbeitung
  • WYSIWYG-Editor
  • Einfache Integration mit museum-digital

Installation

Bei Seitenaufrufen werden wichtige Ordner und Dateien, soweit möglich, angelegt, wenn Sie noch nicht installieren. Auch data ist ein solcher Ordner: er existiert nicht, wird aber ggfs. beim ersten Seitenaufruf automatisch angelegt.

Um das CMS auf einem Server zu installieren, muss man die zip-Datei mit dem Code entpacken und die Inhalte auf den Server, auf dem es später laufen soll, heraufladen. Um in den Bearbeitungsbereich zu gelangen muss nun noch die Datei users.json.sample aus dem Unterordner appFiles in einen neuen Unterordner data kopiert werden und in users.json umbenannt werden. Damit ist der Standardbenutzer installiert.

Die Systemanforderungen sind relativ gering. Das CMS ist in PHP 7 geschrieben, dass auf den meisten Servern eh schon installiert ist. Weil einige Features von PHP 7 verwendet werden, die in PHP 5.X noch nicht verfügbar sind, sollte aber darauf geachtet werden, dass für den gegebenen Webspace / vHost etc. tatsächlich PHP 7 aktiviert ist.

Ansonsten wird ein SSL-Zertifikat benötigt, damit die Kommunikation mit dem Server besonders im Eingabebereich verschlüsselt ablaufen kann (einfach ausgedrückt: die Seite muss unter einer mit URL https:// abrufbar sein). Ist keine verschlüsselte Verbindung möglich, lässt das System keine Benutzer in den Eingabebereich.

Um Seiten zu bearbeiten empfielt es sich auch, einen halbwegs aktuellen Browser zu benutzen.

Seiten bearbeiten

Die Startseite des Eingabebereichs

Nach dem Einloggen im Eingabe-Bereich erscheint ein Willkommensbildschirm, mit einem kurzen Willkommenstext. Dieser Willkommenstext kann von Benutzern mit Adminrechten bearbeitet werden und bietet etwa die Möglichkeit, Regeln für das Schreiben von Beiträgen an einer für Bearbeitende oft gesehenen Stelle zu vermerken.

Links findet sich die Navigation mit Links zu den Bearbeitungsseiten für Seiten und fest stehende Seitenelemente. Klickt man auf „Seiten“ erscheint eine Übersicht aller verfügbaren Seiten; mit einem Klick auf das + daneben werden neue Seiten angelegt.

Einzelne Seiten

Für einzelne Beiträge oder können jeweils ein Titel, der Seiteninhalt, die Position in der Seitenhierarchie / Navigation und der Status als Entwurf oder öffentlicher Artikel angegeben werden. Die Bearbeitung von Seiteninhalten erfolgt mithilfe des WYSIWYG-Editors TinyMCE. So können Inhalte formatiert und z.B. Bilder auch ohne HTML-Kenntnisse eingefügt werden.

Des weiteren können verschiedene Typen von Inhalten aus museum-digital über Platzhalter in den Text eingefügt werden. Um die Platzhalter zu generieren, findet sich am unteren Ende der rechten Seitenspalte ein Generator: Erst wird der Typ der Einbettung ausgewählt, dann zusätzliche URL-Parameter für die Auswahl eingegeben, dann kann mit einem Klick auf Generieren der Platzhalter generiert und in den Text kopiert werden.

Ein Beispiel: Um das Objekt Holzstelzsandalen, Syrien, Türkei als Vorschau-Kachel einzubetten, müsste man zuerst den Einbettungstyp Einzelobjekt (Kachel) auswählen. Danach muss man auf die URL der Objektseite bei museum-digital achten: https://st.museum-digital.de/index.php?t=objekt&oges=46083. Nach „index.php“ folgen die URL-Parameter. t=objekt bedeutet, dass es sich hierbei um eine Objektseite handelt – das ist durch den Einbettungstyp schon implizit bekannt und deshalb weniger interessant. oges=4608 ist an dieser Stelle der entscheidende Parameter: Er besagt, dass das Objekt mit der internen Nummer 4608 gemeint ist. Entsprechend kann oges=4608 nun in den Schlitz für zusätzliche Parameter eingefügt werden. Mit einem Klick auf Generieren wird der Platzhalter ([singleObjectTile]{oges=46083}) generiert. Dieser kann durch kopieren frei im Text platziert werden.

Feste Seitenelemente

Auf eine ähnliche Art und Weise können auch feste Seitenelemente bearbeitet werden: Banner, Seitenspalte und Fußzeile. Ebenso wie bei den Hauptseiteninhalten kommt hier TinyMCE zum Einsatz, um die jeweiligen Elemente zu bearbeiten.

Es fehlen jedoch die Schalter für die Hierarchie und den Veröffentlichungsstatus. Um ein Seitenelement nicht anzuzeigen, kann das entsprechende Eingabefeld einfach leer gelassen werden.

Integration mit museum-digital

Die Integration mit museum-digital beschränkt sich nicht auf die genannten Einbettungen in normale Seiten. Zusätzlich zu diesen gibt es für die verschiedenen Arten von Einträgen bei museum-digital jeweils Spiegelseiten, mit den Detailinformationen aus museum-digital aber abgespeckter Funktionalität (es fehlen etwa die Social Media-Buttons und die Zitierfunktion). Wird das CMS von nur einer Institution benutzt, kann dies in den Seiteneinstellungen vermerkt werden, damit nicht auch die Inhalte anderer Institutionen verfügbar gemacht werden.

Die Suchfunktion des CMS bietet außerdem neben einer Volltextsuche in den Seiten selbst eine Suche in den Objekten des Museums (oder der Museen, auch mehrere sind möglich). Dies ist möglich durch ein Abfragen der Such-API von museum-digital.

Um die vielen Inhalte, die von museum-digital hinzugeladen werden, nicht bei jedem Aufruf der Seite neu abrufen zu müssen, besteht die Möglichkeit diese zwischenzuspeichern. Um den Server von museum-digital nicht übermäßig zu belasten und gleichzeitig die Ladezeit der eigenen Seite wesentlich zu verringern, lohnt es sich dieses Feature in den Seiteneinstellungen zu aktivieren.

Hilfetexte

Um dem Ziel einer möglichst einfachen und klaren Benutzbarkeit weiter näher zu kommen, gibt es hinter jedem Eingabefeld mit Ausnahme von Seitentiteln und Hauptinhalten ein Feld mit Hilfeinformationen. Dieses ist durch ein grau bzw. blau hinterlegtes Fragezeichen erkennbar. Beim überfahren mit der Maus wird der Hilfetext sichtbar.

Ebenso gibt auf jeder Seite des Eingabebereichs Schalter für Hilfetexte, die die ganze Seite betreffen. Diese finden sich immer oben ganz rechts auf der Seite.

Sicherheit

Gerade im technischen Bereich haben Museen oft nur wenige oder keine eigenen Kräfte, die sich z.B. um das Aufsetzen einer Webseite kümmern können. Umso mehr sollte ein CMS für Museumswebseiten Sicherheitsfeatures von Haus aus anbieten – und by default aktiviert haben. Gleichzeitig sollten diese möglichst wenig beim Bearbeiten der Seite ins Gewicht fallen.

Derzeit sorgen vor allem zwei Maßnahmen für eine erhöhte Sicherheit: Einerseits der Zwang zu HTTPS, das mittlerweile eigentlich ein Muss für Webseitenbetreiber ist, und andererseits die Implementation von Content Security Policies.

CSPs sind eine Maßnahme gegen Cross-Site-Scripting-Angriffe, also das Ausführen von externem Code auf der eigenen Seite, mit dem Daten von der eigenen Seite (z.B. Passwörter) an den Angreifer übertragen werden können. CSPs schützen dagegen, indem verschiedene Datenquellen und Typen von Datenquellen gezielt freigeschaltet werden müssen. Die Webseitenadministratoren können so etwa dem Browser des Benutzers mitteilen, dass Videos nur von der eigenen Seite oder https://youtube.com geladen werden können sollen, Bilder aber nur von der eigenen Seite.

Mehr Informationen dazu finden sich in den Hilfetexten hinter den entsprechenden Eingabefeldern in den Seiteneinstellungen. Um zu den Seiteneinstellungen zu gelangen, muss man als Administrator eingeloggt sein.

Weil CSPs bisher nur von relativ wenigen Seitenadministratoren implementiert werden, unterstützt das CMS sie von Haus aus. Falls der Administrator sie aber schon auf Server-Ebene umgesetzt hat, ist das dem Setzen durch das CMS vorzuziehen, deshalb ist dieses Feature abschaltbar.

Ein erster Schritt

Die Grundfunktionen zum Erstellen einer Museumsseite sind mit dem CMS auf seinem jetzigen Stand weitgehend abgedeckt. Dies gilt besonders für Museen, die museum-digital mit allen seinen Publikationsfunktionen benutzen und z.B. auch Ausstellungen und Veranstaltungen dort eintragen. Gleichzeitig fallen mir selbst schon bei kurzem Nachdenken einige Features ein, die wahrscheinlich relativ bald benötigt werden könnten. Dazu zählen etwa die Möglichkeit Seiten auch auf gleicher Ebene zu sortieren (also ihre Reihenfolge festzulegen) oder eine Blogfunktion.

Das Bestehende ist aber meiner Einschätzung nach schon ein erster stabiler Schritt. Ich würde mich über Tester, Anwender und Feedback freuen.

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