Seitenhistorie

...

...

Die vorliegende Version 2.0 der Empfehlungen berücksichtigt die Entwicklungen der letzten Jahre. Den initialen Anlass für die Überarbeitung gab die Einführung des Katologisierungsregelwerks Resource Description and Access (RDA) in Großteilen großen Teilen der deutschsprachigen Bibliothekslandschaft in 2015/2016.

Vorgehen und Konventionen

Erläuterungen zur Vorgehensweise

Die DINI-AG KIM Gruppe Titeldaten analysierte zunächst, welche Metadaten zur Beschreibung einer bibliografischen Ressource erforderlich sind.  und welcher Gruppe einer bibliografischen Beschreibung sie zugeordnet werden können. Dies sind:

...

Die vorliegenden Empfehlungen beinhalten die Modellierung eines Kernelementsets, das für die eindeutige Identifizierung einer bibliografischen Ressource als notwendig erachtet wird. Unter Kernelementen werden hier Properties verstanden, die in einer RDF-Repräsentation enthalten sein sollen, sofern der Ausgangsdatensatz diese enthält.

Im ersten Schritt wird ein Kernelementset für textuelle Ressourcen beschrieben. Die Beschreibung von Kernelementen für spezifische weitere Objekttypen (Film, Musik, etc.) sollen in einer späteren Version Versionen folgen.

Je nach Anwendungsfall können Anforderungen bestehen, zusätzliche Informationselemente mit weiteren RDF-Properties auszuweisen oder eine größere Auswahl an Informationselementen in die RDF-Repräsentation eines Titeldatensatzes mit aufzunehmen. Dies liegt im Ermessen der jeweiligen Institution einzelnen Datenproduzenten. Die Erweiterten Empfehlungen für Textressourcen der DINI-AG KIM Gruppe Titeldaten sammeln Best Practices, die über das Kernelementeset hinaus Best Practiceshinausgehen.

Nachnutzung von RDF-Elementen

Die vorliegende Modellierung nutzt die unten tabellarisch aufgeführten RDF-Element Sets nach.

Die Auswahl richtet sich nach dem Grad der Verbreitung. Das heißt konkret: im Im ersten Schritt wird das Dublin Core-Vokabular nach geeigneten Elementen untersucht, da dieses auch außerhalb der Bibliothekswelt stark verbreitet ist. In den Versionen 1.x dieser Empfehlungen wurden (bibliotheks-)spezifischere Elemente bevorzugt aus der Bibliographic Ontology entnommen. Mit Version 2.0, nach der Einführung der Resource Description and Access (RDA) an vielen Bibliotheken im deutschen Sprachraum, werden weitere Spezifizierungen auch mit den "unconstrained" Properties des RDA Element Sets empfohlen. Deren Verwendung ist dabei unabhängig vom zugrunde liegenden Regelwerk der damit abzubildenden Daten möglich. Der Grund für die Wahl der "unconstrained" Variante der RDA-Element Sets ist der Wunsch, keine Ebenen der Functional Requirements for Bibliographic Records (FRBR) zu implizieren, damit diese Empfehlungen möglichst breit anwendbar sind.

Darstellung von RDF-Beispielen

Illustrierende Beispiele werden in Terse RDF Triple Language-Serialisierung (Turtle) notiert.

Mappings

...

•   Konzeptuelles Mapping (Inhalt - RDF) 

  • Dieses Mapping bleibt auf der konzeptuellen Ebene, das heißt die vorliegenden Empfehlungen sollen unabhängig von konkreten bibliothekarischen Datenformaten anwendbar sein. Deshalb werden die einzelnen Informationselemente

...

• • natürlichsprachig benannt und nicht anhand von MARC-Feldern o.ä. identifiziert.

• MARC 21-RDF-Mapping

