Dieser Artikel oder Abschnitt bedarf einer grundsätzlichen Überarbeitung. Näheres sollte auf derDiskussionsseite angegeben sein. Bitte hilf mit, ihn zuverbessern, und entferne anschließend diese Markierung.

JSON-LD
Dateiendung:	.jsonld
MIME-Type:	application/ld+json
Entwickelt von:	World Wide Web Consortium (W3C)
Aktuelle Version	1.0 (16. Januar 2014)
Art:	konkrete Syntax vonRDF
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)
json-ld.org

JSON-LD (Akronym vonenglisch für „JSON-basierteSerialisierung für verLinkteDaten“) bezeichnet Empfehlungen desW3C,weltweit verknüpfte Daten (nach demRDF-Modell) im schlankenJSON-Format einzubetten. Damit könnenWebservices undWebapplikationen, die ihreDaten bevorzugt in JSON austauschen, leichten Anschluss zumSemantischen Web finden undreibungsloser zusammenarbeiten, indem sieglobaleindeutige Bezeichnungen fürlogisch geordnete Begriffe verwenden.

Die Entwicklung begann 2010^[1] und führte im Januar 2014 zur Verabschiedung zweier Dokumente über die erste Version.^[2][3][4]

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

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

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

JSON-LD verhält sich zu JSON ähnlich, wie sichRDFa,HTML Microdata bzw. einMicroformat jeweils zuHTML 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 keineMarkup-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 dasSemantic Web vereinzelt zu Kritik geführt.^[8]

Der traditionelle Einsatzort von JSON ist jedoch nicht dieSchnittstelle zwischen Mensch und Maschine, sondern die zwischen Maschinen untereinander. Die Trennung von (typographischem) Markup und semantischen Daten kann sogar eine Vereinfachung darstellen. JSON ersetzt hierbeiXML abseits vonXHTML. XML-Parser,^[9]RDF-Speicher undSPARQL-Maschinerie^[10] werden im Web-Umfeld zuweilen als „Overhead“ empfunden. Selbst handliche Formate aus dem RDF-Umfeld (wieTurtle) 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.^[11]

Im Gegensatz zu anderenSerialisierungsformaten fürLinked Data bzw.RDF, dieTripel-orientiert sind, bleibt JSON-LD auch in seiner flachen VorzugsformEntität-zentriert:^[7] Alle ausgehenden Prädikatskanten des Graphen sind nach dem RDF-Subjekt gruppiert und alle RDF-Objekte nach Subjekt und Prädikat.^[12][13]

Gemeinsam mitTriG undN-Quads, sowie im Unterschied zuTurtle unterstützt JSON-LD mehrere (benannte) Graphen (RDF datasets).^[14] Im Gegensatz zuN-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 mittelsIRIs (externe) Referenzen bzw. einfache Links darzustellen (ähnlich Erweiterungen wie JSON Reference,^[15] jedoch ohne die Interpretation desFragmentbezeichners als JSON Pointer; JSON-LD folgt hier RDF-Gepflogenheiten^[16]). Außerdem kann es standardisiert Datentypen und Schema-Informationen aus dem RDF-Umfeld einbinden. (Anders alsJSON Schema^[17] setzt es dabei nicht auf gesonderte bzw. JSON-spezifische Verfahren. EinePrüfung mittels JSON Schema ist jedoch nicht ausgeschlossen.^[18])

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

JSON-LD ist nichtkompatibel mit (dem älteren) RDF/JSON. Siehe auch:AbschnittVorgänger und Alternativen.

Bezüglich derSyntax vonJSON gilt:

