Quelltext der Seite JSON-LD

{{Dieser Artikel|behandelt das Dateiformat. Zur Streaming-Erweiterung „Line-delimited JSON“ siehe [[JSON streaming #Line-delimited JSON]].}}

{{Überarbeiten}}
{{Infobox Dateiformat
| Name = 
| Icon = [[File:JSON-LD.svg|100px]]
| Logo = 
| Screenshot = 
| Beschreibung = 
| Dateiendung = .jsonld
| MIME = application/ld+json
| MIME-Anm = 
| MagischeZahl = 
| MagischeZahlNotation = 
| MagischeZahlHex = 
| Entwickler = [[World Wide Web Consortium]]&nbsp;(W3C)
| Veröffentlicht = 
| LetzteVersion = 1.0
| LetzteVersionDatum = 16. Januar 2014
| Art = [[Abstrakte Syntax|konkrete Syntax]] von [[Resource Description Framework|RDF]]
| Container für = [[Linked Data]]
| Enthalten in = 
| Erweitert von = [[JavaScript Object Notation|JSON]], [[Resource Description Framework|RDF]]
| Erweitert zu = 
| Standard = [https://www.w3.org/TR/json-ld/ JSON-LD 1.0]<br /> [https://www.w3.org/TR/json-ld-api/ JSON-LD 1.0 Processing Algorithms and API] (W3C&nbsp;Recommendations)
| Website = [https://json-ld.org/ json-ld.org]
}}

'''JSON-LD''' ([[Akronym]] von {{enS}} für „'''JSON'''-basierte [[Serialisierung]] für ver'''L'''inkte '''D'''aten“) bezeichnet Empfehlungen des [[World Wide Web Consortium|W3C]], [[Linked Data|weltweit verknüpfte Daten]] (nach dem [[Resource Description Framework|RDF]]-Modell) im schlanken [[JavaScript Object Notation|JSON]]-[[Datenformat|Format]] einzubetten. Damit können [[Webservice]]s und [[Webapplikation]]en, die ihre [[Daten]] bevorzugt in JSON austauschen, leichten Anschluss zum [[Semantic Web|Semantischen Web]] finden und [[Interoperabilität|reibungsloser zusammenarbeiten]], indem sie [[Globale Variable|global]] [[Kontrolliertes Vokabular|eindeutige Bezeichnungen]] für [[Ontologie (Informatik)|logisch geordnete Begriffe]] verwenden.

Die Entwicklung begann 2010<ref name="linked-json" /> und führte im Januar 2014 zur Verabschiedung zweier Dokumente über die erste Version.<ref name="has-been-published" /><ref name="json-ld" /><ref name="json-ld-api" />

Für die Industrie ist die Einbettung in das etablierte JSON interessant, weil sie so den zugehörigen Baukasten aus [[Parser]]n, Speichern<ref>Für praktisch jede [[Programmiersprache]], die zur [[Web-Engineering|Webentwicklung]] benutzt wird, gibt es eine Konvention, JSON-Daten im [[Hauptspeicher]] zu verwalten.</ref> bzw. [[Datenbank]]en,<ref>namentlich vom [[NoSQL]]-Typ, der JSON nativ unterstützt wie [[MongoDB]] und [[CouchDB]], aber auch [[SQL]]-Datenbanken mit JSON-Unterstützung wie [[PostgreSQL]] u.&nbsp;a.</ref> [[Programmiersprache]]n-Anbindungen, sowie [[Know-how]] u.&nbsp;ä. weiter verwenden könnte. Die Entwickler versuchten sich daran zu orientieren, wie JSON bisher zum Datenaustausch genutzt wird. Dadurch soll die [[Migration (Informationstechnik)|Umstellung]] einer Software von JSON auf JSON-LD möglichst einfach sein.<ref name="3gen-web-apis" /> Hierzu kann es bereits ausreichen, einen ansonsten unveränderten JSON-Text mit einem sogenannten Kontext zu verknüpfen (siehe [[#Technik und Grundbegriffe von JSON-LD|Abschnitt ''Technik und Grundbegriffe von JSON-LD'']]).

Anwender von JSON-LD, welche hauptsächlich an herkömmlichem JSON interessiert sind, müssen [[Resource Description Framework|RDF]] nicht verstehen. Gleichzeitig stellt das Datenmodell von JSON-LD eine Erweiterung des RDF-Modells dar.<ref name="json-ld" />

== {{Anker|Merkbild}} Abgrenzung und Einordnung ==
<!-- Sorry. Das ist eventuell fragiler und umständlicher als notwendig. Siehe auch Diskussionsseite. -->
<div class="thumb tleft" style="width: 17em; font-weight: bold;">
 {
   "@id": "<span style="color: #505AB0; font-family: sans-serif; font-style: italic;">Subjekt (IRI)</span>",
   "<span style="color: #B35050; font-family: sans-serif; font-style: italic;">Prädikat (IRI)</span>": {
     "@id": "<span style="color: #50B36E; font-family: sans-serif; font-style: italic;">Objekt (IRI)</span>"
   },
   "<span style="color: #B35050; font-family: sans-serif; font-style: italic;">Prädikat (IRI)</span>":
     <span style="color: #50B36E; font-family: sans-serif; font-style: italic;">Objekt (Literal)</span>,
   "<span style="color: #B35050; font-family: sans-serif; font-style: italic;">Prädikat (IRI)</span>": [
     <span style="color: #50B36E; font-family: sans-serif; font-style: italic;">Objekt</span>, ...
   ]
 }
<div class="thumbcaption" style="font-weight:normal">
Merkbild zur Einbettung der RDF-Tripel (farbig, kursiv) in JSON (schwarz)
</div>
</div>

JSON-LD verhält sich zu JSON ähnlich, wie sich [[RDFa]], [[HTML Microdata]] bzw. ein [[Microformat]] jeweils zu [[Hypertext Markup Language|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 ([[Annotation#Semantische Annotationen|semantische Annotation]]).

Ein wesentlicher Unterschied besteht darin, dass JSON keine [[Auszeichnungssprache|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.<ref>{{cite web|url=http://iamshane.com/articles/2013/8/8/1/json-ld-is-an-unneeded-spec|title=JSON-LD is an Unneeded Spec|author=Shane Becker|accessdate=2014-06-03|offline=yes|archiveurl=https://web.archive.org/web/20140714210706/http://iamshane.com/articles/2013/8/8/1/json-ld-is-an-unneeded-spec|archivedate=2014-07-14|archivebot=2018-04-16 15:11:37 InternetArchiveBot}}</ref>

Der traditionelle Einsatzort von JSON ist jedoch nicht die [[Mensch-Maschine-Schnittstelle|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 [[Extensible Markup Language|XML]] abseits von [[Extensible Hypertext Markup Language|XHTML]]. XML-[[Parser]],<ref name="rdf-in-json" /> [[Graphdatenbank|RDF-Speicher]] und [[SPARQL]]-Maschinerie<ref name="json-ld-origins-2" /> werden im Web-Umfeld zuweilen als „[[Overhead (EDV)|Overhead]]“ empfunden. Selbst handliche Formate aus dem RDF-Umfeld (wie [[Turtle (Syntax)|Turtle]]) werden kaum als Basisformat in Web-[[Kommunikationsprotokoll|Protokollen]] genutzt. JSON-LD soll Probleme lösen, die sich mit den anderen Formaten nicht lösen ließen.<ref name="json-ld-is-the-bees-knees" />

Im Gegensatz zu anderen [[Serialisierung]]sformaten für [[Linked Data]] bzw. [[Resource Description Framework|RDF]], die [[Tupel|Tripel]]-orientiert sind, bleibt JSON-LD auch in seiner flachen Vorzugsform [[Entität (Informatik)|Entität]]-zentriert:<ref name="3gen-web-apis" /> Alle ausgehenden Prädikatskanten des Graphen sind nach dem RDF-Subjekt gruppiert und alle RDF-Objekte nach Subjekt und Prädikat.<ref>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.</ref><ref>Ebenso für Mengen von Graphen, die flach als 4-Tupel (Quads) repräsentiert werden würden: Gruppierung nach dem Namen der Menge.</ref>

Gemeinsam mit [[TriG]] und [[N-Quads]], sowie im Unterschied zu [[Turtle (Syntax)|Turtle]] unterstützt JSON-LD mehrere (benannte) Graphen (RDF datasets).<ref>[https://www.w3.org/TR/2014/NOTE-rdf11-new-20140225/ What’s New in RDF 1.1] w3.org</ref> 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.
<!-- Hauptartikel Serialisierung von RDF?
     Liste der konkreten RDF-Syntaxen?
-->

JSON-LD beinhaltet (gegenüber JSON) eine Standardkonvention, um mittels [[Internationalized Resource Identifier|IRIs]] (externe) Referenzen bzw. einfache Links darzustellen (ähnlich Erweiterungen wie JSON Reference,<ref name="draftpbryan-zyp-json-ref-03" /> jedoch ohne die Interpretation des [[Fragmentbezeichner]]s als JSON Pointer; JSON-LD folgt hier RDF-Gepflogenheiten<ref name="rdf11-concepts" />). Außerdem kann es standardisiert Datentypen und Schema-Informationen aus dem RDF-Umfeld einbinden. (Anders als [[JavaScript Object Notation#JSON Schema|JSON Schema]]<ref>[http://json-schema.org/ json-schema.org]</ref> setzt es dabei nicht auf gesonderte bzw. JSON-spezifische Verfahren. Eine [[Datenvalidierung|Prüfung]] mittels JSON Schema ist jedoch nicht ausgeschlossen.<ref>Beispielsweise verwendet das [http://popoloproject.com/ Popolo Project] JSON Schema und JSON-LD-Kontexte parallel, um für eine einheitliche und validierbare JSON-Form zu sorgen.</ref>)<!-- hier könnte man noch Collection+JSON erwähnen; Links siehe unter "Vorgänger und Alternativen" -->

Zwar stellt JSON-LD selbst keine eigene Sprache für ([[Hypertext Markup Language|HTML]]-freie) [[Hypertext]]- bzw. [[Hypertext Transfer Protocol|HTTP]]-Anwendungen (im [[Representational State Transfer|REST]]-Stil) zur Verfügung (wie etwa JSON HAL<ref name="draft-kelly-json-hal-06" /> oder JSON Hyper-Schema). Eine solche ist jedoch über entsprechende Vokabulare zur Dienst- bzw. [[Schnittstellenbeschreibung]] einbindbar. Siehe auch: [[#Im Bereich der Web-APIs|Abschnitt ''Im Bereich der Web-APIs'']].

JSON-LD ist nicht [[Kompatibilität (Technik)|kompatibel]] mit (dem älteren) RDF/JSON. Siehe auch: [[#Vorgänger und Alternativen|Abschnitt ''Vorgänger und Alternativen'']].

=== Syntax ===

Bezüglich der [[Syntax]] von [[JavaScript Object Notation|JSON]] gilt:
{{Zitat
 |Text=Jeder JSON-LD-Text ist ein gültiger JSON-Text
 |ref=<ref>{{RFC-Internet |RFC=4627 |Titel=The application/json Media Type for JavaScript Object Notation (JSON) |Datum=2006-07}} <!-- Zitat dort nicht auffindbar, und deutsch ohnehin nicht. Abschnitt=???? genaue Formulierung? Sinn? --></ref>}}

Welche JSON-Texte umgekehrt auch gültiges JSON-LD darstellen, ist Gegenstand hauptsächlich des ersten Dokuments.<ref name="json-ld" /> Ein JSON-LD-Text muss u.&nbsp;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üsselwort (Programmierung)|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.&nbsp;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 [[Internationalized Resource Identifier|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 [[Formale Grammatik|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 [[normativ]]en Abschnitten anhand von Beispielen eingeführt. Die formalste Definition besteht aus über achtzig normativen Sätzen in englischer Sprache. Formalismen wie [[Erweiterte Backus-Naur-Form|EBNF]] oder [[Syntaxdiagramm]]e werden nicht angewendet. Es wird keine Sprache von Grund auf neu entworfen. JSON-LD bezieht sich auf die Grammatiken der [[Internet Engineering Task Force|IETF]] aus <nowiki>RFC&nbsp;4627</nowiki> (JSON),<ref>{{RFC-Internet |RFC=4627 |Titel=The application/json Media Type for JavaScript Object Notation (JSON) |Datum=2006-07}}</ref> <nowiki>RFC&nbsp;3987</nowiki> (IRIs),<ref>{{RFC-Internet |RFC=3987 |Titel=Internationalized Resource Identifiers (IRIs) |Datum=2005-01}}</ref> BCP47 alias <nowiki>RFC&nbsp;5646</nowiki><ref>{{RFC-Internet |RFC=5646 |Titel=Tags for Identifying Languages |Datum=2009-09 |Standard=BCP47}} alias [http://tools.ietf.org/html/bcp47 BCP47]</ref> (Sprachkennzeichen, language tags, siehe auch: [[ISO&nbsp;639]]).
<!--
TODO: irgendeine musterbasierte oder graphische Darstellung der Syntax wäre natürlich trotzdem nett

Bisher bekannte erste Ansätze dazu:
http://lists.w3.org/Archives/Public/public-linked-json/2013Dec/0001.html
http://lists.w3.org/Archives/Public/public-linked-json/2013Dec/att-0001/json-ld.ebnf
http://lists.w3.org/Archives/Public/public-linked-json/2013Dec/att-0001/jld-diagram.xhtml

Außerdem der Versuch, für ein JSON Schema:
https://github.com/json-ld/json-ld.org/blob/master/schemas/jsonld-schema.json

(Ansonsten irgendeine Statistik, die suggeriert, dass sich das Biest nicht viel knapper als im (etwas textlastigen) Original darstellen lässt :-)

Wenn sich nomativer Satz <math>i</math> (der <math>N</math> Sätze) in <math>e_i \ge 1</math> elementare Aussagen zerlegen lässt, dann ergeben sich <math>\textstyle e = \sum_{i=1}^{N} e_i</math> Elemente. Alternative Beschreibungen dürften auch nicht mit viel weniger auskommen (wenn man von einer redundanzarmen Spezifikation ausginge, was jedoch typischerweise anzunehmen wäre).

-->

== Ausgangspunkt und Grundlagen ==

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

<syntaxhighlight lang="javascript">
{
  "xfvhgr": "bzmxmhfg",
  "ozwqrsmm": "1879-03-14"
}
</syntaxhighlight>

Selbst wer das [[JavaScript Object Notation|JSON]]-Format lesen kann, wird hier nur dessen Elemente erkennen, wie die Paare aus Namen und Werten. Eine inhaltliche [[Bedeutung (Sprachphilosophie)|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 (Sprachwissenschaft)|Kontext]]. Außerdem wäre ein primitives Basisvokabular vorauszusetzen, dessen Bedeutung bei den Teilnehmern (durch [[Konstruieren (Technik)|Konstruktion]], [[Evolution]] oder [[Sozialisation]] auf niederer oder [[kognitiv]]er Ebene) bereits verankert ist.)

[[Bezeichner]], mit denen nicht zumindest die meisten [[Softwareentwickler]] etwas verbinden können, sind zwar untypisch. (Häufig verwendet werden [[Lexem]]e 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 [[Mehrdeutigkeit]]en (siehe auch: [[Homonym]] bzw. [[Polysemie]], sowie [[Disambiguierung]]).

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

=== Von JSON zu JSON-LD ===

JSON ist zunehmend in den [[Programmierschnittstelle|APIs]] verbreiteter [[Webservice]]s anzutreffen, wie denen von [[Google LLC|Google]], [[Twitter]], [[Facebook]] und vielen anderen.

JSON-Objekte bestehen aus Paaren von Namen<ref>auch: Schlüssel, Schlüsselwerte oder Eigenschaften genannt</ref> 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.&nbsp;B. im Rahmen eines [[Mashup (Internet)|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 (Programmierung)|Schlüsselwort]] @context''' geleistet werden:

{{Anker|erstes_Beispiel}}
<syntaxhighlight highlight="2-4" lang="javascript">
{
  "@context": {
    "born": "http://schema.org/birthDate"
  },
  "born": "1879-03-14"
}
</syntaxhighlight>

Dies sagt einem [[Computerprogramm]] (welches diesen Text als JSON [[Parser|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 [[#Alternative Kontextualisierung|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 [[Internationalized Resource Identifier|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: [[#Algorithmen und Formen|Abschnitt ''Algorithmen und Formen'']]).

<syntaxhighlight lang="javascript">
[
  {
    "@id": "_:b0",
    "http://schema.org/birthDate": [
      {
        "@value": "1879-03-14"
      }
    ]
  }
]
</syntaxhighlight>

Hierbei wurden alle im Kontext definierten Namen wie „born“ zu einem absoluten [[Internationalized Resource Identifier|IRI]] expandiert (und außerdem alle Werte bzw. [[Literal]]e 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: [[#Algorithmen und Formen|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 [[Identifikator|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ät (Informatik)|Entitäten]] bzw. [[Literal]]e. 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.

<syntaxhighlight highlight="7,10-11" lang="javascript">
{
  "@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"
}
</syntaxhighlight>

„xsd:date“ ist ein Beispiel für einen '''kompakten IRI''', der hier zur Abkürzung von
: <code>https://www.w3.org/2001/XMLSchema#date</code>
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.)<ref>Dieses Konstrukt ist verwandt mit Namensraum-Präfixen bzw. -IRIs in anderen konkreten Serialisierungen von RDF, sowie mit [[CURIE]]s (compact URI expressions aus RDFa) und [[QName]]s aus XML.</ref>

[[Ontologie (Informatik)|Ontologien]] werden normalerweise nicht unbegründet gemischt. Generell wird zur Sparsamkeit geraten. (Für manche Anwendungen oder [[Problemdomäne|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 ([[Voreinstellung|Default]]-Präfix).

<syntaxhighlight highlight="3" lang="javascript">
{
  "@context": {
    "@vocab": "http://schema.org/"
  },
  "birthDate": "1879-03-14"
}
</syntaxhighlight>

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.&nbsp;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:

<syntaxhighlight highlight="4-5" lang="javascript">
{
  "@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"
}
</syntaxhighlight>

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

Nicht demonstriert wurden u.&nbsp;a. Mittel zur '''Sprachmarkierung''' und '''[[Internationalisierung (Softwareentwicklung)|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 [[Internationalized Resource Identifier|IRI]] referenziert'' werden:

<syntaxhighlight highlight="2" lang="javascript">
{
  "@context": "http://example.com/person.jsonld",
  "born": "1879-03-14"
}
</syntaxhighlight>

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

Entscheidend für die reibungslose Funktion ist, dass die [[Uniform Resource Locator|URL]] tatsächlich zu einem Kontext gemäß JSON-LD führt, dieser also idealerweise per [[Hypertext Transfer Protocol|HTTP]] im JSON-LD-Format ladbar ist (oder zumindest einmal war).<ref>Siehe auch Anmerkung zum [[#schema.org-Kontext|schema.org-Kontext]]</ref>

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

Speziell vorgesehen ist dies durch den [[Liste der HTTP-Headerfelder#Link|Link-Header]] ''in einer [[Hypertext Transfer Protocol|HTTP]]-Nachricht'' (mit spezieller Link-Relation aus dem JSON-LD-Namensraum<ref>[https://www.w3.org/ns/json-ld JSON-LD-Namensraum.] w3.org</ref>). In die eigentlichen Applikationsdaten bräuchte so nicht eingegriffen zu werden, was die [[Migration (Informationstechnik)|Migration]] erleichtern kann. Die contextURL aus dem Link-Header wird nur beachtet bei einem Inhaltstyp „application/[...+]json“ ungleich „application/ld+json“. Mehr dazu im [[#Anforderung von JSON-LD|Abschnitt ''Anforderung von JSON-LD'']].

Des Weiteren bietet die [[Programmierschnittstelle]] dazu einen ''optionalen Parameter'' (option expandContext, siehe: [[#API|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.&nbsp;a. die Kombination bzw. [[Akkumulation (Wirtschaft)|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''<ref name="json-ld-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. [[Algorithmisch|durch Rechenvorschriften]] erklärt, indem u.&nbsp;a. auch so der Bezug zur [[Abstrakte Syntax|abstrakten Syntax]] von [[Resource Description Framework|RDF]]<ref name="rdf11-concepts" /> 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 [[Redundanz (Informationstheorie)|redundanzarme]] Übertragung bzw. Speicherung, möglichst einfache Verarbeitung, u.&nbsp;a.

Zur Wandlung in besonders interessante Formen definiert diese Empfehlung [[Algorithmus|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 ([[Normalisierung (Text)|Vereinheitlichung]]). ''Diese Algorithmen sind zudem normativ!'' Tatsächlich werden die Formen erst durch die Algorithmen vollständig definiert bzw. [[Normung|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.&nbsp;u.). Beachtenswert ist hierbei, dass alle Name/Wert-Paare, die keine Interpretation im Modell von JSON-LD finden,<ref>deren Name beispielsweise kein IRI oder Schlüsselwort wie @id oder @type ist und auch zu keinem expandiert</ref> dabei entfernt werden. (Soweit es die API-Methoden betrifft ([[#API|s.&nbsp;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:<ref name="3gen-web-apis" /> 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<ref>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.</ref> ineinander geschachtelte [[Schleife (Programmierung)|Schleifen]] aus, um alle enthaltenen RDF-Tripel [[Iterator|aufzuzählen]]. (Siehe auch: Beispiel im [[#API|Abschnitt ''API'']]) Das „flach“ bezieht sich daher offenkundig (nur) auf eine feste bzw. maximale [[Rekursionstiefe]]: Die Kombination einer festen Zahl von [[Iterative Programmierung|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: [[#MIME-Typ-Parameter|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.&nbsp;a. ohne Typ-Definitionen, sowie mit zusätzlichen oder anders benannten IRI-Präfixen und deutschsprachigen Termen und Schlüsselwort-Aliassen).

{| class="centered toptextcells" style="font-size:80%;"
|
<syntaxhighlight lang="javascript">
{
  "@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"
  }
}
</syntaxhighlight>
|
<syntaxhighlight lang="javascript">
{
  "@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"
      }
    }
  ]
}
</syntaxhighlight>
|-
|colspan="2"| <div style="display:table;" class="centered">
<syntaxhighlight lang="javascript">
[
  {
    "@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"
      }
    ]
  }
]
</syntaxhighlight>
</div>
|}

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 ([[World Geodetic System 1984|WGS84]]) sein Geburtsort läge. Oder in Tripel-Notation ([[N-Triples]], siehe auch: [[Turtle (Syntax)|Turtle]]):

<pre style="font-size:80%;">
<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" .
</pre>

=== Hilfsverfahren ===

Als '''interne Hilfsverfahren''' treten u.&nbsp;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.&nbsp;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 [[Zirkelbezug|zirkelhafte Bezüge]] aufgedeckt und zurückgewiesen.
* Erzeugung einer [[Indexstruktur|Zugriffsstruktur]] ''(Node Map Generation)'', welche nach den Subjekten gruppiert und Knoten-Objekte mit gleicher @id verschmilzt (siehe Verflachen).

Bisher u.&nbsp;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.&nbsp;u.) empfohlen, wenngleich sie (in äquivalenter Form) kaum verzichtbarer Bestandteil einer [[Implementierung]] desselben sind.<ref>Die [[Indexstruktur|Indexierung]] 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.</ref>
<!-- Konkrete Fälle manuell aus den Algorithmen herauszulesen ist anspruchsvoll. Wünschenswert wäre eine für Menschen schnell erfassbare (musterbasierte) Darstellung der Expansion über der Syntax. Quelle: Unbekannt. Forschungsauftrag ... Andererseits werden Entwicklertools (welche die Expansion eines Ausdrucks im aktuellen Kontext berechnen und anzeigen können) das vermutlich kompensieren können. -->

=== 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<ref name="rdf11-mt" /> hergestellt. Dies beinhaltet u.&nbsp;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.&nbsp;a.: Sprachkennzeichnung von Strings).

=== MIME-Typ-Parameter ===

Der [[Multipurpose Internet Mail Extensions|MIME]]-Typ von JSON-LD sieht einen optionalen Parameter „profile“ vor. Sein Wert (ein IRI aus dem JSON-LD-Namensraum<ref>[https://www.w3.org/ns/json-ld JSON-LD-Namensraum]</ref>) 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).
<!--

=== Weitere Verfahren ===

Weitere experimentelle Algorithmen, die aber nicht Bestandteil der ersten Empfehlung von 2014 waren, sind solche

* zur Normalisierung (normalization) TODO http://json-ld.org/spec/latest/rdf-graph-normalization/
* zur Filterung und Umstrukturierung (framing) TODO http://json-ld.org/spec/latest/json-ld-framing/
-->

=== 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 ([[Methode (Programmierung)|Methoden]]: compact, expand, flatten) in Programmierumgebungen bereit, vorwiegend auch für das im Web-Umfeld verbreitete [[ECMAScript]]. Die Schnittstelle setzt auf der [[Future (Programmierung)|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 [[Internationalized Resource Identifier|IRI]] bzw. [[Uniform Resource Locator|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).<ref name="iri-deref" />

{{Anker|API-Beispiel}}
<syntaxhighlight highlight="7" lang="coffeescript">
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
</syntaxhighlight>

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-[[Framework]]s bzw. -[[Programmbibliothek]]en auf dieser Grundlage zwischen ihrer jeweiligen RDF-Abstraktion und einer JSON-LD-Form. Siehe auch [[#Programmbibliotheken und Werkzeuge|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 [[Modul (Software)|Module]] können dies auch unterschiedlich handhaben.

Beispiel aus einer [[JavaScript]]-Umgebung (z.&nbsp;B. [[Webbrowser]]):

<syntaxhighlight lang="javascript">
// 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 ) )
</syntaxhighlight>

=== Einbettung in HTML ===

Zur Einbettung von JSON-LD in HTML wird das Script-Element empfohlen:<ref name="json-ld" />

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

Dadurch kann eine Anwendung über das [[Document Object Model|DOM]] darauf zugreifen, u.&nbsp;a. also auch ein [[JavaScript]] im [[Webbrowser]]:

<syntaxhighlight lang="javascript">
// DOM
var data = document.getElementById( 'json-ld-data' ).textContent

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

Mögliche Anwendungen dafür sind zunächst dieselben wie auch für [[RDFa]], [[HTML Microdata]] u.&nbsp;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ürliche Sprache|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 [[Rezipient]]en wäre so noch möglich. Ebenso könnte ein persönlicher Assistent bzw. [[Software-Agent]] autonom darauf reagieren oder Aktionen anbieten. (Siehe auch: [[#Anwendungen und Anwender|Abschnitt ''Anwendungen und Anwender'']])

=== Anforderung von JSON-LD ===

Ein JSON-LD-Kontext oder Daten in diesem Format werden über [[Hypertext Transfer Protocol|HTTP]] vorzugsweise mit dem zugehörigen [[Multipurpose Internet Mail Extensions|MIME]]-Typ angefordert. (Dabei kann es zu [[Content Negotiation|Verhandlungen über den Inhaltstyp]] und [[Weiterleitung]]en kommen ([[HTTP-Statuscode#g3xx|Statuscode 3xx]], [[Liste der HTTP-Headerfelder#Location|Location-Header]]).)

Probeweise Anforderung zum Beispiel mit [[cURL]] (in der [[Bash (Shell)|Bash]] mit einer URL in der Variablen <code>$URL</code>):

<syntaxhighlight lang="bash">
curl -i -L -H "Accept: application/ld+json" "$URL"
</syntaxhighlight>

Im positiven Fall ist die (letzte) Antwort vom entsprechenden [[Liste der HTTP-Headerfelder#Content-Type|Inhaltstyp]] und enthält verwertbares JSON-LD.

(Anmerkung zum MIME-Typ selbst: application/ld+json basiert (im Sinne von <nowiki>RFC&nbsp;6838</nowiki><ref>{{RFC-Internet |RFC=6838 |Titel=Media Type Specifications and Registration Procedures |Datum=2013-01}}</ref>) auf einem ''Structured Syntax (Name) Suffix'' „+json“, das in <nowiki>RFC&nbsp;6839</nowiki><ref>{{RFC-Internet |RFC=6839 |Titel=Additional Media Type Structured Syntax Suffixes |Datum=2013-01}}</ref> registriert ist.)

Besonders im Umfeld von [[Linked Data]] ist bei Inhalt vom Typ application/json Vorsicht geboten, weil dieser in Wirklichkeit u.&nbsp;a. auch vom [[Kompatibilität (Technik)|inkompatiblen]] Format RDF/JSON sein kann, siehe auch [[#Vorgänger und Alternativen|Abschnitt ''Vorgänger und Alternativen'']].

[[Client|Dienstnehmer]] sollten gegenüber dem [[Server|Erbringer des Dienstes]] (1) möglichst eine '''klare Präferenz''' für „ld+json“ zum Ausdruck bringen (ggf. per q-Parameter im [[Liste der HTTP-Headerfelder#Accept|Accept-Header]]) und (2) bei allen anderen „json“-Typen auf eine ''contextURL im Link-Header'' achten (siehe auch: [[#Alternative Kontextualisierung|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 [[#API|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-[[Query-String|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.<ref name="iri-deref" /> 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 ===

[[Implementierung]]en 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 [https://json-ld.org/test-suite/reports/ Test-Reports] zur zugehörigen [[Softwaretest|Testsammlung]]:<ref>womit jedoch noch nichts für die Eignung in [[Produktionssystem (Informatik)|Produktivsystemen]] ausgesagt ist</ref><ref>Die Empfehlung räumt ein: Selbst die erfolgreiche Absolvierung aller Tests gewährleistet nicht die vollständige Konformität.</ref>

* für [[JavaScript]] [https://github.com/digitalbazaar/jsonld.js von Digital Bazaar, Inc.] (Browser, [[Node.js]], [[Kommandozeile]], Web-App)
* für [[Python (Programmiersprache)|Python]] [https://github.com/digitalbazaar/pyld PyLD von Digital Bazaar, Inc.]
* für [[PHP]] [https://github.com/digitalbazaar/php-json-ld von Digital Bazaar, Inc.], [https://github.com/lanthaler/JsonLD von Markus Lanthaler]
* für [[Ruby (Programmiersprache)|Ruby]] [https://github.com/ruby-rdf/json-ld/ innerhalb von Ruby RDF]
* für [[Java (Programmiersprache)|Java]] [https://github.com/jsonld-java/jsonld-java von jsonld-java auf Github]
* für [[C-Sharp|C#]] [https://github.com/NuGet/json-ld.net innerhalb von NuGet]

Wandlung zwischen JSON-LD und anderen Formaten:

* von RDFa: (u.&nbsp;a. auch nach JSON-LD) mittels [https://www.w3.org/2012/pyRdfa/ RDFa 1.1 Distiller and Parser von Ivan Herman] ([http://semanticweb.com/rdfa-1-1-distiller-json-ld_b24954 seit November 2011])
<!--
* in Ruby speziell zur Wandlung von http://schema.org/docs/schema_org_rdfa.html [https://gist.github.com/gkellogg/5691913 Schema.org class heirarchy in JSON-LD] (kann aber auch mittels RDFa Distiller oder RDF translator online erledigt werden)
 -->
* [https://rdf-translator.appspot.com/ RDF Translator]<ref>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}} <!-- http://arxiv.org/abs/1312.4704 --></ref> ([[RDFLib]]-basiert)
* über [https://github.com/RDFLib/rdflib-jsonld ein Plugin] innerhalb von [[RDFLib]] [https://github.com/RDFLib/rdflib bei Github]
* in [[Ruby (Programmiersprache)|Ruby]] [http://gkellogg.github.io/json-ld/ als Erweiterung] zu [https://ruby-rdf.github.io/rdf/ RDF.rb] [http://ruby-rdf.github.io/ 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:<ref name="rdf-in-json" /><ref name="rdf-json" />

  { "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.<ref name="the-state-of-rdf-and-json" />

Auch anzutreffen ist das flache Tripel-Schema<ref name="rdf-in-json" />

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

Fundamentale Konzepte sind über die Arbeit an '''RDFj'''<ref name="rdfj" /> in LD-JSON eingeflossen, die teilweise aus dem Jahr 2004 stammt.<ref name="json-ld" />

Über ein Dutzend weitere Ansätze, RDF-Tripel in JSON abzubilden, listet allein das W3C schon 2011 in seinem Wiki auf.<ref name="JSON+RDF" />

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]], [[Resource Description Framework|RDF]].)

Zu den folgenden Formaten demonstriert die Empfehlung<ref name="json-ld" /> anhand von Beispielen, dass JSON-LD die darin enthaltenen semantischen Daten ausdrücken könne:

* [[Turtle (Syntax)|Turtle]]
* [[RDFa]]
* [[HTML Microdata]]
* [[Mikroformat]]e

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 (Technik)|Kompatibilität]].
<!-- Hauptartikel "Serialisierung nach JSON" und "... von RDF" ?

Es zeichnet sich schon ab: Es gibt eigentlich keine vollwertige Alternative zu JSON-LD: Wenn es das nicht schon gäbe, hätte man es dringend erfinden müssen.

TODO? berühren nur Teilaspekte wie Links, Namespaces oder Schema, kein Bezug zu RDF:
* JSON Schema http://tools.ietf.org/html/draft-zyp-json-schema-04, http://json-schema.org/
* JSON Reference http://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03
* JSON HAL http://tools.ietf.org/html/draft-kelly-json-hal-06, http://stateless.co/hal_specification.html
* Collection+JSON http://amundsen.com/media-types/collection/

Teilweise bei der Einordung oder bei den Web-APIs abgehandelt.
-->

=== Alternative: Microdata+JSON ===

HTML Microdata vom W3C ist erklärtermaßen mit RDF kompatibel<ref>[https://www.w3.org/TR/microdata/ w3.org]</ref> 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.<ref name="sparql11-results-json" /> 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 [[OpenLink Virtuoso|Virtuoso]] die Variablen „s“, „p“ und „o“ ([[Reifizierung#Informatik|Vergegenständlichung]]).<ref>siehe auch: [https://www.w3.org/wiki/TriplesInJSON TriplesInJson] w3.org</ref> 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 [[Reifizierung#Informatik|Vergegenständlichung]] erübrigt sich hierbei.

<!-- In letzter Minute noch gecancelt: Irgendwie schien dem Autor plötzlich, als wäre OData hier noch weit im Felde (oder er müsse für eine kompetente Darstellung auch noch Version 4 des Protokolls besser verstehen bzw. bessere Quellen dazu finden). Möge sich ein Microsoft-Kenner darum kümmern.

=== Alternative: OData ===

Verlinkte Daten lassen sich auch in [[OData]] transportieren. Da OData eine [http://www.odata.org/documentation/odata-version-2-0/json-format JSON-Repräsentation] hat, kann es als Alternative zu JSON-LD eingesetzt werden. Ein Schema dazu (nach dem Virtuoso ausliefert, Achtung: „P+“ symbolisiert hier den Umstand, dass Prädikats-URIs beliebig oft wiederholt werden können, was Probleme mit JSON-Parsern erwarten lässt):

  {"d": {"results":
    [ { "__metadata": { "uri": "S" }, "P+": O } ]
  }}

wobei Objekte O, die Ressourcen per IRI identifizieren, also keine Literale sind, folgendes Muster haben:

  { "__deferred": { "uri": "O" } }

So werden in OData (Version 2) Links auf Daten ausgedrückt, die erst bei Bedarf (verzögert) geladen werden. An den gegenüber JSON-LD weniger prägnanten Kontruktionen lässt sich ablesen, dass OData nicht allein für diesen Zweck entworfen wurde.

OData sieht (in aktuelleren Versionen) ebenfalls Mechanismen zur Typisierung vor, benutzt „@“ (auch) für (semantische) Annotation und Ähnliches. Während der Entwicklung von JSON-LD gab es [http://www.w3.org/2011/rdf-wg/track/issues/162 Bestrebungen], OData und JSON-LD zu harmonisieren, was aber letztendlich [http://json-ld.org/minutes/2013-10-01/#topic-3 zu keiner Änderung mehr geführt] hat.

TODO?
Schemas, Annotations, Vocabularies

http://docs.oasis-open.org/odata/odata/v4.0/os/part1-protocol/odata-v4.0-os-part1-protocol.html

http://www.w3.org/wiki/WebSchemas/SchemaDotOrgOData

TODO: GData

http://onlydifferencefaqs.blogspot.de/2012/09/difference-between-rdf-odata-and-gdata.html
-->

== Anwendungen und Anwender ==

Zu einigen [[Early Adopter|frühen Anwendern]], welche die [[Diffusionstheorie|Übernahme]] von JSON-LD in Produkte oder Dienste bis Juni 2014 zumindest angekündigt haben:<ref>Auswahl ohne Anspruch auf Vollständigkeit; json-ld.org führt eine [https://github.com/json-ld/json-ld.org/wiki/Users-of-JSON-LD Liste dazu unter Github].</ref>

Bereits im Mai 2013 hat [[Google LLC|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 (Computer)|Mailbox]] extrahiert werden. Dem Empfänger werden die semantischen Daten so bei seiner [[Personalisierung (Informationstechnik)|personalisierten]] Suche verfügbar gemacht oder Eintragungen in den Terminkalender angeboten.<ref>{{cite web |author=Jennifer Zaino |title=Gmail, Meet JSON-LD |date=2013-05-17 |url=https://semanticweb.com/gmail-meet-json-ld_b37211 |accessdate=2014-06-09 |work=semanticweb.com |offline=yes |archiveurl=https://web.archive.org/web/20140714223513/https://semanticweb.com/gmail-meet-json-ld_b37211 |archivedate=2014-07-14}}</ref>

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.<ref>[http://msdn.microsoft.com/en-us/library/dn632191.aspx Sending flight information to Microsoft Cortana with contextual awareness]</ref> 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 [[OpenLink Virtuoso|Virtuoso]] bietet in seiner [[Open Source]] Edition JSON-LD Serialisierung mindestens seit November 2011 an.<ref>Virtuoso Open-Source Wiki: [http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VOSNews2011 Virtuoso Open Source Edition News (2011)]</ref>

[[Schema.org]] bekennt sich seit Juni 2013 zu JSON-LD<ref>[http://blog.schema.org/2013/06/schemaorg-and-json-ld.html blog.schema.org]</ref> und gibt Beispiele parallel zu RDFa und Microdata auch in JSON-LD. {{Anker|schema.org-Kontext}} Seit Mitte Juni 2014 wird außerdem ein JSON-LD-Kontext bereitgestellt.<ref>[https://lists.w3.org/Archives/Public/public-linked-json/2014Jun/0020.html lists.w3.org]</ref><ref>Damit werden auch (schon länger im Umlauf befindliche) Beispiele generell funktionsfähig, die [https://schema.org/ schema.org] als @context referenzieren. Dies war vorher nur in Umgebungen der Fall, welche diese URL intern mit einem passenden Kontext verbanden.</ref> Wenig später zog auch [[FOAF]] gleich<ref>{{Webarchiv |url=http://comments.gmane.org/gmane.comp.web.rdfweb/4295 |text=gmane.org |wayback=20140714200742 |archiv-bot=2022-11-19 15:30:15 InternetArchiveBot}}</ref> und stellt sogar die Ontology ([[RDF-Schema]]/[[Web Ontology Language|OWL]]) direkt in JSON-LD zur Verfügung.

Die erste RDF-Version von [[WordNet]]<ref>[http://wordnet-rdf.princeton.edu/ wordnet-rdf.princeton.edu]</ref> (vorgestellt im April 2014)<ref>{{Webarchiv |url=http://t171795.web-semantic-linking-open-data.htmltalk.us/princeton-wordnet-rdf-t171795.html |text=htmltalk.us |wayback=20140714133127 |archiv-bot=2018-04-16 15:11:37 InternetArchiveBot}}</ref> 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 [[Resource Description Framework|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]].<ref name="json-ld-origins-2" /> 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<ref name="3gen-web-apis" />) 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 [[Representational State Transfer|REST]]-Stil für ''[[hypermedia]]-getriebene<ref name="hypermedia-driven" /> Webdienste'' (der nächsten Generation) diskutiert.<ref name="jsonld4rest-paper" />

In '''Hydra'''<ref>[http://www.hydra-cg.com/ www.hydra-cg.com]</ref> (das seit Juni 2013 auch Gegenstand einer [[World Wide Web Consortium|W3C]] Community Group ist) kommt JSON-LD auf folgenden Ebenen zum Einsatz: (1)&nbsp;in den Nachrichten (mittels des API-Vokabulars des jeweiligen Dienstes), (2)&nbsp;in der (semantischen) API-Beschreibung (mittels des Hydra-Vokabulars sowie anderer wohlbekannter) und (3)&nbsp;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 [[Web Services Description Language|WSDL]] (inklusive [[SAWSDL]]) und [[Web Application Description Language|WADL]] bzw. des HTML+RDFa in SA-REST sowie an diejenige des Mikroformats in hRESTS und Micro[[Web Service Modeling Ontology|WSMO]] treten. Zugleich modelliert es REST wie WADL und MicroWSMO.<ref name="3gen-web-apis" />

Seit April 2014 gibt es neben Hydra ein weiteres (für JSON-LD ausgelegtes) Vokabular,<ref>[http://blog.schema.org/2014/04/announcing-schemaorg-actions.html blog.schema.org]</ref> 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.<ref>[https://www.w3.org/wiki/images/1/10/PotentialActionsApril11.pdf w3.org] (PDF; 1,2&nbsp;MB) [https://www.w3.org/wiki/WebSchemas/ActivityActions w3.org]</ref> Wie in Hydra können Eingabe-Elemente sogar an die [[Parameter (Informatik)|Parameter]] von [[URL-Template]]s (nach <nowiki>RFC&nbsp;6570</nowiki><ref>{{RFC-Internet |RFC=6570 |Titel=URI Template |Datum=2012-03}}</ref>) 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 [[Hypermedia|Hypermediums]]. Dienste wie [[Suchmaschine]]n 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. [[Inserat|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 2.0|Activity Streams]]'' (und der zugehörigen Action Handlers)<ref>[https://activitystrea.ms/ activitystrea.ms] [http://tools.ietf.org/html/draft-snell-activitystreams-actions-06 tools.ietf.org]</ref> 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 „[[Out of band|außerhalb des Kanals]]“) soll damit weitgehend der Vergangenheit angehören.

== Siehe auch ==

* [[Semantic Web Services]]
* [[Web Service Modeling Ontology]]

== Weblinks ==

* [https://json-ld.org/ json-ld.org] – Seite für Entwickler mit Browser-Tool („[https://json-ld.org/playground/index.html Playground]“) (englisch)
* [http://www.markus-lanthaler.com/jsonld/playground/ JsonLD Playground von Markus Lanthaler] – Alternativer Spielplatz in [[PHP]] (englisch)
* [http://semanticweb.com/tag/json-ld Artikel mit dem Tag JSON-LD bei semanticweb.com] (englisch)
<!--http://notes.3kbo.com/json-ld -->
<!-- Spam-Filter schlägt Alarm https://de.wikipedia.org/wiki/Spezial:Missbrauchsfilter-Logbuch/427770
* [http://dbpedia.org/page/JSON-LD JSON-LD bei DBpedia] – Daten ''über'' JSON-LD auch ''in'' JSON-LD (durch Link am Seitenfuß) (englisch) -->

== Einzelnachweise und Anmerkungen ==
<!--

Vermerk für Bearbeiter (nach Möglichkeit stehen lassen):
Entscheidung des Artikel-Starters war: Alle Quellenangaben (zumindest aber die potenziell mehrfach referenzierten, die voraussichtlich länger im Artikel verbleiben) hier und alle sonstigen Anmerkungen im Text.

Bei Tilgung der letzten Referenz aus dem Text zeigt MediaWiki eine entsprechende Meldung. Die ref mit dem angezeigten Namen wäre dann hier zusätzlich zu löschen.

-->
<references>
<ref name="json-ld-api">
{{cite web|url=https://www.w3.org/TR/2014/REC-json-ld-api-20140116/|title=JSON-LD 1.0 Processing Algorithms and API, W3C Recommendation 16 January 2014|author=Markus Lanthaler, Gregg Kellogg, Manu Sporny, Editors|accessdate=2014-06-04}}
</ref>
<ref name="json-ld">
{{cite web|url=https://www.w3.org/TR/2014/REC-json-ld-20140116/|title=JSON-LD 1.0, A JSON-based Serialization for Linked Data, W3C Recommendation 16 January 2014|author=Manu Sporny, Gregg Kellogg, Markus Lanthaler, Editors|accessdate=2014-06-04}}
</ref>
<ref name="linked-json">
{{cite web|url=http://manu.sporny.org/2011/linked-json/|title=Linked JSON: RDF for the Masses|author=Manu Sporny|work=The Beautiful, Tormented Machine|accessdate=2014-06-01}}
</ref>
<ref name="json-ld-origins-2">
{{cite web|url=http://manu.sporny.org/2014/json-ld-origins-2/|title=JSON-LD and Why I Hate the Semantic Web|author=Manu Sporny|work=The Beautiful, Tormented Machine|accessdate=2014-06-06}}
</ref>
<ref name="json-ld-is-the-bees-knees">
{{cite web|url=http://manu.sporny.org/2013/json-ld-is-the-bees-knees/|title=JSON-LD is the Bee’s Knees|author=Manu Sporny|work=The Beautiful, Tormented Machine|accessdate=2014-06-04}}
</ref>
<ref name="has-been-published">
{{cite web|url=https://www.w3.org/blog/data/2014/01/16/json-ld-has-been-published-as-a-w3c-recommendation/|title=JSON-LD Has Been Published as a W3C Recommendation|author=Ivan Herman|accessdate=2014-06-07}}
</ref>
<ref name="rdf-in-json">
Keith Alexander: ''RDF in JSON: A Specification for serialising RDF in JSON'' In: [https://ceur-ws.org/Vol-368/ Proceedings of the 4th Workshop on Scripting for the Semantic Web], Tenerife, Spain, June 02, 2008, [https://ceur-ws.org/ CEUR Workshop Proceedings], {{ISSN|1613-0073}}, [https://ceur-ws.org/Vol-368/paper16.pdf CEUR-WS.org] (PDF; 116&nbsp;kB)
</ref>
<ref name="3gen-web-apis">
Markus 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&nbsp;5.3, Seiten&nbsp;108–141, über [http://www.markus-lanthaler.com/publications markus-lanthaler.com] (PDF) [[SHA1]]&nbsp;0ab17eed62aeb2f56e8f8b1ab95ac9820e36c87a, abgerufen am 8. Juni 2014
</ref>
<ref name="rdf-json">
[https://www.w3.org/TR/rdf-json/ ''RDF 1.1 JSON Alternate Serialization (RDF/JSON)''.] W3C Working Group, Note 7. November 2013
</ref>
<ref name="the-state-of-rdf-and-json">
David Wood: [https://www.w3.org/blog/SW/2011/09/13/the-state-of-rdf-and-json/ ''The State of RDF and JSON''.] 13. September 2011. In: ''Semantic Web Activity News''
</ref>
<ref name="rdfj">
{{cite web|url=http://code.google.com/p/backplanejs/wiki/Rdfj|title=Rdfj|work=[http://code.google.com/p/backplanejs/ backplanejs – A JavaScript library that provides cross-browser XForms, RDFa, and SMIL support.]|author=Mark Birbeck (u.&nbsp;a.)|accessdate=2014-06-09}}
</ref>
<ref name="JSON+RDF">
{{cite web|url=https://www.w3.org/wiki/index.php?title=JSON%2BRDF&oldid=53808|title=JSON+RDF|work=w3.org|accessdate=2014-06-09}}
</ref>
<ref name="rdf11-concepts">
{{cite web|url=https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/|title=RDF 1.1 Concepts and Abstract Syntax – W3C Recommendation 25 February 2014|author=Richard Cyganiak, David Wood, Markus Lanthaler|work=W3C Recommendation|accessdate=2014-06-11}}
</ref>
<ref name="rdf11-mt">
{{cite web|url=https://www.w3.org/TR/2014/REC-rdf11-mt-20140225/|title=RDF 1.1 Semantics – W3C Recommendation 25 February 2014|author=Patrick J. Hayes, Peter F. Patel-Schneider|work=W3C Recommendation|accessdate=2014-06-11}}
</ref>
<ref name="jsonld4rest-paper">
Markus Lanthaler, Christian Gütl: ''On Using JSON-LD to Create Evolvable RESTful Services'' In: ''Proceedings of the'' [http://www.ws-rest.org/2012/Third ''International Workshop on RESTful Design''.]{{Toter Link |date=2018-04 |archivebot=2018-04-16 15:11:37 InternetArchiveBot |url=http://www.ws-rest.org/2012/Third}} 2012, S. 25–32, über [http://www.markus-lanthaler.com/publications markus-lanthaler.com] (PDF) [[SHA1]] ba69b6c33792344fb189903792ec955af4aa0a98, abgerufen am 21. Juni 2014
</ref>
<ref name="sparql11-results-json">
[https://www.w3.org/TR/sparql11-results-json/ SPARQL 1.1 Query Results JSON Format]
</ref>
<ref name="hypermedia-driven">
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.)<!-- passender Hauptartikel dazu? bei RESTful?; und „hypermedia-getrieben“ scheint auch kaum jemand zu benutzen ... oh, je --></ref>
<ref name="draft-kelly-json-hal-06">
M. Kelly: [http://tools.ietf.org/html/draft-kelly-json-hal-06 ''JSON Hypertext Application Language''.] In: Internet Engineering Task Force (IETF) Draft
</ref>
<ref name="draftpbryan-zyp-json-ref-03">
P. C. Bryan, K. Zyp: [http://tools.ietf.org/html/draftpbryan-zyp-json-ref-03 ''JSON Reference''.]{{Toter Link |date=2018-04 |archivebot=2018-04-16 15:11:37 InternetArchiveBot |url=http://tools.ietf.org/html/draftpbryan-zyp-json-ref-03}} In: Internet Engineering Task Force (IETF) Draft.
</ref>
<ref name="iri-deref">
Die alternative, format-neutrale AlbertsIRI aus dem Kommentar [[#API-Beispiel|zum API-Beispiel]] ist eigentlich vorzuziehen, stellt jedoch wegen [[Content Negotiation]] und [[Weiterleitung|HTTP-Redirects]] höhere Anforderungen an den eingebauten oder benutzerdefinierten documentLoader bzw. an das Zusammenspiel mit der DBpedia. Siehe auch:<br /> {{cite web |author=Chris Bizer, Richard Cyganiak, Tom Heath |title=How to Publish Linked Data on the Web |url=http://wifo5-03.informatik.uni-mannheim.de/bizer/pub/LinkedDataTutorial/ |accessdate=2014-06-06 |offline=yes |archiveurl=https://web.archive.org/web/20210419093458/http://wifo5-03.informatik.uni-mannheim.de/bizer/pub/LinkedDataTutorial/ |archivedate=2021-04-19 |archivebot=2022-11-19 15:30:15 InternetArchiveBot}} und<br /> {{cite web |author=Leo Sauermann, Richard Cyganiak (eds.) |title=Cool URIs for the Semantic Web |url=https://www.w3.org/TR/cooluris/ |accessdate=2014-06-11 |work=W3C Interest Group Note}} (Work in progress), sowie<br /> 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 Option [http://linkeddatabook.com/book Free HTML Version], abgerufen am 11. Juni 2014, Chapter 2.3 Making URIs Defererenceable (Schreibfehler im Original)
</ref>
</references>

{{Navigationsleiste W3C-Standards}}

[[Kategorie:Datenformat]]
[[Kategorie:Semantisches Web]]
[[Kategorie:JSON]]