Jour fixe 2025-11-07

Eine Seite aus dem Reformhaus

Jour fixe, Freitag, 7. November 2025

Wohin mit filmstandards.org?

Die DFF-IT fragt mit Ticket IT-10814 an, ob der "alte Marzipan-Server" stillgelegt werden kann.

Das geht noch nicht, denn dort liegen bis jetzt die Dienste unter filmstandards.org, also dieses Wiki, ein älteres Wiki zu EN 15907 und verschiedene Schemadefinitionen. Außerdem die schon recht alte Website von collate.eu.

Den Umzug hatten wir zurückgestellt, weil das Portieren von Mediawiki-Instanzen recht arbeitsaufwändig ist.

Ontologie-Entwurf für DFF-ZDB

Kristina hat einen ersten Entwurf für eine Ontologie zur Darstellung der ZDB als RDF-Graph vorgelegt. Hiervon ausgehend wäre zu erörtern, wie die Trennung von (langfristig stabilen) Ontologie-Klassen und Properties auf der einen Seite, und den auch kurzfristig änderbaren Wertevokabularen (im Wesentlichen die bisherige "Term"-Tabelle) am besten zu bewerkstelligen ist.

Vorschlag von Detlev: Trennung in zwei Namensräume, wobei der Vokabular-Namensraum die Einzelvokabulare als Klassen und die Terme als Instanzen der jeweiligen Klasse definiert. Hier ein paar Phantasie-URIs:

zdb: <https://filmstandards.org/schemas/zf01/> # Beispiel für Ontologie-Namensraum
dffvoc: <https://filmstandards.org/vocabularies/dff01/> # Beispiel für Vokabular-Namenraum

Im Vokabular-Namensraum hätten wir folgende Definitionen;

dffvoc:Gattung a rdfs:Class ;
    rdfs:label "Gattung"@de ;
    rdfs:comment "Gesamtheit des Gattungs-Vokabulars"@de .

dffvoc:Kurzspielfilm a dffvoc:Gattung ;
    rdfs:label "Kurz-Spielfilm"@de .

und im Ontologie-Namensraum folgendes Property-Axiom:

zdb:hatGattung a owl:ObjectProperty ;
    rdfs:domain zdb:Filmwerk ;
    rdfs:range [
        a owl:Restriction ;
        owl:onProperty zdb:hatGattung ;
        owl:allValuesFrom dffvoc:Gattung
    ] .

Damit ist "Kurz-Spielfilm" eine Instanz von "Gattung" und als solche ein zulässiger Wert für die Aussage "hatGattung":

<https://filmportal.de/869C2D2B4E1E472389E4D7E8E9F474C8> a zdb:Filmwerk ;
    owl:sameAs <http://www.wikidata.org/entity/Q106718783> ;
    zdb:hatProduktionsjahr "2010/2011" ;
    zdb:hatProduktionsland "DE" ;
    zdb:hatGattung dffvoc:Kurzspielfilm ;
    (...)

Prinzipiell ließe sich das Property-Axiom auch vereinfachen, indem schlicht rdfs:range dffvoc:Gattung deklariert wird, allerdings würde dann auch die Vokabularklasse dffvoc:Gattung selbst als Aussagewert zugelassen, was als Fehler zu werten wäre (Filmerk hatGattung "Gattung" ergibt keinen Sinn).

Anmerkungen zum 0.1-Entwurf

Bei folgenden Punkten habe ich am meisten hin- und herüberlegt:

Produktionsereignis: 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?

Literale Werte: 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?

Orts- und Zeitangaben: 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 ;-) )

Werks-Hierarchien: 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...

Technische Plattform für DFF-Linked Open Data

Benötigt wird ein RDF-Triplestore mit SPARQL-Schnittstelle und zugehörigen Diensten. Implementierungen gibt es mittlerweile reichlich, auch als Coud-Dienste von AWS, Azure und Oracle. Empfehlung von Detlev: Fuseki - weil schon in diversen Anwendungs-Umgebungen erprobt, im Rahmen der Apache Software Foundation fortlaufend gepflegt und mit leicht verständlicher Admin-Oberfläche ausgestattet.

