JSON-LD

JSON-LD
Dateiendung:	.jsonld
MIME-Type:	application/ld+json
Entwickelt von:	World Wide Web Consortium (W3C)
Aktuelle Version:	1.0 (Stand: 16. Januar 2014)
Art:	konkrete Syntax von RDF
Container für:	Linked Data
Erweitert von:	JSON, RDF
Standard(s):	JSON-LD 1.0 JSON-LD 1.0 Processing Algorithms and API (W3C Recommendations)
Website:	json-ld.org

JSON-LD (Akronym von engl. für „JSON-basierte Serialisierung für verLinkte Daten“) bezeichnet Empfehlungen des W3C, weltweit verknüpfte Daten (nach dem RDF-Modell) im schlanken JSON-Format einzubetten. Damit können Webservices und Webapplikationen, die ihre Daten bevorzugt in JSON austauschen, leichten Anschluss zum Semantischen Web finden und reibungsloser zusammenarbeiten, indem sie global eindeutige Bezeichnungen für logisch geordnete Begriffe verwenden.

Die Entwicklung begann 2010 und führte im Januar 2014 zur Verabschiedung zweier Dokumente über die erste Version.

Für die Industrie ist die Einbettung in das etablierte JSON interessant, weil sie so den zugehörigen Baukasten aus Parsern, Speichern bzw. Datenbanken, Programmiersprachen-Anbindungen, sowie Know-how u. ä. weiter verwenden könnte. Die Entwickler versuchten sich daran zu orientieren, wie JSON bisher zum Datenaustausch genutzt wird. Dadurch soll die Umstellung einer Software von JSON auf JSON-LD möglichst einfach sein. Hierzu kann es bereits ausreichen, einen ansonsten unveränderten JSON-Text mit einem sogenannten Kontext zu verknüpfen (siehe Abschnitt Technik und Grundbegriffe von JSON-LD).

Anwender von JSON-LD, welche hauptsächlich an herkömmlichem JSON interessiert sind, müssen RDF nicht verstehen. Gleichzeitig stellt das Datenmodell von JSON-LD eine Erweiterung des RDF-Modells dar.

Abgrenzung und Einordnung

{
  "@id": "Subjekt (IRI)",
  "Prädikat (IRI)": {
    "@id": "Objekt (IRI)"
  },
  "Prädikat (IRI)":
    Objekt (Literal),
  "Prädikat (IRI)": [
    Objekt, ...
  ]
}

Merkbild zur Einbettung der RDF-Tripel (farbig, kursiv) in JSON (schwarz)

JSON-LD verhält sich zu JSON ähnlich, wie sich RDFa, HTML Microdata bzw. ein Microformat jeweils zu HTML verhält: Programme, welche herkömmliches JSON erwarten (hier das Trägerformat), werden durch die Erweiterung zu JSON-LD praktisch nicht beeinträchtigt. Gleichzeitig gestattet es ebenso die Anreicherung um (maschinell interpretierbare) Bedeutung wie die anderen Verfahren (semantische Annotation).

Ein wesentlicher Unterschied besteht darin, dass JSON keine Markup-Sprache zur Präsentation von Inhalten wie HTML ist (und durch JSON-LD auch zu keiner wird): Eine dem Durchschnittsnutzer präsentable Darstellung des Inhalts müsste entweder erst gewonnen oder in einem anderen Format beigefügt werden. Dies hat neben der Kreation eines weiteren Formats für das Semantic Web vereinzelt zu Kritik geführt.

Der traditionelle Einsatzort von JSON ist jedoch nicht die Schnittstelle zwischen Mensch und Maschine, sondern die zwischen Maschinen untereinander. Die Trennung von (typographischem) Markup und semantischen Daten kann sogar eine Vereinfachung darstellen. JSON ersetzt hierbei XML abseits von XHTML. XML-Parser, RDF-Speicher und SPARQL-Maschinerie werden im Web-Umfeld zuweilen als „Overhead“ empfunden. Selbst handliche Formate aus dem RDF-Umfeld (wie Turtle) werden kaum als Basisformat in Web-Protokollen genutzt. JSON-LD soll Probleme lösen, die sich mit den anderen Formaten nicht lösen ließen.

Im Gegensatz zu anderen Serialisierungsformaten für Linked Data bzw. RDF, die Tripel-orientiert sind, bleibt JSON-LD auch in seiner flachen Vorzugsform Entität-zentriert: Alle ausgehenden Prädikatskanten des Graphen sind nach dem RDF-Subjekt gruppiert und alle RDF-Objekte nach Subjekt und Prädikat.

Gemeinsam mit TriG und N-Quads, sowie im Unterschied zu Turtle unterstützt JSON-LD mehrere (benannte) Graphen (RDF datasets). Im Gegensatz zu N-Triples und N-Quads, sowie gemeinsam mit Turtle ist es nicht auf eine flache Tupel-Repräsentation festgelegt. Anders als RDFa bzw. RDF/XML ist es nicht (X)HTML bzw. nicht XML-basiert.

JSON-LD beinhaltet (gegenüber JSON) eine Standardkonvention, um mittels IRIs (externe) Referenzen bzw. einfache Links darzustellen (ähnlich Erweiterungen wie JSON Reference, jedoch ohne die Interpretation des Fragmentbezeichners als JSON Pointer; JSON-LD folgt hier RDF-Gepflogenheiten). Außerdem kann es standardisiert Datentypen und Schema-Informationen aus dem RDF-Umfeld einbinden. (Anders als JSON Schema setzt es dabei nicht auf gesonderte bzw. JSON-spezifische Verfahren. Eine Prüfung mittels JSON Schema ist jedoch nicht ausgeschlossen.)

Zwar stellt JSON-LD selbst keine eigene Sprache für (HTML-freie) Hypertext- bzw. HTTP-Anwendungen (im REST-Stil) zur Verfügung (wie etwa JSON HAL oder JSON Hyper-Schema). Eine solche ist jedoch über entsprechende Vokabulare zur Dienst- bzw. Schnittstellenbeschreibung einbindbar. Siehe auch: Abschnitt Im Bereich der Web-APIs.

JSON-LD ist nicht kompatibel mit (dem älteren) RDF/JSON. Siehe auch: Abschnitt Vorgänger und Alternativen.

Syntax

Bezüglich der Syntax von JSON gilt:

Jeder JSON-LD-Text ist ein gültiger JSON-Text (nach RFC 4627).

