Elementvokabulare

Eine Seite aus dem Reformhaus

Plan

Anforderungen

Warum soll an den Vokabularen 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.

Organisation der Vokabulare

skos:ConceptScheme

Wir unterscheiden zwei ConceptSchemes:

• term - alle Vokabularelemente aus der ZDB-Tabelle pdf.term, diese liefern String-Werte (mit Sprach-Attriut)
• rels - alle Voakabularelemente aus pdf.reldef, diese liefern Bezeichnungen für Beziehungen (Relationen) zwischen Entitäten

Jedes skos:ConceptScheme erhält zusätzlich einen Named Graph im RDF-Dataset, so dass Anfragen an das Vokabular besser isoliert von den Anfragen an den übrigen Datenbestand erfolgen können.

skos:ConceptGroup

In einer ConceptGroup sind Vokabularelemente zusammengefasst, die einen gemeinsamen Anwendungsbereich haben. Diese Gruppierung wird u.a. von Anwendungsprogrammen für kontextbezogene Auswahllisten genutzt.

skos:Concept

Ein skos:Concept kann Bezeichnungen in verschiedenen Sprachen, Definitionen und Gebrauchshinweise, semantische Beziehungen zu anderen Begriffen aus dem gleichen Begriffsschema, und sogenannte Mappings (Äquivalenzaussagen) zu Begriffen aus anderen Begriffsschemata haben.

Restriktionen

Um die Anwendungsdomäne eines skos:Concept zu beschränken, gibt es in der SKOS-Definition lediglich informelle Aussagemöglichkeiten wie skos:scopeNote. Diese sind allerdings nicht für die maschinelle Auswertung vorgesehen. Ein möglicher Workaround wird in Sektion 5.2 des SKOS Primer beschrieben. Allerdings lässt sich dieser Vorschlag kaum sinnvoll auf das ZDB-Vokabilar übertragen (@KR: oder hast du eine Idee, wie das zu machen wäre?).

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 Domain-Restriktion eine skos:Collection zu definieren, die in die Abfrage für Auswahllisten einbezogen werden kann. Also

 zdbvoc:PersonDomain a skos:Collection ;
   member zdbvoc:Adaption ; 
   member zdbvoc:Drehbuch ; 
   ...

|Vorschlag|: Eine bessere Möglichkeit wäre, für die Restriktionen eine eigene Property zu definieren, die direkt auf das skos:Concept angewandt werden. rdfs:domain und rdfs:rag lassen sich nicht auf Klassen-Instanzen wie skos:Concept anwenden. Unter unserem eigenen Namensraum können wir allerdings geeignete Properties definieren:

 zdb:conceptDomain a owl:ObjectProperty ;
    rdfs:domain skos:Concept ;
    rdfs:range zdb:Entity .  # Oberklasse aller Klassen der ZDB-Ontologie

 zdbvoc:Drehbuch a skos:Concept ;
    zdbvoc:conceptDomain zdb:Beteiligung ;
    ...

Ergänzend bräuchte es wohl auch eine eigene Range-Property, beispielsweise für Agent-zu-Agent-Relationen.

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, welchen Zweck diese Angaben im konkreten Fall verwendet werden. Die Instanzen von skos:Concept im zdbvoc-Namendarum sollten also auch Properties für solche Aussagen bereitstellen.

Bisher definiert und in Gebrauch sind

• für P1: Titelzusatz (1), unter Namen (202), Zeitangabe (14)
• für P2: Detail (220), Instrument (2), Rollenname (5), Sprache (1), Stimmlage (1)

|Vorschlag|: Für diese Aussagen gibt es keine Entsprechung in SKOS oder anderen Thesaurus-Standards. Da skos:Concept als owl:Class definiert ist und SKOS keine strikte Konformität mit OWL-DL vorschreibt, ließen sich diese ZDB-Datenelemente in der ZDB-Ontologie als eigene Properties für Instanzen von skos:Concept definieren:

 zdb:unterNamen
   a owl:DatatypeProperty ;
   rdfs:domain skos:Concept ;
   rdfs:range rdfs:Literal ;
   rdfs:comment "Ursprung: pdf.relation.P1" .

 zdbvoc:Animation
   a skos:Concept ;
   ...
   zdb:unterNamen rdfs:Literal ;  # ex P1 im Kontext "Animation"
   zdb:hatDetail rdfs:Literal   ; # ex P2 im Kontext "Animation"
   ...

Diskussion (alt)

• 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.