Welche JSON-Texte umgekehrt auch gültiges JSON-LD darstellen, ist Gegenstand hauptsächlich des ersten Dokuments.^[3] 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-Paaremüssenpro Objekt eindeutig sein (was bei JSON nach IETF nur so seinsollte 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 (sogenannteSchlü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 kompakteIRIs 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 effizientereDatenstrom-Parser unterstützen möchte (welche eine Expansion so bereits während des Lesens durchführen könnten).

Die darauf basierendeGrammatik 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 nichtnormativen Abschnitten anhand von Beispielen eingeführt. Die formalste Definition besteht aus über achtzig normativen Sätzen in englischer Sprache. Formalismen wieEBNF oderSyntaxdiagramme werden nicht angewendet. Es wird keine Sprache von Grund auf neu entworfen. JSON-LD bezieht sich auf die Grammatiken derIETF aus RFC 4627 (JSON),^[21] RFC 3987 (IRIs),^[22] BCP47 alias RFC 5646^[23] (Sprachkennzeichen, language tags, siehe auch:ISO 639).

Bei dermaschinellen Interpretation vonDaten, hier im JSON-Format, werden grundlegende Fragen derBedeutungswissenschaft berührt. Menschen können diese nachvollziehen, wenn man hierzuZeichenketten 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 dasJSON-Format lesen kann, wird hier nur dessen Elemente erkennen, wie die Paare aus Namen und Werten. Eine inhaltlicheBedeutung oder garAussage 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 eineDeutung technisch offenbar schwer erklärbar. (Bei derKommunikation von Maschinen wäre weiter anzunehmen, dass die Teilnehmer sich in jeder Situation auf dasselbe Wörterbuch verständigt hätten, siehe auch:Kontextualisierung undKontext. Außerdem wäre ein primitives Basisvokabular vorauszusetzen, dessen Bedeutung bei den Teilnehmern (durchKonstruktion,Evolution oderSozialisation auf niederer oderkognitiver Ebene) bereits verankert ist.)

Bezeichner, mit denen nicht zumindest die meistenSoftwareentwickler etwas verbinden können, sind zwar untypisch. (Häufig verwendet werdenLexeme 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 vonMehrdeutigkeiten (siehe auch:Homonym bzw.Polysemie, sowieDisambiguierung).

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 bietetRDF bereits. Ein Verfahren, dies in JSON nutzen zu können, wurde durch JSON-LD nun im technischen Detailnormiert.

JSON ist zunehmend in denAPIs verbreiteterWebservices anzutreffen, wie denen vonGoogle,Twitter,Facebook und vielen anderen.

JSON-Objekte bestehen aus Paaren von Namen^[24] 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 einesSemantic 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.

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

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

Dies sagt einemComputerprogramm (welches diesen Text als JSONparst und als JSON-LD interpretiert), dass der Wert mit dem Namen „born“ verbindlich im Sinne des „birthDate“ aus demSchema.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 auchAbschnittAlternative Kontextualisierung.

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

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

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

Hierbei wurden alle im Kontext definierten Namen wie „born“ zu einem absolutenIRI 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:AbschnittAlgorithmen 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-lokalenID ‚_: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 globaleindeutig benannte und (mittelsSchlüsselwort „@type“) typisierteEntitäten bzw.Literale. Im Folgenden wird einer Person (im Sinne vonFOAF) „Albert Einstein“ (im Sinne derDBpedia) ein Geburtsdatum (im Sinne vonSchema.org und in der Schreibweise nachXML 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 einenkompakten IRI, der hier zur Abkürzung von

https://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, dannist der Ausdruck wegen des Doppelpunktes bereits ein absoluter IRI.)^[25]

Ontologien werden normalerweise nicht unbegründet gemischt. Generell wird zur Sparsamkeit geraten. (Für manche Anwendungen oderAnwendungsbereiche (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 sogenanntesSchlü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 zurSprachmarkierung undMehrsprachigkeit von Zeichenketten,Listen (Container),Indexierung,benannte Graphen,relative IRIs undBasis-IRI,umgekehrte Eigenschaften.

Der Kontext muss nicht direkt eingebettet, sondern kann auchperIRI referenziert werden:

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

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

Entscheidend für die reibungslose Funktion ist, dass dieURL tatsächlich zu einem Kontext gemäß JSON-LD führt, dieser also idealerweise perHTTP im JSON-LD-Format ladbar ist (oder zumindest einmal war).^[26]

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

Speziell vorgesehen ist dies durch denLink-Headerin einerHTTP-Nachricht (mit spezieller Link-Relation aus dem JSON-LD-Namensraum^[27]). In die eigentlichen Applikationsdaten bräuchte so nicht eingegriffen zu werden, was dieMigration erleichtern kann. Die contextURL aus dem Link-Header wird nur beachtet bei einem Inhaltstyp „application/[...+]json“ ungleich „application/ld+json“. Mehr dazu imAbschnittAnforderung von JSON-LD.

Des Weiteren bietet dieProgrammierschnittstelle dazu einenoptionalen Parameter (option expandContext, siehe:AbschnittAPI).

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 durchSchachtelung in der JSON-Struktur, sowie durchReihung in Form eines JSON-Arrays. Außerdem gibt esleere Kontexte, um eine Kombinationskette zu unterbrechen.

JSON-LD Processing Algorithms and API^[4] 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 zurabstrakten Syntax vonRDF^[16] 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öglichstredundanzarme Übertragung bzw. Speicherung, möglichst einfache Verarbeitung, u. a.

Zur Wandlung in besonders interessante Formen definiert diese EmpfehlungRechenverfahren

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

DieExpansion 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,^[28] dabei entfernt werden. (Soweit es die API-Methoden betrifft (s. u.), ist die Expansion als interner Zwischenschritt außerdem unumgänglich.)

DieVerdichtung 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:^[7] 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).

DasVerflachen 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^[29] ineinander geschachtelteSchleifen aus, um alle enthaltenen RDF-Tripelaufzuzählen. (Siehe auch: Beispiel imAbschnittAPI) Das „flach“ bezieht sich daher offenkundig (nur) auf eine feste bzw. maximaleRekursionstiefe: Die Kombination einer festen Zahl voniterativen 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:AbschnittMIME-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.

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

Alsinterne 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 werdenzirkelhafte Bezüge aufgedeckt und zurückgewiesen.

• Erzeugung einerZugriffsstruktur(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 einerImplementierung desselben sind.^[30]

Daneben ist dieSerialisierungvom, sowie die Deserialisierungzumabstrakten 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 zurSemantik von RDF^[31] hergestellt. Dies beinhaltet u. a. die Korrespondenz der primitiven JSON-Typen und -Literale mit denjenigen vonXML Schema und diejenige der JSON-LD-Listen mit denen vonRDF-Schema. (Nicht erwähnt hierbei u. a.: Sprachkennzeichnung von Strings).

DerMIME-Typ von JSON-LD sieht einen optionalen Parameter „profile“ vor. Sein Wert (ein IRI aus dem JSON-LD-Namensraum^[32]) 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).

Schließlich wird dieProgrammierschnittstelle einesJSON-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 verbreiteteECMAScript. Die Schnittstelle setzt auf derPromise-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 perIRI bzw.URL referenziert wurden, (von entfernter Seite, remote) aus dem Internet oder lokal aus einemCache laden. Außerdem sollen meist die JSON-LD-Daten hinter IRIs geladen werden (Dereferenzierung). In dieseLadeprozedur kann über die definierte Schnittstelle eingegriffen werden (JsonLdOptions documentLoader).

In einer Umgebung, in der dieses API verfügbar ist (und anderes), würde das folgendeCoffeeScript das Geburtsdatum vonAlbert Einstein lautDBpedia ausgeben (genauer: alle solchen verfügbaren, soweit kein Fehler auftritt).^[33]

AlbertsIRI="http://dbpedia.org/data/Albert_Einstein.jsonld"# bzw. "http://dbpedia.org/resource/Albert_Einstein", siehe Anmerkungdbpprop="http://dbpedia.org/property/"dbpprop$birthDate=dbpprop+"birthDate"expanded=(newJsonLdProcessor).expandAlbertsIRIexpanded.then(subjects) ->forsubjectinsubjectsforobjectinsubject[dbpprop$birthDate]?[]console.logobject['@value']# Fehlerbehandlung weggelassen

Programmier-Schnittstellen zurKonvertierung 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 auchAbschnittProgrammbibliotheken und Werkzeuge.

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). VerschiedeneModule können dies auch unterschiedlich handhaben.

Beispiel aus einerJavaScript-Umgebung (z. B.Webbrowser):

// JSON-Text in der Variablen data// Modul A (ursprüngliche App ohne Bewusstsein für Linked Data)varlegacy=JSON.parse(data)// Modul B (spätere Erweiterung fürs Semantische Web)varadvanced=(newJsonLdProcessor).expand(JSON.parse(data))

Zur Einbettung von JSON-LD in HTML wird das Script-Element empfohlen:^[3]

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

Dadurch kann eine Anwendung über dasDOM darauf zugreifen, u. a. also auch einJavaScript imWebbrowser:

// DOMvardata=document.getElementById('json-ld-data').textContent// jQueryvardata=$('#json-ld-data').text()

Mögliche Anwendungen dafür sind zunächst dieselben wie auch fürRDFa,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 klassischeMetadaten über das Dokument bis zu einer maschinenlesbaren Repräsentation des vollständigen Textinhalts (der parallelnatürlichsprachlich formuliert für die Rezeption durch Menschen bestimmt ist). Dies könnte eine automatisch erstellteAuftragsbestätigung sein. Auch die nachträgliche Generierung oder Anreicherung eines solchen Inhalts abhängig von Vorgaben desRezipienten wäre so noch möglich. Ebenso könnte ein persönlicher Assistent bzw.Software-Agent autonom darauf reagieren oder Aktionen anbieten. (Siehe auch:AbschnittAnwendungen und Anwender)

Ein JSON-LD-Kontext oder Daten in diesem Format werden überHTTP vorzugsweise mit dem zugehörigenMIME-Typ angefordert. (Dabei kann es zuVerhandlungen über den Inhaltstyp undWeiterleitungen kommen (Statuscode 3xx,Location-Header).)

Probeweise Anforderung zum Beispiel mitcURL (in derBash mit einer URL in der Variablen$URL):

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

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

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

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

Dienstnehmer sollten gegenüber demErbringer des Dienstes (1) möglichst eineklare Präferenz für „ld+json“ zum Ausdruck bringen (ggf. per q-Parameter imAccept-Header) und (2) bei allen anderen „json“-Typen auf einecontextURL im Link-Header achten (siehe auch:AbschnittAlternative 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, sieheAbschnittAPI.

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 vonLinked Data zu einer (per URL referenzierten) Entität widerspräche es jedoch Grundsätzen aus diesem Umfeld.^[33] 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.)

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 alskonform zur Spezifikation, basierend auf denTest-Reports zur zugehörigenTestsammlung:^[36][37]

• fürJavaScriptvon Digital Bazaar, Inc. (Browser,Node.js,Kommandozeile, Web-App)
• fürPythonPyLD von Digital Bazaar, Inc.
• fürPHPvon Digital Bazaar, Inc.,von Markus Lanthaler
• fürRubyinnerhalb von Ruby RDF
• fürJavavon jsonld-java auf Github
• fürC#innerhalb von NuGet

Wandlung zwischen JSON-LD und anderen Formaten:

• von RDFa: (u. a. auch nach JSON-LD) mittelsRDFa 1.1 Distiller and Parser von Ivan Herman (seit November 2011)
• RDF Translator^[38] (RDFLib-basiert)
• überein Plugin innerhalb vonRDFLibbei Github
• inRubyals Erweiterung zuRDF.rbim Ruby RDF Project

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 vonRDF/JSON so dar:^[9][39]

 { "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.^[40]

Auch anzutreffen ist das flache Tripel-Schema^[9]

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

Fundamentale Konzepte sind über die Arbeit anRDFj^[41] in LD-JSON eingeflossen, die teilweise aus dem Jahr 2004 stammt.^[3]

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

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. beiLinked Data,RDF.)

Zu den folgenden Formaten demonstriert die Empfehlung^[3] 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 derKompatibilität.

HTML Microdata vom W3C ist erklärtermaßen mit RDF kompatibel^[43] 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 ] } } ] }