Welche JSON-Texte umgekehrt auch gültiges JSON-LD darstellen, ist Gegenstand hauptsächlich des ersten Dokuments. Ein JSON-LD-Text muss u. a.

• ein JSON-Objekt sein oder
• ein JSON-Array aus solchen Objekten

(während neuere Fassungen von JSON bzw. JSON-Parser hier auch andere JSON-Werte erlauben.)

Alle Namen bzw. Schlüssel der Name-Wert-Paare müssen pro Objekt eindeutig sein (was bei JSON nach IETF nur so sein sollte und nach ECMA von der Auslegung abhängt). Außerdem muss auf die leere Zeichenkette als Name verzichtet werden, weil nicht alle JSON-Implementierungen diese handhaben können.

Alle weiteren Syntax-Elemente von JSON-LD werden über spezielle JSON-Strings realisiert (sogenannte Schlüsselwörter), die mit dem Zeichen „@“ beginnen und von denen es bisher dreizehn gibt (@context, @id, @value, @language, @type, @container, @list, @set, @reverse, @index, @base, @vocab, @graph). Im Hinblick auf spätere Erweiterungen wird empfohlen, andere Namen mit diesem Anfang u. a. als JSON-Name (bzw. -Schlüssel) zu vermeiden. Solche haben aber bis dahin keine spezielle Bedeutung.

Eine besondere Bedeutung kommt dem „:“ in Zeichenketten an bestimmten Stellen zu (wodurch sie kontextabhängig als kompakte IRIs oder als absolute IRIs interpretiert werden können, solange eine benutzerdefinierte Definition für die Zeichenkette als Ganzes dies nicht außer Kraft setzt).

Grundsätzlich spielt die Reihenfolge der Paare keine Rolle. Das spezielle Paar mit dem Namen „@context“ sollte am Anfang stehen, wenn man in Zukunft auch effizientere Datenstrom-Parser unterstützen möchte (welche eine Expansion so bereits während des Lesens durchführen könnten).

Die darauf basierende Grammatik umfasst verschiedene Typen von JSON-Objekten (node object, value object, list object, set object, language map, index map und context definition).

Die grundlegenden und fortgeschrittenen Konzepte von JSON-LD werden in nicht normativen Abschnitten anhand von Beispielen eingeführt. Die formalste Definition besteht aus über achtzig normativen Sätzen in englischer Sprache. Formalismen wie EBNF oder Syntaxdiagramme kommen nicht zur Anwendung. Es wird keine Sprache von Grund auf neu entworfen. JSON-LD bezieht sich auf die Grammatiken der IETF aus RFC 4627 (JSON), RFC 3987 (IRIs), BCP47 alias RFC 5646 (Sprachkennzeichen, language tags, siehe auch: ISO 639).

Ausgangspunkt und Grundlagen

Bei der maschinellen Interpretation von Daten, hier im JSON-Format, werden grundlegende Fragen der Bedeutungswissenschaft berührt. Menschen können diese nachvollziehen, wenn man hierzu Zeichenketten präsentiert, mit denen die meisten Leser keine Bedeutung verbinden können (wie die Wörter einer fremden Sprache).

{
  "xfvhgr": "bzmxmhfg",
  "ozwqrsmm": "1879-03-14"
}

Selbst wer das JSON-Format lesen kann, wird hier nur dessen Elemente erkennen, wie die Paare aus Namen und Werten. Eine inhaltliche Bedeutung oder gar Aussage kann er damit nicht verbinden.

Einer Maschine ginge es (stellvertretend für ihren Programmierer) dabei zunächst nicht viel anders: Ohne (einem maschinenlesbaren) „Wörterbuch“ oder „Lexikon“ mit passenden Einträgen ist eine Deutung technisch offenbar schwer erklärbar. (Bei der Kommunikation von Maschinen wäre weiter anzunehmen, dass die Teilnehmer sich in jeder Situation auf dasselbe Wörterbuch verständigt hätten, siehe auch: Kontextualisierung und Kontext. Außerdem wäre ein primitives Basisvokabular vorauszusetzen, dessen Bedeutung bei den Teilnehmern (durch Konstruktion, Evolution oder Sozialisation auf niederer oder kognitiver Ebene) bereits verankert ist.)

Bezeichner, mit denen nicht zumindest die meisten Softwareentwickler etwas verbinden können, sind zwar untypisch. (Häufig verwendet werden Lexeme des Englischen.) Dennoch gibt es auch bei verständlichen bzw. selbstsprechenden Bezeichnern oft noch mehrere Alternativen für „dasselbe“ (Synonymie) und Raum für Fehlinterpretationen aufgrund von Mehrdeutigkeiten (siehe auch: Homonym bzw. Polysemie, sowie Disambiguierung).

Eine technische Lösung besteht u. a. darin, möglichst nur noch global eindeutige Bezeichner zu verwenden (hier: IRIs) bzw. alle anderen in solche zu übersetzen. Ein Rahmenwerk hierzu bietet RDF bereits. Ein Verfahren, dies in JSON nutzen zu können, wurde durch JSON-LD nun im technischen Detail normiert.

Von JSON zu JSON-LD

JSON ist zunehmend in den APIs verbreiteter Webservices anzutreffen, wie denen von Google, Twitter, Facebook und vielen anderen.

JSON-Objekte bestehen aus Paaren von Namen und Werten. Dabei wird oft dieselbe Information – wie ein Geburtsdatum – durch unterschiedliche Namen wie etwa „born“, „born_on“, „dateOfBirth“, „DOB“ oder „дата рождения“ angesprochen. Bei der Zusammenführung durch einen übergreifenden Dienst (z. B. im Rahmen eines Semantic Mashups) fehlt ein Verzeichnis oder Wörterbuch, wie eine bestimmte Information in JSON-Nachrichten bzw. -Dokumenten aus den verschiedenen Quellen identifizierbar wäre.

Zwar könnte jeder, der mit mehreren Quellen arbeitet, für sich ein solches Verzeichnis erstellen, pflegen und fest mit seiner Software verbinden. Es wäre jedoch praktischer, wenn alle Datenlieferanten ihre JSON-Daten explizit mit einer maschinenlesbaren „Interpretationshilfe“ (ebenfalls in JSON) verknüpfen würden (Selbstbeschreibung). Auch wenn diese Zusatzinformation nicht von den Datenquellen stammt oder nur eine einzige Quelle zur Disposition stünde, müsste sie bei der Verarbeitung von JSON-Daten irgendwie eingebracht werden können.