verfügbar. Die Beispielimplementierungen (siehe Anhang) bzw. die aktiven Datenproduzenten können bei Bedarf Auskunft über Mappings aus weiteren bibliothekarischen Datenformaten geben.  die bestehenden Linked Data Services in Deutschland unabhängig voneinander entstanden und jede Bibliothek bzw. jeder Verbund eine eigene Datenmodellierung erarbeitete, sind die Umsetzungen vielfältig. Die unterschiedlichen Modellierungen resultieren unter anderem aus differierenden Katalogisierungsumgebungen an den verschiedenen Institutionen: Die RDF-Beschreibungen werden jeweils auf Basis unterschiedlicher Ausgangsformate erstellt. Als gemeinsames Ausgangsformat für die konkrete Datenmodellierung in RDF wurde daher MARC 21 gewählt. Zunächst folgt ein vom Ausgangsformat unabhängiges konzeptuelles Mapping. Es ist geplant, in Zukunft auch Mappings weiterer Ausgangsformate zur Verfügung zu stellen (siehe hierzu auch: Beispielimplementierungen).

...

MARC 21-RDF-Mapping

Wenn URI-Referenzen nicht immer verfügbar sind

Nicht-verlinkte Information

Viele Datenproduzenten haben mit dem Problem zu tun, dass einzelne Informationselemente sowohl als URI-Referenz auf ein anderes Datenset als auch als Literal in den Daten vorliegen können.

...

Es ist außerdem nicht ratsam, eine Property im selben Datenset sowohl als owl:ObjectProperty (d.h. mit URI in Objektposition) als auch als owl:DatatypeProperty oder owl:AnnotationProperty (d.h. mit zum einem mit einer URI in Objektposition und zum anderen mit einem Literal in Objektposition ) zu verwenden. Das sollte gilt auch geltenfür Properties, wenn ihre deren Definition keine Aussage zum erwarteten Objekttyp macht , d.h. z.B. keine (wenn zum Beispiel keine  rdfs:range-Beschränkung Angabe vorliegt). Deshalb wird hier empfohlen, im beschriebenen Fall jeweils mit einer owl:ObjectProperty zu arbeiten.stattdessen durchgängig URIs beziehungsweise unter Umständen auch Blank Nodes in Objektposition zu verwenden.

Mit anderen Worten sollte  bei bloßen Literalangaben ohne IDs in den Quelldaten Bei Literalangaben sollte demzufolge die Entität, für die das Literal steht, in RDF modelliert und referenzierbar gemacht werden. Die  Die Modellierung sollte mindestens eine Property rdfs:label (oder vergleichbar) enthalten. Für die Referenzierung werden hier zwei Optionen skizziert:

1. Generierung eines Hash-URIs für die Entität
2. Arbeiten mit einem blank node

Option 1 "Hash-URI"

Ein Fragmentsbezeichner, eingeleitet durch das Hash-Zeichen ("#"), kann einem URI angefügt werden. Die Kombination bildet dann einen weiteren URI, der etwas eindeutig identifizieren kann. Über das was, er identifizieren soll, kann dann ebenfalls unter dem Ausgangs-URI eine Beschreibung geliefert werden.

@prefix dctermsdct: <http://purl.org/dc/terms/> .
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema#> .

<http://id.meineInstitution.de/12345> dctermsdct:creator <http://id.meinebibliothek.de/12345#creator_Bergmann_Bertram> .
<http://id.meineInstitution.de/12345#creator_Bergmann_Bertram> rdfs:label "Bertram Bergmann" .

Bei der Erzeugung der RDF-Daten sollte der Fragmentbezeichner so generiert werden, dass er sich bei ggf. anfallender erneuten erneuter Erzeugung der Daten (falls diese regelmäßig aus einem anderen Format konvertiert werden) möglichst nicht ändert. Diese Lösung ist der Option "blank node" vorzuziehen, da so die Entität hinter dem Literal nicht nur temporär und im Kontext der Datenversion referenzierbar ist (wie beim blank node, siehe dort), sondern längerfristig. Das kann auch Mappingprojekte begünstigen, die auf eine Ergänzung der fehlenden Links hinarbeiten.

Option 2 "blank node"

Ein "leerer Knoten" bzw. englisch "blank node" wird im RDF-Modell eine nicht-global-referenzierbare Ressource genannt.

@prefix dctermsdct: <http://purl.org/dc/terms/> .
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema#> .

<http://id.meineInstitution.de/12345> dctermsdct:creator [
    rdfs:label "Bertram Bergmann" .
]

