Erweiterte Empfehlungen (Textressourcen) *NEU 2017*

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" ] .

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).  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.

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.

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.

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.")

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.

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. 

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 ] .