Technik und Grundbegriffe von JSON-LD

In JSON-LD kann diese Hilfe bei der Deutung nun durch den speziellen Namen bzw. das Schlüsselwort @context geleistet werden:

{
  "@context": {
    "born": "http://schema.org/birthDate"
  },
  "born": "1879-03-14"
}

Dies sagt einem Computerprogramm (welches diesen Text als JSON parst und als JSON-LD interpretiert), dass der Wert mit dem Namen „born“ verbindlich im Sinne des „birthDate“ aus dem Schema.org-Vokabular zu verstehen ist (also als Kalenderdatum der Geburt einer Person). Für eine herkömmliche JSON-Anwendung, welche den Kontext nicht beachtet, ändert sich praktisch nichts. Sie verwendet weiterhin ihre fest eingebaute Interpretation für diese Datenquelle.

Zu weiteren Möglichkeiten, JSON-Daten in einen solchen Kontext zu stellen (Kontextualisierung), siehe auch Abschnitt Alternative Kontextualisierung.

An der Interpretation ändert sich für eine JSON-LD-Anwendung auch nichts, wenn man durchgängig den Term „born“ durch „birthdate“ ersetzen würde, weil er weiter zum selben IRI von Schema.org übersetzt wird bzw. „expandiert“.

Die Bedeutung eines solchen Dokuments wird deutlicher in der sogenannten expandierten (und hier zusätzlich flachen) Form, welche eine kontextunabhängige Verarbeitung gestattet (siehe auch: Abschnitt Algorithmen und Formen).

[
  {
    "@id": "_:b0",
    "http://schema.org/birthDate": [
      {
        "@value": "1879-03-14"
      }
    ]
  }
]

Hierbei wurden alle im Kontext definierten Namen wie „born“ zu einem absoluten IRI expandiert (und außerdem alle Werte bzw. Literale durch ein explizites Wert-Objekt mit dem Schlüsselwort @value ersetzt, alle einzelnen Literale und Knoten-Objekte zu (einelementigen) JSON-Arrays vereinheitlicht, sowie alle Knoten-Objekte ohne @id-Element mit einer lokalen ID versehen; siehe auch: Abschnitt Algorithmen und Formen). In dieser Form ließen sich auch Daten, die ursprünglich in unterschiedlichen Kontexten standen, einheitlich verarbeiten, ohne dass es zu Fehlinterpretationen käme.

Der in diesem Dokument enthaltene RDF-Graph aus zwei Knoten und einer Kante macht in etwa die Aussage: „Jemand (oder etwas) (mit der dokument-lokalen ID ‚_:b0‘) wurde (im Sinne von Schema.org) am 14. März 1879 geboren.“

Anonyme und untypisierte Knoten sind manchmal nicht ausreichend. Möglich sind mittels IRI global eindeutig benannte und (mittels Schlüsselwort „@type“) typisierte Entitäten bzw. Literale. Im Folgenden wird einer Person (im Sinne von FOAF) „Albert Einstein“ (im Sinne der DBpedia) ein Geburtsdatum (im Sinne von Schema.org und in der Schreibweise nach XML Schema) zugeschrieben.

{
  "@context": {
    "Person": "http://xmlns.com/foaf/0.1/Person",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "born": {
       "@id": "http://schema.org/birthDate",
       "@type": "xsd:date"
    },
  },
  "@id": "http://dbpedia.org/resource/Albert_Einstein",
  "@type": "Person",
  "born": "1879-03-14"
}

„xsd:date“ ist ein Beispiel für einen kompakten IRI, der hier zur Abkürzung von

http://www.w3.org/2001/XMLSchema#date

dient. Er besteht aus einem Term vor dem Doppelpunkt (Präfix-Term), der qua Kontext zu einem absoluten IRI expandieren muss, und dem Rest danach (Suffix), der unverändert daran angehängt wird. (Beachtenswert ist hierbei: Wenn das Präfix undefiniert ist, dann ist der Ausdruck wegen des Doppelpunktes bereits ein absoluter IRI.)

Ontologien werden normalerweise nicht unbegründet gemischt. Generell wird zur Sparsamkeit geraten. (Für manche Anwendungen oder Anwendungsbereiche (soziale Netzwerke, Bibliotheken, Bezahlsysteme usw.) werden extra welche entworfen.) Die durchgängige Verwendung eines einzelnen bzw. eines Hauptvokabulars lässt sich mit dem Schlüsselwort @vocab abkürzen. Alle Terme, die nicht anders definiert sind, werden dann aus diesem stammend interpretiert (Default-Präfix).

{
  "@context": {
    "@vocab": "http://schema.org/"
  },
  "birthDate": "1879-03-14"
}

Dies hat jedoch die Nebenwirkung, dass nun alle Terme, die im Kontext nicht explizit „null“ definiert sind, als Term aus diesem Vokabular aufgefasst werden. Ohne „@vocab“ würden die JSON-Werte von Termen ohne explizite Definition im Kontext hingegen in der JSON-LD-Sicht auf die Daten ausgeblendet werden.

JSON-LD gestattet sogenanntes Schlüsselwort-Aliasing: Ein Term kann auch zu einem Schlüsselwort wie „@type“ oder „@id“ expandieren (nicht jedoch zu „@context“). Verwendet ein Web-Service z. B. bereits den Namen „is_a“ zur Typisierung und „oid“ zur Identifizierung der Objekte (durch JSON-Strings, keine Zahlen), kann dies folgendermaßen explizit bzw. deutlich gemacht werden:

{
  "@context": {
    "Person": "http://xmlns.com/foaf/0.1/Person",
    "oid": "@id",
    "is_a": "@type"
  },
  "oid": "http://de.wikipedia.org/wiki/Albert_Einstein",
  "is_a": "Person"
}

JSON-Anwendungen, die dem Kontext keine Beachtung schenken, blieben davon wieder unberührt.

Nicht demonstriert wurden u. a. Mittel zur Sprachmarkierung und Mehrsprachigkeit von Zeichenketten, Listen (Container), Indexierung, benannte Graphen, relative IRIs und Basis-IRI, umgekehrte Eigenschaften.

Alternative Kontextualisierung

Der Kontext muss nicht direkt eingebettet, sondern kann auch per IRI referenziert werden:

{
  "@context": "http://example.com/person.jsonld",
  "born": "1879-03-14"
}

