Jour fixe 2026-08-28 - Versionsgeschichte

Dbalzer: /* URIs für unselbstständiuge Entitäten */

2026-08-25T20:41:49Z

‎URIs für unselbstständiuge Entitäten

Dbalzer: /* Mapping */

2026-08-24T21:12:43Z

‎Mapping

Dbalzer: /* zdbvoc:P1 / zdbvoc:P2 */

2026-08-24T20:43:10Z

‎zdbvoc:P1 / zdbvoc:P2

Dbalzer: /* Geografika */

2026-08-24T20:37:34Z

‎Geografika

Dbalzer: /* „Hat …-Typ“-Properties */

2026-08-24T20:07:04Z

‎„Hat …-Typ“-Properties

Dbalzer: /* „Hat …-Typ“-Properties */

2026-08-24T20:06:18Z

‎„Hat …-Typ“-Properties

Dbalzer: /* Entitäten-URIs */

2026-08-24T19:57:57Z

‎Entitäten-URIs

Krose am 19. August 2026 um 08:29 Uhr

2026-08-19T08:29:28Z

Krose am 18. August 2026 um 11:30 Uhr

2026-08-18T11:30:09Z

Krose: /* Jour fixe, Freitag, 28. August 2026 */

2026-08-17T15:06:33Z

‎Jour fixe, Freitag, 28. August 2026

← Nächstältere Version		Version vom 25. August 2026, 20:41 Uhr
Zeile 60:		Zeile 60:

	Lassen sich Nachteile für den Entwurf von KR finden? (DB vermutet: nein)		Lassen sich Nachteile für den Entwurf von KR finden? (DB vermutet: nein)
		+
		+	==== IDTitel versus Titel ====
		+
		+	Im Ontologie-Entwurf 0.4.1 ist die Property IDTitel entfernt worden; im Filmwerk-Entwurf 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.

← Nächstältere Version		Version vom 24. August 2026, 21:12 Uhr
Zeile 52:		Zeile 52:
	==== 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/
		+
		+	==== 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 ist mit einem Blank-Node-Prefix versehen, also nicht als eigene Ressource referenzierbar.
		+
		+	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.
		+
		+	Lassen sich Nachteile für den Entwurf von KR finden? (DB vermutet: nein)

@@ Zeile 32: / Zeile 32: @@
 ==== 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.
 ==== Entitäten-URIs ====

@@ Zeile 10: / Zeile 10: @@
 ==== Geografika ====
 Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?
 ==== Ranges und Domains ====

@@ Zeile 44: / Zeile 44: @@
 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 für 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.  ''
+''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/

@@ Zeile 34: / Zeile 34: @@
 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?
 ==== „Hat …-Typ“-Properties ====

← Nächstältere Version		Version vom 19. August 2026, 08:29 Uhr
Zeile 37:		Zeile 37:
	==== „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.
		+
		+	==== 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/

← Nächstältere Version		Version vom 17. August 2026, 15:06 Uhr
Zeile 3:		Zeile 3:
	== Jour fixe, Freitag, 28. August 2026 ==		== Jour fixe, Freitag, 28. August 2026 ==

−	~~Themenwüsche bitte~~ hier ~~notieren~~.	+	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?
		+
		+	=== 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.
		+
		+	=== 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?
		+
		+	=== „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.