DIF Filmographie Wiki - Benutzerbeiträge [de]

Jour fixe 2026-08-28

2026-08-19T08:29:28Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 28. August 2026 ==

=== Eine Handvoll RDF-Themen: ===

==== Gattungen ====
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/&startNode=c00061&lang=de&d=n

==== Geografika ====
Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?

==== Ranges und Domains ====
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.
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.

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
zdb:hatGattung a owl:ObjectProperty ;
rdfs:label "hat Gattung" ;
rdfs:range zdbvoc:term ; # rdfs:Resource?
rdfs:domain zdb:Filmwerk .
Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss?
Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:
zdb:inFunktion a owl:ObjectProperty ;
rdfs:label "in Funktion" ;
rdfs:range zdbvoc:rels ; # changed from zdbvoc:term
rdfs:domain zdb:Beteiligung .
Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?

==== zdbvoc:P1 / zdbvoc:P2 ====
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.

==== Entitäten-URIs ====
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)
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?

==== „Hat …-Typ“-Properties ====
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.

==== Mapping ====
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/

Jour fixe 2026-08-28

2026-08-18T11:30:09Z

Krose:

Jour fixe 2026-08-28

2026-08-17T15:06:33Z

Krose: /* Jour fixe, Freitag, 28. August 2026 */

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 28. August 2026 ==

Eine Handvoll RDF-Themen:

=== Gattungen ===
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/&startNode=c00061&lang=de&d=n

=== Geografika ===
Wollen wir die Geografika-URIs aus pdf.region.Mappings zurückgreifen statt ein eigenes Vokabular zu führen?

=== Ranges und Domains ===
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.
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.

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
zdb:hatGattung a owl:ObjectProperty ;
rdfs:label "hat Gattung" ;
rdfs:range zdbvoc:term ; # rdfs:Resource?
rdfs:domain zdb:Filmwerk .
Damit ist ausgedrückt, dass als Range von zdb:hatGattung eine Instanz aus zdbvoc:term stehen muss?
Bei zdb:inFunktion habe ich noch eine Extra-Nachfrage:
zdb:inFunktion a owl:ObjectProperty ;
rdfs:label "in Funktion" ;
rdfs:range zdbvoc:rels ; # changed from zdbvoc:term
rdfs:domain zdb:Beteiligung .
Eigentlich ist rdfs:range ja aber zdb:Funktion, oder?

=== zdbvoc:P1 / zdbvoc:P2 ===
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.

=== Entitäten-URIs ===
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)
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?

=== „Hat …-Typ“-Properties ===
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.

Jour fixe 2026-08-07

2026-08-12T11:57:03Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 7. August 2026 ==

Themenwüsche bitte hier notieren.

=== Migration filmstandards.org ===

Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?

Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt.

''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''

''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''

=== Linked Data ===

In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)

''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''

Bei mir sehen die IRIs mit Bindestrich in rels_Credits.trig im Syntax-Highlighting von VS Code etwas komisch aus. Machen die Probleme?

''DB: Nee, das liegt nur am Syntax-Highlighter, der ist nicht ganz auf dem aktuellen Stand.''

==== LD-Filmwerke ====

Die Mehrzahl der Vokabulare aus den ZDB-Tabellen "term" und "reldef" sind so weit in RDF verfügbar (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch fehlenden Vokabularen, v.a. aus der Tabelle "region"), dass wir exemplarische RDF-Darstellungen erster Filmwerke "von Hand" konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung

DESCRIBE <https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89>

in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.

In der Ontologie ist "Beteiligung" keine Unterklasse von "Ereignis". Das erscheint praktisch, aber etwas gegen die Intuition. Sollten wir das ändern oder in einer Definition begründen?

''Geklärt: Beteligung und Ereignis bleiben disjunkt.''

=== Tombstones ===

Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum "Gewinner"-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.

Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.

''Vorschlag: separat über die Status-DB tracken, dann muss in filmportal.de nichts geändert werden, kann aber, wenn gewünscht. Im Grunde wäre es eine simple Tabelle mit der GUID des gelöschten Filmwerks bzw. des Verliererdatensatzes beim Zusammenlegen, einer Spalte mit der Gewinner-GUID (falls zutreffend) und einer Spalte mit dem Datum der Änderung. Aus der Status-DB können die Informationen dann in den RDF-Triple-Store geladen werden um die owl:sameAs oder owl:deprecated Info dort zu führen.''

Jour fixe 2026-08-07

2026-08-12T11:55:37Z

Krose:

Migration filmstandards.org

2026-08-10T16:05:39Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Aufgabe ==

Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.

=== vhost: filmstandards.org ===

'''cen/'''
* Veraltetes zum CEN-Standard (2010) -- kann weg '''(Kristina: die PDFs, die dort liegen gerne archivieren)'''

'''demo/'''
* Visulisierungs-Experiment von 2011 -- kann weg

'''difzf/'''
* Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''
** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.

'''dokuwiki/'''
* Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg

'''efg/'''
* Link-Seite von 2009 zum EFG -- kann weg.

'''fiaf/'''
* Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg

'''fsc/'''
* Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren''' '''(Kristina: wofür steht fsc?)'''
** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.

'''img/'''
* Schriften und Logo zu /fsc -- '''portieren''' und in /fsc integrieren

'''installed/'''
* Distribution von mediawiki-1.16.2 -- kann weg

'''localdefs/'''
* Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''

'''media/'''
* Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren

'''midas/'''
* Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?''' '''(Kristina: das Schema kann unter /schemas/ umgezogen werden)'''

'''mmi/'''
* Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?''' '''(Kristina: gerne, ich habe keinen Zugriff, da Login benötigt)'''

'''news/'''
* Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''

'''schemas/'''
* XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''

'''svc/'''
* u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren''' '''(Kristina: was ist das?)'''

'''uploads/'''
* Datenexporte, Distributionen und Konfigurationen zu unterschiedlichen Projekten -- '''archivieren'''

'''vocab/'''
* temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''

=== vhost: collate.eu ===

* Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren''' '''(Kristina: portieren? Die Website brauchen wir nicht mehr, aber die Mediendateien schon, siehe Kommentar unten beim Punkt "Datenbanken")'''
** verwendet Datenbank "collate", eventuell auch Daten aus "horde".

=== vhost: git.dff-film ===

* Altes Git-Repository für ZDB-Programmcode, jetzt auf gitlab.api.dff.film -- '''archivieren'''
** Verwendet Datenbank "gitea".

=== Datenbanken (MariaDB) ===

* apsc - Paketverwaltung -- nicht übertragen
* collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren''' '''(Kristina: bitte die Mediendateien, die dort liegen, portieren, da die Links von EFG und Europeana referenziert werden (http://www.collate.eu/digitizations/03599_faa_art_270929_p1.jpg). Wenn sich die Domain durch den Umzug ändert, können die Links in EFG angepasst werden.)'''
* difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''
* fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''
* gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''
* horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''
* information_schema - MariaDB-Interna -- nicht übertragen
* mysql - MariaDB-Interna -- nicht übertragen
* oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen
* performance_schema - MariaDB-Interna -- nicht übertragen
* phpmyadmin - Datenbank-Werkzeug -- nicht übertragen
* psa - Systemverwaltung für den Server -- nicht übertragen

Migration filmstandards.org

2026-08-10T16:01:27Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Aufgabe ==

Die Domain filmstandards.org liegt derzeit (Mitte 2026) auf einem Server, der 2019 bei Strato angemietet wurde und auf dem auch diverse zuvor schon existierende Projekte versammelt sind. Dieser Bestand soll um nicht mehr relevante Teile bereinigt auf einen neuen Server umziehen.

=== vhost: filmstandards.org ===

'''cen/'''
* Veraltetes zum CEN-Standard (2010) -- kann weg '''(Kristina: die PDFs, die dort liegen gerne archivieren)'''

'''demo/'''
* Visulisierungs-Experiment von 2011 -- kann weg

'''difzf/'''
* Das DFF-Filmografie-Wiki (diese Website) -- '''portieren'''
** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.

'''dokuwiki/'''
* Wiki von 2007 mit Folien zum geplanten CEN-Stadard; nicht mehr funnktionsfähig -- kann weg

'''efg/'''
* Link-Seite von 2009 zum EFG -- kann weg.

'''fiaf/'''
* Wiki der FIAF Cataloguing Commission von 2008 (letzte Änderung 2011) -- kann weg

'''fsc/'''
* Das Wiki zum CEN-Standard mit Workshop-Kompendium etc. -- '''portieren'''
** Portierung getestet mit Ziel PHP 8.3 und MariaDB 10.x erfolgreich.

'''img/'''
* Schriften und Logo zu /fsc -- '''portieren''' und in /fsc integrieren

'''installed/'''
* Distribution von mediawiki-1.16.2 -- kann weg

'''localdefs/'''
* Erster Entwurf eines RDF-Schemas für die ZDB von 2011 -- '''archivieren'''

'''media/'''
* Folien und Video-Clips zum CEN-Kompendium von 2011 -- '''portieren''' und in /fsc integrieren

'''midas/'''
* Verweis-Seite auf MIDAS und XML-Schema vom SRZ Berlin (2008) -- '''archivieren?''' '''(Kristina: das Schema kann unter /schemas/ umgezogen werden)'''

'''mmi/'''
* Updates der Rechtedatenbank mit MS Access-Dateien, Stand 2006 -- '''archivieren?''' '''(Kristina: gerne, ich habe keinen Zugriff, da Login benötigt)'''

'''news/'''
* Kurznachrichten zu CEN-Aktivitäten 2007-2009 -- '''archivieren'''

'''schemas/'''
* XML-Schemadateien unter ihren Namensraum-Pfaden -- '''portieren'''

'''svc/'''
* u.a. Gateway für Exporte aus filmportal-zdb an externe Nutzer -- '''portieren''' '''(Kristina: was ist das?)'''

'''uploads/'''
* Datenexporte, Distributionen und Konfigurationen zu unterschiedlichen Projekten -- '''archivieren'''

'''vocab/'''
* temporärer URI-Resolver für altutelles Linked-Data-Projekt -- '''portieren'''

=== vhost: collate.eu ===

* Verwaiste Website auf Basis von Typo3, etliche temporäre Projektdateien -- '''archivieren''' '''(Kristina: portieren? Die Website brauchen wir nicht mehr, aber die Mediendateien schon, siehe Kommentar unten beim Punkt "Datenbanken")'''
** verwendet Datenbank "collate", eventuell auch Daten aus "horde".

=== vhost: git.dff-film ===

* Altes Git-Repository für ZDB-Programmcode, jetzt auf gitlab.api.dff.film -- '''archivieren'''
** Verwendet Datenbank "gitea".

=== Datenbanken (MariaDB) ===

