Elementvokabulare

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: FAIRe Vokabulare und Normdaten für Museen und Sammlungen (2025), basierend auf den FAIR Principles.

• alle Anforderungen von 5-Star Linked Open Data für den externen Zugang.

• konforme Anwendung der SKOS-Spezifikation und, soweit erforderlich, deren Ergänzungen SKOS-XL, ISO-Thes und 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 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.