Page tree
Skip to end of metadata
Go to start of metadata

In Arbeit

Diese Seite wird als Nachfolger von Erweiterte Empfehlungen für Textressourcen vorbereitet und ist derzeit in Bearbeitung und noch nicht final abgestimmt! [Jana Hentschke, 16.02.2017]

Während in den Empfehlung für die RDF-Repräsentation bibliografischer Daten (Textressourcen) ein Kernelementset zur bibliografischen Identifizierung von Textressourcen abgebildet wird, sollen diese erweiterten Empfehlungen sukzessive zusätzliche Elemente  ergänzen. Sie ergeben sich zum Beispiel aus praktischen Anforderungen an die RDF-Datensets der einzelnen Gruppenmitglieder und werden in der Gruppe abgestimmt.

Identifier

Inhalt

RDF-Property

Objekttyp

Bemerkung

CODENbibo:codenLiteralbetrifft Zeitschriften
Europäische Artikel Nummer (EAN)schema:gtin13 Literal 

Inhaltserschließende Angaben

Bereich noch in Bearbeitung! [20170301 Jana Hentschke]

 

Für inhaltserschließende Begriffe wird die RDF-Property dct:subject empfohlen.

Sind die Begriffe eines verwendeten Knowledge Organisation System (KOS) über persistente URIs referenzierbar (siehe z.B. DCMI Metadata Terms, Vocabulary Encoding Scheme und Basel Register of Thesauri, Ontologies & Classifications, BARTOC), sollten diese in der Objektposition benutzt werden.

Beispiel URI-Referenz
@prefix dct: <http://purl.org/dc/terms/> . <http://lod.b3kat.de/title/BV023347895> dct:subject <http://d-nb.info/gnd/4763160-0> .

 

Ist dies nicht der Fall, wird empfohlen, die Property dct:subject mit einem blank node zu verwenden. In ihm sollte das zugehörige KOS mittels der Property bf:source angegeben werden und der Begriff mit der Property rdfs:label und/oder (bei Klassifikationsnotation) mit skos:notation. Vgl. Link Allgemeiner Text über bNodes bei nicht-verknüpften Inhalten. (warning)

Beispiel blank node
@prefix dct: <http://purl.org/dc/terms/> .
@prefix bf: <http://id.loc.gov/ontologies/bibframe/> . 
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<http://lobid.org/resources/HT002213253#!>
  dct:subject [
    bf:source <http://purl.org/dc/terms/DDC> ;
    rdfs:label "Bildung und Erziehung" ;
    skos:notation "370"
  ], [
    bf:source <http://purl.org/dc/terms/DDC> ;
    rdfs:label "Recht" ;
    skos:notation "340"
  ] .

 

Alternativ ist es möglich, den Begriff (insbesondere Klassifikationsnotation) mit der Property dc:subject als Literal zu transportieren und mit einem spezifischen Datentyp zu versehen (siehe z.B. DCMI Metadata Terms, Syntax Encoding Schemes).

Beispiele
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dnbt: <http://d-nb.info/standards/elementset/dnb#> .
 
<http://d-nb.info/1066473110> dc:subject "TJ"^^dnbt:thema-classification-notation .

 

Für komplexe inhaltserschließende Angaben, z.B. Schlagwortketten, kann ein madsrdf:ComplexSubject verwendet werden.

Beispiel Schlagwortkette
@prefix dct: <http://purl.org/dc/terms/> .
@prefix madsrdf: <http://www.loc.gov/mads/rdf/v1#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix gndo: <http://d-nb.info/standards/elementset/gnd#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://lobid.org/resources/HT019025795#!>
  dct:subject [
    a madsrdf:ComplexSubject ;
    madsrdf:componentList (
     <http://d-nb.info/gnd/4114333-4>
     <http://d-nb.info/gnd/4221315-0>
     [ rdfs:label "Geschichte" ;
       rdf:type gndo:SubjectHeading ]
    )
  ] .

Weitere Ausführungen: Empfehlung für Modellierung komplexer inhaltserschließender Angaben

 

Inhalt

RDF-Property

Objekttyp

Bemerkung

Zielgruppedct:audienceURIz.B. GND: http://d-nb.info/gnd/<ID>
Inhaltszusammenfassungdct:abstract

Literal

Auch ein URL auf z.B. eine gescannte Datei ist möglich.
Inhaltsverzeichnisdct:tableOfContents

 

Literal

 

 Auch ein URL auf z.B. eine gescannte Datei ist möglich.
Inhaltsangabe allgemeindct:descriptionLiteral

Auch ein URL auf z.B. eine gescannte Datei ist möglich.

Zu verwenden, wenn nicht differenziert werden kann, welche Art von Angabe zum Inhalt (Inhaltszusammenfassung, Inhaltsverzeichnis) vorliegt.

