Re: [Lds] Titeldaten: Meinungsbild zu Modellierungsfrage (Angaben, die sowohl verlinkt als auch nicht-verlinkt vorliegen können)

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 18.01.2016 um 15:00 schrieb Hentschke, Jana:

> im Zuge der Weiterentwicklung unserer RDF-Modellierung für Titeldaten,
 sind wir auf eine Frage gestoßen, zu der wir gerne eine Meinungsbild un
ter Ihnen/euch als den praktisch Betroffenen ermitteln würden:
> 
> Es geht um die Situation, dass ein Informationselement in unseren
> Daten entweder als Literal oder als URI-Verknüpfung vorliegen kann.

zwar nicht Titeldaten, aber kann ich mir das so vorstellen wie in der
GND, wo z.B. Berufe je nach "internem Verknuepfungszustand" mal als
gnd:professionOrOccupation oder als gnd:professionOrOccupationAsLiteral
ausgegeben werden?

Und die Argumente fuer und wider sind "zwei Properties fuer eine
einzige Eigenschaft" gegen "constraint checks sind moeglich"?


> Bisher haben wir uns in Absprache mit der DINI-AG KIM
> Titeldatengruppe[1] dafür entschieden, dann mit zwei unterschiedlichen
> Properties zu arbeiten, z.B.
> 
> URI:
>          <http://d-nb.info/...> dcterms:creator <http://d-nb.info/gnd/
11852710X> .
> Literal:
>          <http://d-nb.info/...> dc:creator "Doyle, A. C." .

Soweit ich weiss, sind die Elemente des Namespaces
http://purl.org/dc/elements/1.1/ keinen Einschraenkungen unterworfen,
insbesondere nicht der Einschraenkung nur #literals als Range. /Ich/
duerfte also sagen:

<http://d-nb.info/...> dc:creator <http://d-nb.info/gnd/11852710X> .

Die bisherige Zweigleisigkeit ist also nur eine Nettigkeit, vergleichbar
mit der Tatsache, dass in den Serialisierungen ein "passendes" Mass
von Zeilenumbruechen eingefuegt ist.


> Anlässlich der Abbildung von Werken soll diese Praxis nun auf den Prüf
stand:
>   Wie groß sind die Vorteile, wenn nur eine Property für denselben inh
altlichen Sachverhalt verwendet würde?
>   ... um den Preis eines blank nodes?
> 
> Ein Beispiel für eine ein-Property-Modellierung (mit blank node):
> 
> URI:
>     <http://d-nb.info/...> schema:exampleOfWork <http://d-nb.info/gnd/
4286121-4> .
> Literal:
>     <http://d-nb.info/...> schema:exampleOfWork [ dc:title "The hound 
of the Baskervilles" ] .


Eine Modellierung mit nur jeweils einer Property halte ich fuer
aeusserst begruessenswert, aus eigener Erfahrung kann ich sagen,
dass die Gefahr, nur eine Property zu finden und zu nutzen und
somit das mit der anderen Property zum gleichen Sachverhalt
abgebildete unbemerkt zu verlieren, real ist.

Die Variante mit Blank Node erlaubt es ueberhaupt erst,
schema:exampleOfWork zu nutzen, das ja die Klasse schema:CreativeWork
als Range zumindest erwartet. Bzw. inhaltlich macht die Konstruktion
deutlich, dass da eine Entitaet lauert, von der wir u.U. nur einen
Titel angeben koennen, aber der festen Ueberzeugung sind, dass sie
definitiv und ganz definiert existiert: Wir muessen sie nur noch
einfangen und mit einem Identifier versehen, aber boese
Ueberraschungen, wie etwa dass es keine Entitaet gibt oder sich unser
Subject nicht zwischen mehreren Entitaeten, die alle so betitelt sind,
entscheiden kann, sind ausgeschlossen. Mit Blank Node ist m.E.
daher sogar besser ausgedrueckt, was wir meinen oder aufgrund unserer
Grundannahmen zu wissen glauben, als ohne.

Ohne Blank node bzw. als zwei-Property-Loesung muessten wir im Beispiel
oben eine geeignete Literal-wertige Eigenschaft selber craften und
haetten dabei vermutlich ein Namensgebungsproblem, denn wir wollen
ja nicht den Eindruck erwecken, dass wir ein Werk ueber seinen Titel
identifizieren koennen und erst recht nicht, dass wir Werk und Titel
gleichsetzen. Die gebotene Vorsicht fliesst dann schnell in die
Namensgebung fuer die Property ein, die waere dann vielleicht
myohmy:exampleOfWorkEvocatedByTitle

Verarbeitungstechnisch sind bei der Blank-Node-Loesung die "Titel" alle
auf derselben Ebene (wenn man das Einschieben einer Ressourcengrenze
als zusaetzliche Ebene oder Indirektheit auffassen will, was man m.E.
aber nicht muss), ob das so viel bringt, kann ich nicht beurteilen,
eine anonyme Resource als Wert von schema:exampleOfWork koennte ja auch
ein schema:name "The hound of the Baskervilles" enthalten und die
(gar-nicht-so-)hypothetische, endgueltige und nicht-mehr-anonyme
Resource <http://d-nb.info/gnd/4286121-4> kennt es wiederum als
gndo:preferredNameForTheWork ...

Solange also ein Patchwork an Vokabularen moeglich ist, werden einige
wie ich in die Falle tappen, nicht alle in verborgener Relation
stehenden Elementnamen der beteiligten Vokabulare kennen und nutzen
zu koennen, aber die Alternative der Vokabulare aus einem Guss kennen
wir zur Genuege und verabschieden uns daher recht freudig davon...

my 2c
Thomas Berger


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iJwEAQECAAYFAlahDXEACgkQYhMlmJ6W47Ma7gQArRHCq2fzTZom+Ftn6paQxkIG
ONEjA5iIVOIcdS7IyqTIYlMMmOjQu34l5T8qUIg8F7nmvXt5pheRfJCbEYyQtQfO
gWx+6RqpCKly9HnjRDWEQnypap6qq+VNE5CGHVlnyN+QLdWTGXR/H1AQA2b6F9C0
tmn/boGdk068Nq5MyEU=
=8Wes
-----END PGP SIGNATURE-----