Elementvokabulare - Versionsgeschichte

Dbalzer: /* Verwendungskontexte */

2026-07-21T14:57:58Z

‎Verwendungskontexte

Dbalzer: /* Verwendungskontexte */

2026-07-21T14:30:49Z

‎Verwendungskontexte

Dbalzer: /* ZDB-Integration */

2026-07-21T13:58:18Z

‎ZDB-Integration

Krose am 9. April 2026 um 14:51 Uhr

2026-04-09T14:51:16Z

Dbalzer: /* Diskussion */

2026-04-08T09:29:18Z

‎Diskussion

Dbalzer am 8. April 2026 um 07:26 Uhr

2026-04-08T07:26:13Z

Dbalzer: /* Der RDF-Graph */

2026-04-08T07:24:36Z

‎Der RDF-Graph

Dbalzer: /* Ergänzende Relations-Angaben (P1, P2) */

2026-03-05T20:14:47Z

‎Ergänzende Relations-Angaben (P1, P2)

Dbalzer: /* Restriktionen */

2026-03-05T20:10:20Z

‎Restriktionen

Dbalzer: /* ZDB-Integration */

2026-03-05T19:19:04Z

‎ZDB-Integration

@@ Zeile 23: / Zeile 23: @@
 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.
-=== Verwendungskontexte ===
+=== Relations-Kontexte ===
 Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden:
@@ Zeile 31: / Zeile 31: @@
 * Tabelle "term" 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.
-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 Abtraktum, das dem Subjekt als Typus zugeordnet wird.
+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.
-In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von "Person" mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen nur eine einmalige Eigenschaftsaussage, so darf beispielsweise eine Instanz von "Aufführung" nur eine einzige Aussage zum Aufführungstyp haben.
+In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von "Person" mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen keine mehrfachen Eigenschaftsaussagen, so ist beispielsweise für eine Instanz von "Aufführung" nur eine einzige Aussage zum Aufführungstyp zugelassen.
 === Restriktionen ===

← Nächstältere Version		Version vom 21. Juli 2026, 14:30 Uhr
Zeile 30:		Zeile 30:

	* Tabelle "term" 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.		* Tabelle "term" 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.
		+
		+	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 Abtraktum, das dem Subjekt als Typus zugeordnet wird.
		+
		+	In 1:n-Beziehungen kann es mehrere Aussagen zu einer Eigenschaft geben, beispielsweise kann eine Instanz von "Person" mehr als eine charakteristische Tätigkeit haben. Die 1:1-Beziehung erlaubt dagegen nur eine einmalige Eigenschaftsaussage, so darf beispielsweise eine Instanz von "Aufführung" nur eine einzige Aussage zum Aufführungstyp haben.

	=== Restriktionen ===		=== Restriktionen ===

@@ Zeile 23: / Zeile 23: @@
 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.
-=== ZDB-Integration ===
+=== Verwendungskontexte ===
-Die ZDB-Bearbeitungeformulare sollen die Inhalte der Auswahllisten über eine einheitliche Programmschnittstelle (API) vom neu einzurichtenden Vokabulardienst beziehen. Das wird im Wesentlichen die gleiche Schnittstelle sein, die auch anderen Datennutzern zur Verfügung steht.
+Im ZDB-Modell wird zwischen zwei Arten von Vokabularen unterschieden:
 === Restriktionen ===

@@ Zeile 79: / Zeile 79: @@
 * 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?
 ** Die Beziehung zwischen Gruppierung und Tätigkeit folgt nicht der Definition für logische Hierarchiebeziehungen, wie von SKOS für broader/narrower gefordert ("Schnitt" IsA "Schnitt", "Licht" IsA "Kamera" 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.
 * 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 "meinem" 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?

@@ Zeile 75: / Zeile 75: @@
 * 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?
-** 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 "betriebsinternen" Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird.
+** 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 "betriebsinternen" 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.
-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?
+* 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?
-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 "meinem" 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?
+* 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 "meinem" 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?
-KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes "Untervokabular" einen eigenen Namensraum erstellt. Was ist da der Vorteil?
+* KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes "Untervokabular" einen eigenen Namensraum erstellt. Was ist da der Vorteil?
-KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?
+* KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?

← Nächstältere Version		Version vom 8. April 2026, 07:26 Uhr
Zeile 1:		Zeile 1:
	Eine Seite aus dem [[Reformhaus]]		Eine Seite aus dem [[Reformhaus]]
		+
		+	== Plan ==

	=== Anforderungen ===		=== Anforderungen ===

← Nächstältere Version		Version vom 8. April 2026, 07:24 Uhr
Zeile 69:		Zeile 69:

	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.		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.
		+
		+	== Diskussion ==
		+
		+	* 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?
		+	** 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 "betriebsinternen" Properties sind keineswegs unüblich und externe Nutzung beschränkt sich ohnehin auf das, was benötigt wird.
		+
		+	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?
		+
		+	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 "meinem" 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?
		+
		+	KR: Das mit den Named Graphs müsstest du mir glaube ich nochmal erklären. Du hast jetzt ja für jedes "Untervokabular" einen eigenen Namensraum erstellt. Was ist da der Vorteil?
		+
		+	KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?

@@ Zeile 51: / Zeile 51: @@
 Für viele der Relations-Vokabularelemente sind im ZDB-Datenbankmodell (Tabelle "reldef") mit "P1" und "P2" 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.
-Bisher gibt es für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)
+Bisher definiert und in Gebrauch sind für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)
 und für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)

@@ Zeile 27: / Zeile 27: @@
 === Restriktionen ===
-Für eine vollständige Integration in die ZDB-Schnittstelle zur Credits-Bearbeitung ist das Problem der Anwendungs-Restriktion zu lösen: Einige Funktionsbegriffe sind nur für Personen definiert, andere nur für Körperschaften und manche für beide Entitäten. Dazu kommen noch die reifizierten Aussagen (domain: REL).
+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.
 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
@@ Zeile 44: / Zeile 44: @@
       zdbvoc:range zdb:Person ;
       ...
 === Ergänzende Relations-Angaben (P1, P2) ===