* apsc - Paketverwaltung -- nicht übertragen
* collate - Type3-CMS-Daten von Projekt Collate -- '''archivieren''' '''(Kristina: bitte die Mediendateien, die dort liegen, portieren, da die Links von EFG und Europeana referenziert werden (http://www.collate.eu/digitizations/03599_faa_art_270929_p1.jpg). Wenn sich die Domain durch den Umzug ändert, können die Links in EFG angepasst werden.)'''
* difwiki - Mediawiki-Daten zum DFF-Filmografie-Wiki -- '''portieren'''
* fscwiki - Mediawiki-Daten zum Basis-Wiki filmstandards.org -- '''portieren'''
* gitea - erstes Git-Repository zur ZDB, abgelöst von Gitlab -- '''archivieren'''
* horde - Installation der Groupware HORDE für Collate, mit einigen Benutzer-Accounts -- '''archivieren'''
* information_schema - MariaDB-Interna -- nicht übertragen
* mysql - MariaDB-Interna -- nicht übertragen
* oai_difzf - alter Datenbestand ZDB-OAI-Dienst, fortgeführt auf oai.dff.film -- nicht übertragen
* performance_schema - MariaDB-Interna -- nicht übertragen
* phpmyadmin - Datenbank-Werkzeug -- nicht übertragen
* psa - Systemverwaltung für den Server -- nicht übertragen

Jour fixe 2026-08-07

2026-08-06T15:21:11Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 7. August 2026 ==

Themenwüsche bitte hier notieren.

=== Migration filmstandards.org ===

Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?

Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt.

''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''

''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''

=== Linked Data ===

In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)

''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''

Bei mir sehen die IRIs mit Bindestrich in rels_Credits.trig im Syntax-Highlighting von VS Code etwas komisch aus. Machen die Probleme?

==== LD-Filmwerke ====

Die Mehrzahl der Vokabulare aus den ZDB-Tabellen "term" und "reldef" sind so weit in RDF verfügbar (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch fehlenden Vokabularen, v.a. aus der Tabelle "region"), dass wir exemplarische RDF-Darstellungen erster Filmwerke "von Hand" konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung

DESCRIBE <https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89>

in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.

=== Tombstones ===

Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum "Gewinner"-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.

Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.

Jour fixe 2026-08-07

2026-08-06T15:20:56Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 7. August 2026 ==

Themenwüsche bitte hier notieren.

=== Migration filmstandards.org ===

Gibt es Neues zur Beschaffung eines neuen Servers? Was muss noch zu den Positionen in der Liste [[Migration_filmstandards.org]] entschieden werden?

Nebenbei: am 24. Juli hat es auf dem jetzigen Server (auf dem auch dieses Wiki liegt) einen Crash gegeben, den wir (Markus / Detlev) am 27. durch Neustart beheben konnten. Das wirft mal wieder die Frage auf, ob und wie weit es eigentlich schon eine ordentliche Backup-Infrastruktur für alles rund um die ZDB gibt.

''Kristina: Können wir uns die Collate.eu-Inhalte nochmal anschauen? Du sagst, das kann archiviert werden, aber auf dem Server liegen auch Digitalisate (z.B. http://www.collate.eu/digitizations/00190_dif_cen_21041932_p1.jpg), die noch auf der Europeana und EFG referenziert werden. Generell planen wir ebenfalls, die Projektbeschreibung umzuziehe, aber für das Hosting der Digitalisate haben wir gerade keine bessere Alternative parat.''

''Kristina: sollen wir das ZDB-Wiki eigentlich mit einem Login versehen?''

=== Linked Data ===

In der aktuellen Version der Vokabular-Definition für die Credits ist die rdfs:range und rdfs:domain analog zur Verlinkung in der ZDB (z.B. zdbvoc:Animations-Kamera rdfs:domain zdb:Filmwerk ; rdfs:range zdb:Person .). In der Ontologie ist das mit zdb:Ereignis und zdb:Beteiligung ja aber anders modelliert - soweit ich das sehe auch noch in der neuen Version 0.4 (siehe Bild hier https://gitlab.api.dff.film/balilabs-coop/ld-svc/-/blob/main/datasets/ontologie/ZDB-Ontologie_V0-1_korrigiert.jpg). Ähnlich ist es beim Vokabular für die Titeltypen. Was hat hier Vorrang - ZDB-Realität oder ZDB-Ontologie? Oder spricht das dafür, doch noch die Properties zdbvoc:range und zdbvoc:domain zu nutzen (zusätzlich oder statt rdfs:range und rdfs:domain)

''DB: Dank für den Hinweis! Ist mir tatsächlich entgangen, dass die rdfs:range-Klasse bei den Credits zdb:Beteiligung sein muss. Das müssen wir ändern. Und domain zdb:Manifestation bei den Titeltypen ist in der Tat auch nicht richtig.''

''Bei mir sehen die IRIs mit Bindestrich in rels_Credits.trig im Syntax-Highlighting von VS Code etwas komisch aus. Machen die Probleme?''

==== LD-Filmwerke ====

Die Mehrzahl der Vokabulare aus den ZDB-Tabellen "term" und "reldef" sind so weit in RDF verfügbar (abgesehen von den ausstehenden domain/range-Änderungen, s.o., und noch fehlenden Vokabularen, v.a. aus der Tabelle "region"), dass wir exemplarische RDF-Darstellungen erster Filmwerke "von Hand" konstruieren können. Ein erster Versuch zur Diskussion ist mit der SPARQL-Anweisung

DESCRIBE <https://www.filmportal.de/4E097896FE814D858788B0FCC0FA3D89>

in https://ws.dff.film/ld-svc/sparql-ui/sparql.html zu bekommen. Die nächste größere Übung wird darin bestehen, Darstellungen für komplexere Filmwerke und schließlich auch für Aggregatwerke zu konstruieren.

=== Tombstones ===

Die wichtigste Frage hierbei ist, was in einem gelöschten Datensatz enthalten sein soll. Naheliegend wäre, einen Link zum "Gewinner"-Datensatz z.B. in filmwerk.Anmerkung zu schreiben. Zusätzlich bräuchte es ein Flag, mit dem dieser Datensatz sowohl ZDB-intern wie auch durch die filmportal-Suchfunktion von den aktiven Datensätzen unterschieden werden kann.

Seitens filmportal.de werden die Anmerkungs-Felder bisher nicht ausgewertet. Das müsste geschehen, damit die Umlenkungen entweder als klickbarer Link oder als Redirect-Anweiseung an den Browser ausgegeben werden können.

Jour fixe 2026-08-07

2026-08-05T15:55:10Z

Krose:

Jour fixe 2026-08-07

2026-08-05T15:38:08Z

Krose:

Jour fixe 2026-07-10

2026-07-10T14:57:49Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 10. Juli 2026 ==

Themenwüsche bitte hier notieren.

=== Doppelte WD-Identifier ===
Ist eine Dokumentation notwendig, wenn Personen mit zwei WD Identifiern zusammen gelegt werden? Bei der GND senden wir gesondert einen GND-Report, welche Nummer der Gewinner ist.
momentan haben wir 8 Personen mit doppelten WD-Identifiern, ich schätze, in der Vergangenheit wurde die WD aus dem Verliererdatensatz gelöscht.

'''Kristina''': wir können die Datensätze auch in Wikidata mergen, wenn es sich um Duplikate (vielleicht sogar durch uns produziert?) handelt: https://www.wikidata.org/wiki/Special:MergeItems

=== Relationenvokabular in RDF ===

==== Umsetzung Entwurf ZDB_V0-1 ====

'''Gruppierungen''': bei direkter Übernahme würden Kollisionen mit der "Notation" auftreten, nach der die Credit-Auswahl bei der Bearbeitung organisisert ist. Die Neugruppierung sollte deshalb erst vorgenommen werden, wenn das RDF-Vokabular in den Bearbeitungszyklus integriert ist.

''Kristina: könntest du das bitte kurz an einem Beispiel erklären? Ich verstehe das gerade noch nicht ganz.''

''DB'': Die vorgeschlagene Gruppe "Mitwirkung" enthält 002 - "Mitwirkung" und 072 - "Interviews", bisher verteilt auf die Gruppen "Darsteller" und "Drehbuch". Für die Neugruppierung wären die Notationen so zu ändern, dass die neue Gruppe sowohl in der Auswahlliste wie auch in der Filmwerks-Darstellung zusammenhängend erscheint.

''Filmportal-Redaktion schaut sich die Notation bei den neuen und geändertern Relatorengruppen an und schickt eine Exceltabelle an Detlev.''

'''Relatoren für URIs''': Bevor wir Relatoren umbenennen, muss erst die Verträglichkeit geprüft werden, und zwar mit
* Credits-Darstellung in filmportal.de und mit
* Anwendungen, die die Datenexporte verwenden (Goethe-Institut, Bundesarchiv, dffb, Filmakademie, VHH, AVefi ...)
''Im XML-Export ändert sich nur etwas, wenn wir auch wirklich die Relatoren ändern. Die Entscheidung, ob wir die Relatoren an sich ändern, hängt noch davon ab wie große Auswirkung dieser Vorgang auf a) die ZDB und b) die Replikation mit filmportal.de hat. Die Änderung an den Relatoren wird mit Werk21 geklärt (s.u.) und auch erstmal nur auf der Ebene des Display-Labels geändert. Es soll ein Upgrade auf Drupal 11 stattfinden und in diesem Zuge ändert sich auch die technische Umsetzung der Credits in Drupal.''

'''Kristina''': an Werk21/kelly haben wir bereits eine Mail geschrieben, wie es mit den Auswirkungen auf filmportal.de aussähe, wenn wir Relatoren (bzw. die Bezeichnungen) ändern würden.

==== Abgleich mit vorhandenen Relationen ====

