Jour fixe 2026-02-06 - Versionsgeschichte

Dbalzer: /* Elementvokabulare */

2026-02-05T16:41:13Z

‎Elementvokabulare

Bsedmak am 4. Februar 2026 um 13:18 Uhr

2026-02-04T13:18:21Z

Dbalzer: /* Warum nicht Qlever? */

2026-02-04T09:07:25Z

‎Warum nicht Qlever?

Dbalzer: /* Warum nicht Qlever? */

2026-02-04T09:02:09Z

‎Warum nicht Qlever?

Dbalzer: /* Relatoren-Tabelle */

2026-02-04T08:27:50Z

‎Relatoren-Tabelle

Dbalzer: /* Elementvokabulare */

2026-02-03T19:35:06Z

‎Elementvokabulare

Dbalzer: /* Warum nicht Qlever? */

2026-02-03T19:30:52Z

‎Warum nicht Qlever?

Dbalzer: /* Warum nicht Qlever? */

2026-02-03T19:28:48Z

‎Warum nicht Qlever?

Dbalzer: /* RDF-Triplestore */

2026-02-03T19:27:59Z

‎RDF-Triplestore

Dbalzer: /* Warum nicht Qlever? */

2026-02-03T19:25:11Z

‎Warum nicht Qlever?

← Nächstältere Version		Version vom 5. Februar 2026, 16:41 Uhr
Zeile 23:		Zeile 23:

	Im Unterschied zu SkoHub können wir die Vokabulardaten zunächst im Triplestore editieren und dort auf Konformität testen, bevor wir sie versioniert ins DFF-Gitlab einchecken. Daran anschließend kann überlegt werden, über welche öffentlichen Vokabularplattformen (BARTOC, SkoHub, etc.) oder NFDI-Dienste die DFF-Vokabulare öffentlich zugänglich gemacht werden sollen.		Im Unterschied zu SkoHub können wir die Vokabulardaten zunächst im Triplestore editieren und dort auf Konformität testen, bevor wir sie versioniert ins DFF-Gitlab einchecken. Daran anschließend kann überlegt werden, über welche öffentlichen Vokabularplattformen (BARTOC, SkoHub, etc.) oder NFDI-Dienste die DFF-Vokabulare öffentlich zugänglich gemacht werden sollen.
		+
		+	=== Ontologie ===
		+
		+	Im aktuellen Entwurf von Kristina sind die verschiedenen Arten von Manifestationen, Filmtiteln und Aufführungen als Klassen modelliert. Ich (DB) würde dagegen vorschlagen, diese Unterscheidungen nicht durch Subklassierung sondern mit dem Typvokabular vorzunehmen. Gründe dafür:
		+
		+	* bei diesen Unterklassen kann es eher vorkommen, dass zukünftig neue Unterscheidungen gewünscht werden als bei der jeweiligen Oberklasse. Wir hätten deshalb hier eine Grauzone zwischen langfristig stabiler Ontologie und den von vornherein auf Erweiterbarkeit angelegten Typvokabularen.
		+
		+	* Die definierten Einzelmerkmale von Manifestationen, Titeln und Aufführungen sind im ZDB-Modell für alle Unterarten gleich. Die Modellierung als separate Klassen würde keinen zusätzlichen semantischen Nutzen bringen.

	=== Relatoren-Tabelle ===		=== Relatoren-Tabelle ===

