JSON-LD

JSON-LD
File extension :	.jsonld
MIME type :	application / ld + json
Developed by:	World Wide Web Consortium (W3C)
Current version:	1.0 (as of January 16, 2014)
Type:	concrete syntax of RDF
Container for:	Linked data
Extended by:	JSON , RDF
Standard (s) :	JSON-LD 1.0 ; JSON-LD 1.0 Processing Algorithms and API (W3C Recommendations)
Website :	json-ld.org

JSON-LD ( acronym of . English for " JSON -based serialization for ver L inkte D ata") refers to the recommendations of the W3C , the world linked data (after the RDF model) in a compact JSON - format embed. This means that web services and web applications that prefer to exchange their data in JSON can easily connect to the Semantic Web and work together more smoothly by using globally clear names for logically ordered terms .

Development began in 2010 and resulted in the adoption of two documents on the first version in January 2014.

Embedding in the established JSON is interesting for the industry because it enables the associated construction kit of parsers , memories or databases , programming language connections, as well as know-how and the like. Ä. could continue to use. The developers tried to orientate themselves on how JSON has been used for data exchange up to now. This should make it as easy as possible to convert software from JSON to JSON-LD. To do this, it may be sufficient to link an otherwise unchanged JSON text with a so-called context (see section Technology and Basic Terms of JSON-LD ).

JSON-LD users who are mainly interested in traditional JSON do not need to understand RDF . At the same time, the data model of JSON-LD represents an extension of the RDF model.

Delimitation and classification

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

Memo image for embedding the RDF triples (colored, italic) in JSON (black)

JSON-LD behaves in a similar way to JSON as RDFa , HTML Microdata or a microformat behaves in relation to HTML : Programs that expect conventional JSON (here the carrier format) are practically not affected by the extension to JSON-LD. At the same time, it also allows for (machine interpretable) meaning to be added, as does the other methods ( semantic annotation ).

An essential difference is that JSON is not a markup language for the presentation of content such as HTML (and JSON-LD does not become one either): A representation of the content that is presentable to the average user would either have to be obtained first or added in a different format. In addition to the creation of a further format for the semantic web, this has occasionally led to criticism.

However, the traditional place of application of JSON is not the interface between man and machine , but the one between machines. The separation of (typographical) markup and semantic data can even represent a simplification. JSON replaces XML apart from XHTML . XML parsers , RDF memories and SPARQL machinery are sometimes perceived as " overhead " in the web environment . Even handy formats from the RDF environment (such as Turtle ) are rarely used as a basic format in web protocols . JSON-LD is intended to solve problems that cannot be solved with the other formats.

In contrast to other serialization formats for linked data or RDF , which are triple- oriented, JSON-LD also remains entity- centered in its flat preferred form: All outgoing predicate edges of the graph are grouped according to the RDF subject and all RDF objects according to subject and predicate.

Together with TriG and N-Quads , and in contrast to Turtle , JSON-LD supports several (named) graphs (RDF datasets). In contrast to N-Triples and N-Quads, as well as together with Turtle, it is not restricted to a flat tuple representation. Unlike RDFa or RDF / XML , it is not (X) HTML or XML-based.

JSON-LD contains (compared to JSON) a standard convention to represent (external) references or simple links by means of IRIs (similar extensions to JSON Reference, but without the interpretation of the fragment identifier as a JSON pointer; JSON-LD follows RDF practices here). It can also integrate standardized data types and schema information from the RDF environment. (Unlike the JSON scheme, it does not rely on separate or JSON-specific procedures. However, a check using the JSON scheme is not excluded.)

It is true that JSON-LD itself does not provide its own language for ( HTML- free) hypertext or HTTP applications (in REST style) (such as JSON HAL or JSON Hyper-Schema). However, this can be integrated into the description of services or interfaces using appropriate vocabulary . See also: Section In the area of the web APIs .

JSON-LD is not compatible with (the older) RDF / JSON. See also: Section Predecessors and Alternatives .

syntax

Regarding the syntax of JSON :

Every JSON-LD text is a valid JSON text (according to RFC 4627 ).

Which JSON texts, conversely, also represent valid JSON-LD, is mainly the subject of the first document. A JSON-LD text may have to be a.

be a JSON object or
a JSON array of such objects

(while newer versions of JSON or JSON parser also allow other JSON values here.)

All names or keys of the name-value pairs must be unique for each object (which should only be the case with JSON according to IETF and according to ECMA depends on the interpretation). In addition, you have to do without the empty string as a name, because not all JSON implementations can handle this.