Für die einzelnen Vokabulare sollte auf jeden Fall geprüft werden, wie die verwendeten Identifikatoren
derzeit in der ZDB-Relationentabelle aussehen. Eine Abfrage für die Agent-Relationen sähe beispielsweise so aus:
SELECT Rel, COUNT(Rel) As Anz FROM relation WHERE
(((SubjEnt="P") AND (ObjEnt="P"))
OR ((SubjEnt="P") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS")))
GROUP BY Rel
und für die Credit-Relationen so:
SELECT Rel, count(Rel) AS Anz FROM relation WHERE
(SubjEnt="FW") AND ((ObjEnt="KS") OR (ObjEnt="P"))
GROUP BY Rel ORDER BY Rel

==== Identifikatoren für URIs ====

Tatsächlich können wir bei den RDF-Darstellungen durchgehend mit [https://www.rfc-editor.org/info/rfc3987/ IRIs] arbeiten, d.h. aufgelöste Umlaute ("Auffuehrung" statt "Aufführung") sind nicht nötig. Im Identifikatoren-Teil müssen nur vorhandene Leerzeichen und einige Interpunktion (/, &, ", ?, : ) vermieden bzw. ersetzt werden.

''Frage:'' Wollen wir es beim derzeitigen Durcheinander belassen, oder eine einheitliche Verwendung von IRIs (also das Beseitigen von "ae", "oe" etc.) anstreben?

DB: Ausnahmen wären zu machen bei den Tabellen-Namen in der ZDB (in der Ontologie als rdfs:Class deklariert), wenn wir eine Mapping-Ebene zwischen RDF und der relationalen Datenbank vermeiden wollen.

''Der Tenor geht zu aufräumen, aber wir müssen abwarten, wie das mit der Änderung von Relatoren funktioniert (s.o.)

=== Grundsatzentscheidungen zu Namensräumen und URIs ===

Die anstehenden Entscheidungen zu LOD-Namensräumen sollen (hoffentlich) für Jahrzehnte Bestand haben. Dazu folgende Überlegungen:

* die Vokabulare bleiben eng mit den Werkzeugen und der Arbeitsweise der Filmwerks-Erfassung verknüpft. Hier sollte die LOD-Darstellung möglichst wenig vom ZDB-Datenmodell abweichen. Die Verwaltung der Vokabulare in RDF gestattet allerdings bessere Möglichkeiten der Anreicherung mit Definitionen, mehrsprachigen Bezeichnern und Mappings zu anderen Vokabularen, als das mit den bisherigen Tabellen "reldef" und "term" der Fall ist.
''Gerne!''

* Die Entitäten können dagegen freier neu definiert und benannt werden, wie im Ontologie-Entwurf von KR bereits vorgeschlagen. Die LOD-Darstellung der Filmwerke muss also keine RDF-Darstellung des XML-Exportschemas sein, sondern kann sich über die historische gewachsenen Definitionen hinweg setzen, solange die Aussagen aus der ZDB semantisch erhalten bleiben.

* Als Basis-Domains für URIs stehen derzeit "filmstandards.org" und "???.dff.film" zur Auswahl. Vorschlag DB: filmstandards.org für Vokabulare und Ontologie (sozusagen als Gemeingut) und irgendetwas wie "ld.dff.film" für die filmografischen Daten (als Produkt des DFF). Denkbar wäre auch etwas wie "vocab.dff.film" für die Vokabulare und die Ontologie. Dies wäre eine strategische Entscheidung, die das DFF treffen muss.
''auch eine Subdomain von filmportal.de kann mit in die Diskussion aufgenommen werden.''

=== Vorläufige RDF-Installation ===

Es sind jetzt einige Vokabulare in den Triplestore übertragen und hier abfragbar: https://ws.dff.film/ld-svc/sparql-ui/sparql.html .

Für URIs der Form http: //filmstandards.org/vocab/dff/ ist jetzt ein Resolver eingerichtet, so dass jeder Aufruf eines URI mit einer RDF/Turtle-Darstellung der Ressource beantwortet wird. Beispiel: [http://filmstandards.org/vocab/dff/credit/Bauten http://filmstandards.org/vocab/dff/credit/Bauten] .

Jour fixe 2026-07-10

2026-07-10T13:45:34Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 10. Juli 2026 ==

Themenwüsche bitte hier notieren.

=== Doppelte WD-Identifier ===
Ist eine Dokumentation notwendig, wenn Personen mit zwei WD Identifiern zusammen gelegt werden? Bei der GND senden wir gesondert einen GND-Report, welche Nummer der Gewinner ist.
momentan haben wir 8 Personen mit doppelten WD-Identifiern, ich schätze, in der Vergangenheit wurde die WD aus dem Verliererdatensatz gelöscht.

'''Kristina''': wir können die Datensätze auch in Wikidata mergen, wenn es sich um Duplikate (vielleicht sogar durch uns produziert?) handelt: https://www.wikidata.org/wiki/Special:MergeItems

=== Relationenvokabular in RDF ===

==== Umsetzung Entwurf ZDB_V0-1 ====

'''Gruppierungen''': bei direkter Übernahme würden Kollisionen mit der "Notation" auftreten, nach der die Credit-Auswahl bei der Bearbeitung organisisert ist. Die Neugruppierung sollte deshalb erst vorgenommen werden, wenn das RDF-Vokabular in den Bearbeitungszyklus integriert ist.

''Kristina: könntest du das bitte kurz an einem Beispiel erklären? Ich verstehe das gerade noch nicht ganz.''

''DB'': Die vorgeschlagene Gruppe "Mitwirkung" enthält 002 - "Mitwirkung" und 072 - "Interviews", bisher verteilt auf die Gruppen "Darsteller" und "Drehbuch". Für die Neugruppierung wären die Notationen so zu ändern, dass die neue Gruppe sowohl in der Auswahlliste wie auch in der Filmwerks-Darstellung zusammenhängend erscheint.

''Filmportal-Redaktion schaut sich die Notation bei den neuen und geändertern Relatorengruppen an und schickt eine Exceltabelle an Detlev.''

'''Relatoren für URIs''': Bevor wir Relatoren umbenennen, muss erst die Verträglichkeit geprüft werden, und zwar mit
* Credits-Darstellung in filmportal.de und mit
* Anwendungen, die die Datenexporte verwenden (Goethe-Institut, Bundesarchiv, dffb, Filmakademie, VHH, AVefi ...)
''Im XML-Export ändert sich nur etwas, wenn wir auch wirklich die Relatoren ändern. Die Entscheidung, ob wir die Relatoren an sich ändern, hängt noch davon ab wie große Auswirkung dieser Vorgang auf a) die ZDB und b) die Replikation mit filmportal.de hat. Die Änderung an den Relatoren wird mit Werk21 geklärt (s.u.) und auch erstmal nur auf der Ebene des Display-Labels geändert. Es soll ein Upgrade auf Drupal 11 stattfinden und in diesem Zuge ändert sich auch die technische Umsetzung der Credits in Drupal.''

'''Kristina''': an Werk21/kelly haben wir bereits eine Mail geschrieben, wie es mit den Auswirkungen auf filmportal.de aussähe, wenn wir Relatoren (bzw. die Bezeichnungen) ändern würden.

==== Abgleich mit vorhandenen Relationen ====

Für die einzelnen Vokabulare sollte auf jeden Fall geprüft werden, wie die verwendeten Identifikatoren
derzeit in der ZDB-Relationentabelle aussehen. Eine Abfrage für die Agent-Relationen sähe beispielsweise so aus:
SELECT Rel, COUNT(Rel) As Anz FROM relation WHERE
(((SubjEnt="P") AND (ObjEnt="P"))
OR ((SubjEnt="P") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS")))
GROUP BY Rel
und für die Credit-Relationen so:
SELECT Rel, count(Rel) AS Anz FROM relation WHERE
(SubjEnt="FW") AND ((ObjEnt="KS") OR (ObjEnt="P"))
GROUP BY Rel ORDER BY Rel

==== Identifikatoren für URIs ====

Tatsächlich können wir bei den RDF-Darstellungen durchgehend mit [https://www.rfc-editor.org/info/rfc3987/ IRIs] arbeiten, d.h. aufgelöste Umlaute ("Auffuehrung" statt "Aufführung") sind nicht nötig. Im Identifikatoren-Teil müssen nur vorhandene Leerzeichen und einige Interpunktion (/, &, ", ?, : ) vermieden bzw. ersetzt werden.

''Frage:'' Wollen wir es beim derzeitigen Durcheinander belassen, oder eine einheitliche Verwendung von IRIs (also das Beseitigen von "ae", "oe" etc.) anstreben?

DB: Ausnahmen wären zu machen bei den Tabellen-Namen in der ZDB (in der Ontologie als rdfs:Class deklariert), wenn wir eine Mapping-Ebene zwischen RDF und der relationalen Datenbank vermeiden wollen.

''Der Tenor geht zu aufräumen, aber wir müssen abwarten, wie das mit der Änderung von Relatoren funktioniert (s.o.)

=== Grundsatzentscheidungen zu Namensräumen und URIs ===

Die anstehenden Entscheidungen zu LOD-Namensräumen sollen (hoffentlich) für Jahrzehnte Bestand haben. Dazu folgende Überlegungen:

* die Vokabulare bleiben eng mit den Werkzeugen und der Arbeitsweise der Filmwerks-Erfassung verknüpft. Hier sollte die LOD-Darstellung möglichst wenig vom ZDB-Datenmodell abweichen. Die Verwaltung der Vokabulare in RDF gestattet allerdings bessere Möglichkeiten der Anreicherung mit Definitionen, mehrsprachigen Bezeichnern und Mappings zu anderen Vokabularen, als das mit den bisherigen Tabellen "reldef" und "term" der Fall ist.

* Die Entitäten können dagegen freier neu definiert und benannt werden, wie im Ontologie-Entwurf von KR bereits vorgeschlagen. Die LOD-Darstellung der Filmwerke muss also keine RDF-Darstellung des XML-Exportschemas sein, sondern kann sich über die historische gewachsenen Definitionen hinweg setzen, solange die Aussagen aus der ZDB semantisch erhalten bleiben.

* Als Basis-Domains für URIs stehen derzeit "filmstandards.org" und "???.dff.film" zur Auswahl. Vorschlag DB: filmstandards.org für Vokabulare und Ontologie (sozusagen als Gemeingut) und irgendetwas wie "ld.dff.film" für die filmografischen Daten (als Produkt des DFF). Denkbar wäre auch etwas wie "vocab.dff.film" für die Vokabulare und die Ontologie. Dies wäre eine strategische Entscheidung, die das DFF treffen muss.

=== Vorläufige RDF-Installation ===

Es sind jetzt einige Vokabulare in den Triplestore übertragen und hier abfragbar: https://ws.dff.film/ld-svc/sparql-ui/sparql.html .

Für URIs der Form http: //filmstandards.org/vocab/dff/ ist jetzt ein Resolver eingerichtet, so dass jeder Aufruf eines URI mit einer RDF/Turtle-Darstellung der Ressource beantwortet wird. Beispiel: [http://filmstandards.org/vocab/dff/credit/Bauten http://filmstandards.org/vocab/dff/credit/Bauten] .

Jour fixe 2026-07-10

2026-07-10T13:41:31Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 10. Juli 2026 ==

Themenwüsche bitte hier notieren.

=== Doppelte WD-Identifier ===
Ist eine Dokumentation notwendig, wenn Personen mit zwei WD Identifiern zusammen gelegt werden? Bei der GND senden wir gesondert einen GND-Report, welche Nummer der Gewinner ist.
momentan haben wir 8 Personen mit doppelten WD-Identifiern, ich schätze, in der Vergangenheit wurde die WD aus dem Verliererdatensatz gelöscht.

'''Kristina''': wir können die Datensätze auch in Wikidata mergen, wenn es sich um Duplikate (vielleicht sogar durch uns produziert?) handelt: https://www.wikidata.org/wiki/Special:MergeItems

=== Relationenvokabular in RDF ===

==== Umsetzung Entwurf ZDB_V0-1 ====

'''Gruppierungen''': bei direkter Übernahme würden Kollisionen mit der "Notation" auftreten, nach der die Credit-Auswahl bei der Bearbeitung organisisert ist. Die Neugruppierung sollte deshalb erst vorgenommen werden, wenn das RDF-Vokabular in den Bearbeitungszyklus integriert ist.

''Kristina: könntest du das bitte kurz an einem Beispiel erklären? Ich verstehe das gerade noch nicht ganz.''

''DB'': Die vorgeschlagene Gruppe "Mitwirkung" enthält 002 - "Mitwirkung" und 072 - "Interviews", bisher verteilt auf die Gruppen "Darsteller" und "Drehbuch". Für die Neugruppierung wären die Notationen so zu ändern, dass die neue Gruppe sowohl in der Auswahlliste wie auch in der Filmwerks-Darstellung zusammenhängend erscheint.

''Filmportal-Redaktion schaut sich die Notation bei den neuen und geändertern Relatorengruppen an und schickt eine Exceltabelle an Detlev.''

'''Relatoren für URIs''': Bevor wir Relatoren umbenennen, muss erst die Verträglichkeit geprüft werden, und zwar mit
* Credits-Darstellung in filmportal.de und mit
* Anwendungen, die die Datenexporte verwenden (Goethe-Institut, Bundesarchiv, dffb, Filmakademie, VHH, AVefi ...)
''Im XML-Export ändert sich nur etwas, wenn wir auch wirklich die Relatoren ändern. Die Entscheidung, ob wir die Relatoren an sich ändern, hängt noch davon ab wie große Auswirkung dieser Vorgang auf a) die ZDB und b) die Replikation mit filmportal.de hat. Die Änderung an den Relatoren wird mit Werk21 geklärt (s.u.) und auch erstmal nur auf der Ebene des Display-Labels geändert. Es soll ein Upgrade auf Drupal 11 stattfinden und in diesem Zuge ändert sich auch die technische Umsetzung der Credits in Drupal.''

'''Kristina''': an Werk21/kelly haben wir bereits eine Mail geschrieben, wie es mit den Auswirkungen auf filmportal.de aussähe, wenn wir Relatoren (bzw. die Bezeichnungen) ändern würden.

==== Abgleich mit vorhandenen Relationen ====

Für die einzelnen Vokabulare sollte auf jeden Fall geprüft werden, wie die verwendeten Identifikatoren
derzeit in der ZDB-Relationentabelle aussehen. Eine Abfrage für die Agent-Relationen sähe beispielsweise so aus:
SELECT Rel, COUNT(Rel) As Anz FROM relation WHERE
(((SubjEnt="P") AND (ObjEnt="P"))
OR ((SubjEnt="P") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS")))
GROUP BY Rel
und für die Credit-Relationen so:
SELECT Rel, count(Rel) AS Anz FROM relation WHERE
(SubjEnt="FW") AND ((ObjEnt="KS") OR (ObjEnt="P"))
GROUP BY Rel ORDER BY Rel

==== Identifikatoren für URIs ====

Tatsächlich können wir bei den RDF-Darstellungen durchgehend mit [https://www.rfc-editor.org/info/rfc3987/ IRIs] arbeiten, d.h. aufgelöste Umlaute ("Auffuehrung" statt "Aufführung") sind nicht nötig. Im Identifikatoren-Teil müssen nur vorhandene Leerzeichen und einige Interpunktion (/, &, ", ?, : ) vermieden bzw. ersetzt werden.

''Frage:'' Wollen wir es beim derzeitigen Durcheinander belassen, oder eine einheitliche Verwendung von IRIs (also das Beseitigen von "ae", "oe" etc.) anstreben?

DB: Ausnahmen wären zu machen bei den Tabellen-Namen in der ZDB (in der Ontologie als rdfs:Class deklariert), wenn wir eine Mapping-Ebene zwischen RDF und der relationalen Datenbank vermeiden wollen.

=== Grundsatzentscheidungen zu Namensräumen und URIs ===

Die anstehenden Entscheidungen zu LOD-Namensräumen sollen (hoffentlich) für Jahrzehnte Bestand haben. Dazu folgende Überlegungen:

* die Vokabulare bleiben eng mit den Werkzeugen und der Arbeitsweise der Filmwerks-Erfassung verknüpft. Hier sollte die LOD-Darstellung möglichst wenig vom ZDB-Datenmodell abweichen. Die Verwaltung der Vokabulare in RDF gestattet allerdings bessere Möglichkeiten der Anreicherung mit Definitionen, mehrsprachigen Bezeichnern und Mappings zu anderen Vokabularen, als das mit den bisherigen Tabellen "reldef" und "term" der Fall ist.

* Die Entitäten können dagegen freier neu definiert und benannt werden, wie im Ontologie-Entwurf von KR bereits vorgeschlagen. Die LOD-Darstellung der Filmwerke muss also keine RDF-Darstellung des XML-Exportschemas sein, sondern kann sich über die historische gewachsenen Definitionen hinweg setzen, solange die Aussagen aus der ZDB semantisch erhalten bleiben.

* Als Basis-Domains für URIs stehen derzeit "filmstandards.org" und "???.dff.film" zur Auswahl. Vorschlag DB: filmstandards.org für Vokabulare und Ontologie (sozusagen als Gemeingut) und irgendetwas wie "ld.dff.film" für die filmografischen Daten (als Produkt des DFF). Denkbar wäre auch etwas wie "vocab.dff.film" für die Vokabulare und die Ontologie. Dies wäre eine strategische Entscheidung, die das DFF treffen muss.

=== Vorläufige RDF-Installation ===

Es sind jetzt einige Vokabulare in den Triplestore übertragen und hier abfragbar: https://ws.dff.film/ld-svc/sparql-ui/sparql.html .

Für URIs der Form http: //filmstandards.org/vocab/dff/ ist jetzt ein Resolver eingerichtet, so dass jeder Aufruf eines URI mit einer RDF/Turtle-Darstellung der Ressource beantwortet wird. Beispiel: [http://filmstandards.org/vocab/dff/credit/Bauten http://filmstandards.org/vocab/dff/credit/Bauten] .

Jour fixe 2026-07-10

2026-07-10T13:35:52Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 10. Juli 2026 ==

Themenwüsche bitte hier notieren.

=== Doppelte WD-Identifier ===
Ist eine Dokumentation notwendig, wenn Personen mit zwei WD Identifiern zusammen gelegt werden? Bei der GND senden wir gesondert einen GND-Report, welche Nummer der Gewinner ist.
momentan haben wir 8 Personen mit doppelten WD-Identifiern, ich schätze, in der Vergangenheit wurde die WD aus dem Verliererdatensatz gelöscht.

'''Kristina''': wir können die Datensätze auch in Wikidata mergen, wenn es sich um Duplikate (vielleicht sogar durch uns produziert?) handelt: https://www.wikidata.org/wiki/Special:MergeItems

=== Relationenvokabular in RDF ===

==== Umsetzung Entwurf ZDB_V0-1 ====

'''Gruppierungen''': bei direkter Übernahme würden Kollisionen mit der "Notation" auftreten, nach der die Credit-Auswahl bei der Bearbeitung organisisert ist. Die Neugruppierung sollte deshalb erst vorgenommen werden, wenn das RDF-Vokabular in den Bearbeitungszyklus integriert ist.

''Kristina: könntest du das bitte kurz an einem Beispiel erklären? Ich verstehe das gerade noch nicht ganz.''

''DB'': Die vorgeschlagene Gruppe "Mitwirkung" enthält 002 - "Mitwirkung" und 072 - "Interviews", bisher verteilt auf die Gruppen "Darsteller" und "Drehbuch". Für die Neugruppierung wären die Notationen so zu ändern, dass die neue Gruppe sowohl in der Auswahlliste wie auch in der Filmwerks-Darstellung zusammenhängend erscheint.

''Filmportal-Redaktion schaut sich die Notation bei den neuen und geändertern Relatorengruppen an und schickt eine Exceltabelle an Detlev.''

'''Relatoren für URIs''': Bevor wir Relatoren umbenennen, muss erst die Verträglichkeit geprüft werden, und zwar mit
* Credits-Darstellung in filmportal.de und mit
* Anwendungen, die die Datenexporte verwenden (Goethe-Institut, Bundesarchiv, dffb, ...)
''Im XML-Export ändert sich nur etwas, wenn wir auch wirklich die Relatoren ändern. Die Entscheidung, ob wir die Relatoren an sich ändern, hängt noch davon ab wie große Auswirkung dieser Vorgang auf a) die ZDB und b) die Replikation mit filmportal.de hat. Die Änderung an den Relatoren wird mit Werk21 geklärt (s.u.) und auch erstmal nur auf der Ebene des Display-Labels geändert. Es soll ein Upgrade auf Drupal 11 stattfinden und in diesem Zuge ändert sich auch die technische Umsetzung der Credits in Drupal.''

'''Kristina''': an Werk21/kelly haben wir bereits eine Mail geschrieben, wie es mit den Auswirkungen auf filmportal.de aussähe, wenn wir Relatoren (bzw. die Bezeichnungen) ändern würden.

==== Abgleich mit vorhandenen Relationen ====

Für die einzelnen Vokabulare sollte auf jeden Fall geprüft werden, wie die verwendeten Identifikatoren
derzeit in der ZDB-Relationentabelle aussehen. Eine Abfrage für die Agent-Relationen sähe beispielsweise so aus:
SELECT Rel, COUNT(Rel) As Anz FROM relation WHERE
(((SubjEnt="P") AND (ObjEnt="P"))
OR ((SubjEnt="P") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS"))
OR ((SubjEnt="KS") AND (ObjEnt="KS")))
GROUP BY Rel
und für die Credit-Relationen so:
SELECT Rel, count(Rel) AS Anz FROM relation WHERE
(SubjEnt="FW") AND ((ObjEnt="KS") OR (ObjEnt="P"))
GROUP BY Rel ORDER BY Rel

==== Identifikatoren für URIs ====

Tatsächlich können wir bei den RDF-Darstellungen durchgehend mit [https://www.rfc-editor.org/info/rfc3987/ IRIs] arbeiten, d.h. aufgelöste Umlaute ("Auffuehrung" statt "Aufführung") sind nicht nötig. Im Identifikatoren-Teil müssen nur vorhandene Leerzeichen und einige Interpunktion (/, &, ", ?, : ) vermieden bzw. ersetzt werden.

''Frage:'' Wollen wir es beim derzeitigen Durcheinander belassen, oder eine einheitliche Verwendung von IRIs (also das Beseitigen von "ae", "oe" etc.) anstreben?

DB: Ausnahmen wären zu machen bei den Tabellen-Namen in der ZDB (in der Ontologie als rdfs:Class deklariert), wenn wir eine Mapping-Ebene zwischen RDF und der relationalen Datenbank vermeiden wollen.

=== Grundsatzentscheidungen zu Namensräumen und URIs ===

Die anstehenden Entscheidungen zu LOD-Namensräumen sollen (hoffentlich) für Jahrzehnte Bestand haben. Dazu folgende Überlegungen:

* die Vokabulare bleiben eng mit den Werkzeugen und der Arbeitsweise der Filmwerks-Erfassung verknüpft. Hier sollte die LOD-Darstellung möglichst wenig vom ZDB-Datenmodell abweichen. Die Verwaltung der Vokabulare in RDF gestattet allerdings bessere Möglichkeiten der Anreicherung mit Definitionen, mehrsprachigen Bezeichnern und Mappings zu anderen Vokabularen, als das mit den bisherigen Tabellen "reldef" und "term" der Fall ist.

* Die Entitäten können dagegen freier neu definiert und benannt werden, wie im Ontologie-Entwurf von KR bereits vorgeschlagen. Die LOD-Darstellung der Filmwerke muss also keine RDF-Darstellung des XML-Exportschemas sein, sondern kann sich über die historische gewachsenen Definitionen hinweg setzen, solange die Aussagen aus der ZDB semantisch erhalten bleiben.

* Als Basis-Domains für URIs stehen derzeit "filmstandards.org" und "???.dff.film" zur Auswahl. Vorschlag DB: filmstandards.org für Vokabulare und Ontologie (sozusagen als Gemeingut) und irgendetwas wie "ld.dff.film" für die filmografischen Daten (als Produkt des DFF). Denkbar wäre auch etwas wie "vocab.dff.film" für die Vokabulare und die Ontologie. Dies wäre eine strategische Entscheidung, die das DFF treffen muss.

=== Vorläufige RDF-Installation ===

Es sind jetzt einige Vokabulare in den Triplestore übertragen und hier abfragbar: https://ws.dff.film/ld-svc/sparql-ui/sparql.html .

Für URIs der Form http: //filmstandards.org/vocab/dff/ ist jetzt ein Resolver eingerichtet, so dass jeder Aufruf eines URI mit einer RDF/Turtle-Darstellung der Ressource beantwortet wird. Beispiel: [http://filmstandards.org/vocab/dff/credit/Bauten http://filmstandards.org/vocab/dff/credit/Bauten] .

Jour fixe 2026-07-10

2026-07-08T10:04:29Z

Krose:

Jour fixe 2026-07-10

2026-07-07T14:17:09Z

Krose:

Jour fixe 2026-07-10

2026-07-07T14:04:28Z

Krose:

Jour fixe 2026-04-10

2026-04-10T14:55:59Z

Krose: /* Tombstones / Deprecation */

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 10. April 2026 ==

=== Server-Umzug filmstandards.org ===

Die Wikis konnten testweise im BaliLabs-Intranet in eine aktuelle Software-Umgebung migriert werden. Bedeutender Aufwand bei Migration auf einen neuen DFF-Server ist damit nicht zu erwarten.

=== Elementvokabulare ===

Kristinas Fragen hierzu finden sich auf der Seite [[Elementvokabulare]] unter 2 - Diskussion, zusammen mit Anmerkungen von DB.

Der SPARQL-Zugang via https ist durch ein automatisches Update auf dem Server verlorengegangen. Das macht nichts, denn wir können künftig auf eine eigene Schnittstelle zurückgreifen, die ich (DB) ursprünglich mal für die LIDO-Terminologie entwickelt habe. Die lässt sich, wie lokale Tests zeigen, gut fürs DFF adaptieren.

=== Syntaktisch falsche Ordnungsdatum-Angaben ===

Die automatische Korrektur muss für jedes Aggregatwerk eigens konfiguriert werden. Deshalb sind bisher erst ca. 7.000 der ursprünglich ca. 16.000 Fälle bearbeitet.

Zu klären ist noch die Frage, wie künftig mit angekündigten, aber noch nicht erschienenen Filmwerken verfahren werden soll. Also denen, die bisher Ordnungsdatierungen wie JJJJ-00-13 oder JJJJ-13-00 haben.

BS: die JJJJ-13-00 können gerne eliminiert werden - ich habe eine Sicherheitskopie bereits gezogen zur WV, ob und wann eine UA stattgefunden hat.

Die JJJJ-00-13 sollten sehr unwahrscheinlich sein :)

=== Bugfixes ===

Die Auswahlliste bei der Filmtitel-Suche endete manchmal abrupt. Grund waren "verwaiste" Filmtitel-Eintrage (Reste von unvollständigen Löschvorgängen). Diese werden jetzt abgefangen; eine Liste der verwaisten Einträge (ca. 90) kann generiert werden.

In der Änderungsprotokoll-Ansicht gabe es häufig Mehrfacheinträge, wenn an einer Entität mehrere Änderungen an einem Tag vorgenommen wurden. Das ist jetzt behoben.

=== Tombstones / Deprecation ===

(Kristina) Bisher werden Datensätze, die gelöscht werden, ja komplett entfernt und der Link führt nur zur Info, dass der Datensatz nicht existiert. Wäre es mit Blick auf die Schnittstelle (und eigentlich auch filmportal.de) nicht besser, eine Art Tombstone-Datensatz zu haben, der die Info gibt, wann der Datensatz gelöscht wurde oder sogar eine Weiterleitung, wenn Datensätze zusammengelegt wurden (im Fall von Dubletten)?

* Datensätze zusammenlegen geht nur bei Personen und Körperschaften; bei Filmwerken ist es zu kompliziert
* Ein Tombstone-Datensatz könnte das Löschdatum und ggf. die UID des "Gewinners" beinhalten, sofern ein Datensatz mit einem anderen zusammengelegt wurde. Bei einem gelöschten Filmwerk könnte man diese UID im Tombstone-Datensatz händisch eintragen.
* Auf filmportal.de könnten diese Tombstone-Informationen dann ebenfalls anstelle des "Seite existiert nicht" angezeigt werden bzw. direkt eine Weiterleitung erfolgen.
* Ggf. ließe sich hieraus auch eine Abfrage oder automatisierte Weitergabe der Lösch-Infos an die DNB generieren
* Für andere Entitäten (Manifestationen, Titel, Aufführungen) wären diese Tombstones nur für die RDF-Schnittstelle nützlich, da diese auf filmportal.de nicht als eigene Seiten aufrufbar sind; ebenso im ZDB-Frontend.

=== Werkvorlage und Musikwerk ===

(Kristina) Wir hatten das Thema schon relativ abgeschlossen, aber ich würde gerne noch einmal zur Debatte stellen, ob es sich fur jeweils ca. 30 Datensätze dieser beiden Entitäten lohnt, diese weiter mitzuführen. Ich hatte es nicht so verstanden, dass in Zukunft wieder aktiv Werksvorlagen und Musikwerke als eigene Entitäten erfasst werden und habe ich gefragt, was dann der Mehrwert ist.

*Wir schauen bis zum nächsten Jour Fixe nochmal rein, welche und wieviele Verknüpfungen das betrifft, aber der Tenor geht in Richtung "rausschmeißen und Informationen archivieren".

*BS: es betrifft 27 MW und 29 WV-Verknüpfungen. Mir liegt eine abfrage vor, die die Filmwerke auch nennt.

Jour fixe 2026-04-10

2026-04-10T14:02:05Z

Krose: /* Werkvorlage und Musikwerk */

Jour fixe 2026-04-10

2026-04-09T15:00:35Z

Krose:

Elementvokabulare

2026-04-09T14:51:16Z

Krose:

Eine Seite aus dem [[Reformhaus]]

== Plan ==

=== Anforderungen ===

Warum soll hier etwas geändert werden?

Vokabulare stellen für jedes normierte Datenelement im ZDB-Datenmodell die dafür definierten Aussagemöglichkeiten bereit. Diese Funktion ist derzeit mit den Tabellen "term" und "reldef" 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.

=== Ziel ===

Die Vokabulare der DFF-ZDB sollen zukünftig folgende Empfehlungen möglichst vollständig umsetzen:

* 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].

* alle Anforderungen von [https://5stardata.info/en/ 5-Star Linked Open Data] für den externen Zugang.

* 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].

* Ein URI-Schema zur Adressierung der Einzelvokabulare und der für jedes Vokabular bereitgestellten Metadaten.

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 ===

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.

=== Restriktionen ===

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

zdbvoc:Range_Person a skos:Collection ;
member voccredit:Adaption ;
member voccredit:Drehbuch ;
...

Statt skos:Collection könnte hier auch isothes:ConceptGroup verwendet werden, um den Unterschied zur Gruppierung nach Gewerk augenfällig zu machen.

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:

voccredit:Drehbuch a skos:Concept ;
zdbvoc:domain zdb:Filmwerk ;
zdbvoc:range zdb:Person ;
...

Dies würde bei Abfragen das Auswerten der Umkehrbeziehung von skos:member ersparen und insgesamt wohl auch einfacher zu pflegen sein.

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

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 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)

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:

voccredit:Animation
a skos:Concept ;
zdbvoc:P1 "unter Namen" ;
zdbvoc:P2 "Detail" ;
...

=== Der RDF-Graph ===

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.

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.

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. 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?
** 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: Ich meinte das auch nicht auf die Credits bezogen, sondern auf andere Vokabulargruppen wie die Aufführungsarten oder die Titel; z.B. "Voraufführung" isA "Aufführung" (also "Voraufführung" als narrower Term von "Aufführung" oder "Uraufführung" isA "Erstaufführung" oder "Titelübersetzung" isA "Weiterer Titel"

* 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?
** 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.

* 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?
** 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.

* KR: Warum zdbvoc:domain und zdbvoc:range anstelle von rdfs:range und rdfs:domain? Weil das mit der Definition von SKOS clasht?
** DB: Grundsätzlich spricht nichts gegen rdfs:range/domain. Vielleicht ist das sogar besser, weil es eine lokale Deklaration erspart.

Jour fixe 2026-01-09

2025-12-17T14:53:31Z

Krose: Die Seite wurde neu angelegt: „Eine Seite aus dem Reformhaus == Jour fixe, Freitag, 9. Januar 2026 == === Änderungen im Relationen-Vokabular === In den letzten Monaten wurden eine R…“

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 9. Januar 2026 ==

=== Änderungen im Relationen-Vokabular ===

In den letzten Monaten wurden eine Reihe von Relatoren in der ZDB (pdf.reldef und pdf.reldef_en) vom DFF-Team diskutiert (Bezeichnung des Relators, Gruppenzuordnung und englische Übersetzung). Ziel war es vor allem, ungegenderte Begriffe zu finden (also weg von "Darsteller"), aber es wurden in diesem Zuge auch ein paar weitere Änderungen vorgenommen. Die Übersicht wird noch per Mail verschickt.

Folgende Fragen zu technisches Abhängigkeiten haben sich ergeben:

• Wenn wir einen Relator in der ZDB umbenennen, wie ist dafür der Ablauf? Welche Folgen hat das innerhalb der ZDB? Aktualisieren sich alle betroffenen Einträge in der pdf.Relation automatisch oder muss das dort ebenfalls per Korrektur geändert werden?

• Wenn wir die Übersetzung eines Relators ändern, welche Folgen hat das innerhalb der ZDB? Gar keine, weil sie nicht ausgegeben werden?

• Wenn wir einem Relator eine neue Gruppe zuweisen, welche Folgen hat das innerhalb der ZDB? Gar keine, weil sie nicht ausgegeben werden?

• Welche Änderungsbedarfe bestehen noch an den Eintragungen in der Spalte „Notation“ in pdf.reldef

• Was bedeutet die Änderung für die Nutzer*innen der OAI-Schnittstelle und des Webservice?

• Was bedeuten Umbenennungen in den Person -> Person Relatoren für die GND-Schnittstelle? Verarbeitet die GND diese Informationen und geben wir sie überhaupt mit raus? Wo ist ein Beispiel für einen Datensatz mit Relationen im Austauschformat?

• Haben wir aktuelle Schemata, die wir aktualisieren müssten? [filmstandards.org/schemas/de-dif/zf-fw-view-1.5/] (Struktur ändert sich wahrscheinlich nicht, aber die Werte in den Elementen.)

Bereinigung des Datenschemas

2025-12-17T14:52:55Z

Krose:

Seit der Definition des Datenbankschemas für die Zentrale Filmografie (ZDB) sind in der Praxis etliche der ursprünglichen Annahmen obsolet geworden.

==Zugelassene Relationen==

Als Ausgangspunkt erstellen wir eine Übersicht über die in der Tabelle "relation" vorhandenen Verknüpfungen:

SELECT relation.SubjEnt, ent1.Tabname, relation.ObjEnt, ent2.Tabname, COUNT(*) AS AnzRel
FROM pdf.relation
JOIN entities AS ent1 ON ent1.ID=relation.SubjEnt
JOIN entities AS ent2 ON ent2.ID=relation.ObjEnt
GROUP BY relation.SubjEnt, relation.ObjEnt

Eine aktuelle Übersicht findet sich hier: [https://zdb.dff.film/fdb/relationStatus.php]

In den letzten Monaten wurden eine Reihe von Relatoren in der ZDB vom DFF-Team bearbeitet (Bezeichnung des Relators, Gruppenzuordnung und englische Übersetzung). Ziel war es vor allem, ungegenderte Begriffe zu finden (also weg von "Darsteller"), aber es wurden in diesem Zuge auch ein paar weitere Änderungen vorgenommen. Die Übersicht wird per Mail verschickt.
In Zahlen:

'''Umbenennung von Relatoren: '''40

'''Übersetzungsänderung bei Relatoren: '''31 (Sechs Begriffe stehen noch aus)

'''Löschen von Relatoren: '''1 (Falls ganze Entitäten wie “TD” gelöscht werden, fallen noch mehr Relatoren weg)

'''Neuzuweisung Relator -> Relatorgruppe:''' 26

'''Neue Relatorengruppen: '''4

'''Umbenennung von Relatorengruppen: '''4

'''Löschen Relatorengruppe: '''1

==Betroffene Entitäten==

===Plakat===
Metadaten zu Filmplakaten werden, anders als im ersten Schema-Entwurf angelegt, über das Filmportal-CMS verwaltet. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 02-Jun-2023: Alle Instanzen von Entität PL (Plakat) und Relationen FM<->PL gelöscht (s.o.); Tabelle "plakat" und Programmcode zur Anzeige von Plakat-Metadaten aus ZDB entfernt.

Plakat-Metadatensätze des DFF haben derzeit (noch) keine persistenten Identifikatoren. Eine verlässliche Verlinkung von der ZDB zur Darstellung in Filmportal oder DDB ist derzeit nicht möglich.

===Foto===
''Status:'' '''Erledigt'''

Metadaten zu Fotos werden, anders als im ersten Schema-Entwurf definiert, über das Filmportal-CMS verwaltet. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 03-Jun-2023: Alle Instanzen von Entität FO (Foto) und Relationen FO<->P sowie FW<->FO gelöscht (s.o.). Tabelle "plakat" entfernt.
* 06-Jun-2023: Programmcode mit Bezug zu Foto-Metadaten in ZDB entfernt.

===Genre===
''Status:'' '''Erledigt'''

Genre-Angaben zu Filmwerken sind im ersten Schema-Entwurf definiert, konnten aber mangels Datengrundlage nicht genutzt werden. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 03-Jun-2023: Alle Instanzen von Entität GE (Genre) und Relationen mit GE, sowie Tabelle "genre" entfernt.
* 06-Jun-2023: Programmcode mit Bezug zu Genre-Angaben in ZDB entfernt.

===Gruppe===

''Status:'' '''Erledigt'''

Die Entität "Gruppe" war aus der Vorgänger-Datenbank am DIF in die ZDB übernommen worden. Für filmportal.de war keine Entsprechung hierzu geplant. Daher werden seither alle neuen Personengruppen in der Entität "Körperschaft erfasst". Zur Bereinigung des ZDB-Datenbestandes werden die noch vorhandenen Daten aus der Entität "Gruppe" in "Körperschaft" überführt und die Entität wie auch der zugehörige Programmcode aus der ZDB entfernt.

* 07-Jun-2023: 340 Gruppen-Datensätze waren nicht über Relationen verknüpft und wurden automatisiert gelöscht.

* 22-Mrz-2024: die verbliebenen ca. 300 Gruppen-Datensätze sind zu 2/3 in Körperschaften überführt.

'''2do''': Alle verbliebenen Instanzen der Entität Gruppe sollen in Körperschaften gewandelt werden.

===Musikwerk und Werkvorlage===
Wäre es hier nicht eine Idee, die wenigen Einträge, die wir haben (jeweils nur 28?) durch einen Link zur GND zu ersetzen und auch zukünftig eher direkt dorthin zu verlinken?
Gleiches wäre auch für die Relation FW->P "hat Vorlage" denkbar, nur dass diese natürlich weitaus öfter verwendet wurde.

===Surrogat===
Sind das einfach filmportal-Biografien, die repliziert wurden/werden?

Reformhaus

2025-12-17T14:46:55Z

Krose: Agenda für JF am 9.1.26 angelegt

Fortlaufende Aktivitäten zur Anpassung und Weiterentwicklung der Filmografie-Datenbank und zugehöriger Datendienste des DFF

'''Telekonferenzen zu anstehenden Themen'''

* [[Jour fixe 2025-02-07]] - Diskussionspunkte zur Prioritäten-Findung
* [[Jour fixe 2025-03-07]] - Diskussionspunkte
* [[Jour fixe 2025-04-04]] - Diskussionspunkte
* [[Jour fixe 2025-05-09]] - Diskussionspunkte
* [[Jour fixe 2025-06-13]] - Diskussionspunkte
* [[Jour fixe 2025-07-11]] - Diskussionspunkte
* [[Jour fixe 2025-09-05]] - Diskussionspunkte
* ''[[Jour fixe 2025-10-10]]'' - vertagt
* [[Jour fixe 2025-11-07]] - Diskussionspunkte
* [[Jour fixe 2025-12-05]] - Diskussionspunkte
* [[Jour fixe 2026-01-09]] - Diskussionspunkte

'''Laufendes'''

* [[Ergänzung des Datenschemas]] - Neue Relatoren

* [[Bereinigung des Datenschemas]] - Entfernen nicht (mehr) benötigter Entitäten und Relationen; Änderungen an Eigenschaften und Datentypen

* [[Erweiterungswünsche]] für die ZDB-Bearbeitung

Bereinigung des Datenschemas

2025-12-17T14:43:00Z

Krose: Ergänzungen zur Arbeit am Relationen-Vokabular

Seit der Definition des Datenbankschemas für die Zentrale Filmografie (ZDB) sind in der Praxis etliche der ursprünglichen Annahmen obsolet geworden.

==Zugelassene Relationen==

Als Ausgangspunkt erstellen wir eine Übersicht über die in der Tabelle "relation" vorhandenen Verknüpfungen:

SELECT relation.SubjEnt, ent1.Tabname, relation.ObjEnt, ent2.Tabname, COUNT(*) AS AnzRel
FROM pdf.relation
JOIN entities AS ent1 ON ent1.ID=relation.SubjEnt
JOIN entities AS ent2 ON ent2.ID=relation.ObjEnt
GROUP BY relation.SubjEnt, relation.ObjEnt

Eine aktuelle Übersicht findet sich hier: [https://zdb.dff.film/fdb/relationStatus.php]

In den letzten Monaten wurden eine Reihe von Relatoren in der ZDB vom DFF-Team bearbeitet (Bezeichnung des Relators, Gruppenzuordnung und englische Übersetzung). Ziel war es vor allem, ungegenderte Begriffe zu finden (also weg von "Darsteller"), aber es wurden in diesem Zuge auch ein paar weitere Änderungen vorgenommen. Die Übersicht wird per Mail verschickt.
In Zahlen:
'''Umbenennung von Relatoren: '''40
'''Übersetzungsänderung bei Relatoren: '''31 (Sechs Begriffe stehen noch aus)
'''Löschen von Relatoren: '''1 (Falls ganze Entitäten wie “TD” gelöscht werden, fallen noch mehr Relatoren weg)
'''Neuzuweisung Relator -> Relatorgruppe:''' 26
'''Neue Relatorengruppen: '''4
'''Umbenennung von Relatorengruppen: '''4
'''Löschen Relatorengruppe: '''1

==Betroffene Entitäten==

===Plakat===
Metadaten zu Filmplakaten werden, anders als im ersten Schema-Entwurf angelegt, über das Filmportal-CMS verwaltet. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 02-Jun-2023: Alle Instanzen von Entität PL (Plakat) und Relationen FM<->PL gelöscht (s.o.); Tabelle "plakat" und Programmcode zur Anzeige von Plakat-Metadaten aus ZDB entfernt.

Plakat-Metadatensätze des DFF haben derzeit (noch) keine persistenten Identifikatoren. Eine verlässliche Verlinkung von der ZDB zur Darstellung in Filmportal oder DDB ist derzeit nicht möglich.

===Foto===
''Status:'' '''Erledigt'''

Metadaten zu Fotos werden, anders als im ersten Schema-Entwurf definiert, über das Filmportal-CMS verwaltet. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 03-Jun-2023: Alle Instanzen von Entität FO (Foto) und Relationen FO<->P sowie FW<->FO gelöscht (s.o.). Tabelle "plakat" entfernt.
* 06-Jun-2023: Programmcode mit Bezug zu Foto-Metadaten in ZDB entfernt.

===Genre===
''Status:'' '''Erledigt'''

Genre-Angaben zu Filmwerken sind im ersten Schema-Entwurf definiert, konnten aber mangels Datengrundlage nicht genutzt werden. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 03-Jun-2023: Alle Instanzen von Entität GE (Genre) und Relationen mit GE, sowie Tabelle "genre" entfernt.
* 06-Jun-2023: Programmcode mit Bezug zu Genre-Angaben in ZDB entfernt.

===Gruppe===

''Status:'' '''Erledigt'''

Die Entität "Gruppe" war aus der Vorgänger-Datenbank am DIF in die ZDB übernommen worden. Für filmportal.de war keine Entsprechung hierzu geplant. Daher werden seither alle neuen Personengruppen in der Entität "Körperschaft erfasst". Zur Bereinigung des ZDB-Datenbestandes werden die noch vorhandenen Daten aus der Entität "Gruppe" in "Körperschaft" überführt und die Entität wie auch der zugehörige Programmcode aus der ZDB entfernt.

* 07-Jun-2023: 340 Gruppen-Datensätze waren nicht über Relationen verknüpft und wurden automatisiert gelöscht.

* 22-Mrz-2024: die verbliebenen ca. 300 Gruppen-Datensätze sind zu 2/3 in Körperschaften überführt.

'''2do''': Alle verbliebenen Instanzen der Entität Gruppe sollen in Körperschaften gewandelt werden.

===Musikwerk und Werkvorlage===
Wäre es hier nicht eine Idee, die wenigen Einträge, die wir haben (jeweils nur 28?) durch einen Link zur GND zu ersetzen und auch zukünftig eher direkt dorthin zu verlinken?
Gleiches wäre auch für die Relation FW->P "hat Vorlage" denkbar, nur dass diese natürlich weitaus öfter verwendet wurde.

===Surrogat===
Sind das einfach filmportal-Biografien, die repliziert wurden/werden?

Ergänzung des Datenschemas

2025-12-17T14:12:02Z

Krose:

Eine Seite aus dem [[Reformhaus]]
== Relatoren aus Wikidata ==

Wikidata arbeitet offenbar nicht mit impliziten Umkehrbeziehungen. Eine Aussage wie "hat Eigentümer" muss auf der Eigentümerseite mit einer separaten Aussage "ist Eigentümer von" vervollständigt werden. Das wird oft nicht richig gehandhabt. Außerdem gibt es keine Restriktionen für Domain und Range, was oft zu beliebig ausgewählten Properties führt.

=== Relation Körperschaft zu Körperschaft ===

Diese Abfrage über den [https://query.wikidata.org/ Wikidata SPARQL-Dienst] listet die derzeit verwendeten Properties zwischen Items des Typs "Filmproduktionsgesellschaft" (Q1762059) auf:

SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE
{
?s wdt:P31 wd:Q1762059 .
?o wdt:P31 wd:Q1762059 .
?s ?prop ?o .
?propertyItem wikibase:directClaim ?prop
SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}
GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)

Siehe auch dieser Abgleich mit der GND-Ontologie im Protokoll vom [https://filmstandards.org/difzf/index.php?title=Jour_fixe_2025-07-11 11. Juli 2025].

=== Relation Körperschaft zu Person ===

Diese Abfrage über den [https://query.wikidata.org/ Wikidata SPARQL-Dienst] listet die derzeit verwendeten Properties mit Subjekt "Filmproduktionsgesellschaft" (Q1762059) und Objekt "Mensch" (Q5) auf:

SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE
{
?s wdt:P31 wd:Q1762059 . # film production company
?o wdt:P31 wd:Q5 . # human
?s ?prop ?o .
?propertyItem wikibase:directClaim ?prop
SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}
GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)

Und hier noch die Umkehrbeziehung (Subjekt) Mensch zu (Objekt) Filmproduktionsgesellschaft:

SELECT DISTINCT (COUNT(?prop) AS ?Anz) ?prop ?propertyItemLabel WHERE
{
?s wdt:P31 wd:Q5 . # human
?o wdt:P31 wd:Q1762059 . # film production company
?s ?prop ?o .
?propertyItem wikibase:directClaim ?prop
SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}
GROUP BY ?prop ?propertyItemLabel ORDER BY DESC(?Anz)

Wir sehen, dass bei fehlender Kontrolle der Umkehrbeziehungen allerhand Unsinn entsteht. Beispiel: [https://www.wikidata.org/wiki/Q116870917 Steven Af], Tologolesischer Filmproduzent, [https://www.wikidata.org/wiki/Property:P127 ist Eigentum von] (P127) der Produktionsfirma [https://www.wikidata.org/wiki/Q118724830 Sunlight Group]. Praktiziert diese Firma noch Sklavenhaltung?

Weitere Menschen, die Eigentum einer Filmproduktionsfirma sind:

SELECT DISTINCT ?pname ?kname WHERE
{
?s wdt:P31 wd:Q5 ; # human
rdfs:label ?pname .
?o wdt:P31 wd:Q1762059 ; # film production company
rdfs:label ?kname .
?s wdt:P127 ?o . # owned by
FILTER(LANG(?pname)="en") . FILTER(LANG(?kname)="en")
}

Jour fixe 2025-11-07

2025-11-07T12:17:22Z

Krose: Kackpunkte der Ontologie V0.1 ergänzt

Eine Seite aus dem [[Reformhaus]]

== Jour fixe, Freitag, 7. November 2025 ==

=== Wohin mit filmstandards.org? ===

Die DFF-IT fragt mit Ticket IT-10814 an, ob der "alte Marzipan-Server" stillgelegt werden kann.

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.

=== Ontologie-Entwurf für DFF-ZDB ===

Kristina hat einen ersten Entwurf für eine Ontologie zur Darstellung der ZDB als RDF-Graph vorgelegt. Hiervon ausgehend wäre zu erörtern, wie die Trennung von (langfristig stabilen) Ontologie-Klassen und Properties auf der einen Seite, und den auch kurzfristig änderbaren Wertevokabularen (im Wesentlichen die bisherige "Term"-Tabelle) am besten zu bewerkstelligen ist.

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/> # Beispiel für Ontologie-Namensraum
dffvoc: <https://filmstandards.org/vocabularies/dff01/> # Beispiel für Vokabular-Namenraum</pre>

Im Vokabular-Namensraum hätten wir folgende Definitionen;

<pre>dffvoc:Gattung a rdfs:Class ;
rdfs:label "Gattung"@de ;
rdfs:comment "Gesamtheit des Gattungs-Vokabulars"@de .

dffvoc:Kurzspielfilm a dffvoc:Gattung ;
rdfs:label "Kurz-Spielfilm"@de .</pre>

und im Ontologie-Namensraum folgendes Property-Axiom:

<pre>zdb:hatGattung a owl:ObjectProperty ;
rdfs:domain zdb:Filmwerk ;
rdfs:range [
a owl:Restriction ;
owl:onProperty zdb:hatGattung ;
owl:allValuesFrom dffvoc:Gattung
] .
</pre>

Damit ist "Kurz-Spielfilm" eine Instanz von "Gattung" und als solche ein zulässiger Wert für die Aussage "hatGattung":

<pre><https://filmportal.de/869C2D2B4E1E472389E4D7E8E9F474C8> a zdb:Filmwerk ;
owl:sameAs <http://www.wikidata.org/entity/Q106718783> ;
zdb:hatProduktionsjahr "2010/2011" ;
zdb:hatProduktionsland "DE" ;
zdb:hatGattung dffvoc:Kurzspielfilm ;
(...)</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 (''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 ===

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, 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 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 ===

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 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 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? ===

==== Musikwerk ====

Diese Entität war schon in der Vorgänger-Datenbank zur ZDB einmal angelegt worden. Ins ZDB-Datenmodell wurde die Entität Musikwerk übernommen und mit vorhandenen Daten aus der Vorgängerdatenbank befüllt. Bisher gibt es aber in der ZDB noch keine Möglichkeiten zur Bearbeitung und Verknüpfung von Musikwerken.

Nach Übernahme in die ZDB war ein kurzer Anlauf unternommen worden, die erfassten Musikwerke mit externen Identifikatoren der Verwertungsgesellschaften GEMA und BMI anzureichern. Viele der Werke wurden auch in den Werkkatalogen von ASCAP (USA) und SACEM (Frankreich) gefunden, aber seinerzeit mangels verlässlicher Identifikatoren nicht aufgenommen. Kristina hat jetzt die Überschneidung mit der GND untersucht und ist hier auch fündig geworden.

Um filmisch genutzte Musikwerke zu einer interessanten und nütrzlichen Ressource für ZDB/Filmportal zu machen, könnten noch die Schnittmengen mit Wikidata und MusicBrainz untersucht werden. Diese beiden Datenbanken bieten wie die GND persistente Idenitfikatoren und liefern maschinell verarbeitbare Daten über frei nutzbare Programmschnittstellen (APIs).

''In der ZDB vorhandene Daten:'' Hier eine Abfrage vorhandener P2-Angaben in der Relation "Musikalische_Vorlage"
select relation.SubjUID, filmwerk.IDTitel_P, relation.ObjUID,
person.IDName, relation.P2 FROM relation
JOIN filmwerk on filmwerk.uid=relation.SubjUID
JOIN person on relation.ObjUID=person.uid
WHERE relation.Rel="Musikalische_Vorlage" AND relation.ObjEnt="P" AND (relation.P2 is not null)

==== Literarische Vorlagen und Bühnenstücke ====

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.

Bereinigung des Datenschemas

2025-08-20T13:25:43Z

Krose:

Seit der Definition des Datenbankschemas für die Zentrale Filmografie (ZDB) sind in der Praxis etliche der ursprünglichen Annahmen obsolet geworden.

==Zugelassene Relationen==

Als Ausgangspunkt erstellen wir eine Übersicht über die in der Tabelle "relation" vorhandenen Verknüpfungen:

SELECT relation.SubjEnt, ent1.Tabname, relation.ObjEnt, ent2.Tabname, COUNT(*) AS AnzRel
FROM pdf.relation
JOIN entities AS ent1 ON ent1.ID=relation.SubjEnt
JOIN entities AS ent2 ON ent2.ID=relation.ObjEnt
GROUP BY relation.SubjEnt, relation.ObjEnt

Eine aktuelle Übersicht findet sich hier: [https://zdb.dff.film/fdb/relationStatus.php]

==Betroffene Entitäten==

===Plakat===
Metadaten zu Filmplakaten werden, anders als im ersten Schema-Entwurf angelegt, über das Filmportal-CMS verwaltet. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 02-Jun-2023: Alle Instanzen von Entität PL (Plakat) und Relationen FM<->PL gelöscht (s.o.); Tabelle "plakat" und Programmcode zur Anzeige von Plakat-Metadaten aus ZDB entfernt.

Plakat-Metadatensätze des DFF haben derzeit (noch) keine persistenten Identifikatoren. Eine verlässliche Verlinkung von der ZDB zur Darstellung in Filmportal oder DDB ist derzeit nicht möglich.

===Foto===
''Status:'' '''Erledigt'''

Metadaten zu Fotos werden, anders als im ersten Schema-Entwurf definiert, über das Filmportal-CMS verwaltet. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 03-Jun-2023: Alle Instanzen von Entität FO (Foto) und Relationen FO<->P sowie FW<->FO gelöscht (s.o.). Tabelle "plakat" entfernt.
* 06-Jun-2023: Programmcode mit Bezug zu Foto-Metadaten in ZDB entfernt.

===Genre===
''Status:'' '''Erledigt'''

Genre-Angaben zu Filmwerken sind im ersten Schema-Entwurf definiert, konnten aber mangels Datengrundlage nicht genutzt werden. Die zu Testzwecken angelegten Datensätze und Relationen, sowie der dafür eingerichtete Programmcode werden aus der ZDB entfernt.

* 03-Jun-2023: Alle Instanzen von Entität GE (Genre) und Relationen mit GE, sowie Tabelle "genre" entfernt.
* 06-Jun-2023: Programmcode mit Bezug zu Genre-Angaben in ZDB entfernt.

===Gruppe===

''Status:'' '''Erledigt'''

Die Entität "Gruppe" war aus der Vorgänger-Datenbank am DIF in die ZDB übernommen worden. Für filmportal.de war keine Entsprechung hierzu geplant. Daher werden seither alle neuen Personengruppen in der Entität "Körperschaft erfasst". Zur Bereinigung des ZDB-Datenbestandes werden die noch vorhandenen Daten aus der Entität "Gruppe" in "Körperschaft" überführt und die Entität wie auch der zugehörige Programmcode aus der ZDB entfernt.

* 07-Jun-2023: 340 Gruppen-Datensätze waren nicht über Relationen verknüpft und wurden automatisiert gelöscht.

* 22-Mrz-2024: die verbliebenen ca. 300 Gruppen-Datensätze sind zu 2/3 in Körperschaften überführt.

'''2do''': Alle verbliebenen Instanzen der Entität Gruppe sollen in Körperschaften gewandelt werden.

===Musikwerk und Werkvorlage===
Wäre es hier nicht eine Idee, die wenigen Einträge, die wir haben (jeweils nur 28?) durch einen Link zur GND zu ersetzen und auch zukünftig eher direkt dorthin zu verlinken?
Gleiches wäre auch für die Relation FW->P "hat Vorlage" denkbar, nur dass diese natürlich weitaus öfter verwendet wurde.

===Surrogat===
Sind das einfach filmportal-Biografien, die repliziert wurden/werden?

Jour fixe 2025-07-11

2025-07-14T09:58:57Z

Krose:

== Jour fixe, Freitag, 11. Juli 2025 ==

=== Erledigtes aus voriger Besprechung ===

Körperschaft-zu-Körperschaft-Relation ist jetzt bearbeitbar. Bisher ist nur eine Vorgänger-Nachfolger-Relation definiert, weitere wären jetzt zu überlegen und zu definieren.

'''Aus GND-Ontologie (habe auch gleich nach Relationen für Personen und Familien geschaut)'''
* Link: [https://d-nb.info/standards/elementset/gnd#memberOfTheFamily] ('''''Familienmitglied''''') Domain: Person, Range: Familie
* Link: [https://d-nb.info/standards/elementset/gnd#contributingFamily] ('''''Beteiligte Familie''''') Domain: Körperschaft, Range: Familie
* Link: [https://d-nb.info/standards/elementset/gnd#contributingCorporateBody] ('''''Beteiligte Körperschaft''''') Domain: Körperschaft, Range: Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#contributingPerson] ('''''Beteiligte Person''''') Domain: Körperschaft, Range: Person
* Link: [https://d-nb.info/standards/elementset/gnd#corporateBodyIsMember] ('''''Körperschaft ist Mitglied''''') Domain: Körperschaft, Range: Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#founder] ('''''Gründer''''') Domain: Körperschaft, Range: Familie, Person, Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#hierarchicalSuperiorOfTheCorporateBody] ('''''Administrative Überordnung der Körperschaft''''') Domain: Körperschaft, Range: Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#precedingCorporateBody] ('''''Vorherige Körperschaft''''') Domain: Körperschaft, Range: Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#sponsorOrPatron] ('''''Sponsor oder Mäzen''''') Domain: Körperschaft, Range: Familie, Person, Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#succeedingCorporateBody] ('''''Nachfolgende Körperschaft''''') Domain: Körperschaft, Range: Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#temporaryNameOfTheCorporateBody] ('''''Zeitweiser Name der Körperschaft''''') Domain: Körperschaft, Range: Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#relatedCorporateBody] ('''''In Beziehung stehende Körperschaft''''') Domain: Familie, Person, Körperschaft, Range: Körperschaft
* Link: [https://d-nb.info/standards/elementset/gnd#relatedFamily] ('''''In Beziehung stehende Familie''''') Domain: Familie, Person, Körperschaft, Range: Familie
* Link: [https://d-nb.info/standards/elementset/gnd#relatedPerson] ('''''In Beziehung stehende Person''''') Domain: Familie, Person, Körperschaft, Range: Person
* Link: [https://d-nb.info/standards/elementset/gnd#acquaintanceshipOrFriendship] ('''''Beziehung, Bekanntschaft, Freundschaft''''') Domain: Familie, Person, Range: Familie, Person
* Link: [https://d-nb.info/standards/elementset/gnd#familialRelationship] ('''''Familiäre Beziehung''''') Domain: Familie, Person, Range: Familie, Person

'''Kleinkram'''

* In einigen Datensichten wurde Text nach doppelten Anführungszeichen "verschluckt". Ist jetzt korrigiert, aber wahrscheinlich gibt es noch unentdeckte Fälle.

=== Unerledigtes aus voriger Besprechung ===

Fehlende Relation Filmwerk '''''hat_Thema''''' [ Sachbegriff | Person | Körperschaft ]. Sachbegriffe könnten vorrangig oder ausschließlich der GND entstammen, Personen und Körperschaften vorrangig oder ausschließlich der ZDB selbst.

'''''Frage:''''' wird filmportal.de eine solche Themenaussage für die Anzeige auswerten, ignorieren, oder wird sie die Portal-Software ins Stolpern bringen?

"'''Wahlwiederholung'''" beim Zuordnen von Personen und Körperschaften. -- ist in Arbeit.

=== Semantischer Abgleich von Element- und Relationenvokabular ===

Kristina bringt verschiedene Ansätze ins Gespräch, vielleicht gelingt es schon, daraus einige Aufgaben zu definieren.

'''Vokabular-Werkzeug'''

Leidige Frage; ich (DB) wünschte, ich könnte hiezu eine klare Empfehlung geben.

Kandidaten, die ich bisher evaluieren, teils auch nutzen konnte:

'''xTree''' von digiCULT.

(+) Zahlreiche Anwender in deutschen Museen und Kultureinrichtungen. Integration mit der digiCULT-Katalogisierungs- und Publikationsplattform für museale Sammlungen.

(-) Semi-kommerzielle Plattform, Closed Source, kein eigenes Hosting möglich. RDF/SKOS-Export unvollständig, keine eigene Unsterstützung für LOD-Publikation der Vokabulare.

'''Vocbench'''

(+) Zahlreiche Anwender bei UN- und EU-Behörden, Open Source, eigenes Hosting möglich, deckt vieles an aktueller Wissensrepräsentation ab.

(+) Benutzen wir für das DE-BIAS Projekt

(-) aufwändiger Registrierungs- und Veröffentlichungsprozess

(+/-) kann viel, erfordert deswegen aber auch etwas Einarbeitung

'''Protégé'''

(+) Seit Jahrzehnten das Standard-Werkzeug für anspruchsvolles Ontologie-Design und Re-Engineering. Open Source, eigenes Hosting möglich, viele Plugins

(-) Komplexe Benutzeroberfläche, großer Umfang von für Terminologiearbeit wenig relevanten Funktionen.

'''OntoME''' [https://ontome.net/]

(+) Zahlreiche Anwender in Geschichts- und Geisteswissenschaften. Übersichtliche Benutzerobefläche, untersützt Alignment und Anwendungsprofile für vorhandene Vokabulare, LOD-Publikation mit eigenen Namensräumen.

(-) Obwohl Open Source, kein eigenes Hosting möglich, d.h. vollständig abhängig von den Universitäten Lyon und Grenoble.

----

Interessant und eine Evaluierung wert wäre vielleicht:

'''Atramhasis''' [https://github.com/OnroerendErfgoed/atramhasis]

SKOS (und ISO-Thes)-basierte Vokabularverwaltung, ursprünglich entwickelt für das flämische Kulturerbe. Übersichtliches Design, wird aktiv weiterentwickelt und mittlerweile genutzt für zahlreiche weitere Projekte. Open Source, geeignet für eigenes Hosting, LOD-Publikationsschnittstelle.

Daneben werden anscheinend immer wieder neue SKOS-Editoren entwickelt, über die Gründe lässt sich trefflich spekulieren.

Jour fixe 2025-07-11

2025-07-10T10:14:39Z

Krose:

== Jour fixe, Freitag, 11. Juli 2025 ==

=== Erledigtes aus voriger Besprechung ===

Köroerschaft-zu-Körperschaft-Relation ist jetzt bearbeitbar. Bisher ist nur eine Vorgänger-Nachfolger-Relation definiert, weitere wären jetzt zu überlegen und zu definieren.

'''Kleinkram'''

* In einigen Datensichten wurde Text nach doppelten Anführungszeichen "verschluckt". Ist jetzt korrigiert, aber wahrscheinlich gibt es noch unentdeckte Fälle.

=== Unerledigtes aus voriger Besprechung ===

Fehlende Relation Filmwerk '''''hat_Thema''''' [ Sachbegriff | Person | Körperschaft ]. Sachbegriffe könnten vorrangig oder ausschließlich der GND entstammen, Personen und Körperschaften vorrangig oder ausschließlich der ZDB selbst.

"'''Wahlwiederholung'''" beim Zuordnen von Personen und Körperschaften. -- ist in Arbeit.

=== Semantischer Abgleich von Element- und Relationenvokabular ===

Kristina bringt verschiedene Ansätze ins Gespräch, vielleicht gelingt es schon, daraus einige Aufgaben zu definieren.

'''Vokabular-Werkzeug'''

Leidige Frage; ich (DB) wünschte, ich könnte hiezu eine klare Empfehlung geben.

Kandidaten, die ich bisher evaluieren, teil auch nutzen konnte:

'''xTree''' von digiCULT.

(+) Zahlreiche Anwender in deutschen Museen und Kultureinrichtungen. Integration mit der digiCULT-Katalogisierungs- und Publikationsplattform für museale Sammlungen.

(-) Semi-kommerzielle Plattform, Closed Source, kein eigenes Hosting möglich. RDF/SKOS-Export unvollständig, keine eigene Unsterstützung für LOD-Publikation der Vokabulare.

'''Vocbench'''

(+) Zahlreiche Anwender bei UN- und EU-Behörden, Open Source, eigenes Hosting möglich, deckt vieles an aktueller Wissensrepräsentation ab.

(+) Benutzen wir für das DE-BIAS Projekt

(-) aufwändiger Registrierungs- und Veröffentlichungsprozess

(+/-) kann viel, erfordert deswegen aber auch etwas Einarbeitung

Jour fixe 2025-07-11

2025-07-10T10:14:15Z

Krose:

== Jour fixe, Freitag, 11. Juli 2025 ==

=== Erledigtes aus voriger Besprechung ===

Köroerschaft-zu-Körperschaft-Relation ist jetzt bearbeitbar. Bisher ist nur eine Vorgänger-Nachfolger-Relation definiert, weitere wären jetzt zu überlegen und zu definieren.

'''Kleinkram'''

* In einigen Datensichten wurde Text nach doppelten Anführungszeichen "verschluckt". Ist jetzt korrigiert, aber wahrscheinlich gibt es noch unentdeckte Fälle.

=== Unerledigtes aus voriger Besprechung ===

Fehlende Relation Filmwerk '''''hat_Thema''''' [ Sachbegriff | Person | Körperschaft ]. Sachbegriffe könnten vorrangig oder ausschließlich der GND entstammen, Personen und Körperschaften vorrangig oder ausschließlich der ZDB selbst.

"'''Wahlwiederholung'''" beim Zuordnen von Personen und Körperschaften. -- ist in Arbeit.

=== Semantischer Abgleich von Element- und Relationenvokabular ===

Kristina bringt verschiedene Ansätze ins Gespräch, vielleicht gelingt es schon, daraus einige Aufgaben zu definieren.

'''Vokabular-Werkzeug'''

Leidige Frage; ich (DB) wünschte, ich könnte hiezu eine klare Empfehlung geben.

Kandidaten, die ich bisher evaluieren, teil auch nutzen konnte:

'''xTree''' von digiCULT.

(+) Zahlreiche Anwender in deutschen Museen und Kultureinrichtungen. Integration mit der digiCULT-Katalogisierungs- und Publikationsplattform für museale Sammlungen.

(-) Semi-kommerzielle Plattform, Closed Source, kein eigenes Hosting möglich. RDF/SKOS-Export unvollständig, keine eigene Unsterstützung für LOD-Publikation der Vokabulare.

'''Vocbench'''

(+) Zahlreiche Anwender bei UN- und EU-Behörden, Open Source, eigenes Hosting möglich, deckt vieles an aktueller Wissensrepräsentation ab.
(+) Benutzen wir für das DE-BIAS Projekt

(-) aufwändiger Registrierungs- und Veröffentlichungsprozess

(+/-) kann viel, erfordert deswegen aber auch etwas Einarbeitung