https://filmstandards.org/difzf/api.php?action=feedcontributions&feedformat=atom&user=Dbalzer 2026-05-12T16:02:21Z Benutzerbeiträge MediaWiki 1.31.7 https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-05-08&diff=1579 2026-05-08T12:39:22Z

<p>Dbalzer: /* Sinkende Zahl der WD-Identifier */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 8. Mai 2026 ==<br /> <br /> Von DB dieses Mal wenig Neues, weil im April zu sehr anderweitig beschäftigt. Immerhin gibt es jetzt die versprochene [https://ws.dff.film/ld-svc/sparql-ui/sparql.html SPARQL-Werkbank], allerdings erst mit den wenigen bisher vorhandenen Vokabular-Testdaten.<br /> <br /> Weitere Themenwüsche bitte hier notieren.<br /> <br /> === Rang während Verknüpfung PS/KS &lt;=&gt; FW vergeben === <br /> wäre es prinzipiell möglich, dass man den Rang schon während der Relationen vergibt? Momentan findet die Sortierung nach der Verknüpfung statt (Defaultwert = 0). Wäre das unaufwändiger als die Entwicklung der &quot;Wahlwiederholung&quot;? <br /> <br /> <br /> === Sinkende Zahl der WD-Identifier === <br /> Im Vergleich zum letzten Jahr sind die WD-Identifier gesunken - das hat mich ein bisschen gewundert: <br /> <br /> 2025 (Stand Juli) =&gt; 2026 (Stand Mai)&lt;br&gt;<br /> Personen: 153.090 =&gt; 252.703 &lt;br&gt;<br /> Filmwerke: 20.419 =&gt; 12.937&lt;br&gt;<br /> <br /> Quelle: in beiden Fällen https://zdb.dff.film/fdb/synop_extids.php<br /> <br /> DB: 252.703 ist die aktuelle Zahl der GND-Identifier für Personen. Am 14-Feb-2022 waren erstmals 5.383 WD-Matchings übernommen worden, danach folgten weitere Matchings und jetzt sind es 152.720.<br /> <br /> Aktuelle Zahl der WD-Identifier für Filmwerke ist korrekt; am 14-Feb-2022 waren erstmals 12.932 WD-Matchings übernommen worden, jetzt sind es 12.937.<br /> <br /> Möglicherweise lag im Juli 2025 ein Bug in der Statusübersicht vor.<br /> <br /> === Rückfrage: Verlinkung Filmportal.de auf externe Seiten === <br /> https://filmstandards.org/difzf/index.php?title=Jour_fixe_2025-06-13#Verlinkungen_von_Portal_auf_externe_Seiten<br /> <br /> Die erwähnte Seite von Imme Klages https://www.filmexil.de/ wurde nun gelauncht. Habe ich korrekt im Kopf, dass die Verlinkungen bei W21 liegen? <br /> <br /> <br /> === Nächster Jourfixe ===<br /> Aufgrund des Brückentages am 5.6. bietet sich ein Verschieben auf den 12.6.2026 an. Bianca wäre allerdings nicht dabei.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-05-08&diff=1578 2026-05-08T12:37:30Z

<p>Dbalzer: /* Sinkende Zahl der WD-Identifier */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 8. Mai 2026 ==<br /> <br /> Von DB dieses Mal wenig Neues, weil im April zu sehr anderweitig beschäftigt. Immerhin gibt es jetzt die versprochene [https://ws.dff.film/ld-svc/sparql-ui/sparql.html SPARQL-Werkbank], allerdings erst mit den wenigen bisher vorhandenen Vokabular-Testdaten.<br /> <br /> Weitere Themenwüsche bitte hier notieren.<br /> <br /> === Rang während Verknüpfung PS/KS &lt;=&gt; FW vergeben === <br /> wäre es prinzipiell möglich, dass man den Rang schon während der Relationen vergibt? Momentan findet die Sortierung nach der Verknüpfung statt (Defaultwert = 0). Wäre das unaufwändiger als die Entwicklung der &quot;Wahlwiederholung&quot;? <br /> <br /> <br /> === Sinkende Zahl der WD-Identifier === <br /> Im Vergleich zum letzten Jahr sind die WD-Identifier gesunken - das hat mich ein bisschen gewundert: <br /> <br /> 2025 (Stand Juli) =&gt; 2026 (Stand Mai)&lt;br&gt;<br /> Personen: 153.090 =&gt; 252.703 &lt;br&gt;<br /> Filmwerke: 20.419 =&gt; 12.937&lt;br&gt;<br /> <br /> Quelle: in beiden Fällen https://zdb.dff.film/fdb/synop_extids.php<br /> <br /> DB: 252.703 ist die aktuelle Zahl der GND-Identifier für Personen. Am 14-Feb-2022 waren erstmals 5.383 Matchings übernommen worden, danach folgten weitere Matchings und jetzt sind es 152.720.<br /> <br /> Aktuelle Zahl der WD-Identifier für Filmwerke ist korrekt; am 14-Feb-2022 waren erstmals 12.932 Matchings übernommen worden, jetzt sind es 12.937.<br /> <br /> Möglicherweise lag im Juli 2025 ein Bug in der Statusübersicht vor.<br /> <br /> === Rückfrage: Verlinkung Filmportal.de auf externe Seiten === <br /> https://filmstandards.org/difzf/index.php?title=Jour_fixe_2025-06-13#Verlinkungen_von_Portal_auf_externe_Seiten<br /> <br /> Die erwähnte Seite von Imme Klages https://www.filmexil.de/ wurde nun gelauncht. Habe ich korrekt im Kopf, dass die Verlinkungen bei W21 liegen? <br /> <br /> <br /> === Nächster Jourfixe ===<br /> Aufgrund des Brückentages am 5.6. bietet sich ein Verschieben auf den 12.6.2026 an. Bianca wäre allerdings nicht dabei.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-05-08&diff=1574 2026-05-07T06:04:14Z

<p>Dbalzer: /* Jour fixe, Freitag, 8. Mai 2026 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 8. Mai 2026 ==<br /> <br /> Von DB dieses Mal wenig Neues, weil im April zu sehr anderweitig beschäftigt. Immerhin gibt es jetzt die versprochene [https://ws.dff.film/ld-svc/sparql-ui/sparql.html SPARQL-Werkbank], allerdings erst mit den wenigen bisher vorhandenen Vokabular-Testdaten.<br /> <br /> Weitere Themenwüsche bitte hier notieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-05-08&diff=1573 2026-05-05T15:35:44Z

<p>Dbalzer: Die Seite wurde neu angelegt: „Eine Seite aus dem Reformhaus == Jour fixe, Freitag, 8. Mai 2026 ==“</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 8. Mai 2026 ==</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Reformhaus&diff=1572 2026-05-05T15:34:03Z

<p>Dbalzer: /* Telekonferenzen zu anstehenden Themen */</p> <hr /> <div>Fortlaufende Aktivitäten zur Anpassung und Weiterentwicklung der Filmografie-Datenbank und zugehöriger Datendienste des DFF<br /> <br /> === Telekonferenzen zu anstehenden Themen ===<br /> <br /> * '''[[Jour fixe 2026-05-08]]''' - Diskussionspunkte<br /> * [[Jour fixe 2026-04-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-03-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-02-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-01-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-12-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-11-07]] - Diskussionspunkte<br /> * ''[[Jour fixe 2025-10-10]]'' - vertagt<br /> * [[Jour fixe 2025-09-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-07-11]] - Diskussionspunkte<br /> * [[Jour fixe 2025-06-13]] - Diskussionspunkte<br /> * [[Jour fixe 2025-05-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-04-04]] - Diskussionspunkte<br /> * [[Jour fixe 2025-03-07]] - Diskussionspunkte<br /> * [[Jour fixe 2025-02-07]] - Diskussionspunkte zur Prioritäten-Findung<br /> <br /> === Laufendes ===<br /> <br /> * [[Elementvokabulare]] - Neuorganisation als Linked Data-Ressource<br /> <br /> * [[Zeitangaben in RDF]] - Standard-konforme Darstellung für Linked Data<br /> <br /> * [[Geografika in RDF]] - URIs für Länder und Regionen<br /> <br /> * [[Ergänzung des Datenschemas]] - Neue Relatoren<br /> <br /> * [[Bereinigung des Datenschemas]] - Entfernen nicht (mehr) benötigter Entitäten und Relationen; Änderungen an Eigenschaften und Datentypen<br /> <br /> * [[Erweiterungswünsche]] für die ZDB-Bearbeitung</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1567 2026-04-09T21:12:59Z

<p>Dbalzer: /* Syntaktisch falsche Ordnungsdatum-Angaben */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.<br /> <br /> === Elementvokabulare ===<br /> <br /> Kristinas Fragen hierzu finden sich auf der Seite [[Elementvokabulare]] unter 2 - Diskussion, zusammen mit Anmerkungen von DB.<br /> <br /> Der SPARQL-Zugang via https ist durch ein automatisches Update auf dem Server verlorengegangen. Das macht nichts, denn wir können künftig auf eine eigene Schnittstelle zurückgreifen, die ich (DB) ursprünglich mal für die LIDO-Terminologie entwickelt habe. Die lässt sich, wie lokale Tests zeigen, gut fürs DFF adaptieren.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 7.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll. Also denen, die bisher Ordnungsdatierungen wie JJJJ-00-13 oder JJJJ-13-00 haben.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.<br /> <br /> In der Änderungsprotokoll-Ansicht gabe es häufig Mehrfacheinträge, wenn an einer Entität mehrere Änderungen an einem Tag vorgenommen wurden. Das ist jetzt behoben.<br /> <br /> === Tombstones / Deprecation ===<br /> <br /> (Kristina) Bisher werden Datensätze, die gelöscht werden, ja komplett entfernt und der Link führt nur zur Info, dass der Datensatz nicht existiert. Wäre es mit Blick auf die Schnittstelle (und eigentlich auch filmportal.de) nicht besser, eine Art Tombstone-Datensatz zu haben, der die Info gibt, wann der Datensatz gelöscht wurde oder sogar eine Weiterleitung, wenn Datensätze zusammengelegt wurden (im Fall von Dubletten)?<br /> <br /> === Werkvorlage und Musikwerk ===<br /> <br /> (Kristina) Wir hatten das Thema schon relativ abgeschlossen, aber ich würde gerne noch einmal zur Debatte stellen, ob es sich fur jeweils ca. 30 Datensätze dieser beiden Entitäten lohnt, diese weiter mitzuführen. Ich hatte es nicht so verstanden, dass in Zukunft wieder aktiv Werksvorlagen und Musikwerke als eigene Entitäten erfasst werden und habe ich gefragt, was dann der Mehrwert ist.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1564 2026-04-08T09:58:30Z

<p>Dbalzer: /* Elementvokabulare */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.<br /> <br /> === Elementvokabulare ===<br /> <br /> Kristinas Fragen hierzu finden sich auf der Seite [[Elementvokabulare]] unter 2 - Diskussion, zusammen mit Anmerkungen von DB.<br /> <br /> Der SPARQL-Zugang via https ist durch ein automatisches Update auf dem Server verlorengegangen. Das macht nichts, denn wir können künftig auf eine eigene Schnittstelle zurückgreifen, die ich (DB) ursprünglich mal für die LIDO-Terminologie entwickelt habe. Die lässt sich, wie lokale Tests zeigen, gut fürs DFF adaptieren.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll. Also denen, die bisher Ordnungsdatierungen wie JJJJ-00-13 oder JJJJ-13-00 haben.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.<br /> <br /> In der Änderungsprotokoll-Ansicht gabe es häufig Mehrfacheinträge, wenn an einer Entität mehrere Änderungen an einem Tag vorgenommen wurden. Das ist jetzt behoben.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1563 2026-04-08T09:53:57Z

<p>Dbalzer: /* Elementvokabulare */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.<br /> <br /> === Elementvokabulare ===<br /> <br /> Kristinas Fragen hierzu finden sich auf der Seite [[Elementvokabulare]] unter 2 - Diskussion, zusammen mit Anmerkungen von DB.<br /> <br /> Der SPARQL-Zugang via https ist durch ein automatisches Update auf dem alten Server verlorengegangen. Das macht nichts, denn wir können künftig auf eine eigene Schnittstelle zurückgreifen, die ich (DB) ursprünglich mal für die LIDO-Terminologie entwickelt habe. Die lässt sich, wie lokale Tests zeigen, gut fürs DFF adaptieren.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll. Also denen, die bisher Ordnungsdatierungen wie JJJJ-00-13 oder JJJJ-13-00 haben.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.<br /> <br /> In der Änderungsprotokoll-Ansicht gabe es häufig Mehrfacheinträge, wenn an einer Entität mehrere Änderungen an einem Tag vorgenommen wurden. Das ist jetzt behoben.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1562 2026-04-08T09:52:36Z

<p>Dbalzer: /* Syntaktisch falsche Ordnungsdatum-Angaben */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.<br /> <br /> === Elementvokabulare ===<br /> <br /> Kristinas Fragen hierzu finden sich in [[Elementvokabulare]] unter 2 - Diskussion, zusammen mit Anmerkungen von DB.<br /> <br /> Der SPARQL-Zugang via https ist durch ein automatisches Update auf dem alten Server verlorengegangen. Das macht nichts, denn wir können künftig auf eine eigene Schnittstelle zurückgreifen, die ich (DB) ursprünglich mal für die LIDO-Terminologie entwickelt habe. Die lässt sich, wie lokale Tests zeigen, gut fürs DFF adaptieren.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll. Also denen, die bisher Ordnungsdatierungen wie JJJJ-00-13 oder JJJJ-13-00 haben.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.<br /> <br /> In der Änderungsprotokoll-Ansicht gabe es häufig Mehrfacheinträge, wenn an einer Entität mehrere Änderungen an einem Tag vorgenommen wurden. Das ist jetzt behoben.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1561 2026-04-08T09:49:15Z

<p>Dbalzer: /* Jour fixe, Freitag, 10. April 2026 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.<br /> <br /> === Elementvokabulare ===<br /> <br /> Kristinas Fragen hierzu finden sich in [[Elementvokabulare]] unter 2 - Diskussion, zusammen mit Anmerkungen von DB.<br /> <br /> Der SPARQL-Zugang via https ist durch ein automatisches Update auf dem alten Server verlorengegangen. Das macht nichts, denn wir können künftig auf eine eigene Schnittstelle zurückgreifen, die ich (DB) ursprünglich mal für die LIDO-Terminologie entwickelt habe. Die lässt sich, wie lokale Tests zeigen, gut fürs DFF adaptieren.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.<br /> <br /> In der Änderungsprotokoll-Ansicht gabe es häufig Mehrfacheinträge, wenn an einer Entität mehrere Änderungen an einem Tag vorgenommen wurden. Das ist jetzt behoben.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1560 2026-04-08T09:29:18Z

<p>Dbalzer: /* Diskussion */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Plan ==<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) vom neu einzurichtenden Vokabulardienst beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.<br /> <br /> == Diskussion ==<br /> <br /> * KR: Ich hatte bei der RDF-Version der ZDB-Daten immer insbesondere externe Nutzer und Nutzerinnen vor Augen. Diese benötigen Informationen/Properties wie skos:notation mit dem Rang des Credits, zdbvoc:P1 und zdbvoc:P2 mit Informationen zur Darstellung in Benutzeroberflächen ja gar nicht, oder? Vielleicht können wir hier noch etwas reduzieren. Die Reihenfolge von Credits, im Sinne der Nennung im Abspann, könnte man ja eher noch als weitere Property von zdb:Beteiligung modellieren?<br /> ** DB: Wenn wir Properties für P1/P2 und dergleichen rauslassen, brauchen wir einen anderen Ort dafür. Der Vorteil, alle für die ZDB-Bearbeitung nötigen Deklarationen mit einer RDF-Abfrage zu bekommen, wäre dann nicht mehr gegeben. Solche &quot;betriebsinternen&quot; Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird. Vokabular-APIs können darüber hinaus auch mit Profilen (short/standard/full oder so) versehen werden.<br /> <br /> * KR: Bei Vokabularen, in denen wir Hierarchien haben (z.B. Aufführungsart) könnte man in einem weiteren Schritt aber noch mit skos:broader und skos:narrower arbeiten, richtig? Im letzten Treffen hattest du große Einwände, aber ich glaube, das Bezog sich auf skos:ConceptSchemes?<br /> ** Die Beziehung zwischen Gruppierung und Tätigkeit folgt nicht der Definition für logische Hierarchiebeziehungen, wie von SKOS für broader/narrower gefordert (&quot;Schnitt&quot; IsA &quot;Schnitt&quot;, &quot;Licht&quot; IsA &quot;Kamera&quot; usw. sind logisch nicht haltbare Aussagen). Außerdem werden die Gruppenbezeichner nicht als Relatoren verwendet, sondern dienen nur dem Arrangement an Benutzeroberflächen. Externe Anwendungen können Credits umgruppieren, ohne dass sich die eigentliche Aussage ändert. Für Grupperungen jenseits logischer Hierarchien sieht SKOS ausdrücklich das Collection-Element vor. <br /> <br /> * KR: Noch eine Verständnisfrage zum Verhältnis der ConceptSchemes (zdbvoc:auff_art, zdbvoc:credit und zdbvoc:fmtype) zu den jeweiligen Ontologie-Klassen zdb:Veroeffentlichung, zdb:Funktion und zdb:Manifestation in &quot;meinem&quot; Ontologie-Entwurf: Heißt das, dass diese ConceptSchemes deckungsgleich mit den Ontologie-Klassen sind und man beispielsweise die Range von zdb:hatManifestation begrenzen würde auf Objekte, die dem ConceptScheme zdbvoc:fmtype angehören?<br /> ** Ja, so wäre es zu deklarieren, wenn wir sagen wollen: die Eigenschaft Aufführungsart kann nur mit Vokabeln aus dem angegebenen Eigenschaftenvokabular ausgedrückt werden. zdbvoc:fmtype ist dann: (1) ein skos:ConceptScheme, (2) damit auch eine owl:Class und (3) ein RDF-Namensraum unter dem URI für zdbvoc:fmtype.<br /> <br /> * KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes &quot;Untervokabular&quot; einen eigenen Namensraum erstellt. Was ist da der Vorteil?<br /> ** DB: Die Ontologie kann so Range-Restriktionen für Properties mit kontrolliertem Vokabular mittels Namensraum-URIs ausdrücken. Außerdem wird die Wartung des Gesamtvokabulars vereinfacht, wenn eine Änderung an einem isolierten Namensraum erfolgen kann.<br /> <br /> * KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?<br /> ** DB: Grundsätzlich spricht nichts gegen rdfs:range/domain. Vielleicht ist das sogar besser, weil es eine lokale Deklaration erspart.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1559 2026-04-08T07:26:13Z

<p>Dbalzer: </p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Plan ==<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) vom neu einzurichtenden Vokabulardienst beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.<br /> <br /> == Diskussion ==<br /> <br /> * KR: Ich hatte bei der RDF-Version der ZDB-Daten immer insbesondere externe Nutzer und Nutzerinnen vor Augen. Diese benötigen Informationen/Properties wie skos:notation mit dem Rang des Credits, zdbvoc:P1 und zdbvoc:P2 mit Informationen zur Darstellung in Benutzeroberflächen ja gar nicht, oder? Vielleicht können wir hier noch etwas reduzieren. Die Reihenfolge von Credits, im Sinne der Nennung im Abspann, könnte man ja eher noch als weitere Property von zdb:Beteiligung modellieren?<br /> ** DB: Wenn wir Properties für P1/P2 und dergleichen rauslassen, brauchen wir einen anderen Ort dafür. Der Vorteil, alle für die ZDB-Bearbeitung nötigen Deklarationen mit einer RDF-Abfrage zu bekommen, wäre dann nicht mehr gegeben. Solche &quot;betriebsinternen&quot; Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird. <br /> <br /> KR: Bei Vokabularen, in denen wir Hierarchien haben (z.B. Aufführungsart) könnte man in einem weiteren Schritt aber noch mit skos:broader und skos:narrower arbeiten, richtig? Im letzten Treffen hattest du große Einwände, aber ich glaube, das Bezog sich auf skos:ConceptSchemes?<br /> <br /> KR: Noch eine Verständnisfrage zum Verhältnis der ConceptSchemes (zdbvoc:auff_art, zdbvoc:credit und zdbvoc:fmtype) zu den jeweiligen Ontologie-Klassen zdb:Veroeffentlichung, zdb:Funktion und zdb:Manifestation in &quot;meinem&quot; Ontologie-Entwurf: Heißt das, dass diese ConceptSchemes deckungsgleich mit den Ontologie-Klassen sind und man beispielsweise die Range von zdb:hatManifestation begrenzen würde auf Objekte, die dem ConceptScheme zdbvoc:fmtype angehören?<br /> <br /> KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes &quot;Untervokabular&quot; einen eigenen Namensraum erstellt. Was ist da der Vorteil?<br /> <br /> KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1558 2026-04-08T07:24:36Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) vom neu einzurichtenden Vokabulardienst beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.<br /> <br /> == Diskussion ==<br /> <br /> * KR: Ich hatte bei der RDF-Version der ZDB-Daten immer insbesondere externe Nutzer und Nutzerinnen vor Augen. Diese benötigen Informationen/Properties wie skos:notation mit dem Rang des Credits, zdbvoc:P1 und zdbvoc:P2 mit Informationen zur Darstellung in Benutzeroberflächen ja gar nicht, oder? Vielleicht können wir hier noch etwas reduzieren. Die Reihenfolge von Credits, im Sinne der Nennung im Abspann, könnte man ja eher noch als weitere Property von zdb:Beteiligung modellieren?<br /> ** DB: Wenn wir Properties für P1/P2 und dergleichen rauslassen, brauchen wir einen anderen Ort dafür. Der Vorteil, alle für die ZDB-Bearbeitung nötigen Deklarationen mit einer RDF-Abfrage zu bekommen, wäre dann nicht mehr gegeben. Solche &quot;betriebsinternen&quot; Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird. <br /> <br /> KR: Bei Vokabularen, in denen wir Hierarchien haben (z.B. Aufführungsart) könnte man in einem weiteren Schritt aber noch mit skos:broader und skos:narrower arbeiten, richtig? Im letzten Treffen hattest du große Einwände, aber ich glaube, das Bezog sich auf skos:ConceptSchemes?<br /> <br /> KR: Noch eine Verständnisfrage zum Verhältnis der ConceptSchemes (zdbvoc:auff_art, zdbvoc:credit und zdbvoc:fmtype) zu den jeweiligen Ontologie-Klassen zdb:Veroeffentlichung, zdb:Funktion und zdb:Manifestation in &quot;meinem&quot; Ontologie-Entwurf: Heißt das, dass diese ConceptSchemes deckungsgleich mit den Ontologie-Klassen sind und man beispielsweise die Range von zdb:hatManifestation begrenzen würde auf Objekte, die dem ConceptScheme zdbvoc:fmtype angehören?<br /> <br /> KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes &quot;Untervokabular&quot; einen eigenen Namensraum erstellt. Was ist da der Vorteil?<br /> <br /> KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1557 2026-04-07T14:06:14Z

