https://filmstandards.org/difzf/api.php?action=feedcontributions&feedformat=atom&user=Dbalzer 2026-10-11T06:38:38Z Benutzerbeiträge MediaWiki 1.31.7 https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1765 2026-10-09T07:19:19Z

<p>Dbalzer: /* Geografika (Region) */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> Sollten wir hier vom alphanumerischen URI-Schema abweichen und die vorhandenen ZDB-Länderkürzel als Unterscheidungsmerkmal nehmen? <br /> <br /> Problem dabei: es gibt Länder/Regionen in mehr als einer (zeitlichen) Ausprägung, die auch auf URI-Ebene unterscheidbar bleiben sollen.<br /> <br /> Es gibt Kulturerbe-Datenbanken, die zwischen Deutsches Reich und BR Deutschland unterscheiden. Eine retrospektive Änderung für DE in der ZDB wäre anhand von Jahresangaben prinzipiell möglich, dürfte aber schwierig umzusetzen sein. Soll es trotzdem versucht werden?<br /> <br /> Außerdem: Vorgänger-Nachfolger-Relationen zwischen einzelnen Geografika, die sind zur Zeit nur in der ZDB-Tabelle &quot;region&quot; als Notiz vermerkt. Und sollen auch Hierarchiebeziehungen für teilautonome Gebiete vorgesehen werden (IM skos:broader GB)?<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===<br /> <br /> Für die Klasse Beteiligung wäre noch die Eigenschaft &quot;Rang&quot; zu definieren.<br /> <br /> Eine Klasse &quot;Beziehng&quot; wäre für die Agent-Agent-Relationen in analoger Weise einzurichten. Auch hier geht des darum, die verschiedenen Beziehungsarten über das (erweiterbare) Vokabular und nicht als abgeschlossene Menge von Properties in der Ontologie zu definieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1764 2026-10-09T07:07:35Z

<p>Dbalzer: /* Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> Sollten wir hier vom alphanumerischen URI-Schema abweichen und die vorhandenen ZDB-Länderkürzel als Unterscheidungsmerkmal nehmen? <br /> <br /> Problem dabei: es gibt Länder/Regionen in mehr als einer (zeitlichen) Ausprägung, die auch auf URI-Ebene unterschieden werden müssen.<br /> <br /> Es gibt Kulturerbe-Datenbanken, die zwischen Deutsches Reich und BR Deutschland unterscheiden. Eine retrospektive Änderuung für DE in der ZDB wäre anhand von Jahresangaben prinzipiell möglich, dürfte aber schwierig umzusetzen sein. Soll es trotzdem versucht werden?<br /> <br /> Außerdem: Vorgänger-Nachfolger-Relationen zwischen einzelnen Geografika. Und sollen auch Hierarchiebeziehungen für teilautonome Gebiete vorgesehen werden (IM skos:broader GB)?<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===<br /> <br /> Für die Klasse Beteiligung wäre noch die Eigenschaft &quot;Rang&quot; zu definieren.<br /> <br /> Eine Klasse &quot;Beziehng&quot; wäre für die Agent-Agent-Relationen in analoger Weise einzurichten. Auch hier geht des darum, die verschiedenen Beziehungsarten über das (erweiterbare) Vokabular und nicht als abgeschlossene Menge von Properties in der Ontologie zu definieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1763 2026-10-09T07:03:50Z

<p>Dbalzer: /* Geografika (Region) */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> Sollten wir hier vom alphanumerischen URI-Schema abweichen und die vorhandenen ZDB-Länderkürzel als Unterscheidungsmerkmal nehmen? <br /> <br /> Problem dabei: es gibt Länder/Regionen in mehr als einer (zeitlichen) Ausprägung, die auch auf URI-Ebene unterschieden werden müssen.<br /> <br /> Es gibt Kulturerbe-Datenbanken, die zwischen Deutsches Reich und BR Deutschland unterscheiden. Eine retrospektive Änderuung für DE in der ZDB wäre anhand von Jahresangaben prinzipiell möglich, dürfte aber schwierig umzusetzen sein. Soll es trotzdem versucht werden?<br /> <br /> Außerdem: Vorgänger-Nachfolger-Relationen zwischen einzelnen Geografika. Und sollen auch Hierarchiebeziehungen für teilautonome Gebiete vorgesehen werden (IM skos:broader GB)?<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===<br /> <br /> Für die Klasse Beteiligung wäre noch die Eigenschaft &quot;Rang&quot; zu definieren.<br /> <br /> Eine Klasse &quot;Beziehng&quot; würde für die Agent-Agent-Relationen in analoger Weise einzurichten sein. Auch hier geht des darum, die verschiedenen Beziehungsarten über das (erweiterbare) Vokabular und nicht als abgeschlossene Menge von Properties in der Ontologie zu definieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1762 2026-10-09T07:02:20Z

<p>Dbalzer: /* Geografika (Region) */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> Sollten wir hier vom alphanumerischen URI-Schema abweichen und die vorhandenen ZDB-Länderkürzel als Unterscheidungsmerkmal nehmen? <br /> <br /> Problem dabei: es gibt Länder/Regionen in mehr als einer (zeitlichen) Ausprägung, die auch auf URI-Ebene unterschieden werden müssen.<br /> <br /> Es gibt Kulturerbe-Datenbanken, die zwischen Deutsches Reich und BR Deutschland unterscheiden. Eine retrospektive Änderuung für DE in der ZDB dürfte schwierig sein. Soll es trotzdem versucht werden?<br /> <br /> Außerdem: Vorgänger-Nachfolger-Relationen zwischen einzelnen Geografika. Und sollen auch Hierarchiebeziehungen für teilautonome Gebiete vorgesehen werden (IM skos:broader GB)?<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===<br /> <br /> Für die Klasse Beteiligung wäre noch die Eigenschaft &quot;Rang&quot; zu definieren.<br /> <br /> Eine Klasse &quot;Beziehng&quot; würde für die Agent-Agent-Relationen in analoger Weise einzurichten sein. Auch hier geht des darum, die verschiedenen Beziehungsarten über das (erweiterbare) Vokabular und nicht als abgeschlossene Menge von Properties in der Ontologie zu definieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1761 2026-10-09T06:50:02Z

<p>Dbalzer: /* Geografika (Region) */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> Sollten wir hier vom alphanumerischen URI-Schema abweichen und die vorhandenen ZDB-Länderkürzel als Unterscheidungsmerkmal nehmen? <br /> <br /> Problem dabei: es gibt Länder/Regionen in mehr als einer (zeitlichen) Ausprägung, die auch auf URI-Ebene unterschieden werden müssen.<br /> <br /> Außerdem: Hierarchiebeziehungen und Vorgänger-Nachfolger-Relationen zwischen einzelnen Geografika.<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===<br /> <br /> Für die Klasse Beteiligung wäre noch die Eigenschaft &quot;Rang&quot; zu definieren.<br /> <br /> Eine Klasse &quot;Beziehng&quot; würde für die Agent-Agent-Relationen in analoger Weise einzurichten sein. Auch hier geht des darum, die verschiedenen Beziehungsarten über das (erweiterbare) Vokabular und nicht als abgeschlossene Menge von Properties in der Ontologie zu definieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1760 2026-10-09T06:38:14Z