All other syntax elements of JSON-LD are implemented using special JSON strings (so-called keywords ) that begin with the " @ " character and of which there are currently thirteen (@context, @id, @value, @language, @ type, @container, @list, @set, @reverse, @index, @base, @vocab, @graph). With a view to future expansions, it is recommended to use other names with this beginning u. a. as a JSON name (or key). Until then, however, these have no special meaning.

The ":" in character strings has a special meaning at certain places (whereby they can be interpreted as compact IRIs or as absolute IRIs depending on the context , as long as a user-defined definition for the character string as a whole does not override this).

In principle, the order of the pairs does not matter. The special couple named " @context " should be at the beginning, if you also more efficient in the future stream - parser would like to support (could so already conduct which an expansion during the reading).

The grammar based on it comprises different types of JSON objects (node object, value object, list object, set object, language map, index map and context definition).

The basic and advanced concepts of JSON-LD are introduced in non- normative sections using examples. The most formal definition consists of over eighty normative sentences in the English language. Formalisms such as EBNF or syntax diagrams are not used. No language is designed from scratch. JSON-LD relates to the IETF grammars from RFC 4627 (JSON), RFC 3987 (IRIs), BCP47 alias RFC 5646 (language tags, see also: ISO 639 ).

Starting point and basics

The machine interpretation of data , here in JSON format, touches on fundamental questions of the science of meaning . People can understand this if one presents character strings with which most readers cannot associate a meaning (such as words in a foreign language).

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

Even if you can read the JSON format, you will only recognize its elements here, such as the pairs of names and values. He cannot associate any meaning or statement with it.

A machine (on behalf of its programmer) would not do much differently: Without a (machine-readable) “ dictionary ” or “ lexicon ” with suitable entries, an interpretation is obviously difficult to explain from a technical point of view. (In the communication of machines would continue to assume that the participants had agreed in any situation on the same dictionary, see also: contextualization and context addition, a primitive basic vocabulary would assume, the meaning of the participants (by. Construction , Evolution or socialization on lower or cognitive level) is already anchored.)

Identifiers with which at least most software developers can not associate something are atypical. ( English lexemes are often used .) Nevertheless, there are often several alternatives for "the same" ( synonymy ) and room for misinterpretation due to ambiguity (see also: homonym or polysemy , as well as disambiguation ).

A technical solution is u. a. to use only globally unique identifiers if possible (here: IRIs ) or to translate all others into such. RDF already offers a framework for this . A method for using this in JSON has now been standardized in technical detail by JSON-LD .

From JSON to JSON-LD

JSON is increasingly found in the APIs of popular web services such as those of Google , Twitter , Facebook and many others.

JSON objects are made up of pairs of names and values. Often the same information - like a date of birth - is addressed by different names such as "born", "born_on", "dateOfBirth", "DOB" or "дата рождения". When merging through a comprehensive service (e.g. as part of a semantic mashup ), a directory or dictionary is missing as to how certain information in JSON messages or documents from the various sources can be identified.

Anyone who works with multiple sources could create and maintain such a directory for themselves and link it to their software. It would be more practical, however, if all data providers would explicitly link their JSON data with a machine-readable "interpretation aid" (also in JSON) (self-description). Even if this additional information does not come from the data sources or if only a single source is available, it should somehow be brought into the processing of JSON data.

Technology and basic concepts of JSON-LD

In JSON-LD, this help for the interpretation can now be provided by the special name or the keyword @context :

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

This tells a computer program (which parses this text as JSON and interprets it as JSON-LD) that the value with the name "born" is binding in the sense of the "birthDate" from the Schema.org vocabulary ( i.e. as the calendar date of the Birth of a person). For a conventional JSON application that ignores the context, practically nothing changes. It continues to use its built-in interpretation for this data source.

For further options for placing JSON data in such a context ( contextualization ), see also section Alternative contextualization .

The interpretation does not change for a JSON-LD application if one were to consistently replace the term “born” with “birthdate” because it continues to be translated or “expanded” to the same IRI by Schema.org.

The meaning of such a document becomes clearer in the so-called expanded (and here additionally flat) form, which allows context-independent processing (see also: Section Algorithms and Forms ).

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

Here, all names defined in the context such as "born" were expanded to an absolute IRI (and all values or literals were also replaced by an explicit value object with the keyword @value , all individual literals and node objects to (single-element) JSON Arrays unified and all node objects without @id element given a local ID; see also: Section Algorithms and Shapes ). In this form, data that were originally in different contexts can also be processed in a uniform manner without any misinterpretation.

