Jour fixe 2026-08-28

Eine Seite aus dem Reformhaus

Jour fixe, Freitag, 28. August 2026

Eine Handvoll RDF-Themen:

Gattungen

Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&startNode=c00061&lang=de&d=n

Geografika

Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?

Ein paar Überlegungen dazu sind hier schon notiert: Geografika in RDF

Ranges und Domains

Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.

In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term zdb:hatGattung a owl:ObjectProperty ;

   rdfs:label "hat Gattung" ;
   rdfs:range zdbvoc:term ; # rdfs:Resource?
   rdfs:domain zdb:Filmwerk .

Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage: zdb:inFunktion a owl:ObjectProperty ;

   rdfs:label "in Funktion" ;
   rdfs:range zdbvoc:rels ; # changed from zdbvoc:term 
   rdfs:domain zdb:Beteiligung .

Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?

DB: da ist auf jeden Fall noch was zu tun. Ja, ein skos:Concept sollte eigentlich keine rdfs:domain haben; die Verwendungs-Restriktion sollten wir anders ausdrücken.

zdbvoc:P1 / zdbvoc:P2

Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.

DB: Stimmt. In der RDF-Darstellung sollten diese Properties so heißen, wie sie in 'reldef' für den jeweiligen Kontext definiert sind. Die Übersetzng aus der ZDB-Tabelle 'relation' wird dann beim RDF-Export erledigt.

Entitäten-URIs

Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10) Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?

DB: Grundsätzlich gibt es zwei Möglichkeiten:

(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen).

(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren.

Der Eigentümer der Domain filmportal.de kann jederzeit Subdomains einrichten und an die IP-Adresse eines bestimmten Servers (z.B. den neu anzumietenden Server mit den RDF-Daten) konnektieren. Wenn das DFF die Domain als Eigentümer verwaltet, braucht Werk21 gar nicht bemüht werden.

Vokabular-URIs

Wenn diese mit abstrakten wie Ziffernfolgen als Bezeichner gebildet werden, sollte eine auf technischer Ebene mögliche Konfusion des Lokalteils mit Zahlenwerten vermieden werden. Beispielsweise wird der String "34" in Javascript zur Zahl 34 konvertiert, auch in Spreadsheets kann so etwas vorkommen. Viele RDF-basierte URI-Schemata setzen deshalb vor die Ziffernfolge einen Buchstaben, sodass der Lokalteil eines URI auch isoliert immer als String erkannt wird ("Q" bei Wikidata, "E" und "P" bei CIDOC-CRM, "sj", "n", "no" usw. bei LCSH, ...).

Für das ZDB-Vokabular würde sich anbieten, die Terme mit "T" und die Relatoren mit "R" zu kennzeichnen, beispielsweise "zdbvoc:Ehe_mit" -> "zdbvoc:R016"; "zdbvoc:Originaltitel" -> "zdbvoc:T003". Denkbar wäre auch, jeder skos:Collection (zusätzlich) einen eigenen Buchstaben zu geben, z.B. "TC" für terms->Credits; das entspräche dem Verfahren bei den LoC Authority Files.

„Hat …-Typ“-Properties

Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.

DB: die differenzierten Properties soll(t)en die Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen.

Mapping

Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/

DB: Ich hatte mir das vor einiger Zeit auch mal angesehen und kam zu dem Ergebnis, dass es für Datenbanken mit striktem ER-Modell (also für jede m:n-Relation eine eigene Kreuztabelle) wohl nützlich wäre. Die ZDB verwendet aber ein hybrides Datenmodell mit einer einzigen SPO-Tabelle für alle m:n-Relationen, die zudem keine klassische Kreuztabelle ist. Da habe ich nicht rausgefunden, wie das mit RML zu handhaben wäre.

URIs für unselbstständiuge Entitäten

Im Filmwerk-Entwurf von DB sind nur die UIDs für Entitäten Filmwerk, Person und Körperschaft als Filmportal-URIs dargestellt. Alles Andere wir das Blank Node behandelt, ist also nicht als eigene Ressource referenzierbar. Motivation hierfür war, dass auf diese Weise mittels SPARQL DESCRIBE ein nahezu kompletter Filmwerks-Datensatz konstruiert wird.

Der Entwurf von KR stellt alle UIDs der ZDB unter den öffentlichen Namensraum (fpde:). Damit wären auch unselbstständige Entitäten wie Aufführung, Manifestation, etc. als RDF-Ressource aus der LD-Sphäre abrufbar.

Mit dem Entwurf von KR lassen sich vollständige Filmwerks-Datensätze nur mit komplexen SPARQL-Abfragen erzeugen. Vgl. hierzu die aggregierte Datensicht in wikidata.org mit der von SPARQL DESCRIBE in query.wikidata.org; im ersten Fall wird die Datensicht unsichtbar im Hintergrund erzeugt, im zweiten Fall erhalten wir nur eine flache Liste der direkt verbundenen Tripel.

Fazit (DB): Der Vorschlag von KR ist technisch anspruchsvoller, bietet aber langfristig mehr Möglichkeiten für die Datenauswertung.

IDTitel versus Titel

Im Ontologie-Entwurf 0.4.1 ist die Property IDTitel entfernt worden; im Filmwerk-Entwurf wurde IDTitel durch hatTitel (...) ersetzt. Im ZDB-Datenmodell ist IDTitel absichtlich nicht als Instanz von Filmtitel modelliert, weil es hier als direkte, menschenlesbare Bezeichnung für das Filmwerk dient. Es ist ein einfacher String-Wert ohne weitere Eigenschaften. Bei der Erfassung wird der IDTitel automatisch aus den eigentlichen Titelangaben generiert und erfüllt nur den Zweck, das Filmwerk für menschliche Leser ohne SQL-Joins (und künftig in SPARQL ohne Property Chains) identifizierbar zu machen.

Laufendes

Neuer Server

Wie ist der Stand bei der Beschaffung?

Datensicherung

Gibt es Fortschritte in den Gesprächen mit der DFF-IT?