<p>Dbalzer: /* Bugfixes */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.<br /> <br /> In der Änderungsprotokoll-Ansicht gabe es häufig Mehrfacheinträge, wenn an einer Entität mehrere Änderungen an einem Tag vorgenommen wurden. Das ist jetzt behoben.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1556 2026-04-07T13:42:06Z

<p>Dbalzer: /* Server-Umzug filmstandards.org */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1555 2026-04-07T13:41:13Z

<p>Dbalzer: /* Syntaktisch falsche Ordnungsdatum-Angaben */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist nicht zu erwarten.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet.<br /> <br /> Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1554 2026-04-07T13:39:16Z

<p>Dbalzer: /* Jour fixe, Freitag, 10. April 2026 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist nicht zu erwarten.<br /> <br /> === Syntaktisch falsche Ordnungsdatum-Angaben ===<br /> <br /> Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 6.000 der ursprünglich ca. 16.000 Fälle bearbeitet. <br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1553 2026-04-07T13:33:47Z

<p>Dbalzer: /* Jour fixe, Freitag, 10. April 2026 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==<br /> <br /> === Server-Umzug filmstandards.org ===<br /> <br /> Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist nicht zu erwarten.<br /> <br /> === Bugfixes ===<br /> <br /> Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren &quot;verwaiste&quot; Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-04-10&diff=1552 2026-04-07T13:27:14Z

<p>Dbalzer: Die Seite wurde neu angelegt: „Eine Seite aus dem Reformhaus == Jour fixe, Freitag, 10. April 2026 ==“</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 10. April 2026 ==</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Reformhaus&diff=1551 2026-04-07T13:26:14Z

<p>Dbalzer: </p> <hr /> <div>Fortlaufende Aktivitäten zur Anpassung und Weiterentwicklung der Filmografie-Datenbank und zugehöriger Datendienste des DFF<br /> <br /> === Telekonferenzen zu anstehenden Themen ===<br /> <br /> * '''[[Jour fixe 2026-04-10]]''' - Diskussionspunkte<br /> <br /> * [[Jour fixe 2026-03-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-02-06]] - Diskussionspunkte<br /> * [[Jour fixe 2026-01-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-12-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-11-07]] - Diskussionspunkte<br /> * ''[[Jour fixe 2025-10-10]]'' - vertagt<br /> * [[Jour fixe 2025-09-05]] - Diskussionspunkte<br /> * [[Jour fixe 2025-07-11]] - Diskussionspunkte<br /> * [[Jour fixe 2025-06-13]] - Diskussionspunkte<br /> * [[Jour fixe 2025-05-09]] - Diskussionspunkte<br /> * [[Jour fixe 2025-04-04]] - Diskussionspunkte<br /> * [[Jour fixe 2025-03-07]] - Diskussionspunkte<br /> * [[Jour fixe 2025-02-07]] - Diskussionspunkte zur Prioritäten-Findung<br /> <br /> === Laufendes ===<br /> <br /> * [[Elementvokabulare]] - Neuorganisation als Linked Data-Ressource<br /> <br /> * [[Zeitangaben in RDF]] - Standard-konforme Darstellung für Linked Data<br /> <br /> * [[Geografika in RDF]] - URIs für Länder und Regionen<br /> <br /> * [[Ergänzung des Datenschemas]] - Neue Relatoren<br /> <br /> * [[Bereinigung des Datenschemas]] - Entfernen nicht (mehr) benötigter Entitäten und Relationen; Änderungen an Eigenschaften und Datentypen<br /> <br /> * [[Erweiterungswünsche]] für die ZDB-Bearbeitung</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-03-06&diff=1550 2026-03-06T07:27:06Z

<p>Dbalzer: /* Element- und Relationenvokabulare */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 6. März 2026 == <br /> <br /> === RDF-Triplestore ===<br /> <br /> Der Fuseki-Triplestore auf ws.dff.film ist jetzt ohne Umweg über Port 3030 direkt und mit https erreichbar: [https://ws.dff.film/fuseki/index.html https://ws.dff.film/fuseki/index.html]<br /> <br /> === RDF-Datenmodell ===<br /> <br /> ==== Zeitangaben ====<br /> <br /> Wir hatten bereits EDTF als Syntax-Kandidaten für DFF Linked Data vorgemerkt. Die Umwandlung von der internen ZDB-Syntax (sofern korrekt) nach EDTF und zurück dürfte keine nennenswerten Probleme bereiten. Damit spricht nichts dagegen, EDTF als Zeit-Datentyp für die RDF-Darstellung der ZDB-Daten zu definieren. Näheres dazu in -&gt; [[Zeitangaben intern und in RDF]].<br /> <br /> ==== Element- und Relationenvokabulare ====<br /> <br /> Aktuelle Überlegungen zu Anforderungen und Realisierungsvorschläge sind hier: -&gt; [[Elementvokabulare]],<br /> <br /> ==== Namen von Agents ====<br /> <br /> Was spricht dafür oder dagegen, die Eigenschaften der Personen- und Körperschaftsnamen in einem gemeinsamen Vokabular zusammenzufassen?<br /> <br /> Für Körperschaften haben wir Vorzugsname, Offizieller Name, Kurzname und Weiterer Name<br /> <br /> Für Personen haben wir Vorzugsname, Geburtsname, Weiterer Name, Schreibvariante, Pseudonym<br /> <br /> Offizieller Name und Geburtsname überlappen sich in ihrer Bedeutung, Schreibvariante ließe sich auch auf Körperschaften anwenden. Kurzname (meist für Akronyme gebraucht und unüblich für Personen) und Pseudonym (für Körperschaften unüblich) haben keine enge Entsprechung.<br /> <br /> Andereseits: Eine Einteilung in Kollektiv- und Individualnamen ist vielleich leichter nachvollziehbar als eine durchgehende Reihe von Namens-Eigenschaften, die teils für Individuen, teils für Kollektive und teils für beides gelten.<br /> <br /> ==== Geografika ====<br /> <br /> Für die Darstellung der ZDB-Daten in einem RDF-Wissensgraphen ist zu überlegen, wie die Ländercodes in den &quot;Region&quot;-Datenelementen über URIs &quot;anschlussfähig&quot; gemacht werden könn en. Näheres hier: [[Geografika in RDF]].<br /> <br /> === Datenqualität ===<br /> <br /> ==== Ordnungsdatum ====<br /> <br /> Es werden weiter neue Filmwerke mit Ordnungsdaten wie &quot;2026-00-13&quot; angelegt. Ist das eine Vormerk-Methode für spätere Ergänzungen? Wenn ja, dann wäre das ein Hinweis darauf, dass wir noch keinen sauberen Mechanismus zum Kennzeichnen des Bearbeitungsstatus haben, den man zum Suchen und Filtern verwenden kann.<br /> <br /> Erste Läufe mit dem Roboter-Skript zur Bereinigung des Ordnungsdatums haben stattgefunden, von den ca. 16.000 Fällen sind ca. 5.000 erledigt. Demnächst folgen die restlichen Wochen- und Monatsschauen. Für viele der Serienwerke werden noch weitere Konfigurations-Optionen für das Skript benötigt-<br /> <br /> === Formatänderung MARC 21 seitens DNB ===<br /> <br /> Welche Auswirkungen hat das auf unsere GND-Schnittstelle? <br /> --&gt; Die Infos zur Formatänderung von MARC21 finden sich hier: https://wiki.dnb.de/spaces/GND/pages/388869577/Informationen+zu+Schnittstellen+Aktuelle+Informationen+zur+GND<br /> <br /> Laut [https://wiki.dnb.de/spaces/LINKEDDATASERVICE/pages/437860786/Versionshistorie+Linked-Data-Service?preview=/437860415/463148648/Rundschreiben_RDF_ExportRelease_2026_01.pdf Änderungshistorie] wurde im Januar 2026 nur ein Tippfehler im Klassennamen gndo:FullerFormOfNameOfThePerson korrigiert. Diese Aussage werten wir aber nicht aus. <br /> <br /> Die MARC21-Darstellung der GND-Datensätze nutzen wir nicht.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-03-06&diff=1549 2026-03-06T07:22:12Z

<p>Dbalzer: /* Element- und Relationenvokabulare */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 6. März 2026 == <br /> <br /> === RDF-Triplestore ===<br /> <br /> Der Fuseki-Triplestore auf ws.dff.film ist jetzt ohne Umweg über Port 3030 direkt und mit https erreichbar: [https://ws.dff.film/fuseki/index.html https://ws.dff.film/fuseki/index.html]<br /> <br /> === RDF-Datenmodell ===<br /> <br /> ==== Zeitangaben ====<br /> <br /> Wir hatten bereits EDTF als Syntax-Kandidaten für DFF Linked Data vorgemerkt. Die Umwandlung von der internen ZDB-Syntax (sofern korrekt) nach EDTF und zurück dürfte keine nennenswerten Probleme bereiten. Damit spricht nichts dagegen, EDTF als Zeit-Datentyp für die RDF-Darstellung der ZDB-Daten zu definieren. Näheres dazu in -&gt; [[Zeitangaben intern und in RDF]].<br /> <br /> ==== Element- und Relationenvokabulare ====<br /> <br /> Aktuelle Überlegungen zu Anforderungen und Realisierungsvorschläge sind hier: [[Elementvokabulare]],<br /> <br /> ==== Namen von Agents ====<br /> <br /> Was spricht dafür oder dagegen, die Eigenschaften der Personen- und Körperschaftsnamen in einem gemeinsamen Vokabular zusammenzufassen?<br /> <br /> Für Körperschaften haben wir Vorzugsname, Offizieller Name, Kurzname und Weiterer Name<br /> <br /> Für Personen haben wir Vorzugsname, Geburtsname, Weiterer Name, Schreibvariante, Pseudonym<br /> <br /> Offizieller Name und Geburtsname überlappen sich in ihrer Bedeutung, Schreibvariante ließe sich auch auf Körperschaften anwenden. Kurzname (meist für Akronyme gebraucht und unüblich für Personen) und Pseudonym (für Körperschaften unüblich) haben keine enge Entsprechung.<br /> <br /> Andereseits: Eine Einteilung in Kollektiv- und Individualnamen ist vielleich leichter nachvollziehbar als eine durchgehende Reihe von Namens-Eigenschaften, die teils für Individuen, teils für Kollektive und teils für beides gelten.<br /> <br /> ==== Geografika ====<br /> <br /> Für die Darstellung der ZDB-Daten in einem RDF-Wissensgraphen ist zu überlegen, wie die Ländercodes in den &quot;Region&quot;-Datenelementen über URIs &quot;anschlussfähig&quot; gemacht werden könn en. Näheres hier: [[Geografika in RDF]].<br /> <br /> === Datenqualität ===<br /> <br /> ==== Ordnungsdatum ====<br /> <br /> Es werden weiter neue Filmwerke mit Ordnungsdaten wie &quot;2026-00-13&quot; angelegt. Ist das eine Vormerk-Methode für spätere Ergänzungen? Wenn ja, dann wäre das ein Hinweis darauf, dass wir noch keinen sauberen Mechanismus zum Kennzeichnen des Bearbeitungsstatus haben, den man zum Suchen und Filtern verwenden kann.<br /> <br /> Erste Läufe mit dem Roboter-Skript zur Bereinigung des Ordnungsdatums haben stattgefunden, von den ca. 16.000 Fällen sind ca. 5.000 erledigt. Demnächst folgen die restlichen Wochen- und Monatsschauen. Für viele der Serienwerke werden noch weitere Konfigurations-Optionen für das Skript benötigt-<br /> <br /> === Formatänderung MARC 21 seitens DNB ===<br /> <br /> Welche Auswirkungen hat das auf unsere GND-Schnittstelle? <br /> --&gt; Die Infos zur Formatänderung von MARC21 finden sich hier: https://wiki.dnb.de/spaces/GND/pages/388869577/Informationen+zu+Schnittstellen+Aktuelle+Informationen+zur+GND<br /> <br /> Laut [https://wiki.dnb.de/spaces/LINKEDDATASERVICE/pages/437860786/Versionshistorie+Linked-Data-Service?preview=/437860415/463148648/Rundschreiben_RDF_ExportRelease_2026_01.pdf Änderungshistorie] wurde im Januar 2026 nur ein Tippfehler im Klassennamen gndo:FullerFormOfNameOfThePerson korrigiert. Diese Aussage werten wir aber nicht aus. <br /> <br /> Die MARC21-Darstellung der GND-Datensätze nutzen wir nicht.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-03-06&diff=1548 2026-03-06T07:21:07Z

<p>Dbalzer: /* Element- und relationsvokabulare */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 6. März 2026 == <br /> <br /> === RDF-Triplestore ===<br /> <br /> Der Fuseki-Triplestore auf ws.dff.film ist jetzt ohne Umweg über Port 3030 direkt und mit https erreichbar: [https://ws.dff.film/fuseki/index.html https://ws.dff.film/fuseki/index.html]<br /> <br /> === RDF-Datenmodell ===<br /> <br /> ==== Zeitangaben ====<br /> <br /> Wir hatten bereits EDTF als Syntax-Kandidaten für DFF Linked Data vorgemerkt. Die Umwandlung von der internen ZDB-Syntax (sofern korrekt) nach EDTF und zurück dürfte keine nennenswerten Probleme bereiten. Damit spricht nichts dagegen, EDTF als Zeit-Datentyp für die RDF-Darstellung der ZDB-Daten zu definieren. Näheres dazu in -&gt; [[Zeitangaben intern und in RDF]].<br /> <br /> ==== Element- und Relationenvokabulare ====<br /> <br /> Aktuelle Überlegungen zu Anforderungen und Realisiserungsvorschläge sind hier: [[Elementvokabulare]],<br /> <br /> ==== Namen von Agents ====<br /> <br /> Was spricht dafür oder dagegen, die Eigenschaften der Personen- und Körperschaftsnamen in einem gemeinsamen Vokabular zusammenzufassen?<br /> <br /> Für Körperschaften haben wir Vorzugsname, Offizieller Name, Kurzname und Weiterer Name<br /> <br /> Für Personen haben wir Vorzugsname, Geburtsname, Weiterer Name, Schreibvariante, Pseudonym<br /> <br /> Offizieller Name und Geburtsname überlappen sich in ihrer Bedeutung, Schreibvariante ließe sich auch auf Körperschaften anwenden. Kurzname (meist für Akronyme gebraucht und unüblich für Personen) und Pseudonym (für Körperschaften unüblich) haben keine enge Entsprechung.<br /> <br /> Andereseits: Eine Einteilung in Kollektiv- und Individualnamen ist vielleich leichter nachvollziehbar als eine durchgehende Reihe von Namens-Eigenschaften, die teils für Individuen, teils für Kollektive und teils für beides gelten.<br /> <br /> ==== Geografika ====<br /> <br /> Für die Darstellung der ZDB-Daten in einem RDF-Wissensgraphen ist zu überlegen, wie die Ländercodes in den &quot;Region&quot;-Datenelementen über URIs &quot;anschlussfähig&quot; gemacht werden könn en. Näheres hier: [[Geografika in RDF]].<br /> <br /> === Datenqualität ===<br /> <br /> ==== Ordnungsdatum ====<br /> <br /> Es werden weiter neue Filmwerke mit Ordnungsdaten wie &quot;2026-00-13&quot; angelegt. Ist das eine Vormerk-Methode für spätere Ergänzungen? Wenn ja, dann wäre das ein Hinweis darauf, dass wir noch keinen sauberen Mechanismus zum Kennzeichnen des Bearbeitungsstatus haben, den man zum Suchen und Filtern verwenden kann.<br /> <br /> Erste Läufe mit dem Roboter-Skript zur Bereinigung des Ordnungsdatums haben stattgefunden, von den ca. 16.000 Fällen sind ca. 5.000 erledigt. Demnächst folgen die restlichen Wochen- und Monatsschauen. Für viele der Serienwerke werden noch weitere Konfigurations-Optionen für das Skript benötigt-<br /> <br /> === Formatänderung MARC 21 seitens DNB ===<br /> <br /> Welche Auswirkungen hat das auf unsere GND-Schnittstelle? <br /> --&gt; Die Infos zur Formatänderung von MARC21 finden sich hier: https://wiki.dnb.de/spaces/GND/pages/388869577/Informationen+zu+Schnittstellen+Aktuelle+Informationen+zur+GND<br /> <br /> Laut [https://wiki.dnb.de/spaces/LINKEDDATASERVICE/pages/437860786/Versionshistorie+Linked-Data-Service?preview=/437860415/463148648/Rundschreiben_RDF_ExportRelease_2026_01.pdf Änderungshistorie] wurde im Januar 2026 nur ein Tippfehler im Klassennamen gndo:FullerFormOfNameOfThePerson korrigiert. Diese Aussage werten wir aber nicht aus. <br /> <br /> Die MARC21-Darstellung der GND-Datensätze nutzen wir nicht.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-03-06&diff=1547 2026-03-06T07:20:47Z

<p>Dbalzer: /* Zeitangaben */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 6. März 2026 == <br /> <br /> === RDF-Triplestore ===<br /> <br /> Der Fuseki-Triplestore auf ws.dff.film ist jetzt ohne Umweg über Port 3030 direkt und mit https erreichbar: [https://ws.dff.film/fuseki/index.html https://ws.dff.film/fuseki/index.html]<br /> <br /> === RDF-Datenmodell ===<br /> <br /> ==== Zeitangaben ====<br /> <br /> Wir hatten bereits EDTF als Syntax-Kandidaten für DFF Linked Data vorgemerkt. Die Umwandlung von der internen ZDB-Syntax (sofern korrekt) nach EDTF und zurück dürfte keine nennenswerten Probleme bereiten. Damit spricht nichts dagegen, EDTF als Zeit-Datentyp für die RDF-Darstellung der ZDB-Daten zu definieren. Näheres dazu in -&gt; [[Zeitangaben intern und in RDF]].<br /> <br /> ==== Element- und relationsvokabulare ====<br /> <br /> Aktuelle Überlegungen zu Anforderungen und Realisiserungsvorschläge sind hier: [[Elementvokabulare]],<br /> <br /> ==== Namen von Agents ====<br /> <br /> Was spricht dafür oder dagegen, die Eigenschaften der Personen- und Körperschaftsnamen in einem gemeinsamen Vokabular zusammenzufassen?<br /> <br /> Für Körperschaften haben wir Vorzugsname, Offizieller Name, Kurzname und Weiterer Name<br /> <br /> Für Personen haben wir Vorzugsname, Geburtsname, Weiterer Name, Schreibvariante, Pseudonym<br /> <br /> Offizieller Name und Geburtsname überlappen sich in ihrer Bedeutung, Schreibvariante ließe sich auch auf Körperschaften anwenden. Kurzname (meist für Akronyme gebraucht und unüblich für Personen) und Pseudonym (für Körperschaften unüblich) haben keine enge Entsprechung.<br /> <br /> Andereseits: Eine Einteilung in Kollektiv- und Individualnamen ist vielleich leichter nachvollziehbar als eine durchgehende Reihe von Namens-Eigenschaften, die teils für Individuen, teils für Kollektive und teils für beides gelten.<br /> <br /> ==== Geografika ====<br /> <br /> Für die Darstellung der ZDB-Daten in einem RDF-Wissensgraphen ist zu überlegen, wie die Ländercodes in den &quot;Region&quot;-Datenelementen über URIs &quot;anschlussfähig&quot; gemacht werden könn en. Näheres hier: [[Geografika in RDF]].<br /> <br /> === Datenqualität ===<br /> <br /> ==== Ordnungsdatum ====<br /> <br /> Es werden weiter neue Filmwerke mit Ordnungsdaten wie &quot;2026-00-13&quot; angelegt. Ist das eine Vormerk-Methode für spätere Ergänzungen? Wenn ja, dann wäre das ein Hinweis darauf, dass wir noch keinen sauberen Mechanismus zum Kennzeichnen des Bearbeitungsstatus haben, den man zum Suchen und Filtern verwenden kann.<br /> <br /> Erste Läufe mit dem Roboter-Skript zur Bereinigung des Ordnungsdatums haben stattgefunden, von den ca. 16.000 Fällen sind ca. 5.000 erledigt. Demnächst folgen die restlichen Wochen- und Monatsschauen. Für viele der Serienwerke werden noch weitere Konfigurations-Optionen für das Skript benötigt-<br /> <br /> === Formatänderung MARC 21 seitens DNB ===<br /> <br /> Welche Auswirkungen hat das auf unsere GND-Schnittstelle? <br /> --&gt; Die Infos zur Formatänderung von MARC21 finden sich hier: https://wiki.dnb.de/spaces/GND/pages/388869577/Informationen+zu+Schnittstellen+Aktuelle+Informationen+zur+GND<br /> <br /> Laut [https://wiki.dnb.de/spaces/LINKEDDATASERVICE/pages/437860786/Versionshistorie+Linked-Data-Service?preview=/437860415/463148648/Rundschreiben_RDF_ExportRelease_2026_01.pdf Änderungshistorie] wurde im Januar 2026 nur ein Tippfehler im Klassennamen gndo:FullerFormOfNameOfThePerson korrigiert. Diese Aussage werten wir aber nicht aus. <br /> <br /> Die MARC21-Darstellung der GND-Datensätze nutzen wir nicht.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-03-06&diff=1546 2026-03-06T07:15:00Z

<p>Dbalzer: /* Ordnungsdatum */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 6. März 2026 == <br /> <br /> === RDF-Triplestore ===<br /> <br /> Der Fuseki-Triplestore auf ws.dff.film ist jetzt ohne Umweg über Port 3030 direkt und mit https erreichbar: [https://ws.dff.film/fuseki/index.html https://ws.dff.film/fuseki/index.html]<br /> <br /> === RDF-Datenmodell ===<br /> <br /> ==== Zeitangaben ====<br /> <br /> WIr hatten bereits EDTF als Syntax-Kandidaten für DFF Linked Data vorgemerkt. Die Umwandlung von der internen ZDB-Syntax (sofern korrekt) nach EDTF und zurück dürfte keine nennenswerten Probleme bereiten. Damit spricht nichts dagegen, EDTF als Zeit-Datentyp für die RDF-Darstellung der ZDB-Daten zu definieren. Näheres dazu in -&gt; [[Zeitangaben intern und in RDF]].<br /> <br /> ==== Namen von Agents ====<br /> <br /> Was spricht dafür oder dagegen, die Eigenschaften der Personen- und Körperschaftsnamen in einem gemeinsamen Vokabular zusammenzufassen?<br /> <br /> Für Körperschaften haben wir Vorzugsname, Offizieller Name, Kurzname und Weiterer Name<br /> <br /> Für Personen haben wir Vorzugsname, Geburtsname, Weiterer Name, Schreibvariante, Pseudonym<br /> <br /> Offizieller Name und Geburtsname überlappen sich in ihrer Bedeutung, Schreibvariante ließe sich auch auf Körperschaften anwenden. Kurzname (meist für Akronyme gebraucht und unüblich für Personen) und Pseudonym (für Körperschaften unüblich) haben keine enge Entsprechung.<br /> <br /> Andereseits: Eine Einteilung in Kollektiv- und Individualnamen ist vielleich leichter nachvollziehbar als eine durchgehende Reihe von Namens-Eigenschaften, die teils für Individuen, teils für Kollektive und teils für beides gelten.<br /> <br /> ==== Geografika ====<br /> <br /> Für die Darstellung der ZDB-Daten in einem RDF-Wissensgraphen ist zu überlegen, wie die Ländercodes in den &quot;Region&quot;-Datenelementen über URIs &quot;anschlussfähig&quot; gemacht werden könn en. Näheres hier: [[Geografika in RDF]].<br /> <br /> === Datenqualität ===<br /> <br /> ==== Ordnungsdatum ====<br /> <br /> Es werden weiter neue Filmwerke mit Ordnungsdaten wie &quot;2026-00-13&quot; angelegt. Ist das eine Vormerk-Methode für spätere Ergänzungen? Wenn ja, dann wäre das ein Hinweis darauf, dass wir noch keinen sauberen Mechanismus zum Kennzeichnen des Bearbeitungsstatus haben, den man zum Suchen und Filtern verwenden kann.<br /> <br /> Erste Läufe mit dem Roboter-Skript zur Bereinigung des Ordnungsdatums haben stattgefunden, von den ca. 16.000 Fällen sind ca. 5.000 erledigt. Demnächst folgen die restlichen Wochen- und Monatsschauen. Für viele der Serienwerke werden noch weitere Konfigurations-Optionen für das Skript benötigt-<br /> <br /> === Formatänderung MARC 21 seitens DNB ===<br /> <br /> Welche Auswirkungen hat das auf unsere GND-Schnittstelle? <br /> --&gt; Die Infos zur Formatänderung von MARC21 finden sich hier: https://wiki.dnb.de/spaces/GND/pages/388869577/Informationen+zu+Schnittstellen+Aktuelle+Informationen+zur+GND<br /> <br /> Laut [https://wiki.dnb.de/spaces/LINKEDDATASERVICE/pages/437860786/Versionshistorie+Linked-Data-Service?preview=/437860415/463148648/Rundschreiben_RDF_ExportRelease_2026_01.pdf Änderungshistorie] wurde im Januar 2026 nur ein Tippfehler im Klassennamen gndo:FullerFormOfNameOfThePerson korrigiert. Diese Aussage werten wir aber nicht aus. <br /> <br /> Die MARC21-Darstellung der GND-Datensätze nutzen wir nicht.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-03-06&diff=1545 2026-03-06T07:09:18Z

<p>Dbalzer: /* Formatänderung MARC 21 seitens DNB */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 6. März 2026 == <br /> <br /> === RDF-Triplestore ===<br /> <br /> Der Fuseki-Triplestore auf ws.dff.film ist jetzt ohne Umweg über Port 3030 direkt und mit https erreichbar: [https://ws.dff.film/fuseki/index.html https://ws.dff.film/fuseki/index.html]<br /> <br /> === RDF-Datenmodell ===<br /> <br /> ==== Zeitangaben ====<br /> <br /> WIr hatten bereits EDTF als Syntax-Kandidaten für DFF Linked Data vorgemerkt. Die Umwandlung von der internen ZDB-Syntax (sofern korrekt) nach EDTF und zurück dürfte keine nennenswerten Probleme bereiten. Damit spricht nichts dagegen, EDTF als Zeit-Datentyp für die RDF-Darstellung der ZDB-Daten zu definieren. Näheres dazu in -&gt; [[Zeitangaben intern und in RDF]].<br /> <br /> ==== Namen von Agents ====<br /> <br /> Was spricht dafür oder dagegen, die Eigenschaften der Personen- und Körperschaftsnamen in einem gemeinsamen Vokabular zusammenzufassen?<br /> <br /> Für Körperschaften haben wir Vorzugsname, Offizieller Name, Kurzname und Weiterer Name<br /> <br /> Für Personen haben wir Vorzugsname, Geburtsname, Weiterer Name, Schreibvariante, Pseudonym<br /> <br /> Offizieller Name und Geburtsname überlappen sich in ihrer Bedeutung, Schreibvariante ließe sich auch auf Körperschaften anwenden. Kurzname (meist für Akronyme gebraucht und unüblich für Personen) und Pseudonym (für Körperschaften unüblich) haben keine enge Entsprechung.<br /> <br /> Andereseits: Eine Einteilung in Kollektiv- und Individualnamen ist vielleich leichter nachvollziehbar als eine durchgehende Reihe von Namens-Eigenschaften, die teils für Individuen, teils für Kollektive und teils für beides gelten.<br /> <br /> ==== Geografika ====<br /> <br /> Für die Darstellung der ZDB-Daten in einem RDF-Wissensgraphen ist zu überlegen, wie die Ländercodes in den &quot;Region&quot;-Datenelementen über URIs &quot;anschlussfähig&quot; gemacht werden könn en. Näheres hier: [[Geografika in RDF]].<br /> <br /> === Datenqualität ===<br /> <br /> ==== Ordnungsdatum ====<br /> <br /> Es werden weiter neue Filmwerke mit Ordnungsdaten wie &quot;2026-00-13&quot; angelegt. Ist das eine Vormerk-Methode für spätere Ergänzungen? Wenn ja, dann wäre das ein Hinweis darauf, dass wir noch keinen sauberen Mechanismus zum Kennzeichnen des Bearbeitungsstatus haben, den man zum Suchen und Filtern verwenden kann.<br /> <br /> <br /> === Formatänderung MARC 21 seitens DNB ===<br /> <br /> Welche Auswirkungen hat das auf unsere GND-Schnittstelle? <br /> --&gt; Die Infos zur Formatänderung von MARC21 finden sich hier: https://wiki.dnb.de/spaces/GND/pages/388869577/Informationen+zu+Schnittstellen+Aktuelle+Informationen+zur+GND<br /> <br /> Laut [https://wiki.dnb.de/spaces/LINKEDDATASERVICE/pages/437860786/Versionshistorie+Linked-Data-Service?preview=/437860415/463148648/Rundschreiben_RDF_ExportRelease_2026_01.pdf Änderungshistorie] wurde im Januar 2026 nur ein Tippfehler im Klassennamen gndo:FullerFormOfNameOfThePerson korrigiert. Diese Aussage werten wir aber nicht aus. <br /> <br /> Die MARC21-Darstellung der GND-Datensätze nutzen wir nicht.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1544 2026-03-05T20:14:47Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) vom neu einzurichtenden Vokabulardienst beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1543 2026-03-05T20:10:20Z

<p>Dbalzer: /* Restriktionen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) vom neu einzurichtenden Vokabulardienst beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung müssen auch Anwendungs-Restriktionen berücksichtigt werden: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL) und die Eigenschaftsvokabulare für Ereignisse usw. <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher gibt es für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)<br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1542 2026-03-05T19:19:04Z

<p>Dbalzer: /* ZDB-Integration */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) vom neu einzurichtenden Vokabulardienst beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher gibt es für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)<br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1541 2026-03-05T16:01:06Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher gibt es für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)<br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, vorhandene ZDB-Datenelemente als eigene Properties zu definieren:<br /> <br /> voccredit:Animation<br /> a skos:Concept ;<br /> zdbvoc:P1 &quot;unter Namen&quot; ;<br /> zdbvoc:P2 &quot;Detail&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1540 2026-03-05T15:34:51Z

<p>Dbalzer: /* Ziel */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> Für den DFF-internen Gebrauch soll gelten, dass die Vokabulare möglichst keine Vorannahmen dazu enthalten, wie sie in der RDF-Darstellung der Filmwerke und der anderen ZDB-Entitäten zur Anwendung kommen.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher gibt es für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)<br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, eigene Properties zu definieren.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1539 2026-03-05T15:28:29Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher gibt es für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)<br /> und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in the Thesaurus-Standards. Das ist insofern irrelvant, als extene Nutzer des Vokabulars in ihren Datenmodellen kaum gleichwertige Verwendung für diese Angaben haben dürften. Es hindert uns also nichts daran, eigene Properties zu definieren.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1538 2026-03-05T14:50:44Z

<p>Dbalzer: /* ZDB-Integration */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Restriktionen ===<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle &quot;reldef&quot;) mit &quot;P1&quot; und &quot;P2&quot; zusätzliche Angaben definiert. Ein RDF-basierter Vokabulardienst sollte aussagen können, für welchen Zweck diese Angaben zu verwenden sind. Die Klasse skos:Concept braucht also auch Properties für P1 und P2.<br /> <br /> Bisher gibt es für P1:<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1537 2026-03-05T13:22:25Z

