Jour fixe 2025-11-07 - Versionsgeschichte

Krose: Kackpunkte der Ontologie V0.1 ergänzt

2025-11-07T12:17:22Z

Kackpunkte der Ontologie V0.1 ergänzt

Dbalzer: /* Ontologie-Entwurf für DFF-ZDB */

2025-11-07T08:32:41Z

‎Ontologie-Entwurf für DFF-ZDB

Dbalzer: /* Ontologie-Entwurf für DFF-ZDB */

2025-11-07T08:28:20Z

‎Ontologie-Entwurf für DFF-ZDB

Dbalzer: /* GND Linked Open Data */

2025-11-07T08:23:08Z

‎GND Linked Open Data

Dbalzer: /* Ontologie-Entwurf für DFF-ZDB */

2025-11-06T20:13:16Z

‎Ontologie-Entwurf für DFF-ZDB

Dbalzer: /* Wohin mit filmstandards.org? */

2025-11-06T20:10:39Z

‎Wohin mit filmstandards.org?

Dbalzer: /* Technische Plattform für DFF-Linked Open Data */

2025-11-06T20:06:52Z

‎Technische Plattform für DFF-Linked Open Data

Dbalzer: /* Technische Plattform für DFF-Linked Open Data */

2025-11-06T20:05:58Z

‎Technische Plattform für DFF-Linked Open Data

Dbalzer: /* Ontologie-Entwurf für DFF-ZDB */

2025-11-06T20:03:45Z

‎Ontologie-Entwurf für DFF-ZDB

Dbalzer: /* Literarische Vorlagen und Bühnenstücke */

2025-11-06T19:45:36Z

‎Literarische Vorlagen und Bühnenstücke

← Nächstältere Version		Version vom 7. November 2025, 12:17 Uhr
Zeile 50:		Zeile 50:

	Prinzipiell ließe sich das Property-Axiom auch vereinfachen, indem schlicht <code>rdfs:range dffvoc:Gattung</code> deklariert wird, allerdings würde dann auch die Vokabularklasse <code>dffvoc:Gattung</code> selbst als Aussagewert zugelassen, was als Fehler zu werten wäre (''Filmerk hatGattung "Gattung"'' ergibt keinen Sinn).		Prinzipiell ließe sich das Property-Axiom auch vereinfachen, indem schlicht <code>rdfs:range dffvoc:Gattung</code> deklariert wird, allerdings würde dann auch die Vokabularklasse <code>dffvoc:Gattung</code> selbst als Aussagewert zugelassen, was als Fehler zu werten wäre (''Filmerk hatGattung "Gattung"'' ergibt keinen Sinn).
		+
		+	==== Anmerkungen zum 0.1-Entwurf ====
		+
		+	Bei folgenden Punkten habe ich am meisten hin- und herüberlegt:
		+
		+	'''Produktionsereignis: '''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?
		+
		+	'''Literale Werte: '''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?
		+
		+	'''Orts- und Zeitangaben: '''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 ;-) )
		+
		+	'''Werks-Hierarchien: '''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...

	=== Technische Plattform für DFF-Linked Open Data ===		=== Technische Plattform für DFF-Linked Open Data ===

@@ Zeile 49: / Zeile 49: @@
      (...)</pre>
-Prinzipiell ließe sich das Property-Axiom auch vereinfachen, indem schlicht <code>rdfs:range dffvoc:Gattung</code> deklariert wird, allerdings würde dann auch die Vokabularklasse <code>dffvoc:Gattung</code> selbst als Aussagewert zugelassen, was als Fehler zu werten wäre.
+Prinzipiell ließe sich das Property-Axiom auch vereinfachen, indem schlicht <code>rdfs:range dffvoc:Gattung</code> deklariert wird, allerdings würde dann auch die Vokabularklasse <code>dffvoc:Gattung</code> selbst als Aussagewert zugelassen, was als Fehler zu werten wäre (''Filmerk hatGattung "Gattung"'' ergibt keinen Sinn).
 === Technische Plattform für DFF-Linked Open Data ===

@@ Zeile 17: / Zeile 17: @@
 Vorschlag von Detlev: Trennung in zwei Namensräume, wobei der Vokabular-Namensraum die Einzelvokabulare als Klassen und die Terme als Instanzen der jeweiligen Klasse definiert. Hier ein paar Phantasie-URIs:
-<pre>zdb: <https://filmstandards.org/schemas/zf01/> # Ontologie-Namensraum (Beispiel)
+<pre>zdb: <https://filmstandards.org/schemas/zf01/> # Beispiel für Ontologie-Namensraum
-dffvoc: <https://filmstandards.org/vocabularies/dff01/> # Vokabular-Namenraum (Beispiel)</pre>
+dffvoc: <https://filmstandards.org/vocabularies/dff01/> # Beispiel für Vokabular-Namenraum</pre>
 Im Vokabular-Namensraum hätten wir folgende Definitionen;

@@ Zeile 62: / Zeile 62: @@
 Mit der neuen SPARQL-Schnittstelle zur GND sind jetzt auch die Rück-Verlinkungen von GND zu ZDB bzw. Filmportal maschinell auswertbar. Beispiel: in [https://sparql.dnb.de/1BOuDK?exec=true
-Phil Nylund] der dritte owl:sameAs-Link nach VIAF und Wikidata. Bisher werden diese Links in den GND-Anzeigen von DNB und lobid.org noch nicht sichtbar gemacht.
+Phil Nylund] der dritte owl:sameAs-Link nach VIAF und Wikidata. Bisher werden diese Links nur im GND-Explorer, nicht aber in den GND-Anzeigen von DNB und lobid.org sichtbar gemacht.
 Mit der DNB könnte man vielleicht erörtern, ob das DFF nicht auch die Möglichkeit bekommen sollte, solche Links für Körperschaften und Filmwerke an die GND zu übermitteln.
