Adrian Pohl /
@acka47
Linked
Open Data, Hochschulbibliothekszentrum NRW (hbz)
Mannheim, 2018-04-10
Diese Präsentation:
http://slides.lobid.org/kim-ws-2018/
RDF isn't natural — and therefore is barely used — by the average Web developer or data wrangler. CSV [and JSON], by contrast, is. And you are going to need to win the hearts and minds of those folks for whatever approach is proposed.
– Rufus Pollock, 2013 (siehe hier & hier)
Stop mentioning RDF and the Semantic Web.
Focus on tools for developers.
Do more dogfooding.
– Manu Sporny, 2012, beim Schreiben an der JSON-LD Spec (Quelle)Ultimately, RDF and the Semantic Web are of no interest to Web developers. They also have a really negative public perception problem. We should stop talking about them. Let’s shift the focus to be on Linked Data, explaining the problems that Web developers face today, and concrete, demonstrable solutions to those problems.ebd.
Quelle: Rob Sanderson, "Publishing & Retrieving Linked Open Usable Data", CC-BY
xml api json api sparql endpoint
10 % bis 19 % aller Domains haben eingebettetes JSON-LD
Quellen: Google Trends, Web Data Commons, W3TechsEin einfaches, lesbares Key-Value-Format für strukturierte Daten
Key = String in Anführungszeichen
Values = object, array, number, string oder boolean
{ "foo": "bar" }
$ curl -H "Accept: application/json" https://api.github.com/users/acka47
{
"login": "acka47",
"avatar_url": "https://avatars2.githubusercontent.com/u/160292?v=4",
"url": "https://api.github.com/users/acka47",
"type": "User",
"name": "Adrian",
"company": "hbz",
"location": "Cologne, Germany",
"bio": "Metadata, RDF, vocabularies. Working at @hbz. "
}
{
"@context": {
"schema": "http://schema.org/",
"login": "schema:alternateName",
"avatar_url": "schema:image",
"url": "schema:url",
"type": "@type",
"User": "schema:Person",
"name": "schema:name",
"company": "schema:worksFor",
"location": "schema:homeLocation",
"bio": "schema:description"
},
"login": "acka47",
"avatar_url": "https://avatars2.githubusercontent.com/u/160292?v=4",
"url": "https://api.github.com/users/acka47",
"type": "User",
"name": "Adrian",
"company": "hbz",
"location": "Cologne, Germany",
"bio": "Metadata, RDF, vocabularies. Working at @hbz. "
}
Expanded Document Form: Ohne @context
(d.h. alle URIs immer ausgeschrieben) und Values immer in Array
Compacted Document Form: Mit @context
Flattened Document Form: Mit @context
und @graph
und alle Objekte ungeschachtelt auf einer Ebene
@context
mappt Strings für Properties & Klassen auf URIs
@id
identifiziert die URI eines Nodes (das Subjekt)
@type
ist multifunktional: legt 1.) die Klasse eines nodes (rdf:type
) fest oder 2.) den Datentyp eines Literals oder kann 3. für type coercion genutzt werden
Sonstige: @value
, @language
, @container
, @list
, @set
, @reverse
, @index
, @base
, @vocab
, @graph
{
"@context": {
"schema": "http://schema.org/",
"login": "schema:alternateName",
"avatar_url": "schema:image",
"url": "schema:url",
"type": "@type",
"User": "schema:Person",
"name": "schema:name",
"company": "schema:worksFor",
"location": "schema:homeLocation",
"bio": "schema:description"
},
"login": "acka47",
"avatar_url": "https://avatars2.githubusercontent.com/u/160292?v=4",
"url": "https://api.github.com/users/acka47",
"type": "User",
"name": "Adrian",
"company": "hbz",
"location": "Cologne, Germany",
"bio": "Metadata, RDF, vocabularies. Working at @hbz. "
}
{
"@context": {
"schema": "http://schema.org/",
"login": "schema:alternateName",
"avatar_url": "schema:image",
"url": "schema:url",
"type": "@type",
"User": "schema:Person",
"name": "schema:name",
"company": "schema:worksFor",
"location": "schema:homeLocation",
"bio": "schema:description"
},
"@id": "https://api.github.com/users/acka47#!",
"login": "acka47",
"avatar_url": "https://avatars2.githubusercontent.com/u/160292?v=4",
"url": "https://api.github.com/users/acka47",
"type": "User",
"name": "Adrian",
"company": "hbz",
"location": "Cologne, Germany",
"bio": "Metadata, RDF, vocabularies. Working at @hbz. "
}
Konversion von RDF mit JSON-LD Java Library führt zu suboptimalem Ergebnis, vor allem:
Flaches JSON, mit mehreren Nodes in @graph
-Objekt
{
"@id" : "http://lobid.org/organisation/DE-180/about",
"primaryTopic" : "http://lobid.org/organisation/DE-180",
"@graph": [ {
"@context" : "http://lobid.org/context/lobid-organisations.json",
"@id" : "http://lobid.org/organisation/DE-180",
"name" : "Universitätsbibliothek Mannheim",
"stocksize" : "http://purl.org/lobid/stocksize#n10",
"address" : "_:t3"
}, {
"@id" : "_:t3",
"countryName" : "Germany",
"locality" : "Mannheim",
"postalCode" : "68131",
"streetAddress" : "Schloss Schneckenhof West"
}, {
"@id" : "http://purl.org/lobid/stocksize#n10",
"prefLabel" : [ {
"@language" : "de",
"@value" : "1.000.001 und mehr"
}, {
"@language" : "en",
"@value" : "1,000,001 and more"
} ]
} ]
}
Quelle: http://manu.sporny.org/2014/json-ld-origins-2/#comment-4190
Wenn Node zweimal auftaucht wird Beschreibung nur einmal eingebettet
Mängel bei der Erzeugung von Arrays mit gemischten Inhalten
Index- und Auslieferungsformat unterscheiden sich (extended vs. flattened)
...plus ein paar Dinge, die ich vergessen habe
Selbst geschriebenes Java-Tool zur Generierung von JSON-LD (GitHub)
Aliasse für @type
und @id
(best practice)
Labels für alle Nodes ergänzen mit etikett
Language maps für mehrsprachige Labels
Identisches Index- und Auslieferungsformat
Verbesserte Datenmodellierung (mehr Bibframe, schema.org...)
{
"@context" : "http://lobid.org/organisations/context.jsonld",
"id" : "http://lobid.org/organisations/DE-180#!",
"name" : "Universitätsbibliothek Mannheim",
"location" : [ {
"type" : "Place",
"address" : {
"postalCode" : "68131",
"streetAddress" : "Schloss Schneckenhof West",
"addressLocality" : "Mannheim",
"addressCountry" : "DE",
"type" : "PostalAddress"
},
"geo": {
"lat": "49.48309",
"lon": "8.46362"
}
} ],
"collects" : {
"type" : "Collection",
"extent" : {
"id" : "http://purl.org/lobid/stocksize#n10",
"type" : "Concept",
"label" : {
"de" : "1.000.001 und mehr",
"en" : "1,000,001 and more"
}
}
}
}
@graph
-ObjektWenn man JSON-LD als zentrale RDF-Serialisierung benutzt, bietet sich JSON Schema zur Validierung an
Ist näher an der Serialisierung, leichter verständlich und besser unterstützt als SHACL oder ShEx
Einsatz in der OER World Map zur Validierung der Eingabe (POST)
(Noch einfacher les- und schreibbar ist GraphQL Schema Language, die für zukünftige Implementierungen in Betracht kommt.)
Mögliche Properties und Constraints finden -> in Schema schreiben -> in Editor testen -> Diskussion -> von vorne
JSON-Schema-basierter Metadateneditor von Felix Ostrowski: http://graphthinking.com/jpf/
JSON-Schemas für OER-Metadaten: https://github.com/dini-ag-kim/oer-metadata-schemas
Nachteil: abhängig von bestimmter Umsetzung einer bestimmten RDF-Serialisierung & damit nicht für andere Implementierungen als Referenz nutzbar
Ein Update der JSON-LD-Spezifikation ist im Gange.
Motto: Keys not Arrays! Framing!
Mehr Details: Präsentationsfolien von Gregg Kellog & Rob Sanderson zu JSON-LD 1.1
Rob Sanderson für seine Vortragsfolien, die mir für einige Slides als Vorlage dienten.
Rurik Greenall für seinen JSON-LD-Kurs: https://github.com/brinxmat/json-ld-course, dessen Aufgaben ich als Vorlage genommen habe.