<p>Dbalzer: /* ZDB-Integration */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Filmwerk ;<br /> zdbvoc:range zdb:Person ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1536 2026-03-05T12:04:33Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:range &quot;Person&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, außerdem fallweise (wie im Credits-Vokabular) auch skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1535 2026-03-05T12:03:33Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:range &quot;Person&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche skos:Collections zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1534 2026-03-05T11:56:59Z

<p>Dbalzer: /* ZDB-Integration */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:range &quot;Person&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1533 2026-03-05T11:54:53Z

<p>Dbalzer: /* Anforderungen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen &quot;term&quot; und &quot;reldef&quot; realisiert, die den Anforderungen aber nicht mehr gerecht werden. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist noch das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:range &quot;Person&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1532 2026-03-05T11:51:10Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist noch das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:range &quot;Person&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptScheme bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1531 2026-03-05T11:42:44Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist noch das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:range &quot;Person&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptScheme deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1530 2026-03-05T11:30:15Z

<p>Dbalzer: /* ZDB-Integration */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist noch das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> Die andere Möglichkeit wäre, für die Restriktionen eigene Properties zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties sollten wohl besser der eigentlichen Ontologie vorbehalten bleiben. Man könnte sie aber unter den Namensraum des Vokabulars stellen, etwa so:<br /> <br /> voccredit:Drehbuch a skos:Concept ;<br /> zdbvoc:range &quot;Person&quot; ;<br /> ...<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptGroup deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1529 2026-03-05T11:12:54Z