Würde man den Inhalt des ersten Beispiels (bis auf die vorletzte Zeile) in einer Datei namens „person.jsonld“ ablegen und unter dieser URL bereitstellen, führte dies zur selben Interpretation.

Entscheidend für die reibungslose Funktion ist, dass die URL tatsächlich zu einem Kontext gemäß JSON-LD führt, dieser also idealerweise per HTTP im JSON-LD-Format ladbar ist (oder zumindest einmal war).

Alternativ kann der Kontext auch außerhalb des eigentlichen JSON-Textes hergestellt werden.

Speziell vorgesehen ist dies durch den Link-Header in einer HTTP-Nachricht (mit spezieller Link-Relation aus dem JSON-LD-Namensraum). In die eigentlichen Applikationsdaten bräuchte so nicht eingegriffen zu werden, was die Migration erleichtern kann. Die contextURL aus dem Link-Header wird nur beachtet bei einem Inhaltstyp „application/[...+]json“ ungleich „application/ld+json“. Mehr dazu im Abschnitt Anforderung von JSON-LD.

Des Weiteren bietet die Programmierschnittstelle dazu einen optionalen Parameter (option expandContext, siehe: Abschnitt API).

Ein Kontext kann in jedem JSON-Objekt (außer in Kontext-Definitionen selbst) vorkommen, nicht nur im äußeren. Nicht weiter erläutert wurden hier u. a. die Kombination bzw. Akkumulation von Kontexten durch Schachtelung in der JSON-Struktur, sowie durch Reihung in Form eines JSON-Arrays. Außerdem gibt es leere Kontexte, um eine Kombinationskette zu unterbrechen.

Algorithmen und Formen

JSON-LD Processing Algorithms and API ist die andere der beiden Empfehlung des W3C, die für die erste Version von JSON-LD zusammen verabschiedet wurden. Sie behandelt nützliche Umformungen. Erst durch diesen Teil wird die Interpretation bzw. Bedeutung eines JSON-LD-Textes formal bzw. durch Rechenvorschriften erklärt, indem u. a. auch so der Bezug zur abstrakten Syntax von RDF hergestellt wird.

JSON-LD gestattet es, dieselben verlinkten Daten (RDF-Graph) in mehr als einer Form darzustellen. Die bevorzugte Form hängt dabei im Allgemeinen vom Anwendungsfall ab, wie Verarbeiter (Mensch oder Maschine), möglichst redundanzarme Übertragung bzw. Speicherung, möglichst einfache Verarbeitung, u. a.

Zur Wandlung in besonders interessante Formen definiert diese Empfehlung Rechenverfahren

• zur Expansion (expansion), die zur expandierten (expanded) Form führt
• zur Verdichtung (compaction), die zur kompakten oder verdichteten (compacted) Form führt
• zum Verflachen (flattening), was zur flachen oder verflachten (flattened) Form führt

Die wiederholte Anwendung einer Umformung (soweit möglich) verändert das Ergebnis nicht mehr nennenswert (Vereinheitlichung). Diese Algorithmen sind zudem normativ! Tatsächlich werden die Formen erst durch die Algorithmen vollständig definiert bzw. normiert. Sonstige Aussagen über die Formen sind entweder nicht normativ, nicht vollständig oder aus den Algorithmen abgeleitet (bzw. abzuleiten). Des Weiteren ergibt sich daraus eine Einschränkung bezüglich gültiger Eingaben: Ein JSON-Text, der bei der Expansion ergebnislos bzw. als fehlerbehaftet abgewiesen werden würde, besitzt eigentlich keine maschinell verwertbare Interpretation als JSON-LD.

Die Expansion ist die Transformation, an der die meisten Anwendungen interessiert sein werden, welche den Mehrwert von JSON-LD gegenüber JSON schöpfen wollen (und dazu nicht durchgängig eine expandierte Form verwenden, s. u.). Beachtenswert ist hierbei, dass alle Name/Wert-Paare, die keine Interpretation im Modell von JSON-LD finden, dabei entfernt werden. (Soweit es die API-Methoden betrifft (s. u.), ist die Expansion als interner Zwischenschritt außerdem unumgänglich.)

Die Verdichtung findet zu einem gegebenen Kontext eine möglichst kompakte Form in diesem Kontext, welche (unter diesem) expandiert wiederum gleichbedeutend (aber nicht notwendig genau gleich) mit der Eingabe ist. Expansion und Verdichtung sind so bis zu einem gewissen Grade Umkehrungen zueinander: Die Expansion macht die Daten kontextunabhängig. Die Verdichtung kontextabhängig.

Bei der Verdichtung kann optional die Umwandlung von einelementigen Arrays in ihr einziges Element unterdrückt werden (option compactArrays).

Das Verflachen versieht (anonyme) Knoten-Objekte ohne „@id“ mit einer dokumentweit eindeutigen (blank node identifier), verschmilzt solche mit gleicher „@id“ und entfernt (tiefergehende) Schachtelungen. Es ergibt sich ein JSON-Array der RDF-Subjekte mit allen jeweils ausgehenden Prädikatskanten (mindestens eine, wobei eine @type-Kante mitzählt). Dort wo sie auch als RDF-Objekte auftreten, bleibt nur eine ansonsten eigenschaftslose Referenz mit der jeweiligen „@id“ zurück. Dies gilt auch für (untypisierte) Knotenobjekte, die nur in der Objekt-Rolle vorkommen.

In dieser Form reichen drei bis vier ineinander geschachtelte Schleifen aus, um alle enthaltenen RDF-Tripel aufzuzählen. (Siehe auch: Beispiel im Abschnitt API) Das „flach“ bezieht sich daher offenkundig (nur) auf eine feste bzw. maximale Rekursionstiefe: Die Kombination einer festen Zahl von iterativen Schleifen ist hinreichend.

Beim Verflachen kann durch Angabe eines (auch leeren) Kontextes optional eine leicht abgewandelte Verdichtung nachgeschaltet werden, die zu einer etwas bestimmteren Form führt.

Anwendungen, welche durchgängig die flache Form verwendeten (siehe auch: Abschnitt MIME-Typ-Parameter), kämen auch ganz ohne die Algorithmen aus.

Anwendungen wählen zur möglichst generischen Verarbeitung entweder die verflachte Form (ohne nachgeschaltete Verdichtung). Oder sie verdichten (zusätzlich) mit einem Kontext, der ihrem Zweck entgegenkommt. Letzteres hat den Vorteil, dass sich damit die Handhabung von absoluten IRIs weitgehend eliminieren lässt.