Für das Ergebnis vonSPARQL-Anfragen wurde eine JSON-Form normiert.^[44] 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 beispielsweiseVirtuoso die Variablen „s“, „p“ und „o“ (Vergegenständlichung).^[45] 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. EineVergegenständlichung erübrigt sich hierbei.

Zu einigenfrühen Anwendern, welche dieÜbernahme von JSON-LD in Produkte oder Dienste bis Juni 2014 zumindest angekündigt haben:^[46]

Bereits im Mai 2013 hatGoogle angekündigt, JSON-LD zusätzlich zuHTML Microdata in seinen Produkten zu unterstützen. Beispielsweise kann in HTML-E-Mails eingebettetes JSON-LD beim Eintreffen in derMailbox extrahiert werden. Dem Empfänger werden die semantischen Daten so bei seinerpersonalisierten Suche verfügbar gemacht oder Eintragungen in den Terminkalender angeboten.^[47]

Auch Produkte vonMicrosoft 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.^[48] Voraussetzung dafür ist, dass der Absender dazu (ebenso wie bei Google) das Vokabular vonSchema.org verwendet.

DBpedia liefert (verlinkte) Daten, neben vielen anderen Formaten, auch in JSON-LD aus. Das dazu verwendeteVirtuoso bietet in seinerOpen Source Edition JSON-LD Serialisierung mindestens seit November 2011 an.^[49]

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

