[Dini-ag-kim-titeldaten] Anwendungsprofile und JSON-LD-Kontext-Dokumente

Adrian Pohl pohl at hbz-nrw.de
Mit Jul 17 17:11:30 CEST 2013


Hallo,

die Version 1.0 der "Empfehlung für die RDF-Repräsentation
bibliografischer Daten (Textressourcen)"[0] wird voraussichtlich in den
nächsten Wochen veröffentlicht. Für zukünftige Versionen der
Empfehlungen wie auch für andere Anwendungsprofile fände ich es
sinnvoll, diese ergänzend in Form eines JSON-LD-Kontext Dokuments zu
publizieren. JSON-LD [1] ist ja gerade das neueste heiße Ding in der
Linked-Data-Welt und steht kurz davor, W3C-Standard zu werden. Ich habe
das Gefühl, dass Kontext-Dateien für die Dokumentation und Benutzung von
Anwendungsprofilen  wie die DINI-KIM-Titeldaten-Empfehlungen nützlich
sein könnten.

Ein JSON-LD-Kontext kann zu dem Zweck eingesetzt werden, Property-URIs
auf knappe Kürzel zu reduzieren, die dann in einem JSON-Dokument genutzt
werden können. So muss in einem JSON-Dokument z.B. nicht überall
"http://purl.org/dc/terms/title" stehen, sondern es kann einfach
die Kurzversion "title" benutzt werden, wenn diese über ein engebettetes
oder verlinktes Kontext-Dokument auf die entsprechende Property-URI
gemappt wird. Mit anderen Worten: Während die Prefix-Deklaration etwa in
einem Turtle-Dokument (z. B. "@prefix dct: <http://purl.org/dc/terms/
.") es erlaubt Namespaces durch ein Kürzel zu ersetzen, um diese im
Dokument nicht immer wiederholen zu müssen, können in einem
Kontext-Dokument komplette Property-URIs auf ein eigenes Kürzel gemappt
werden, z. B. : 

{
  "@context":
  {
    "title": "http://purl.org/dc/terms/title"
  }
}

Mit so einem Kontext-Dokument lassen sich, wenn nicht alle, so
zumindest einige wichtige Teile der Titeldaten-Empfehlungen abbilden,
nämlich die vorgeschlagenen Properties plus die Information, ob diese
mit einem URI oder einem Literal in Objektstellung verwendet werden
sollten. Die Kontext-Datei zu dem Anwendungsprofil kann dann von der
DINI-KIM-AG im Web (etwa auf github) veröffentlicht werden und jedeR
kann sich dies dann klonen und für seine Zwecke ergänzen.

Ich habe mal einen ersten Entwurf eines solchen Dokuments gemacht,
siehe [2]. Was ich noch ergänzt habe in dem Dokument sind deutsch- und
englischsprachige Labels für die Properties. (Ich bin mir nicht sicher,
ob das so gemacht werden soll/kann [3], sehe aber nichts, was dagegen
spricht.) So kann vielleicht erreicht werden, dass unterschiedliche
Projekte, die die Empfehlungen umsetzen, nicht nur einheitliche
Properties, sondern auch die gleichen Labels für die Properties
benutzen. So würden Besucher verschiedener Services nicht durch
unterschiedliche Terminologie verwirrt werden.

Hier mal beispielhaft ein Ausschnitt aus der Kontext-Datei für
dc:title:

"title": {
      "@id": "http://purl.org/dc/elements/1.1/title",
      "@type": "xsd:string",
      "label":
      [
          {
             "@value": "Titel",
             "@language": "de"
          },
          {
             "@value": "title",
             "@language": "en"
          }
      ]
    }

JSON-LD macht ja "normalen" Webentwicklern den Einstieg in die LOD-Welt
deutlich leichter. Das ist ja für sich schon mal eine Errungenschaft.
Daneben liegt m. E. eben auch einiges Potential in den
Kontext-Dokumenten, die ganz neue Möglichkeiten bieten - eben bspw. für
die Darstellung von Anwendungsprofilen. Was meinen Sie/meint ihr?

Ciao
Adrian

[0] https://wiki.dnb.de/x/cYMOB

[1] http://json-ld.org

[2]
https://github.com/acka47/dini-kim-ag-titeldaten/blob/master/titledata-context.jsonld

[3] https://twitter.com/acka47/status/357483666630393857