Jour fixe 2026-01-09 - Versionsgeschichte

Dbalzer: /* Änderungen im Relationen-Vokabular */

2026-01-09T09:29:50Z

‎Änderungen im Relationen-Vokabular

Dbalzer: /* Werks-Hierarchien */

2026-01-09T09:26:10Z

‎Werks-Hierarchien

Dbalzer: /* Vokabulardienst */

2026-01-06T13:18:41Z

‎Vokabulardienst

Dbalzer: /* Orts- und Zeitangaben */

2026-01-06T13:18:08Z

‎Orts- und Zeitangaben

Dbalzer: /* Orts- und Zeitangaben */

2026-01-06T12:51:00Z

‎Orts- und Zeitangaben

Dbalzer: /* Literale Werte */

2026-01-06T11:57:23Z

‎Literale Werte

Dbalzer: /* Diskussion Ontologie-Entwurf */

2026-01-06T10:46:39Z

‎Diskussion Ontologie-Entwurf

Dbalzer: /* Diskussion Ontologie-Entwurf */

2026-01-06T10:30:06Z

‎Diskussion Ontologie-Entwurf

Dbalzer: /* Diskussion Ontologie-Entwurf */

2026-01-06T09:21:58Z

‎Diskussion Ontologie-Entwurf

Dbalzer: /* Diskussion Ontologie-Entwurf */

2026-01-06T09:20:49Z

‎Diskussion Ontologie-Entwurf

@@ Zeile 16: / Zeile 16: @@
 • Wenn wir einem Relator eine neue Gruppe zuweisen, welche Folgen hat das innerhalb der ZDB? Gar keine, weil sie nicht ausgegeben werden?
-* ''Die RelatorGruppe wird als zusätzliches Sortierkriterium bei der ZDB-Filmwerks-Ansicht und in den Austauschformaten verwendet, um beispielsweise die Darsteller-Credits im Anschluss an die anderen Funktionen ausgeben zu können. Allein nach Notation würden sie vor allen anderen Credits erscheinen.''
+* ''Die RelatorGruppe wird als zusätzliches Sortierkriterium bei der ZDB-Filmwerks-Ansicht und in den Austauschformaten verwendet, um die gewünschte Ausgabereihenfolge der Gewerke zu bestimmen.''
 • Welche Änderungsbedarfe bestehen noch an den Eintragungen in der Spalte „Notation“ in pdf.reldef