Die erste RDF-Version vonWordNet^[54] (vorgestellt im April 2014)^[55] liefert neben anderen RDF-Formaten auch JSON-LD schon seit Beginn (mittelsRDFLib).

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

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 dasWissensmanagement imSemantic Web (über dieRDF-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 dasSemantic Web.^[10] 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^[7]) 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- undSchnittstellenbeschreibung (API/service description) bereits Gegenstand von Forschung und Entwicklung.

Spätestens seit April 2012 wird JSON-LD im Zusammenhang mit demREST-Stil fürhypermedia-getriebene^[56] Webdienste (der nächsten Generation) diskutiert.^[57]

InHydra^[58] (das seit Juni 2013 auch Gegenstand einerW3C 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 vonRDF-Schema). In dieser Konstellation würde JSON-LD an die Stelle des XML in Ansätzen wieWSDL (inklusiveSAWSDL) undWADL 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.^[7]

Seit April 2014 gibt es neben Hydra ein weiteres (für JSON-LD ausgelegtes) Vokabular,^[59] 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.^[60] Wie in Hydra können Eingabe-Elemente sogar an dieParameter vonURL-Templates (nach RFC 6570^[61]) geknüpft werden. Diese Elemente (PropertyValueSpecification) orientieren sich am Input-Element vonHTML5, 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 interaktivenHypermediums. Dienste wieSuchmaschinen 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 derActivity Streams (und der zugehörigen Action Handlers)^[62] 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.

