Inhalt
| Inhalt |
|---|
Zur Diskussion verschiedener Modellierungsoptionen für die Abbildung der Werkebene in bibliografischen Daten / Titeldaten
- zu berücksichtigen:
- Optionen nach RDA
- Angabe von Literalen (Werktitel und ggf. weitere Attribute)
- Link zu GND-Werk-Datensätzen
- constraints der properties
- Modellierung von vorhandenen Titeldaten (RAK etc.)
- Optionen nach RDA
Status quo (DINI-AG-KIM-Empfehlung)
...
| Option 4 (mit blank nodes) | Bemerkung | |||||
|---|---|---|---|---|---|---|
| A creative work that this work is an example/instance/realization/derivation of. |
|
| Option 5 (mit generierten Werk-URIs) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
--> Alternative: blank node? | |||||||||
| Codeblock |
Property-Wahl für Werkverknüpfung
Diskussion 02.09.2015
Der schema:exampleOfWork Property liegt mit Domain und Range schema:CreativeWork kein Contraint zu Grunde, der nicht zu den künftigen RDA-Daten passen würde.
Werktitelliterale
Diskussion 02.09.2015
Nach wie vor Bedenken, dass die rdau:P60588 "has preferred title for the resource" verständlich genug ausdrückt, dass es sich bei dem Literal um den Titel des zugehörigen Werkes handelt. Zwar ist es eindeutig in rdau so entstanden und gemeint, aber intuitiv wirkt es bei vorliegender Benennung und Definition trotzdem nicht.
Lars Svensson regt an, die Option bnode mal durchzudenken: hat den Vorteil, dass sowohl Literal als auch Relation mit derselben Property ausgedrückt werden können, was es in SPARQL-Abfragen gedacht, einfacher macht.
Für die Empfehlungen 1.0 wurde bewusst nirgendwo eine bnode-Empfehlung gegeben.
Adrian ist nicht mehr so contra bnode wie früher. hbz liefert jetzt zumeist json-ld und da stören bnodes nicht so sehr.
Fazit: Es kann noch keine Entscheidung erreicht werden, am 08.10.2015 besprechenr wir die von Adrian Pohl ergänzte Option 4 mit bnode.
[Nachtrag Jana:] Ist es richtig, dass wir keine Empfehlung abgeben werden, ob bei einer vorhandenen Relationen noch zusätzlich das Literal ausgegeben werden soll, sondern das Sache des Datenerzeugers ist?
Diskussion 08.10.2015
Stefanie Rühle: Werktitelliteral sollte vielleicht gar nicht ausgegeben werden, sondern nur Werkverknüpfungen. Es handelt sich ja bei dem Werk um eine andere Ressource und es sollte irgendwo eine Grenze gezogen werden, wieviel Beschreibung über andere Ressource man in eine Beschreibung aufnimmt.
Barbara Block: Für die Erfassung war z.B. bei Musiktonträgern der Hintergrund, dass auf einer CD so viele Stücke sein können, dass es nicht leistbar ist, für alle eigene Werksätze zu machen, weshalb dann alles in einem Datensatz erfasst wird (Manifestationstitel in MARC 249/505).
Jana Hentschke: ein vielzitiertes Nutzerbedürfnis ist es doch immer, "alle Ausgaben eines bestimmten Werkes" recherchieren zu können. Das Werktitelliteral dann nicht zu transportieren, wenn es doch schon erfasst wird, wäre schade.
Vorläufiges Fazit: Die Werkverknüpfung wird mit RDA nicht so flächendeckend praktiziert, wie man es sich aus LD-Sicht gewünscht hätte. Wie gehen wir damit um? Sollen Properties gesucht werden, die es ermöglichen, diese Informationen über das Werk in der RDF-Beschreibung der Manifestation zu transportieren? Oder soll sie in RDF unterschlagen werden?
ToDo: Bisher unberücksichtigt: die Lösung für die Werktitelliterale sollte idealer Weise auch eine sinnvolle Umsetzung für die Einheitssachtitel sein, die in den Altdaten aus der Zeit vor RDA in denselben Feldern (MARC 130, 240, 730, 7X0 $t) erfasst wurden.
Werktitel-Literale und -Verknüpfungen mit dergleichen oder mit unterschiedlichen Properties ausgeben?
Diskussion 08.10.2015
Andreas Kahl spricht sich dafür aus, die Verwendung von bNodes weiterhin zu vermeiden, außer es gibt absolut gar keine Alternative. bNode behalten den Nachteil, dass sie eine Hierarchie einfügen - die untergeordneten Triple im bNode haben kein explizites Subjekt.
Die Alternativlösung, zwei verschieden Properties für Werktitelliteral und Werktitelverknüpfung, hat den Nachteil, dass man die Daten sehr gut kennen muss, um zu wissen, dass zwei Varianten berücksichtigt werden müssen, um alle Werktitel auszuwerten.
Option 5, Andreas Kahl: Für Werke für die wir keine URIs haben, könnten wir auch welche generieren. Das wären dann zwar von allen RDF-Produzenten unterschiedliche URIs, aber die zusammenzubringen ist auch nicht schwieriger, als ein Stringabgleich.
Sein Beispiel für einen solche URI: http://d-nb.info/title/123/
...
exampleOfWork/t456 (t456 ein persistenter Wert) [Nachtrag: oben eingefügt als Option 5]
Vorteil: statt des unbenannten Subjekts hat man einen referenzierbaren URI. Verbünde können untereinander sameAs-Mappings erstellen
Stefanie Rühle: ... und wenn es irgendwann stabile (GND-)URIs gibt, müssen diese nicht in den verteilten Datenbeständen nachvollzogen werden, dann wird einfach das Mapping erweitert.
Reinhold Heuvelmann: Im DNB Bibframe-Prototypen wird das für die Werkeben bereits gemacht:
Z. B. http://d-nb.info/
...
schema:exampleOfWork
bf_temp/work_1075923727 (1075923727 ist die IDN des Satzes der zusammengesetzten Beschreibung)
Stefanie Rühle: Wir sollten mit den DDB-Kollegen reden (Francesca Schulze). Dort werden URIs für Events generiert und es ist zu dem Thema einiges an Erfahrung vorhanden. ToDo: Jana Hentschke
Diskussion Arbeitstreffen 21.01.2016
<http://schema.org/exampleOfWork>
<http://schema.org/domainIncludes> <http://schema.org/CreativeWork> ;
<http://schema.org/rangeIncludes> <http://schema.org/CreativeWork> ;
a <http://www.w3.org/2000/01/rdf-schema#Property> ;
<http://www.w3.org/2000/01/rdf-schema#comment> "A creative work that this work is an
...
example/instance/realization/derivation of.
...
bf:instanceOf
...
"@en ;
<http://www.w3.org/ns/rdfa#usesVocabulary> <http://schema.org/> .
Ein Vorteil der bNode/Hash-URI-Lösung ist jetzt auch, dass für unverknüpfte Werke auch dc:creator etc. mittransportiert werden können und, dass dieselben Properties für dieselben Elemente verwendet werden können, wie bei anderen Ressourcen auch.
Fazit: siehe und Property schema:exampleOfWork
Modellierung Werk
| http://d-nb.info/gnd/4286121-4 | Bemerkung | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
oder <gndo:preferredNameForTheWork> The hound of the Baskervilles oder <bf:workTitle>The hound of the Baskervilles oder <schema:name> The hound of the Baskervilles oder <bne:hastitleofthework>The hound of the Baskervilles
oder
oder
oder
| RDA: "has preferred title for the work" | http://d-nb.info/gnd/4286121-4 |
...