The RDF graph of two nodes and an edge contained in this document makes the following statement: "Someone (or something) (with the document-local ID '_: b0') was (in the sense of Schema.org) on 14 Born March 1879. "

Anonymous and untyped nodes are sometimes not enough. Globally uniquely named and typed entities or literals (using the keyword “@type” ) are possible using IRI . In the following, a person (in the sense of FOAF ) "Albert Einstein" (in the sense of DBpedia ) is assigned a date of birth (in the sense of Schema.org and in the notation according to XML schema ).

{
  "@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” is an example of a compact IRI , which is used here to abbreviate

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

serves. It consists of a term in front of the colon ( prefix term), which has to expand to an absolute IRI due to the context, and the rest after it ( suffix ), which is appended to it unchanged. (Of note is this: If the prefix is undefined, is the term for the colon already an absolute IRI.)

Ontologies are usually not mixed up for no reason. In general, it is recommended to be thrifty. (For some applications or areas of application (social networks, libraries, payment systems, etc.) some are specially designed.) The consistent use of a single or a main vocabulary can be abbreviated with the keyword @vocab . All terms that are not defined differently are interpreted as originating from this ( default prefix).

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

However, this has the side effect that now all terms that are not explicitly defined as “zero” in the context are taken as terms from this vocabulary. Without “@vocab”, the JSON values of terms without an explicit definition in the context would be hidden in the JSON-LD view of the data.

JSON-LD allows so-called keyword aliasing : A term can also expand to a keyword like “@type” or “@id” (but not to “@context”). Does a web service use e.g. E.g. the name "is_a" for typing and "oid" for identifying the objects (using JSON strings, no numbers), this can be made explicit or clear as follows:

{
  "@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 applications that do not pay attention to the context remain unaffected.

Not demonstrated were u. a. Means for language marking and multilingualism of strings, lists (containers), indexing , named graphs , relative IRIs and basic IRI , inverse properties .

Alternative contextualization

The context does not have to be embedded directly, but can also be referenced via IRI :

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

If you were to save the content of the first example (except for the penultimate line) in a file called “person.jsonld” and make it available under this URL , this would lead to the same interpretation.

It is crucial for the smooth function that the URL actually leads to a context according to JSON-LD, so this can ideally be loaded via HTTP in JSON-LD format (or at least was once).

Alternatively, the context can also be created outside of the actual JSON text.

This is specifically provided for by the link header in an HTTP message (with a special link relation from the JSON-LD namespace). There would be no need to intervene in the actual application data, which can make migration easier. The contextURL from the link header is only taken into account with a content type “application /[...+] json” not equal to “application / ld + json”. More on this in the section Requiring JSON-LD .

The programming interface also offers an optional parameter (option expandContext, see: Section API ).

A context can appear in every JSON object (except in context definitions themselves), not just in the outer. Not explained further here u. a. the combination or accumulation of contexts through nesting in the JSON structure, as well as through sequencing in the form of a JSON array. There are also empty contexts to break a combination chain.

Algorithms and forms

JSON-LD Processing Algorithms and API is the other of the two W3C recommendations that were jointly adopted for the first version of JSON-LD. It covers useful transformations. It is only through this part that the interpretation or meaning of a JSON-LD text is explained formally or by calculation rules , in that u. a. also in this way the reference to the abstract syntax of RDF is established.

JSON-LD allows the same linked data (RDF graph) to be represented in more than one form. The preferred form generally depends on the application, such as processor (human or machine), transmission or storage with as little redundancy as possible, processing that is as simple as possible, and the like. a.

This recommendation defines calculation methods for conversion into particularly interesting forms

to expansion, which leads to expanded form
to compaction, which leads to compact or compacted form
to flattening, which leads to the flat or flattened shape

The repeated application of a transformation (as far as possible) no longer changes the result significantly ( standardization ). These algorithms are also normative! In fact, the shapes are fully defined or normalized only by the algorithms . Other statements about the forms are either non-normative, incomplete or derived from the algorithms (or to be derived). Furthermore, this results in a restriction with regard to valid entries: A JSON text that would be rejected without result or as faulty during expansion actually has no machine-usable interpretation as JSON-LD.

The expansion is the transformation of the most applications will be interested, who want to recoup the added value of JSON-LD against JSON (and that does not consistently use an expanded form, s. U.). It is important to note that all name / value pairs that cannot be interpreted in the JSON-LD model are removed. (As far as the API methods are concerned (see below) , expansion as an internal intermediate step is also inevitable.)

For a given context, the compression finds a form that is as compact as possible in this context, which (under this) expanded again has the same meaning (but not necessarily exactly the same) as the input. Expansion and compression are, to a certain extent, reversals of one another: the expansion makes the data context-independent. The compression depends on the context.

During compression, the conversion of single-element arrays into their single element can optionally be suppressed (option compactArrays).

The flattening provides (anonymous) node objects without "@id" with a document-wide unique (blank node identifier), such blends having the same "@id" and removed (deeper) nestings. The result is a JSON array of the RDF subjects with all of the outgoing predicate edges (at least one, including one @ type edge). Where they also appear as RDF objects, only an otherwise unproperty-free reference with the respective “@id” remains. This also applies to (untyped) node objects that only appear in the object role.

In this form, three to four nested loops are sufficient to enumerate all contained RDF triples . (See also: Example in the API section ) The “flat” therefore obviously refers (only) to a fixed or maximum recursion depth : The combination of a fixed number of iterative loops is sufficient.

When flattening, a slightly modified compression can optionally be added by specifying a (also empty) context, which leads to a somewhat more specific shape.

Applications that consistently use the flat form (see also: Section MIME type parameters ) could do without the algorithms at all.

For the most generic processing possible, applications choose either the flattened form (without subsequent compression). Or they condense (additionally) with a context that suits their purpose. The latter has the advantage that the handling of absolute IRIs can be largely eliminated.

Forming example

The following three JSON-LD texts are related as follows: a source text (handwritten or from an application) at the top left ; below the expanded and flattened form of it (without subsequent compression), here an anonymous node was named and replaced by a reference (and the pair with the undefined term "comment" removed); At the top right a condensed form of it in a modified context (including without type definitions, as well as with additional or differently named IRI prefixes and German-language terms and keyword aliases).

{
  "@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"
      }
    ]
  }
]