• Semantic Web Services
• Web Service Modeling Ontology

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

1. ↑Manu Sporny: Linked JSON: RDF for the Masses. In: The Beautiful, Tormented Machine. Archiviert vom Original am 17. Juni 2014; abgerufen am 1. Juni 2014 (englisch). 
2. ↑Ivan Herman: JSON-LD Has Been Published as a W3C Recommendation. Abgerufen am 7. Juni 2014 (englisch). 
3. ↑^abcdefManu Sporny, Gregg Kellogg, Markus Lanthaler, Editors: JSON-LD 1.0, A JSON-based Serialization for Linked Data, W3C Recommendation 16 January 2014. Abgerufen am 4. Juni 2014 (englisch). 
4. ↑^abMarkus Lanthaler, Gregg Kellogg, Manu Sporny, Editors: JSON-LD 1.0 Processing Algorithms and API, W3C Recommendation 16 January 2014. Abgerufen am 4. Juni 2014 (englisch). 
5. ↑Für praktisch jedeProgrammiersprache, die zurWebentwicklung benutzt wird, gibt es eine Konvention, JSON-Daten imHauptspeicher zu verwalten.
6. ↑namentlich vomNoSQL-Typ, der JSON nativ unterstützt wieMongoDB undCouchDB, aber auchSQL-Datenbanken mit JSON-Unterstützung wiePostgreSQL u. a.
7. ↑^abcdeMarkus Lanthaler:Third Generation Web APIs – Bridging the Gap between REST and Linked Data. Doctoral Dissertation, Institute of Information Systems and Computer Media, Graz University of Technology, Austria, 5. März 2014, Abschnitt 5.3, Seiten 108–141, übermarkus-lanthaler.com (PDF)SHA1 0ab17eed62aeb2f56e8f8b1ab95ac9820e36c87a, abgerufen am 8. Juni 2014
8. ↑Shane Becker: JSON-LD is an Unneeded Spec. Archiviert vom Original am 14. Juli 2014; abgerufen am 3. Juni 2014 (englisch). 
9. ↑^abcKeith Alexander:RDF in JSON: A Specification for serialising RDF in JSON In:Proceedings of the 4th Workshop on Scripting for the Semantic Web, Tenerife, Spain, June 02, 2008,CEUR Workshop Proceedings,ISSN 1613-0073,CEUR-WS.org (PDF; 116 kB)
10. ↑^abManu Sporny: JSON-LD and Why I Hate the Semantic Web. In: The Beautiful, Tormented Machine. Archiviert vom Original am 29. Mai 2014; abgerufen am 6. Juni 2014 (englisch). 
11. ↑Manu Sporny: JSON-LD is the Bee’s Knees. In: The Beautiful, Tormented Machine. Archiviert vom Original am 18. Juni 2014; abgerufen am 4. Juni 2014 (englisch). 
12. ↑Es ist allerdings zulässig, die von einem Knoten ausgehenden Kanten auf beliebig viele JSON-Objekte (mit gleicher „@id“) zu verteilen („Knoten-Objekte“). Diese werden dann durch die empfohlenen Algorithmen zu einem Objekt verschmolzen. Hierbei handelt es sich jedoch nicht um eine bevorzugte Form bzw. Zielform von JSON-LD.
13. ↑Ebenso für Mengen von Graphen, die flach als 4-Tupel (Quads) repräsentiert werden würden: Gruppierung nach dem Namen der Menge.
14. ↑What’s New in RDF 1.1 w3.org
15. ↑P. C. Bryan, K. Zyp: JSON Reference. Entwurf. In: Internet Engineering Task Force (IETF). 16. September 2012, abgerufen am 8. August 2025 (englisch). 
16. ↑^abRichard Cyganiak, David Wood, Markus Lanthaler: RDF 1.1 Concepts and Abstract Syntax – W3C Recommendation 25 February 2014. In: W3C Recommendation. Abgerufen am 11. Juni 2014 (englisch). 
17. ↑json-schema.org
18. ↑Beispielsweise verwendet dasPopolo Project JSON Schema und JSON-LD-Kontexte parallel, um für eine einheitliche und validierbare JSON-Form zu sorgen.
19. ↑M. Kelly:JSON Hypertext Application Language. In: Internet Engineering Task Force (IETF) Draft
20. ↑RFC:4627 –The application/json Media Type for JavaScript Object Notation (JSON). Juli 2006 (englisch).
21. ↑RFC:4627 –The application/json Media Type for JavaScript Object Notation (JSON). Juli 2006 (englisch).
22. ↑RFC:3987 –Internationalized Resource Identifiers (IRIs). Januar 2005 (englisch).
23. ↑RFC:5646 –Tags for Identifying Languages. September 2009 – Standard: [BCP47] (englisch). aliasBCP47
24. ↑auch: Schlüssel, Schlüsselwerte oder Eigenschaften genannt
25. ↑Dieses Konstrukt ist verwandt mit Namensraum-Präfixen bzw. -IRIs in anderen konkreten Serialisierungen von RDF, sowie mitCURIEs (compact URI expressions aus RDFa) undQNames aus XML.
26. ↑Siehe auch Anmerkung zumschema.org-Kontext
27. ↑JSON-LD-Namensraum. w3.org
28. ↑deren Name beispielsweise kein IRI oder Schlüsselwort wie @id oder @type ist und auch zu keinem expandiert
29. ↑abhängig davon, ob mehr als ein RDF-Graph zu erwarten ist; Listen würden die Tiefe zusätzlich um maximal eins erhöhen, weil sie nicht geschachtelt werden dürfen.
30. ↑DieIndexierung nach den „@id“s der Subjekte ist beispielsweise nicht vorgesehen, weil sich dies mit ein paar Zeilen Programmcode bei Bedarf leicht realisieren lässt. Des Weiteren haben Anwendungen auch Bedarf zur Indexierung nach komplexeren Kriterien.
31. ↑Patrick J. Hayes, Peter F. Patel-Schneider: RDF 1.1 Semantics – W3C Recommendation 25 February 2014. In: W3C Recommendation. Abgerufen am 11. Juni 2014 (englisch). 
32. ↑JSON-LD-Namensraum
33. ↑^abDie alternative, format-neutrale AlbertsIRI aus dem Kommentarzum API-Beispiel ist eigentlich vorzuziehen, stellt jedoch wegenContent Negotiation undHTTP-Redirects höhere Anforderungen an den eingebauten oder benutzerdefinierten documentLoader bzw. an das Zusammenspiel mit der DBpedia. Siehe auch:
    Chris Bizer, Richard Cyganiak, Tom Heath: How to Publish Linked Data on the Web. Archiviert vom Original am 19. April 2021; abgerufen am 6. Juni 2014 (englisch).  und
    Leo Sauermann, Richard Cyganiak (eds.): Cool URIs for the Semantic Web. In: W3C Interest Group Note. Abgerufen am 11. Juni 2014 (englisch).  (Work in progress), sowie
    Tom Heath and Christian Bizer (2011)Linked Data: Evolving the Web into a Global Data Space (1st edition). Synthesis Lectures on the Semantic Web: Theory and Technology, 1:1, 1-136. Morgan & Claypool. Per Access OptionFree HTML Version, abgerufen am 11. Juni 2014, Chapter 2.3 Making URIs Defererenceable (Schreibfehler im Original)
