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

[Konstantin Baierer]

Liebe Liste,

TL;DR: Ich wäre für Modellierung mit Blank Nodes, solange
Rückwärtskompatibilität gewahrt bleibt.

Hier ein Beispiel, wie die Änderung wie ich sie verstehe, in RDF-XML
Syntax aussähe:

BISHER (wenn Person in GND)

<rdf:Description rdf:about="http://d-nb.info/840726325">
   <dcterms:creator rdf:resource="http://d-nb.info/gnd/11852710X"/>
</rdf:Description>
<rdf:Description rdf:about="http://d-nb.info/gnd/11852710X">
   <dc:label>Doyle, Arthur Conan</dc:label>
</rdf:Description>

BISHER (wenn Person nicht in GND)

<rdf:Description rdf:about="http://d-nb.info/840726325">
   <dc:creator>Doyle, A. C.</dc:creator>
</rdf:Description>

NEU (wenn Person nicht in GND)

<rdf:Description rdf:about="http://d-nb.info/840726325">
   <dcterms:creator>
     <rdf:Description rdf:nodeID="ZUFAELLIGE_BLANK_NODE_ID">
       <dc:label>Doyle, Arthur Conan</dc:label>
     </rdf:Description>
   </dc:creator>
</rdf:Description>

Die Lösung mit Blank Nodes würde die Abfragemöglichkeiten über SPARQL
vereinheitlichen:

SELECT ?creator_name WHERE {
   <http://d-nb.info/840726325> dcterms:creator ?creator .
   ?creator dc:label ?creator_id .
}

statt, wie bisher,

SELECT ?creator_name WHERE {
   {
     <http://d-nb.info/840726325> dcterms:creator ?creator .
     ?creator dc:label ?creator_id .
   } UNION {
      <http://d-nb.info/840726325> dc:creator ?creator .
   }
} LIMIT 1

Ein Nachteil von Blank Nodes ist, dass Blank Nodes sich zwar in SPARQL
wie URIs verhalten, aber keine sind. Insbesondere sind die Identifier
der Blank Nodes nur immer pro einzelner Abfrage gültig. Das macht es
schwierig, nicht-statische Daten mit Text-Werkzeugen wie grep, sed oder
mit XML-Werkzeugen wie XSLT zu durchsuchen.

Da die GND so umfangreich ist, ist es meiner Erfahrung nach aus
Speichergründen schwierig, die gesamten Daten effizient mit SPARQL zu
durchsuchen. Daher arbeite ich meist auf dem Dump der Daten im N-TRIPLE
Format, da man das leicht durchsuchen und indexieren kann.

Bisher konnte man die Fallunterscheidung wie man an das Label einer
Resource kommt, anhand des Property-Namen machen (im Beispiel dc:creator 
vs dcterms:creator ). Gibt es nur eine Literal-Property: Nimm den Wert. 
Gibt es eine URI-Property: Speichere die URI, derefenziere sie per HTTP 
oder lokal und nimm den Wert aus der dereferenzierten Ressource (bspw. 
dc:label).

Mit der Blank-Node-Modellierung muss man eine Fallunterscheidung anhand
des Typen von referenzierter Resource machen (BNode vs. URI) und man
muss die Dereferenzierung im selben Schritt machen, weil die ID von
Blank Nodes nicht persistent ist. In RDF/XML-Syntax sehen die Referenzen
auf BNode, bzw. auf URI sehr unterschiedlich aus (siehe Beispiel oben).
Mit XML-Werkzeugen könnte es dadurch komplexer werden , an die Labels zu 
kommen, für die Arbeit mit Textwerkzeugen auf N-TRIPLE-Syntax kann man 
aber beide Fälle gleich behandeln.

Ein Vorteil einer Modellierung mit Blank Nodes ist, dass diese auch mehr
als eine Property enthalten können, bspw. das Literal in mehreren
Sprachen, sowie rdf:type Statements. Wenn die Blank Nodes dann in der
Zukunft zur URIs werden (bspw. die Person in der GND identifiziert
wurde), müssen Konsumenten der Daten wenig bis gar nichts ändern.

Im Sinne von einheitlichen und stabilen Daten wäre ich also *für* die
Modellierung mit Blank Nodes.

Allerdings frage ich mich, wie drastisch diese Änderung wäre, d.h. an
wie vielen Stellen im Modell kommt das vor, wie viele Statements sind 
davon betroffen und kann man sicherstellen, dass die Änderung 
rückwärtskompatibel ist?

Beste Grüße

Konstantin

-- 
Konstantin Baierer
Universitätsbibliothek Mannheim
Abteilung Digitale Bibliotheksdienste / Projekt InFoLiS II
68131 Mannheim
Tel. 0621/181-2962
Email: konstantin.baierer at bib.uni-mannheim.de