@@ Zeile 45: / Zeile 45: @@
 : DB -> ''Mit Filmwerk und Aggregatwerk als Geschwisterklassen sehe ich kein grundsätzliches Problem. Oder übersehe ich da etwas? FRBR-oo hat einen ganzen Zoo an direkten Unterklassen von [https://www.iflastandards.info/fr/frbr/frbroo#F1 F1 Work], neben F14 Individual Work noch F15 Complex Work, F16 Container Work, F17 Aggregation Work, F18 Serial Work und F19 Publication Work. Das [https://www.iflastandards.info/lrm/lrmer.html IFLA LRM] dagegen hat gar keine Unterklassen von E2 Work, sondern differenziert alle Werktypen über die Property E2A1 has category of work.''
 : ''In der ZDB identifizieren wir Aggregate allein anhand des Attributs Titel-Typ, was dem LRM näher käme als der Ansatz aus FRBR-oo. Allerdings müssten wir dann das Filmwerk mit einer Werktyp-Property versehen, was ganz neue Komplikationen aufwirft, denn Aggregatwerke haben ganz andere Eigenschaften als das einzelne Filmwerk.''
 ==== Produktionsereignis ====

@@ Zeile 66: / Zeile 66: @@
 ''
-== Vokabulardienst ==
+=== Vokabulardienst ===
 Eine wichtige Neuerung für die ZDB wäre die Übertragung der "term"-Tabelle in einen RDF-gestützten Vokabular-Webservice. Dies kann relativ kurzfristig geschehen, sobald der Triplestore für die ZDB verfügbar ist.
 Die bisherigen SQL-Anfragen an die Tabelle pdf.term würden sukzessiv durch SPARQL-Anfragen an den SKOS-basierten RDF-Graphen ersetzt. Sobald diese Umstellung abgeschlossen ist, kann die weitere Vokabularpflege im RDF-Graphen erfolgen. Welche Hilfsmittel dafür sinnvoll sind, kann zu einem späteren Zeitpunkt durch Ausprobieren ermittelt werden. Im einfachsten Fall wären Textdateien in Turtle-Syntax zu editieren.

@@ Zeile 63: / Zeile 63: @@
 : ''Geografika sind auch wieder ein Sonderfall. Die ZDB-Konventionen für Länderkürzel finden sich in [[Ländercodes]]. Hier könnte ähnlich verfahren werden wie in der GND, wo mit der Property gndo:geographicAreaCode auf ein eigenes, fallweise mit ISO 3166-1 gemapptes Vokabular zurückgegriffen wird.''
-: ''Für Toponyme existieren teilweise Mappings zur GND, die bei der Datenübermittlung via SCUSI verwendet werden. Die GND erhält im Fall eines vorliegenden Mappings einen GND-URI als Aussagewert. In allen anderen Fällen wird der Ortsname als String-Literal übergeben. Es wäre zu überlegen, ob dieses Verfahren auch für die ZDB-Darstellung als RDF-Graph angewendet werden soll. Für Ortsangaben wäre dann sowohl eine ObjectProperty wie auch eine DatatypeProperty zu definieren.
+: ''Für Toponyme existieren teilweise Mappings zur GND, die bei der Datenübermittlung via SCUSI verwendet werden. Die GND erhält im Fall eines vorliegenden Mappings einen GND-URI als Aussagewert. In allen anderen Fällen wird der Ortsname als String-Literal übergeben. Es wäre zu überlegen, ob dieses Verfahren auch für die ZDB-Darstellung als RDF-Graph angewendet werden soll. Für Ortsangaben wäre dann sowohl eine ObjectProperty wie auch eine DatatypeProperty zu definieren, wie es auch in der GND der Fall ist.
 ''

← Nächstältere Version		Version vom 6. Januar 2026, 12:51 Uhr
Zeile 61:		Zeile 61:
	: DB -> ''dcterms:date wird in den meisten Fällen nicht funktionieren, weil wir vielfach Sonder-Konventionen verwenden, die nur als Literale mit Syntax-Constraints beschieben werden können. Siehe dazu auch [[Syntaxen und Umrechnungsfaktoren]] in diesem Wiki''.		: DB -> ''dcterms:date wird in den meisten Fällen nicht funktionieren, weil wir vielfach Sonder-Konventionen verwenden, die nur als Literale mit Syntax-Constraints beschieben werden können. Siehe dazu auch [[Syntaxen und Umrechnungsfaktoren]] in diesem Wiki''.

−	''Geografika sind auch wieder ein Sonderfall''	+	: ''Geografika sind auch wieder ein Sonderfall. Die ZDB-Konventionen für Länderkürzel finden sich in [[Ländercodes]]. Hier könnte ähnlich verfahren werden wie in der GND, wo mit der Property gndo:geographicAreaCode auf ein eigenes, fallweise mit ISO 3166-1 gemapptes Vokabular zurückgegriffen wird.''
		+
		+	: ''Für Toponyme existieren teilweise Mappings zur GND, die bei der Datenübermittlung via SCUSI verwendet werden. Die GND erhält im Fall eines vorliegenden Mappings einen GND-URI als Aussagewert. In allen anderen Fällen wird der Ortsname als String-Literal übergeben. Es wäre zu überlegen, ob dieses Verfahren auch für die ZDB-Darstellung als RDF-Graph angewendet werden soll. Für Ortsangaben wäre dann sowohl eine ObjectProperty wie auch eine DatatypeProperty zu definieren.
		+	''

← Nächstältere Version		Version vom 6. Januar 2026, 11:57 Uhr
Zeile 55:		Zeile 55:

	: DB -> ''In RDF können wir Literale mit syntaktischen Restriktionen versehen. Für das Bildseitenverhältnis beispielsweise käme der reguläre Ausdruck "/\d:\d/", in Frage, für die Zeitangaben sähe es etwas komplexer aus. Bei einem RDF-Export müssen wir außerdem berücksichtigen, dass syntaktisch normierte Literale nicht immer den Vorschriften entsprechen bzw. schon retrospektiv normiert wurden. Die aufzählbaren Literal-Werte (z.B. Aufführungsart), die in der ZDB meist schon in der Vokabulartabelle ("term") definiert sind, sollten wir immer als ObjectProperty mit einem Vokabularelement-IRI in der Objekt-Position darstellen. Damit können wir die Ontologie auf Definitionen mit "Ewigkeitscharakter" beschränken.''		: DB -> ''In RDF können wir Literale mit syntaktischen Restriktionen versehen. Für das Bildseitenverhältnis beispielsweise käme der reguläre Ausdruck "/\d:\d/", in Frage, für die Zeitangaben sähe es etwas komplexer aus. Bei einem RDF-Export müssen wir außerdem berücksichtigen, dass syntaktisch normierte Literale nicht immer den Vorschriften entsprechen bzw. schon retrospektiv normiert wurden. Die aufzählbaren Literal-Werte (z.B. Aufführungsart), die in der ZDB meist schon in der Vokabulartabelle ("term") definiert sind, sollten wir immer als ObjectProperty mit einem Vokabularelement-IRI in der Objekt-Position darstellen. Damit können wir die Ontologie auf Definitionen mit "Ewigkeitscharakter" beschränken.''
		+
		+	==== Orts- und Zeitangaben ====
		+	: KR -> In einigen Fällen habe ich keine eigenen Properties modelliert, sondern auf dcterms:spatial und dcterms:date zurückgegriffen. Mir erschien es, dass viele Orts- und Zeit-Attribute in der ZDB doch semantisch ähnlich sind und es keine spezifischen/unterschiedlichen Properties dafür bräuchte. (Beispielsweise: Titelregion, Ort der Dreharbeiten, Aufführungsort, Zeitangabe der Aufführung, Zeitangabe des Titels, Zeitangabe des Aggregatwerks, Produktionsjahr (das ist wahrscheinlich etwas streitbar ;-) )
		+
		+	: DB -> ''dcterms:date wird in den meisten Fällen nicht funktionieren, weil wir vielfach Sonder-Konventionen verwenden, die nur als Literale mit Syntax-Constraints beschieben werden können. Siehe dazu auch [[Syntaxen und Umrechnungsfaktoren]] in diesem Wiki''.
		+
		+	''Geografika sind auch wieder ein Sonderfall''

@@ Zeile 40: / Zeile 40: @@
 === Diskussion Ontologie-Entwurf ===
-Werks-Hierarchien
+==== Werks-Hierarchien ====
 :  KR -> Ich glaube, die hierarchische Modellierung von Werk - Aggregatwerk - Filmwerk ist noch etwas schief bzw. könnten da über "inferred"-Logiken komische Aussagen bei herumkommen. Werk hatte ich als unspezifizierte Überklasse mit hereingenommen, um zum Filmwerk noch andere Werksarten wie Musik und Literatur (siehe unten) ergänzen zu können, aber gleichzeitig einen übergeordneten Knoten zu haben. Wo steht das Aggregatwerk in diesem Konstrukt? Ich hatte es jetzt auch dem Werk untergordnet, aber irgendwo sind dann schon komische Dinge passiert...
@@ Zeile 46: / Zeile 46: @@
 : ''In der ZDB identifizieren wir Aggregate allein anhand des Attributs Titel-Typ, was dem LRM näher käme als der Ansatz aus FRBR-oo. Allerdings müssten wir dann das Filmwerk mit einer Werktyp-Property versehen, was ganz neue Komplikationen aufwirft, denn Aggregatwerke haben ganz andere Eigenschaften als das einzelne Filmwerk.''
-Produktionsereignis
+==== Produktionsereignis ====
 : KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder? ''
 : DB -> ''Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein.  Grundsätzlich spräche nichts dagegen, im RDF-Graphen Eigenschaften wie Land, Zeitangabe, Gattung und alle Credits unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind.''
-Literale Werte
+==== Literale Werte ====
 : KR -> Einige Angaben in der ZDB sind Freitextfelder, v.a. bei den Manifestationseigenschaften. In V0.1 habe ich mich relativ nah an den Ist-Zustand gehalten und keine Klassen für "Trägermaterial", "Bildseitenverhältnis" etc. modelliert. stattdessen haben die entsprechenden Properties ebenfalls ein Literal als Wert, um den Mappingaufwand gering zu halten. Aufwändige Matchingtabellen würden dadurch gespart - aber eben auf Kosten der Interoperabilität und ggf. Mehrsprachigkeit. Wenn man wie oben vorgeschlagen die "Kern-Ontologie" von den Vokabularen trennt, ist man hier aber vielleicht insofern etwas flexibler, dass man sehr eindeutige Werte aus ein LOD-Vokabular matchen könnte und für alles andere dann die Literale beibehält?
-: DB -> ''In RDF können wir Literale mit verschiedenen Arten von Restriktionen versehen. Für das Bildseitenverhältnis beispielsweise käme der reguläre Ausdruck "/\d:\d/", in Frage, für die Zeitangaben sähe es etwas komplexer aus. Grundsätzlich sollten wir die Ontologie auf Definitionen mit "Ewigkeitscharakter" beschränken. Bei einem RDF-Export müssen wir berücksichtigen, dass syntaktisch normierte Literale nicht immer den Vorschriften entsprechen bzw. schon retrospektiv normiert wurden. Bei den aufzählbaren Literal-Werten (z.B. Aufführungsart), die in der ZDB meist schon in der Vokabulartabelle ("term") definiert sind, sollten wir nur definieren, aus welchem Teilvokabular die Aussage kommen muss.''
+: DB -> ''In RDF können wir Literale mit syntaktischen Restriktionen versehen. Für das Bildseitenverhältnis beispielsweise käme der reguläre Ausdruck "/\d:\d/", in Frage, für die Zeitangaben sähe es etwas komplexer aus. Bei einem RDF-Export müssen wir außerdem berücksichtigen, dass syntaktisch normierte Literale nicht immer den Vorschriften entsprechen bzw. schon retrospektiv normiert wurden. Die aufzählbaren Literal-Werte (z.B. Aufführungsart), die in der ZDB meist schon in der Vokabulartabelle ("term") definiert sind, sollten wir immer als ObjectProperty mit einem Vokabularelement-IRI in der Objekt-Position darstellen. Damit können wir die Ontologie auf Definitionen mit "Ewigkeitscharakter" beschränken.''

← Nächstältere Version		Version vom 6. Januar 2026, 10:30 Uhr
Zeile 49:		Zeile 49:
	: KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder? ''		: KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder? ''

−	: DB -> ''~~Das ist in der Tat etwas knifflig.~~ Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein. Grundsätzlich spräche nichts dagegen, im RDF-Graphen Eigenschaften wie Land, Zeitangabe, Gattung und alle Credits unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind.''	+	: DB -> ''Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein. Grundsätzlich spräche nichts dagegen, im RDF-Graphen Eigenschaften wie Land, Zeitangabe, Gattung und alle Credits unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind.''
		+
		+	Literale Werte
		+	: KR -> Einige Angaben in der ZDB sind Freitextfelder, v.a. bei den Manifestationseigenschaften. In V0.1 habe ich mich relativ nah an den Ist-Zustand gehalten und keine Klassen für "Trägermaterial", "Bildseitenverhältnis" etc. modelliert. stattdessen haben die entsprechenden Properties ebenfalls ein Literal als Wert, um den Mappingaufwand gering zu halten. Aufwändige Matchingtabellen würden dadurch gespart - aber eben auf Kosten der Interoperabilität und ggf. Mehrsprachigkeit. Wenn man wie oben vorgeschlagen die "Kern-Ontologie" von den Vokabularen trennt, ist man hier aber vielleicht insofern etwas flexibler, dass man sehr eindeutige Werte aus ein LOD-Vokabular matchen könnte und für alles andere dann die Literale beibehält?
		+
		+	: DB -> ''In RDF können wir Literale mit verschiedenen Arten von Restriktionen versehen. Für das Bildseitenverhältnis beispielsweise käme der reguläre Ausdruck "/\d:\d/", in Frage, für die Zeitangaben sähe es etwas komplexer aus. Grundsätzlich sollten wir die Ontologie auf Definitionen mit "Ewigkeitscharakter" beschränken. Bei einem RDF-Export müssen wir berücksichtigen, dass syntaktisch normierte Literale nicht immer den Vorschriften entsprechen bzw. schon retrospektiv normiert wurden. Bei den aufzählbaren Literal-Werten (z.B. Aufführungsart), die in der ZDB meist schon in der Vokabulartabelle ("term") definiert sind, sollten wir nur definieren, aus welchem Teilvokabular die Aussage kommen muss.''

← Nächstältere Version		Version vom 6. Januar 2026, 09:21 Uhr
Zeile 49:		Zeile 49:
	: KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder? ''		: KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder? ''

−	: DB -> ''Das ist in der Tat etwas knifflig. Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein. Grundsätzlich spräche nichts dagegen, Eigenschaften wie Land, Zeitangabe, Gattung und alle Credits unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind.''	+	: DB -> ''Das ist in der Tat etwas knifflig. Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein. Grundsätzlich spräche nichts dagegen, im RDF-Graphen Eigenschaften wie Land, Zeitangabe, Gattung und alle Credits unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind.''

← Nächstältere Version		Version vom 6. Januar 2026, 09:20 Uhr
Zeile 49:		Zeile 49:
	: KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder? ''		: KR -> Es gibt 11 Ereignis-Unterklassen und alle haben eine GUID in der ZDB (glaube ich), nur das am häufigsten verwendete Ereignis nicht - das Produktionsereignis. So wie es in V0.1 gelöst ist, müsste man wohl mit Blank Nodes als Identifikator arbeiten. Da die Eriegnis-GUIDs wohl (bis auf Prüfung?) keine wirkliche Normdatenfunktion haben, ist das ggf. nicht so schlimm, aber wie kritisch sind Blank Nodes für die Nachnutzung? Die ändern ändern sich doch gerne mal, oder? ''

−	: DB -> ''Das ist in der Tat etwas knifflig. Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein. Grundsätzlich spräche nichts dagegen, Eigenschaften wie Land, Zeitangabe und ~~Gattung~~ unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind~~. Beispielweise ließe sich die Credits-Relation 'Filmförderung' hier hineinnehmen~~.''	+	: DB -> ''Das ist in der Tat etwas knifflig. Beim ZDB-Modell sind wir davon ausgegangen, dass ein Filmwerk das Produktionsereignis impliziert, denn ohne das kann es nicht existieren. Außerdem wollen wir einzelne Produktionsereignisse modellieren können, gegenwärtig sind das nur die Dreharbeiten. Welche Eigenschaften eines Filmwerks können wir angeben, die nicht Teil des Produktionsereignisses sind und die damit allein dem Filmwerk zukommen? Bisher fallen mir dazu nur die Identifikatoren (uid und ExtIDs) ein. Grundsätzlich spräche nichts dagegen, Eigenschaften wie Land, Zeitangabe, Gattung und alle Credits unter einem Produktionsereignis zusammenzufassen, wenn die Vorteile klar sind.''