<p>Dbalzer: /* Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===<br /> <br /> Für die Klasse Beteiligung wäre noch die Eigenschaft &quot;Rang&quot; zu definieren.<br /> <br /> Eine Klasse &quot;Beziehng&quot; würde für die Agent-Agent-Relationen in analoger Weise einzurichten sein. Auch hier geht des darum, die verschiedenen Beziehungsarten über das (erweiterbare) Vokabular und nicht als abgeschlossene Menge von Properties in der Ontologie zu definieren.</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1759 2026-10-09T06:31:43Z

<p>Dbalzer: /* Offene Punkte bei den Vokabularen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1758 2026-10-08T17:26:02Z

<p>Dbalzer: /* Constraints für skos:Concept */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Daneben gibt es noch die Eigenschaft Rang, die ebenfalls als ZDB-Erweiterung der Properties von skos:Concept einzurichten wäre.<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property [https://www.wikidata.org/wiki/Property:P86 P86 (composer)]:<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1757 2026-10-08T17:13:25Z

<p>Dbalzer: /* Offene Punkte bei den Vokabularen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Daneben gibt es noch die Eigenschaft Rang, die ebenfalls als ZDB-Erweiterung der Properties von skos:Concept einzurichten wäre.<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property P86 (composer):<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1756 2026-10-08T14:32:10Z

<p>Dbalzer: /* Constraints für skos:Concept */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property P86 (composer):<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person, Gruppe, o.a. verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1755 2026-10-08T14:31:20Z

<p>Dbalzer: /* Constraints für skos:Concept */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property P86 (composer):<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86] verweist dabei nicht direkt auf die Person oder Gruppe, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1754 2026-10-08T14:27:39Z

<p>Dbalzer: /* Constraints für skos:Concept */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property P86 (composer):<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86} verweist dabei nicht direkt auf den Komponisten, sondern auf ein Instanz von ''statement'' aus dem Namensraum www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1753 2026-10-08T14:24:05Z

<p>Dbalzer: /* Offene Punkte bei den Vokabularen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> ==== Constraints für skos:Concept ====<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> Anregung könnte Wikidata liefern. Hier die relevanten Constraints für die Property P86 (composer):<br /> * [https://www.wikidata.org/wiki/Q21503250 subject type constraint] schränkt ein auf Instanzen u.a. der Klassen [https://www.wikidata.org/wiki/Q386724 Werk] und [https://www.wikidata.org/wiki/Q17489659 Gruppe von Werken]<br /> * [https://www.wikidata.org/wiki/Q21510865 value-type constraint] schränkt ein auf Instanzen von u.a. [https://www.wikidata.org/wiki/Q5 Mensch], [https://www.wikidata.org/wiki/Q215380 Musikgruppe] und neuerdings auch [https://www.wikidata.org/wiki/Q117246174 Generative KI].<br /> <br /> Die Property [https://www.wikidata.org/wiki/Property:P86 P86} verweist dabei nicht direkt auf den Komponisten, sondern auf ein Instanz von ''statement'' aus dem Namensraum http://www.wikidata.org/entity/statement/, wo qualifizierende Angaben gemacht werden können. Daneben gibt es für die Property P86 einen weiteren Namensraum, http://www.wikidata.org/prop/direct/, mit dem das ''statement'' umgangen wird und das Werk direkt mit der Person verbunden ist.<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1752 2026-10-08T07:18:04Z

<p>Dbalzer: /* Offene Punkte bei den Vokabularen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Die bisher mit rdfs:domain und range angegebenen Gültigkeits-Constraints sind nur für Properties definiert und damit für die Klasse skos:Concept nicht anwendbar. Wie wollen/können wir Alternativen deklarieren, die mit RDFS und SKOS verträglich sind?<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1751 2026-10-08T06:48:25Z

<p>Dbalzer: /* Offene Punkte bei den Vokabularen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1750 2026-10-08T06:45:37Z

<p>Dbalzer: /* Offene Punkte bei den Vokabularen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> Bei den aus xTree importierten Vokabularen fehlt noch der Urprungs-URI. Mit welcher Property (skos:exactMatch, oder etwas Eigenes wie zdb:origin) soll der aufgenommen werden? <br /> <br /> Für die ZDB-Datenelemente relation.P1 und P2, die je nach Kontext verschiedene Bedeutung haben, sollen in der ZDB-Ontologie der Bedeutung entsprechende Properties deklariert werden. Dies betrifft folgende Aussagen:<br /> <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1749 2026-10-08T06:35:47Z

<p>Dbalzer: /* Neues URI-Schema */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> Mit Ausnahme der ConceptGroups haben jetzt alle Vokabularelemente einen alphanumerischen Identifikator. <br /> <br /> Frage: soll der numerische Teil mit führenden Nullen in eine einheitliche Länge gebracht werden (Bsp. TA13 -&gt; TA0013 &quot;Erstaufführung&quot;)? Wikidata und GND tun das nicht, LCSH, Xtree, u.a. tun es.<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1748 2026-10-08T06:26:19Z

<p>Dbalzer: /* Jour fixe, Freitag, 09. Oktober 2026 */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}<br /> <br /> == Vokabulare in RDF ==<br /> <br /> Es gibt aktualisierte Vokabulare für Relationen und Typangaben. Diese können im [https://ws.dff.film/ld-svc/sparql-ui/sparql.html Triplestore] mit SPARQL-Abfragen getestet werden.<br /> <br /> === Neues URI-Schema ===<br /> <br /> === Offene Punkte bei den Vokabularen ===<br /> <br /> === Geografika (Region) ===<br /> <br /> === Ontologie-Klassen &quot;Beteiligung&quot; und &quot;Beziehung&quot; ===</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Reformhaus&diff=1747 2026-10-05T06:43:01Z

<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-10-09]]''' - Diskussionspunkte<br /> * [[Jour fixe 2026-08-28]] - Diskussionspunkte<br /> * [[Jour fixe 2026-08-07]] - Diskussionspunkte<br /> * [[Jour fixe 2026-07-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-29]] - Diskussionspunkte<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 /> * [[Migration filmstandards.org]] - Was auf einen neuen Server mitgenommen werden soll<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-10-09&diff=1746 2026-10-05T06:41:07Z

<p>Dbalzer: </p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-10-09&diff=1745 2026-10-05T06:39:51Z

<p>Dbalzer: Die Seite wurde neu angelegt: „== Jour fixe, Freitag, 09. Oktober 2026 == Themenwüsche bitte hier notieren. === Anpassung Körperschaften-Credits === Das Interface der Personen-Credits in…“</p> <hr /> <div>== Jour fixe, Freitag, 09. Oktober 2026 ==<br /> <br /> Themenwüsche bitte hier notieren.<br /> <br /> === Anpassung Körperschaften-Credits ===<br /> Das Interface der Personen-Credits in der ZDB wurde im Juni angepasst. Ein Feedback von Natalie und Bianca wurde schon an Detlev gegeben. Aus unserer Sicht kann das Interface auch bei den Körperschaften-Credits übernommen werden. <br /> <br /> <br /> === Sprachenkürzel in Regionsfeldern ===<br /> Bei Filmtiteln wurden des öfteren Sprachenkürzel (eng, frz, jid...) verwendet. Wie sollte damit zukünftig umgegangen werden? könnte das in Zukunft zu Problemen führen? Sauberer wäre vermutlich ein weiteres Feld für Titelsprache (ergänzend zur jetztigen Titelregion?) <br /> Betroffen sind rund 3.000 Filmtitel<br /> <br /> <br /> {| class=&quot;wikitable sortable mw-datatable&quot; style=&quot;background-color:#FFFFFF&quot;<br /> ! style=&quot;background-color:#B3B7FF&quot; | Kürzel !! style=&quot;background-color:#B3B7FF&quot; | Bedeutung<br /> |-<br /> | eng || 2.771 Filmtitel<br /> |-<br /> | yid || 124 Filmtitel <br /> |-<br /> | heb|| 105 Filmtitel<br /> |-<br /> | deu|| 52 Filmtitel<br /> |-<br /> |}</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Reformhaus&diff=1744 2026-10-05T06:36:32Z

<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-10-09]]''' - Diskussionspunkte<br /> * [[Jour fixe 2026-09-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-08-28]] - Diskussionspunkte<br /> * [[Jour fixe 2026-08-07]] - Diskussionspunkte<br /> * [[Jour fixe 2026-07-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-29]] - Diskussionspunkte<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 /> * [[Migration filmstandards.org]] - Was auf einen neuen Server mitgenommen werden soll<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=Reformhaus&diff=1743 2026-10-05T06:35:58Z