-Weiteres Verlinkungspotential ZDB zu GND bieten Musikwerke (s.u.) und literarische Vorlagen (s.u.), sowie Filmwerke. Zu Letzteren gibt es über 4000 GND-Datensätze, die über die Werkform als solche zu finden wären. Allerdings unterliegt das Werkform-Vokabular kaum einer Kontrolle, wie diese Abfrage zeigt: [https://sparql.dnb.de/SsrCTH?exec=true] .
+Weiteres Verlinkungspotential ZDB zu GND bieten Musikwerke (s.u.) und literarische Vorlagen (s.u.), sowie Filmwerke. Zu Letzteren gibt es über 4.000 GND-Datensätze, die über die Werkform als solche zu finden wären. Allerdings unterliegt das Werkform-Vokabular kaum einer Kontrolle, wie diese Abfrage zeigt: [https://sparql.dnb.de/SsrCTH?exec=true] .
 === Aktivieren von "verwaisten" Entitäten? ===

@@ Zeile 49: / Zeile 49: @@
      (...)</pre>
-Prinzipiell ließe sich dieses Verfahren auch vereinfachen, indem schlicht <code>rdfs:range dffvoc:Gattung</code> deklariert wird, allerdings würde dann auch die Vokabularklasse <code>dffvoc:Gattung</code> selbst als Aussagewert zugelassen, was als Fehler zu werten wäre.
+Prinzipiell ließe sich das Property-Axiom auch vereinfachen, indem schlicht <code>rdfs:range dffvoc:Gattung</code> deklariert wird, allerdings würde dann auch die Vokabularklasse <code>dffvoc:Gattung</code> selbst als Aussagewert zugelassen, was als Fehler zu werten wäre.
 === Technische Plattform für DFF-Linked Open Data ===

@@ Zeile 7: / Zeile 7: @@
 Die DFF-IT fragt mit Ticket IT-10814 an, ob der "alte Marzipan-Server" stillgelegt werden kann.
-Das geht noch nicht, denn dort liegen noch die Dienste unter filmstandards.org, also dieses Wiki, ein älteres Wiki zu EN 15907 und verschiedene Schemadefinitionen. Außerdem die schon recht alte Website von collate.eu.
+Das geht noch nicht, denn dort liegen bis jetzt die Dienste unter filmstandards.org, also dieses Wiki, ein älteres Wiki zu EN 15907 und verschiedene Schemadefinitionen. Außerdem die schon recht alte Website von collate.eu.
 Den Umzug hatten wir zurückgestellt, weil das Portieren von Mediawiki-Instanzen recht arbeitsaufwändig ist.

@@ Zeile 57: / Zeile 57: @@
 Abzuklären mit der DFF-IT wäre, ob der Triplestore auf einem der vorhandenen Server Unterschlupf finden kann oder besser gleich einen neuen Server bekommen soll. Zur Mengenschätzung: eine lokale Installation der GND (Stand 2018) kam im BaliLabs-Intranet auf unter 200 Mio. Tripel, entsprechend ca. 100 GB Plattenplatz, für Wikidata wurden 2023 etwa 15 Milliarden Tripel angegeben. Für die ZDB wären zunächst noch weniger als 50 Mio. Tripel zu erwarten.
-Nachdem die DNB jetzt (endlich!) einen Triplestore für die GND eingerichtet hat, stellt sich die Frage, ob deren technische Lösung auch für das DFF infrage käme. [https://github.com/ad-freiburg/qlever QLever] ist allerdings bisher ein universitäres Projekt und damit den typischen Unwägbarkeiten bei der Kontinuität ausgesetzt.
+Nachdem die DNB jetzt (endlich!) einen eigenen Triplestore für die GND eingerichtet hat, stellt sich die Frage, ob deren technische Lösung auch für das DFF infrage käme. [https://github.com/ad-freiburg/qlever QLever] ist allerdings bisher ein universitäres Projekt und damit den typischen Unwägbarkeiten bei der Kontinuität ausgesetzt.
 === GND Linked Open Data ===

@@ Zeile 55: / Zeile 55: @@
 Benötigt wird ein RDF-Triplestore mit SPARQL-Schnittstelle und zugehörigen Diensten. Implementierungen gibt es mittlerweile reichlich, auch als Coud-Dienste von AWS, Azure und Oracle. Empfehlung von Detlev: [https://jena.apache.org/documentation/fuseki2/index.html Fuseki] - weil schon in diversen Anwendungs-Umgebungen erprobt, im Rahmen der Apache Software Foundation  fortlaufend gepflegt und mit leicht verständlicher Admin-Oberfläche ausgestattet.
-Abzuklären mit der DFF-IT wäre, ob der Triplestore auf einem der vorhandenen Server Unterschlupf finden kann oder besser gleich einen neuen Server bekommen soll. Zur Mengenschätzung: eine lokale Installation der GND (Stand 2018) kam im BaliLabs-Intranet auf unter 200 Mio. Tripel, entsprechend ca. 100 GB Plattenplatz, Wikidata kam 2023 auf 15 Milliarden Tripel. Für die ZDB wären zunächst noch weniger als 50 Mio. Tripel zu erwarten.
+Abzuklären mit der DFF-IT wäre, ob der Triplestore auf einem der vorhandenen Server Unterschlupf finden kann oder besser gleich einen neuen Server bekommen soll. Zur Mengenschätzung: eine lokale Installation der GND (Stand 2018) kam im BaliLabs-Intranet auf unter 200 Mio. Tripel, entsprechend ca. 100 GB Plattenplatz, für Wikidata wurden 2023 etwa 15 Milliarden Tripel angegeben. Für die ZDB wären zunächst noch weniger als 50 Mio. Tripel zu erwarten.
 Nachdem die DNB jetzt (endlich!) einen Triplestore für die GND eingerichtet hat, stellt sich die Frage, ob deren technische Lösung auch für das DFF infrage käme. [https://github.com/ad-freiburg/qlever QLever] ist allerdings bisher ein universitäres Projekt und damit den typischen Unwägbarkeiten bei der Kontinuität ausgesetzt.

← Nächstältere Version		Version vom 6. November 2025, 19:45 Uhr
Zeile 88:		Zeile 88:

	Wie für Musikwerke ist zu Beginn der ZDB auch eine eigee Entität für Werkvorlagen eingerichtet, aber bisher nur mit einem kleinen Satz Testdaten befüllt worden. Ein Matching-Versuch von Kristina ergab mit diesen Testdaten allerdimgs eine relativ hohe Trefferquote (17 von 28).		Wie für Musikwerke ist zu Beginn der ZDB auch eine eigee Entität für Werkvorlagen eingerichtet, aber bisher nur mit einem kleinen Satz Testdaten befüllt worden. Ein Matching-Versuch von Kristina ergab mit diesen Testdaten allerdimgs eine relativ hohe Trefferquote (17 von 28).
		+
		+	Insgesamt gibt es in der ZDB momentan 7.471 Filmwerke mit einer Relation "hat_Vorlage", die auf den Urheber der Vorlage verweist. In ca. 25-30% der Fälle enthalten diese Relationen einen identifizierbaren Werktitel, in etlichen weiteren Fällen geht der Werktitel aus dem Filmtitel hervor.