<p>Dbalzer: /* ZDB-Integration */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist noch das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL). <br /> <br /> Diese Restriktionen sollten direkt mit dem Concept-Datensatz geliefert werden, damit kein Umweg über einen weiteren Abfragedienst nötig ist. Eine (wenn auch unelegante) Möglichkeit bestünde darin, für jede Range-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:Range_Person a skos:Collection ;<br /> member voccredit:Adaption ; <br /> member voccredit:Drehbuch ; <br /> ...<br /> <br /> Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptGroup deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1527 2026-03-04T20:47:21Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabulare nach ihren Verwendungszwecken unterschieden werden.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptGroup deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem als skos:Collection geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1526 2026-03-04T19:26:47Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabularelemente nach ihren Verwendungszwecken gegliedert werden können.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptGroup deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem mit ConceptGroups geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung [https://www.w3.org/TR/trig/ TriG] (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1525 2026-03-04T19:06:41Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabularelemente nach ihren Verwendungszwecken gegliedert werden können.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph würde intern als skos:ConceptGroup deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem mit ConceptGroups geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung TriG (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nur mit der (bisher wenig gebräuchlichen) Erweiterung TriX möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Erg%C3%A4nzung_des_Datenschemas&diff=1524 2026-03-04T18:55:30Z

<p>Dbalzer: /* Relation Körperschaft zu Person */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> == Relatoren aus Wikidata ==<br /> <br /> Wikidata arbeitet offenbar nicht mit impliziten Umkehrbeziehungen. Eine Aussage wie &quot;hat Eigentümer&quot; muss auf der Eigentümerseite mit einer separaten Aussage &quot;ist Eigentümer von&quot; vervollständigt werden. Das wird oft nicht richig gehandhabt. Außerdem gibt es keine Restriktionen für Domain und Range, was oft zu beliebig ausgewählten Properties führt.<br /> <br /> === Relation Körperschaft zu Körperschaft ===<br /> <br /> Diese Abfrage über den [https://query.wikidata.org/ Wikidata SPARQL-Dienst] listet die derzeit verwendeten Properties zwischen Items des Typs &quot;Filmproduktionsgesellschaft&quot; (Q1762059) auf:<br /> <br /> # https://query.wikidata.org/<br /> SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE<br /> {<br /> ?s wdt:P31 wd:Q1762059 .<br /> ?o wdt:P31 wd:Q1762059 .<br /> ?s ?prop ?o .<br /> ?propertyItem wikibase:directClaim ?prop<br /> SERVICE wikibase:label { bd:serviceParam wikibase:language &quot;en&quot; }<br /> }<br /> GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)<br /> <br /> Siehe auch dieser Abgleich mit der GND-Ontologie im Protokoll vom [https://filmstandards.org/difzf/index.php?title=Jour_fixe_2025-07-11 11. Juli 2025].<br /> <br /> === Relation Körperschaft zu Person ===<br /> <br /> Diese Abfrage über den [https://query.wikidata.org/ Wikidata SPARQL-Dienst] listet die derzeit verwendeten Properties mit Subjekt &quot;Filmproduktionsgesellschaft&quot; (Q1762059) und Objekt &quot;Mensch&quot; (Q5) auf:<br /> <br /> # https://query.wikidata.org/<br /> SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE<br /> {<br /> ?s wdt:P31 wd:Q1762059 . # film production company<br /> ?o wdt:P31 wd:Q5 . # human<br /> ?s ?prop ?o .<br /> ?propertyItem wikibase:directClaim ?prop<br /> SERVICE wikibase:label { bd:serviceParam wikibase:language &quot;en&quot; }<br /> }<br /> GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)<br /> <br /> Und hier noch die Umkehrbeziehung (Subjekt) Mensch zu (Objekt) Filmproduktionsgesellschaft:<br /> <br /> # https://query.wikidata.org/<br /> SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE<br /> {<br /> ?s wdt:P31 wd:Q5 . # human<br /> ?o wdt:P31 wd:Q1762059 . # film production company<br /> ?s ?prop ?o .<br /> ?propertyItem wikibase:directClaim ?prop<br /> SERVICE wikibase:label { bd:serviceParam wikibase:language &quot;en&quot; }<br /> }<br /> GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)<br /> <br /> Wir sehen, dass bei fehlender Kontrolle der Umkehrbeziehungen allerhand Unsinn entsteht. Beispiel: [https://www.wikidata.org/wiki/Q116870917 Steven Af], Tologolesischer Filmproduzent, [https://www.wikidata.org/wiki/Property:P127 ist Eigentum von] (P127) der Produktionsfirma [https://www.wikidata.org/wiki/Q118724830 Sunlight Group]. Praktiziert diese Firma noch Sklavenhaltung?<br /> <br /> Weitere Menschen, die Eigentum einer Filmproduktionsfirma sind:<br /> <br /> # https://query.wikidata.org/<br /> SELECT DISTINCT ?pname ?kname WHERE<br /> {<br /> ?s wdt:P31 wd:Q5 ; # human<br /> rdfs:label ?pname .<br /> ?o wdt:P31 wd:Q1762059 ; # film production company<br /> rdfs:label ?kname . <br /> ?s wdt:P127 ?o . # owned by<br /> FILTER(LANG(?pname)=&quot;en&quot;) . FILTER(LANG(?kname)=&quot;en&quot;)<br /> }</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Erg%C3%A4nzung_des_Datenschemas&diff=1523 2026-03-04T18:54:39Z

<p>Dbalzer: /* Relation Körperschaft zu Körperschaft */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> == Relatoren aus Wikidata ==<br /> <br /> Wikidata arbeitet offenbar nicht mit impliziten Umkehrbeziehungen. Eine Aussage wie &quot;hat Eigentümer&quot; muss auf der Eigentümerseite mit einer separaten Aussage &quot;ist Eigentümer von&quot; vervollständigt werden. Das wird oft nicht richig gehandhabt. Außerdem gibt es keine Restriktionen für Domain und Range, was oft zu beliebig ausgewählten Properties führt.<br /> <br /> === Relation Körperschaft zu Körperschaft ===<br /> <br /> Diese Abfrage über den [https://query.wikidata.org/ Wikidata SPARQL-Dienst] listet die derzeit verwendeten Properties zwischen Items des Typs &quot;Filmproduktionsgesellschaft&quot; (Q1762059) auf:<br /> <br /> # https://query.wikidata.org/<br /> SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE<br /> {<br /> ?s wdt:P31 wd:Q1762059 .<br /> ?o wdt:P31 wd:Q1762059 .<br /> ?s ?prop ?o .<br /> ?propertyItem wikibase:directClaim ?prop<br /> SERVICE wikibase:label { bd:serviceParam wikibase:language &quot;en&quot; }<br /> }<br /> GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)<br /> <br /> Siehe auch dieser Abgleich mit der GND-Ontologie im Protokoll vom [https://filmstandards.org/difzf/index.php?title=Jour_fixe_2025-07-11 11. Juli 2025].<br /> <br /> === Relation Körperschaft zu Person ===<br /> <br /> Diese Abfrage über den [https://query.wikidata.org/ Wikidata SPARQL-Dienst] listet die derzeit verwendeten Properties mit Subjekt &quot;Filmproduktionsgesellschaft&quot; (Q1762059) und Objekt &quot;Mensch&quot; (Q5) auf:<br /> <br /> SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE<br /> {<br /> ?s wdt:P31 wd:Q1762059 . # film production company<br /> ?o wdt:P31 wd:Q5 . # human<br /> ?s ?prop ?o .<br /> ?propertyItem wikibase:directClaim ?prop<br /> SERVICE wikibase:label { bd:serviceParam wikibase:language &quot;en&quot; }<br /> }<br /> GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)<br /> <br /> Und hier noch die Umkehrbeziehung (Subjekt) Mensch zu (Objekt) Filmproduktionsgesellschaft:<br /> <br /> SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE<br /> {<br /> ?s wdt:P31 wd:Q5 . # human<br /> ?o wdt:P31 wd:Q1762059 . # film production company<br /> ?s ?prop ?o .<br /> ?propertyItem wikibase:directClaim ?prop<br /> SERVICE wikibase:label { bd:serviceParam wikibase:language &quot;en&quot; }<br /> }<br /> GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)<br /> <br /> Wir sehen, dass bei fehlender Kontrolle der Umkehrbeziehungen allerhand Unsinn entsteht. Beispiel: [https://www.wikidata.org/wiki/Q116870917 Steven Af], Tologolesischer Filmproduzent, [https://www.wikidata.org/wiki/Property:P127 ist Eigentum von] (P127) der Produktionsfirma [https://www.wikidata.org/wiki/Q118724830 Sunlight Group]. Praktiziert diese Firma noch Sklavenhaltung?<br /> <br /> Weitere Menschen, die Eigentum einer Filmproduktionsfirma sind:<br /> <br /> SELECT DISTINCT ?pname ?kname WHERE<br /> {<br /> ?s wdt:P31 wd:Q5 ; # human<br /> rdfs:label ?pname .<br /> ?o wdt:P31 wd:Q1762059 ; # film production company<br /> rdfs:label ?kname . <br /> ?s wdt:P127 ?o . # owned by<br /> FILTER(LANG(?pname)=&quot;en&quot;) . FILTER(LANG(?kname)=&quot;en&quot;)<br /> }</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-03-06&diff=1522 2026-03-04T18:46:39Z

<p>Dbalzer: /* Namen von Agents */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 6. März 2026 == <br /> <br /> === RDF-Triplestore ===<br /> <br /> Der Fuseki-Triplestore auf ws.dff.film ist jetzt ohne Umweg über Port 3030 direkt und mit https erreichbar: [https://ws.dff.film/fuseki/index.html https://ws.dff.film/fuseki/index.html]<br /> <br /> === RDF-Datenmodell ===<br /> <br /> ==== Zeitangaben ====<br /> <br /> WIr hatten bereits EDTF als Syntax-Kandidaten für DFF Linked Data vorgemerkt. Die Umwandlung von der internen ZDB-Syntax (sofern korrekt) nach EDTF und zurück dürfte keine nennenswerten Probleme bereiten. Damit spricht nichts dagegen, EDTF als Zeit-Datentyp für die RDF-Darstellung der ZDB-Daten zu definieren. Näheres dazu in -&gt; [[Zeitangaben intern und in RDF]].<br /> <br /> ==== Namen von Agents ====<br /> <br /> Was spricht dafür oder dagegen, die Eigenschaften der Personen- und Körperschaftsnamen in einem gemeinsamen Vokabular zusammenzufassen?<br /> <br /> Für Körperschaften haben wir Vorzugsname, Offizieller Name, Kurzname und Weiterer Name<br /> <br /> Für Personen haben wir Vorzugsname, Geburtsname, Weiterer Name, Schreibvariante, Pseudonym<br /> <br /> Offizieller Name und Geburtsname überlappen sich in ihrer Bedeutung, Schreibvariante ließe sich auch auf Körperschaften anwenden. Kurzname (meist für Akronyme gebraucht und unüblich für Personen) und Pseudonym (für Körperschaften unüblich) haben keine enge Entsprechung.<br /> <br /> Andereseits: Eine Einteilung in Kollektiv- und Individualnamen ist vielleich leichter nachvollziehbar als eine durchgehende Reihe von Namens-Eigenschaften, die teils für Individuen, teils für Kollektive und teils für beides gelten.<br /> <br /> ==== Geografika ====<br /> <br /> Für die Darstellung der ZDB-Daten in einem RDF-Wissensgraphen ist zu überlegen, wie die Ländercodes in den &quot;Region&quot;-Datenelementen über URIs &quot;anschlussfähig&quot; gemacht werden könn en. Näheres hier: [[Geografika in RDF]].<br /> <br /> === Datenqualität ===<br /> <br /> ==== Ordnungsdatum ====<br /> <br /> Es werden weiter neue Filmwerke mit Ordnungsdaten wie &quot;2026-00-13&quot; angelegt. Ist das eine Vormerk-Methode für spätere Ergänzungen? Wenn ja, dann wäre das ein Hinweis darauf, dass wir noch keinen sauberen Mechanismus zum Kennzeichnen des Bearbeitungsstatus haben, den man zum Suchen und Filtern verwenden kann.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1521 2026-03-04T08:39:32Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabularelemente nach ihren Verwendungszwecken gegliedert werden können.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph wird intern als skos:ConceptGroup deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem mit ConceptGroups geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.<br /> <br /> Zur serialisierten (d.h. textlichen) Darstellung von NamedGraphs gibt es die Turtle-Erweiterung TriG (Turtle with Named Graphs). Eine Serialisierung in RDF/XML ist nicht möglich, da RDF/XML vor der Einführung von NamedGraphs definiert wurde.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1520 2026-03-04T08:34:29Z

<p>Dbalzer: /* Der RDF-Graph */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll hier etwas geändert werden?<br /> <br /> Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit der &quot;term&quot;-Tabelle realisiert, die den Anforderungen aber nicht mehr gerecht wird. Es fehlt an geeigneter Unterstützung für Mehrsprachigkeit, für durchgehende Ergänzung mit Definitionen und Verwendungshinweisen, Statusangeben und externen Mappings. Außerdem sind die Term-Abfragen im Programmcode für die Bearbeutungsformulare (historisch gewachsen) über zahlreiche Einzelfunktionen vestreut; eine dokumentierte Möglichkeit zur Nachnutzung in anderen Anwendungen (Portale, Partnerprojekte) gibt es nicht.<br /> <br /> === Ziel ===<br /> <br /> Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:<br /> <br /> * FG Dokumentation im Deutschen Museumsbund: [https://zenodo.org/records/17950403 FAIRe Vokabulare und Normdaten für Museen und Sammlungen] (2025), basierend auf den [https://www.go-fair.org/fair-principles/ FAIR Principles].<br /> <br /> * alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.<br /> <br /> * konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, [https://www.niso.org/schemas/iso25964 ISO-Thes] und [https://schema.vocnet.org/ Vocnet].<br /> <br /> * Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.<br /> <br /> === ZDB-Integration ===<br /> <br /> Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.<br /> <br /> === Der RDF-Graph ===<br /> <br /> Allen Vokabularelementen ist gemeinsam, dass sie als Instanzen von CRM E55_Type aufgefasst weden können. crm:E55 ist der Übergang von der Struktur-Ontologie zu den konkreten Aussagen im Wissensgraphen. Hier mutiert crm:E55_Type zu skos:Concept, so dass jedes Vokabularelement auch eine Instanz von skos:Concept ist. Der SKOS-Namensraum stellt als Strukturknoten skos:ConceptGroup bereit, mit dem die Vokabularelemente nach ihren Verwendungszwecken gegliedert werden können.<br /> <br /> Jedes Elementvokabular der ZDB ist in sich abgeschlossen, es gibt also keine semantischen oder sonstigen Beziehungen zu Begriffen aus einem anderen Elementvokabular. Damit kann und sollte es als eigener URI-Namensraum adressierbar sein. Für solche Sub-Namensräume gibt es in RDF das Modellelement der ''Named Graphs''. Jeder NamedGraph wird intern als skos:ConceptGroup deklariert, unbeschadet der Tatsache, dass es innerhalb eines Einzelvokabulars weitere Gliederungem mit ConceptGroups geben kann, die aber keine NamedGraphs sind. Ein NamedGraph enthält stets Metadaten zum betreffenden Vokabular und die Deklarationen der Begriffe als skos:Concept, fallweise (wie im Credits-Vokabular) auch zusätzliche ConceptGroups zur Untergliederng.</div>

Dbalzer