Beispiel zur Umformung

Die folgenden drei JSON-LD-Texte stehen in folgender Beziehung: links oben ein Quelltext (handgeschrieben oder von einer Applikation stammend); unten die expandierte und verflachte Form davon (ohne nachgeschaltete Verdichtung), hierbei wurde ein anonymer Knoten benannt und durch eine Referenz ersetzt (sowie das Paar mit dem undefinierten Term „comment“ entfernt); rechts oben eine verdichtete Form wiederum davon in einem abgewandelten Kontext (u. a. ohne Typ-Definitionen, sowie mit zusätzlichen oder anders benannten IRI-Präfixen und deutschsprachigen Termen und Schlüsselwort-Aliassen).

{ "@context": { "dbpedia": "http://dbpedia.org/resource/", "dbp-owl": "http://dbpedia.org/ontology/", "geo": "http://www.w3.org/2003/01/geo/wgs84_pos#", "bornOn": { "@id": "dbp-owl:birthDate", "@type": "http://www.w3.org/2001/XMLSchema#date" }, "bornIn": "dbp-owl:birthPlace" }, "@id": "dbpedia:Albert_Einstein", "bornOn": "1879-03-14", "bornIn": { "geo:alt": "482", "comment": "drop me" } }

{ "@context": { "enti": "http://dbpedia.org/resource/", "onto": "http://dbpedia.org/ontology/", "Geburtsdatum": "onto:birthDate", "Geburtsort": "onto:birthPlace", "Ortshöhe": "http://www.w3.org/2003/01/geo/wgs84_pos#alt", "xsd": "http://www.w3.org/2001/XMLSchema#", "JJJJ-MM-TT": "xsd:date", "Typ": "@type" }, "@graph": [ { "@id": "_:b0", "Ortshöhe": "482" }, { "@id": "enti:Albert_Einstein", "Geburtsdatum": { "Typ": "JJJJ-MM-TT", "@value": "1879-03-14" }, "Geburtsort": { "@id": "_:b0" } } ] }

[ { "@id": "_:b0", "http://www.w3.org/2003/01/geo/wgs84_pos#alt": [ { "@value": "482" } ] }, { "@id": "http://dbpedia.org/resource/Albert_Einstein", "http://dbpedia.org/ontology/birthDate": [ { "@type": "http://www.w3.org/2001/XMLSchema#date", "@value": "1879-03-14" } ], "http://dbpedia.org/ontology/birthPlace": [ { "@id": "_:b0" } ] } ]

Durch das @graph-Element können sich hier mehrere Knoten-Objekte denselben Kontext teilen.

Unabhängig von der Form besagt der darin enthaltene Graph, wann Albert Einstein geboren wäre und auf welchem Höhenmeter (WGS84) sein Geburtsort läge. Oder in Tripel-Notation (N-Triples, siehe auch: Turtle):

<http://dbpedia.org/resource/Albert_Einstein> <http://dbpedia.org/ontology/birthDate> "1879-03-14"^^<http://www.w3.org/2001/XMLSchema#date> .
<http://dbpedia.org/resource/Albert_Einstein> <http://dbpedia.org/ontology/birthPlace> _:b0 .
_:b0 <http://www.w3.org/2003/01/geo/wgs84_pos#alt> "482" .

Hilfsverfahren

Als interne Hilfsverfahren treten u. a. auf

• Kontextverarbeitung (Context Processing Algorithm): Kontexte können kombiniert und per IRI referenziert werden. Ergebnis dieser Operationen ist jeweils wieder ein Kontext (Akkumulation). Dabei müssen u. U. zyklische Bezüge abgewiesen werden.

• Erzeugung einer Term-Definition (Create Term Definition): Diese tritt immer auf, wenn eine Definition aus einem Kontext in den (aktiven) Ergebniskontext einfließt. Auch hierbei werden zirkelhafte Bezüge aufgedeckt und zurückgewiesen.

• Erzeugung einer Zugriffsstruktur (Node Map Generation), welche nach den Subjekten gruppiert und Knoten-Objekte mit gleicher @id verschmilzt (siehe Verflachen).

Bisher u. a. nicht erwähnt: IRI Expansion, Value Expansion, Inverse Context Creation, IRI Compaction, Term Selection, Value Compaction, Generate Blank Node Identifier.

Diese Verfahren sind jedoch nicht für das API (s. u.) empfohlen, wenngleich sie (in äquivalenter Form) kaum verzichtbarer Bestandteil einer Implementierung desselben sind.

Bezug zu RDF

Daneben ist die Serialisierung vom, sowie die Deserialisierung zum abstrakten RDF-Modell (benannte Mengen von Tripeln bzw. Graph-Mengen) definiert und damit indirekt die Wandlung zu bzw. von jeder (anderen) konkreten RDF-Syntax. Des Weiteren wird darüber die Verbindung zur Semantik von RDF hergestellt. Dies beinhaltet u. a. die Korrespondenz der primitiven JSON-Typen und -Literale mit denjenigen von XML Schema und diejenige der JSON-LD-Listen mit denen von RDF-Schema. (Nicht erwähnt hierbei u. a.: Sprachkennzeichnung von Strings).

MIME-Typ-Parameter

Der MIME-Typ von JSON-LD sieht einen optionalen Parameter „profile“ vor. Sein Wert (ein IRI aus dem JSON-LD-Namensraum) korrespondiert mit den drei genannten Formen.

Beispiel eines MIME Types im HTTP-Accept-Header:

Accept: application/ld+json#compacted

Damit kann ggf. verhindert werden, dass Transformationen unnötig mehrfach ausgeführt werden bzw. in falscher Erwartung unterbleiben. Außerdem kann darüber der Ort der Verarbeitung ausgehandelt werden (beim Sender bzw. Empfänger).

API

Schließlich wird die Programmierschnittstelle eines JSON-LD-Prozessors spezifiziert (JsonLdProcessor), jedoch nur nicht-normativ. Damit stünde ein einheitlicher Zugang zu den drei Transformations-Verfahren (Methoden: compact, expand, flatten) in Programmierumgebungen bereit, vorwiegend auch für das im Web-Umfeld verbreitete ECMAScript. Die Schnittstelle setzt auf der Promise-Abstraktion zur asynchronen Programmierung auf. Die Flatten- und Compact-Methoden aus dem API beinhalten Expansion (und IRI-Dereferenzierung).

