DIF Filmographie Wiki - Benutzerbeiträge [de]

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