Jour fixe 2026-01-09

Eine Seite aus dem Reformhaus

Jour fixe, Freitag, 9. Januar 2026

Änderungen im Relationen-Vokabular

In den letzten Monaten wurden eine Reihe von Relatoren in der ZDB (pdf.reldef und pdf.reldef_en) vom DFF-Team diskutiert (Bezeichnung des Relators, Gruppenzuordnung und englische Übersetzung). Ziel war es vor allem, ungegenderte Begriffe zu finden (also weg von "Darsteller"), aber es wurden in diesem Zuge auch ein paar weitere Änderungen vorgenommen. Die Übersicht wird noch per Mail verschickt.

Folgende Fragen zu technisches Abhängigkeiten haben sich ergeben:

• Wenn wir einen Relator in der ZDB umbenennen, wie ist dafür der Ablauf? Welche Folgen hat das innerhalb der ZDB? Aktualisieren sich alle betroffenen Einträge in der pdf.Relation automatisch oder muss das dort ebenfalls per Korrektur geändert werden?

• Der Relator ist schlicht ein mnemonischer Datenbankschlüssel, d.h. die Aussagen hätten auch beispielsweise "Y123" statt "Darsteller" lauten können. Rückwirkende Änderungen von Datenbankschlüsseln sind hochproblematisch, in der Regel aber nicht notwendig.

• Wenn wir die Übersetzung eines Relators ändern, welche Folgen hat das innerhalb der ZDB? Gar keine, weil sie nicht ausgegeben werden?

• Übersetzungen bzw. Display-Formen können ohne Rückwirkung auf den Datenbestand geändert werden. Wenn nötig, können wir auch ein Element für feminine Display-Formen und sogar Numerus-Formen einführen. Die Gender-Angabe im Personendatensatz ließe sich dafür heranziehen. Im Fall der aggregierten Ausgabe von Darsteller-Credits wären allerdings Fallunterscheidungen zu implementieren für (1) männlich oder unbestimmt im Singular, (2) weiblich im Singular, (3 wie (1)) männlich oder unbestimmt im Plural, (4) weiblich im Plural, und (5) gemischtgeschlechtlich im Plural.

• Wenn wir einem Relator eine neue Gruppe zuweisen, welche Folgen hat das innerhalb der ZDB? Gar keine, weil sie nicht ausgegeben werden?

• Die RelatorGruppe wird als zusätzliches Sortierkriterium bei der ZDB-Filmwerks-Ansicht und in den Austauschformaten verwendet, um beispielsweise die Darsteller-Credits im Anschluss an die anderen Funktionen ausgeben zu können. Allein nach Notation würden sie vor allen anderen Credits erscheinen.

• Welche Änderungsbedarfe bestehen noch an den Eintragungen in der Spalte „Notation“ in pdf.reldef

• Die Notation bestimmt (1) die Reihenfolge in den Relations-Auswahllisten beim Zuordnen von Personen und Körperschaften und (2) die Ausgabereihenfolge der Credits innerhalb einer Gruppe in der Filmwerk-Ansicht.

• Was bedeutet die Änderung für die Nutzer*innen der OAI-Schnittstelle und des Webservice?

• Hier werden die CreditRel-Elemente ebenfalls nach Notation sortiert.

• Was bedeuten Umbenennungen in den Person -> Person Relatoren für die GND-Schnittstelle? Verarbeitet die GND diese Informationen und geben wir sie überhaupt mit raus? Wo ist ein Beispiel für einen Datensatz mit Relationen im Austauschformat?

• An die GND können Person-Person-Relationen nicht übermittelt werden. Obwohl die GND solche Relationen kennt, wurde die Übermittlung in der SCUSI-Spezifikation nicht vorgesehen. Im EAC-Datenexport werden Person-Person-Relationen derzeit nicht ausgegeben. Prinzipiell möglich wäre dies mit den EAC-Attributen reltype='parent' und reltype='child', mehr ist im verwendeten Schema nicht vorgesehen. In DNB-JSON fehlt diese Relation ebenfalls, weil die sich nach der SCUSI-Spezifikation der DNB richtet.

• Haben wir aktuelle Schemata, die wir aktualisieren müssten? [filmstandards.org/schemas/de-dif/zf-fw-view-1.5/] (Struktur ändert sich wahrscheinlich nicht, aber die Werte in den Elementen.)

• Einige Elemente tragen den Namen von Relatoren (z.B. hat_Titel), während die Credits-Relationen und alles übrige wird aus der Datenbank bezogen werden. Das XML-Schema ließe sich erweitern, indem das CreditRel-Element neben 'rel' ein weiteres Attribut 'displayRel' bekommt, sozusagen als Empfehlung für die Weiterverarbeitung. Von dieser Methode wird u.a. in LIDO (exzessiv) Gebrauch gemacht.

Evaluierung von Ontologie- und Vokabularplattformen

Leider bisher ohne überzeugendes Ergebnis.

TemaTres wurde zwischenzeitlich von DB getestet, zeigt entscheidende Schwächen. Das Datenmodell ist fest auf SKOS-XL verdrahtet, erlaubt damit keine projektspezifischen Relationen. Pro Installation gibt es nur ein einziges Vokabular, elementspezifische Vokabulare müssten daher mittels Hierarchien in einem zusammenhängenden Namensraum verwaltet werden. Kooperatives Arbeiten ist standardmäßig nicht vorgesehen; nur mit Workaround kann mehr als eine Benutzer-ID pro Thesaurus genutzt werden.

Vorschlag für vorläufige Lösung: Gar keine interaktive Plattform verwenden, sondern sowohl die Ontologie wie auch die Vokabulare in textbasierten Formaten pflegen. Kontrollen würden dann mit generischen (Syntax-Checker) und Schema-spezifischen (SHACL, etc) Werkzeugen erfolgen. Kooperatives Arbeiten ließe sich gut mit Git realisieren, dort gibt es Änderungsverfolgung, Versionierung und etliches mehr. Die Arbeit wäre damit ähnlich wie in einem Wiki, aber mit besserer Integration in die Anwendungen (ZDB, Triplestore, etc.).