Um seine Aufgabe zu erledigen, muss der Prozessor ggf. (rekursiv) externe Kontexte, die per IRI bzw. URL referenziert wurden, (von entfernter Seite, remote) aus dem Internet oder lokal aus einem Cache laden. Außerdem sollen meist die JSON-LD-Daten hinter IRIs geladen werden (Dereferenzierung). In diese Ladeprozedur kann über die definierte Schnittstelle eingegriffen werden (JsonLdOptions documentLoader).

In einer Umgebung, in der dieses API verfügbar ist (und anderes), würde das folgende CoffeeScript das Geburtsdatum von Albert Einstein laut DBpedia ausgeben (genauer: alle solchen verfügbaren, soweit kein Fehler auftritt).

AlbertsIRI = "http://dbpedia.org/data/Albert_Einstein.jsonld"
# bzw. "http://dbpedia.org/resource/Albert_Einstein", siehe Anmerkung

dbpprop = "http://dbpedia.org/property/"
dbpprop$birthDate = dbpprop + "birthDate"

expanded = (new JsonLdProcessor).expand AlbertsIRI
expanded.then (subjects) ->
  for subject in subjects
    for object in subject[dbpprop$birthDate] ? []
      console.log object['@value']
# Fehlerbehandlung weggelassen

Programmier-Schnittstellen zur Konvertierung zwischen JSON-LD und dem RDF-Modell sind zwar nicht Bestandteil des empfohlenen APIs. Der Entwicklungsprozess beim W3C hat aber auch dafür Beispiel-Implementierungen hervorgebracht (toRDF, fromRDF). Außerdem wandeln RDF-Frameworks bzw. -Programmbibliotheken auf dieser Grundlage zwischen ihrer jeweiligen RDF-Abstraktion und einer JSON-LD-Form. Siehe auch Abschnitt Programmbibliotheken und Werkzeuge.

Verarbeitung von JSON-LD

Unabhängig von der Quelle eines JSON-LD-Textes: Dieselben Daten können als JSON-LD (in kompakter Form) interpretiert und vor der Verarbeitung expandiert oder nur als einfaches JSON geparst werden (wie vor einer Migration von JSON nach JSON-LD). Verschiedene Module können dies auch unterschiedlich handhaben.

Beispiel aus einer JavaScript-Umgebung (z. B. Webbrowser):

// JSON-Text in der Variablen data

// Modul A (ursprüngliche App ohne Bewusstsein für Linked Data)
var legacy = JSON.parse( data )

// Modul B (spätere Erweiterung fürs Semantische Web)
var advanced = (new JsonLdProcessor).expand( JSON.parse( data ) )

Einbettung in HTML

Zur Einbettung von JSON-LD in HTML wird das Script-Element empfohlen:

<script type="application/ld+json" id="json-ld-data">
  {
    "@context": ...
    "@id": ...
    "createdAt": ...
    "author": ...
  }
</script>

Dadurch kann eine Anwendung über das DOM darauf zugreifen, u. a. also auch ein JavaScript im Webbrowser:

// DOM
var data = document.getElementById( 'json-ld-data' ).textContent

// jQuery
var data = $( '#json-ld-data' ).text()

Mögliche Anwendungen dafür sind zunächst dieselben wie auch für RDFa, HTML Microdata u. a. Der Unterschied besteht hauptsächlich darin, wie die semantischen Daten technisch extrahiert werden. Die Bindung an HTML-Attribute und die Verzahnung mit dessen Elementstruktur entfällt hierbei. Nachteilig ist das hingegen in Umgebungen, die bisher allein mit (X)HTML-Werkzeugen auskamen (da sie nun auch JSON verarbeiten müssten).

Anwendungsbeispiele sind klassische Metadaten über das Dokument bis zu einer maschinenlesbaren Repräsentation des vollständigen Textinhalts (der parallel natürlichsprachlich formuliert für die Rezeption durch Menschen bestimmt ist). Dies könnte eine automatisch erstellte Auftragsbestätigung sein. Auch die nachträgliche Generierung oder Anreicherung eines solchen Inhalts abhängig von Vorgaben des Rezipienten wäre so noch möglich. Ebenso könnte ein persönlicher Assistent bzw. Software-Agent autonom darauf reagieren oder Aktionen anbieten. (Siehe auch: Abschnitt Anwendungen und Anwender)

Anforderung von JSON-LD

Ein JSON-LD-Kontext oder Daten in diesem Format werden über HTTP vorzugsweise mit dem zugehörigen MIME-Typ angefordert. (Dabei kann es zu Verhandlungen über den Inhaltstyp und Weiterleitungen kommen (Statuscode 3xx, Location-Header).)

Probeweise Anforderung zum Beispiel mit cURL (in der Bash mit einer URL in der Variablen $URL):

  curl -i -L -H "Accept: application/ld+json" "$URL"

Im positiven Fall ist die (letzte) Antwort vom entsprechenden Inhaltstyp und enthält verwertbares JSON-LD.

(Anmerkung zum MIME-Typ selbst: application/ld+json basiert (im Sinne von RFC 6838) auf einem Structured Syntax (Name) Suffix „+json“, das in RFC 6839 registriert ist.)

Besonders im Umfeld von Linked Data ist bei Inhalt vom Typ application/json Vorsicht geboten, weil dieser in Wirklichkeit u. a. auch vom inkompatiblen Format RDF/JSON sein kann, siehe auch Abschnitt Vorgänger und Alternativen.

Dienstnehmer sollten gegenüber dem Erbringer des Dienstes (1) möglichst eine klare Präferenz für „ld+json“ zum Ausdruck bringen (ggf. per q-Parameter im Accept-Header) und (2) bei allen anderen „json“-Typen auf eine contextURL im Link-Header achten (siehe auch: Abschnitt Alternative Kontextualisierung). Ansonsten riskieren sie, sonstige JSON-Daten zu erhalten (die in der JSON-LD-Sicht zu einer leeren oder andersartig unerwarteten Tripelmenge expandieren), ohne dass dies (vom Standard-API) als Fehler signalisiert werden würde.

Für die reibungslose Kommunikation mit möglichst vielen Datenquellen kann daher eine benutzerdefinierte Ladeprozedur (custom document loader) erforderlich sein, siehe Abschnitt API.