<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-10-09]]''' - Diskussionspunkte<br /> * [[Jour fixe 2026-09-1099 - Diskussionspunkte<br /> * [[Jour fixe 2026-08-28]] - Diskussionspunkte<br /> * [[Jour fixe 2026-08-07]] - Diskussionspunkte<br /> * [[Jour fixe 2026-07-10]] - Diskussionspunkte<br /> * [[Jour fixe 2026-05-29]] - Diskussionspunkte<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 /> * [[Migration filmstandards.org]] - Was auf einen neuen Server mitgenommen werden soll<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=Geografika_in_RDF&diff=1738 2026-09-22T08:37:05Z

<p>Dbalzer: /* Klasse &quot;Region&quot; für die ZDB-Ontologie */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Klasse &quot;Region&quot; für die ZDB-Ontologie ==<br /> <br /> Die ZDB-Tabelle &quot;region&quot; soll auch als RDF-Ressource verfügbar gemacht werden, damit künftige RDF-basierte Anwendungen auf alle dort verfügbaren Angaben zugreifen können.<br /> <br /> Eine Modellierung der Tabelle analog zu den Elementvokabularen, d.h. als Instanzen von skos:Concept, müsste allerdings folgende Überlegungen berücksichtigen: <br /> <br /> * Ein ZDB-Ländercode kann für mehrere aufeinanderfolgende Ausprägungen eines Staates oder einer Verwaltungseinheit stehen (prominentes Beispiel: Deutschland). Die ZDB fasst diese Ausprägungen in der Regel unter einem Ländercode zusammen, weil filmografische Quellen nicht immer eine genauere Zuordnung erlauben. In Datenabfragen für Display und Export kann die genauere Bezeichnung allerdings dann ermittelt werden, wenn die zetliche Gültigkeit vermerkt ist und mit dem Kontext-Zeitpunkt (Produktion, Aufführung, Prüfung, ...) verglichen werden kann.<br /> <br /> : - Prinzipiell würde sich hier eine SKOS-Modellierung mit Hierarchierelationen anbieten. Dies könnte auch die Aktualisierung im Falle zukünftiger Sezessionen, Vereinigungen und Grenzverschiebungen erleichtern.<br /> <br /> * Für die zeitliche Gültigkeit müssten Properties deklariert werden. <br /> <br /> : - Semantisch würden diese weitgehend den Zeitangaben &quot;gegründet&quot; und &quot;aufgelöst&quot; bei Körperschaften entsprechen (letztlich sind Staaten und Verwaltungseinheiten auch Körperschaften). <br /> <br /> * Die Vorgänger-Nachfolger-Relation ist in der ZDB-Tabelle &quot;region&quot; bisher nur informell als scope note vermerkt.<br /> <br /> : - Auch hier gibt es eine semantische Entsprechung zu den Körperschaften. Eine Vorgänger-Nachfolger-Relation für Körperschaften ist in der ZDB bereits realisiert.<br /> <br /> == URIs für ZDB-Ländercodes ==<br /> <br /> Für die ISO 3166-Ländercodes gibt es nach wie vor keinen offiziellen RDF-Namensraum (die ISO ist in jeder Hinsicht im 20. Jahrhundert steckengebieben. Immerhin erlaubt man jetzt gnädiger Weise die Verwendung der Kürzel, ohne die 159 sFr für den Standard bezahlt zu haben).<br /> <br /> Naheliegend wäre auch, sich bei den [https://d-nb.info/standards/vocab/gnd/geographic-area-code.html GND-Regionencodes] zu bedienen. <br /> <br /> Allerdings gibt es ZDB-[[Ländercodes]], für die in der GND keine Entsprechung existiert. Mögliche Lösungen wären:<br /> <br /> * GND GeographicAreaCode dort, wo eine Übereinstimmung existiert und GND-Geografikum für die übrigen Regionen.<br /> <br /> * ZDB-Ländercodes mit exakter Entsprechung zu ISO 3166 unter den ISO-Namensraum und die übrigen entweder<br /> # als GND-Geografikum für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://d-nb.info/gnd/35065-5 GND:35065-5])<br /> # als Wikidata-Item für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://www.wikidata.org/wiki/Q170361 WD:Q170361])<br /> <br /> * oder vollständig unter einen eigenen DFF-Vokabular-Namensraum, mit Mappings zu allen bekannten URIs aus anderen Namensräumen.<br /> <br /> ''Kristina: ich finde Option GND GeographicAreaCode + GND-Geografikum oder die letze Option mit mehreren Mappings am besten. Die Mappings würden wir direkt in der ZDB hinterlegen?<br /> ''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Geografika_in_RDF&diff=1737 2026-09-22T08:18:40Z

<p>Dbalzer: /* Klasse &quot;Region&quot; für die ZDB-Ontologie */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Klasse &quot;Region&quot; für die ZDB-Ontologie ==<br /> <br /> Die ZDB-Tabelle &quot;region&quot; soll auch als RDF-Ressource verfügbar gemacht werden, damit künftige RDF-basierte Anwendungen auf alle dort verfügbaren Angaben zugreifen können.<br /> <br /> Eine Modellierung der Tabelle analog zu den Elementvokabularen, d.h. als Instanzen von skos:Concept, müsste allerdings folgende Überlegungen berücksichtigen: <br /> <br /> * Ein ZDB-Ländercode kann für mehrere aufeinanderfolgende Ausprägungen eines Staates oder einer Verwaltungseinheit stehen (prominentes Beispiel: Deutschland). Die ZDB fasst diese Ausprägungen in der Regel unter einem Ländercode zusammen, weil filmografische Quellen nicht immer eine genauere Zuordnung erlauben. In Datenabfragen für Display und Export kann die genauere Bezeichnung allerdings dann ermittelt werden, wenn die zetliche Gültigkeit vermerkt ist und mit dem Kontext-Zeitpunkt (Produktion, Aufführung, Prüfung, ...) verglichen werden kann.<br /> <br /> * Prinzipiell fürde sich hier eine SKOS-Modellierung mit Hierarchierelationen anbieten<br /> <br /> == URIs für ZDB-Ländercodes ==<br /> <br /> Für die ISO 3166-Ländercodes gibt es nach wie vor keinen offiziellen RDF-Namensraum (die ISO ist in jeder Hinsicht im 20. Jahrhundert steckengebieben. Immerhin erlaubt man jetzt gnädiger Weise die Verwendung der Kürzel, ohne die 159 sFr für den Standard bezahlt zu haben).<br /> <br /> Naheliegend wäre auch, sich bei den [https://d-nb.info/standards/vocab/gnd/geographic-area-code.html GND-Regionencodes] zu bedienen. <br /> <br /> Allerdings gibt es ZDB-[[Ländercodes]], für die in der GND keine Entsprechung existiert. Mögliche Lösungen wären:<br /> <br /> * GND GeographicAreaCode dort, wo eine Übereinstimmung existiert und GND-Geografikum für die übrigen Regionen.<br /> <br /> * ZDB-Ländercodes mit exakter Entsprechung zu ISO 3166 unter den ISO-Namensraum und die übrigen entweder<br /> # als GND-Geografikum für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://d-nb.info/gnd/35065-5 GND:35065-5])<br /> # als Wikidata-Item für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://www.wikidata.org/wiki/Q170361 WD:Q170361])<br /> <br /> * oder vollständig unter einen eigenen DFF-Vokabular-Namensraum, mit Mappings zu allen bekannten URIs aus anderen Namensräumen.<br /> <br /> ''Kristina: ich finde Option GND GeographicAreaCode + GND-Geografikum oder die letze Option mit mehreren Mappings am besten. Die Mappings würden wir direkt in der ZDB hinterlegen?<br /> ''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Geografika_in_RDF&diff=1736 2026-09-22T08:13:09Z

<p>Dbalzer: /* Klasse &quot;Region&quot; für die ZDB-Ontologie */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Klasse &quot;Region&quot; für die ZDB-Ontologie ==<br /> <br /> Die ZDB-Tabelle &quot;region&quot; soll auch als RDF-Ressource verfügbar gemacht werden, damit künftige RDF-basierte Anwendungen auf alle dort verfügbaren Angaben zugreifen können.<br /> <br /> Eine Modellierung der Tabelle analog zu den Elementvokabularen, d.h. als Instanzen von skos:Concept, müsste allerdings folgende Überlegungen berücksichtigen: <br /> <br /> * Ein ZDB-Ländercode kann für mehrere aufeinanderfolgende Ausprägungen eines Staates oder einer Verwaltungseinheit stehen (prominentes Beispiel: Deutschland). Die ZDB fasst diese Ausprägungen in der Regel unter einem Ländercode zusammen, weil filmografische Quellen nicht immer eine genauere Zuordnung erlauben. In Datenabfragen für Display und Export kann die genauere Bezeichnung allerdings in solchen Fällen ermittelt werden, wo die zetliche Gültigkeit vermerkt ist und mit dem Kontext-Zeitpunkt (Produktion, Aufführung, Prüfung, ...) verglichen werden kann.<br /> <br /> * Prinzipiell fürde sich hier eine SKOS-Modellierung mit Hierarchierelationen anbieten<br /> <br /> == URIs für ZDB-Ländercodes ==<br /> <br /> Für die ISO 3166-Ländercodes gibt es nach wie vor keinen offiziellen RDF-Namensraum (die ISO ist in jeder Hinsicht im 20. Jahrhundert steckengebieben. Immerhin erlaubt man jetzt gnädiger Weise die Verwendung der Kürzel, ohne die 159 sFr für den Standard bezahlt zu haben).<br /> <br /> Naheliegend wäre auch, sich bei den [https://d-nb.info/standards/vocab/gnd/geographic-area-code.html GND-Regionencodes] zu bedienen. <br /> <br /> Allerdings gibt es ZDB-[[Ländercodes]], für die in der GND keine Entsprechung existiert. Mögliche Lösungen wären:<br /> <br /> * GND GeographicAreaCode dort, wo eine Übereinstimmung existiert und GND-Geografikum für die übrigen Regionen.<br /> <br /> * ZDB-Ländercodes mit exakter Entsprechung zu ISO 3166 unter den ISO-Namensraum und die übrigen entweder<br /> # als GND-Geografikum für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://d-nb.info/gnd/35065-5 GND:35065-5])<br /> # als Wikidata-Item für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://www.wikidata.org/wiki/Q170361 WD:Q170361])<br /> <br /> * oder vollständig unter einen eigenen DFF-Vokabular-Namensraum, mit Mappings zu allen bekannten URIs aus anderen Namensräumen.<br /> <br /> ''Kristina: ich finde Option GND GeographicAreaCode + GND-Geografikum oder die letze Option mit mehreren Mappings am besten. Die Mappings würden wir direkt in der ZDB hinterlegen?<br /> ''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Geografika_in_RDF&diff=1735 2026-09-22T07:49:12Z

<p>Dbalzer: /* URIs für ZDB-Ländercodes */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Klasse &quot;Region&quot; für die ZDB-Ontologie ==<br /> <br /> Die ZDB-Tabelle &quot;region&quot; soll auch als RDF-Ressource verfügbar gemacht werden, damit künftige RDF-basierte Anwendungen auf alle dort verfügbaren Angaben zugreifen können.<br /> <br /> Eine Modellierung der Tabelle als Instanzen von skos:Concept stößt allerdings auf Schwierigkeiten, weil mehrere Eigenschaften einer Region <br /> <br /> == URIs für ZDB-Ländercodes ==<br /> <br /> Für die ISO 3166-Ländercodes gibt es nach wie vor keinen offiziellen RDF-Namensraum (die ISO ist in jeder Hinsicht im 20. Jahrhundert steckengebieben. Immerhin erlaubt man jetzt gnädiger Weise die Verwendung der Kürzel, ohne die 159 sFr für den Standard bezahlt zu haben).<br /> <br /> Naheliegend wäre auch, sich bei den [https://d-nb.info/standards/vocab/gnd/geographic-area-code.html GND-Regionencodes] zu bedienen. <br /> <br /> Allerdings gibt es ZDB-[[Ländercodes]], für die in der GND keine Entsprechung existiert. Mögliche Lösungen wären:<br /> <br /> * GND GeographicAreaCode dort, wo eine Übereinstimmung existiert und GND-Geografikum für die übrigen Regionen.<br /> <br /> * ZDB-Ländercodes mit exakter Entsprechung zu ISO 3166 unter den ISO-Namensraum und die übrigen entweder<br /> # als GND-Geografikum für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://d-nb.info/gnd/35065-5 GND:35065-5])<br /> # als Wikidata-Item für den ZDB-Ländercode (Beispiel ZDB:D4 -&gt; [https://www.wikidata.org/wiki/Q170361 WD:Q170361])<br /> <br /> * oder vollständig unter einen eigenen DFF-Vokabular-Namensraum, mit Mappings zu allen bekannten URIs aus anderen Namensräumen.<br /> <br /> ''Kristina: ich finde Option GND GeographicAreaCode + GND-Geografikum oder die letze Option mit mehreren Mappings am besten. Die Mappings würden wir direkt in der ZDB hinterlegen?<br /> ''</div>

Dbalzer https://filmstandards.org/difzf/index.php?title=Elementvokabulare&diff=1734 2026-09-02T20:58:57Z

<p>Dbalzer: /* Anforderungen */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Plan ==<br /> <br /> === Anforderungen ===<br /> <br /> Warum soll an den Vokabularen 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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> '''|Vorschlag|:''' <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller Klassen der ZDB-Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<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, welchen Zweck diese Angaben im konkreten Fall verwendet werden. Die Instanzen von skos:Concept im zdbvoc-Namendarum sollten also auch Properties für solche Aussagen bereitstellen.<br /> <br /> Bisher definiert und in Gebrauch sind <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> '''|Vorschlag|:''' Für diese Aussagen gibt es keine Entsprechung in SKOS oder anderen Thesaurus-Standards. Da skos:Concept als owl:Class definiert ist und SKOS keine strikte Konformität mit OWL-DL vorschreibt, ließen sich diese ZDB-Datenelemente in der ZDB-Ontologie als eigene Properties für Instanzen von skos:Concept definieren:<br /> <br /> zdb:unterNamen<br /> a owl:DatatypeProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range rdfs:Literal ;<br /> rdfs:comment &quot;Ursprung: pdf.relation.P1&quot; .<br /> <br /> zdbvoc:Animation<br /> a skos:Concept ;<br /> ...<br /> zdb:unterNamen rdfs:Literal ; # ex P1 im Kontext &quot;Animation&quot;<br /> zdb:hatDetail rdfs:Literal ; # ex P2 im Kontext &quot;Animation&quot;<br /> ...<br /> <br /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1733 2026-09-02T20:57:39Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> '''|Vorschlag|:''' <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller Klassen der ZDB-Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<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, welchen Zweck diese Angaben im konkreten Fall verwendet werden. Die Instanzen von skos:Concept im zdbvoc-Namendarum sollten also auch Properties für solche Aussagen bereitstellen.<br /> <br /> Bisher definiert und in Gebrauch sind <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> '''|Vorschlag|:''' Für diese Aussagen gibt es keine Entsprechung in SKOS oder anderen Thesaurus-Standards. Da skos:Concept als owl:Class definiert ist und SKOS keine strikte Konformität mit OWL-DL vorschreibt, ließen sich diese ZDB-Datenelemente in der ZDB-Ontologie als eigene Properties für Instanzen von skos:Concept definieren:<br /> <br /> zdb:unterNamen<br /> a owl:DatatypeProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range rdfs:Literal ;<br /> rdfs:comment &quot;Ursprung: pdf.relation.P1&quot; .<br /> <br /> zdbvoc:Animation<br /> a skos:Concept ;<br /> ...<br /> zdb:unterNamen rdfs:Literal ; # ex P1 im Kontext &quot;Animation&quot;<br /> zdb:hatDetail rdfs:Literal ; # ex P2 im Kontext &quot;Animation&quot;<br /> ...<br /> <br /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1732 2026-09-02T20:52:44Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> '''|Vorschlag|:''' <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller Klassen der ZDB-Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<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, welchen Zweck diese Angaben im konkreten Fall verwendet werden. Die Klasse skos:Concept braucht also auch Properties für solche Aussagen.<br /> <br /> Bisher definiert und in Gebrauch sind <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in SKOS oder anderen Thesaurus-Standards. Da skos:Concept als owl:Class definiert ist und SKOS keine strikte Konformität mit OWL-DL vorschreibt, ließen sich diese ZDB-Datenelemente in der ZDB-Ontologie als eigene Properties für Instanzen von skos:Concept definieren:<br /> <br /> zdb:unterNamen<br /> a owl:DatatypeProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range rdfs:Literal ;<br /> rdfs:comment &quot;Ursprung: pdf.relation.P1&quot; .<br /> <br /> zdbvoc:Animation<br /> a skos:Concept ;<br /> ...<br /> zdb:unterNamen rdfs:Literal ; # ex P1 im Kontext &quot;Animation&quot;<br /> zdb:hatDetail rdfs:Literal ; # ex P2 im Kontext &quot;Animation&quot;<br /> ...<br /> <br /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1731 2026-09-02T20:44:55Z

<p>Dbalzer: /* Restriktionen */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> '''|Vorschlag|:''' <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller Klassen der ZDB-Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<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, welchen Zweck diese Angaben im konkreten Fall verwendet werden. Die Klasse skos:Concept braucht also auch Properties für solche Aussagen.<br /> <br /> Bisher definiert und in Gebrauch sind <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in Thesaurus-Standards. Es hindert uns also nichts daran, auch diese ZDB-Datenelemente in der ZDB-Ontologie als eigene Properties für Instanzen von skos:Concept zu definieren:<br /> <br /> zdb:unterNamen<br /> a owl:DatatypeProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range rdfs:Literal ;<br /> rdfs:comment &quot;Ursprung: pdf.relation.P1&quot; .<br /> <br /> zdbvoc:Animation<br /> a skos:Concept ;<br /> ...<br /> zdb:unterNamen rdfs:Literal ; # ex P1 im Kontext &quot;Animation&quot;<br /> zdb:hatDetail rdfs:Literal ; # ex P2 im Kontext &quot;Animation&quot;<br /> ...<br /> <br /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1730 2026-09-02T20:33:26Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller Klassen der ZDB-Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<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, welchen Zweck diese Angaben im konkreten Fall verwendet werden. Die Klasse skos:Concept braucht also auch Properties für solche Aussagen.<br /> <br /> Bisher definiert und in Gebrauch sind <br /> * für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14) <br /> * für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)<br /> <br /> Für diese Aussagen gibt es keine Entsprechung in Thesaurus-Standards. Es hindert uns also nichts daran, auch diese ZDB-Datenelemente in der ZDB-Ontologie als eigene Properties für Instanzen von skos:Concept zu definieren:<br /> <br /> zdb:unterNamen<br /> a owl:DatatypeProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range rdfs:Literal ;<br /> rdfs:comment &quot;Ursprung: pdf.relation.P1&quot; .<br /> <br /> zdbvoc:Animation<br /> a skos:Concept ;<br /> ...<br /> zdb:unterNamen rdfs:Literal ; # ex P1 im Kontext &quot;Animation&quot;<br /> zdb:hatDetail rdfs:Literal ; # ex P2 im Kontext &quot;Animation&quot;<br /> ...<br /> <br /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1729 2026-09-01T21:05:37Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller Klassen der ZDB-Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> ''(veraltet: wird überarbeitet)''<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 /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1728 2026-09-01T21:05:09Z

<p>Dbalzer: /* Restriktionen */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller Klassen der ZDB-Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> (veraltet: wird überarbeitet)<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 /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1727 2026-09-01T20:58:52Z

<p>Dbalzer: /* Organisation der Vokabulare */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConceptSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller rdfs.Class in der Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> (veraltet: wird überarbeitet)<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 /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1726 2026-09-01T20:53:29Z

<p>Dbalzer: /* Der RDF-Graph */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller rdfs.Class in der Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> (veraltet: wird überarbeitet)<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 /> == Diskussion (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1725 2026-09-01T20:52:53Z

<p>Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller rdfs.Class in der Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<br /> <br /> === Ergänzende Relations-Angaben (P1, P2) ===<br /> <br /> (veraltet: wird überarbeitet)<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 (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1724 2026-09-01T20:52:00Z

<p>Dbalzer: /* Restriktionen */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also<br /> <br /> zdbvoc:PersonDomain a skos:Collection ;<br /> member zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller rdfs.Class in der Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<br /> ...<br /> <br /> Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.<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 (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1723 2026-09-01T20:42:13Z

<p>Dbalzer: /* Restriktionen */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Es lässt sich aber unter den Namensraum des Vokabulars eine eigene Property definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity . # Oberklasse aller rdfs.Class in der Ontologie<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<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 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 (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1722 2026-09-01T20:37:10Z

<p>Dbalzer: /* Restriktionen */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 zdbvoc:Adaption ; <br /> member zdbvoc:Drehbuch ; <br /> ...<br /> <br /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Es lässt sich aber unter den Namensraum des Vokabulars eine eigene Property definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity .<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<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 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 (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1721 2026-09-01T20:35:45Z

<p>Dbalzer: /* Diskussion (alt) */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Es lässt sich aber unter den Namensraum des Vokabulars eine eigene Property definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity .<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<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 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 (neu) ==<br /> <br /> <br /> == Diskussion (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1720 2026-09-01T20:35:05Z

<p>Dbalzer: /* Restriktionen */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 /> Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. Naheliegend wären rdfs:range und rdfs:domain, aber diese Properties lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Es lässt sich aber unter den Namensraum des Vokabulars eine eigene Property definieren:<br /> <br /> zdb:conceptDomain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity .<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:conceptDomain zdb:Beteiligung ;<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 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 (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1719 2026-09-01T20:32:32Z

<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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 /> Eine bessere 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 lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Man könnte aber unter den Namensraum des Vokabulars eine eigene Property definieren:<br /> <br /> zdb:domain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity .<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Beteiligung ;<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 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 (alt) ==<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1718 2026-09-01T20:31:45Z

<p>Dbalzer: /* Restriktionen */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<br /> <br /> === Restriktionen ===<br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<br /> <br /> 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 /> Eine bessere 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 lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Man könnte aber unter den Namensraum des Vokabulars eine eigene Property definieren:<br /> <br /> zdb:domain a owl:ObjectProperty ;<br /> rdfs:domain skos:Concept ;<br /> rdfs:range zdb:Entity .<br /> <br /> zdbvoc:Drehbuch a skos:Concept ;<br /> zdbvoc:domain zdb:Beteiligung ;<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 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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1717 2026-09-01T20:15:31Z

<p>Dbalzer: /* Organisation der Vokabulare */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1716 2026-09-01T20:14:28Z

<p>Dbalzer: /* Relations-Kontexte */</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 /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben. <br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1715 2026-09-01T20:13:30Z

<p>Dbalzer: /* Relations-Kontexte */</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 /> === Relations-Kontexte ===<br /> <br /> Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden: <br /> <br /> * die Tabelle &quot;reldef&quot; definiert Beziehungen der Form m:n (''many-to-many''). die in der Tabelle &quot;relation&quot; für Aussagen zu Beziehungen zwischen jeweils zwei Entitäten verwednet werden. In OWL entpricht dies dem Typ ObjectProperty.<br /> <br /> * Tabelle &quot;term&quot; definiert Beziehungen der Formen 1:n und 1:1, die als Aussagen zu verschiedenen Eigenschaften einer Entität verwendet werden. In OWL entspricht die Form 1:n dem Typ DatatypeProperty und die Form 1:1 dem Typ FunctionalProperty.<br /> <br /> Der wichtigste Unterschied ist hierbei, dass es sich bei der n:m-Relation (ObjectProperty) auf beiden Seiten (Subjekt und Objekt) um Instanzen vollwertiger Entitäten handelt, während dies bei der 1:n und der 1:1-Relation nur für das Subjekt gilt. Das Objekt ist hier lediglich ein Begriff, also ein Abstraktum, das dem Subjekt als Typus zugeordnet wird.<br /> <br /> In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von &quot;Person&quot; mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen keine mehrfachen Eigenschaftsaussagen, so ist beispielsweise für eine Instanz von &quot;Aufführung&quot; nur eine einzige Aussage zum Aufführungstyp zugelassen.<br /> <br /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben. <br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1714 2026-09-01T19:49:54Z

<p>Dbalzer: /* Organisation der Vokabulare */</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 /> === Relations-Kontexte ===<br /> <br /> Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden: <br /> <br /> * die Tabelle &quot;reldef&quot; definiert Beziehungen der Form m:n (''many-to-many''). die in der Tabelle &quot;relation&quot; für Aussagen zu Beziehungen zwischen jeweils zwei Entitäten verwednet werden. In OWL entpricht dies dem Typ ObjectProperty.<br /> <br /> * Tabelle &quot;term&quot; definiert Beziehungen der Formen 1:n und 1:1, die als Aussagen zu verschiedenen Eigenschaften einer Entität verwendet werden. In OWL entspricht die Form 1:n dem Typ DatatypeProperty und die Form 1:1 dem Typ FunctionalProperty.<br /> <br /> Der wichtigste Unterschied ist hierbei, dass es sich bei der n:m-Relation (ObjectProperty) auf beiden Seiten (Subjekt und Objekt) um Instanzen vollwertiger Entitäten handelt, während dies bei der 1:n und der 1:1-Relation nur für das Subjekt gilt. Das Objekt ist hier lediglich ein Begriff, also ein Abstraktum, das dem Subjekt als Typus zugeordnet wird.<br /> <br /> In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von &quot;Person&quot; mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen keine mehrfachen Eigenschaftsaussagen, so ist beispielsweise für eine Instanz von &quot;Aufführung&quot; nur eine einzige Aussage zum Aufführungstyp zugelassen.<br /> <br /> &lt;blockquote style=&quot;background-color:yellow&quot;&gt;<br /> '''Hinweis:''' Die nachfolgenden Abschnitte sind nicht mehr aktuell. Sie werden ersetzt, sobald die RDF-Darstellung der Vokabulare verbindlich vereinbart ist.<br /> &lt;/blockquote&gt;<br /> <br /> <br /> === Organisation der Vokabulare ===<br /> <br /> '''skos:ConceptScheme'''<br /> <br /> Wir unterscheiden zwei ConcepSchemes:<br /> * term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)<br /> * rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten<br /> <br /> '''skos:ConceptGroup'''<br /> <br /> In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt. <br /> <br /> '''skos:Concept'''<br /> <br /> Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben. <br /> <br /> Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in [https://www.w3.org/TR/skos-primer/#secskosowl Sektion 5.2 des SKOS Primer] beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=1711 2026-08-28T07:34:39Z

<p>Dbalzer: /* Organisation der Vokabulare */</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 /> === Relations-Kontexte ===<br /> <br /> Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden: <br /> <br /> * die Tabelle &quot;reldef&quot; definiert Beziehungen der Form m:n (''many-to-many''). die in der Tabelle &quot;relation&quot; für Aussagen zu Beziehungen zwischen jeweils zwei Entitäten verwednet werden. In OWL entpricht dies dem Typ ObjectProperty.<br /> <br /> * Tabelle &quot;term&quot; definiert Beziehungen der Formen 1:n und 1:1, die als Aussagen zu verschiedenen Eigenschaften einer Entität verwendet werden. In OWL entspricht die Form 1:n dem Typ DatatypeProperty und die Form 1:1 dem Typ FunctionalProperty.<br /> <br /> Der wichtigste Unterschied ist hierbei, dass es sich bei der n:m-Relation (ObjectProperty) auf beiden Seiten (Subjekt und Objekt) um Instanzen vollwertiger Entitäten handelt, während dies bei der 1:n und der 1:1-Relation nur für das Subjekt gilt. Das Objekt ist hier lediglich ein Begriff, also ein Abstraktum, das dem Subjekt als Typus zugeordnet wird.<br /> <br /> In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von &quot;Person&quot; mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen keine mehrfachen Eigenschaftsaussagen, so ist beispielsweise für eine Instanz von &quot;Aufführung&quot; nur eine einzige Aussage zum Aufführungstyp zugelassen.<br /> <br /> &lt;blockquote style=&quot;background-color:yellow&quot;&gt;<br /> '''Hinweis:''' Die nachfolgenden Abschnitte sind nicht mehr aktuell. Sie werden ersetzt, sobald die RDF-Darstellung der Vokabulare verbindlich vereinbart ist.<br /> &lt;/blockquote&gt;<br /> <br /> <br /> === Organisation der Vokabulare ===<br /> <br /> skos:Concept<br /> <br /> Jedes Vokabularelement der DFF-ZDB wird, entprechend einer weit verbreiteten Konvention, als eine Instanz der Klasse skos:Concept definiert. Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben. <br /> <br /> skos:ConceptGroup<br /> <br /> skos:ConceptScheme<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 /> **KR: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. &quot;Voraufführung&quot; isA &quot;Aufführung&quot; (also &quot;Voraufführung&quot; als narrower Term von &quot;Aufführung&quot; oder &quot;Uraufführung&quot; isA &quot;Erstaufführung&quot; oder &quot;Titelübersetzung&quot; isA &quot;Weiterer Titel&quot;<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=Jour_fixe_2026-08-28&diff=1710 2026-08-27T19:46:08Z

<p>Dbalzer: /* Vokabular-URIs */</p> <hr /> <div>Eine Seite aus dem [[Reformhaus]]<br /> <br /> == Jour fixe, Freitag, 28. August 2026 ==<br /> <br /> === Eine Handvoll RDF-Themen: ===<br /> <br /> ==== Gattungen ====<br /> Ist dieses Vokabular hier irgendwie nachnutzbar? Leider funktioniert das Aufrufen der URIs auch nicht wirklich, weil etwas in XTree falsch konfiguriert ist. https://xtree-public.digicult-verbund.de/vocnet/?uriVocItem=http://filmportal.vocnet.org/category/&amp;startNode=c00061&amp;lang=de&amp;d=n <br /> <br /> ==== Geografika ====<br /> Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?<br /> <br /> Ein paar Überlegungen dazu sind hier schon notiert: [[Geografika in RDF]]<br /> <br /> ==== Ranges und Domains ====<br /> Jetzt, wo wir die Vokabulare aus pdf.term und pdf.reldef in SKOS formuliert und ausgelagert haben, stellt sich mir die Frage nach der Verwendung von rdfs:range/rdfs:domain. <br /> In den Vokabular-Definitionen fallen Domain/Range komplett raus, weil es dort ja um skos:Concepts geht und nicht um Properties. Ich habe die bestehenden Aussagen durch zdbvoc:domain/zdbvoc:range geändert, damit die Info erstmal nicht verloren geht. Wenn wir das beibehalten wollen, müssen wir die Properties noch definieren.<br /> <br /> In der Ontologie-Definition steht bei den Properties, welche in unserem RDF-Ausdruck der ZDB-Daten zu den o.g. Vokabularen führen, jetzt zdbvoc:term<br /> zdb:hatGattung a owl:ObjectProperty ;<br /> rdfs:label &quot;hat Gattung&quot; ;<br /> rdfs:range zdbvoc:term ; # rdfs:Resource?<br /> rdfs:domain zdb:Filmwerk .<br /> Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss? <br /> Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:<br /> zdb:inFunktion a owl:ObjectProperty ;<br /> rdfs:label &quot;in Funktion&quot; ;<br /> rdfs:range zdbvoc:rels ; # changed from zdbvoc:term <br /> rdfs:domain zdb:Beteiligung .<br /> Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?<br /> <br /> ''DB: da ist auf jeden Fall noch was zu tun. Ja, ein skos:Concept sollte eigentlich keine rdfs:domain haben; die Verwendungs-Restriktion sollten wir anders ausdrücken.''<br /> <br /> ==== zdbvoc:P1 / zdbvoc:P2 ====<br /> Müssen diese Properties in den Vokabular-Definitionen stehen, um diese in der ZDB nutzen zu können? Für den RDF-Ausdruck der ZDB werden sie ja nicht wirklich benötigt, weil die Werte mit u.a. zdb:inRolle, zdb:genanntAls modelliert werden.<br /> <br /> ''DB: Stimmt. In der RDF-Darstellung sollten diese Properties so heißen, wie sie in 'reldef' für den jeweiligen Kontext definiert sind. Die Übersetzng aus der ZDB-Tabelle 'relation' wird dann beim RDF-Export erledigt.''<br /> <br /> ==== Entitäten-URIs ====<br /> Wir möchten gerne URIs à la ld.filmportal.de/4E097896FE814D858788B0FCC0FA3D89 für die Entitäten (außerhalb der Vokabulare) verwenden – also eine Subdomain von filmportal.de (siehe: https://filmstandards.org/difzf/index.php?title=Jour_fixe_2026-07-10)<br /> Wir brauchen noch ein bisschen Nachhilfe, was das konkret für die Einrichtung dieser Subdomain bedeutet. Was müssen wir dafür mit Werk21 klären? Oder kann diese Subdomain unabhängig vom Drupal auf www.filmportal.de verwaltet werden?<br /> <br /> ''DB: Grundsätzlich gibt es zwei Möglichkeiten: ''<br /> <br /> ''(1) Filmportal-URI (https-URL) ist identisch für die Web-Darstellung in Portal und für die Linked-Data-Ressource. Unterschieden wird per Content Negotiation, zusätzlich vielleicht auch per Suffix (.json, .ttl u.a.). Werk21 müsste dafür ein Stückchen Resolver-Code in ihren Webserver einfügen (der Code kann von uns kommen). ''<br /> <br /> ''(2) Alle RDF-Ressourcen werden über eine Subdomain wie ld.filmportal.de geliefert. Auch da würden wir einen Resolver mit Content Negotiation und eventuell Suffix-Erkennung verwenden, um die gewünschte RDF-Serialisierung zu aktivieren. ''<br /> <br /> ''Der Eigentümer der Domain filmportal.de kann jederzeit Subdomains einrichten und an die IP-Adresse eines bestimmten Servers (z.B. den neu anzumietenden Server mit den RDF-Daten) konnektieren. Wenn das DFF die Domain als Eigentümer verwaltet, braucht Werk21 gar nicht bemüht werden.''<br /> <br /> ==== Vokabular-URIs ====<br /> <br /> Wenn diese mit abstrakten wie Ziffernfolgen als Bezeichner gebildet werden, sollte eine auf technischer Ebene mögliche Konfusion des Lokalteils mit Zahlenwerten vermieden werden. Beispielsweise wird der String &quot;34&quot; in Javascript zur Zahl 34 konvertiert, auch in Spreadsheets kann so etwas vorkommen. Viele RDF-basierte URI-Schemata setzen deshalb vor die Ziffernfolge einen Buchstaben, sodass der Lokalteil eines URI auch isoliert immer als String erkannt wird (&quot;Q&quot; bei Wikidata, &quot;E&quot; und &quot;P&quot; bei CIDOC-CRM, &quot;sj&quot;, &quot;n&quot;, &quot;no&quot; usw. bei LCSH, ...).<br /> <br /> Für das ZDB-Vokabular würde sich anbieten, die Terme mit &quot;T&quot; und die Relatoren mit &quot;R&quot; zu kennzeichnen, beispielsweise &quot;zdbvoc:Ehe_mit&quot; -&gt; &quot;zdbvoc:R016&quot;; &quot;zdbvoc:Originaltitel&quot; -&gt; &quot;zdbvoc:T003&quot;. Denkbar wäre auch, jeder skos:Collection (zusätzlich) einen eigenen Buchstaben zu geben, z.B. &quot;RC&quot; für rels-&gt;Credits; das entspräche dem Verfahren bei den LoC Authority Files.<br /> <br /> ==== „Hat …-Typ“-Properties ====<br /> Wir haben jetzt mehrere Properties, die die eine Instanz mit ihrem Typ aus dem Typenvokabular verbinden: zdb:hatTitelTyp, zdb:hatManifestationstyp, zdb:hatAuffuehrungsTyp, zdb:hatPruefungsTyp. Ist stattdessen auch eine generellere Property zdb:hatTyp denkbar? Ich habe sie testweise in Version 0.4.1 modelliert.<br /> <br /> ''DB: die differenzierten Properties soll(t)en die Restriktion auf das zulässige Teilvokabular ausdrücken. Wenn wir SHACL zur Konformiätsprüfung einsetzen, dann können wir den konkret zulässigen Typ anhand des Aussagesubjekts bestimmen; damit müsste zdb:hatTyp ausreichen. ''<br /> <br /> ==== Mapping ====<br /> Ich habe vor einigen Jahren Mal RML / RML Mapper für das Generieren von Linked Data ausprobiert. Damals war das nicht so erfolgreich, weil die Ausgangsdatei ein XML war und xSLT am Ende besser funktioniert hat. Aber RML schien mir auf Tabellen als Ausgangsformat ausgelegt zu sein. Vielleicht interessant für uns? https://rml.io/specs/rml/ https://www.w3.org/TR/r2rml/<br /> <br /> ''DB: Ich hatte mir das vor einiger Zeit auch mal angesehen und kam zu dem Ergebnis, dass es für Datenbanken mit striktem ER-Modell (also für jede m:n-Relation eine eigene Kreuztabelle) wohl nützlich wäre. Die ZDB verwendet aber ein hybrides Datenmodell mit einer einzigen SPO-Tabelle für alle m:n-Relationen, die zudem keine klassische Kreuztabelle ist. Da habe ich nicht rausgefunden, wie das mit RML zu handhaben wäre.''<br /> <br /> ==== URIs für unselbstständiuge Entitäten ====<br /> <br /> Im Filmwerk-Entwurf von DB sind nur die UIDs für Entitäten Filmwerk, Person und Körperschaft als Filmportal-URIs dargestellt. Alles Andere wir das Blank Node behandelt, ist also nicht als eigene Ressource referenzierbar. Motivation hierfür war, dass auf diese Weise mittels SPARQL DESCRIBE ein nahezu kompletter Filmwerks-Datensatz konstruiert wird.<br /> <br /> Der Entwurf von KR stellt alle UIDs der ZDB unter den öffentlichen Namensraum (fpde:). Damit wären auch unselbstständige Entitäten wie Aufführung, Manifestation, etc. als RDF-Ressource aus der LD-Sphäre abrufbar.<br /> <br /> Mit dem Entwurf von KR lassen sich vollständige Filmwerks-Datensätze nur mit komplexen SPARQL-Abfragen erzeugen. Vgl. hierzu die [https://www.wikidata.org/wiki/Q1273863 aggregierte Datensicht] in wikidata.org mit der von [https://query.wikidata.org/#DESCRIBE%20wd%3AQ1273863 SPARQL DESCRIBE] in query.wikidata.org; im ersten Fall wird die Datensicht unsichtbar im Hintergrund erzeugt, im zweiten Fall erhalten wir nur eine flache Liste der direkt verbundenen Tripel.<br /> <br /> Fazit (DB): Der Vorschlag von KR ist technisch anspruchsvoller, bietet aber langfristig mehr Möglichkeiten für die Datenauswertung. Im Übrigen wird die Komplexität für vollständige Filmwerks-Ansichten mit SPARQL nicht wesentlich anders sein als die mit den (im Hintergrund ablaufenden) SQL-Abfragen in der ZDB.<br /> <br /> ==== IDTitel versus Titel ====<br /> <br /> Im Ontologie-Entwurf 0.4.1 ist die Property IDTitel entfernt worden; im Filmwerk-Entwurf wurde IDTitel durch hatTitel (...) ersetzt. Im ZDB-Datenmodell ist IDTitel absichtlich nicht als Instanz von Filmtitel modelliert, weil es hier als direkte, menschenlesbare Bezeichnung für das Filmwerk dient. Es ist ein einfacher String-Wert ohne weitere Eigenschaften. Bei der Erfassung wird der IDTitel automatisch aus den eigentlichen Titelangaben generiert und erfüllt nur den Zweck, das Filmwerk für menschliche Leser ohne SQL-Joins (und künftig in SPARQL ohne Property Chains) identifizierbar zu machen.<br /> <br /> === Laufendes ===<br /> <br /> ==== Neuer Server ====<br /> <br /> Wie ist der Stand bei der Beschaffung?<br /> <br /> ==== Datensicherung ====<br /> <br /> Gibt es Fortschritte in den Gesprächen mit der DFF-IT?</div>

Dbalzer