Vertriebsangabe, Herstellungsangabe, Entstehungsangabe

 

Inhalt

RDF-Property

Objekttyp

Bemerkung

Vertriebsangaberdau:P60330Literal 
Herstellungsangaberdau:P60331Literal 
Entstehungsangabe (bei unveröffentlichten Ressourcen)rdau:P60332Literal 
Vertriebrdau:P60438Literal 
Herstellerrdau:P60162Literal 
Produzent ((warning) Erläuterndes zum Unterschied zu Hersteller?)rdau:P60441Literal 

Datumsangaben

Falls möglich, sollten für die folgenden Datumsangaben ein Datentyp angeben werden, z.B. http://www.w3.org/2001/XMLSchema#gYear, für 4-stellige Jahresangaben.

Inhalt

RDF-Property

Objekttyp

Bemerkung

Datum des Originals (bei Reproduktionen)rdau:P60527Literal Datentyp angeben, z.B. http://www.w3.org/2001/XMLSchema#gYear, für 4-stellige Jahresangaben
Copyrightdatumdct:dateCopyrightedLiteral Datentyp angeben, z.B. http://www.w3.org/2001/XMLSchema#gYear, für 4-stellige Jahresangaben
Vertriebsdatumrdau:P60070LiteralDatentyp angeben, z.B. http://www.w3.org/2001/XMLSchema#gYear, für 4-stellige Jahresangaben
Herstellungsdatumrdau:P60072LiteralDatentyp angeben, z.B. http://www.w3.org/2001/XMLSchema#gYear, für 4-stellige Jahresangaben
Entstehungsdatum (bei unveröffentlichten Ressourcen)rdau:P60071LiteralDatentyp angeben, z.B. http://www.w3.org/2001/XMLSchema#gYear, für 4-stellige Jahresangaben

Ortsangaben

Inhalt

RDF-Property

Objekttyp

Bemerkung

Vertriebsortrdau:P60160Literal 
Herstellungsortrdau:P60162Literal 
Entstehungsort (bei unveröffentlichten Ressourcen)rdau:P60161Literal 
Geografische Angaben (z.B. für Kartenmaterial)dct:spatialbNode

Die Geometrien können innerhalb des Blank Nodes mit WKT (Well-known Text) beschrieben werden unter Verwendung des Datentyps geo:asWKTLiteral. Dazu ein Beispiel:

@prefix sf: <http://www.opengis.net/ont/sf#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix bibo: <http://purl.org/ontology/bibo/> .

<http://d-nb.info/1105671259> a bibo:Map , bibo:Document ;
 dc:title "Sehkarte Ostfriesland, Jadebusen, Elbe" ;
 dct:spatial [
 a sf:Polygon ;
 geo:asWKT "Polygon (( +006.666666 +054.166666, +006.666666 +053.500000, +008.666666 +053.500000, +008.666666 +054.166666, +006.666666 +054.166666 ))"^^geo:wktLiteral .
] .

Eine alternative Möglichkeit ist die Angabe der Geometrie mit schema:geo.

Weitere Ausführungen zu geografischen Angaben: Empfehlung für geografische Angaben zu Karten

Erscheinungsweise

Inhalt

RDF-Property

Objekttyp

Bemerkung

Erscheinungsfrequenzdct:accrualPeriodicityURI

 Werte des Value Vocabularies  Publication Frequencies Scheme

 

 

  • No labels