Generell unproblematisch(er) sind URLs, welche einen eindeutigen Hinweis auf das gewünschte Format bereits enthalten (etwa durch die Endung „.jsonld“ oder durch einen entsprechenden Datentyp- bzw. Format-Parameter). Dieses Verfahren ist zum Bezug eines JSON-LD-Kontextes meist ausreichend. (Bei der Anforderung von Linked Data zu einer (per URL referenzierten) Entität widerspräche es jedoch Grundsätzen aus diesem Umfeld. Beispielsweise müsste einer Dienstbeschreibung zur jeweiligen Quelle erst entnommen werden, wie diese URL zu bilden wäre. Generische bzw. anpassungsfähige Verfahren werden daher bevorzugt.)

Programmbibliotheken und Werkzeuge

Implementierungen des empfohlenen APIs sowie zusätzlicher Funktionen zur Verarbeitung von JSON-LD gibt es bereits für mehrere Programmiersprachen (Stand Juni 2014).

Die folgenden gelten als konform zur Spezifikation, basierend auf den Test-Reports zur zugehörigen Testsammlung:

• für JavaScript von Digital Bazaar, Inc. (Browser, Node.js, Kommandozeile, Web-App)
• für Python PyLD von Digital Bazaar, Inc.
• für PHP von Digital Bazaar, Inc., von Markus Lanthaler
• für Ruby innerhalb von Ruby RDF
• für Java von jsonld-java auf Github
• für C# innerhalb von NuGet

Wandlung zwischen JSON-LD und anderen Formaten:

• von RDFa: (u. a. auch nach JSON-LD) mittels RDFa 1.1 Distiller and Parser von Ivan Herman (seit November 2011)
• RDF Translator (RDFLib-basiert)
• über ein Plugin innerhalb von RDFLib bei Github
• in Ruby als Erweiterung zu RDF.rb im Ruby RDF Project

Vorgänger und Alternativen

Weder ist JSON-LD aus dem Nichts entstanden, noch ist die gewählte Struktur zur Repräsentation von Linked Data im Allgemeinen und der Serialisierung von RDF im Besonderen die einzig mögliche.

Veranschaulicht man die Serialisierungs-Struktur von JSON-LD bezüglich RDF-Tripeln S(ubjekt), P(rädikat), O(bjekt) folgendermaßen (flache Form)

 [ { "@id": "S", "P": [ O ] } ]

dann stellt sich die von RDF/JSON so dar:

 { "S": { "P": [ O ] } }

wobei für Objekte O per „type“ zwischen Literalen und Ressourcen unterschieden wird:

 { "type": "literal", "value": ..., "datatype": … }
 { "type": "uri",   "value": … }

(„[ O ]“ symbolisiert hierbei die Gruppierung von Objekten mit gleichem Subjekt und Prädikat in einem JSON-Array.)

RDF/JSON (vereinzelt auch: Talis RDF/JSON) wurde vom W3C zugunsten von JSON-LD nicht weiter verfolgt.

Auch anzutreffen ist das flache Tripel-Schema

 [ { "s": {"uri": S}, "p": "P", "o": O } ]

Fundamentale Konzepte sind über die Arbeit an RDFj in LD-JSON eingeflossen, die teilweise aus dem Jahr 2004 stammt.

Über ein Dutzend weitere Ansätze, RDF-Tripel in JSON abzubilden, listet allein das W3C schon 2011 in seinem Wiki auf.

Alternativen im engeren Sinne wären (1) gültiges JSON und hätten (2) einen Bezug zu RDF. Serialisierungsformen von RDF bzw. Transportformen für Linked Data, die nicht nach JSON führen, werden hier nicht als Alternativen im engeren Sinne behandelt. (Siehe ggf. bei Linked Data, RDF.)

Zu den folgenden Formaten demonstriert die Empfehlung anhand von Beispielen, dass JSON-LD die darin enthaltenen semantischen Daten ausdrücken könne:

• Turtle
• RDFa
• HTML Microdata
• Mikroformate

Zu einigen davon gibt es zwar gesonderte JSON-Formen (die Überbleibsel des Quellformats enthalten). Als langfristige Alternative erscheinen sie so nur noch unter dem Aspekt der Kompatibilität.

Alternative: Microdata+JSON

HTML Microdata vom W3C ist erklärtermaßen mit RDF kompatibel und beinhaltet eine gesonderte Konvertierung nach JSON. Indirekt kann es daher als Alternative zu JSON-LD betrachtet werden. Die Verbindung mit einer Markup-Sprache ist jedoch gerade das, wovon JSON-LD vollkommen frei ist.

Schema:

 {"items": [
    { "id": "S", "properties": { "P": [ O ] } }
 ] }

Alternative: SPARQL-Anfrage-Ergebnis

Für das Ergebnis von SPARQL-Anfragen wurde eine JSON-Form normiert. Geht es nur um die Verarbeitung solcher Ergebnisse, stellt dies eine (beschränkte) Alternative dar.

Das Ergebnis von SELECT-Anfragen sind Variablen-Bindungen, keine gewöhnlichen Tripelmengen. CONSTRUCT-Anfragen liefern hingegen Tripelmengen. Für CONSTRUCT-Anfragen bindet beispielsweise Virtuoso die Variablen „s“, „p“ und „o“ (Vergegenständlichung). In keinem Fall entspricht das Muster dem von JSON-LD.

Allerdings können SPARQL-Endpunkte (wie die von Virtuoso) bei CONSTRUCT- und DESCRIBE-Anfragen die Tripelmenge (neben vielen anderen konkreten RDF-Syntaxen) auch schon in JSON-LD liefern. Eine Vergegenständlichung erübrigt sich hierbei.

Anwendungen und Anwender

Zu einigen frühen Anwendern, welche die Übernahme von JSON-LD in Produkte oder Dienste bis Juni 2014 zumindest angekündigt haben:

Bereits im Mai 2013 hat Google angekündigt, JSON-LD zusätzlich zu HTML Microdata in seinen Produkten zu unterstützen. Beispielsweise kann in HTML-E-Mails eingebettetes JSON-LD beim Eintreffen in der Mailbox extrahiert werden. Dem Empfänger werden die semantischen Daten so bei seiner personalisierten Suche verfügbar gemacht oder Eintragungen in den Terminkalender angeboten.

Auch Produkte von Microsoft können JSON-LD aus E-Mails lesen, um dem Empfänger darüber Dienste eines persönlichen Assistenten abhängig von Zeit und Aufenthaltsort anzubieten. Voraussetzung dafür ist, dass der Absender dazu (ebenso wie bei Google) das Vokabular von Schema.org verwendet.

