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

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

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.

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

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

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.

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

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

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.

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

Deutlichere Beschriftungen

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

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

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

Schnelle Sucheinstiege sind nur Einstiege

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

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

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

Neue Such- und Sortieroption

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

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

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

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

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

Apropos: Neue Screencasts zu musdb auf Youtube

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

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

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.

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

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.

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

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.

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)

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

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.

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

• OpenSearch-Spezifikation
• OpenSearch bei Mozilla MDN

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