10 Comments

  1. Für lobid haben wir uns entschieden, weitestgehend der schema.org-Variante zur Angabe von Publikationsangaben zu folgen, die ja sehr dem Ansatz der British Library ähnel. Dabei werden die Publikationsangaben (Ort, Datum, Publisher) mit der Property https://schema.org/publication an eine Entity vom Typ https://schema.org/PublicationEvent gehängt. Wir wollen sogar noch weitere Informationen ergänzen, wie Angaben zu einer Sekundärpublikation, Publikationsfrequenz (bei Periodika). Hier ein Beispiel:

     

    @prefix dcterms: <http://purl.org/dc/terms/> .
    @prefix lv: <http://purl.org/lobid/lv#> .
    @prefix rdau: <http://rdaregistry.info/Elements/u/> .
    @prefix schema: <http://schema.org/> .

    <http://lobid.org/resources/HT002213253> schema:publication
        [ a schema:PublicationEvent ;
          rdau:P60538 <http://marc21rdf.info/terms/continuingfre#i> ;
          schema:endDate "1934" ;
          schema:location "Berlin" ;
          schema:publishedBy "Weidmann" ;
          schema:startDate "1859" ],
        [ a lv:SecondaryPublicationEvent ;
          dcterms:description "Berlin : Staatsbibliothek zu Berlin, 1999",
          "Mikrofilm-Ausg." ;
          schema:location "Berlin" ;
          schema:publishedBy "Staatsbibliothek zu Berlin" ;
          schema:startDate "1999" ] .

  2. Hallo Pohl, Adrian, du hattest im Google Doc für die Hauptempfehlungen noch erwähnt, dass ihr im hbz die subjects mittlerweile anders angebt.

    Wenn ich dein Beispiel richtig überblicke, macht ihr jetzt (im Fall DDC) statt
    Literalangabe mit dc:subject+spezifischen Datentyp einen bNode. Wir können das hier als weitere Alternative darstellen (Ein wenig wird es natürlich auch vom Abschnitt "Nicht-verlinkte Information" abgedeckt. Wobei man natürlich trotzdem noch hier auf dieser Seite Empfehlungen aussprechen könnte, welche Angaben im bNode stehen sollten). (question) Könntest du hier einen Vorschlag beisteuern?

    Und für alles, was per URI referenzierbar ist (=unabhängig davon, ob Einzelschlagwort oder Schlagwortkette?), macht ihr jetzt ein mads:ComplexSubject? Das würde ich pauschal hier nicht so empfehlen wollen, weil es sicher viele Anwender gibt, die den ComplexSubject-Fall gar nicht haben und es mir dann verdaulicher und geradliniger erscheint, mir einfachen Links zu arbeiten.

     

     

  3. Bei DDC würden wir natürlich auch lieber einen URI angeben anstatt einen bnode zu benutzen. Allerdings sind wir dazu übergegangen, anstatt dewey.info-URIs bnodes zu nehmen plus die Angabe der Notation:

      {
        "label" : "Künste",
        "notation" : "700",
        "source" : {
          "id" : "http://d-nb.info/gnd/4149423-4",
          "label" : "Dewey-Dezimalklassifikation"
        }
      }
    

    Der Grund ist, dass wir nicht davon ausgehen, dass dewey.info irgendwann wieder läuft uns es nirgendwo ander DDC-URIs gibt. Zusätzlich geben wir bei allen subject-Angaben die Normdatenquelle mit bf:source an (siehe dazu https://github.com/hbz/lobid-resources/issues/265).

    Und für alles, was per URI referenzierbar ist (=unabhängig davon, ob Einzelschlagwort oder Schlagwortkette?), macht ihr jetzt ein mads:ComplexSubject?

    Nein, ComplexSubjet machen wir in den Fällen, woe die Reihenfolge der Schlagwörter eine Rolle spielt, sprich bei Schlagwortfolgen. Momentan ist also alles, was ComplexSubject ist nach RSWK. Im Verbundkatalog gibt es aber auch noch ein paar MeSH-Schlagwortfolgen, die wir allerdings bisher noch gar nicht im RDF haben. Falls die dazukommen, dann logischerweise auch mit ComplexSubject.

  4. Ok. Kannst du mir noch mal sagen, welchen Punkt du jetzt für die Erweiterten Empfehlungen zu subject ergänzt haben wolltest?

     

    Bei DDC würden wir natürlich auch lieber einen URI angeben anstatt einen bnode zu benutzen. [...] Der Grund ist, dass wir nicht davon ausgehen, dass dewey.info irgendwann wieder läuft uns es nirgendwo ander DDC-URIs gibt.

    Das schätzen wir in DNB und ZDB ähnlich ein und haben deshalb zumindest schon mal bei den DDC-Sachgruppen mit der Ausgabe in Literalform mit spezifischem Datentyp begonnen (vgl. http://d-nb.info/361103255). Das ist dann so, wie wir es hier empfehlen.

  5. Kannst du mir noch mal sagen, welchen Punkt du jetzt für die Erweiterten Empfehlungen zu subject ergänzt haben wolltest?

    Leider finde ich den von dir erwähnten Kommentar im Google Doc nicht. Ich denke mal, es ging um den ComponentList-Ansatz für RSWK-Schlagwortfolgen, der ja jetzt oben drin ist. (Ein bisschen verwirrend ist bei dem jetzigen Beispiel, dass es im Live-System momentan noch anders aussieht, siehe https://d-nb.info/964946211/about/lds. Setzt ihr das bald um? Ansonsten würde ich vorschlagen, ein lobid-Beispiel zu nehmen.)

    Gerade heißt es im Text:

    Ist dies nicht der Fall, wird empfohlen, die Property dcterms:subject mit einem blankNode zu verwenden in dem idealer Weise das zugehörige KOS mittels der Property skos:inScheme angegeben wird

    Da nicht alle Normdaten als skos:ConceptScheme typisiert sind und viele womöglich nicht einmal als RDF vorliegen, finde ich die generische bf:source-Property passender, um eine Notation oder einen Term mit der Normdatenquelle zu verknüpfen. (Definition von bf:source: "Resource from which value or label came or was derived, such as the formal source/scheme from which a classification number is taken or derived, list from which an agent name is taken or derived, source within which an identifier is unique.")

  6. Leider finde ich den von dir erwähnten Kommentar im Google Doc nicht

    Das ging mir auch so. Nachdem ich auf "resolve" gedrückt hatte, konnte ich ihn nicht mehr hervorbringen. :-/

    Ein bisschen verwirrend ist bei dem jetzigen Beispiel, dass es im Live-System momentan noch anders aussieht, siehe https://d-nb.info/964946211/about/lds

    Das stimmt natürlich. DNB ist jetzt auch frühestens im Mai 2018 damit am Start. Ich habe das Beispiel von euch eingefügt. (Allerdings habe ich die Typisierung des Formschlagworts als gndo:SubjectHeading unterschlagen. Auch wenn formal daran nichts auszusetzen ist, deckt diese Verwendung sich evtl. nicht ganz mit unserer Intention der gndo. Das möchte ich noch mal mit Hartmann, Sarah und Svensson, Lars besprechen und melde mich wieder - Das Beispiel funktioniert ja ohne rdf:type genauso gut ...)

    bf:source-Property oben ausgetauscht.

     

     

  7. Sind die Begriffe eines verwendeten Knowledge Organisation System (KOS) über persistente URIs referenzierbar (siehe z.B. DCMI Metadata Terms, Vocabulary Encoding Scheme und Basel Register of Thesauri, Ontologies & Classifications, BARTOC), sollten diese in der Objektposition benutzt werden.

    Ich verstehe nicht, warum hier DCMI Vocabulary Encoding Scheme und BARTOC genannt werden. Es geht ja nicht um URIs für die KOS selbst, sondern für die Terme aus denen sie bestehen. Da wären als Beispiele eher die GND und MeSH in RDF oder so. Das hat mich aber auf die Idee gebracht, die DC-URI für die DDC bei bf:source zu verwenden. Hab das mal angepasst. So ist es leichter zu lesen. 

    1. Wie Adrian finde ich auch den Text leicht missverständlich. Ich schlage folgendes vor:

      Sind die Begriffe eines verwendeten Knowledge Organisation System (KOS) über persistente URIs referenzierbar, sollten diese in der Objektposition benutzt werden. URIs für KOS und Begriffe können über Dienste wie Basel Register of Thesauri, Ontologies & Classifications (BARTOC) gefunden werden.

      Der Hinweis auf DCMI Metadata Terms, Vocabulary Encoding Scheme und die Verwendung mit bf:source ist super und sollte entsprechend beim bNode-Beispiel stehen. Vorschlag

      Ist dies nicht der Fall, wird empfohlen, die Property dct:subject mit einem blank node zu verwenden. In ihm sollte das zugehörige KOS mittels der Property bf:source angegeben werden und der Begriff mit der Property rdfs:label und/oder (bei Klassifikationsnotation) mit skos:notation. URIs für KOS können über Dienste wie Basel Register of Thesauri, Ontologies & Classifications (BARTOC) gefunden werden, einige, z. B. DDC, sind auch als Vocabulary Encoding Schemes in DCMI Metadata Terms aufgeführt. Vgl. Link Allgemeiner Text über bNodes bei nicht-verknüpften Inhalten.

      Viele Grüße,

       

      Lars

  8. Eine alternative Möglichkeit ist die Angabe der Geometrie mit schema:geo.

    Da könnte noch ein Beispiel aus lobid rein, etwa http://lobid.org/resources/HT019318158#!:

    <http://lobid.org/resources/HT019318158#!> a dcterms:BibliographicResource, 
     bibo:Book ;
        dcterms:spatial <http://www.wikidata.org/entity/Q365> .
    <http://www.wikidata.org/entity/Q365> a <http://lobid.org/resources/Location> ;
        rdfs:label "Köln" ;
        schema:geo [ schema:latitude 5.094222e+01 ; 
     schema:longitude 6.957778e+00 ] .
  9. (Allerdings habe ich die Typisierung des Formschlagworts als gndo:SubjectHeading unterschlagen. Auch wenn formal daran nichts auszusetzen ist, deckt diese Verwendung sich evtl. nicht ganz mit unserer Intention der gndo. Das möchte ich noch mal mit Hartmann, Sarah und Svensson, Lars besprechen und melde mich wieder - Das Beispiel funktioniert ja ohne rdf:type genauso gut ...)

    Wir haben gesprochen und ich nehme alle Bedenken zurück. Verwendung von gndo:SubjectHeading völlig in Ordnung. Zusatzidee: statt rdfs:label dann auch gndo:preferredNameForTheSubjectHeading verwenden, dann sind alle Elemente der Liste homogen.