← Nächstältere Version		Version vom 4. Februar 2026, 13:18 Uhr
Zeile 33:		Zeile 33:

	Die Umwandlung soll für jedes der betreffenden Aggregatwerke einzeln erfolgen, damit sie vorher jeweils einzeln in einer ZDB-Kopie getestet werden kann.		Die Umwandlung soll für jedes der betreffenden Aggregatwerke einzeln erfolgen, damit sie vorher jeweils einzeln in einer ZDB-Kopie getestet werden kann.
		+
		+
		+
		+	=== Wiedervorlage: Serverspezifikationen ===
		+	Da David heute nicht dabei sein kann, hat er mich um Wiedervorlage gebeten. Gern kannst du, Detlev, die Serverspezifikationen hier rein schreiben. Siehe [https://filmstandards.org/difzf/index.php?title=Jour_fixe_2025-12-05#Status_Server-Administration Jour Fixe vom 5.12.2025]

@@ Zeile 14: / Zeile 14: @@
 ==== Warum nicht Qlever? ====
-Eine Reihe von neuen Linked-Data-Projekten hierzulande verwendet [https://en.wikipedia.org/wiki/QLever Qlever] als Triplestore. Das DFF könnte gefragt werden, warum wir nicht "Made in Germany" verwenden. Von einer Installation für das DFF habe ich (DB) zunächst abgesehen, weil sich das Projekt noch in einer Entwicklungsphase mit für uns wenig relevanten Prioritäten befindet und die Unterstützung von RDF Named Graphs bisher nur angekündigt, aber nicht realisiert ist. Außerdem fehlen der Web-basierten SPARQL-Schnittstelle (z.B. https://sparql.dnb.de/ ) noch viele für effektives Arbeiten unentbehrliche Merkmale.
+Eine Reihe von neuen Linked-Data-Projekten hierzulande verwendet [https://en.wikipedia.org/wiki/QLever Qlever] als Triplestore. Das DFF könnte gefragt werden, warum wir nicht "Made in Germany" verwenden. Von einer Installation für das DFF habe ich (DB) zunächst abgesehen, weil sich das Projekt noch in einer Entwicklungsphase mit für uns wenig relevanten Prioritäten befindet und die Unterstützung von RDF Named Graphs bisher nur angekündigt, aber nicht realisiert ist. Außerdem fehlen der Web-basierten SPARQL-Schnittstelle (z.B. https://sparql.dnb.de/ ) noch einige für effektives Arbeiten unentbehrliche Merkmale.
 === Elementvokabulare ===

@@ Zeile 14: / Zeile 14: @@
 ==== Warum nicht Qlever? ====
-Eine Reihe von neuen Linked-Data-Projekten hierzulande verwendet [https://en.wikipedia.org/wiki/QLever Qlever] als Triplestore. Von einer Installation für das DFF habe ich (DB) zunächst abgesehen, weil sich das Projekt noch in einer Entwicklungsphase mit für uns wenig relevanten Prioritäten befindet und die Unterstützung von RDF Named Graphs bisher nur angekündigt, aber nicht realisiert ist. Außerdem fehlen der Web-basierten SPARQL-Schnittstelle (z.B. https://sparql.dnb.de/ ) noch viele für effektives Arbeiten unentbehrliche Merkmale.
+Eine Reihe von neuen Linked-Data-Projekten hierzulande verwendet [https://en.wikipedia.org/wiki/QLever Qlever] als Triplestore. Das DFF könnte gefragt werden, warum wir nicht "Made in Germany" verwenden. Von einer Installation für das DFF habe ich (DB) zunächst abgesehen, weil sich das Projekt noch in einer Entwicklungsphase mit für uns wenig relevanten Prioritäten befindet und die Unterstützung von RDF Named Graphs bisher nur angekündigt, aber nicht realisiert ist. Außerdem fehlen der Web-basierten SPARQL-Schnittstelle (z.B. https://sparql.dnb.de/ ) noch viele für effektives Arbeiten unentbehrliche Merkmale.
 === Elementvokabulare ===

← Nächstältere Version		Version vom 4. Februar 2026, 08:27 Uhr
Zeile 26:		Zeile 26:
	=== Relatoren-Tabelle ===		=== Relatoren-Tabelle ===
	Aus der Tabelle mit Änderungsvorschlägen habe ich (DB) bisher noch nichts in die ZDB übernommen, weil ich an mehreren Stellen noch nicht ganz klar sehe. Vielleicht lässt sich das hier schon klären.		Aus der Tabelle mit Änderungsvorschlägen habe ich (DB) bisher noch nichts in die ZDB übernommen, weil ich an mehreren Stellen noch nicht ganz klar sehe. Vielleicht lässt sich das hier schon klären.
		+
		+	=== Syntax-Korrektur Ordnungsdatum ===
		+	DB hat ein Roboter-Skript vorbereitet, aber noch nicht auf die Live-Datenbank angewandt. Die Vorgehensweise ist so:
		+
		+	Wo die Folge bzw. Ausgabe im Titel angegeben ist (Bsp. "Pioniermonatsschau [Jg. 1951 / Nr. 07]") wird diese ausgelesen und in das Element "RelAnm" der Relation zum Gesamttitel übernommen, so wie es bei vielen Serienwerken schon der Fall ist. In der Auflistung zum Gesamttitel ergibt das zwar eine Dopplung der Aussage, aber die Auflistung kann jetzt nach den Folgenummern innerhalb eines Jahres aufsteigend sortiert werden. Damit entfällt die Notwendigkeit, die Reihenfolge über ein modifiziertes Ordnungsdatum ausdrücken zu wollen.
		+
		+	Die Umwandlung soll für jedes der betreffenden Aggregatwerke einzeln erfolgen, damit sie vorher jeweils einzeln in einer ZDB-Kopie getestet werden kann.

← Nächstältere Version		Version vom 3. Februar 2026, 19:35 Uhr
Zeile 23:		Zeile 23:

	Im Unterschied zu SkoHub können wir die Vokabulardaten zunächst im Triplestore editieren und dort auf Konformität testen, bevor wir sie versioniert ins DFF-Gitlab einchecken. Daran anschließend kann überlegt werden, über welche öffentlichen Vokabularplattformen (BARTOC, SkoHub, etc.) oder NFDI-Dienste die DFF-Vokabulare öffentlich zugänglich gemacht werden sollen.		Im Unterschied zu SkoHub können wir die Vokabulardaten zunächst im Triplestore editieren und dort auf Konformität testen, bevor wir sie versioniert ins DFF-Gitlab einchecken. Daran anschließend kann überlegt werden, über welche öffentlichen Vokabularplattformen (BARTOC, SkoHub, etc.) oder NFDI-Dienste die DFF-Vokabulare öffentlich zugänglich gemacht werden sollen.
		+
		+	=== Relatoren-Tabelle ===
		+	Aus der Tabelle mit Änderungsvorschlägen habe ich (DB) bisher noch nichts in die ZDB übernommen, weil ich an mehreren Stellen noch nicht ganz klar sehe. Vielleicht lässt sich das hier schon klären.

@@ Zeile 9: / Zeile 9: @@
 * [https://shacl.dev/ SHACL] als Validierungs-Instrument und zur erweiterten Spezifikation für alle RDF-Ressourcen
 * die Elementvokabulare im SKOS-Datenschema (s.u.)
-* die Filmwerks-Datensätze als RDF-basierte Linked-Data-Ressourcen
+* die Filmwerks- und Agent-Datensätze als RDF-basierte Linked-Data-Ressourcen
-* die sich daraus ergebenden Möglichkeiten für neue Dienste im Linked-Data-Umfeld, besonders im Zusammenhang mit Wikidata und der GND.
+* die sich daraus ergebenden Möglichkeiten für neue Dienste im Linked-Data-Umfeld, besonders im Zusammenwirken mit Wikidata und der GND.
 ==== Warum nicht Qlever? ====