Jour fixe 2026-08-28: Unterschied zwischen den Versionen
Krose (Diskussion | Beiträge) |
Krose (Diskussion | Beiträge) |
||
| (24 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
| Zeile 10: | Zeile 10: | ||
==== Geografika ==== | ==== Geografika ==== | ||
Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen? | 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 ==== | ==== Ranges und Domains ==== | ||
| Zeile 27: | Zeile 29: | ||
rdfs:domain zdb:Beteiligung . | rdfs:domain zdb:Beteiligung . | ||
Eigentlich ist rdfs:range ja aber zdb:Funktion, oder? | 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 ==== | ==== 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. | 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 ==== | ==== 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 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? | 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. "RC" für rels->Credits; das entspräche dem Verfahren bei den LoC Authority Files. | ||
| + | |||
| + | ''KR: finde ich gut!'' | ||
==== „Hat …-Typ“-Properties ==== | ==== „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. | 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. '' | ||
| + | |||
| + | ''KR: dann lasse ich die Superproperty zdb:hatTyp drin und wir können die Subproperties später noch rausschmeißen, wenn sie nicht benötigt werden.'' | ||
==== Mapping ==== | ==== 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/ | 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 [https://www.wikidata.org/wiki/Q1273863 aggregierte Datensicht] in wikidata.org mit der von [https://query.wikidata.org/#DESCRIBE%20wd%3AQ1273863 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. Im Übrigen wird die Komplexität für vollständige Filmwerks-Ansichten mit SPARQL nicht wesentlich anders sein als die mit den (im Hintergrund ablaufenden) SQL-Abfragen in der ZDB. | ||
| + | |||
| + | ''KR: wäre das auch komplexer, die Ansicht auf diesen Seiten komplett darzustellen? https://ws.dff.film/ld-svc/sparql-ui/svc/tsproxy.php?filmstandards.org/vocab/dff/credit/Bauten ?'' | ||
| + | |||
| + | ==== 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. | ||
| + | |||
| + | ''KR: Alles klar, ich verstehe! Dann brauchen wir de Titeltyp "Identifying title" nicht? Oder würdest du den IDTitel zusätzlich dorthin mappen? | ||
| + | '' | ||
| + | === Laufendes === | ||
| + | |||
| + | ==== Neuer Server ==== | ||
| + | |||
| + | Wie ist der Stand bei der Beschaffung? | ||
| + | |||
| + | ==== Datensicherung ==== | ||
| + | |||
| + | Gibt es Fortschritte in den Gesprächen mit der DFF-IT? | ||
| + | |||
| + | ''KR: bisher ist die IT schwer zu erreichen, was die Rückmeldung zum Betriebskonzept allgemein betrifft. Für die ZDB spezifisch werden wir nochmal nachhaken, wie die Bachup-Situation aussieht.'' | ||
Aktuelle Version vom 28. August 2026, 12:19 Uhr
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?
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. "RC" für rels->Credits; das entspräche dem Verfahren bei den LoC Authority Files.
KR: finde ich gut!
„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.
KR: dann lasse ich die Superproperty zdb:hatTyp drin und wir können die Subproperties später noch rausschmeißen, wenn sie nicht benötigt werden.
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. Im Übrigen wird die Komplexität für vollständige Filmwerks-Ansichten mit SPARQL nicht wesentlich anders sein als die mit den (im Hintergrund ablaufenden) SQL-Abfragen in der ZDB.
KR: wäre das auch komplexer, die Ansicht auf diesen Seiten komplett darzustellen? https://ws.dff.film/ld-svc/sparql-ui/svc/tsproxy.php?filmstandards.org/vocab/dff/credit/Bauten ?
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.
KR: Alles klar, ich verstehe! Dann brauchen wir de Titeltyp "Identifying title" nicht? Oder würdest du den IDTitel zusätzlich dorthin mappen?
Laufendes
Neuer Server
Wie ist der Stand bei der Beschaffung?
Datensicherung
Gibt es Fortschritte in den Gesprächen mit der DFF-IT?
KR: bisher ist die IT schwer zu erreichen, was die Rückmeldung zum Betriebskonzept allgemein betrifft. Für die ZDB spezifisch werden wir nochmal nachhaken, wie die Bachup-Situation aussieht.
