Jour fixe 2026-08-28 - Versionsgeschichte

Krose am 28. August 2026 um 12:19 Uhr

2026-08-28T12:19:52Z

Dbalzer: /* Vokabular-URIs */

2026-08-27T19:46:08Z

‎Vokabular-URIs

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

2026-08-27T19:39:21Z

‎URIs für unselbstständiuge Entitäten

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

2026-08-27T19:27:09Z

‎URIs für unselbstständiuge Entitäten

Dbalzer: /* Vokabular-URIs */

2026-08-27T15:56:26Z

‎Vokabular-URIs

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

2026-08-27T15:32:00Z

‎URIs für unselbstständiuge Entitäten

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

2026-08-27T15:03:43Z

‎URIs für unselbstständiuge Entitäten

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

2026-08-27T15:02:30Z

‎URIs für unselbstständiuge Entitäten

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

2026-08-27T14:58:46Z

‎URIs für unselbstständiuge Entitäten

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

2026-08-27T14:52:37Z

‎URIs für unselbstständiuge Entitäten

@@ Zeile 54: / Zeile 54: @@
 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.
 ==== „Hat …-Typ“-Properties ====
@@ Zeile 59: / Zeile 61: @@
 ''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 ====
@@ Zeile 74: / Zeile 78: @@
 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.
 ==== IDTitel versus Titel ====
@@ Zeile 79: / Zeile 85: @@
 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 ===
@@ Zeile 88: / Zeile 96: @@
 Gibt es Fortschritte in den Gesprächen mit der DFF-IT?

@@ Zeile 53: / Zeile 53: @@
 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.
+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.
 ==== „Hat …-Typ“-Properties ====

@@ Zeile 73: / Zeile 73: @@
 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.
+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.
 ==== IDTitel versus Titel ====

@@ Zeile 71: / Zeile 71: @@
 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: Komplette Filmwerks-Datensätze lassen sich nur mit SPARQL CONSTRUCT-Abfragen erzeugen; vgl. 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)
+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.

@@ Zeile 51: / Zeile 51: @@
 ==== 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 immer als String erkannt wird ("Q" bei Wikidata, "E" und "P" bei CIDOC-CRM, "sj", "n", "no" usw. bei LCSH, ...).
+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.

← Nächstältere Version		Version vom 27. August 2026, 15:02 Uhr
Zeile 72:		Zeile 72:

	Lassen sich Nachteile für den Entwurf von KR finden? (DB: Komplette Filmwerks-Datensätze lassen sich nur mit SPARQL CONSTRUCT-Abfragen erzeugen; vgl. 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)		Lassen sich Nachteile für den Entwurf von KR finden? (DB: Komplette Filmwerks-Datensätze lassen sich nur mit SPARQL CONSTRUCT-Abfragen erzeugen; vgl. 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)
		+
		+	Fazit (DB): Der Vorschlag von KR ist technisch anspruchsvoller, beiet aber langfristig mehr Möglichkeiten für die Datenauswertung.

	==== IDTitel versus Titel ====		==== IDTitel versus Titel ====

@@ Zeile 67: / Zeile 67: @@
 ==== 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.
+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.
-Lassen sich Nachteile für den Entwurf von KR finden? (DB vermutet: nein)
+Lassen sich Nachteile für den Entwurf von KR finden? (DB: Komplette Filmwerks-Datensätze lassen sich nur mit SPARQL CONSTRUCT-Abfragen erzeugen)
 ==== IDTitel versus Titel ====