Skip to end of metadata
Go to start of metadata

Versionshistorie

XX.11.2017

Version 2.0

Überarbeitungen im Zuge der Einführung von Resource Description and Access (RDA) an vielen Institutionen des deutschen Sprachraums,
Anpassungen an Erkenntnisse aus der Praxis der beteiligten RDF-Datenproduzenten

02.06.2014Version 1.1
urn:nbn:de:kobv:11-100217673

Korrektur des RDA Namespaces und der Base Domain

30.09.2013

Version 1.0
urn:nbn:de:kobv:11-100212769

Über die DINI-AG KIM Gruppe Titeldaten

Die Gruppe Titeldaten wurde im Januar 2012 gegründet, seit April 2012 agiert sie als Untergruppe des Kompetenzzentrums Interoperable Metadaten (DINI-AG KIM). KIM ist eine Arbeitsgruppe der Deutschen Initiative für Netzwerkinformation e. V. (DINI e.V.). Vertreten sind alle deutschen Bibliotheksverbünde, die Deutsche Nationalbibliothek, die Österreichische Bibliothekenverbund und Service GmbH, die Schweizerische Nationalbibliothek sowie einige weitere interessierte und engagierte Kolleginnen und Kollegen mit entsprechender Expertise. Die Moderation und Koordination liegt bei der Deutschen Nationalbibliothek.

Die Gruppe Titeldaten dient als Forum für den fachlichen Austausch über die Repräsentation von bibliografischen Daten als Linked Data. Die Teilnehmerinnen und Teilnehmer teilen ihre Erfahrungen, sammeln Best Practices und markieren Fallstricke in Bezug auf die Transformation vorhandener Titeldaten nach RDF.

Ergebnis dieser Diskussionen sind die "Empfehlungen zur RDF-Repräsentation bibliografischer Daten", die nun in der Version 2.0 vorliegen. Die Empfehlungen dokumentieren Lösungen und zeigen mögliche Alternativen auf. Sie sollen zum einen Neueinsteigern auf dem Gebiet die Arbeit erleichtern und zum anderen zu einer Harmonisierung der RDF-Repräsentationen von Titeldaten im deutschsprachigen Raum beitragen. Durch die Etablierung eines “Quasi-Standards” soll die Interoperabilität bibliografischer Linked-Open-Data-Publikationen im deutschsprachigen Raum gewährleistet werden.

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ß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:

  • Titel
  • Beteiligte Personen / Rollen / Organisationen
  • Datumsangaben
  • Ortsangaben
  • Identifier
  • Medientypen
  • Relationen / Hierarchien
  • Inhaltserschließende Angaben
  • Sprache

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 weitere Objekttypen (Film, Musik, etc.) sollen in späteren 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 hinausgehen.

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 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 des IFLA Library Reference Model (IFLA-LRM) 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.

Die Beispielimplementierungen (siehe Anhang) beziehungsweise die aktiven Datenproduzenten können bei Bedarf Auskunft über Mappings aus weiteren bibliothekarischen Datenformaten geben.

 Wenn URI-Referenzen nicht in allen Fällen verfügbar sind

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

Beispiel

Icon

Das Element "Schöpfer" wird nach aktueller Erfassungspraxis der Beispielinstitution über einen Link auf die Gemeinsame Normdatei (GND) identifiziert, wurde aber in einer bestimmten Generation von Altdaten als Literal erfasst.

Da es sich um dasselbe Informationselement handelt, sollte für beide Fälle dieselbe rdf:Property verwendet werden. Andernfalls ist für den Nutzer der Daten Hintergrundwissen über der Modellierung der Daten notwendig, um beide Formen gleichberechtigt auswerten zu können.

Es ist außerdem nicht ratsam, eine Property im selben Datenset sowohl mit URIs in Objektposition als auch mit Literalen in Objektposition zu verwenden. Das gilt auch für Properties, deren Definition keine Aussage zum erwarteten Objekttyp macht (wenn zum Beispiel keine  rdfs:range-Angabe vorliegt). Deshalb wird hier empfohlen, 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 die Entität, für die das Literal steht, in RDF modelliert und referenzierbar gemacht werden. 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.

Beispiel Option 1 "Hash-URI"

Bei der Erzeugung der RDF-Daten sollte der Fragmentbezeichner so generiert werden, dass er sich bei ggf. anfallender 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" beziehungsweise englisch "blank node" wird im RDF-Modell eine nicht-global-referenzierbare Ressource genannt.

Beispiel Option 2 "blank node"

