JSON-LD (Akronym von für „JSON-basierte Serialisierung für verLinkte Daten“) bezeichnet Empfehlungen des W3C, weltweit verknüpfte Daten (nach dem RDF-Modell) im schlanken JSON-Format einzubetten. Damit können Webservices und Webapplikationen, die ihre Daten bevorzugt in JSON austauschen, leichten Anschluss zum Semantischen Web finden und reibungsloser zusammenarbeiten, indem sie global eindeutige Bezeichnungen für logisch geordnete Begriffe verwenden.
Die Entwicklung begann 2010 und führte im Januar 2014 zur Verabschiedung zweier Dokumente über die erste Version.
Für die Industrie ist die Einbettung in das etablierte JSON interessant, weil sie so den zugehörigen Baukasten aus Parsern, SpeichernFür praktisch jede Programmiersprache, die zur Webentwicklung benutzt wird, gibt es eine Konvention, JSON-Daten im Hauptspeicher zu verwalten. bzw. Datenbanken,namentlich vom NoSQL-Typ, der JSON nativ unterstützt wie MongoDB und CouchDB, aber auch SQL-Datenbanken mit JSON-Unterstützung wie PostgreSQL u. a. Programmiersprachen-Anbindungen, sowie Know-how u. ä. weiter verwenden könnte. Die Entwickler versuchten sich daran zu orientieren, wie JSON bisher zum Datenaustausch genutzt wird. Dadurch soll die Umstellung einer Software von JSON auf JSON-LD möglichst einfach sein. Hierzu kann es bereits ausreichen, einen ansonsten unveränderten JSON-Text mit einem sogenannten Kontext zu verknüpfen (siehe Abschnitt Technik und Grundbegriffe von JSON-LD).
Anwender von JSON-LD, welche hauptsächlich an herkömmlichem JSON interessiert sind, müssen RDF nicht verstehen. Gleichzeitig stellt das Datenmodell von JSON-LD eine Erweiterung des RDF-Modells dar.
Abgrenzung und Einordnung
JSON-LD verhält sich zu JSON ähnlich, wie sich RDFa, HTML Microdata bzw. ein Microformat jeweils zu HTML verhält: Programme, welche herkömmliches JSON erwarten (hier das Trägerformat), werden durch die Erweiterung zu JSON-LD praktisch nicht beeinträchtigt. Gleichzeitig gestattet es ebenso die Anreicherung um (maschinell interpretierbare) Bedeutung wie die anderen Verfahren (semantische Annotation).
Ein wesentlicher Unterschied besteht darin, dass JSON keine Markup-Sprache zur Präsentation von Inhalten wie HTML ist (und durch JSON-LD auch zu keiner wird): Eine dem Durchschnittsnutzer präsentable Darstellung des Inhalts müsste entweder erst gewonnen oder in einem anderen Format beigefügt werden. Dies hat neben der Kreation eines weiteren Formats für das Semantic Web vereinzelt zu Kritik geführt.
Der traditionelle Einsatzort von JSON ist jedoch nicht die Schnittstelle zwischen Mensch und Maschine, sondern die zwischen Maschinen untereinander. Die Trennung von (typographischem) Markup und semantischen Daten kann sogar eine Vereinfachung darstellen. JSON ersetzt hierbei XML abseits von XHTML. XML-Parser, RDF-Speicher und SPARQL-Maschinerie werden im Web-Umfeld zuweilen als „Overhead“ empfunden. Selbst handliche Formate aus dem RDF-Umfeld (wie Turtle) werden kaum als Basisformat in Web-Protokollen genutzt. JSON-LD soll Probleme lösen, die sich mit den anderen Formaten nicht lösen ließen.
Im Gegensatz zu anderen Serialisierungsformaten für Linked Data bzw. RDF, die Tripel-orientiert sind, bleibt JSON-LD auch in seiner flachen Vorzugsform Entität-zentriert: Alle ausgehenden Prädikatskanten des Graphen sind nach dem RDF-Subjekt gruppiert und alle RDF-Objekte nach Subjekt und Prädikat.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.Ebenso für Mengen von Graphen, die flach als 4-Tupel (Quads) repräsentiert werden würden: Gruppierung nach dem Namen der Menge.
Gemeinsam mit TriG und N-Quads, sowie im Unterschied zu Turtle unterstützt JSON-LD mehrere (benannte) Graphen (RDF datasets).What’s New in RDF 1.1 w3.org Im Gegensatz zu N-Triples und N-Quads, sowie gemeinsam mit Turtle ist es nicht auf eine flache Tupel-Repräsentation festgelegt. Anders als RDFa bzw. RDF/XML ist es nicht (X)HTML bzw. nicht XML-basiert.
JSON-LD beinhaltet (gegenüber JSON) eine Standardkonvention, um mittels IRIs (externe) Referenzen bzw. einfache Links darzustellen (ähnlich Erweiterungen wie JSON Reference, jedoch ohne die Interpretation des Fragmentbezeichners als JSON Pointer; JSON-LD folgt hier RDF-Gepflogenheiten). Außerdem kann es standardisiert Datentypen und Schema-Informationen aus dem RDF-Umfeld einbinden. (Anders als JSON Schemajson-schema.org setzt es dabei nicht auf gesonderte bzw. JSON-spezifische Verfahren. Eine Prüfung mittels JSON Schema ist jedoch nicht ausgeschlossen.Beispielsweise verwendet das Popolo Project JSON Schema und JSON-LD-Kontexte parallel, um für eine einheitliche und validierbare JSON-Form zu sorgen.)
Zwar stellt JSON-LD selbst keine eigene Sprache für (HTML-freie) Hypertext- bzw. HTTP-Anwendungen (im REST-Stil) zur Verfügung (wie etwa JSON HAL oder JSON Hyper-Schema). Eine solche ist jedoch über entsprechende Vokabulare zur Dienst- bzw. Schnittstellenbeschreibung einbindbar. Siehe auch: Abschnitt Im Bereich der Web-APIs.
JSON-LD ist nicht kompatibel mit (dem älteren) RDF/JSON. Siehe auch: Abschnitt Vorgänger und Alternativen.
Syntax
Welche JSON-Texte umgekehrt auch gültiges JSON-LD darstellen, ist Gegenstand hauptsächlich des ersten Dokuments. Ein JSON-LD-Text muss u. a.
ein JSON-Objekt sein oder ein JSON-Array aus solchen Objekten
(während neuere Fassungen von JSON bzw. JSON-Parser hier auch andere JSON-Werte erlauben.)
Alle Namen bzw. Schlüssel der Name-Wert-Paare müssen pro Objekt eindeutig sein (was bei JSON nach IETF nur so sein sollte und nach ECMA von der Auslegung abhängt). Außerdem muss auf die leere Zeichenkette als Name verzichtet werden, weil nicht alle JSON-Implementierungen diese handhaben können.
Alle weiteren Syntax-Elemente von JSON-LD werden über spezielle JSON-Strings realisiert (sogenannte Schlüsselwörter), die mit dem Zeichen „@“ beginnen und von denen es bisher dreizehn gibt (@context, @id, @value, @language, @type, @container, @list, @set, @reverse, @index, @base, @vocab, @graph). Im Hinblick auf spätere Erweiterungen wird empfohlen, andere Namen mit diesem Anfang u. a. als JSON-Name (bzw. -Schlüssel) zu vermeiden. Solche haben aber bis dahin keine spezielle Bedeutung.
Eine besondere Bedeutung kommt dem „:“ in Zeichenketten an bestimmten Stellen zu (wodurch sie kontextabhängig als kompakte IRIs oder als absolute IRIs interpretiert werden können, solange eine benutzerdefinierte Definition für die Zeichenkette als Ganzes dies nicht außer Kraft setzt).
Grundsätzlich spielt die Reihenfolge der Paare keine Rolle. Das spezielle Paar mit dem Namen @context sollte am Anfang stehen, wenn man in Zukunft auch effizientere Datenstrom-Parser unterstützen möchte (welche eine Expansion so bereits während des Lesens durchführen könnten).
Die darauf basierende Grammatik umfasst verschiedene Typen von JSON-Objekten (node object, value object, list object, set object, language map, index map und context definition).
Die grundlegenden und fortgeschrittenen Konzepte von JSON-LD werden in nicht normativen Abschnitten anhand von Beispielen eingeführt. Die formalste Definition besteht aus über achtzig normativen Sätzen in englischer Sprache. Formalismen wie EBNF oder Syntaxdiagramme werden nicht angewendet. Es wird keine Sprache von Grund auf neu entworfen. JSON-LD bezieht sich auf die Grammatiken der IETF aus RFC 4627 (JSON), RFC 3987 (IRIs), BCP47 alias RFC 5646 alias BCP47 (Sprachkennzeichen, language tags, siehe auch: ISO 639).
Ausgangspunkt und Grundlagen
Bei der maschinellen Interpretation von Daten, hier im JSON-Format, werden grundlegende Fragen der Bedeutungswissenschaft berührt. Menschen können diese nachvollziehen, wenn man hierzu Zeichenketten präsentiert, mit denen die meisten Leser keine Bedeutung verbinden können (wie die Wörter einer fremden Sprache).
{ "xfvhgr": "bzmxmhfg", "ozwqrsmm": "1879-03-14" }
Selbst wer das JSON-Format lesen kann, wird hier nur dessen Elemente erkennen, wie die Paare aus Namen und Werten. Eine inhaltliche Bedeutung oder gar Aussage kann er damit nicht verbinden.
Einer Maschine ginge es (stellvertretend für ihren Programmierer) dabei zunächst nicht viel anders: Ohne (einem maschinenlesbaren) „Wörterbuch“ oder „Lexikon“ mit passenden Einträgen ist eine Deutung technisch offenbar schwer erklärbar. (Bei der Kommunikation von Maschinen wäre weiter anzunehmen, dass die Teilnehmer sich in jeder Situation auf dasselbe Wörterbuch verständigt hätten, siehe auch: Kontextualisierung und Kontext. Außerdem wäre ein primitives Basisvokabular vorauszusetzen, dessen Bedeutung bei den Teilnehmern (durch Konstruktion, Evolution oder Sozialisation auf niederer oder kognitiver Ebene) bereits verankert ist.)
Bezeichner, mit denen nicht zumindest die meisten Softwareentwickler etwas verbinden können, sind zwar untypisch. (Häufig verwendet werden Lexeme des Englischen.) Dennoch gibt es auch bei verständlichen bzw. selbstsprechenden Bezeichnern oft noch mehrere Alternativen für „dasselbe“ (Synonymie) und Raum für Fehlinterpretationen aufgrund von Mehrdeutigkeiten (siehe auch: Homonym bzw. Polysemie, sowie Disambiguierung).
Eine technische Lösung besteht u. a. darin, möglichst nur noch global eindeutige Bezeichner zu verwenden (hier: IRIs) bzw. alle anderen in solche zu übersetzen. Ein Rahmenwerk hierzu bietet RDF bereits. Ein Verfahren, dies in JSON nutzen zu können, wurde durch JSON-LD nun im technischen Detail normiert.
Von JSON zu JSON-LD
JSON ist zunehmend in den APIs verbreiteter Webservices anzutreffen, wie denen von Google, Twitter, Facebook und vielen anderen.
JSON-Objekte bestehen aus Paaren von Namenauch: Schlüssel, Schlüsselwerte oder Eigenschaften genannt und Werten. Dabei wird oft dieselbe Information – wie ein Geburtsdatum – durch unterschiedliche Namen wie etwa „born“, „born_on“, „dateOfBirth“, „DOB“ oder „дата рождения“ angesprochen. Bei der Zusammenführung durch einen übergreifenden Dienst (z. B. im Rahmen eines Semantic Mashups) fehlt ein Verzeichnis oder Wörterbuch, wie eine bestimmte Information in JSON-Nachrichten bzw. -Dokumenten aus den verschiedenen Quellen identifizierbar wäre.
Zwar könnte jeder, der mit mehreren Quellen arbeitet, für sich ein solches Verzeichnis erstellen, pflegen und fest mit seiner Software verbinden. Es wäre jedoch praktischer, wenn alle Datenlieferanten ihre JSON-Daten explizit mit einer maschinenlesbaren „Interpretationshilfe“ (ebenfalls in JSON) verknüpfen würden (Selbstbeschreibung). Auch wenn diese Zusatzinformation nicht von den Datenquellen stammt oder nur eine einzige Quelle zur Disposition stünde, müsste sie bei der Verarbeitung von JSON-Daten irgendwie eingebracht werden können.
Technik und Grundbegriffe von JSON-LD
In JSON-LD kann diese Hilfe bei der Deutung nun durch den speziellen Namen bzw. das Schlüsselwort @context geleistet werden:
{ "@context": { "born": "http://schema.org/birthDate" }, "born": "1879-03-14" }
Dies sagt einem Computerprogramm (welches diesen Text als JSON parst und als JSON-LD interpretiert), dass der Wert mit dem Namen „born“ verbindlich im Sinne des „birthDate“ aus dem Schema.org-Vokabular zu verstehen ist (also als Kalenderdatum der Geburt einer Person). Für eine herkömmliche JSON-Anwendung, welche den Kontext nicht beachtet, ändert sich praktisch nichts. Sie verwendet weiterhin ihre fest eingebaute Interpretation für diese Datenquelle.
Zu weiteren Möglichkeiten, JSON-Daten in einen solchen Kontext zu stellen (Kontextualisierung), siehe auch Abschnitt Alternative Kontextualisierung.
An der Interpretation ändert sich für eine JSON-LD-Anwendung auch nichts, wenn man durchgängig den Term „born“ durch „birthdate“ ersetzen würde, weil er weiter zum selben IRI von Schema.org übersetzt wird bzw. „expandiert“.