Jour fixe 2026-02-06: Unterschied zwischen den Versionen
(→Elementvokabulare) |
(→Elementvokabulare) |
||
| (17 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 7: | Zeile 7: | ||
Nach Absprache mit der DFF-IT konnte jetzt ein vorläufiger Triplestore mit Apache Jena Fuseki auf [http://ws.dff.film:3030/# ws.dff.film] eingerichtet werden. Unter dieser Adresse können wir jetzt die Linked-Data-Publikation der DFF-ZDB Stück für Stück entwickeln und testen. Das betrifft im einzelnen: | Nach Absprache mit der DFF-IT konnte jetzt ein vorläufiger Triplestore mit Apache Jena Fuseki auf [http://ws.dff.film:3030/# ws.dff.film] eingerichtet werden. Unter dieser Adresse können wir jetzt die Linked-Data-Publikation der DFF-ZDB Stück für Stück entwickeln und testen. Das betrifft im einzelnen: | ||
* die Filmportal-Ontologie als formales "Rückgrat" für die filmographischen Daten, | * die Filmportal-Ontologie als formales "Rückgrat" für die filmographischen Daten, | ||
| + | * [https://shacl.dev/ SHACL] als Validierungs-Instrument und zur erweiterten Spezifikation für alle RDF-Ressourcen | ||
* die Elementvokabulare im SKOS-Datenschema (s.u.) | * 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 | + | * 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? ==== | ||
| + | |||
| + | 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 === | === Elementvokabulare === | ||
| Zeile 15: | Zeile 20: | ||
Keines der bisher untersuchten Software-Werkzeuge zum Verwalten von SKOS-basierten Vokabularen hat bisher überzeugen können. DB schlägt vor, zunächst gar keine Thesaurus-Software einzusetzen, sondern SKOS-Datensätze direkt in RDF/Turtle zu editieren und diese mittel Git zu versionieren. | Keines der bisher untersuchten Software-Werkzeuge zum Verwalten von SKOS-basierten Vokabularen hat bisher überzeugen können. DB schlägt vor, zunächst gar keine Thesaurus-Software einzusetzen, sondern SKOS-Datensätze direkt in RDF/Turtle zu editieren und diese mittel Git zu versionieren. | ||
| − | Parallel hierzu ist die [https://metadaten.community/about Metadaten-Community] mit dem Projekt [https://skohub.io/ SkoHub] praktisch zum gleichen Ergebnis gekommen, indem vorgeschlagen wird, die Vokabulare direkt [https://github.com/hbz/lobid-vocabs/blob/master/how-to-edit/guide.md auf GitHub] zu editieren. | + | Parallel hierzu ist die [https://metadaten.community/about Metadaten-Community] mit dem Projekt [https://skohub.io/ SkoHub] praktisch zum gleichen Ergebnis gekommen, indem dort vorgeschlagen wird, die Vokabulare als RDF/Turtle direkt [https://github.com/hbz/lobid-vocabs/blob/master/how-to-edit/guide.md auf GitHub] zu editieren. |
| + | |||
| + | 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 === | ||
| + | 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. | ||
| + | |||
| + | |||
| − | + | === 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] | ||
Aktuelle Version vom 5. Februar 2026, 16:41 Uhr
Eine Seite aus dem Reformhaus
Inhaltsverzeichnis
Jour fixe, Freitag, 6. Februar 2026
RDF-Triplestore
Nach Absprache mit der DFF-IT konnte jetzt ein vorläufiger Triplestore mit Apache Jena Fuseki auf ws.dff.film eingerichtet werden. Unter dieser Adresse können wir jetzt die Linked-Data-Publikation der DFF-ZDB Stück für Stück entwickeln und testen. Das betrifft im einzelnen:
- die Filmportal-Ontologie als formales "Rückgrat" für die filmographischen Daten,
- SHACL als Validierungs-Instrument und zur erweiterten Spezifikation für alle RDF-Ressourcen
- die Elementvokabulare im SKOS-Datenschema (s.u.)
- 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 Zusammenwirken mit Wikidata und der GND.
Warum nicht Qlever?
Eine Reihe von neuen Linked-Data-Projekten hierzulande verwendet 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
Keines der bisher untersuchten Software-Werkzeuge zum Verwalten von SKOS-basierten Vokabularen hat bisher überzeugen können. DB schlägt vor, zunächst gar keine Thesaurus-Software einzusetzen, sondern SKOS-Datensätze direkt in RDF/Turtle zu editieren und diese mittel Git zu versionieren.
Parallel hierzu ist die Metadaten-Community mit dem Projekt SkoHub praktisch zum gleichen Ergebnis gekommen, indem dort vorgeschlagen wird, die Vokabulare als RDF/Turtle direkt auf GitHub zu editieren.
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
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.
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 Jour Fixe vom 5.12.2025