DBpedia liefert (verlinkte) Daten, neben vielen anderen Formaten, auch in JSON-LD aus. Das dazu verwendete Virtuoso bietet in seiner Open Source Edition JSON-LD Serialisierung mindestens seit November 2011 an.

Schema.org bekennt sich seit Juni 2013 zu JSON-LD und gibt Beispiele parallel zu RDFa und Microdata auch in JSON-LD. Seit Mitte Juni 2014 wird außerdem ein JSON-LD-Kontext bereitgestellt. Wenig später zog auch FOAF gleich und stellt sogar die Ontology (RDF-Schema/OWL) direkt in JSON-LD zur Verfügung.

Die erste RDF-Version von WordNet (vorgestellt im April 2014) liefert neben anderen RDF-Formaten auch JSON-LD schon seit Beginn (mittels RDFLib).

Es ist zu erwarten, dass viele bestehende oder neue Angebote von Linked Data früher oder später auch in diesem Format erfolgen werden.

Im Bereich der Web-APIs

JSON wurde bis zur Entwicklung von JSON-LD als Mittel zur allgemeinen Diensterbringung (über JSON-basierte Web-APIs) genutzt. Der Transport von RDF-Daten oder das Wissensmanagement im Semantic Web (über die RDF-Technologien) an sich war nicht seine Domäne.

Wesentlich an der Entwicklung von JSON-LD Beteiligte sahen (nach eigenem Bekunden) den Wunsch nach besseren Web-APIs als Motivation für die Schaffung von JSON-LD, nicht das Semantic Web. Auf diesem Wege zu den JSON-basierten Web-Diensten (die sich durch die Nutzung der semantischen Technologien (mittels JSON-LD) fast zwangsläufig nahtlos in die „Linked Data Cloud“ integrieren) würde das Semantische Web jedoch schließlich Wirklichkeit werden.

Naheliegend ist die semantische Anreicherung der Nutz- bzw. Inhaltsdaten durch die Verwendung wohlbekannter und maßgeschneiderter Vokabulare für den jeweiligen Gegenstandsbereich (also für Produkt- und Dokumentbeschreibungen, Preisangaben, Angebote, Aufträge, Bezahlarten, Termine, Akteure usw.). Darüber hinaus ist aber auch der Einsatz zur Dienst- und Schnittstellenbeschreibung (API/service description) bereits Gegenstand von Forschung und Entwicklung.

Spätestens seit April 2012 wird JSON-LD im Zusammenhang mit dem REST-Stil für hypermedia-getriebene Webdienste (der nächsten Generation) diskutiert.

In Hydra (das seit Juni 2013 auch Gegenstand einer W3C Community Group ist) kommt JSON-LD auf folgenden Ebenen zum Einsatz: (1) in den Nachrichten (mittels des API-Vokabulars des jeweiligen Dienstes), (2) in der (semantischen) API-Beschreibung (mittels des Hydra-Vokabulars sowie anderer wohlbekannter) und (3) in der Beschreibung des Hydra-Schemas zur API-Beschreibung (mittels des Vokabulars von RDF-Schema). In dieser Konstellation würde JSON-LD an die Stelle des XML in Ansätzen wie WSDL (inklusive SAWSDL) und WADL bzw. des HTML+RDFa in SA-REST sowie an diejenige des Mikroformats in hRESTS und MicroWSMO treten. Zugleich modelliert es REST wie WADL und MicroWSMO.

Seit April 2014 gibt es neben Hydra ein weiteres (für JSON-LD ausgelegtes) Vokabular, welches Einstiegspunkte (EntryPoint, target) in Dienste bzw. Operationen (mit Ein- und Ausgabe-Parametern) beschreiben kann: schema.org v1.2 beinhaltet dazu (potentielle) Aktionen (Action, potentialAction) wie Anhören, Kaufen, Teilen, Kommentieren, Durchsuchen usw. Wie in Hydra können Eingabe-Elemente sogar an die Parameter von URL-Templates (nach RFC 6570) geknüpft werden. Diese Elemente (PropertyValueSpecification) orientieren sich am Input-Element von HTML5, womit die Umsetzung in entsprechende Bedienelemente für den Benutzer weitgehend erklärt ist. Auf diese Weise erhält das HTML-freie JSON (über JSON-LD) die Fähigkeiten eines interaktiven Hypermediums. Dienste wie Suchmaschinen können damit allein aus einer RDF-Graphdatenbank, Suchergebnisse unmittelbar mit (semantisch eingeordneten) Interaktionsangeboten (externer Anbieter) verbinden. Voraussetzung ist, wie bei Hydra, ein generischer Interpreter oder Client für die jeweilige Informations-Struktur, weil es im Gegensatz zu HTML sonst keine „Browser“ dafür gibt. Die Tripel in der Datenbank können freilich auch aus jedem anderen RDF-Serialisierungsformat stammen. Inserenten bzw. Websitebetreiber sind zwar auf RDF (und Schema.org) festgelegt, nicht jedoch unbedingt auf JSON-LD.

Ansätze auf der Grundlage von JSON-LD (und damit RDF) stehen neben solchen, die zunächst direkt auf JSON aufsetzen. Neuere Versionen der Activity Streams (und der zugehörigen Action Handlers) sehen jedoch bereits eine Verarbeitung als JSON-LD vor, indem sie zumindest einen (nicht-normativen) JSON-LD-Kontext beinhalten.

Generell können Spezifikationen, die auf JSON-LD und Hypermedia setzen, spätere Erweiterungen in die Vokabularschicht auslagern und relativ generische Anwendungsprogramme zur Laufzeit mit jeweils aktuellen Informationen zum API versorgen (wie über neue Aktionen bzw. Operationen und zugehörige Parameter und Rückgabewerte). Eine schwerfällige Abstimmung im Vorfeld oder nach Erweiterungen (durch den Informationsaustausch „außerhalb des Kanals“) soll damit weitgehend der Vergangenheit angehören.

Siehe auch

• Semantic Web Services
• Web Service Modeling Ontology

Weblinks

• json-ld.org – Seite für Entwickler mit Browser-Tool („Playground“) (englisch)
• JsonLD Playground von Markus Lanthaler – Alternativer Spielplatz in PHP (englisch)
• Artikel mit dem Tag JSON-LD bei semanticweb.com (englisch)

Einzelnachweise und Anmerkungen

V – D

Standards des World Wide Web Consortiums (W3C)