Abzuklären mit der DFF-IT wäre, ob der Triplestore auf einem der vorhandenen Server Unterschlupf finden kann oder besser gleich einen neuen Server bekommen soll. Zur Mengenschätzung: eine lokale Installation der GND (Stand 2018) kam im BaliLabs-Intranet auf unter 200 Mio. Tripel, entsprechend ca. 100 GB Plattenplatz, für Wikidata wurden 2023 etwa 15 Milliarden Tripel angegeben. Für die ZDB wären zunächst noch weniger als 50 Mio. Tripel zu erwarten.

Nachdem die DNB jetzt (endlich!) einen eigenen Triplestore für die GND eingerichtet hat, stellt sich die Frage, ob deren technische Lösung auch für das DFF infrage käme. QLever ist allerdings bisher ein universitäres Projekt und damit den typischen Unwägbarkeiten bei der Kontinuität ausgesetzt.

GND Linked Open Data

Mit der neuen SPARQL-Schnittstelle zur GND sind jetzt auch die Rück-Verlinkungen von GND zu ZDB bzw. Filmportal maschinell auswertbar. Beispiel: in [https://sparql.dnb.de/1BOuDK?exec=true Phil Nylund] der dritte owl:sameAs-Link nach VIAF und Wikidata. Bisher werden diese Links nur im GND-Explorer, nicht aber in den GND-Anzeigen von DNB und lobid.org sichtbar gemacht.

Mit der DNB könnte man vielleicht erörtern, ob das DFF nicht auch die Möglichkeit bekommen sollte, solche Links für Körperschaften und Filmwerke an die GND zu übermitteln.

Weiteres Verlinkungspotential ZDB zu GND bieten Musikwerke (s.u.) und literarische Vorlagen (s.u.), sowie Filmwerke. Zu Letzteren gibt es über 4.000 GND-Datensätze, die über die Werkform als solche zu finden wären. Allerdings unterliegt das Werkform-Vokabular kaum einer Kontrolle, wie diese Abfrage zeigt: [1] .

Aktivieren von "verwaisten" Entitäten?

Musikwerk

Diese Entität war schon in der Vorgänger-Datenbank zur ZDB einmal angelegt worden. Ins ZDB-Datenmodell wurde die Entität Musikwerk übernommen und mit vorhandenen Daten aus der Vorgängerdatenbank befüllt. Bisher gibt es aber in der ZDB noch keine Möglichkeiten zur Bearbeitung und Verknüpfung von Musikwerken.

Nach Übernahme in die ZDB war ein kurzer Anlauf unternommen worden, die erfassten Musikwerke mit externen Identifikatoren der Verwertungsgesellschaften GEMA und BMI anzureichern. Viele der Werke wurden auch in den Werkkatalogen von ASCAP (USA) und SACEM (Frankreich) gefunden, aber seinerzeit mangels verlässlicher Identifikatoren nicht aufgenommen. Kristina hat jetzt die Überschneidung mit der GND untersucht und ist hier auch fündig geworden.

Um filmisch genutzte Musikwerke zu einer interessanten und nütrzlichen Ressource für ZDB/Filmportal zu machen, könnten noch die Schnittmengen mit Wikidata und MusicBrainz untersucht werden. Diese beiden Datenbanken bieten wie die GND persistente Idenitfikatoren und liefern maschinell verarbeitbare Daten über frei nutzbare Programmschnittstellen (APIs).

In der ZDB vorhandene Daten: Hier eine Abfrage vorhandener P2-Angaben in der Relation "Musikalische_Vorlage"

 select relation.SubjUID, filmwerk.IDTitel_P, relation.ObjUID, 
 person.IDName, relation.P2 FROM relation
 JOIN filmwerk on filmwerk.uid=relation.SubjUID 
 JOIN person on relation.ObjUID=person.uid
 WHERE relation.Rel="Musikalische_Vorlage" AND relation.ObjEnt="P" AND (relation.P2 is not null)

Literarische Vorlagen und Bühnenstücke

Wie für Musikwerke ist zu Beginn der ZDB auch eine eigee Entität für Werkvorlagen eingerichtet, aber bisher nur mit einem kleinen Satz Testdaten befüllt worden. Ein Matching-Versuch von Kristina ergab mit diesen Testdaten allerdimgs eine relativ hohe Trefferquote (17 von 28).

Insgesamt gibt es in der ZDB momentan 7.471 Filmwerke mit einer Relation "hat_Vorlage", die auf den Urheber der Vorlage verweist. In ca. 25-30% der Fälle enthalten diese Relationen einen identifizierbaren Werktitel, in etlichen weiteren Fällen geht der Werktitel aus dem Filmtitel hervor.