Frontend

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

musdb

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

Importer

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

CSVXML

• Neue Felder: tag_related_identifier_type, tag_related_identifier

Vorträge etc.

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

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

Dezember 2024

Frontend

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

musdb

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

Januar 2025

Frontend

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

musdb

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

Importer

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

nodac

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

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.

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.

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.

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.

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

Kontrollierte Vokabulare bei Museum-Digital

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

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

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

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

md:term

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

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

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

Daten von md:term abfragen

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

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

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

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

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

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

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