Jour fixe 2026-08-28
Eine Seite aus dem Reformhaus
Inhaltsverzeichnis
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?
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.
„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/