The @ graph element allows several node objects to share the same context.

Regardless of the shape, the graph it contains tells when Albert Einstein would have been born and at what altitude ( WGS84 ) his place of birth would be. Or in triple notation ( N-Triples , see also: 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".

Auxiliary procedures

As internal auxiliary method & Contact. a. on

Context processing ( Context Processing Algorithm ): Contexts can be combined and referenced by IRI. The result of these operations is again a context (accumulation). It must u. Cyclical payments may be rejected.

Generation of a term definition ( Create Term Definition ): This always occurs when a definition from a context flows into the (active) result context. Here, too, circular references are revealed and rejected.

Creation of an access structure ( Node Map Generation ), which groups according to the subjects and merges node objects with the same @id (see flattening).

So far u. a. not mentioned: IRI Expansion , Value Expansion , Inverse Context Creation , IRI Compaction , Term Selection , Value Compaction , Generate Blank Node Identifier .

However, these procedures are not recommended for the API (see below), even though they (in equivalent form) are hardly an indispensable part of an implementation of the same.

Relation to RDF

In addition, the serialization from , as well as the deserialization to the abstract RDF model (named sets of triples or graph sets) is defined and thus indirectly the conversion to or from any (other) concrete RDF syntax. Furthermore, the connection to the semantics of RDF is established. This includes u. a. the correspondence of the primitive JSON types and literals with those of XML schema and that of the JSON-LD lists with those of RDF schema . (Not mentioned here inter alia: language identification of strings).

MIME type parameters

The MIME type of JSON-LD provides an optional parameter “profile”. Its value (an IRI from the JSON-LD namespace) corresponds to the three forms mentioned.

This can prevent transformations from being unnecessarily carried out multiple times or from being omitted in the wrong expectation. The place of processing can also be negotiated (at the sender or receiver).

API

Finally, the programming interface of a JSON-LD processor is specified (JsonLdProcessor), but only non-normatively. This would provide uniform access to the three transformation processes ( methods : compact, expand, flatten) in programming environments, primarily also for the ECMAScript, which is widespread in the web environment . The interface is based on the promise abstraction for asynchronous programming. The Flatten and Compact methods from the API include expansion (and IRI dereferencing).

In order to do its job, the processor may have to ( recursively ) load external contexts referenced by IRI or URL (from a remote site) from the Internet or locally from a cache . In addition, the JSON-LD data should usually be loaded behind IRIs (dereferencing). The defined interface can be used to intervene in this loading procedure (JsonLdOptions documentLoader).

In an environment in which this API is available (and others), the following CoffeeScript would output the date of birth of Albert Einstein according to DBpedia (more precisely: all available ones, if no error occurs).

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

Programming interfaces for converting between JSON-LD and the RDF model are not part of the recommended API. The development process at the W3C has also produced sample implementations for this (toRDF, fromRDF). In addition, RDF frameworks or program libraries convert on this basis between their respective RDF abstraction and a JSON-LD form. See also section Program Libraries and Tools .

Processing of JSON-LD

Regardless of the source of a JSON-LD text: The same data can be interpreted as JSON-LD (in compact form) and expanded before processing or just parsed as simple JSON (as before a migration from JSON to JSON-LD). Different modules can also handle this differently.

Example from a JavaScript environment (e.g. web browser ):

// 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 ) )

Embedding in HTML

The script element is recommended for embedding JSON-LD in HTML:

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

This allows an application to access it through the DOM , including a. So also a JavaScript in the web browser :

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

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

Possible applications for this are initially the same as for RDFa , HTML Microdata and the like. a. The difference is mainly in how the semantic data is technically extracted. The link to HTML attributes and the interlinking with its element structure is no longer necessary. On the other hand, this is disadvantageous in environments that previously managed only with (X) HTML tools (since they would now also have to process JSON).

Application examples range from classic metadata about the document to a machine-readable representation of the complete text content (which is also formulated in natural language and intended for human reception). This could be an automatically generated order confirmation . The subsequent generation or enrichment of such content depending on the recipient's specifications would still be possible. A personal assistant or software agent could also react autonomously to this or offer actions. (See also: Section Applications and Users )

Request from JSON-LD

A JSON-LD context or data in this format are requested via HTTP preferably with the associated MIME type. (This can lead to negotiations about the content type and redirects ( status code 3xx , location header ).)

Test request, for example with cURL (in Bash with a URL in the variable $URL):

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

In the positive case, the (last) response is of the corresponding content type and contains usable JSON-LD.

(Note on the MIME type itself: application / ld + json is based (in the sense of RFC 6838 ) on a structured syntax (name) suffix "+ json", which is registered in RFC 6839. )

Particularly in the context of linked data , care should be taken with content of the type application / json, because in reality it may a. can also be of the incompatible format RDF / JSON, see also section Predecessors and alternatives .

Employees should (1) express a clear preference for “ld + json” (if possible via q parameters in the Accept header ) to the service provider and (2) for all other “json” types to a contextURL Pay attention to the link header (see also: Section Alternative contextualization ). Otherwise you risk receiving other JSON data (which in the JSON-LD view expand to an empty or otherwise unexpected triple set) without this being signaled as an error (by the standard API).

For smooth communication with as many data sources as possible, a custom document loader may be required, see section API .

Generally unproblematic are URLs that already contain a clear reference to the desired format (for example with the ending “.jsonld” or with a corresponding data type or format parameter ). This procedure is usually sufficient to refer to a JSON-LD context. (When requesting linked data for an entity (referenced by URL) it would contradict principles from this environment. For example, a service description for the respective source would first have to be taken as to how this URL would be formed. Generic or adaptable methods are therefore preferred. )

Program libraries and tools

Implementations of the recommended API and additional functions for processing JSON-LD are already available for several programming languages (as of June 2014).

The following are considered to conform to the specification based on the test reports for the associated test suite :

for JavaScript from Digital Bazaar, Inc. (browser, Node.js , command line , web app)
for Python PyLD from Digital Bazaar, Inc.
for PHP by Digital Bazaar, Inc. , by Markus Lanthaler
for Ruby within Ruby RDF
for Java from jsonld-java on Github
for C # within NuGet

Conversion between JSON-LD and other formats:

from RDFa: (also according to JSON-LD) using RDFa 1.1 Distiller and Parser by Ivan Herman ( since November 2011 )
RDF Translator ( RDFLib -based)
via a plugin within RDFLib at Github
in Ruby as an extension to RDF.rb in the Ruby RDF Project

Predecessors and alternatives

JSON-LD did not come out of nowhere, nor is the chosen structure for the representation of linked data in general and the serialization of RDF in particular the only possible one.

If you illustrate the serialization structure of JSON-LD with regard to RDF triples S (subject), P (predicate), O (object) as follows (flat form)

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

then the one from RDF / JSON looks like this:

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

whereby for objects O per "type" a distinction is made between literals and resources:

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

("[O]" here symbolizes the grouping of objects with the same subject and predicate in a JSON array.)

RDF / JSON (occasionally also: Talis RDF / JSON ) was no longer pursued by the W3C in favor of JSON-LD.

The flat triple scheme can also be found

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

Fundamental concepts have flowed into LD-JSON through the work on RDFj , some of which dates back to 2004.

As early as 2011, the W3C alone listed over a dozen other approaches to mapping RDF triples in JSON in its Wiki.

Alternatives in the narrower sense would be (1) valid JSON and (2) have a reference to RDF. Serialization forms of RDF or transport forms for linked data that do not lead to JSON are not treated here as alternatives in the narrower sense. (See Linked Data , RDF, if applicable .)

For the following formats, the recommendation uses examples to demonstrate that JSON-LD can express the semantic data it contains:

For some of them there are separate JSON forms (which contain remnants of the source format). As a long-term alternative, they only appear under the aspect of compatibility .

Alternative: Microdata + JSON

HTML Microdata from W3C is declared compatible with RDF and includes a separate conversion to JSON. It can therefore be viewed indirectly as an alternative to JSON-LD. The connection with a markup language is exactly what JSON-LD is completely free of.

Scheme:

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

Alternative: SPARQL query result

A JSON form has been standardized for the result of SPARQL queries. If it is only a matter of processing such results, this is a (limited) alternative.

The result of SELECT queries are variable bindings, not ordinary triple sets. CONSTRUCT queries, on the other hand, deliver triple quantities. For CONSTRUCT requests, for example, Virtuoso binds the variables "s", "p" and "o" ( objectification ). In no case does the pattern match that of JSON-LD.

However, SPARQL endpoints (like those from Virtuoso) for CONSTRUCT and DESCRIBE queries can also deliver the triple set (in addition to many other specific RDF syntaxes) in JSON-LD. An objectification is unnecessary in this case.

Applications and users

Some early users who have at least announced the adoption of JSON-LD in products or services by June 2014:

As early as May 2013, Google announced that it would support JSON-LD in its products in addition to HTML Microdata . For example, JSON-LD embedded in HTML e-mails can be extracted when they arrive in the mailbox . The semantic data is made available to the recipient during his personalized search or entries are offered in the appointment calendar.

Microsoft products can also read JSON-LD from emails in order to offer the recipient the services of a personal assistant depending on time and location. The prerequisite is that the sender to it (as with Google) the vocabulary of Schema.org used.

DBpedia delivers (linked) data, in addition to many other formats, also in JSON-LD. The Virtuoso used for this has been offering JSON-LD serialization in its open source edition at least since November 2011.

Schema.org has been committed to JSON-LD since June 2013 and also gives examples in JSON-LD parallel to RDFa and Microdata.A JSON-LD context has also been provided since mid-June 2014. A little later, FOAF also caught up and even provides the ontology ( RDF schema / OWL ) directly in JSON-LD.

The first RDF version of WordNet (presented in April 2014) has provided JSON-LD as well as other RDF formats since the beginning (using RDFLib ).

It is to be expected that many existing or new linked data offers will sooner or later also be made in this format.

In the area of web APIs

JSON was used as a means of general service delivery (via JSON-based web APIs) until JSON-LD was developed. The transport of RDF data or knowledge management in the Semantic Web (via RDF technologies) was not his domain.

Those involved in the development of JSON-LD saw (by their own admission) the desire for better web APIs as a motivation for the creation of JSON-LD, not the Semantic Web . On this path to the JSON-based web services (which are almost inevitably seamlessly integrated into the "Linked Data Cloud" through the use of semantic technologies (using JSON-LD)), the Semantic Web would ultimately become reality.

The semantic enrichment of the useful or content data through the use of well-known and tailor-made vocabularies for the respective subject area (i.e. for product and document descriptions, price information, offers, orders, payment methods, dates, actors, etc.) is obvious. In addition, the use of service and interface description (API / service description) is already the subject of research and development.

JSON-LD has been discussed in connection with the REST style for hypermedia-driven web services (of the next generation) since April 2012 at the latest .

In Hydra (which has also been part of a W3C Community Group since June 2013 ), JSON-LD is used on the following levels: (1) in the messages (using the API vocabulary of the respective service), (2) in the (semantic) API description (using the Hydra vocabulary as well as other well-known ones) and (3) in the description of the Hydra scheme for the API description (using the vocabulary of RDF scheme ). In this constellation, JSON-LD would take the place of XML in approaches such as WSDL (including SAWSDL ) and WADL or HTML + RDFa in SA-REST and that of the microformat in hRESTS and Micro WSMO . At the same time, it models REST such as WADL and MicroWSMO.

Since April 2014 there has been a further vocabulary (designed for JSON-LD) in addition to Hydra, which can describe entry points (EntryPoint, target) in services or operations (with input and output parameters): schema.org v1.2 includes this (Potential) actions (Action, potentialAction) such as listening, buying, sharing, commenting, searching, etc. As in Hydra, input elements can even be linked to the parameters of URL templates (according to RFC 6570 ). These elements (PropertyValueSpecification) are based on the input element of HTML5 , which largely explains the implementation in corresponding operating elements for the user. In this way, the HTML-free JSON (via JSON-LD) has the capabilities of an interactive hypermedia . Services such as search engines can use an RDF graph database alone to connect search results directly with (semantically classified) interaction offers (external providers). As with Hydra, the prerequisite is a generic interpreter or client for the respective information structure, because in contrast to HTML there are no other “browsers” for it. The triples in the database can of course also come from any other RDF serialization format. Advertisers or website operators are set to RDF (and Schema.org), but not necessarily to JSON-LD.

Approaches based on JSON-LD (and thus RDF) stand alongside those that are initially based directly on JSON. However, newer versions of the activity streams (and the associated action handlers) already provide for processing as JSON-LD by including at least one (non-normative) JSON-LD context.

In general, specifications that rely on JSON-LD and hypermedia can outsource later extensions to the vocabulary layer and provide relatively generic application programs with current information about the API at runtime (such as new actions or operations and associated parameters and return values). A cumbersome coordination in advance or after expansions (through the exchange of information " outside the channel ") should therefore largely be a thing of the past.

Web links

json-ld.org - page for developers with browser tool (" Playground ") (English)
JsonLD Playground by Markus Lanthaler - Alternative playground in PHP (English)
Article with the tag JSON-LD at semanticweb.com (English)

References and comments

↑ Manu Sporny: Linked JSON: RDF for the Masses . In: The Beautiful, Tormented Machine . Retrieved June 1, 2014.

↑ Ivan Herman: JSON-LD Has Been Published as a W3C Recommendation . Retrieved June 7, 2014.

↑ ^a ^b ^c ^d ^e ^f Manu Sporny, Gregg Kellogg, Markus Lanthaler, Editors: JSON-LD 1.0, A JSON-based Serialization for Linked Data, W3C Recommendation 16 January 2014 . Retrieved June 4, 2014.

↑ ^a ^b Markus Lanthaler, Gregg Kellogg, Manu Sporny, Editors: JSON-LD 1.0 Processing Algorithms and API, W3C Recommendation 16 January 2014 . Retrieved June 4, 2014.

↑ Practically every programming language used for web development has a convention for managing JSON data in main memory .

↑ namely from the NoSQL type, which supports JSON natively like MongoDB and CouchDB , but also SQL databases with JSON support like PostgreSQL and the like. a.

↑ ^a ^b ^c ^d ^e 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, March 5, 2014, section 5.3, pages 108–141, via markus-lanthaler.com (PDF) SHA1 0ab17eed62aeb2f56e8f8b1ab95ac9820e36c87a, accessed on June 8, 2014 < ref name = "rdf-json"> RDF 1.1 JSON Alternate Serialization (RDF / JSON) . W3C Working Group, Note November 7, 2013

↑ Shane Becker: JSON-LD is an Unneeded Spec . Archived from the original on July 14, 2014. Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved June 3, 2014.

↑ ^a ^b ^c Keith Alexander: RDF in JSON: A Specification for serializing 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)

