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 die gewünschte Ausgabereihenfolge der Gewerke zu bestimmen.

• 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 EAC-Schema nicht definiert. 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 der Datenbank entnommen wird. 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 (XSL, SHACL, etc) Skripten 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.).

Diskussion Ontologie-Entwurf

Werks-Hierarchien

KR -> Ich glaube, die hierarchische Modellierung von Werk - Aggregatwerk - Filmwerk ist noch etwas schief bzw. könnten da über "inferred"-Logiken komische Aussagen bei herumkommen. Werk hatte ich als unspezifizierte Überklasse mit hereingenommen, um zum Filmwerk noch andere Werksarten wie Musik und Literatur (siehe unten) ergänzen zu können, aber gleichzeitig einen übergeordneten Knoten zu haben. Wo steht das Aggregatwerk in diesem Konstrukt? Ich hatte es jetzt auch dem Werk untergordnet, aber irgendwo sind dann schon komische Dinge passiert...

DB -> Mit Filmwerk und Aggregatwerk als Geschwisterklassen sehe ich kein grundsätzliches Problem. Oder übersehe ich da etwas? FRBR-oo hat einen ganzen Zoo an direkten Unterklassen von F1 Work, neben F14 Individual Work noch F15 Complex Work, F16 Container Work, F17 Aggregation Work, F18 Serial Work und F19 Publication Work. Das IFLA LRM dagegen hat gar keine Unterklassen von E2 Work, sondern differenziert alle Werktypen über die Property E2A1 has category of work.

In der ZDB identifizieren wir Aggregate allein anhand des Attributs Titel-Typ, was dem LRM näher käme als der Ansatz aus FRBR-oo. Allerdings müssten wir dann das Filmwerk mit einer Werktyp-Property versehen, was ganz neue Komplikationen aufwirft, denn Aggregatwerke haben ganz andere Eigenschaften als das einzelne Filmwerk.

Zur Orientierung: gegenwärtig (09-Jan-2026) haben wir 772 Gesamttitel, 2197 Reihentitel und 25 Periodikum, das ergibt 2994 Aggregatwerke (real etwas weniger, weil einige auch mehrsprachig angegeben sind).

Produktionsereignis

KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder?

DB -> Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein. Grundsätzlich spräche nichts dagegen, im RDF-Graphen Eigenschaften wie Land, Zeitangabe, Gattung und alle Credits unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind.

Literale Werte

KR -> Einige Angaben in der ZDB sind Freitextfelder, v.a. bei den Manifestationseigenschaften. In V0.1 habe ich mich relativ nah an den Ist-Zustand gehalten und keine Klassen für "Trägermaterial", "Bildseitenverhältnis" etc. modelliert. stattdessen haben die entsprechenden Properties ebenfalls ein Literal als Wert, um den Mappingaufwand gering zu halten. Aufwändige Matchingtabellen würden dadurch gespart - aber eben auf Kosten der Interoperabilität und ggf. Mehrsprachigkeit. Wenn man wie oben vorgeschlagen die "Kern-Ontologie" von den Vokabularen trennt, ist man hier aber vielleicht insofern etwas flexibler, dass man sehr eindeutige Werte aus ein LOD-Vokabular matchen könnte und für alles andere dann die Literale beibehält?

DB -> In RDF können wir Literale mit syntaktischen Restriktionen versehen. Für das Bildseitenverhältnis beispielsweise käme der reguläre Ausdruck "/\d:\d/", in Frage, für die Zeitangaben sähe es etwas komplexer aus. Bei einem RDF-Export müssen wir außerdem berücksichtigen, dass syntaktisch normierte Literale nicht immer den Vorschriften entsprechen bzw. schon retrospektiv normiert wurden. Die aufzählbaren Literal-Werte (z.B. Aufführungsart), die in der ZDB meist schon in der Vokabulartabelle ("term") definiert sind, sollten wir immer als ObjectProperty mit einem Vokabularelement-IRI in der Objekt-Position darstellen. Damit können wir die Ontologie auf Definitionen mit "Ewigkeitscharakter" beschränken.

Orts- und Zeitangaben

KR -> In einigen Fällen habe ich keine eigenen Properties modelliert, sondern auf dcterms:spatial und dcterms:date zurückgegriffen. Mir erschien es, dass viele Orts- und Zeit-Attribute in der ZDB doch semantisch ähnlich sind und es keine spezifischen/unterschiedlichen Properties dafür bräuchte. (Beispielsweise: Titelregion, Ort der Dreharbeiten, Aufführungsort, Zeitangabe der Aufführung, Zeitangabe des Titels, Zeitangabe des Aggregatwerks, Produktionsjahr (das ist wahrscheinlich etwas streitbar ;-) )

DB -> dcterms:date wird in den meisten Fällen nicht funktionieren, weil wir vielfach Sonder-Konventionen verwenden, die nur als Literale mit Syntax-Constraints beschieben werden können. Siehe dazu auch Syntaxen und Umrechnungsfaktoren in diesem Wiki.

Geografika sind auch wieder ein Sonderfall. Die ZDB-Konventionen für Länderkürzel finden sich in Ländercodes. Hier könnte ähnlich verfahren werden wie in der GND, wo mit der Property gndo:geographicAreaCode auf ein eigenes, fallweise mit ISO 3166-1 gemapptes Vokabular zurückgegriffen wird.

Für Toponyme existieren teilweise Mappings zur GND, die bei der Datenübermittlung via SCUSI verwendet werden. Die GND erhält im Fall eines vorliegenden Mappings einen GND-URI als Aussagewert. In allen anderen Fällen wird der Ortsname als String-Literal übergeben. Es wäre zu überlegen, ob dieses Verfahren auch für die ZDB-Darstellung als RDF-Graph angewendet werden soll. Für Ortsangaben wäre dann sowohl eine ObjectProperty wie auch eine DatatypeProperty zu definieren, wie es auch in der GND der Fall ist.

Vokabulardienst

Eine wichtige Neuerung für die ZDB wäre die Übertragung der "term"-Tabelle in einen RDF-gestützten Vokabular-Webservice. Dies kann relativ kurzfristig geschehen, sobald der Triplestore für die ZDB verfügbar ist.

Die bisherigen SQL-Anfragen an die Tabelle pdf.term würden sukzessiv durch SPARQL-Anfragen an den SKOS-basierten RDF-Graphen ersetzt. Sobald diese Umstellung abgeschlossen ist, kann die weitere Vokabularpflege im RDF-Graphen erfolgen. Welche Hilfsmittel dafür sinnvoll sind, kann zu einem späteren Zeitpunkt durch Ausprobieren ermittelt werden. Im einfachsten Fall wären Textdateien in Turtle-Syntax zu editieren.