34. ↑RFC:6838 –Media Type Specifications and Registration Procedures. Januar 2013 (englisch).
35. ↑RFC:6839 –Additional Media Type Structured Syntax Suffixes. Januar 2013 (englisch).
36. ↑womit jedoch noch nichts für die Eignung inProduktivsystemen ausgesagt ist
37. ↑Die Empfehlung räumt ein: Selbst die erfolgreiche Absolvierung aller Tests gewährleistet nicht die vollständige Konformität.
38. ↑Alex Stolz, Bene Rodriguez-Castro, Martin Hepp:RDF Translator: A RESTful Multi-Format Data Converter for the Semantic Web, Technical Report TR-2013-1, E-Business and Web Science Research Group, Universität der Bundeswehr München, 2013,arxiv:1312.4704
39. ↑RDF 1.1 JSON Alternate Serialization (RDF/JSON). W3C Working Group, Note 7. November 2013
40. ↑David Wood:The State of RDF and JSON. 13. September 2011. In:Semantic Web Activity News
41. ↑Mark Birbeck (u. a.): Rdfj. In: backplanejs – A JavaScript library that provides cross-browser XForms, RDFa, and SMIL support. Abgerufen am 9. Juni 2014 (englisch). 
42. ↑JSON+RDF. In: w3.org. Abgerufen am 9. Juni 2014 (englisch). 
43. ↑w3.org
44. ↑SPARQL 1.1 Query Results JSON Format
45. ↑siehe auch:TriplesInJson w3.org
46. ↑Auswahl ohne Anspruch auf Vollständigkeit; json-ld.org führt eineListe dazu unter Github.
47. ↑Jennifer Zaino: Gmail, Meet JSON-LD. In: semanticweb.com. 17. Mai 2013, archiviert vom Original am 14. Juli 2014; abgerufen am 9. Juni 2014 (englisch). 
48. ↑Sending flight information to Microsoft Cortana with contextual awareness
49. ↑Virtuoso Open-Source Wiki:Virtuoso Open Source Edition News (2011)
50. ↑Schema.org and JSON-LD. In: blog.schema.org. 3. Juni 2013, archiviert vom Original am 8. Juni 2013; abgerufen am 8. August 2025 (englisch). 
51. ↑lists.w3.org
52. ↑Damit werden auch (schon länger im Umlauf befindliche) Beispiele generell funktionsfähig, dieschema.org als @context referenzieren. Dies war vorher nur in Umgebungen der Fall, welche diese URL intern mit einem passenden Kontext verbanden.
53. ↑gmane.org (Memento vom 14. Juli 2014 imInternet Archive)
54. ↑wordnet-rdf.princeton.edu
55. ↑htmltalk.us (Memento vom 14. Juli 2014 imInternet Archive)
56. ↑Beim hypermedia-getriebenen Ansatz (mit JSON-LD) reicht es (ähnlich wie bei der menschlichen Interaktion mit einer Webseite), einen Einstiegspunkt (entry point) in den Dienst zu finden. Alle weiteren Links und (Selbst-)Beschreibungen dazu sind maschinenlesbar über JSON-LD-Kontexte miteinander verknüpft: Literale und IRIs für Ressourcen in einer Antwort sind verknüpft mit Operationen, die darauf angewendet werden können. Deren Anwendung kann wieder zu solch einer Antwort führen, usf. (Sowohl Entwickler als auch flexible Software-Agenten könnten einen Dienst so schrittweise und standardisiert erkunden, um einen Weg zu finden, ihr eigentliches Ziels zu erreichen.)
57. ↑Markus Lanthaler, Christian Gütl: On Using JSON-LD to Create Evolvable RESTful Services. (PDF) In: Proceedings of the Third International Workshop on RESTful Design. 2012, S. 25–32, abgerufen am 21. Juni 2014 (englisch, SHA1 ba69b6c33792344fb189903792ec955af4aa0a98). 
58. ↑www.hydra-cg.com
59. ↑Jason Douglas et al.: Announcing Schema.org Actions. In: blog.schema.org. 16. April 2014, archiviert vom Original am 17. April 2014; abgerufen am 8. August 2025 (englisch). 
60. ↑w3.org (PDF; 1,2 MB)w3.org
61. ↑RFC:6570 –URI Template. März 2012 (englisch).
62. ↑activitystrea.mstools.ietf.org

• Datenformat
• Semantisches Web
• JSON

• Wikipedia:Überarbeiten