↑ ^a ^b Manu Sporny: JSON-LD and Why I Hate the Semantic Web . In: The Beautiful, Tormented Machine . Retrieved June 6, 2014.

↑ Manu Sporny: JSON-LD is the Bee's Knees . In: The Beautiful, Tormented Machine . Retrieved June 4, 2014.

↑ However, it is permissible to distribute the connections from a node to any number of JSON objects (with the same “@id”) (“node objects”). These are then merged into one object using the recommended algorithms. However, this is not a preferred form or target form of JSON-LD.

↑ Likewise for sets of graphs that would be represented flatly as 4-tuples (quads): grouping according to the name of the set.

^ What's New in RDF 1.1

↑ PC Bryan, K. Zyp: JSON Reference . ( Page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice. In: Internet Engineering Task Force (IETF) Draft.

↑ ^a ^b Richard Cyganiak, David Wood, Mark Lanthaler: RDF Concepts and Abstract Syntax 1.1 - W3C Recommendation 25 February 2014 . In: W3C Recommendation . Retrieved June 11, 2014.

↑ json-schema.org

↑ For example, the Popolo Project uses JSON schema and JSON-LD contexts in parallel to ensure a uniform and validatable JSON form.

^ M. Kelly: JSON Hypertext Application Language . In: Internet Engineering Task Force (IETF) Draft

↑ also: called keys, key values or properties

↑ This construct is related to namespace prefixes or IRIs in other specific serializations of RDF, as well as to CURIEs (compact URI expressions from RDFa) and QNames from XML.

↑ See also note on schema.org context

↑ JSON-LD namespace

↑ whose name, for example, is not an IRI or a keyword like @id or @type and does not expand to any

↑ depending on whether more than one RDF graph is to be expected; Lists would increase the depth by a maximum of one, because they cannot be nested.

↑ The indexing of the "@id" s of subjects example, is not provided because this can be easily achieved with a few lines of code, if necessary. Furthermore, applications also need to be indexed according to more complex criteria.

↑ Patrick J. Hayes, Peter F. Patel-Schneider: RDF 1.1 Semantics - W3C Recommendation 25 February 2014 . In: W3C Recommendation . Retrieved June 11, 2014.

↑ JSON-LD namespace

↑ ^a ^b The alternative, format-neutral AlbertsIRI from the comment on the API example is actually preferable, but because of content negotiation and HTTP redirects , it places higher demands on the built-in or user-defined document loader and on the interaction with DBpedia. See also:
Chris Bizer, Richard Cyganiak, Tom Heath: How to Publish Linked Data on the Web . Retrieved June 6, 2014. and
Leo Sauermann, Richard Cyganiak (eds.): Cool URIs for the Semantic Web . In: W3C Interest Group Note . Retrieved June 11, 2014 (Work in progress), and
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 Free HTML Version , Retrieved June 11, 2014, Chapter 2.3 Making URIs Defererenceable (spelling mistake in the original)

↑ which however nothing for suitability in production systems is predicated

↑ The recommendation admits: Even the successful completion of all tests does not guarantee complete conformity.

↑ 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

^ David Wood: The State of RDF and JSON . September 13, 2011. In: Semantic Web Activity News

^ Mark Birbeck (inter alia): Rdfj . In: backplanejs - A JavaScript library that provides cross-browser XForms, RDFa, and SMIL support. . Retrieved June 9, 2014.

↑ JSON + RDF . In: w3.org . Retrieved June 9, 2014.

↑ w3.org

↑ SPARQL 1.1 Query Results JSON format

↑ see also: TriplesInJson w3.org

↑ Selection without claim to completeness; json-ld.org has a list on Github .

↑ Jennifer Zaino: Gmail, Meet JSON-LD . In: semanticweb.com . May 17, 2013. Archived from the original on July 14, 2014. Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice. Retrieved June 9, 2014.

^ Sending flight information to Microsoft Cortana with contextual awareness

↑ Virtuoso Open Source Wiki: Virtuoso Open Source Edition News (2011)

↑ blog.schema.org

↑ lists.w3.org

↑ This also makes examples (which have been in circulation for a long time) that reference schema.org as @context. This was previously only the case in environments that internally linked this URL with a suitable context.

↑ gmane.org

↑ wordnet-rdf.princeton.edu

↑ htmltalk.us ( Memento of the original from July 14, 2014 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.

↑ With the hypermedia-driven approach (with JSON-LD) it is sufficient (similar to human interaction with a website) to find an entry point into the service. All other links and (self-) descriptions are linked in machine-readable form via JSON-LD contexts: literals and IRIs for resources in a response are linked to operations that can be applied to them. Their application can lead to such an answer again, etc. (Both developers and flexible software agents could explore a service step by step and in a standardized way in order to find a way to achieve their actual goal.)

↑ Markus Lanthaler, Christian Gütl: On Using JSON-LD to Create Evolvable RESTful Services In: Proceedings of the International Workshop on RESTful Design . ( Page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice. 2012, pp. 25–32, via markus-lanthaler.com (PDF) SHA1 ba69b6c33792344fb189903792ec955af4aa0a98, accessed on June 21, 2014@1@ 2Template: Dead Link / www.ws-rest.org

↑ hydra-cg.com