Die Verwendung von blank nodes mindert die Nutzbarkeit der Daten (gegenüber URIs), da kein Externer sich auf die betroffene Entität beziehen nicht eindeutig referenziert und sie somit vernetzen könntesomit nicht verlinkt werden kann. Innerhalb einer Datenversion (z.B. Datendumpdatei vom 16.05.2017) wird die Referenzierbarkeit der im blank node beschriebenen Entität zwar hergestellt über einen nur für diese Datenversion gültigen temporären Identifier . In der folgenden alternativen Notation in Turtle wird dies sichtbar, sie entspricht (siehe Beispiel unten, das semantisch dem Beispiel oben :entspricht). Allerdings handelt es sich bei einem solchen Identifier weder um eine stabile ID noch um einen HTTP-URI. Somit wird damit keine Referenzierbarkeit durch externe Datensets hergestellt.

@prefix dctermsdct: <http://purl.org/dc/terms/> .
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema#> .

<http://id.meineInstitution.de/12345> dctermsdct:creator _:node1b6mbf4tqx36921502 .
_:node1b6mbf4tqx36921502 rdfs:label "Bertram Bergmann" .

Lizenzangaben für bibliografische Daten

Betreffend die Lizensierung bibliografischer Daten sollte sich an der Empfehlungen zur Öffnung bibliothekarischer Daten der DINI-AG KIM Gruppe Lizenzen orientiert werden. Die vergebene Lizenz sollte in RDF transportiert werden. Es wird empfohlen, dies im Rahmen von Datenset-Beschreibungen zu tun. In der W3C Empfehlung "Data on the Web Best Practices" sind im Abschnitt 8.2. Metadata weitere entsprechende Empfehlungen enthalten. Die Zuordnung der Datenset-Zugehörigkeit eines einzelnen RDF-Dokuments setzt die Beachtung der URI-Design-Empfehlungen, d.h. die klare Unterscheidung der URIs für ein Ding und seine Beschreibung, voraus. Mit Hilfe des URIs der Beschreibung und der Property void:inDataset kann das RDF-Dokument als Teil eines Datensets ausgezeichnet werden.

@prefix void: <http://rdfs.org/ns/void#> .
@prefix dctermsdct: <http://purl.org/dc/terms/> .

<http://lobidd-nb.orginfo/resourcegnd/HT0087901491128736977/about> void:inDataset <http://lobidd-nb.orginfo/resourcesdataset/dataset#!>gnd> .
<http://lobidd-nb.orginfo/resourcesdataset/dataset#!>gnd> dctermsdct:license <https://creativecommons.org/publicdomain/zero/1.0/> .

Adrian, bitte noch bei dem Beispiel helfen!

Anhang

• Mitwirkende der DINI-AG-KIM Gruppe Titeldaten:
  
  • Barbara Block - GBV
  • Iris Hausmann - BSZ
  • Sarah Hartmann - DNB
  • Jana Hentschke - DNB
  • Reinhold Heuvelmann - DNB
  • Andreas Kahl - BSB
  • Cornelia Katz - BSZ
  • Carsten Klee - ZDB
  • Adrian Pohl - hbz
  • Stefanie Rühle - SUB Göttingen
  • Christiane Schmidt - Schweizerische Nationalbibliothek
  • Dr. Thomas Striffler - HeBIS
  • Dr. Lars G. Svensson - DNB
• Mitwirkende an früheren Versionen dieser Empfehlungen
  
  • Stefan Brecheisen - BVB
  • Pascal Christoph - hbz
  • Julia Hauser - DNB
  • Dieter Janka - BSZ
  • Verena Schaffner - OBVSG
  • Stephani Scholz - hbz
    
    
• URI-Design-Empfehlungen
  
  
• Best Practices / Beispielimplementierungen:
  
  • Linked Data Service der Deutschen Nationalbibliothek
  • Linked Data Service der Zeitschriftendatenbank
  • lobid-resources – der hbz-Verbundkatalog als LOD, hbz — Hochschulbibliothekszentrum des Landes NRW
  • LinkedOpenData-Service des B3Kat
  • HeBIS Linked Open Data Services
  • SWB-Verbunddatenbank als Linked Open Data