Die Verwendung von blank nodes mindert die Nutzbarkeit der Daten (gegenüber URIs), da die betroffene Entität nicht eindeutig referenziert und somit nicht verlinkt werden kann. Innerhalb einer Datenversion (zum Beispiel 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 (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.

Beispiel Option 2 "blank node", Darstellung mit temporärer ID

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 entsprechende Empfehlungen enthalten. Die Zuordnung der Datenset-Zugehörigkeit eines einzelnen RDF-Dokuments setzt die Beachtung der URI-Design-Empfehlungen, das heißt 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.

Beispiel Datenset-Zugehörigkeit und Lizenz des Datensets

Anhang

  • No labels

4 Comments

  1. Zum Thema Hash-URI vs. Blank Node:

    Um ein Hash-URI zu erzeugen braucht es einen Algorithmus. Das ist aufwändig und fehleranfällig. Für Blank Nodes fällt das weg. Blank Nodes können genau wie Hash-URI innerhalb eines Dokumentes referenziert werden. Für SPARQL macht es auch keinen Unterschied und ich sehe keinen Anwendungsfall, bei dem von einem Dokument auf einen Teil eines anderen Dokumentes referenziert würde. Wenn man eine Ressource von Außen referenzierbar machen möchte, dann sollte man diese auch als ganzes dereferenzierbar machen, sprich keine Hash-, sondern Slash-URI verwenden.

    Hier mal ein Beispiel einer SPARQL-Anfrage über zwei Ressourcen, um zu verdeutlichen, dass eine Hash-URI keinen Vorteil hat:

    Gegeben:

    <http://id.meineInstitution.de/54321>  dc:creator <http: //id.meineInstitution.de/12345#creator_Bergmann_Bertram> .

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

    SELECT ?label WHERE {
      <http://id.meineInstitution.de/54321>  dc:creator ?creator_res . # ?creator_res ist jetzt <http://id.meineInstitution.de/12345#creator_Bergmann_Bertram>
      ?creator_res rdfs:label ?label .                                 # ?creator_res wird jetzt dereferenziert -> <http://id.meineInstitution.de/12345>
                                                                       # Damit wird "?creator_res rdf:label ?label" nicht das gewünschte Ergebnis liefern. 

    }

    Das war nicht richtig. Andreas hat das Gegenteil bewiesen.

  2. Ich würde übrigens nicht für die selbe Property plädieren. Der Nutzer muss sowieso Hintergrundwissen über die Modellierung der Daten haben. Dazu kommt noch, das es problematisch werden könnte, weil der Nutzer nicht weiß, was er bei der Property zu erwarten hat.

    Also einmal bekommt er

     

    <http://id.meineInstitution.de/12345> dcterms:creator _:node1ba4e4f62x838202 .
    und dann ein anderes Mal
    <http://id.meineInstitution.de/55555> dcterms:creator <http://d-nb.info/gnd/1234567890> .
    Wenn der Nutzer jetzt den Namen der Person haben möchte, dann müsste er für die erste Ressource anfragen
    SELECT *name WHERE {
      <http://id.meineInstitution.de/12345> dcterms:creator ?creator  .
      ?creator rdfs:label ?name .
    }
    und bei der zweiten Ressource
    SELECT *name WHERE {
      <http://id.meineInstitution.de/12345> dcterms:creator ?creator  .
      ?creator gndo:preferredNameForThePerson ?name .
    }
    Im Zweifelsfall weiß der Nutzer nicht, welche Ressource in ?creator nun eigentlich vorhanden ist und ob der Name jetzt mit rdfs:label oder gndo:preferredNameForThePerson ausgezeichnet wird. Das Problem hat man allerdings oft bei verteilten Abfragen und man muss einen Weg finden das abzufangen. Aber für den Fall, dass die selbe Property genutzt wird, muss ein Fall mehr überprüft werden.
    1. In der ZDB-/DNB-Titeldatenkonversion benutzen wir genau aus diesem Grund auch im bNode gndo:preferredName: Beispiel

      Ich fand nur als Beispiel hier rdfs:label anschaulicher.

  3. Ohne Mitglied der Titeldatengruppe zu sein, plädiere ich für eine Beibehaltung der aktuellen Empfehlung, wo vorhanden dcelements-Properties zu verwenden, wenn nur Namens-Strings bekannt sind.

    Ich würde schon den oben angeführten Ausgangspunkt in Frage stellen, dass "es sich um dasselbe Informationselement handelt": Einmal bezeichnet das Informationselement eine individuelle Person (etc.), das andere Mal einen Namens-String, den sich beliebig viele individuelle Personen teilen können.

    Ebenso wie Carsten sehe ich keinen Vorteil darin, aus Namen-Strings trickreich URIs zu konstruieren. Wenn der Datenproduzent der aktuellen Empfehlung folgt, weiß der Consumer, dass dass er dc:creator-Einträge einfach als String ausgeben kann, während für dct:creator ein Lookup erforderlich wird, um einen Namen anzeigen und ggf. verlinken zu können. Verrenkungen, um durch eine URI mittels spezieller Abfragen doch wieder beim Namens-String zu landen - egal, ob das nun rdfs:label oder gndo:preferredName ist - komplizieren lediglich die Verarbeitung, und die konstruierte URI ist als Link-Ziel wertlos.

    Eine Diskussion zum selben Thema findet derzeit im Dublin Core Usage Board statt - s. https://github.com/dcmi/usage/issues/42