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.

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.

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

Durch die Zentralisierung wird die Terminologie-Arbeit aber eben auch ein versteckt. Hin und wieder berichten wir in Vorträgen oder hier im Blog aus der Vokabular-Arbeit oder nodac, dem Tool, mit dem die „Normdatenredaktion“ die Vokabulare kontrolliert. Neben einigen Vortragsfolien im Dokumentenarchiv und einer Seite auf der allgemeinen Vorstellungsseite ist es aber recht schwer, weitere Informationen zur Arbeit der Normdatenredaktion und zu nodac zu finden.

Um etwas Licht ins Dunkel zu bringen, wird in den nächsten Tagen auf dem frisch eröffneten Youtube-Channel eine kleine Reihe von fünf Screencasts veröffentlicht, die nodac vorstellen. Der Fokus liegt dabei klar auf nodac als Werkzeug. Weil nodac aber auf Basis der Bedarfe der Normdatenredaktion entsteht, wird diese zwangsläufig auch ein wenig vorgestellt.

Die Videos erscheinen ab heute (1.4.2023) mit einem Abstand von zwei Tagen. Wer also alle fünf in einem Rutsch gucken möchte, muss sich damit noch bis zum 9. gedulden. An alle anderen, wie man so sagt: Like and subscribe.

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.

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

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

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.

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.

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.

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

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

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.

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.

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

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.

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

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

Schlagworte verfeinern

Viele Objekte sind nicht so genau verschlagwortet, wie es möglich wäre. Ein Portrait ist ein Portrait. Und häufig fällt einem beim Eingeben schlicht nichts genaueres ein.

Handelt es sich um ein Portrait einer Frau, wäre der Begriff „Damenportrait“ allerdings spezifischer. Eine spezifische Verschlagwortung würde suchen nach diesem konkreten Begriff ermöglichen, aber durch die im Hintergrund angereichterten Hierarchien würde das Objekt bei Suchen nach „Portrait“ weiterhin gefunden. Kurz zusammengefasst: Eine so genaue Verschlagwortung wie möglich ist in eigentlich jedem Fall gut.

Wurde ein Objekt einmal als Portrait verschlagwortet, war das Spezifizieren des Begriffs bisher leider etwas mühsam. Man musste zuerst das genauere Schlagwort anhängen, und dann das ungenauere entfernen. Um die Spezifizierung zu vereinfachen, kann man jetzt in der Eingabeoberfläche mit einem Rechtsklick auf ein verknüpftes Schlagwort eine Seitenspalte öffnen. In dieser sind alle dem Schlagwort direkt untergeordneten Begriffe zu finden. Durch einen Klick auf einen Eintrag aus dieser Liste wird das ungenaue durch das genauere Schlagwort ersetzt.

Neben der Vereinfachung der Verschlagwortung bietet die Funktion so auch vielleicht eine Inspiration, falls man gerade nicht im eigenen Fachgebiet arbeitet.

Vielen Dank an die Kollegen aus Ungarn, die uns auf dem Benutzertreffen in Budapest Anfang November zu dieser Funktion inspiriert haben.

Orte, Akteure und Schlagworte mehrsprachig eingeben

Eine weitere Verbesserung der Verschlagwortungsfunktionen ist die Möglichkeit, Orte, Akteure und Schlagworte in anderen Sprachen einzugeben. Wenn im Museum jemand arbeitet, der oder die nicht muttersprachlich Deutsch spricht, ist es hilfreich, auch „Cologne“ statt „Köln“ eingeben zu können.

Deshalb beachtet musdb bei der Verschlagwortung jetzt auch die allgemeine Umgebungssprache des Benutzers. Ist diese auf Englisch eingestellt, erkennt das System beim Eingeben von „Cologne“, dass Köln gemeint ist, und bietet auch „Cologne“ in Auswahllisten für Orte an. Die deutsch-sprachigen Kollegen sehen dann „Köln“ verlinkt, weil im Hintergrund gespeichert ist, dass beides Namen für dieselbe Stadt in Englisch bzw. Deutsch sind.

So wird auch Kollegen, die wenig oder gar kein Deutsch sprechen, die Möglichkeit gegeben, die Objektdaten weiter anzureichern.

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

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.

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

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 …

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