From 682360bfefca4d1f0c2f5a083f24cb546ef09da6 Mon Sep 17 00:00:00 2001 From: Gregg Kellogg Date: Sat, 28 Apr 2018 08:57:35 -0700 Subject: [PATCH 1/6] CG-FINAL publication snapshots for 2018-05-07. --- spec/CG-FINAL/json-ld-api/20180507/index.html | 7037 +++++++++++++++++ .../json-ld-framing/20180507/index.html | 2965 +++++++ spec/CG-FINAL/json-ld/20180507/index.html | 6441 +++++++++++++++ .../json-ld/20180507/linked-data-graph.dia | Bin 0 -> 2150 bytes .../json-ld/20180507/linked-data-graph.png | Bin 0 -> 27844 bytes spec/latest/json-ld-api/index.html | 1 - spec/latest/json-ld-framing/index.html | 3 +- 7 files changed, 16444 insertions(+), 3 deletions(-) create mode 100644 spec/CG-FINAL/json-ld-api/20180507/index.html create mode 100644 spec/CG-FINAL/json-ld-framing/20180507/index.html create mode 100644 spec/CG-FINAL/json-ld/20180507/index.html create mode 100644 spec/CG-FINAL/json-ld/20180507/linked-data-graph.dia create mode 100644 spec/CG-FINAL/json-ld/20180507/linked-data-graph.png diff --git a/spec/CG-FINAL/json-ld-api/20180507/index.html b/spec/CG-FINAL/json-ld-api/20180507/index.html new file mode 100644 index 000000000..eaf0dd6da --- /dev/null +++ b/spec/CG-FINAL/json-ld-api/20180507/index.html @@ -0,0 +1,7037 @@ + +JSON-LD 1.1 Processing Algorithms and API + + + + + + + +
+ +

JSON-LD 1.1 Processing Algorithms and API

+ +

Final Community Group Report

+
+ + +
Latest editor's draft:
https://json-ld.org/spec/latest/json-ld-api/
+
Test suite:
https://json-ld.org/test-suite/
+ + +
Previous version:
https://www.w3.org/TR/2014/REC-json-ld-api-20140116/
+ +
Editor:
+
Gregg Kellogg (Spec-Ops) (v1.0 and v1.1)
+
Former editors:
Markus Lanthaler (Graz University of Technology) (v1.0)
Manu Sporny (Digital Bazaar) (v1.0)
+
Authors:
Dave Longley (Digital Bazaar) (v1.0)
Gregg Kellogg (Spec-Ops) (v1.0 and v1.1)
Markus Lanthaler (Graz University of Technology) (v1.0)
Manu Sporny (Digital Bazaar) (v1.0)
Niklas Lindström (v1.0)
+
Participate:
+ GitHub json-ld/json-ld.org +
+ File a bug +
+ Commit history +
+ Pull requests +
+
+ +

+ Copyright © + 2010-2018 + the Contributors to the JSON-LD 1.1 Processing Algorithms and API Specification, published by the + JSON for Linking Data W3C Community Group under the + W3C Community Final Specification Agreement (FSA). + A human-readable summary is available. + +

+
+
+

Abstract

+

This specification defines a set of algorithms for programmatic transformations + of JSON-LD documents. Restructuring data according to the defined transformations + often dramatically simplifies its usage. Furthermore, this document proposes + an Application Programming Interface (API) for developers implementing the + specified algorithms.

+
+ +

Status of This Document

+ This specification was published by the JSON for Linking Data W3C Community Group. + It is not a W3C Standard nor is it on the W3C Standards Track. + + Please note that under the + W3C Community Final Specification Agreement (FSA) + other conditions apply. + + Learn more about + W3C Community and Business Groups. +

This document has been developed by the + JSON for Linking Data W3C Community Group + as an update to the 1.0 recommendation [JSON-LD-API] developed + by the RDF Working Group. + The specification has undergone + significant development, review, and changes during the course of several years.

There are several independent + interoperable implementations of + this specification, a test suite [JSON-LD-TESTS] and a + live JSON-LD playground that is capable + of demonstrating the features described in this document.

If you wish to make comments regarding this document, please send them to + public-linked-json@w3.org + (subscribe, + archives).

+

Set of Documents

+

This document is one of three JSON-LD 1.1 Recommendations produced by the + JSON for Linking Data W3C Community Group:

+ + +
+ + +
+

1. Introduction §

This section is non-normative.

+ +

This document is a detailed specification of the JSON-LD processing algorithms. + The document is primarily intended for the following audiences:

+ + + +

To understand the basics in this specification you must first be familiar with + JSON, which is detailed in [RFC7159]. You must also understand the + JSON-LD syntax defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all + of the algorithms in this document. To understand the API and how it is + intended to operate in a programming environment, it is useful to have working + knowledge of the JavaScript programming language [ECMASCRIPT-6.0] and + WebIDL [WEBIDL]. To understand how JSON-LD maps to RDF, it is helpful to be + familiar with the basic RDF concepts [RDF11-CONCEPTS].

+ +
+

1.1 Contributing §

+ +

There are a number of ways that one may participate in the development of + this specification:

+ +
    +
  • Technical discussion typically occurs on the public mailing list: + public-linked-json@w3.org
    • + + + +
  • The #json-ld + IRC channel is available for real-time discussion on irc.freenode.net.
    • +
+ +
+ +
+

1.2 Terminology §

+ +

This document uses the following terms as defined in JSON [RFC7159]. Refer + to the JSON Grammar section in [RFC7159] for formal definitions.

+ +
array
+ In the JSON serialization, an array structure is represented as square brackets surrounding zero + or more values. Values are separated by commas. + In the internal representation, an array is an ordered collection of zero or more values. + While JSON-LD uses the same array representation as JSON, + the collection is unordered by default. While order is + preserved in regular JSON arrays, it is not in regular JSON-LD arrays + unless specifically defined (see + Sets and Lists in + the JSON-LD Syntax specification [JSON-LD11CG]).
+
JSON object
+ In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or + more key-value pairs. A key is a string. A single colon comes after + each key, separating the key from the value. A single comma separates a value + from a following key. In JSON-LD the keys in an object MUST be unique. + In the internal representation a JSON object is equivalent to a + dictionary (see [WEBIDL]).
+
JSON-LD internal representation
The JSON-LD + internal representation is the result of transforming a JSON syntactic structure + into the core data structures suitable for direct processing: + arrays, dictionaries, + strings, numbers, booleans, and null.
+
null
+ The use of the null value within JSON-LD is used to + ignore or reset values. A key-value pair in the @context where + the value, or the @id of the value, is null + explicitly decouples a term's association with an IRI. A key-value pair in + the body of a JSON-LD document whose value is null has the + same meaning as if the key-value pair was not defined. If + @value, @list, or @set is set to + null in expanded form, then the entire JSON + object is ignored.
+
number
+ In the JSON serialization, a number is similar to that used in most programming languages, except + that the octal and hexadecimal formats are not used and that leading + zeros are not allowed. + In the internal representation, a number is equivalent to either + a long + or double, depending + on if the number has a non-zero fractional part (see [WEBIDL]).
+
scalar
+ A scalar is either a JSON string, number, true, + or false.
+
string
+ A string is a sequence of zero or more Unicode (UTF-8) characters, + wrapped in double quotes, using backslash escapes (if necessary). A + character is represented as a single character string.
+
true and false
+ Values that are used to express one of two possible + boolean states.
+ +

Furthermore, the following terminology is used throughout this document:

+ +
absolute IRI
+ An absolute IRI is defined in [RFC3987] containing a scheme along with a path and + optional query and fragment segments.
+
active context
+ A context that is used to resolve terms while the processing + algorithm is running.
+
base IRI
+ The base IRI is an absolute IRI established in the context, + or is based on the JSON-LD document location. The base IRI is used to turn + relative IRIs into absolute IRIs.
+
blank node
+ A node in a graph that is neither an + IRI, nor a JSON-LD value, nor a list. + A blank node does not contain a de-referenceable + identifier because it is either ephemeral in nature or does not contain information that needs to be + linked to from outside of the linked data graph. A blank node is assigned an identifier starting with + the prefix _:.
+
blank node identifier
+ A blank node identifier is a string that can be used as an identifier for a + blank node within the scope of a JSON-LD document. Blank node identifiers + begin with _:.
+
compact IRI
+ A compact IRI is has the form of prefix:suffix and is used as a way + of expressing an IRI without needing to define separate term definitions for + each IRI contained within a common vocabulary identified by prefix.
+
context
+ A a set of rules for interpreting a JSON-LD document as specified in + The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+
datatype IRI
+ A datatype IRI + as specified by [RDF11-CONCEPTS].
+
default graph
+ The default graph is the only graph in a JSON-LD document which has no graph name. + When executing an algorithm, the graph where data should be placed + if a named graph is not specified.
+
default language
+ The default language is set in the context using the @language key whose + value MUST be a string representing a [BCP47] language code or null.
+
+
edge
+ Every edge has a direction associated with it and is labeled with + an IRI or a blank node identifier. Within the JSON-LD syntax + these edge labels are called properties. Whenever possible, an + edge should be labeled with an IRI.
+
expanded term definition
+ An expanded term definition, is a term definition where the value is a JSON object + containing one or more keyword properties to define the associated absolute IRI, + if this is a reverse property, the type associated with string values, and a container mapping.
+
Frame
+ A JSON-LD document, which describes the form for transforming + another JSON-LD document using matching and embedding rules. + A frame document allows additional keywords and certain property values + to describe the matching and transforming process.
+
+
graph name
+ The IRI identifying a named graph.
+
graph object
+ A graph object represents a named graph represented as the + value of a property within a node object. When expanded, a + graph object MUST have an @graph member, and may also have + @id, and @index members. + A simple graph object is a + graph object which does not have an @id member. Note + that node objects may have a @graph member, but are + not considered graph objects if they include any other properties. + A top-level object consisting of @graph is also not a graph object.
+
id map
+ An id map is a JSON object value of a term defined with + @container set to @id, who's keys are + interpreted as IRIs representing the @id + of the associated node object; value MUST be a node object. + If the value contains a property expanding to @id, it's value MUST + be equivalent to the referencing key.
+
+
index map
+ An index map is a JSON object value of a term defined with + @container set to @index, whose values MUST be any of the following types: + string, + number, + true, + false, + null, + node object, + value object, + list object, + set object, or + an array of zero or more of the above possibilities. +
+
IRI
+ An Internationalized Resource Identifier as described in [RFC3987].
+
JSON-LD document
+ A JSON-LD document is a serialization of a collection of + graphs and comprises exactly one + default graph and zero or more named graphs.
+
JSON-LD Processor
+ A JSON-LD Processor is a system which can perform the algorithms defined in [JSON-LD11CG-API].
+
JSON-LD value
+ A JSON-LD value is a string, a number, + true or false, a typed value, or a + language-tagged string.
+
keyword
+ A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] + in the section titled Syntax Tokens and Keywords.
+
language map
+ An language map is a JSON object value of a term defined with + @container set to @language, whose keys MUST be strings representing + [BCP47] language codes and the values MUST be any of the following types: + null, + string, or + an array of zero or more of the above possibilities. +
+
language-tagged string
+ A language-tagged string consists of a string and a non-empty language + tag as defined by [BCP47]. The language tag MUST be well-formed according to + section 2.2.9 Classes of Conformance + of [BCP47], and is normalized to lowercase.
+
+
linked data graph
+ A labeled directed graph, i.e., a set of nodes + connected by edges, + as specified in the Data Model + section of the JSON-LD specification [JSON-LD11CG]. + A linked data graph is a generalized representation of an + RDF graph + as defined in [RDF-CONCEPTS].
+
list
+ A list is an ordered sequence of IRIs, + blank nodes, and JSON-LD values. + See RDF collection + in [RDF-SCHEMA].
+
list object
+ A list object is a JSON object that has an @list + member.
+
+
local context
+ A context that is specified within a JSON object, + specified via the @context keyword.
+
named graph
+ A named graph is a linked data graph that is identified by an IRI or blank node.
+
+
node
+ Every node is an IRI, a blank node, + a JSON-LD value, or a list. + A piece of information that is represented in a linked data graph.
+
node object
+ A node object represents zero or more properties of a + node in the graph serialized by the + JSON-LD document. A JSON object is a node object + if it exists outside of the JSON-LD context and: +
    +
  • it does not contain the @value, @list, + or @set keywords, or
    • +
  • it is not the top-most JSON object in the JSON-LD document consisting + of no other members than @graph and @context.
    • +
+
+
+
object
+ An object is a node in a linked data graph with at least one incoming edge. + See RDF objectin [RDF11-CONCEPTS].
+
prefix
+ A prefix is the first component of a compact IRI which comes from a + term that maps to a string that, when prepended to the suffix of the compact IRI + results in an absolute IRI.
+
processing mode
+ The processing mode defines how a JSON-LD document is processed. + By default, all documents are assumed to be conformant with + JSON-LD 1.0 [JSON-LD]. By defining + a different version using the @version member in a + context, or via explicit API option, other processing modes + can be accessed. This specification defines extensions for the + json-ld-1.1 processing mode.
+
property
+ The IRI label of an edge in a linked data graph. + See RDF predicate in [RDF11-CONCEPTS].
+
+
RDF dataset
+ A dataset as specified by [RDF11-CONCEPTS] representing a collection of + RDF graphs.
+
RDF resource
+ A resource as specified by [RDF11-CONCEPTS].
+
RDF triple
+ A triple as specified by [RDF11-CONCEPTS].
+
relative IRI
+ A relative IRI is an IRI that is relative to some other absolute IRI, + typically the base IRI of the document. Note that + properties, values of @type, and values of terms defined to be vocabulary relative + are resolved relative to the vocabulary mapping, not the base IRI.
+
set object
+ A set object is a JSON object that has an @set + member.
+
subject
+ A subject is anode in a linked data graph with at least one outgoing edge, related to an object node through a property. + See RDF subject in [RDF11-CONCEPTS].
+
term
+ A term is a short word defined in a context that MAY be expanded to an IRI +
+
term definition
+ A term definition is an entry in a context, where the key defines a term which may be used within + a JSON object as a property, type, or elsewhere that a string is interpreted as a vocabulary item. + Its value is either a string (simple term definition), expanding to an absolute IRI, or an expanded term definition. +
+
type map
+ An type map is a JSON object value of a term defined with + @container set to @type, who's keys are + interpreted as IRIs representing the @type + of the associated node object; + value MUST be a node object, or array of node objects. + If the value contains a property expanding to @type, it's values + are merged with the map value when expanding.
+
+
typed value
+ A typed value consists of a value, which is a string, and a type, + which is an IRI.
+
value object
+ A value object is a JSON object that has an @value + member.
+
vocabulary mapping
+ The vocabulary mapping is set in the context using the @vocab key whose + value MUST be an absolute IRI null.
+
+ +
+

1.2.1 Algorithm Terms §

+ +

The Following terms are used within specific algorithms.

+ +
active graph
+ The name of the currently active graph that the processor should use when + processing.
+
+
active property
+ The currently active property or keyword that the processor + should use when processing. The active property is represented in + the original lexical form, which is used for finding coercion mappings in + the active context.
+
+
+
+
+
JSON-LD input
+ The JSON-LD data structure that is provided as input to the algorithm.
+
+
+
+
+
+
+
promise
+ A promise is an object that represents the eventual result of a single asynchronous operation. + Promises are defined in [ECMASCRIPT-6.0].
+
+
+
+ +
+ +
+

1.3 Typographical conventions §

+

The following typographic conventions are used in this specification:

+ +
+
markup
+
Markup (elements, attributes, properties), machine processable values (string, characters, media types), property name, or a file name is in red-orange monospace font.
+
variable
+
A variable in pseudo-code or in an algorithm description is in italics.
+
definition
+
A definition of a term, to be used elsewhere in this or other specifications, is in bold and italics.
+
definition reference
+
A reference to a definition in this document is underlined and is also an active link to the definition itself.
+
markup definition reference
+
A references to a definition in this document, when the reference itself is also a markup, is underlined, red-orange monospace font, and is also an active link to the definition itself.
+
external definition reference
+
A reference to a definition in another document is underlined, in italics, and is also an active link to the definition itself.
+
markup external definition reference
+
A reference to a definition in another document, when the reference itself is also a markup, is underlined, in italics red-orange monospace font, and is also an active link to the definition itself.
+
hyperlink
+
A hyperlink is underlined and in blue.
+
[reference]
+
A document reference (normative or informative) is enclosed in square brackets and links to the references section.
+
Changes from Recommendation
+
Sections or phrases changed from the previous Recommendation are highlighted.
+
+ +
Note

Notes are in light green boxes with a green left border and with a "Note" header in green. Notes are normative or informative depending on the whether they are in a normative or informative section, respectively.

+ +
Example 1
Examples are in light khaki boxes, with khaki left border, and with a
+numbered "Example" header in khaki. Examples are always informative.
+The content of the example is in monospace font and may be syntax colored.
+
+
+ +
+

1.4 Example Conventions §

+

Note that in the examples used in this document, output + is of necessity shown in serialized form as JSON. While the algorithms + describe operations on the JSON-LD internal representation, when + they as displayed as examples, the JSON serialization is used. In particular, + the internal representation use of dictionaries are represented using + JSON objects.

+ +
Example 2: Sample JSON-LD document
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows"
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "name": "Markus Lanthaler",
+  "knows": [
+    {
+      "name": "Dave Longley"
+    }
+  ]
+}
+

In the internal representation, the example above would be of a + dictionary containing @context, @id, name, and knows keys, + with either dictionaries, strings, or arrays of + dictionaries or strings values. In the JSON serialization, JSON objects are used + for dictionaries, while arrays and strings are serialized using a + convention common to many programming languages.

+
+ +
+ + +
+

2. Features §

This section is non-normative.

+ +

The JSON-LD 1.1 Syntax specification [JSON-LD11CG] defines a syntax to + express Linked Data in JSON. Because there is more than one way to + express Linked Data using this syntax, it is often useful to be able to + transform JSON-LD documents so that they may be more easily consumed by + specific applications.

+ +

To allow these algorithms to be adapted for syntaxes + other than JSON, the algorithms operate on the JSON-LD internal representation, + which uses the generic + concepts of arrays, dictionaries, + strings, numbers, booleans, and null to describe + the data represented by a JSON document. Algorithms act on this + internal representation with API entry points responsible for + transforming between the concrete and internal representations.

+ +

JSON-LD uses contexts to allow Linked Data + to be expressed in a way that is specifically tailored to a particular + person or application. By providing a context, + JSON data can be expressed in a way that is a natural fit for a particular + person or application whilst also indicating how the data should be + understood at a global scale. In order for people or applications to + share data that was created using a context that is different + from their own, a JSON-LD processor must be able to transform a document + from one context to another. Instead of requiring JSON-LD + processors to write specific code for every imaginable + context switching scenario, it is much easier to specify a + single algorithm that can remove any context. Similarly, + another algorithm can be specified to subsequently apply any + context. These two algorithms represent the most basic + transformations of JSON-LD documents. They are referred to as + expansion and compaction, respectively.

+ +

JSON-LD 1.1 introduces new features that are + compatible with JSON-LD 1.0 [JSON-LD], + but if processed by a JSON-LD 1.0 processor may produce different results. + In order to detect this JSON-LD 1.1 requires that the processing + mode be explicitly set to json-ld-1.1, either through the + processingMode API option, or using the + @version member within a context.

+ +

There are four major types of transformation that are discussed in this + document: expansion, compaction, flattening, and RDF serialization/deserialization.

+ +
+

2.1 Expansion §

This section is non-normative.

+ +

The algorithm that removes context is + called expansion. Before performing any other + transformations on a JSON-LD document, it is easiest to + remove any context from it and to make data structures + more regular.

+ +

To get an idea of how context and data structuring affects the same data, + here is an example of JSON-LD that uses only terms + and is fairly compact:

+ +
Example 3: JSON-LD documenet using only terms
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "homepage": {
+      "@id": "http://xmlns.com/foaf/0.1/homepage",
+      "@type": "@id"
+    }
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "name": "Markus Lanthaler",
+  "homepage": "http://www.markus-lanthaler.com/"
+}
+ + + +

The next input example uses one IRI to express a property + and an array to encapsulate another, but + leaves the rest of the information untouched.

+ +
Example 4: Sample JSON-LD document using an IRI instead of a term to express a property
{
+  "@context": {
+    "website": "http://xmlns.com/foaf/0.1/homepage"
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "http://xmlns.com/foaf/0.1/name": "Markus Lanthaler",
+  "website": { "@id": "http://www.markus-lanthaler.com/" }
+}
+ +

Note that both inputs are valid JSON-LD and both represent the same + information. The difference is in their context information + and in the data structures used. A JSON-LD processor can remove + context and ensure that the data is more regular by employing + expansion.

+ +

Expansion has two important goals: removing any contextual + information from the document, and ensuring all values are represented + in a regular form. These goals are accomplished by expanding all properties + to absolute IRIs and by expressing all + values in arrays in + expanded form. Expanded form is the most verbose + and regular way of expressing of values in JSON-LD; all contextual + information from the document is instead stored locally with each value. + Running the Expansion algorithm + (expand) + operation) against the above examples results in the following output:

+ +
Example 5: Expanded JSON-LD document using an IRI
[
+  {
+    "@id": "http://me.markus-lanthaler.com/",
+    "http://xmlns.com/foaf/0.1/name": [
+      { "@value": "Markus Lanthaler" }
+    ],
+    "http://xmlns.com/foaf/0.1/homepage": [
+      { "@id": "http://www.markus-lanthaler.com/" }
+    ]
+  }
+]
+ +

The example above is the JSON-LD serialization of the output of the + expansion algorithm, + where the algorithm's use of dictionaries are replaced with JSON objects.

+ +

Note that in the output above all context definitions have + been removed, all terms and + compact IRIs have been expanded to absolute + IRIs, and all + JSON-LD values are expressed in + arrays in expanded form. While the + output is more verbose and difficult for a human to read, it establishes a + baseline that makes JSON-LD processing easier because of its very regular + structure.

+
+ +
+

2.2 Compaction §

This section is non-normative.

+ +

While expansion removes context from a given + input, compaction's primary function is to + perform the opposite operation: to express a given input according to + a particular context. Compaction applies a + context that specifically tailors the way information is + expressed for a particular person or application. This simplifies applications + that consume JSON or JSON-LD by expressing the data in application-specific + terms, and it makes the data easier to read by humans.

+ +

Compaction uses a developer-supplied context to + shorten IRIs to terms or + compact IRIs and + JSON-LD values expressed in + expanded form to simple values such as strings + or numbers.

+ +

For example, assume the following expanded JSON-LD input document:

+ +
Example 6: Expanded sample document
[
+  {
+    "@id": "http://me.markus-lanthaler.com/",
+    "http://xmlns.com/foaf/0.1/name": [
+      { "@value": "Markus Lanthaler" }
+    ],
+    "http://xmlns.com/foaf/0.1/homepage": [
+      { "@id": "http://www.markus-lanthaler.com/" }
+    ]
+  }
+]
+ +

Additionally, assume the following developer-supplied JSON-LD + context:

+ +
Example 7: JSON-LD context
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "homepage": {
+      "@id": "http://xmlns.com/foaf/0.1/homepage",
+      "@type": "@id"
+    }
+  }
+}
+ +

Running the Compaction Algorithm + (compact) + operation) given the context supplied above against the JSON-LD input + document provided above would result in the following output:

+ +
Example 8: Compacted sample document
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "homepage": {
+      "@id": "http://xmlns.com/foaf/0.1/homepage",
+      "@type": "@id"
+    }
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "name": "Markus Lanthaler",
+  "homepage": "http://www.markus-lanthaler.com/"
+}
+ +

The example above is the JSON-LD serialization of the output of the + compaction algorithm, + where the algorithm's use of dictionaries are replaced with JSON objects.

+ +

Note that all IRIs have been compacted to + terms as specified in the context, + which has been injected into the output. While compacted output is + useful to humans, it is also used to generate structures that are easy to + program against. Compaction enables developers to map any expanded document + into an application-specific compacted document. While the context provided + above mapped http://xmlns.com/foaf/0.1/name to name, it + could also have been mapped to any other term provided by the developer.

+
+ +
+

2.3 Flattening §

This section is non-normative.

+ +

While expansion ensures that a document is in a uniform structure, + flattening goes a step further to ensure that the shape of the data + is deterministic. In expanded documents, the properties of a single + node may be spread across a number of different + dictionaries. By flattening a + document, all properties of a node are collected in a single + dictionary and all blank nodes + are labeled with a blank node identifier. This may drastically + simplify the code required to process JSON-LD data in certain applications.

+ +

For example, assume the following JSON-LD input document:

+ +
Example 9: JSON-LD document in compact form
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows"
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "name": "Markus Lanthaler",
+  "knows": [
+    {
+      "name": "Dave Longley"
+    }
+  ]
+}
+ +

Running the Flattening Algorithm + (flatten) + operation) with a context set to null to prevent compaction + returns the following document:

+ +
Example 10: Flattened sample document in expanded form
[
+  {
+    "@id": "_:t0",
+    "http://xmlns.com/foaf/0.1/name": [
+      { "@value": "Dave Longley" }
+    ]
+  },
+  {
+    "@id": "http://me.markus-lanthaler.com/",
+    "http://xmlns.com/foaf/0.1/name": [
+      { "@value": "Markus Lanthaler" }
+    ],
+    "http://xmlns.com/foaf/0.1/knows": [
+      { "@id": "_:t0" }
+    ]
+  }
+]
+ +

The example above is the JSON-LD serialization of the output of the + flattening algorithm, + where the algorithm's use of dictionaries are replaced with JSON objects.

+ +

Note how in the output above all properties of a node are collected in a + single dictionary and how the blank node representing + "Dave Longley" has been assigned the blank node identifier + _:t0.

+ +

To make it easier for humans to read or for certain applications to + process it, a flattened document can be compacted by passing a context. Using + the same context as the input document, the flattened and compacted document + looks as follows:

+ +
Example 11: Flattened and compacted sample document
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows"
+  },
+  "@graph": [
+    {
+      "@id": "_:t0",
+      "name": "Dave Longley"
+    }, {
+      "@id": "http://me.markus-lanthaler.com/",
+      "name": "Markus Lanthaler",
+      "knows": { "@id": "_:t0" }
+    }
+  ]
+}
+ +

Please note that the result of flattening and compacting a document + is always a dictionary, + (represented as a JSON object when serialized), + which contains an @graph + member that represents the default graph.

+
+ +
+

2.4 RDF Serialization/Deserialization §

This section is non-normative.

+ +

JSON-LD can be used to serialize RDF data as described in + [RDF11-CONCEPTS]. This ensures that data can be round-tripped to and from + any RDF syntax without any loss in fidelity.

+ +

For example, assume the following RDF input serialized in Turtle [TURTLE]:

+ +
Example 12: Sample Turtle document
<http://me.markus-lanthaler.com/> <http://xmlns.com/foaf/0.1/name> "Markus Lanthaler" .
+<http://me.markus-lanthaler.com/> <http://xmlns.com/foaf/0.1/homepage> <http://www.markus-lanthaler.com/> .
+ +

Using the Serialize RDF as JSON-LD algorithm + a developer could transform this document into expanded JSON-LD:

+ +
Example 13: Sample Turtle document converted to JSON-LD
[
+  {
+    "@id": "http://me.markus-lanthaler.com/",
+    "http://xmlns.com/foaf/0.1/name": [
+      { "@value": "Markus Lanthaler" }
+    ],
+    "http://xmlns.com/foaf/0.1/homepage": [
+      { "@id": "http://www.markus-lanthaler.com/" }
+    ]
+  }
+]
+ +

The example above is the JSON-LD serialization of the output of the + Serialize RDF as JSON-LD algorithm, + where the algorithm's use of dictionaries are replaced with JSON objects.

+ +

Note that the output above could easily be compacted using the technique outlined + in the previous section. It is also possible to deserialize the JSON-LD document back + to RDF using the Deserialize JSON-LD to RDF algorithm.

+
+
+ + +

3. Conformance §

+ As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, + and notes in this specification are non-normative. Everything else in this specification is + normative. +

The key words MAY, MUST, and MUST NOT are + to be interpreted as described in [RFC2119]. +

+

There are two classes of products that can claim conformance to this + specification: JSON-LD Processors, + and RDF Serializers/Deserializers.

+ +

A conforming JSON-LD Processor is a system which can perform the + Expansion, Compaction, + and Flattening operations + in a manner consistent with + the algorithms defined in this specification.

+ +

JSON-LD Processors MUST NOT + attempt to correct malformed IRIs or language tags; + however, they MAY issue validation warnings. IRIs are not modified other + than conversion between relative and + absolute IRIs.

+ +

A conforming RDF Serializer/Deserializer is a system that can + deserialize JSON-LD to RDF and + serialize RDF as JSON-LD as + defined in this specification.

+ +

The algorithms in this specification are generally written with more concern for clarity + than efficiency. Thus, JSON-LD Processors may + implement the algorithms given in this specification in any way desired, + so long as the end result is indistinguishable from the result that would + be obtained by the specification's algorithms.

+ +

In algorithm steps that describe operations on keywords, those steps + also apply to keyword aliases.

+ +
Note

Implementers can partially check their level of conformance to + this specification by successfully passing the test cases of the JSON-LD test + suite [JSON-LD-TESTS]. Note, however, that passing all the tests in the test + suite does not imply complete conformance to this specification. It only implies + that the implementation conforms to aspects tested by the test suite.

+
+ +
+

4. Context Processing Algorithms §

+ +
+

4.1 Context Processing Algorithm §

+ +

When processing a JSON-LD data structure, each processing rule is applied + using information provided by the active context. This + section describes how to produce an active context.

+ +

The active context contains the active + term definitions which specify how + properties and values have to be interpreted as well as the current base IRI, + the vocabulary mapping and the default language. Each + term definition consists of an IRI mapping, a boolean + flag reverse property, an optional type mapping + or language mapping, + an optional context, + an optional nest value, + an optional prefix flag, + and an optional container mapping. + A term definition can not only be used to map a term + to an IRI, but also to map a term to a keyword, + in which case it is referred to as a keyword alias.

+ +

When processing, active context is initialized + without any term definitions, + vocabulary mapping, or default language. + If a local context is encountered during processing, a new + active context is created by cloning the existing + active context. Then the information from the + local context is merged into the new active context. + Given that local contexts may contain + references to remote contexts, this includes their retrieval.

+ +
+

4.1.1 Overview §

This section is non-normative.

+ +

First we prepare a new active context result by cloning + the current active context. Then we normalize the form of the original + local context to an array. + Local contexts may be in the form of a + dictionary, a string, or an array containing + a combination of the two. Finally we process each context contained + in the local context array as follows.

+ +

Unless specified using + processingMode API option, + the processing mode is set using the @version member + in a local context and + affects the behavior of algorithms including expansion and compaction.

+ +

If context is a string, it represents a reference to + a remote context. We dereference the remote context and replace context + with the value of the @context key of the top-level object in the + retrieved JSON-LD document. If there's no such key, an + invalid remote context + has been detected. Otherwise, we process context by recursively using + this algorithm ensuring that there is no cyclical reference.

+ +

If context is a dictionary, we first update the + base IRI, the vocabulary mapping, processing mode, and the + default language by processing three specific keywords: + @base, @vocab, @version, and @language. + These are handled before any other keys in the local context because + they affect how the other keys are processed. Please note that @base is + ignored when processing remote contexts.

+ +

Then, for every other key in local context, we update + the term definition in result. Since + term definitions in a local context + may themselves contain terms or + compact IRIs, we may need to recurse. + When doing so, we must ensure that there is no cyclical dependency, + which is an error. After we have processed any + term definition dependencies, + we update the current term definition, + which may be a keyword alias.

+ +

Finally, we return result as the new active context.

+
+ +
+

4.1.2 Algorithm §

+ +

This algorithm specifies how a new active context is updated + with a local context. The algorithm takes three input variables: + an active context, a local context, and an array + remote contexts which is used to detect cyclical context inclusions. + If remote contexts is not passed, it is initialized to an empty + array.

+ +
    +
  1. Initialize result to the result of cloning + active context.
    2. +
  2. If local context is not an array, + set it to an array containing only + local context.
    3. +
  3. + For each item context in local context: +
      +
    1. If context is null, set result to a + newly-initialized active context and continue with the + next context. + In JSON-LD 1.0, the base IRI was given + a default value here; this is now described conditionally + in section 9. The Application Programming Interface.
      2. +
    2. If context is a string, +
        +
      1. Set context to the result of resolving value against + the base IRI which is established as specified in + section 5.1 Establishing a Base URI + of [RFC3986]. Only the basic algorithm in + section 5.2 + of [RFC3986] is used; neither + Syntax-Based Normalization nor + Scheme-Based Normalization + are performed. Characters additionally allowed in IRI + references are treated in the same way that unreserved + characters are treated in URI references, per + section 6.5 + of [RFC3987].
        2. +
      2. If context is in the remote contexts array, a + recursive context inclusion + error has been detected and processing is aborted; + otherwise, add context to remote contexts.
        3. +
      3. If context was previously dereferenced, + then the processor MUST NOT do a further dereference, and + context is set to the + previously established internal representation.
        4. +
      4. Otherwise, dereference context, transforming into the internal representation. + If context cannot be dereferenced, + or cannot be transformed into the internal representation, + a loading remote context failed + error has been detected and processing is aborted. If the dereferenced document has no + top-level dictionary with an @context member, an + invalid remote context + has been detected and processing is aborted; otherwise, + set context to the value of that member.
        5. +
      5. Set result to the result of recursively calling this algorithm, + passing result for active context, + context for local context, and a copy of remote contexts.
        6. +
      6. Continue with the next context.
        7. +
      +
      3. +
    3. If context is not a dictionary, an + invalid local context + error has been detected and processing is aborted.
      4. +
    4. If context has an @base key and remote contexts is empty, i.e., the currently + being processed context is not a remote context: +
        +
      1. Initialize value to the value associated with the + @base key.
        2. +
      2. If value is null, remove the + base IRI of result.
        3. +
      3. Otherwise, if value is an absolute IRI, + the base IRI of result is set to value.
        4. +
      4. Otherwise, if value is a relative IRI and + the base IRI of result is not null, + set the base IRI of result to the result of + resolving value against the current base IRI + of result.
        5. +
      5. Otherwise, an + invalid base IRI + error has been detected and processing is aborted.
        6. +
      +
      5. +
    5. If context has an @version key: +
        +
      1. If the associated value is not 1.1, + an invalid @version value + has been detected, and processing is aborted.
        2. +
      2. If processing mode + is set to json-ld-1.0, + a processing mode conflict + error has been detected and processing is aborted.
        3. +
      3. Set processing mode, + to json-ld-1.1, if not already set.
        4. +
      +
      6. +
    6. If context has an @vocab key: +
        +
      1. Initialize value to the value associated with the + @vocab key.
        2. +
      2. If value is null, remove + any vocabulary mapping from result.
        3. +
      3. Otherewise, if value + the empty string (""), + the effective value is the current base IRI.
        4. +
      4. Otherwise, if value is + an absolute IRI + or blank node identifier, the vocabulary mapping + of result is set to value. If it is not + an absolute IRI, or a blank node identifier, an + invalid vocab mapping + error has been detected and processing is aborted.
        5. +
      +
      7. +
    7. If context has an @language key: +
        +
      1. Initialize value to the value associated with the + @language key.
        2. +
      2. If value is null, remove + any default language from result.
        3. +
      3. Otherwise, if value is string, the + default language of result is set to + lowercased value. If it is not a string, an + invalid default language + error has been detected and processing is aborted.
        4. +
      +
      8. +
    8. Create a dictionary defined to use to keep + track of whether or not a term has already been defined + or currently being defined during recursion.
      9. +
    9. For each key-value pair in context where + key is not @base, @vocab, or + @language, invoke the + Create Term Definition algorithm, + passing result for active context, + context for local context, key, + and defined.
      10. +
    +
    4. +
  4. Return result.
    5. +
+
+
+ +
+

4.2 Create Term Definition §

+ +

This algorithm is called from the + Context Processing algorithm + to create a term definition in the active context + for a term being processed in a local context.

+ +
+

4.2.1 Overview §

This section is non-normative.

+ +

term definitions are created by + parsing the information in the given local context for the + given term. If the given term is a + compact IRI, it may omit an IRI mapping by + depending on its prefix having its own + term definition. If the prefix is + a key in the local context, then its term definition + must first be created, through recursion, before continuing. Because a + term definition can depend on other + term definitions, a mechanism must + be used to detect cyclical dependencies. The solution employed here + uses a map, defined, that keeps track of whether or not a + term has been defined or is currently in the process of + being defined. This map is checked before any recursion is attempted.

+ +

After all dependencies for a term have been defined, the rest of + the information in the local context for the given + term is taken into account, creating the appropriate + IRI mapping, container mapping, and + type mapping or language mapping for the + term.

+
+ +
+

4.2.2 Algorithm §

+ +

The algorithm has four required inputs which are: + an active context, a local context, + a term, and a map defined.

+ +
    +
  1. If defined contains the key term and the associated + value is true (indicating that the + term definition has already been created), return. Otherwise, + if the value is false, a + cyclic IRI mapping + error has been detected and processing is aborted.
    2. +
  2. Set the value associated with defined's term key to + false. This indicates that the term definition + is now being created but is not yet complete.
    3. +
  3. Since keywords cannot be overridden, + term must not be a keyword. Otherwise, a + keyword redefinition + error has been detected and processing is aborted.
    4. +
  4. Remove any existing term definition for term in + active context.
    5. +
  5. Initialize value to a copy of the value associated with the key + term in local context.
    6. +
  6. If value is null or value + is a dictionary containing the key-value pair + @id-null, set the + term definition in active context to + null, set the value associated with defined's + key term to true, and return.
    7. +
  7. Otherwise, if value is a string, convert it + to a dictionary consisting of a single member whose + key is @id and whose value is value. + Set simple term to true.
    8. +
  8. Otherwise, value must be a dictionary, if not, an + invalid term definition + error has been detected and processing is aborted. + Set simple term to false.
    9. +
  9. Create a new term definition, definition.
    10. +
  10. If value contains the key @type: +
      +
    1. Initialize type to the value associated with the + @type key, which must be a string. Otherwise, an + invalid type mapping + error has been detected and processing is aborted.
      2. +
    2. Set type to the result of using the + IRI Expansion algorithm, passing + active context, type for value, + true for vocab, + local context, and defined. If the expanded type is + neither @id, nor @vocab, nor an absolute IRI, an + invalid type mapping + error has been detected and processing is aborted.
      3. +
    3. Set the type mapping for definition to type.
      4. +
    +
    11. +
  11. If value contains the key @reverse: +
      +
    1. If value contains @id or @nest, members, an + invalid reverse property + error has been detected and processing is aborted.
      2. +
    2. If the value associated with the @reverse key + is not a string, an + invalid IRI mapping + error has been detected and processing is aborted.
      3. +
    3. Otherwise, set the IRI mapping of definition to the + result of using the IRI Expansion algorithm, + passing active context, the value associated with + the @reverse key for value, true + for vocab, + local context, and defined. If the result + is neither an absolute IRI nor a blank node identifier, + i.e., it contains no colon (:), an + invalid IRI mapping + error has been detected and processing is aborted.
      4. +
    4. If value contains an @container member, + set the container mapping of definition + to its value; if its value is neither @set, nor + @index, nor null, an + invalid reverse property + error has been detected (reverse properties only support set- and + index-containers) and processing is aborted.
      5. +
    5. Set the reverse property flag of definition + to true.
      6. +
    6. Set the term definition of term in + active context to definition and the + value associated with defined's key term to + true and return.
      7. +
    +
    12. +
  12. Set the reverse property flag of definition + to false.
    13. +
  13. If value contains the key @id and its value + does not equal term: +
      +
    1. If the value associated with the @id key is not a string, an + invalid IRI mapping + error has been detected and processing is aborted.
      2. +
    2. Otherwise, set the IRI mapping of definition to the + result of using the IRI Expansion algorithm, passing + active context, the value associated with the @id key for + value, true for vocab, + local context, and defined. If the resulting + IRI mapping is neither a keyword, nor an + absolute IRI, nor a blank node identifier, an + invalid IRI mapping + error has been detected and processing is aborted; if it equals @context, an + invalid keyword alias + error has been detected and processing is aborted.
      3. +
    3. If term does not contain a colon (:), + simple term is true, and the, + IRI mapping of definition ends with a URI + gen-delim character, + set the prefix flag in definition to true.
      4. +
    +
    14. +
  14. + Otherwise if the term contains a colon (:): +
      +
    1. If term is a compact IRI with a + prefix that is a key in local context + a dependency has been found. Use this algorithm recursively passing + active context, local context, the + prefix as term, and defined.
      2. +
    2. If term's prefix has a + term definition in active context, set + the IRI mapping of definition to the result of + concatenating the value associated with the prefix's + IRI mapping and the term's suffix.
      3. +
    3. Otherwise, term is an absolute IRI or + blank node identifier. Set the IRI mapping + of definition to term.
      4. +
    +
    15. +
  15. Otherwise, if active context has a + vocabulary mapping, the IRI mapping + of definition is set to the result of concatenating the value + associated with the vocabulary mapping and term. + If it does not have a vocabulary mapping, an + invalid IRI mapping + error been detected and processing is aborted.
    16. +
  16. If value contains the key @container: +
      +
    1. Initialize container to the value associated with the + @container key, which must be either + @graph, + @id, + @index, + @language, + @list, + @set, or + @type. + + or an array containing exactly any one of those + keywords, an array containing @graph and + either @id or @index optionally + including @set, or an array containing a + combination of @set and any of + @index, @id, @type, + @language in any order + . + Otherwise, an + invalid container mapping + has been detected and processing is aborted.
      2. +
    2. If processingMode + is json-ld-1.0 and the container value + is @graph, @id, or @type, or is otherwise not a string, an + invalid container mapping + has been detected and processing is aborted.
      3. +
    3. Set the container mapping of definition to + container.
      4. +
    +
    17. +
  17. If value contains the key @context: +
      +
    1. If processingMode is json-ld-1.0, an + invalid term definition + has been detected and processing is aborted.
      2. +
    2. Initialize context to the value associated with the + @context key, which is treated as a local context.
      3. +
    3. Invoke the Context Processing algorithm + using the active context and context as local context. + If any error is detected, an + invalid scoped context error + has been detected and processing is aborted.
      4. +
    4. Set the local context of definition to context.
      5. +
    +
    18. +
  18. If value contains the key @language and + does not contain the key @type: +
      +
    1. Initialize language to the value associated with the + @language key, which must be either null + or a string. Otherwise, an + invalid language mapping + error has been detected and processing is aborted.
      2. +
    2. If language is a string set it to + lowercased language. Set the language mapping + of definition to language.
      3. +
    +
    19. +
  19. If value contains the key @nest: +
      +
    1. If processingMode is json-ld-1.0, an + invalid term definition + has been detected and processing is aborted.
      2. +
    2. Initialize nest value in defined to the value associated with the + @nest key, which must be a string and + must not be a keyword other than @nest. Otherwise, an + invalid @nest value + error has been detected and processing is aborted.
      3. +
    +
    20. +
  20. If value contains the key @prefix: +
      +
    1. If processingMode is json-ld-1.0, or if + term contains a colon (:), an + invalid term definition + has been detected and processing is aborted.
      2. +
    2. Initialize the prefix flag to the value associated with the + @prefix key, which must be a boolean. Otherwise, an + invalid @prefix value + error has been detected and processing is aborted.
      3. +
    +
    21. +
  21. If the value contains any key other than @id, + @reverse, @container, + @context, @nest, + @prefix, or @type, an + invalid term definition error has + been detected and processing is aborted.
    22. +
  22. Set the term definition of term in + active context to definition and set the value + associated with defined's key term to + true.
    23. +
+
+
+ +
+

4.3 IRI Expansion §

+ +

In JSON-LD documents, some keys and values may represent + IRIs. This section defines an algorithm for + transforming a string that represents an IRI into + an absolute IRI or blank node identifier. + It also covers transforming keyword aliases + into keywords.

+ +

IRI expansion may occur during context processing or during + any of the other JSON-LD algorithms. If IRI expansion occurs during context + processing, then the local context and its related defined + map from the Context Processing algorithm + are passed to this algorithm. This allows for term definition + dependencies to be processed via the + Create Term Definition algorithm.

+ +
+

4.3.1 Overview §

This section is non-normative.

+ +

In order to expand value to an absolute IRI, we must + first determine if it is null, a term, a + keyword alias, or some form of IRI. Based on what + we find, we handle the specific kind of expansion; for example, we expand + a keyword alias to a keyword and a term + to an absolute IRI according to its IRI mapping + in the active context. While inspecting value we + may also find that we need to create term definition + dependencies because we're running this algorithm during context processing. + We can tell whether or not we're running during context processing by + checking local context against null. + We know we need to create a term definition in the + active context when value is + a key in the local context and the defined map + does not have a key for value with an associated value of + true. The defined map is used during + Context Processing to keep track of + which terms have already been defined or are + in the process of being defined. We create a + term definition by using the + Create Term Definition algorithm.

+
+ +
+

4.3.2 Algorithm §

+ +

The algorithm takes two required and four optional input variables. The + required inputs are an active context and a value + to be expanded. The optional inputs are two flags, + document relative and vocab, that specifying + whether value can be interpreted as a relative IRI + against the document's base IRI or the + active context's + vocabulary mapping, respectively, and + a local context and a map defined to be used when + this algorithm is used during Context Processing. + If not passed, the two flags are set to false and + local context and defined are initialized to null.

+ +
    +
  1. If value is a keyword or null, + return value as is.
    2. +
  2. If local context is not null, it contains + a key that equals value, and the value associated with the key + that equals value in defined is not true, + invoke the Create Term Definition algorithm, + passing active context, local context, + value as term, and defined. This will ensure that + a term definition is created for value in + active context during Context Processing. +
    3. +
  3. If active context has a term definition for + value, and the associated IRI mapping is a keyword, + return that keyword.
    4. +
  4. If vocab is true and the + active context has a term definition for + value, return the associated IRI mapping.
    5. +
  5. If value contains a colon (:), it is either + an absolute IRI, a compact IRI, or a + blank node identifier: +
      +
    1. Split value into a prefix and suffix + at the first occurrence of a colon (:).
      2. +
    2. If prefix is underscore (_) + or suffix begins with double-forward-slash + (//), return value as it is already an + absolute IRI or a blank node identifier.
      3. +
    3. If local context is not null, it + contains a key that equals prefix, and the value + associated with the key that equals prefix in defined + is not true, invoke the + Create Term Definition algorithm, + passing active context, + local context, prefix as term, + and defined. This will ensure that a + term definition is created for prefix + in active context during + Context Processing.
      4. +
    4. If active context contains a term definition + for prefix, return the result of concatenating + the IRI mapping associated with prefix and + suffix.
      5. +
    5. Return value as it is already an absolute IRI.
      6. +
    +
    6. +
  6. If vocab is true, and + active context has a vocabulary mapping, + return the result of concatenating the vocabulary mapping + with value.
    7. +
  7. Otherwise, if document relative is true + set value to the result of resolving value against + the base IRI. Only the basic algorithm in + section 5.2 + of [RFC3986] is used; neither + Syntax-Based Normalization nor + Scheme-Based Normalization + are performed. Characters additionally allowed in IRI references are treated + in the same way that unreserved characters are treated in URI references, per + section 6.5 + of [RFC3987].
    8. +
  8. Return value as is.
    9. +
+
+
+
+ + +
+

5. Expansion Algorithms §

+ +
+

5.1 Expansion Algorithm §

+ +

This algorithm expands a JSON-LD document, such that all context + definitions are removed, all terms and + compact IRIs are expanded to + absolute IRIs, + blank node identifiers, or + keywords and all + JSON-LD values are expressed in + arrays in expanded form.

+ +
+

5.1.1 Overview §

This section is non-normative.

+ +

Starting with its root element, we can process the + JSON-LD document recursively, until we have a fully + expanded result. When + expanding an element, we can treat + each one differently according to its type, in order to break down the + problem:

+ +
    +
  1. If the element is null, there is nothing + to expand.
    2. +
  2. Otherwise, if element is a scalar, we expand it + according to the Value Expansion algorithm.
    3. +
  3. Otherwise, if the element is an array, then we expand + each of its items recursively and return them in a new + array.
    4. +
  4. Otherwise, element is a dictionary. We expand + each of its keys, adding them to our result, and then we expand + each value for each key recursively. Some of the keys will be + terms or + compact IRIs and others will be + keywords or simply ignored because + they do not have definitions in the context. Any + IRIs will be expanded using the + IRI Expansion algorithm. +
    5. +
+ +

Finally, after ensuring result is in an array, + we return result.

+
+ +
+

5.1.2 Algorithm §

+ +

The algorithm takes three required and one optional input variables. + The required inputs are an active context, + an active property, and an element to be expanded. + The optional input is the flag frame expansion the allows + special forms of input used for frame expansion. + To begin, the active property is set to null, + and element is set to the JSON-LD input. + If not passed, the frame expansion flag is set to false.

+ +

The algorithm also performs processing steps specific to expanding + a JSON-LD Frame. For a frame, the @id and + @type properties can accept an array of IRIs or + an empty dictionary. The properties of a value object can also + accept an array of strings, or an empty dictionary. + Framing also uses additional keyword properties: + (@explicit, @default, + @embed, @explicit, @omitDefault, or + @requireAll) which are preserved through expansion. + Special processing for a JSON-LD Frame is invoked when the + frame expansion flag is set to true.

+ +
    +
  1. If element is null, return null.
    2. +
  2. If active property is @default, + set the frame expansion flag to false.
    3. +
  3. If element is a scalar, +
      +
    1. If active property is null or @graph, + drop the free-floating scalar by returning null.
      2. +
    2. Return the result of the + Value Expansion algorithm, passing the + active context, active property, and + element as value.
      3. +
    +
    4. +
  4. If element is an array, +
      +
    1. Initialize an empty array, result.
      2. +
    2. For each item in element: +
        +
      1. Initialize expanded item to the result of using this + algorithm recursively, passing active context, + active property, item as element, + and the frame expansion flag.
        2. +
      2. If the active property is @list or its + container mapping includes @list, the + expanded item must not be an array or a + list object, otherwise a + list of lists + error has been detected and processing is aborted.
        3. +
      3. If expanded item is an array, append each + of its items to result. Otherwise, if + expanded item is not null, append it to result.
        4. +
      +
      3. +
    3. Return result.
      4. +
    +
    5. +
  5. Otherwise element is a dictionary.
    6. +
  6. If element contains the key @context, set + active context to the result of the + Context Processing algorithm, + passing active context and the value of the + @context key as local context.
    7. +
  7. For each key/value pair in element + where key expands to @type using the + IRI Expansion algorithm, + passing active context, key for + value, and true for vocab: +
      +
    1. For each term which is a value of value ordered lexicographically, + if term's term definition in active context + has a local context, set active context to the result + to the result of the + Context Processing algorithm, + passing active context and the value of the + term's local context as local context.
      2. +
    +
    8. +
  8. Initialize an empty dictionary, result.
    9. +
  9. For each key and value in element, + ordered lexicographically by key: +
      +
    1. If key is @context, continue to + the next key.
      2. +
    2. Set expanded property to the result of + using the IRI Expansion algorithm, + passing active context, key for + value, and true for vocab.
      3. +
    3. If expanded property is null or it neither + contains a colon (:) nor it is a keyword, + drop key by continuing to the next key.
      4. +
    4. If expanded property is a keyword: +
        +
      1. If active property equals @reverse, an + invalid reverse property map + error has been detected and processing is aborted.
        2. +
      2. If result has already an expanded property member, a + colliding keywords + error has been detected and processing is aborted.
        3. +
      3. If expanded property is @id and + value is not a string, an + invalid @id value + error has been detected and processing is aborted. Otherwise, + set expanded value to the result of using the + IRI Expansion algorithm, + passing active context, value, and true + for document relative. + + When the frame expansion flag is set, value + may be an empty dictionary, or an array of one + or more strings. expanded value will be + an array of one or more of these, with string + values expanded using the IRI Expansion Algorithm.
        4. +
      4. If expanded property is @type and value + is neither a string nor an array of + strings, an + invalid type value + error has been detected and processing is aborted. Otherwise, + set expanded value to the result of using the + IRI Expansion algorithm, passing + active context, true for vocab, + and true for document relative to expand the value + or each of its items. + + When the frame expansion flag is set, value + may also be an empty dictionary.
        5. +
      5. If expanded property is @graph, set + expanded value to the result of using this algorithm + recursively passing active context, @graph + for active property, value for element, + and the frame expansion flag, + + ensuring that expanded value is an array of one or more dictionaries.
        6. +
      6. If expanded property is @value and + value is not a scalar or null, an + invalid value object value + error has been detected and processing is aborted. Otherwise, + set expanded value to value. If expanded value + is null, set the @value + member of result to null and continue with the + next key from element. Null values need to be preserved + in this case as the meaning of an @type member depends + on the existence of an @value member. + + When the frame expansion flag is set, value + may also be an empty dictionary or an array of + scalar values. expanded value will be null, or an + array of one or more scalar values.
        7. +
      7. If expanded property is @language and + value is not a string, an + invalid language-tagged string + error has been detected and processing is aborted. + + Otherwise, set expanded value to lowercased value. + When the frame expansion flag is set, value + may also be an empty dictionary or an array of zero or + strings. expanded value will be an + array of one or more string values converted to lower case.
        8. +
      8. If expanded property is @index and + value is not a string, an + invalid @index value + error has been detected and processing is aborted. Otherwise, + set expanded value to value.
        9. +
      9. If expanded property is @list: +
          +
        1. If active property is null or + @graph, continue with the next key + from element to remove the free-floating list.
          2. +
        2. Otherwise, initialize expanded value to the result of using + this algorithm recursively passing active context, + active property, value for element, + and the frame expansion flag.
          3. +
        3. If expanded value is a list object, a + list of lists + error has been detected and processing is aborted.
          4. +
        +
        10. +
      10. If expanded property is @set, set + expanded value to the result of using this algorithm + recursively, passing active context, + active property, value for element, + and the frame expansion flag.
        11. +
      11. If expanded property is @reverse and + value is not a dictionary, an + invalid @reverse value + error has been detected and processing is aborted. Otherwise +
          +
        1. Initialize expanded value to the result of using this + algorithm recursively, passing active context, + @reverse as active property, + value as element, + and the frame expansion flag.
          2. +
        2. If expanded value contains an @reverse member, + i.e., properties that are reversed twice, execute for each of its + property and item the following steps: +
            +
          1. If result does not have a property member, create + one and set its value to an empty array.
            2. +
          2. Append item to the value of the property member + of result.
            3. +
          +
          3. +
        3. If expanded value contains members other than @reverse: +
            +
          1. If result does not have an @reverse member, create + one and set its value to an empty dictionary.
            2. +
          2. Reference the value of the @reverse member in result + using the variable reverse map.
            3. +
          3. For each property and items in expanded value + other than @reverse: +
              +
            1. For each item in items: +
                +
              1. If item is a value object or list object, an + invalid reverse property value + has been detected and processing is aborted.
                2. +
              2. If reverse map has no property member, create one + and initialize its value to an empty array.
                3. +
              3. Append item to the value of the property + member in reverse map.
                4. +
              +
              2. +
            +
            4. +
          +
          4. +
        4. Continue with the next key from element.
          5. +
        +
        12. +
      12. If expanded property is @nest, + add key to nests, initializing it to an empty array, + if necessary. + Continue with the next key from element.
        13. +
      13. When the frame expansion flag is set, + if expanded property is any other + framing keyword (@explicit, @default, + @embed, @explicit, @omitDefault, or + @requireAll), + set expanded value to the result of performing the + Expansion Algorithm + recursively, passing active context, + active property, value for element, + and the frame expansion flag.
        14. +
      14. Unless expanded value is null, set + the expanded property member of result to + expanded value.
        15. +
      15. Continue with the next key from element.
        16. +
      +
      5. +
    5. If key's term definition in active context + has a local context, set term context to the result of the + Context Processing algorithm, + passing active context and the value of the + key's local context as local context. Otherwise, + set term context to active context.
      6. +
    6. Set container mapping to key's container mapping in + term context.
      7. +
    7. If container mapping includes @language and + value is a dictionary then value + is expanded from a language map + as follows: +
        +
      1. Initialize expanded value to an empty + array.
        2. +
      2. For each key-value pair language-language value + in value, ordered lexicographically by language: +
          +
        1. If language value is not an array + set it to an array containing only + language value.
          2. +
        2. For each item in language value: +
            +
          1. item must be a string + or null, + otherwise an + invalid language map value + error has been detected and processing is aborted.
            2. +
          2. Append a dictionary to + expanded value that consists of two + key-value pairs: (@value-item) + and (@language-lowercased + language), + unless item is null. + If language is @none, + or expands to @none, do not set the @language member. +
          +
          3. +
        +
        3. +
      +
      8. +
    8. Otherwise, if container mapping + includes @index, + @type, or @id and + value is a dictionary then value + is expanded from an map as follows: +
        +
      1. Initialize expanded value to an empty + array.
        2. +
      2. For each key-value pair index-index value + in value, ordered lexicographically by index: +
          +
        1. If container mapping includes @type, + and index's term definition in + term context has a local context, set + map context to the result of the Context Processing + algorithm, passing term context as active context and the + value of the index's local context as + local context. Otherwise, set map context + to term context.
          2. +
        2. Set expanded index to the result of using the + IRI Expansion algorithm, + passing active context, index, and true + for vocab.
          3. +
        3. If index value is not an array + set it to an array containing only + index value.
          4. +
        4. Initialize index value to the result of + using this algorithm recursively, passing + map context as active context, + key as active property, + index value as element, + and the frame expansion flag.
          5. +
        5. For each item in index value: +
            +
          1. If container mapping includes + @graph and if item is not a + graph object, set item to a new + dictionary containing the key-value pair + @graph-item, ensuring that the + value is represented using an array.
            2. +
          2. If container mapping includes @index + and item does not have the key + @index and expanded index is not @none, + add the key-value pair + (@index-index) to item.
            3. +
          3. Otherwise, if container mapping includes @id + and item does not have the key + @id, add the key-value pair + (@id-expanded index) to + item, where expanded index is set to the result of + using the + IRI Expansion algorithm, + passing active context, index, and true + for document relative, unless expanded index + is already set to @none.
            4. +
          4. Otherwise, if container mapping includes @type + set types to the concatenation of + expanded index with any existing values of + @type in item. + If expanded index is @none, + do not concatenate expanded index to types. + Add the key-value pair + (@type-types) to + item.
            5. +
          5. Append item to expanded value.
            6. +
          +
          6. +
        +
        3. +
      +
      9. +
    9. Otherwise, initialize expanded value to the result of + using this algorithm recursively, passing term context as active context, + key for active property, value for element, + and the frame expansion flag.
      10. +
    10. If expanded value is null, ignore key + by continuing to the next key from element.
      11. +
    11. If container mapping includes @list and + expanded value is not already a list object, + convert expanded value to a list object + by first setting it to an array containing only + expanded value if it is not already an array, + and then by setting it to a dictionary containing + the key-value pair @list-expanded value.
      12. +
    12. If container mapping includes + @graph, convert expanded value into an array, if necessary, + then convert each value ev in expanded value into a + graph object: +
        +
      1. If ev is not a graph object, convert it into + one by creating a dictionary containing the key-value + pair @graph-ev + where ev is represented as an array.
        2. +
      +
    13. Otherwise, if the term definition associated to + key indicates that it is a reverse property +
        +
      1. If result has no @reverse member, create + one and initialize its value to an empty dictionary.
        2. +
      2. Reference the value of the @reverse member in result + using the variable reverse map.
        3. +
      3. If expanded value is not an array, set + it to an array containing expanded value.
        4. +
      4. For each item in expanded value +
          +
        1. If item is a value object or list object, an + invalid reverse property value + has been detected and processing is aborted.
          2. +
        2. If reverse map has no expanded property member, + create one and initialize its value to an empty array.
          3. +
        3. Append item to the value of the expanded property + member of reverse map.
          4. +
        +
        5. +
      +
      14. +
    14. Otherwise, if key is not a reverse property: +
        +
      1. If result does not have an expanded property + member, create one and initialize its value to an empty + array.
        2. +
      2. Append expanded value to value of the expanded property + member of result.
        3. +
      +
      15. +
    15. For each key nesting-key in nests +
        +
      1. Set nested values to the value of nesting-key + in element, ensuring that it is an array.
        2. +
      2. For each nested value in nested values: +
          +
        1. If nested value is not a dictionary, or any key within + nested value expands to @value, an + invalid @nest value error + has been detected and processing is aborted.
          2. +
        2. Recursively repeat step 7 + using nested value for element.
          3. +
        +
        3. +
      +
      16. +
    +
    10. +
  10. If result contains the key @value: +
      +
    1. The result must not contain any keys other than + @value, @language, @type, + and @index. It must not contain both the + @language key and the @type key. + Otherwise, an + invalid value object + error has been detected and processing is aborted.
      2. +
    2. If the value of result's @value key is + null, then set result to null.
      3. +
    3. Otherwise, if the value of result's @value member + is not a string and result contains the key + @language, an + invalid language-tagged value + error has been detected (only strings + can be language-tagged) and processing is aborted.
      4. +
    4. Otherwise, if the result has an @type member + and its value is not an IRI, an + invalid typed value + error has been detected and processing is aborted.
      5. +
    +
    11. +
  11. Otherwise, if result contains the key @type + and its associated value is not an array, set it to + an array containing only the associated value.
    12. +
  12. Otherwise, if result contains the key @set + or @list: +
      +
    1. The result must contain at most one other key and that + key must be @index. Otherwise, an + invalid set or list object + error has been detected and processing is aborted.
      2. +
    2. If result contains the key @set, then + set result to the key's associated value.
      3. +
    +
    13. +
  13. If result contains only the key + @language, set result to null.
    14. +
  14. If active property is null or @graph, + drop free-floating values as follows: +
      +
    1. If result is an empty dictionary or contains + the keys @value or @list, set result to + null.
      2. +
    2. Otherwise, if result is a dictionary whose only + key is @id, set result to null. + + When the frame expansion flag is set, a dictionary + containing only the @id key is retained.
      3. +
    +
    15. +
  15. Return result.
    16. +
+ +

If, after the above algorithm is run, the result is a + dictionary that contains only an @graph key, set the + result to the value of @graph's value. Otherwise, if the result + is null, set it to an empty array. Finally, if + the result is not an array, then set the result to an + array containing only the result.

+
+
+ + +
+

5.2 Value Expansion §

+ +

Some values in JSON-LD can be expressed in a + compact form. These values are required + to be expanded at times when processing + JSON-LD documents. A value is said to be in expanded form + after the application of this algorithm.

+ +
+

5.2.1 Overview §

This section is non-normative.

+ +

If active property has a type mapping in the + active context set to @id or @vocab, + and the value is a string, + a dictionary with a single member @id whose + value is the result of using the + IRI Expansion algorithm on value + is returned.

+ +

Otherwise, the result will be a dictionary containing + an @value member whose value is the passed value. + Additionally, an @type member will be included if there is a + type mapping associated with the active property + or an @language member if value is a + string and there is language mapping associated + with the active property.

+ +

Note that values interpreted as IRIs fall into two categories: + those that are document relative, and those that are + vocabulary relative. Properties and values of @type, + along with terms marked as "@type": "@vocab" + are vocabulary relative, meaning that they need to be either + a defined term, a compact IRI + where the prefix is a term, + or a string which is turned into an absolute IRI using + the vocabulary mapping.

+
+ +
+

5.2.2 Algorithm §

+ +

The algorithm takes three required inputs: an active context, + an active property, and a value to expand.

+ +
    +
  1. If the active property has a type mapping + in active context that is @id, + and the value is a string, + return a new + dictionary containing a single key-value pair where the + key is @id and the value is the result of using the + IRI Expansion algorithm, passing + active context, value, and true for + document relative.
    2. +
  2. If active property has a type mapping in + active context that is @vocab, + and the value is a string, + return a new + dictionary containing a single key-value pair where the + key is @id and the value is the result of using the + IRI Expansion algorithm, passing + active context, value, true for + vocab, and true for + document relative.
    3. +
  3. Otherwise, initialize result to a dictionary + with an @value member whose value is set to + value.
    4. +
  4. If active property has a type mapping in + active context, + other than @id or @vocab, + add an @type member to + result and set its value to the value associated with the + type mapping.
    5. +
  5. Otherwise, if value is a string: +
      +
    1. If a language mapping is associated with + active property in active context, + add an @language to result and set its + value to the language code associated with the + language mapping; unless the + language mapping is set to null in + which case no member is added.
      2. +
    2. Otherwise, if the active context has a + default language, add an @language + to result and set its value to the + default language.
      3. +
    +
    6. +
  6. Return result.
    7. +
+
+
+ +
+ + +
+

6. Compaction Algorithms §

+ +
+

6.1 Compaction Algorithm §

+ +

This algorithm compacts a JSON-LD document, such that the given + context is applied. This must result in shortening + any applicable IRIs to + terms or + compact IRIs, any applicable + keywords to + keyword aliases, and + any applicable JSON-LD values + expressed in expanded form to simple values such as + strings or + numbers.

+ +
+

6.1.1 Overview §

This section is non-normative.

+ +

Starting with its root element, we can process the + JSON-LD document recursively, until we have a fully + compacted result. When + compacting an element, we can treat + each one differently according to its type, in order to break down the + problem:

+ +
    +
  1. If the element is a scalar, it is + already in compacted form, so we simply return it.
    2. +
  2. If the element is an array, we compact + each of its items recursively and return them in a new + array.
    3. +
  3. Otherwise element is a dictionary. The value + of each key in element is compacted recursively. Some of the keys will be + compacted, using the IRI Compaction algorithm, + to terms or compact IRIs + and others will be compacted from keywords to + keyword aliases or simply left + unchanged because they do not have definitions in the context. + Values will be converted to compacted form via the + Value Compaction algorithm. Some data + will be reshaped based on container mapping + specified in the context such as @index or @language + maps.
    4. +
+ +

The final output is a dictionary with an @context + key, if a non-empty context was given, where the dictionary + is either result or a wrapper for it where result appears + as the value of an (aliased) @graph key because result + contained two or more items in an array.

+
+ +
+

6.1.2 Algorithm §

+ +

The algorithm takes five required input variables: an active context, + an inverse context, an active property, an + element to be compacted, and a flag + compactArrays + To begin, the active context is set to the result of + performing Context Processing + on the passed context, the inverse context is + set to the result of performing the + Inverse Context Creation algorithm + on active context, the active property is + set to null, element is set to the result of + performing the Expansion algorithm + on the JSON-LD input, and, if not passed, + compactArrays + is set to true.

+ +
    +
  1. If the term definition for active property has a + local context: +
      +
    1. Set active context to the result of the + Context Processing algorithm, + passing active context and the value of the + active property's local context as local context.
      2. +
    2. Set inverse context using the + Inverse Context Creation algorithm + using active context.
      3. +
    +
    2. +
  2. If element is a scalar, it is already in its most + compact form, so simply return element.
    3. +
  3. If element is an array: +
      +
    1. Initialize result to an empty array.
      2. +
    2. For each item in element: +
        +
      1. Initialize compacted item to the result of using this + algorithm recursively, passing active context, + inverse context, active property, and + item for element.
        2. +
      2. If compacted item is not null, then append + it to result.
        3. +
      +
      3. +
    3. If result contains only one item (it has a length of + 1), + + active property is not @graph or @set, + or the container mapping for active property in + active context does not include @list or @set, + + and compactArrays + is true, set result to its only item.
      4. +
    4. Return result.
      5. +
    +
    4. +
  4. Otherwise element is a dictionary. + If element has an @value or @id + member and the result of using the + Value Compaction algorithm, + passing active context, inverse context, + active property,and element as value is + a scalar, return that result.
    5. +
  5. Initialize inside reverse to true if + active property equals @reverse, + otherwise to false.
    6. +
  6. Initialize result to an empty dictionary.
    7. +
  7. If element has a @type member, + create a new array compacted types initialized + by transforming each expanded type of that member + into it's compacted form using the IRI Compaction algorithm, + passing active context, inverse context, + expanded type for var, and + true for vocab. Then, for each term + in compacted types ordered lexicographically: +
      +
    1. If the term definition for term has a + local context: +
        +
      1. Set active context to the result of the + Context Processing algorithm, + passing active context and the value of term's + local context as local context.
        2. +
      2. Set inverse context using the + Inverse Context Creation algorithm + using active context.
        3. +
      +
      2. +
    +
    8. +
  8. For each key expanded property and value expanded value + in element, ordered lexicographically by expanded property: +
      +
    1. If expanded property is @id or + @type: +
        +
      1. If expanded value is a string, + then initialize compacted value to the result + of using the IRI Compaction algorithm, + passing active context, inverse context, + expanded value for var, + and true for vocab if + expanded property is @type, + false otherwise.
        2. +
      2. Otherwise, expanded value must be a + @type array: +
          +
        1. Initialize compacted value to an empty + array.
          2. +
        2. For each item expanded type in + expanded value: +
            +
          1. Set term to the result of + of using the IRI Compaction algorithm, + passing active context, inverse context, + expanded type for var, and + true for vocab.
            2. +
          2. Append term, to compacted value.
            3. +
          +
          3. +
        3. If compacted value contains only one + item (it has a length of 1), then + set compacted value to its only item.
          4. +
        +
        3. +
      3. Initialize alias to the result of using the + IRI Compaction algorithm, + passing active context, inverse context, + expanded property for var, + and true for vocab.
        4. +
      4. Add a member alias to result whose value is + set to compacted value and continue to the next + expanded property.
        5. +
      +
      2. +
    2. If expanded property is @reverse: +
        +
      1. Initialize compacted value to the result of using this + algorithm recursively, passing active context, + inverse context, @reverse for + active property, and expanded value + for element.
        2. +
      2. For each property and value in compacted value: +
          +
        1. If the term definition for property in the + active context indicates that property is + a reverse property +
            +
          1. If the term definition for property in + the active context has a + container mapping including @set or + compactArrays + is false, and value is not an + array, set value to a new + array containing only value.
            2. +
          2. If property is not a member of + result, add one and set its value to value.
            3. +
          3. Otherwise, if the value of the property member of + result is not an array, set it to a new + array containing only the value. Then + append value to its value if value + is not an array, otherwise append each + of its items.
            4. +
          4. Remove the property member from + compacted value.
            5. +
          +
          2. +
        +
        3. +
      3. If compacted value has some remaining members, i.e., + it is not an empty dictionary: +
          +
        1. Initialize alias to the result of using the + IRI Compaction algorithm, + passing active context, inverse context, + @reverse for var, + and true for vocab.
          2. +
        2. Set the value of the alias member of result to + compacted value.
          3. +
        +
        4. +
      4. Continue with the next expanded property from element.
        5. +
      +
      3. +
    3. If expanded property is @preserve + then: +
        +
      1. Initialize compacted value to the result of using this + algorithm recursively, passing active context, + inverse context, property for + active property, and expanded value + for element.
        2. +
      2. Add expanded value as the value of @preserve + in result unless expanded value is an empty array.
        3. +
      +
      4. +
    4. If expanded property is @index and + active property has a container mapping + in active context that includes @index, + then the compacted result will be inside of an @index + container, drop the @index property by continuing + to the next expanded property.
      5. +
    5. Otherwise, if expanded property is @index, + @value, or @language: +
        +
      1. Initialize alias to the result of using + the IRI Compaction algorithm, + passing active context, inverse context, + expanded property for var, + and true for vocab.
        2. +
      2. Add a member alias to result whose value is + set to expanded value and continue with the next + expanded property.
        3. +
      +
      6. +
    6. If expanded value is an empty array: +
        +
      1. Initialize item active property to the result of + using the IRI Compaction algorithm, + passing active context, inverse context, + expanded property for var, + expanded value for value, + true for vocab, and + inside reverse.
        2. +
      2. If the term definition for item active property + in the active context has a nest value, that value (nest term) must be + @nest, or a term in the + active context that expands to @nest, + otherwise an invalid @nest + value error has been detected, and processing is aborted. + If result does not have the key that equals nest + term, initialize it to an empty JSON object (nest + object). If nest object does not have the key + that equals item active property, set this key's + value in nest object to an empty + array.Otherwise, if the key's value is not an + array, then set it to one containing only the + value.
        3. +
      3. Otherwise, if result does not have the key that equals + item active property, set this key's value in + result to an empty array. Otherwise, if + the key's value is not an array, then set it + to one containing only the value.
        4. +
      +
      7. +
    7. + At this point, expanded value must be an + array due to the + Expansion algorithm. + For each item expanded item in expanded value: +
        +
      1. Initialize item active property to the result of using + the IRI Compaction algorithm, + passing active context, inverse context, + expanded property for var, + expanded item for value, + true for vocab, and + inside reverse.
        2. +
      2. If the term definition for item active property + in the active context has a nest value + member, that value (nest term) must be + @nest, or a term in the + active context that expands to @nest, + otherwise an invalid @nest + value error has been detected, and processing is aborted. + Set nest result to the value of nest term in result, + initializing it to a new dictionary, if necessary; otherwise + set nest result to result.
        3. +
      3. Initialize container to null. If there + is a container mapping for + item active property in active context, + set container to the first + such value other than @set.
        4. +
      4. Initialize as array to + true or false depending on if the container mapping for + item active property in active context + includes @set or if item active property + is @graph or @list.
        5. +
      5. Initialize compacted item to the result of using + this algorithm recursively, passing + active context, inverse context, + item active property for active property, + expanded item for element if it does + not contain the key @list + and is not a graph object containing @list, + otherwise pass the key's associated value for element.
        6. +
      6. + If expanded item is a list object: +
          +
        1. If compacted item is not an array, + then set it to an array containing only + compacted item.
          2. +
        2. If container is not @list: +
            +
          1. Convert compacted item to a + list object by setting it to a + dictionary containing key-value pair + where the key is the result of the + IRI Compaction algorithm, + passing active context, inverse context, + @list for var, and compacted item + for value and the value is the original compacted item.
            2. +
          2. If expanded item contains the key + @index, then add a key-value pair + to compacted item where the key is the + result of the IRI Compaction algorithm, + passing active context, inverse context, + @index as var, and the value associated with the + @index key in expanded item as value.
            3. +
          +
          3. +
        3. Otherwise, item active property must not be a key + in nest result because there cannot be two + list objects associated + with an active property that has a + container mapping; a + compaction to list of lists + error has been detected and processing is aborted.
          4. +
        +
        7. +
      7. + If expanded item is a graph object: +
          +
        1. If container includes @graph and @id: +
            +
          1. Initialize map object to the value of item active property + in nest result.
            2. +
          2. Initialize map key to the result of calling the + IRI Compaction algorithm + passing active context and the value of @id in expanded item + or @none if no such value exists as var, with vocab set to true + if there is no @id member in expanded item.
            3. +
          3. If compacted item is not an + array and as array is true, + set compacted item to an array containing that value.
            4. +
          4. If map key is not a key in map object, + then set this key's value in map object + to compacted item. Otherwise, if the value + is not an array, then set it to one + containing only the value and then append + compacted item to it.
            5. +
          +
          2. +
        2. Otherwise, if container includes @graph and @index + and expanded item is a simple graph object: +
            +
          1. Initialize map object to the value of item active property + in nest result.
            2. +
          2. Initialize map key the value of @index in + expanded item or @none, if no such + value exists.
            3. +
          3. If compacted item is not an + array and as array is true, + set compacted item to an array containing that value.
            4. +
          4. If map key is not a key in map object, + then set this key's value in map object + to compacted item. Otherwise, if the value + is not an array, then set it to one + containing only the value and then append + compacted item to it.
            5. +
          +
          3. +
        3. Otherwise, if container includes @graph + and expanded item is a simple graph + object the value cannot be represented as a map + object. If compacted item is not an array + and as array is true, set + compacted item to an array containing + that value. If the value associated with the key that + equals item active property in + nest result is not an array, + set it to a new array containing only the value. + Then append compacted item to the value if + compacted item is not an array, + otherwise, concatenate it. +
          4. +
        4. Otherwise, container does not include @graph + or otherwise does not match one of the previous cases, redo compacted item. +
            +
          1. Set compacted item to a new dictionary containing + the key resulting from calling the IRI Compaction algorithm + passing active context, @graph as + var, and true for + vocab using the original + compacted item as a value.
            2. +
          2. If expanded item contains the key @id, + add the key resulting from calling the IRI Compaction algorithm + passing active context, @id as + var, and true for + vocab using the value resulting from calling the IRI Compaction algorithm + passing active context, the value of @id + in expanded item as + var.
            3. +
          3. If expanded item contains the key @index, + add the key resulting from calling the IRI Compaction algorithm + passing active context, @index as + var, and true for + vocab using the value of @index + in expanded item.
            4. +
          4. If as array is true, + set compacted item to an array + containing that value.
            5. +
          5. Then append compacted item to the value if + compacted item is not an array, + otherwise, concatenate it.
            6. +
          +
          5. +
        +
        8. +
      8. + Otherwise, if container includes @language, + @index, @id, + or @type + and container does not include @graph: +
          +
        1. If item active property is not a key in + nest result, initialize it to an empty dictionary. + Initialize map object to the value of item active property + in nest result.
          2. +
        2. Set container key to the result of calling the + IRI Compaction algorithm + passing active context, + either @language, @index, @id, or @type + based on the contents of container, as var, and true + for vocab.
          3. +
        3. If container includes @language and + expanded item contains the key + @value, then set compacted item + to the value associated with its @value key. + Set map key to the value of @language in expanded item, if any.
          4. +
        4. If container includes @index set map key to the value of @index in expanded item, if any, + and remove container key from compacted item.
          5. +
        5. If container includes @id, set + map key to the value of container key in + compacted item and remove container key from compacted item.
          6. +
        6. If container is @type, + set map key to the first value of container key in compacted item, if any. + If there are remaining values in compacted item + for compacted container, set the value of + compacted container in compacted value + to those remaining values. Otherwise, remove that + key-value pair from compacted item.
          7. +
        7. If compacted item is not an + array and as array is true, + set compacted item to an array containing that value.
          8. +
        8. If map key is null, set it to the result of calling the + IRI Compaction algorithm + passing active context, @none as + var, and true for + vocab.
          9. +
        9. If map key is not a key in map object, + then set this key's value in map object + to compacted item. Otherwise, if the value + is not an array, then set it to one + containing only the value and then append + compacted item to it.
          10. +
        +
        9. +
      9. + Otherwise, +
          +
        1. If + compactArrays + is false, as array is true and + compacted item is not an array, + set it to a new array + containing only compacted item.
          2. +
        2. If item active property is not a key in + result then add the key-value pair, + (item active property-compacted item), + to nest result.
          3. +
        3. Otherwise, if the value associated with the key that + equals item active property in nest result + is not an array, set it to a new + array containing only the value. Then + append compacted item to the value if + compacted item is not an array, + otherwise, concatenate it.
          4. +
        +
        10. +
      +
      8. +
    +
    9. +
  9. Return result.
    10. +
+ +

If, after the algorithm outlined above is run, result + is an empty array, replace it with a new dictionary. + Otherwise, if result is an array, replace it with a new + dictionary with a single member whose key is the result + of using the IRI Compaction algorithm, + passing active context, inverse context, and + @graph as var and whose value is the array + result.

+

Finally, if a non-empty context has been passed, + add an @context member to result and set its value + to the passed context.

+
+
+ +
+

6.2 Inverse Context Creation §

+ +

When there is more than one term that could be chosen + to compact an IRI, it has to be ensured that the term + selection is both deterministic and represents the most context-appropriate + choice whilst taking into consideration algorithmic complexity.

+ +

In order to make term selections, the concept of an + inverse context is introduced. An inverse context + is essentially a reverse lookup table that maps + container mapping, + type mappings, and + language mappings to a simple + term for a given active context. A + inverse context only needs to be generated for an + active context if it is being used for compaction.

+ +

To make use of an inverse context, a list of preferred + container mapping and the + type mapping or language mapping are gathered + for a particular value associated with an IRI. These parameters + are then fed to the Term Selection algorithm, + which will find the term that most appropriately + matches the value's mappings.

+ +
+

6.2.1 Overview §

This section is non-normative.

+ +

To create an inverse context for a given + active context, each term in the + active context is visited, ordered by length, shortest + first (ties are broken by choosing the lexicographically least + term). For each term, an entry is added to + the inverse context for each possible combination of + container mapping and type mapping + or language mapping that would legally match the + term. Illegal matches include differences between a + value's type mapping or language mapping and + that of the term. If a term has no + container mapping, type mapping, or + language mapping (or some combination of these), then it + will have an entry in the inverse context using the special + key @none. This allows the + Term Selection algorithm to fall back + to choosing more generic terms when a more + specifically-matching term is not available for a particular + IRI and value combination.

+
+ +
+

6.2.2 Algorithm §

+ +

The algorithm takes one required input: the active context that + the inverse context is being created for.

+ +
    +
  1. Initialize result to an empty dictionary.
    2. +
  2. Initialize default language to @none. If the + active context has a default language, + set default language to it.
    3. +
  3. For each key term and value term definition in + the active context, ordered by shortest term + first (breaking ties by choosing the lexicographically least + term): +
      +
    1. If the term definition is null, + term cannot be selected during compaction, + so continue to the next term.
      2. +
    2. Initialize container to @none. + + If the container mapping is not empty, set container + to the concatenation of all values of the container mapping + in lexicographically order + .
      3. +
    3. Initialize var to the value of the IRI mapping + for the term definition.
      4. +
    4. If var is not a key in result, add + a key-value pair where the key is var and the value + is an empty dictionary to result.
      5. +
    5. Reference the value associated with the var member in + result using the variable container map.
      6. +
    6. If container map has no container member, + create one and set its value to a new + dictionary with three members. + The first member is @language and its value is a new empty + dictionary, the second member is @type + and its value is a new empty dictionary, + and the third member is @any + and its value is a new dictionary with the member + @none set to the term being processed.
      7. +
    7. Reference the value associated with the container member + in container map using the variable type/language map.
      8. +
    8. If the term definition indicates that the term + represents a reverse property: +
        +
      1. Reference the value associated with the @type + member in type/language map using the variable + type map.
        2. +
      2. If type map does not have an @reverse + member, create one and set its value to the term + being processed.
        3. +
      +
      9. +
    9. Otherwise, if term definition has a + type mapping: +
        +
      1. Reference the value associated with the @type + member in type/language map using the variable + type map.
        2. +
      2. If type map does not have a member corresponding + to the type mapping in term definition, + create one and set its value to the term + being processed.
        3. +
      +
      10. +
    10. Otherwise, if term definition has a + language mapping (might be null): +
        +
      1. Reference the value associated with the @language + member in type/language map using the variable + language map.
        2. +
      2. If the language mapping equals null, + set language to @null; otherwise set it + to the language code in language mapping.
        3. +
      3. If language map does not have a language member, + create one and set its value to the term + being processed.
        4. +
      +
      11. +
    11. Otherwise: +
        +
      1. Reference the value associated with the @language + member in type/language map using the variable + language map.
        2. +
      2. If language map does not have a default language + member, create one and set its value to the term + being processed.
        3. +
      3. If language map does not have an @none + member, create one and set its value to the term + being processed.
        4. +
      4. Reference the value associated with the @type + member in type/language map using the variable + type map.
        5. +
      5. If type map does not have an @none + member, create one and set its value to the term + being processed.
        6. +
      +
      12. +
    +
    4. +
  4. Return result.
    5. +
+
+
+ +
+

6.3 IRI Compaction §

+ +

This algorithm compacts an IRI to a term or + compact IRI, or a keyword to a + keyword alias. A value that is associated with the + IRI may be passed in order to assist in selecting the most + context-appropriate term.

+ +
+

6.3.1 Overview §

This section is non-normative.

+ +

If the passed IRI is null, we simply + return null. Otherwise, we first try to find a term + that the IRI or keyword can be compacted to if + it is relative to active context's + vocabulary mapping. In order to select the most appropriate + term, we may have to collect information about the passed + value. This information includes which + container mapping + would be preferred for expressing the value, and what its + type mapping or language mapping is. For + JSON-LD lists, the type mapping + or language mapping will be chosen based on the most + specific values that work for all items in the list. Once this + information is gathered, it is passed to the + Term Selection algorithm, which will + return the most appropriate term to use.

+ +

If no term was found that could be used to compact the + IRI, an attempt is made to compact the IRI using the + active context's vocabulary mapping, + if there is one. If the IRI could not be compacted, an + attempt is made to find a compact IRI. + A term will be used to create a compact IRI + only if the term definition contains the prefix flag + with the value true. + If there is no appropriate compact IRI, + and the compactToRelative option is true, + the IRI is + transformed to a relative IRI using the document's + base IRI. Finally, if the IRI or + keyword still could not be compacted, it is returned + as is.

+
+ +
+

6.3.2 Algorithm §

+ +

This algorithm takes three required inputs and three optional inputs. + The required inputs are an active context, an inverse context, + and the var to be compacted. The optional inputs are a value associated + with the var, a vocab flag which specifies whether the + passed var should be compacted using the + active context's + vocabulary mapping, and a reverse flag which specifies whether + a reverse property is being compacted. If not passed, value is set to + null and vocab and reverse are both set to + false.

+ +
    +
  1. If var is null, return null.
    2. +
  2. If vocab is true and var is a + key in inverse context: +
      +
    1. Initialize default language to + active context's + default language, if it has one, otherwise to + @none.
      2. +
    2. If value is a dictionary containing + the property @preserve, use the first + element from the value of @preserve as value.
      3. +
    3. Initialize containers to an empty array. This + array will be used to keep track of an ordered list of + preferred container mapping + for a term, based on what is compatible with + value.
      4. +
    4. Initialize type/language to @language, + and type/language value to @null. These two + variables will keep track of the preferred + type mapping or language mapping for + a term, based on what is compatible with value.
      5. +
    5. If value is a dictionary, + that contains the key @index, + and value is not a graph object + then append the values @index and @index@set to containers.
      6. +
    6. If reverse is true, set type/language + to @type, type/language value to + @reverse, and append @set to containers.
      7. +
    7. Otherwise, if value is a list object, then set + type/language and type/language value + to the most specific values that work for all items in + the list as follows: +
        +
      1. If @index is a not key in value, then + append @list to containers.
        2. +
      2. Initialize list to the array associated + with the key @list in value.
        3. +
      3. Initialize common type and common language to null. If + list is empty, set common language to + default language.
        4. +
      4. For each item in list: +
          +
        1. Initialize item language to @none and + item type to @none.
          2. +
        2. If item contains the key @value: +
            +
          1. If item contains the key @language, + then set item language to its associated + value.
            2. +
          2. Otherwise, if item contains the key + @type, set item type to its + associated value.
            3. +
          3. Otherwise, set item language to + @null.
            4. +
          +
          3. +
        3. Otherwise, set item type to @id.
          4. +
        4. If common language is null, set it + to item language.
          5. +
        5. Otherwise, if item language does not equal + common language and item contains the + key @value, then set common language + to @none because list items have conflicting + languages.
          6. +
        6. If common type is null, set it + to item type.
          7. +
        7. Otherwise, if item type does not equal + common type, then set common type + to @none because list items have conflicting + types.
          8. +
        8. If common language is @none and + common type is @none, then + stop processing items in the list because it has been + detected that there is no common language or type amongst + the items.
          9. +
        +
        5. +
      5. If common language is null, set it to + @none.
        6. +
      6. If common type is null, set it to + @none.
        7. +
      7. If common type is not @none then set + type/language to @type and + type/language value to common type.
        8. +
      8. Otherwise, set type/language value to + common language.
        9. +
      +
      8. +
    8. Otherwise, if value is a graph object, + prefer a mapping most appropriate for the particular value. +
        +
      1. If value contains the key @index, + append the values @graph@index and @graph@index@set + to containers.
        2. +
      2. If the value contains the key @id, + append the values @graph@id and @graph@id@set + to containers.
        3. +
      3. Append the values @graph @graph@set, + and @set + to containers.
        4. +
      4. If value does not contain the key @index, + append the values @graph@index and @graph@index@set + to containers.
        5. +
      5. If the value does not contain the key @id, + append the values @graph@id and @graph@id@set + to containers.
        6. +
      6. Append the values @index and @index@set + to containers.
        7. +
      +
      9. +
    9. Otherwise: +
        +
      1. If value is a value object: +
          +
        1. If value contains the key @language + and does not contain the key @index, + then set type/language value to its associated + value and, append @language + and @language@set to + containers.
          2. +
        2. Otherwise, if value contains the key + @type, then set type/language value to + its associated value and set type/language to + @type.
          3. +
        +
        2. +
      2. Otherwise, set type/language to @type + and set type/language value to @id, + and append @id, @id@set, + @type, and @set@type, + to containers.
        3. +
      3. Append @set to containers.
        4. +
      +
      10. +
    10. Append @none to containers. This represents + the non-existence of a container mapping, and it will + be the last container mapping value to be checked as it + is the most generic.
      11. +
    11. + If processing mode is json-ld-1.1 and value does not contain the key @index, append + @index and @index@set to containers. +
      12. +
    12. + If processing mode is json-ld-1.1 and value contains only the key @value, append + @language and @language@set to containers. +
      13. +
    13. If type/language value is null, set it to + @null. This is the key under which null values + are stored in the inverse context entry.
      14. +
    14. Initialize preferred values to an empty array. + This array will indicate, in order, the preferred values for + a term's type mapping or + language mapping.
      15. +
    15. If type/language value is @reverse, append + @reverse to preferred values.
      16. +
    16. If type/language value is @id or @reverse + and value has an @id member: +
        +
      1. If the result of using the + IRI compaction algorithm, + passing active context, inverse context, + the value associated with the @id key in value for + var, and true for vocab has a + term definition in the active context + with an IRI mapping that equals the value associated + with the @id key in value, + then append @vocab, @id, and + @none, in that order, to preferred values.
        2. +
      2. Otherwise, append @id, @vocab, and + @none, in that order, to preferred values.
        3. +
      +
      17. +
    17. Otherwise, append type/language value and @none, in + that order, to preferred values. + If value is an empty list object, + set type/language to @any.
      18. +
    18. Initialize term to the result of the + Term Selection algorithm, passing + inverse context, var, containers, + type/language, and preferred values.
      19. +
    19. If term is not null, return term.
      20. +
    +
    3. +
  3. At this point, there is no simple term that var + can be compacted to. If vocab is true and + active context has a vocabulary mapping: +
      +
    1. If var begins with the + vocabulary mapping's value + but is longer, then initialize suffix to the substring + of var that does not match. If suffix does not + have a term definition in active context, + then return suffix.
      2. +
    +
    4. +
  4. The var could not be compacted using the + active context's vocabulary mapping. + Try to create a compact IRI, starting by initializing + compact IRI to null. This variable will be used to + tore the created compact IRI, if any.
    5. +
  5. For each key term and value term definition in + the active context: +
      +
    1. If the term definition is null, + its IRI mapping equals var, its + IRI mapping is not a substring at the beginning of + var, + or the term definition does not contain + the prefix flag having a value of true, + the term cannot be used as a prefix. + Continue with the next term.
      2. +
    2. Initialize candidate by concatenating term, + a colon (:), and the substring of var + that follows after the value of the + term definition's + IRI mapping.
      3. +
    3. If either compact IRI is null, candidate is + shorter or the same length but lexicographically less than + compact IRI and candidate does not have a + term definition in active context, or if the + term definition has an IRI mapping + that equals var and value is null, + set compact IRI to candidate.
      4. +
    +
    6. +
  6. If compact IRI is not null, return compact IRI.
    7. +
  7. If vocab is false, + transform var to a relative IRI using + the base IRI from active context, if it exists.
    8. +
  8. Finally, return var as is.
    9. +
+
+
+ +
+

6.4 Term Selection §

+ +

This algorithm, invoked via the IRI Compaction algorithm, + makes use of an active context's + inverse context to find the term that is best + used to compact an IRI. Other + information about a value associated with the IRI is given, + including which container mapping + and which type mapping or language mapping would + be best used to express the value.

+ +
+

6.4.1 Overview §

This section is non-normative.

+ +

The inverse context's entry for + the IRI will be first searched according to the preferred + container mapping, in the order + that they are given. Amongst terms with a matching + container mapping, preference will be given to those + with a matching type mapping or language mapping, + over those without a type mapping or + language mapping. If there is no term + with a matching container mapping then the term + without a container mapping that matches the given + type mapping or language mapping is selected. If + there is still no selected term, then a term + with no type mapping or language mapping will + be selected if available. No term will be selected that + has a conflicting type mapping or language mapping. + Ties between terms that have the same + mappings are resolved by first choosing the shortest terms, and then by + choosing the lexicographically least term. Note that these ties are + resolved automatically because they were previously resolved when the + Inverse Context Creation algorithm + was used to create the inverse context.

+
+ +
+

6.4.2 Algorithm §

+ +

This algorithm has five required inputs. They are: + an inverse context, a keyword or IRI + var, an array containers that represents an + ordered list of preferred container mapping, + a string type/language that indicates whether + to look for a term with a matching type mapping + or language mapping, and an array representing + an ordered list of preferred values for the type mapping + or language mapping to look for.

+ +
    +
  1. Initialize container map to the value associated with + var in the inverse context.
    2. +
  2. For each item container in containers: +
      +
    1. If container is not a key in container map, then + there is no term with a matching + container mapping for it, so continue to the next + container.
      2. +
    2. Initialize type/language map to the value associated + with the container member in container map.
      3. +
    3. Initialize value map to the value associated + with type/language member in type/language map.
      4. +
    4. For each item in preferred values: +
        +
      1. If item is not a key in value map, + then there is no term with a matching + type mapping or language mapping, + so continue to the next item.
        2. +
      2. Otherwise, a matching term has been found, return the value + associated with the item member in + value map.
        3. +
      +
      5. +
    +
    3. +
  3. No matching term has been found. Return null.
    4. +
+
+ +
+

6.4.3 Examples §

This section is non-normative.

+

The following examples are intended to illustrate how the term selection algorithm + behaves for different term definitions and values. It is not comprehensive, but + intended to illustrate different parts of the algorithm.

+ +
+
6.4.3.1 Language Map Term §
+

If the term definition has "@container": "@language", it will only match a + value object having no @type.

+
Example 14: Term definition with language map
{
+  "@context": {"t": {"@id": "http://example/t", "@container": "@language"}}
+}
+

The inverse context will contain the following:

+ 
{
+  "@language": {
+    "@language": {"@none": "t"},
+    "@type": {"@none": "t"},
+    "@any": {"@none": "t"}
+  }
+}
+
+ + +
+ +
+
6.4.3.2 Datatyped Term §
+

If the term definition has a datatype, it will only match a + value object having a matching datatype.

+
Example 16: Term definition with datatype
{
+  "@context": {"t": {"@id": "http://example/t", "@type": "http:/example/type"}}
+}
+

The inverse context will contain the following:

+ 
{
+  "@none": {
+    "@language": {},
+    "@type": {"http:/example/type": "t"},
+    "@any": {"@none": "t"}
+  }
+}
+
+ + + + + + +
+
+
+ +
+

6.5 Value Compaction §

+ +

Expansion transforms all values into expanded form + in JSON-LD. This algorithm performs the opposite operation, transforming + a value into compacted form. This algorithm compacts a + value according to the term definition in the given + active context that is associated with the value's associated + active property.

+ +
+

6.5.1 Overview §

This section is non-normative.

+ +

The value to compact has either an @id or an + @value member.

+ +

For the former case, if the type mapping of + active property is set to @id or @vocab + and value consists of only an @id member and, if + the container mapping of active property + includes @index, an @index member, value + can be compacted to a string by returning the result of + using the IRI Compaction algorithm + to compact the value associated with the @id member. + Otherwise, value cannot be compacted and is returned as is.

+ +

For the latter case, it might be possible to compact value + just into the value associated with the @value member. + This can be done if the active property has a matching + type mapping or language mapping and there + is either no @index member or the container mapping + of active property includes @index. It can + also be done if @value is the only member in value + (apart an @index member in case the container mapping + of active property includes @index) and + either its associated value is not a string, there is + no default language, or there is an explicit + null language mapping for the + active property.

+
+ +
+

6.5.2 Algorithm §

+ +

This algorithm has four required inputs: an active context, an + inverse context, an active property, and a value + to be compacted.

+ +
    +
  1. Initialize number members to the number of members + value contains.
    2. +
  2. If value has an @index member and the + container mapping associated to active property + includes @index, decrease number members by + 1.
    3. +
  3. If number members is greater than 2, return + value as it cannot be compacted.
    4. +
  4. If value has an @id member: +
      +
    1. If number members is 1 and + the type mapping of active property + is set to @id, return the result of using the + IRI compaction algorithm, + passing active context, inverse context, + and the value of the @id member for var.
      2. +
    2. Otherwise, if number members is 1 and + the type mapping of active property + is set to @vocab, return the result of using the + IRI compaction algorithm, + passing active context, inverse context, + the value of the @id member for var, and + true for vocab.
      3. +
    3. Otherwise, return value as is.
      4. +
    +
    5. +
  5. Otherwise, if value has an @type member whose + value matches the type mapping of active property, + return the value associated with the @value member + of value.
    6. +
  6. Otherwise, if value has an @language member whose + value matches the language mapping of + active property, return the value associated with the + @value member of value.
    7. +
  7. Otherwise, if number members equals 1 and either + the value of the @value member is not a string, + or the active context has no default language, + or the language mapping of active property + is set to null,, return the value associated with the + @value member.
    8. +
  8. Otherwise, return value as is.
    9. +
+
+
+
+ + +
+

7. Flattening Algorithms §

+ +
+

7.1 Flattening Algorithm §

+ +

This algorithm flattens an expanded JSON-LD document by collecting all + properties of a node in a single dictionary + and labeling all blank nodes with + blank node identifiers. + This resulting uniform shape of the document, may drastically simplify + the code required to process JSON-LD data in certain applications.

+ +
+

7.1.1 Overview §

This section is non-normative.

+ +

First, a node map is generated using the + Node Map Generation algorithm + which collects all properties of a node in a single + dictionary. In the next step, the node map is + converted to a JSON-LD document in + flattened document form. + Finally, if a context has been passed, the flattened document + is compacted using the Compaction algorithm + before being returned.

+
+ +
+

7.1.2 Algorithm §

+ +

The algorithm takes two input variables, an element to flatten and + an optional context used to compact the flattened document. If not + passed, context is set to null.

+ +

This algorithm generates new blank node identifiers + and relabels existing blank node identifiers. + The Generate Blank Node Identifier algorithm + keeps an identifier map and a counter to ensure consistent + relabeling and avoid collisions. Thus, before this algorithm is run, + the identifier map is reset and the counter is initialized + to 0.

+ +
    +
  1. Initialize node map to a dictionary consisting of + a single member whose key is @default and whose value is + an empty dictionary.
    2. +
  2. Perform the Node Map Generation algorithm, passing + element and node map.
    3. +
  3. Initialize default graph to the value of the @default + member of node map, which is a dictionary representing + the default graph.
    4. +
  4. For each key-value pair graph name-graph in node map + where graph name is not @default, perform the following steps: +
      +
    1. If default graph does not have a graph name member, create + one and initialize its value to a dictionary consisting of an + @id member whose value is set to graph name.
      2. +
    2. Reference the value associated with the graph name member in + default graph using the variable entry.
      3. +
    3. Add an @graph member to entry and set it to an + empty array.
      4. +
    4. For each id-node pair in graph ordered by id, + add node to the @graph member of entry, + unless the only member of node is @id.
      5. +
    +
    5. +
  5. Initialize an empty array flattened.
    6. +
  6. For each id-node pair in default graph ordered by id, + add node to flattened, + unless the only member of node is @id.
    7. +
  7. If context is null, return flattened.
    8. +
  8. Otherwise, return the result of compacting flattened according the + Compaction algorithm passing context + ensuring that the compaction result has only the @graph keyword (or its alias) + at the top-level other than @context, even if the context is empty or if there is only one element to + put in the @graph array. This ensures that the returned + document has a deterministic structure.
    9. +
+
+
+ +
+

7.2 Node Map Generation §

+ +

This algorithm creates a dictionary node map holding an indexed + representation of the graphs and nodes + represented in the passed expanded document. All nodes that are not + uniquely identified by an IRI get assigned a (new) blank node identifier. + The resulting node map will have a member for every graph in the document whose + value is another object with a member for every node represented in the document. + The default graph is stored under the @default member, all other graphs are + stored under their graph name.

+ +
+

7.2.1 Overview §

This section is non-normative.

+ +

The algorithm recursively runs over an expanded JSON-LD document to + collect all properties of a node + in a single dictionary. The algorithm constructs a + dictionary node map whose keys represent the + graph names used in the document + (the default graph is stored under the key @default) + and whose associated values are dictionaries + which index the nodes in the + graph. If a + property's value is a node object, + it is replaced by a node object consisting of only an + @id member. If a node object has no @id + member or it is identified by a blank node identifier, + a new blank node identifier is generated. This relabeling + of blank node identifiers is + also done for properties and values of + @type.

+
+ +
+

7.2.2 Algorithm §

+ +

The algorithm takes as input an expanded JSON-LD document element and a reference to + a dictionary node map. Furthermore it has the optional parameters + active graph (which defaults to @default), an active subject, + active property, and a reference to a dictionary list. If + not passed, active subject, active property, and list are + set to null.

+ +
    +
  1. If element is an array, process each item in element + as follows and then return: +
      +
    1. Run this algorithm recursively by passing item for element, + node map, active graph, active subject, + active property, and list.
      2. +
    +
    2. +
  2. Otherwise element is a dictionary. Reference the + dictionary which is the value of the active graph + member of node map using the variable graph. If the + active subject is null, set node to null + otherwise reference the active subject member of graph using the + variable node.
    3. +
  3. If element has an @type member, perform for each + item the following steps: +
      +
    1. If item is a blank node identifier, replace it with a newly + generated blank node identifier + passing item for identifier.
      2. +
    +
    4. +
  4. If element has an @value member, perform the following steps: +
      +
    1. If list is null: +
        +
      1. If node does not have an active property member, + create one and initialize its value to an array + containing element.
        2. +
      2. Otherwise, compare element against every item in the + array associated with the active property + member of node. If there is no item equivalent to element, + append element to the array. Two + dictionaries are considered + equal if they have equivalent key-value pairs.
        3. +
      +
      2. +
    2. Otherwise, append element to the @list member of list.
      3. +
    +
    5. +
  5. Otherwise, if element has an @list member, perform + the following steps: +
      +
    1. Initialize a new dictionary result consisting of a single member + @list whose value is initialized to an empty array.
      2. +
    2. Recursively call this algorithm passing the value of element's + @list member for element, active graph, + active subject, active property, and + result for list.
      3. +
    3. Append result to the value of the active property member + of node.
      4. +
    +
    6. +
  6. Otherwise element is a node object, perform + the following steps: +
      +
    1. If element has an @id member, set id + to its value and remove the member from element. If id + is a blank node identifier, replace it with a newly + generated blank node identifier + passing id for identifier.
      2. +
    2. Otherwise, set id to the result of the + Generate Blank Node Identifier algorithm + passing null for identifier.
      3. +
    3. If graph does not contain a member id, create one and initialize + its value to a dictionary consisting of a single member @id whose + value is id.
      4. +
    4. Reference the value of the id member of graph using the + variable node.
      5. +
    5. If active subject is a dictionary, a reverse property relationship + is being processed. Perform the following steps: +
        +
      1. If node does not have an active property member, + create one and initialize its value to an array + containing active subject.
        2. +
      2. Otherwise, compare active subject against every item in the + array associated with the active property + member of node. If there is no item equivalent to active subject, + append active subject to the array. Two + dictionaries are considered + equal if they have equivalent key-value pairs.
        3. +
      +
      6. +
    6. Otherwise, if active property is not null, perform the following steps: +
        +
      1. Create a new dictionary reference consisting of a single member + @id whose value is id.
        2. +
      2. If list is null: +
          +
        1. If node does not have an active property member, + create one and initialize its value to an array + containing reference.
          2. +
        2. Otherwise, compare reference against every item in the + array associated with the active property + member of node. If there is no item equivalent to reference, + append reference to the array. Two + dictionaries are considered + equal if they have equivalent key-value pairs.
          3. +
        +
        3. +
      3. Otherwise, append reference to the @list member of list.
        4. +
      +
      7. +
    7. If element has an @type key, append + each item of its associated array to the + array associated with the @type key of + node unless it is already in that array. Finally + remove the @type member from element.
      8. +
    8. If element has an @index member, set the @index + member of node to its value. If node has already an + @index member with a different value, a + conflicting indexes + error has been detected and processing is aborted. Otherwise, continue by + removing the @index member from element.
      9. +
    9. If element has an @reverse member: +
        +
      1. Create a dictionary referenced node with a single member @id whose + value is id.
        2. +
      2. Set reverse map to the value of the @reverse member of + element.
        3. +
      3. For each key-value pair property-values in reverse map: +
          +
        1. For each value of values: +
            +
          1. Recursively invoke this algorithm passing value for + element, node map, active graph, + referenced node for active subject, and + property for active property. Passing a + dictionary for active subject indicates to the + algorithm that a reverse property relationship is being processed.
            2. +
          +
          2. +
        +
        4. +
      4. Remove the @reverse member from element.
        5. +
      +
      10. +
    10. If element has an @graph member, recursively invoke this + algorithm passing the value of the @graph member for element, + node map, and id for active graph before removing + the @graph member from element.
      11. +
    11. Finally, for each key-value pair property-value in element ordered by + property perform the following steps: +
        +
      1. If property is a blank node identifier, replace it with a newly + generated blank node identifier + passing property for identifier.
        2. +
      2. If node does not have a property member, create one and initialize + its value to an empty array.
        3. +
      3. Recursively invoke this algorithm passing value for element, + node map, active graph, id for active subject, + and property for active property.
        4. +
      +
      12. +
    +
    7. +
+
+
+ +
+

7.3 Generate Blank Node Identifier §

+ +

This algorithm is used to generate new + blank node identifiers or to + relabel an existing blank node identifier to avoid collision + by the introduction of new ones.

+ +
+

7.3.1 Overview §

This section is non-normative.

+ +

The simplest case is if there exists already a blank node identifier + in the identifier map for the passed identifier, in which + case it is simply returned. Otherwise, a new blank node identifier + is generated by concatenating the string _:b and the + counter. If the passed identifier is not null, + an entry is created in the identifier map associating the + identifier with the blank node identifier. Finally, + the counter is increased by one and the new + blank node identifier is returned.

+
+ +
+

7.3.2 Algorithm §

+ +

The algorithm takes a single input variable identifier which may + be null. Between its executions, the algorithm needs to + keep an identifier map to relabel existing + blank node identifiers + consistently and a counter to generate new + blank node identifiers. The + counter is initialized to 0 by default.

+ +
    +
  1. If identifier is not null and has an entry in the + identifier map, return the mapped identifier.
    2. +
  2. Otherwise, generate a new blank node identifier by concatenating + the string _:b and counter.
    3. +
  3. Increment counter by 1.
    4. +
  4. If identifier is not null, create a new entry + for identifier in identifier map and set its value + to the new blank node identifier.
    5. +
  5. Return the new blank node identifier.
    6. +
+
+
+ +
+

7.4 Merge Node Maps §

+

This algorithm creates a new map of subjects to nodes using all graphs + contained in the graph map created using the Node Map Generation algorithm + to create merged node objects containing information defined for a given subject + in each graph contained in the node map.

+ +
    +
  1. Create result as an empty dictionary
    2. +
  2. For each graph name and node map in graph map + and for each id and node in node map: +
      +
    1. Set merged node to the value for id in result, initializing it + with a new dictionary consisting of a single member @id whose value is id, if it does not exist.
      2. +
    2. For each property and values in node: +
        +
      1. If property is a keyword, add property and values to merged node.
        2. +
      2. Otherwise, merge each element from values into the values for property + in merged node, initializing it to an empty array if necessary.
        3. +
      +
      3. +
    +
    3. +
  3. Return result.
    4. +
+
+ +
+ + +
+

8. RDF Serialization/Deserialization Algorithms §

+ +

This section describes algorithms to deserialize a JSON-LD document to an + RDF dataset and vice versa. The algorithms are designed for in-memory + implementations with random access to dictionary elements.

+ +

Throughout this section, the following vocabulary + prefixes are used in + compact IRIs:

+ + + + + + + + + + + + + + + + + + + + +
PrefixIRI
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http://www.w3.org/2000/01/rdf-schema#
xsdhttp://www.w3.org/2001/XMLSchema#
+ +
+

8.1 Deserialize JSON-LD to RDF algorithm §

+ +

This algorithm deserializes a JSON-LD document to an RDF dataset. + Please note that RDF does not allow a blank node to be used + as a property, while JSON-LD does. Therefore, by default + RDF triples that would have contained blank nodes as properties are + discarded when interpreting JSON-LD as RDF.

+ +
+

8.1.1 Overview §

This section is non-normative.

+ +

The JSON-LD document is expanded and converted to a node map using the + Node Map Generation algorithm. + This allows each graph represented within the document to be + extracted and flattened, making it easier to process each + node object. Each graph from the node map + is processed to extract RDF triple, + to which any (non-default) graph name is applied to create an + RDF dataset. Each node object in the + node map has an @id member which corresponds to the + RDF subject, the other members + represent RDF predicates. Each + member value is either an IRI or + blank node identifier or can be transformed to an + RDF literal + to generate an RDF triple. Lists + are transformed into an + RDF collection + using the List to RDF Conversion algorithm.

+
+ +
+

8.1.2 Algorithm §

+ +

The algorithm takes a JSON-LD document element and returns an + RDF dataset. Unless the produceGeneralizedRdf option + is set to true, RDF triple + containing a blank node predicate + are excluded from output.

+ +

This algorithm generates new blank node identifiers + and relabels existing blank node identifiers. + The Generate Blank Node Identifier algorithm + keeps an identifier map and a counter to ensure consistent + relabeling and avoid collisions. Thus, before this algorithm is run, + the identifier map is reset and the counter is initialized + to 0.

+ +
    +
  1. Expand element according to the + Expansion algorithm.
    2. +
  2. Generate a node map according to the + Node Map Generation algorithm.
    3. +
  3. Initialize an empty RDF dataset dataset.
    4. +
  4. For each graph name and graph in node map + ordered by graph name: +
      +
    1. If graph name is a relative IRI, continue + with the next graph name-graph pair.
      2. +
    2. Initialize triples as an empty array.
      3. +
    3. For each subject and node in graph ordered + by subject: +
        +
      1. If subject is a relative IRI, continue + with the next subject-node pair.
        2. +
      2. For each property and values in node + ordered by property: +
          +
        1. If property is @type, then for each + type in values, append a triple + composed of subject, rdf:type, + and type to triples.
          2. +
        2. Otherwise, if property is a keyword + continue with the next property-values pair.
          3. +
        3. Otherwise, if property is a blank node identifier and + the produceGeneralizedRdf option is not true, + continue with the next property-values pair.
          4. +
        4. Otherwise, if property is a relative IRI, + continue with the next property-values pair.
          5. +
        5. Otherwise, property is an absolute IRI or + blank node identifier. For each item + in values: +
            +
          1. If item is a list object, initialize + list triples as an empty array and + list head to the result of the List Conversion algorithm, passing + the value associated with the @list key from + item and list triples. Append first a + triple composed of subject, + property, and list head to triples and + finally append all triples from + list triples to triples.
            2. +
          2. Otherwise, item is a value object + or a node object. Append a triple + composed of subject, property, and + the result of using the + Object to RDF Conversion algorithm + passing item to triples, unless the result is + null, indicating a relative IRI that has + to be ignored.
            3. +
          +
          6. +
        +
        3. +
      +
      4. +
    4. If graph name is @default, add + triples to the default graph in dataset.
      5. +
    5. Otherwise, create a named graph in dataset + composed of graph name and add triples.
      6. +
    +
    5. +
  5. Return dataset.
    6. +
+
+
+ +
+

8.2 Object to RDF Conversion §

+ +

This algorithm takes a node object or value object + and transforms it into an + RDF resource + to be used as the object of an RDF triple. If a + node object containing a relative IRI is passed to + the algorithm, null is returned which then causes the resulting + RDF triple to be ignored.

+ +
+

8.2.1 Overview §

This section is non-normative.

+ +

Value objects are transformed to + RDF literals as described in + section 8.6 Data Round Tripping + whereas node objects are transformed + to IRIs, + blank node identifiers, + or null.

+
+ +
+

8.2.2 Algorithm §

+ +

The algorithm takes as its sole argument item which MUST be + either a value object or node object.

+ +
    +
  1. If item is a node object and the value of + its @id member is a relative IRI, return + null.
    2. +
  2. If item is a node object, return the + IRI or blank node identifier associated + with its @id member.
    3. +
  3. Otherwise, item is a value object. Initialize + value to the value associated with the @value + member in item. +
  4. Initialize datatype to the value associated with the + @type member of item or null if + item does not have such a member.
    5. +
  5. If value is true or + false, set value to the string + true or false which is the + canonical lexical form as described in + section 8.6 Data Round Tripping + If datatype is null, set it to + xsd:boolean.
    6. +
  6. Otherwise, if value is a number with a non-zero fractional + part (the result of a modulo‑1 operation) or value is a number + and datatype equals xsd:double, convert value to a + string in canonical lexical form of + an xsd:double as defined in [XMLSCHEMA11-2] + and described in + section 8.6 Data Round Tripping. + If datatype is null, set it to + xsd:double.
    7. +
  7. Otherwise, if value is a number with no non-zero + fractional part (the result of a modulo‑1 operation) or value + is a number and datatype + equals xsd:integer, convert value to a + string in canonical lexical form of + an xsd:integer as defined in [XMLSCHEMA11-2] + and described in + section 8.6 Data Round Tripping. + If datatype is null, set it to + xsd:integer.
    8. +
  8. Otherwise, if datatype is null, set it to + xsd:string or rdf:langString, depending on if + item has an @language member.
    9. +
  9. Initialize literal as an RDF literal using + value and datatype. If item has an + @language member, add the value associated with the + @language key as the language tag of literal.
    10. +
  10. Return literal.
    11. +
+
+
+ +
+

8.3 List to RDF Conversion §

+ +

List Conversion is the process of taking a list object + and transforming it into an + RDF collection + as defined in RDF Semantics [RDF11-MT].

+ +
+

8.3.1 Overview §

This section is non-normative.

+ +

For each element of the list a new blank node identifier + is allocated which is used to generate rdf:first and + rdf:rest ABBR. The + algorithm returns the list head, which is either the first allocated + blank node identifier or rdf:nil if the + list is empty. If a list element represents a relative IRI, + the corresponding rdf:first triple is omitted.

+
+ +
+

8.3.2 Algorithm §

+ +

The algorithm takes two inputs: an array list + and an empty array list triples used for returning + the generated triples.

+ +
    +
  1. If list is empty, return rdf:nil.
    2. +
  2. Otherwise, create an array bnodes composed of a + newly generated blank node identifier + for each entry in list.
    3. +
  3. Initialize an empty array list triples.
    4. +
  4. For each pair of subject from bnodes and item from list: +
      +
    1. Initialize object to the result of using the + Object to RDF Conversion algorithm + passing item to list triples.
      2. +
    2. Unless object is null, append a triple + composed of subject, rdf:first, and object.
      3. +
    3. Set rest as the next entry in bnodes, or if that + does not exist, rdf:nil. Append a + triple composed of subject, + rdf:rest, and rest to list triples.
      4. +
    +
    5. +
  5. Return the first blank node from bnodes or + rdf:nil if bnodes is empty.
    6. +
+
+
+ +
+

8.4 Serialize RDF as JSON-LD Algorithm §

+ +

This algorithm serializes an RDF dataset consisting of a + default graph and zero or more + named graphs into a JSON-LD document.

+ +

In the RDF abstract syntax, RDF literals have a + lexical form, as defined + in [RDF11-CONCEPTS]. The form of these literals is used when creating JSON-LD values based on these literals.

+ +
+

8.4.1 Overview §

This section is non-normative.

+ +

Iterate through each graph in the dataset, converting each + RDF collection into a list + and generating a JSON-LD document in expanded form for all + RDF literals, IRIs + and blank node identifiers. + If the use native types flag is set to true, + RDF literals with a + datatype IRI + that equals xsd:integer or xsd:double are converted + to a JSON numbers and RDF literals + with a datatype IRI + that equals xsd:boolean are converted to true or + false based on their + lexical form + as described in + section 8.6 Data Round Tripping. + Unless the use rdf:type flag is set to true, rdf:type + predicates will be serialized as @type as long as the associated object is + either an IRI or blank node identifier.

+
+ +
+

8.4.2 Algorithm §

+ +

The algorithm takes one required and two optional inputs: an RDF dataset dataset + and the two flags use native types and use rdf:type + that both default to false.

+ +
    +
  1. Initialize default graph to an empty dictionary.
    2. +
  2. Initialize graph map to a dictionary consisting + of a single member @default whose value references + default graph.
    3. +
  3. Initialize node usage map to an empty dictionary.
    4. +
  4. For each graph in dataset: +
      +
    1. If graph is the default graph, + set name to @default, otherwise to the + graph name associated with graph.
      2. +
    2. If graph map has no name member, create one and set + its value to an empty dictionary.
      3. +
    3. If graph is not the default graph and + default graph does not have a name member, + create such a member and initialize its value to a new + dictionary with a single member @id + whose value is name.
      4. +
    4. Reference the value of the name member in graph map + using the variable node map.
      5. +
    5. For each RDF triple in graph + consisting of subject, predicate, and object: +
        +
      1. If node map does not have a subject member, + create one and initialize its value to a new dictionary + consisting of a single member @id whose value is + set to subject.
        2. +
      2. Reference the value of the subject member in node map + using the variable node.
        3. +
      3. If object is an IRI or blank node identifier, + and node map does not have an object member, + create one and initialize its value to a new dictionary + consisting of a single member @id whose value is + set to object.
        4. +
      4. If predicate equals rdf:type, the + use rdf:type flag is not true, and object + is an IRI or blank node identifier, + append object to the value of the @type + member of node; unless such an item already exists. + If no such member exists, create one + and initialize it to an array whose only item is + object. Finally, continue to the next + RDF triple.
        5. +
      5. Set value to the result of using the + RDF to Object Conversion algorithm, + passing object and use native types.
        6. +
      6. If node does not have an predicate member, create one + and initialize its value to an empty array.
        7. +
      7. If there is no item equivalent to value in the array + associated with the predicate member of node, append a + reference to value to the array. Two JSON objects + are considered equal if they have equivalent key-value pairs.
        8. +
      8. If object is a blank node identifier or IRI, + it might represent the list node: +
          +
        1. If the object member of node usage map does not exist, + initialize it to a new empty array.
          2. +
        2. Append the value of the @id member of node to + the object member of node usage map.
          3. +
        3. If the object member of node map has no + usages member, create one and initialize it to + an empty array.
          4. +
        4. Reference the usages member of the object + member of node map using the variable usages.
          5. +
        5. Append a new dictionary consisting of three + members, node, property, and value + to the usages array. The node member + is set to a reference to node, property to predicate, + and value to a reference to value.
          6. +
        +
        9. +
      +
      6. +
    +
    5. +
  5. For each name and graph object in graph map: +
      +
    1. If graph object has no rdf:nil member, continue + with the next name-graph object pair as the graph does + not contain any lists that need to be converted.
      2. +
    2. Initialize nil to the value of the rdf:nil member + of graph object.
      3. +
    3. For each item usage in the usages member of + nil, perform the following steps: +
        +
      1. Initialize node to the value of the value of the + node member of usage, property to + the value of the property member of usage, + and head to the value of the value member + of usage.
        2. +
      2. Initialize two empty arrays list + and list nodes.
        3. +
      3. While property equals rdf:rest, + the value of the @id member + of node is a blank node identifier, + the array value of the member of node usage map associated with the @id + member of node has only one member, + + the value associated to the usages member of node has + exactly 1 entry, + node has a rdf:first and rdf:rest property, + both of which have as value an array consisting of a single element, + and node has no other members apart from an optional @type + member whose value is an array with a single item equal to + rdf:List, + node represents a well-formed list node. + Perform the following steps to traverse the list backwards towards its head: +
          +
        1. Append the only item of rdf:first member of + node to the list array.
          2. +
        2. Append the value of the @id member of + node to the list nodes array.
          3. +
        3. Initialize node usage to the only item of the + usages member of node.
          4. +
        4. Set node to the value of the node member + of node usage, property to the value of the + property member of node usage, and + head to the value of the value member + of node usage.
          5. +
        5. If the @id member of node is an + IRI instead of a blank node identifier, + exit the while loop.
          6. +
        +
        4. +
      4. If property equals rdf:first, i.e., the + detected list is nested inside another list +
          +
        1. and the value of the @id of node equals + rdf:nil, i.e., the detected list is empty, + continue with the next usage item. The + rdf:nil node cannot be converted to a + list object as it would result in a list of + lists, which isn't supported.
          2. +
        2. Otherwise, the list consists of at least one item. We preserve the + head node and transform the rest of the linked list to a + list object.
          3. +
        3. Set head id to the value of the @id + member of head.
          4. +
        4. Set head to the value of the head id member of + graph object so that all it's properties can be accessed.
          5. +
        5. Then, set head to the only item in the value of the + rdf:rest member of head.
          6. +
        6. Finally, remove the last item of the list array + and the last item of the list nodes array.
          7. +
        +
        5. +
      5. Remove the @id member from head.
        6. +
      6. Reverse the order of the list array.
        7. +
      7. Add an @list member to head and initialize + its value to the list array.
        8. +
      8. For each item node id in list nodes, remove the + node id member from graph object.
        9. +
      +
      4. +
    +
    6. +
  6. Initialize an empty array result.
    7. +
  7. For each subject and node in default graph + ordered by subject: +
      +
    1. If graph map has a subject member: +
        +
      1. Add an @graph member to node and initialize + its value to an empty array.
        2. +
      2. For each key-value pair s-n in the subject + member of graph map ordered by s, append n + to the @graph member of node after + removing its usages member, unless the only + remaining member of n is @id.
        3. +
      +
      2. +
    2. Append node to result after removing its + usages member, unless the only remaining member of + node is @id.
      3. +
    +
    8. +
  8. Return result.
    9. +
+
+
+ +
+

8.5 RDF to Object Conversion §

+ +

This algorithm transforms an RDF literal to a JSON-LD value object + and a RDF blank node or IRI to an JSON-LD node object.

+ +
+

8.5.1 Overview §

This section is non-normative.

+ +

RDF literals are transformed to + value objects whereas IRIs and + blank node identifiers are + transformed to node objects. + If the use native types flag is set to true, + RDF literals with a + datatype IRI + that equals xsd:integer or xsd:double are converted + to a JSON numbers and RDF literals + with a datatype IRI + that equals xsd:boolean are converted to true or + false based on their + lexical form + as described in + section 8.6 Data Round Tripping.

+
+ +
+

8.5.2 Algorithm §

+ +

This algorithm takes two required inputs: a value to be converted + to a dictionary and a flag use native types.

+ +
    +
  1. If value is an IRI or a + blank node identifier, return a new dictionary + consisting of a single member @id whose value is set to + value.
    2. +
  2. Otherwise value is an + RDF literal: +
      +
    1. Initialize a new empty dictionary result.
      2. +
    2. Initialize converted value to value.
      3. +
    3. Initialize type to null
      4. +
    4. If use native types is true +
        +
      1. If the + datatype IRI + of value equals xsd:string, set + converted value to the + lexical form + of value.
        2. +
      2. Otherwise, if the + datatype IRI + of value equals xsd:boolean, set + converted value to true if the + lexical form + of value matches true, or false + if it matches false. If it matches neither, + set type to xsd:boolean.
        3. +
      3. Otherwise, if the + datatype IRI + of value equals xsd:integer or + xsd:double and its + lexical form + is a valid xsd:integer or xsd:double + according [XMLSCHEMA11-2], set converted value + to the result of converting the + lexical form + to a JSON number.
        4. +
      +
      5. +
    5. Otherwise, if value is a + language-tagged string + add a member @language to result and set its value to the + language tag of value.
      6. +
    6. Otherwise, set type to the + datatype IRI + of value, unless it equals xsd:string which is ignored.
      7. +
    7. Add a member @value to result whose value + is set to converted value.
      8. +
    8. If type is not null, add a member @type + to result whose value is set to type.
      9. +
    9. Return result.
      10. +
    +
    3. +
+
+
+ +
+

8.6 Data Round Tripping §

+ +

When deserializing JSON-LD to RDF + JSON-native numbers are automatically + type-coerced to xsd:integer or xsd:double + depending on whether the number has a non-zero fractional part + or not (the result of a modulo‑1 operation), the boolean values + true and false are coerced to xsd:boolean, + and strings are coerced to xsd:string. + The numeric or boolean values themselves are converted to + canonical lexical form, i.e., a deterministic string + representation as defined in [XMLSCHEMA11-2].

+ +

The canonical lexical form of an integer, i.e., a + number with no non-zero fractional part or a number + coerced to xsd:integer, is a finite-length sequence of decimal + digits (0-9) with an optional leading minus sign; leading + zeros are prohibited. In JavaScript, implementers can use the following + snippet of code to convert an integer to + canonical lexical form:

+ +
Example 20: Sample integer serialization implementation in JavaScript
(value).toFixed(0).toString()
+ +

The canonical lexical form of a double, i.e., a + number with a non-zero fractional part or a number + coerced to xsd:double, consists of a mantissa followed by the + character E, followed by an exponent. The mantissa is a + decimal number and the exponent is an integer. Leading zeros and a + preceding plus sign (+) are prohibited in the exponent. + If the exponent is zero, it is indicated by E0. For the + mantissa, the preceding optional plus sign is prohibited and the + decimal point is required. Leading and trailing zeros are prohibited + subject to the following: number representations must be normalized + such that there is a single digit which is non-zero to the left of + the decimal point and at least a single digit to the right of the + decimal point unless the value being represented is zero. The + canonical representation for zero is 0.0E0. + xsd:double's value space is defined by the IEEE + double-precision 64-bit floating point type [IEEE-754-2008] whereas + the value space of JSON numbers is not + specified; when deserializing JSON-LD to RDF the mantissa is rounded to + 15 digits after the decimal point. In JavaScript, implementers + can use the following snippet of code to convert a double to + canonical lexical form:

+ +
Example 21: Sample floating point number serialization implementation in JavaScript
(value).toExponential(15).replace(/(\d)0*e\+?/,'$1E')
+ +

The canonical lexical form of the boolean + values true and false are the strings + true and false.

+ +

When JSON-native numbers are deserialized + to RDF, lossless data round-tripping cannot be guaranteed, as rounding + errors might occur. When + serializing RDF as JSON-LD, + similar rounding errors might occur. Furthermore, the datatype or the lexical + representation might be lost. An xsd:double with a value + of 2.0 will, e.g., result in an xsd:integer + with a value of 2 in canonical lexical form + when converted from RDF to JSON-LD and back to RDF. It is important + to highlight that in practice it might be impossible to losslessly + convert an xsd:integer to a number because + its value space is not limited. While the JSON specification [RFC7159] + does not limit the value space of numbers + either, concrete implementations typically do have a limited value + space.

+ +

To ensure lossless round-tripping the + Serialize RDF as JSON-LD algorithm + specifies a use native types flag which controls whether + RDF literals + with a datatype IRI + equal to xsd:integer, xsd:double, or + xsd:boolean are converted to their JSON-native + counterparts. If the use native types flag is set to + false, all literals remain in their original string + representation.

+ +

Some JSON serializers, such as PHP's native implementation in some versions, + backslash-escape the forward slash character. For example, the value + http://example.com/ would be serialized as http:\/\/example.com\/. + This is problematic as other JSON parsers might not understand those escaping characters. + There is no need to backslash-escape forward slashes in JSON-LD. To aid + interoperability between JSON-LD processors, forward slashes MUST NOT be + backslash-escaped.

+
+
+ + +
+

9. The Application Programming Interface §

+ +

This API provides a clean mechanism that enables developers to convert + JSON-LD data into a variety of output formats that are often easier to + work with.

+ +

The JSON-LD API uses Promises to represent + the result of the various asynchronous operations. + Promises are defined in [ECMASCRIPT-6.0]. + General use within specifications can be found in [promises-guide].

+ +
+

9.1 The JsonLdProcessor Interface §

+ +

The JsonLdProcessor interface is the high-level programming structure + that developers use to access the JSON-LD transformation methods.

+ +

It is important to highlight that implementations do not modify the input parameters. + If an error is detected, the Promise is + rejected passing a JsonLdError with the corresponding error + code + and processing is stopped.

+ +

If the documentLoader + option is specified, it is used to dereference remote documents and contexts. + The documentUrl + in the returned RemoteDocument + is used as base IRI and the + contextUrl + is used instead of looking at the HTTP Link Header directly. For the sake of simplicity, none of the algorithms + in this document mention this directly.

+ + 
[Constructor]
+interface JsonLdProcessor {
+    static Promise<JsonLdDictionary>           compact(JsonLdInput input,
+                                                       JsonLdContext context,
+                                                       optional JsonLdOptions? options);
+    static Promise<sequence<JsonLdDictionary>> expand(JsonLdInput input,
+                                                      optional JsonLdOptions? options);
+    static Promise<JsonLdDictionary>           flatten(JsonLdInput input,
+                                                       optional JsonLdContext? context,
+                                                       optional JsonLdOptions? options);
+};
+ +
compact
+
+

Compacts the given input using the + context according to the steps in the + Compaction algorithm:

+ +
    +
  1. Create a new Promise promise and return it. The + following steps are then executed asynchronously.
    2. +
  2. Set expanded input to the result of using the + expand + method using input and options. +
  3. If context is a dictionary having an @context member, set + context to that member's value, otherwise to context.
    4. +
  4. Initialize an active context using context; + the base IRI is set to + the base option from + options, if set; + otherwise, if the + compactToRelative option is + true, to the IRI of the currently being processed + document, if available; otherwise to null.
    5. +
  5. Set compacted output to the result of using the + Compaction algorithm, using active context, + an empty dictionary as inverse context, + null as property, + expanded input as element, and if passed, the + compactArrays flag in options.
    6. +
  6. Fulfill the promise passing compacted output. + transforming compacted output from the + internal representation to a JSON serialization.
    7. +
+ +
+
input
+
The dictionary, array of dictionaries to perform the compaction upon or an + IRI referencing the JSON-LD document to compact.
+
context
+
The context to use when compacting the input; + it can be specified by using a dictionary, an + IRI, or an array consisting of + dictionaries and IRIs.
+
options
+
A set of options to configure the algorithms. This allows, e.g., + to set the input document's base IRI.
+
+
+ +
expand
+
+

Expands the given input according to + the steps in the Expansion algorithm:

+ +
    +
  1. Create a new Promise promise and return it. The + following steps are then executed asynchronously.
    2. +
  2. If the passed input is a string + representing the IRI of a remote document, dereference it. + If the retrieved document's content type is neither application/json, + nor application/ld+json, nor any other media type using a + +json suffix as defined in [RFC6839], reject the promise passing an + loading document failed + error.
    3. +
  3. Initialize a new empty active context. The base IRI + of the active context is set to the IRI of the currently being processed + document, if available; otherwise to null. If set, the + base option from options overrides the base IRI.
    4. +
  4. If an + expandContext option + has been passed, update the active context using the + Context Processing algorithm, passing the + expandContext + as local context. If + expandContext + is a dictionary having an @context member, pass that member's value instead.
    5. +
  5. Once input has been retrieved, the response has an HTTP Link Header [RFC5988] + using the http://www.w3.org/ns/json-ld#context link relation + and a content type of application/json or any media type + with a +json suffix as defined in [RFC6839] except + application/ld+json, update the active context using the + Context Processing algorithm, passing the + context referenced in the HTTP Link Header as local context. The + HTTP Link Header is ignored for documents served as application/ld+json If + multiple HTTP Link Headers using the http://www.w3.org/ns/json-ld#context + link relation are found, the promise is rejected with a JsonLdError whose code is set to + multiple context link headers + and processing is terminated.
    6. +
  6. If necessary, transform input into the + internal representation. If input cannot be transformed to the + internal representation, reject promise passing a + loading document failed error.
    7. +
  7. Set expanded output to the result of using the + Expansion algorithm, passing the + active context and input as element, + and, if the frameExpansion option is set, pass the frame expansion flag as true..
    8. +
  8. Fulfill the promise passing expanded output. + transforming expanded output from the + internal representation to a JSON serialization.
    9. +
+ +
+
input
+
The dictionary or array of dictionaries to perform the expansion upon or an + IRI referencing the JSON-LD document to expand.
+
options
+
A set of options to configure the used algorithms such. This allows, e.g., + to set the input document's base IRI.
+
+
+ +
flatten
+
+

Flattens the given input and + compacts it using the passed context + according to the steps in the Flattening algorithm:

+ +
    +
  1. Create a new Promise promise and return it. The + following steps are then executed asynchronously.
    2. +
  2. Set expanded input to the result of using the + expand + method using input and options. +
  3. If context is a dictionary having an @context member, set + context to that member's value, otherwise to context.
    4. +
  4. Initialize an active context using context; + the base IRI is set to + the base option from + options, if set; + otherwise, if the + compactToRelative option is + true, to the IRI of the currently being processed + document, if available; otherwise to null.
    5. +
  5. Initialize an empty identifier map and a counter (set to 0) + to be used by the + Generate Blank Node Identifier algorithm.
    6. +
  6. Set flattened output to the result of using the + Flattening algorithm, passing + expanded input as element, active context, and if passed, the + compactArrays flag in options + (which is internally passed to the + Compaction algorithm).
    7. +
  7. Fulfill the promise passing flattened output. + transforming flattened output from the + internal representation to a JSON serialization.
    8. +
+ +
+
input
+
The dictionary or array of dictionaries or an IRI + referencing the JSON-LD document to flatten.
+
context
+
The context to use when compacting the flattened expanded input; + it can be specified by using a dictionary, an + IRI, or an array consisting of dictionaries + and IRIs. If not + passed or null is passed, the result will not be compacted + but kept in expanded form.
+
options
+
A set of options to configure the used algorithms such. This allows, e.g., + to set the input document's base IRI.
+
+
+ + 
dictionary JsonLdDictionary {
+};
+

The JsonLdDictionary is the definition of a dictionary + used to contain arbitrary key/value pairs which are the result of + parsing a JSON Object. + + 

typedef (JsonLdDictionary or sequence<JsonLdDictionary> or USVString) JsonLdInput;
+ +

The JsonLdInput type is used to refer to an input value that + that may be a dictionary, an array of dictionaries or a string representing an + IRI which an be dereferenced to retrieve a valid JSON document.

+ + 
typedef (JsonLdDictionary or USVString or sequence<(JsonLdDictionary or USVString)>) JsonLdContext;
+ +

The JsonLdContext type is used to refer to a value that + that may be a dictionary, a string representing an + IRI, or an array of dictionaries + and strings.

+
+ +
+

9.2 The JsonLdOptions Type §

+ +

The JsonLdOptions type is used to pass various options to the + JsonLdProcessor methods.

+ + 
dictionary JsonLdOptions {
+    USVString?                       base;
+    boolean                          compactArrays = true;
+    boolean                          compactToRelative = true;
+    LoadDocumentCallback             documentLoader = null;
+    (JsonLdDictionary? or USVString) expandContext = null;
+    boolean                          frameExpansion = false;
+    USVString                        processingMode = null;
+    boolean                          produceGeneralizedRdf = true;
+};
+ +
base
+
The base IRI to use when expanding or compacting the document. If set, this overrides + the input document's IRI.
+
compactArrays
+
If set to true, the JSON-LD processor replaces arrays with just + one element with that element during compaction. If set to false, + all arrays will remain arrays even if they have just one element. +
+
compactToRelative
+
Determines if IRIs are compacted relative to the + base option or document location when compacting.
+
documentLoader
+
The callback of the loader to be used to retrieve remote documents and contexts. + If specified, it is used to retrieve remote documents and contexts; otherwise, + if not specified, the processor's built-in loader is used.
+
expandContext
+
A context that is used to initialize the active context when expanding a document.
+
frameExpansion
+
Enables special frame processing rules for the Expansion Algorithm.
processingMode
+
Sets the processing mode. + If set to json-ld-1.0 or json-ld-1.1, the + implementation must produce exactly the same results as the algorithms + defined in this specification. + If set to another value, the JSON-LD processor is allowed to extend + or modify the algorithms defined in this specification to enable + application-specific optimizations. The definition of such + optimizations is beyond the scope of this specification and thus + not defined. Consequently, different implementations may implement + different optimizations. Developers must not define modes beginning + with json-ld as they are reserved for future versions + of this specification.
+
produceGeneralizedRdf
+
If set to true, the JSON-LD processor may emit blank nodes for + triple predicates, otherwise they will be omitted.
+
+
+ +
+

9.3 Remote Document and Context Retrieval §

+ +

Users of an API implementation can utilize a callback to control how remote + documents and contexts are retrieved. This section details the parameters of + that callback and the data structure used to return the retrieved context.

+ +
+

9.3.1 LoadDocumentCallback §

+ +

The LoadDocumentCallback defines a callback that custom document loaders + have to implement to be used to retrieve remote documents and contexts.

+ + 
callback LoadDocumentCallback = Promise<USVString> (USVString url);
+ +
+
url
+
The URL of the remote document or context to load.
+
+ +

All errors result in the Promise being rejected with + a JsonLdError whose code is set to + loading document failed + or multiple context link headers + as described in the next section.

+
+ +
+

9.3.2 RemoteDocument §

+ +

The RemoteDocument type is used by a LoadDocumentCallback + to return information about a remote document or context.

+ + 
dictionary RemoteDocument {
+    USVString contextUrl = null;
+    USVString documentUrl;
+    any       document;
+};
+ +
+
contextUrl
+
If available, the value of the HTTP Link Header [RFC5988] using the + http://www.w3.org/ns/json-ld#context link relation in the + response. If the response's content type is application/ld+json, + the HTTP Link Header is ignored. If multiple HTTP Link Headers using + the http://www.w3.org/ns/json-ld#context link relation are found, + the Promise of the LoadDocumentCallback is rejected with + a JsonLdError whose code is set to + multiple context link headers.
+
documentUrl
+
The final URL of the loaded document. This is important + to handle HTTP redirects properly.
+
document
+
The retrieved document. This can either be the raw payload or the already + parsed document.
+
+
+
+ +
+

9.4 Error Handling §

+ +

This section describes the datatype definitions used within the + JSON-LD API for error handling.

+ +
+

9.4.1 JsonLdError §

+ +

The JsonLdError type is used to report processing errors.

+ + 
dictionary JsonLdError {
+    JsonLdErrorCode code;
+    USVString?      message = null;
+};
+ +
+
code
+
a string representing the particular error type, as described in + the various algorithms in this document.
+
message
+
an optional error message containing additional debugging information. + The specific contents of error messages are outside the scope of this + specification.
+
+
+ +
+

9.4.2 JsonLdErrorCode §

+

The JsonLdErrorCode represents the collection of valid JSON-LD error + codes.

+ + 
enum JsonLdErrorCode {
+    "colliding keywords",
+    "compaction to list of lists",
+    "conflicting indexes",
+    "cyclic IRI mapping",
+    "invalid @id value",
+    "invalid @index value",
+    "invalid @nest value",
+    "invalid @prefix value",
+    "invalid @reverse value",
+    "invalid @version value",
+    "invalid base IRI",
+    "invalid container mapping",
+    "invalid default language",
+    "invalid IRI mapping",
+    "invalid keyword alias",
+    "invalid language map value",
+    "invalid language mapping",
+    "invalid language-tagged string",
+    "invalid language-tagged value",
+    "invalid local context",
+    "invalid remote context",
+    "invalid reverse property",
+    "invalid reverse property map",
+    "invalid reverse property value",
+    "invalid scoped context",
+    "invalid set or list object",
+    "invalid term definition",
+    "invalid type mapping",
+    "invalid type value",
+    "invalid typed value",
+    "invalid value object",
+    "invalid value object value",
+    "invalid vocab mapping",
+    "keyword redefinition",
+    "list of lists",
+    "loading document failed",
+    "loading remote context failed",
+    "multiple context link headers",
+    "processing mode conflict",
+    "recursive context inclusion"
+};
+ +
colliding keywords
+
Two properties which expand to the same keyword have been detected. + This might occur if a keyword and an alias thereof + are used at the same time.
+
compaction to list of lists
+
The compacted document contains a list of lists as multiple + lists have been compacted to the same term.
+
conflicting indexes
+
Multiple conflicting indexes have been found for the same node.
+
cyclic IRI mapping
+
A cycle in IRI mappings has been detected.
+
invalid @id value
+
An @id member was encountered whose value was not a + string.
+
invalid @index value
+
An @index member was encountered whose value was + not a string.
+
invalid @nest value
+
An invalid value for @nest has been found.
+
invalid @prefix value
+
An invalid value for @prefix has been found.
+
invalid @reverse value
+
An invalid value for an @reverse member has been detected, + i.e., the value was not a dictionary.
+
invalid @version value
+
The @version key was used in a context with + an out of range value.
+
invalid base IRI
+
An invalid base IRI has been detected, i.e., it is + neither an absolute IRI nor null.
+
invalid container mapping
+
An @container member was encountered whose value was + not one of the following strings: + @list, @set, or @index.
+
invalid default language
+
The value of the default language is not a string + or null and thus invalid.
+
invalid IRI mapping
+
A local context contains a term that has + an invalid or missing IRI mapping.
+
invalid keyword alias
+
An invalid keyword alias definition has been + encountered.
+
invalid language map value
+
An invalid value in a language map + has been detected. It has to be a string or an array of + strings.
+
invalid language mapping
+
An @language member in a term definition + was encountered whose value was neither a string nor + null and thus invalid.
+
invalid language-tagged string
+
A language-tagged string with an invalid language + value was detected.
+
invalid language-tagged value
+
A number, true, or false with an + associated language tag was detected.
+
invalid local context
+
In invalid local context was detected.
+
invalid remote context
+
No valid context document has been found for a referenced, + remote context.
+
invalid reverse property
+
An invalid reverse property definition has been detected.
+
invalid reverse property map
+
An invalid reverse property map has been detected. No + keywords apart from @context + are allowed in reverse property maps.
+
invalid reverse property value
+
An invalid value for a reverse property has been detected. The value of an inverse + property must be a node object.
+
invalid scoped context
+
The local context defined within a term definition is invalid.
+
invalid set or list object
+
A set object or list object with + disallowed members has been detected.
+
invalid term definition
+
An invalid term definition has been detected.
+
invalid type mapping
+
An @type member in a term definition + was encountered whose value could not be expanded to an + absolute IRI.
+
invalid type value
+
An invalid value for an @type member has been detected, + i.e., the value was neither a string nor an array + of strings.
+
invalid typed value
+
A typed value with an invalid type was detected.
+
invalid value object
+
A value object with disallowed members has been + detected.
+
invalid value object value
+
An invalid value for the @value member of a + value object has been detected, i.e., it is neither + a scalar nor null.
+
invalid vocab mapping
+
An invalid vocabulary mapping has been detected, i.e., + it is neither an absolute IRI nor null.
+
keyword redefinition
+
A keyword redefinition has been detected.
+
list of lists
+
A list of lists was detected. List of lists are not supported in + this version of JSON-LD due to the algorithmic complexity.
+
loading document failed
+
The document could not be loaded or parsed as JSON.
+
loading remote context failed
+
There was a problem encountered loading a remote context.
+
multiple context link headers
+
Multiple HTTP Link Headers [RFC5988] using the + http://www.w3.org/ns/json-ld#context link relation + have been detected.
+
processing mode conflict
+
An attempt was made to change the processing mode which is + incompatible with the previous specified version.
+
recursive context inclusion
+
A cycle in remote context inclusions has been detected.
+
+
+
+ +

A. IDL Index §

This section is non-normative.

+
[Constructor]
+interface JsonLdProcessor {
+    static Promise<JsonLdDictionary>           compact(JsonLdInput input,
+                                                       JsonLdContext context,
+                                                       optional JsonLdOptions? options);
+    static Promise<sequence<JsonLdDictionary>> expand(JsonLdInput input,
+                                                      optional JsonLdOptions? options);
+    static Promise<JsonLdDictionary>           flatten(JsonLdInput input,
+                                                       optional JsonLdContext? context,
+                                                       optional JsonLdOptions? options);
+};
+dictionary JsonLdDictionary {
+};
+typedef (JsonLdDictionary or sequence<JsonLdDictionary> or USVString) JsonLdInput;
+typedef (JsonLdDictionary or USVString or sequence<(JsonLdDictionary or USVString)>) JsonLdContext;
+dictionary JsonLdOptions {
+    USVString?                       base;
+    boolean                          compactArrays = true;
+    boolean                          compactToRelative = true;
+    LoadDocumentCallback             documentLoader = null;
+    (JsonLdDictionary? or USVString) expandContext = null;
+    boolean                          frameExpansion = false;
+    USVString                        processingMode = null;
+    boolean                          produceGeneralizedRdf = true;
+};
+callback LoadDocumentCallback = Promise<USVString> (USVString url);
+dictionary RemoteDocument {
+    USVString contextUrl = null;
+    USVString documentUrl;
+    any       document;
+};
+dictionary JsonLdError {
+    JsonLdErrorCode code;
+    USVString?      message = null;
+};
+enum JsonLdErrorCode {
+    "colliding keywords",
+    "compaction to list of lists",
+    "conflicting indexes",
+    "cyclic IRI mapping",
+    "invalid @id value",
+    "invalid @index value",
+    "invalid @nest value",
+    "invalid @prefix value",
+    "invalid @reverse value",
+    "invalid @version value",
+    "invalid base IRI",
+    "invalid container mapping",
+    "invalid default language",
+    "invalid IRI mapping",
+    "invalid keyword alias",
+    "invalid language map value",
+    "invalid language mapping",
+    "invalid language-tagged string",
+    "invalid language-tagged value",
+    "invalid local context",
+    "invalid remote context",
+    "invalid reverse property",
+    "invalid reverse property map",
+    "invalid reverse property value",
+    "invalid scoped context",
+    "invalid set or list object",
+    "invalid term definition",
+    "invalid type mapping",
+    "invalid type value",
+    "invalid typed value",
+    "invalid value object",
+    "invalid value object value",
+    "invalid vocab mapping",
+    "keyword redefinition",
+    "list of lists",
+    "loading document failed",
+    "loading remote context failed",
+    "multiple context link headers",
+    "processing mode conflict",
+    "recursive context inclusion"
+};
+
+ +
+

B. Security Considerations §

+
Editor's note

Consider requirements from Self-Review Questionnaire: Security and Privacy.

+
+ +
+

C. Changes since 1.0 Recommendation of 16 January 2014 §

This section is non-normative.

+ +
+ +
+

D. Open Issues §

This section is non-normative.

+

The following is a list of issues open at the time of publication.

+
Issue 246: Ignoring semantically meaningless nestingapideferspec-designsyntax

Thanks for the great work with JSON-LD! However, when trying to use JSON-LD for to present data in the company I'm working in, I noticed the following missing feature:

+

FEATURE PROPOSAL: ABILITY TO DEFINE ANY KEY AS AN INDEX KEY

+

In addition to JSON-LD's existing index container structure, I propose that any key under a JSON-LD node could be defined as a index key.

+

This would help clustering data under a node into coder friendly logical groups without messing up the Linked Data interpretation with e.g. blank nodes. I encountered the need for this feature at our company where our problem is that the amount of attributes a single JSON-LD node can have can potentially be quite many, say, tens or hundreds of attributes.

+

As far as I know, this can not be currently done with JSON-LD without 1) ending up with blank nodes or 2) the need to create a deeper JSON structure by using a separate index term (using "@container":"@index") which then contains the data underneath.

+

In addition, if a single key could be defined as a index term, this would make it more flexible to attach the JSON-LD Linked Data interpretation to even a wider amount of existing JSON data, without having to change the structure of such data (and without ending up with e.g. lots of blank nodes).

+

DEFINING AN INDIVIDUAL INDEX KEY IN @context

+

The "@context" definition could be done e.g. using the existing reserved keyword "@index" in the following way:

+
"indexkey":"@index"
+
+

which should be interpreted in the following way: 1) the "indexkey" is an index key and should be skipped when traversing the JSON tree while doing the JSON-LD to RDF interpretation, 2) any data directly under the "indexkey" should be interpreted as data directly attached to the node of the indexkey (same RDF subject).

+

EXAMPLE

+

To give a full example, in the following a single key "labels" is defined as an index index key to help grouping the data into coder friendly logical groups without messing up the Linked Data interpretation):

+
{
+  "@context": {
+     "labels":"@index",
+     "main_label":"http://example.org/my-schema#main_label",
+     "other_label":"http://example.org/my-schema#other_label",
+     "homepage":{ "@id":"http://example.org/my-schema#homepage", "@type":"@id"}
+  },
+  "@id":"http://example.org/myresource",
+  "homepage": "http://example.org",
+  "labels": {
+     "main_label": "This is the main label for my resource",
+     "other_label": "This is the other label"
+  }
+}
+

This example JSON-LD should generate the following RDF triplets:

+
<http://example.org/myresource> <http://example.org/my-schema#homepage> <http://example.org>. 
+<http://example.org/myresource> <http://example.org/my-schema#main_label> "This is the main label for my resource".
+<http://example.org/myresource> <http://example.org/my-schema#other_label> "This is the other label".
+
+
Issue 333: Support JSON values that aren't mappedapideferspec-designsyntax

This has already been discussed several times usingvarious terms.. the most recent request has come from David Janes on the mailing list. The basic idea is to support JSON values/subtrees that aren't mapped to an IRI in the context. They should survive algorithmic transformations (basically without being touched at all).

+
Issue 338: Option to compact terms but not valuesapidefer

_This was raised by Fabian Steeg:_

+
+

The JSON-LD API document states: "Expansion has two important goals: removing any contextual information from the document, and ensuring all values are represented in a regular form."

+

Is there a way to achieve only the second goal, the regular form, but with compact terms? Using compaction with compactArrays=false is pretty close, but there is still at least one thing that is irregular and causing issues for me.

+

Given this input:

+
{
+  "http://example.com/foo": "foo-value",
+  "http://example.com/bar": {
+    "@value": "bar-value",
+    "@language": "en"
+  },
+  "@context": {
+    "foo": "http://example.com/foo",
+    "bar": "http://example.com/bar"
+  }
+}
+
+

I get this from compaction with compactArrays=false:

+
{
+  "@graph": [{
+    "foo": ["foo-value"],              <-- foo: array of strings
+    "bar": [{                          <-- bar: array of objects
+      "@language": "en",
+      "@value": "bar-value"
+    }]
+  }],
+  "@context": {
+    "foo": "http://example.com/foo",
+    "bar": "http://example.com/bar"
+  }
+}
+
+

But I'd like to get this (which is what expansion does to the values):

+
{
+  "@graph": [{
+    "foo": [{                          <-- both foo and bar:
+      "@value" : "foo-value"               array of objects
+    }],
+    "bar": [{
+      "@language": "en",
+      "@value": "bar-value"
+    }]
+  }],
+  "@context": {
+    "foo": "http://example.com/foo",
+    "bar": "http://example.com/bar"
+  }
+}
+
+

So I guess I'm looking for something like a compactValues=false option.

+

Is there some way to get this output?

+
+
Issue 357: Lists shared between graphs are not correctly serializedapispec-bug

_Reported by @afs:_

+

We are encountering an issue when converting RDF Datasets to JSON-LD.

+

The problem is with blank nodes that are shared between graphs and lists.

+

In TriG (yes, this is a synthetic reduced test case that captures a
+smaller example that might appear for real):

+
# Bnode references across graph and lists
+PREFIX :        <http://www.example.com/>
+PREFIX rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
+
+:G {
+   # Written in short form it would be:
+   # :z :q ("cell-A" "cell-B")
+   # but we want to share the tail ("cell-B")
+
+   :z :q _:z0 .
+
+   _:z0   rdf:first "cell-A" .
+   _:z0   rdf:rest  _:z1 .
+
+   _:z1   rdf:first "cell-B" .
+   _:z1   rdf:rest rdf:nil .
+}
+
+:G1 {
+    # This references the tail  ("cell-B")
+    :x :p _:z1 .
+}
+
+

The triple in :G1 references into the list in :G.

+

But as we understand the conversion algorithm, section 4 only considers
+each graph in turn and so does not see the cross graph sharing.

+

Is this a correct reading of the spec text?

+

Part 4 of the conversion algorithm has
+"For each name and graph object in graph map: "

+

so 4.3.3.* walks back up the list in one graph only.

+

(Conversion generated by jsonld-java : it does not matter if compaction
+is applied or not):

+
{
+   "@graph" : [ {
+     "@graph" : [ {
+       "@id" : ":z",
+       ":q" : {
+         "@list" : [ "cell-A", "cell-B" ]
+       }
+     } ],
+     "@id" : ":G"
+   }, {
+     "@graph" : [ {
+       "@id" : ":x",
+       ":p" : {
+         "@id" : "_:b1"
+       }
+     } ],
+     "@id" : ":G1"
+   } ],
+   "@context" : {
+     "@base" : "http://www.example.com/",
+     "" : "http://www.example.com/",
+     "rdf" : "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   }
+}
+
+

There is no _:b1 in :G to refer to because the algorith generated @list
+and its implicit bNodes don't have labels.
+This is a different dataset with no shared bNode.

+

If it is all the same graph (s/:G1/:G/), the RDF dataset structure is
+correctly serialized.

+

Andy

+
Issue 368: JSON-LD 1.1 Feature Request: Object-level @languageapideferspec-designsyntax

See: digitalbazaar/jsonld.js#72

+

It would be helpful to have the ability to use @language within an object as a shorthand for "@context": {"@language": "..."} ... for instance... make:

+
{
+  "@language": "en",
+  "displayName": "foo"
+}
+

equivalent to:

+
{
+  "@context": {"@language": "en"}, 
+  "displayName": "foo"
+}
+
Issue 371: JSON-LD 1.1 Feature Request: New @label keywordapideferspec-designsyntax

In the spirit of "Labeling Everything" (http://patterns.dataincubator.org/book/label-everything.html) ... it would be worthwhile, IMO, for JSON-LD to provide a basic @Label keyword for use both in @context and nodes. It's largely syntactic sugar but would be useful.

+

For example:

+
{
+  "@context": {
+    "@label": "An Example Context",
+    "displayName": "@label",
+  },
+  "displayName": "A Simple Label"
+}
+

Which would expand to:

+
_:c14n0 <http://www.w3.org/2000/01/rdf-schema#label> "A Simple Label" .
+
+
Issue 397: JSON-LD 1.1 Feature Request: support @values for describing multidimensional containers (list of lists)apideferspec-designsyntax

Problem description §

+

Many JSON specs existed before JSON-LD. A couple of these specs may not be compatible with JSON-LD as they contain multidimensional containers, such as GeoJSON.

+

Example of a multidimensional array:

+
[ [3.1,51.06,30],
+  [3.1,51.06,20] ]
+

This issue is a result from the discussion on the GeoJSON-LD repository: geojson/geojson-ld#32. If this issue will not get resolved, the GeoJSON-LD community would suggest creating custom JSON-LD parsers for JSON-LD dialects. This situation would be far from desirable.

+

Suggested solution §

+

Introduce a new @values keyword, which can be used to describe the values of a @set or a @list container in more detail.

+

When an array is given in the @values, then the precise amount of objects within this array corresponds with the array in the graph in this order.

+

When an object is given in the @values, each value of the array in the graph is mapped according to this template.

+

Example §

+
{
+  "@context": {
+     "coordinates": {
+        "@id": "geojson:coordinates",
+        "@container" : "@list",
+        "@values" : { 
+           "@type" : "geojson:Coordinate",
+           "@container" : "@set",
+           "@values" : [
+               {"@type" : "xsd:double", "@id":"geo:longitude"},
+               {"@type" : "xsd:double", "@id":"geo:latitude"}
+           ]
+        }
+     }
+  },
+  "@graph" : [{
+   "@id" : "ex:LineString1",
+    "coordinates" : [
+          [
+            3.1057405471801753,
+            51.064216229943476
+          ],
+          [
+            3.1056976318359375,
+            51.063434090307574
+          ]
+    ]
+  }]
+}
+

Would transform to (and vice versa):

+
ex:LineString1 geojson:coordinates _:b0 .
+_:b0 rdf:first _:b1 .
+_:b1 a geojson:Coordinate ;
+      geo:longitude "3.105740547180175E0"^^xsd:double ;
+      geo:latitude "5.106421622994348E1"^^xsd:double .
+_:b0 rdf:rest _:b2 .
+_:b2 rdf:first a geojson:Coordinate ;
+      geo:longitude "3.1056976318359375"^^xsd:double ;
+      geo:latitude "51.063434090307574"^^xsd:double .
+_:b2 rdf:rest rdf:nil .
+
Issue 402: Relax the colliding keywords constraint for @typeapideferspec-design

I want the following:

+
{
+  "@context": {
+    "type": "@type",
+    "profile": "@type"
+  },
+  "type": "cov:Coverage",
+  "profile": "cov:GridCoverage"
+}
+

However this is not allowed. The playground says "Invalid JSON-LD syntax; colliding keywords detected".

+

However, this one works:

+
{
+  "@context": {
+    "type": {"@id": "rdf:type", "@type": "@id" },
+    "profile": {"@id": "rdf:type", "@type": "@id" }
+  },
+  "type": "cov:Coverage",
+  "profile": "cov:GridCoverage"
+}
+

I understand that this restriction probably makes sense for other keywords, but could it do any harm for @type?

+
Issue 434: Streaming Profiles for JSON-LD to/from RDFapideferspec-design

There have been some discussions on what it would take to be able to do a streaming parse of JSON-LD into Quads, and similarly to generate compliant JSON-LD from a stream of quads. Describing these as some kind of a profile would be useful for implementations that expect to work in a streaming environment, when it's not feasible to work on an entire document basis.

+

As currently stated, the JSON-LD to RDF algorithm requires expanding the document and creating a node map. A profile of JSON-LD which used a flattened array of node objects, where each node object could be independently expanded and no flattening is required could facilitate deserializing an arbitrarily long JSON-LD source to Quads. (Some simplifying restrictions on shared lists may be necessary). Outer document is an object, containing @context and @graph only; obviously, this only will work for systems that can access key/values in order, and for systems that ensure that @context comes lexically before @graph in the output. Obviously, only implementations that can read and write JSON objects with key ordering intact will be able to take advantage of such streaming capability.

+

Fo serializing RDF to JSON-LD, expectations on the grouping of quads with the same graph name and subject are necessary to reduce serialization cost, and marshaling components of RDF Lists is likely not feasible. Even if graph name/subject grouping is not maintained in the input, the resulting output will still represent a valid JSON-LD document, although it may require flattening for further processing. (Many triple stores will, in fact, generate statements/quads properly grouped, so this is likely not an issue in real world applications).

+
Issue 460: "Stratified" or "Dictionaried" API featureapideferspec-design

Hi there,

+

I was looking for a way to access properties in a JSON-LD document based on triples (to patch the document). This would mean having a view which creates a dictionary for a given document. The term Normalisation is already used, but this approach would be close to the way https://github.com/paularmstrong/normalizr. D3 uses https://github.com/d3/d3-hierarchy/blob/master/README.md#stratify in a slightly different way but with the same general intent.

+

The goal would be to be able to address document values with this syntax stratified_doc[triple.subject][triple.predicate] or even better stratified[triple.graph][triple.subject][triple.predicate].

+

This could also be a @stratified parameter for expansion.

+

Example §

+

For a document:

+
{
+  "@context": {
+    "dc": "http://purl.org/dc/elements/1.1/",
+    "ex": "http://example.org/vocab#",
+    "xsd": "http://www.w3.org/2001/XMLSchema#",
+    "ex:contains": {
+      "@type": "@id"
+    }
+  },
+  "@id": "http://example.org/graph/0",
+  "dc:creator": "Jane Doe",
+  "@graph": [
+    {
+      "@id": "http://example.org/library",
+      "@type": "ex:Library",
+      "ex:contains": "http://example.org/library/the-republic"
+    }
+  ]
+}
+

Such a stratified would therefore look like:

+
{
+  "http://example.org/graph/0": {
+   "http://example.org/library": {
+      "@type": "http://example.org/vocab#Library",
+      "http://example.org/vocab#contains": {
+        "@id": "http://example.org/library/the-republic"
+      }
+    },
+    "http://example.org/library/the-republic": {}
+  },
+  "@graph": {
+    "http://example.org/graph/0": {
+      "http://purl.org/dc/elements/1.1/creator": "Jane Doe"
+    }
+  }
+}
+

This would therefore allow to do the following:

+
// Access a triple from the default graph
+var creator = stratified['@graph']['http://example.org/graph/0']['http://purl.org/dc/elements/1.1/creator'];
+// "Jane Doe"
+
+// Access a triple in a named graph
+var type = stratified['http://example.org/graph/0']['http://example.org/library']['@type'];
+// "http://example.org/vocab#Library"
+
+// Before submitting a document, mutate a property
+stratified['http://example.org/graph/0']['http://example.org/library/the-republic']['@type'] = 'http://example.org/vocab#Book';
+
+// Or using an immutable spread syntax approach
+var new_doc = { 
+  ...stratified, 
+  'http://example.org/graph/0': {
+    ...stratified['http://example.org/graph/0'],
+    'http://example.org/library/the-republic' : {
+      ...stratified['http://example.org/graph/0']['http://example.org/library/the-republic'],
+      '@type': 'http://example.org/vocab#Book'
+    }
+  }
+}
+
Issue 507: JSON-LD 1.1: method to require {"id": "uri"} resource compaction resultapidefer

Issue: The compaction algorithm prefers the most compact format, which for resources without relationships is a string containing the URI. This causes problems in systems that cannot handle arrays of mixed data types (for example ElasticSearch) when there are also resources that have relationships, resulting in both objects and strings in the same array.

+

For example:

+
"seeAlso": [
+    "http://example.org/reference1",
+    {"id": "http://example.org/reference2", "format": "text/html"}
+  ]
+
+

would raise an error in Elastic.

+

Proposed solution: Provide a flag to the compaction algorithm to signal that the resulting JSON should always create objects for resources, even if there is only the URI available. This would instead render the example above as an array of objects:

+
"seeAlso": [
+    {"id": "http://example.org/reference1"},
+    {"id": "http://example.org/reference2", "format": "text/html"}
+  ]
+
+
Issue 512: @type as @container:@set?apispec-design

The purpose of the @container:@set functionality (AFAIU) is to ensure that the output is consistent in shape. Thus if there can ever be multiple values, the structure is always an array.

+

There are two situations in which this functionality could be desirable but is currently not possible:

+
    +
  1. @type As it's a keyword, we can only alias it (e.g. as type) but not define it to have @container:@set functionality. Meaning that there's a gotcha waiting to happen for ontologies that require or use multiple classes for a single resource instance. See playground
    2. +
  2. @context Less useful, but @context will also compact to a single string/object when there might be multiple contexts. See playground
    3. +
+

@context modifying itself seems particularly strange, but the inconsistency for @type seems solvable if the restrictions in its definition were loosened?

+
Issue 526: precedence of @vocab for compaction too strong?apideferspec-design

This is related to #235: When I have the following document:

+
{
+  "@context": {
+    "@vocab"  : "http://vocab.getty.edu/",
+    "a"     : "http://vocab.getty.edu/aaaaaaaaaat/"
+  }, 
+  "@id" : "http://vocab.getty.edu/aaaaaaaaaat/5001065997",
+  "@type": "http://vocab.getty.edu/aaaaaaaaaat/datatype"
+}
+

By point 3 of the spec, because http://vocab.getty.edu/aaaaaaaaaat/5001065997 contains the value of @vocab, it gets compacted as aaaaaaaaaat/5001065997 without even looking at the prefixes. I think this is not reasonable, in this case a:5001065997 would look much nicer IMO.

+
Issue 530: Losing Last Element in RDF Listapiquestion

We have web application that needs to be able to modify RDF lists from a triple store and propagate the changes back. To do this, we are utilizing jsonld-java to serialize the RDF into JSON-LD, modifying it in the web app, and then sending it back to be deserialized and stored in the triple store. Originally, we were using blank nodes like the ones shown in Turtle below.

+
<http://example.com> <http://example.com/property> _:a .
+_:a a <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "a" ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> _:b .
+_:b a <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "b" ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> _:c .
+_:c a <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "c" ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .
+
+

However, we discovered that blank node lists are collapsed during serialization thus losing all the blank node IDs.

+
[ {
+  "@id" : "http://example.com",
+  "http://example.com/property" : [ {
+    "@list" : [ {
+      "@value" : "a"
+    }, {
+      "@value" : "b"
+    }, {
+      "@value" : "c"
+    } ]
+  } ]
+} ]
+

With blank node IDs removed, we are no longer able to reference the existing RDF in the triple store to perform updates when the lists are modified in the web-app without much more complex logic. To avoid this, we skolemized the blank node IDs into IRIs.

+
<http://example.com> <http://example.com/property> <urn:a> .
+<urn:a> a <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "a" ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <urn:b> .
+<urn:b> a <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "b" ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <urn:c> .
+<urn:c> a <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "c" ;
+    <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .
+
+

However, when serializing the skolemized triples, the IRI for the last element in the RDF list is hidden, in this case urn:c. This leads to the same problem we were having when using blank node IDs.

+
[ {
+  "@id" : "http://example.com",
+  "http://example.com/property" : [ {
+    "@id" : "urn:a"
+  } ]
+}, {
+  "@id" : "urn:a",
+  "@type" : [ "http://www.w3.org/1999/02/22-rdf-syntax-ns#List" ],
+  "http://www.w3.org/1999/02/22-rdf-syntax-ns#first" : [ {
+    "@value" : "a"
+  } ],
+  "http://www.w3.org/1999/02/22-rdf-syntax-ns#rest" : [ {
+    "@id" : "urn:b"
+  } ]
+}, {
+  "@id" : "urn:b",
+  "@type" : [ "http://www.w3.org/1999/02/22-rdf-syntax-ns#List" ],
+  "http://www.w3.org/1999/02/22-rdf-syntax-ns#first" : [ {
+    "@value" : "b"
+  } ],
+  "http://www.w3.org/1999/02/22-rdf-syntax-ns#rest" : [ {
+    "@list" : [ {
+      "@value" : "c"
+    } ]
+  } ]
+} ]
+

Issue #277 seems to be the point where the implementation changed from serializing lists in the manner we expect to this new compact way. Is there any way we can get around this so that the last blank node of a list is not collapsed?

+
Issue 542: Feature request: Could framing return properties in the order listed by the frame? apideferframing

Currently it appears that properties are sorted into alphabetical order after any JSON-LD operation (compaction, framing).

+

In the context of framing, this is sometimes a nice feature, since it means that after framing multiple input JSON files, the JSON data is at least in a consistent order.

+

I understand that ordering is semantically meaningless, but as framing exists to turn the graph (which could correspond to multiple different trees) into a predictable JSON tree as a convenience for developers, it seems natural to me that if an explicit ordering is given in the frame, that the algorithm would respect that order rather than alphabetize. For example, if my data is:

+
{
+  "@context": "http://schema.org/",
+  "@id": "document",
+  "b": "text",
+  "a": "more text"
+ 
+}
+
+

Under the frame:

+
{
+  "@context": "http://schema.org/",
+  "@id":  "document",
+  "b": {},
+  "a": {}
+}
+
+

(example in playground)

+

the returned document reverses the order of b and a (to be alphabetical), and not the order given in the frame. Framing is a really elegant way to specify the nesting order, but it would be nice for framing to also be able to dictate the ordering, so that the output data file really follows the exact structure of the given frame.

+

Related issue: there is no way to indicate that referenced nodes should occur before they are references (excluding circular references), which can be useful in streaming files. Having control of the node order via the frame would also give a mechanism to address that.

+

Hope this makes sense and apologies if I'm missing something fundamental here that makes alphabetizing the node order the only logical thing to do; or if I've misunderstood the expected behavior.

+
Issue 548: Use version 2.0 instead of 1.1apideferspec-designsyntax

Comments at TPAC suggested that as our work is a breaking change (causing 1.0 processors that are not 1.1 compatible to intentionally break when they see "@version": 1.1), semantic versioning would suggest that we use a major release number, rather than a minor number.

+

This could impact a potential WG, which may want to make further changes, and then be in the place of using either 2.1 or 3.0, which is odd given that the previous recommendation is 1.0.

+

In some situations it is important/necessary to include the base direction of a text, alongside its language; see the “Requirements for Language and Direction Metadata in Data Formats” for further details. In practice, in a vanilla JSON, it would require something like:

+
"title": [ { "value": "Moby Dick", "lang": "en" },
+           { "value": "موبي ديك", "lang": "ar"  "dir": "rtl"}
+         ]  
+
+

(the example comes from that document).

+

At this moment, I believe the only way you can reasonably express that in JSON-LD is via cheating a bit:

+
"title": [ { "@value": "Moby Dick", "@language": "en" },
+           { "@value": "موبي ديك",  "@language": "ar"  "dir": "rtl"}
+         ]  
+
+

and making sure that the dir term is not defined in the relevant @context so that, when generating the RDF output, that term is simply ignored. But that also means that there is no round-tripping, that term will disappear after expansion.

+

The difficulty lies in the RDF layer, in fact; RDF does not have any means (alas!) to express text direction. On the other hand, this missing feature is a general I18N problem whenever JSON-LD is used (there were issues when developing the Web Annotation Model, these issues are popping up in the Web Publication work, etc.).

+

Here is what I would propose as a non-complete solution

+
    +
  1. Let us introduce a @dir term, alongside @language. This means this term can be used in place of dir above, ie, it is a bona-fide part of a string representation, and would therefore be kept in the compaction/expansion steps, can also be used for framing.
    2. +
  2. In JSON-LD 1.1, @dir is ignored when transforming into RDF. I.e., only the language tag would be used.
    3. +
  3. We may initiate some work in the RDF community to solve this issue. There may be several ways, each of them require the RDF community to chime in
    +3.1. Define a mechanism of "parametrized" standard datatypes that represent a (language,direction) pair. One would then get something like[] ex:title "موبي ديك"^^rdf:internationalText(ar,rtl) ;
    +3.2. Go for a "generalized" RDF where strings can also appear as subjects (that has been a matter of dispute for a long time...). That would give the possibility to add such attribute to texts like directions
    +3.3. Some other mechanisms that I cannot think about
    4. +
  4. In a future JSON-LD 1.* the @dir value can be properly mapped onto an RDF representing the right choices (if such choices are worked out)
    5. +
+

Cc: @BigBlueHat @r12a

+
Issue 595: Native support for schema:ListItemapideferspec-designsyntax

Per a suggestion by @danbri, we may want to add a container type, similar to @list for encoding schema:ItemList serializations, when the values are schema:ListItem and order is set through schema:position. ItemList can be used with text values as well, but this is already reasonably supported natively.

+

Markup might look like the following:

+
{
+  "@context": {
+    "@vocab": "http://schema.org/",
+    "itemListElement": {"@container": "@listItem"}
+  },
+  "@type": "ItemList",
+  "@url": "http://en.wikipedia.org/wiki/Billboard_200",
+  "name": "Top music artists",
+  "description": "The artists with the most cumulative weeks at number one according to Billboard 200",
+  "itemListElement": [
+    {"@type": "MusicGroup", "name": "Beatles"},
+    {"@type": "MusicGroup", "name": "Elvis Presley"},
+    {"@type": "MusicGroup", "name": "Michael Jackson"},
+    {"@type": "MusicGroup", "name": "Garth Brooks" }
+  ]
+

This would expand to the following:

+
[
+  {
+    "@id": "http://en.wikipedia.org/wiki/Billboard_200",
+    "@type": ["http://schema.org/ItemList"],
+    "http://schema.org/description": [{
+      "@value": "The artists with the most cumulative weeks at number one according to Billboard 200"
+    }],
+    "http://schema.org/itemListElement": [{
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Beatles"}]
+      }],
+      "http://schema.org/position": [{"@value": 1}]
+    },  {
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Elvis Presley"}]
+      }],
+      "http://schema.org/position": [{"@value": 2}]
+    }, {
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Michael Jackson"}]
+      }],
+      "http://schema.org/position": [{"@value": 3}]
+    }, {
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Garth Brooks"}]
+      }],
+      "http://schema.org/position": [{"@value": 3}]
+    }
+  ],
+  "http://schema.org/name": [{"@value": "Top music artists"}]
+}]
+

Otherwise, it works like @list.

+

When compacting, the processor will re-order items based on position, and ignore any nextItem or previousItem entries.

+

Expansion shows 1-base position, but could be 0-base as well. Note that specific position values are lost when compacting, and duplicate values may lead to undefined relative ordering.

+
Issue 589: JSON-LD version on playgroundplayground

During the last meeting it was resolved to have one playground for 1.0 and 1.1 processing. Some notes on that related to jsonld.js:

+
    +
  • 0.4.x passes older 1.0 test suites
    • +
  • 0.4.x does not pass more recent tests added for 1.0
    • +
  • 0.5.x does pass all current 1.0 tests
    • +
  • 0.5.x also includes a bit of 1.1 functionality, in particular some @graph handling and a bit of @version handling
    • +
  • 0.6.x should end up passing all 1.0 and current 1.1 draft tests
    • +
  • there may be technical issues using multiple jsonld.js versions on one page
    • +
+

From an ease of site development viewpoint, I think we should just put the most recent jsonld.js on the playground and add a UI control to pick the processingMode API option. Due to practicalities of jsonld.js not having a full correct 1.0 only lib, it seems not worth the effort to try and deal with this any other way. There are edge cases where a 1.1 lib in 1.0 mode will produce different results than a 1.0 lib. My guess is that in practice this really doesn't matter. Or in any case, is not worth handling on the playground.

+
+ +
+

E. Acknowledgements §

This section is non-normative.

+ +

A large amount of thanks goes out to the JSON-LD Community Group + participants who worked through many of the technical issues on the mailing + list and the weekly telecons - of special mention are Niklas Lindström, + François Daoust, Lin Clark, and Zdenko 'Denny' Vrandečić. + The editors would like to thank Mark Birbeck, who provided a great deal of + the initial push behind the JSON-LD work via his work on RDFj. + The work of Dave Lehn and Mike Johnson are appreciated for reviewing, + and performing several implementations of the specification. Ian Davis is + thanked for his work on RDF/JSON. Thanks also to Nathan Rixham, + Bradley P. Allen, Kingsley Idehen, Glenn McDonald, Alexandre Passant, + Danny Ayers, Ted Thibodeau Jr., Olivier Grisel, Josh Mandel, Eric Prud'hommeaux, + David Wood, Guus Schreiber, Pat Hayes, Sandro Hawke, and Richard Cyganiak + for their input on the specification.

+
+ + + +

F. References §

F.1 Normative references §

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47 +
[IEEE-754-2008]
IEEE 754-2008 Standard for Floating-Point Arithmetic. Institute of Electrical and Electronics Engineers. 2008. URL: http://standards.ieee.org/findstds/standard/754-2008.html +
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ +
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld/ +
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/ +
[RDF11-MT]
RDF 1.1 Semantics. Patrick Hayes; Peter Patel-Schneider. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-mt/ +
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 +
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986 +
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987 +
[RFC5988]
Web Linking. M. Nottingham. IETF. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5988 +
[RFC7159]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7159 +
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/ +

F.2 Informative references §

[ECMASCRIPT-6.0]
ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html +
[JSON-LD-API]
JSON-LD 1.0 Processing Algorithms and API. Markus Lanthaler; Gregg Kellogg; Manu Sporny. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld-api/ +
[JSON-LD-TESTS]
JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ +
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-api/ +
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-framing/ +
[promises-guide]
Writing Promise-Using Specifications. Domenic Denicola. W3C. 16 February 2016. Finding of the W3C TAG. URL: https://www.w3.org/2001/tag/doc/promises-guide +
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/ +
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ +
[RFC6839]
Additional Media Type Structured Syntax Suffixes. T. Hansen; A. Melnikov. IETF. January 2013. Informational. URL: https://tools.ietf.org/html/rfc6839 +
[TURTLE]
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/ +
[WEBIDL]
Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/ +
\ No newline at end of file diff --git a/spec/CG-FINAL/json-ld-framing/20180507/index.html b/spec/CG-FINAL/json-ld-framing/20180507/index.html new file mode 100644 index 000000000..3a58e21ee --- /dev/null +++ b/spec/CG-FINAL/json-ld-framing/20180507/index.html @@ -0,0 +1,2965 @@ + +JSON-LD 1.1 Framing + + + + + + + +
+ +

JSON-LD 1.1 Framing

+

An Application Programming Interface for the JSON-LD Syntax

+

Final Community Group Report

+
+ + +
Latest editor's draft:
https://json-ld.org/spec/latest/json-ld-framing/
+
Test suite:
https://json-ld.org/test-suite/
+ + +
Previous version:
https://json-ld.org/spec/ED/json-ld-framing/20120830/
+ +
Editor:
+
Gregg Kellogg (Spec-Ops)
+
Former editors:
Manu Sporny (Digital Bazaar)
Dave Longley (Digital Bazaar)
Markus Lanthaler (Graz University of Technology)
+
Authors:
Dave Longley (Digital Bazaar) (v1.0)
Manu Sporny (Digital Bazaar) (v1.0)
Gregg Kellogg (Spec-Ops) (v1.0 and v1.1)
Markus Lanthaler (Graz University of Technology) (v1.0)
Niklas Lindström (v1.0)
+
Participate:
+ GitHub json-ld/json-ld.org +
+ File a bug +
+ Commit history +
+ Pull requests +
+
+ +

+ Copyright © + 2010-2018 + the Contributors to the JSON-LD 1.1 Framing Specification, published by the + Linking Data in JSON Community Group under the + W3C Community Final Specification Agreement (FSA). + A human-readable summary is available. + +

+
+
+

Abstract

+

JSON-LD Framing allows developers to query by example and + force a specific tree layout to a JSON-LD document.

+
+ +

Status of This Document

+ This specification was published by the Linking Data in JSON Community Group. + It is not a W3C Standard nor is it on the W3C Standards Track. + + Please note that under the + W3C Community Final Specification Agreement (FSA) + other conditions apply. + + Learn more about + W3C Community and Business Groups. +

This document has been developed by the + JSON for Linking Data W3C Community Group. + The specification has undergone + significant development, review, and changes during the course of several years.

There are several independent + interoperable implementations of + this specification, a test suite [JSON-LD-TESTS] and a + live JSON-LD playground that is capable + of demonstrating the features described in this document.

If you wish to make comments regarding this document, please send them to + public-linked-json@w3.org + (subscribe, + archives).

+

Set of Documents

+

This document is one of three JSON-LD 1.1 Recommendations produced by the + JSON for Linking Data W3C Community Group:

+ + +
+ +
+

1. Introduction §

+

A JSON-LD document is a representation of a directed graph. A single + directed graph can have many different serializations, each expressing + exactly the same information. Developers typically work with trees, represented as + JSON objects. While mapping a graph to + a tree can be done, the layout of the end result must be specified in advance. + A Frame can be used by a developer on a JSON-LD document to + specify a deterministic layout for a graph.

+ +
+

1.1 How to Read this Document §

+ +

+This document is a detailed specification for a serialization of Linked +Data in JSON. The document is primarily intended for the following audiences: +

+ +
    +
  • Authors who want to query JSON-LD documents to create representations + more appropriate for a given use case.
    • +
  • Software developers that want to implement processors and APIs for + JSON-LD.
    • +
+ +

+To understand the basics in this specification you must first be familiar with +JSON, which is detailed in [RFC7159]. You must also understand the +JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all of the +algorithms in this document, +and the JSON-LD 1.1 API [JSON-LD11CG-API]. To understand the API and how it is +intended to operate in a programming environment, it is useful to have working +knowledge of the JavaScript programming language [ECMASCRIPT-6.0] and +WebIDL [WEBIDL]. To understand how JSON-LD maps to RDF, it is helpful to be +familiar with the basic RDF concepts [RDF-CONCEPTS].

+ +
+ +
+

1.2 Contributing §

+ +

There are a number of ways that one may participate in the development of + this specification:

+ +
    +
  • Technical discussion typically occurs on the public mailing list: + public-linked-json@w3.org
    • + + + +
  • The #json-ld + IRC channel is available for real-time discussion on irc.freenode.net.
    • +
+ +
+ +
+

1.3 Terminology §

+ +

This document uses the following terms as defined in JSON [RFC7159]. Refer + to the JSON Grammar section in [RFC7159] for formal definitions.

+ +
array
+ In the JSON serialization, an array structure is represented as square brackets surrounding zero + or more values. Values are separated by commas. + In the internal representation, an array is an ordered collection of zero or more values. + While JSON-LD uses the same array representation as JSON, + the collection is unordered by default. While order is + preserved in regular JSON arrays, it is not in regular JSON-LD arrays + unless specifically defined (see + Sets and Lists in + the JSON-LD Syntax specification [JSON-LD11CG]).
+
JSON object
+ In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or + more key-value pairs. A key is a string. A single colon comes after + each key, separating the key from the value. A single comma separates a value + from a following key. In JSON-LD the keys in an object MUST be unique. + In the internal representation a JSON object is equivalent to a + dictionary (see [WEBIDL]).
+
JSON-LD internal representation
The JSON-LD + internal representation is the result of transforming a JSON syntactic structure + into the core data structures suitable for direct processing: + arrays, dictionaries, + strings, numbers, booleans, and null.
+
null
+ The use of the null value within JSON-LD is used to + ignore or reset values. A key-value pair in the @context where + the value, or the @id of the value, is null + explicitly decouples a term's association with an IRI. A key-value pair in + the body of a JSON-LD document whose value is null has the + same meaning as if the key-value pair was not defined. If + @value, @list, or @set is set to + null in expanded form, then the entire JSON + object is ignored.
+
number
+ In the JSON serialization, a number is similar to that used in most programming languages, except + that the octal and hexadecimal formats are not used and that leading + zeros are not allowed. + In the internal representation, a number is equivalent to either + a long + or double, depending + on if the number has a non-zero fractional part (see [WEBIDL]).
+
+
string
+ A string is a sequence of zero or more Unicode (UTF-8) characters, + wrapped in double quotes, using backslash escapes (if necessary). A + character is represented as a single character string.
+
true and false
+ Values that are used to express one of two possible + boolean states.
+ +

Furthermore, the following terminology is used throughout this document:

+ +
absolute IRI
+ An absolute IRI is defined in [RFC3987] containing a scheme along with a path and + optional query and fragment segments.
+
active context
+ A context that is used to resolve terms while the processing + algorithm is running.
+
base IRI
+ The base IRI is an absolute IRI established in the context, + or is based on the JSON-LD document location. The base IRI is used to turn + relative IRIs into absolute IRIs.
+
blank node
+ A node in a graph that is neither an + IRI, nor a JSON-LD value, nor a list. + A blank node does not contain a de-referenceable + identifier because it is either ephemeral in nature or does not contain information that needs to be + linked to from outside of the linked data graph. A blank node is assigned an identifier starting with + the prefix _:.
+
blank node identifier
+ A blank node identifier is a string that can be used as an identifier for a + blank node within the scope of a JSON-LD document. Blank node identifiers + begin with _:.
+
+
context
+ A a set of rules for interpreting a JSON-LD document as specified in + The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+
+
default graph
+ The default graph is the only graph in a JSON-LD document which has no graph name. + When executing an algorithm, the graph where data should be placed + if a named graph is not specified.
+
+
default object
+ A default object is a JSON object that has a @default member.
+
edge
+ Every edge has a direction associated with it and is labeled with + an IRI or a blank node identifier. Within the JSON-LD syntax + these edge labels are called properties. Whenever possible, an + edge should be labeled with an IRI.
+
+
Frame
+ A JSON-LD document, which describes the form for transforming + another JSON-LD document using matching and embedding rules. + A frame document allows additional keywords and certain property values + to describe the matching and transforming process.
+
frame object
+ A frame object is a dictionary element within a frame + which represents a specific portion of the frame matching either a + node object or a value object in the input.
+
graph name
+ The IRI identifying a named graph.
+
+
+
+
+
IRI
+ An Internationalized Resource Identifier as described in [RFC3987].
+
JSON-LD document
+ A JSON-LD document is a serialization of a collection of + graphs and comprises exactly one + default graph and zero or more named graphs.
+
JSON-LD Processor
+ A JSON-LD Processor is a system which can perform the algorithms defined in [JSON-LD11CG-API].
+
JSON-LD value
+ A JSON-LD value is a string, a number, + true or false, a typed value, or a + language-tagged string.
+
keyword
+ A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] + in the section titled Syntax Tokens and Keywords.
+
+
language-tagged string
+ A language-tagged string consists of a string and a non-empty language + tag as defined by [BCP47]. The MUST be well-formed according to + section 2.2.9 Classes of Conformance + of [BCP47], and is normalized to lowercase.
+
+ A set of documents, each containing a representation of a linked data graph.
+
linked data graph
+ A labeled directed graph, i.e., a set of nodes + connected by edges, + as specified in the Data Model + section of the JSON-LD specification [JSON-LD11CG]. + A linked data graph is a generalized representation of an + RDF graph + as defined in [RDF-CONCEPTS].
+
list
+ A list is an ordered sequence of IRIs, + blank nodes, and JSON-LD values. + See RDF collection + in [RDF-SCHEMA].
+
+
+
+
named graph
+ A named graph is a linked data graph that is identified by an IRI or blank node.
+
+
node
+ Every node is an IRI, a blank node, + a JSON-LD value, or a list. + A piece of information that is represented in a linked data graph.
+
node object
+ A node object represents zero or more properties of a + node in the graph serialized by the + JSON-LD document. A JSON object is a node object + if it exists outside of the JSON-LD context and: +
    +
  • it does not contain the @value, @list, + or @set keywords, or
    • +
  • it is not the top-most JSON object in the JSON-LD document consisting + of no other members than @graph and @context.
    • +
+
+
node reference
+ A node object used to reference a node having only the + @id key.
+
object
+ An object is a node in a linked data graph with at least one incoming edge. + See RDF objectin [RDF11-CONCEPTS].
+
+
processing mode
+ The processing mode defines how a JSON-LD document is processed. + By default, all documents are assumed to be conformant with + JSON-LD 1.0 [JSON-LD]. By defining + a different version using the @version member in a + context, or via explicit API option, other processing modes + can be accessed. This specification defines extensions for the + json-ld-1.1 processing mode.
+
property
+ The IRI label of an edge in a linked data graph. + See RDF predicate in [RDF11-CONCEPTS].
+
+
+
+
+
relative IRI
+ A relative IRI is an IRI that is relative to some other absolute IRI, + typically the base IRI of the document. Note that + properties, values of @type, and values of terms defined to be vocabulary relative + are resolved relative to the vocabulary mapping, not the base IRI.
+
+
subject
+ A subject is anode in a linked data graph with at least one outgoing edge, related to an object node through a property. + See RDF subject in [RDF11-CONCEPTS].
+
term
+ A term is a short word defined in a context that MAY be expanded to an IRI +
+
+
+
+
typed value
+ A typed value consists of a value, which is a string, and a type, + which is an IRI.
+
value object
+ A value object is a JSON object that has an @value + member.
+
vocabulary mapping
+ The vocabulary mapping is set in the context using the @vocab key whose + value MUST be an absolute IRI null.
+
+ +
+

1.3.1 Algorithm Terms §

+ +

The Following terms are used within specific algorithms.

+ +
+
+
active property
+ The currently active property or keyword that the processor + should use when processing. The active property is represented in + the original lexical form, which is used for finding coercion mappings in + the active context.
+
+
explicit inclusion flag
+ A flag specifying that for properties to be included in the output, they + must be explicitly declared in the matching frame.
+
framing state
+ A dictionary containing values for the + object embed flag, the + require all flag, the + explicit inclusion flag, and the + omit default flag.
+
input frame
+ The initial Frame provided to the framing algorithm.
+
JSON-LD input
+ The JSON-LD data structure that is provided as input to the algorithm.
+
JSON-LD output
+ The JSON-LD data structure that is produced as output by the algorithm.
+
map of flattened subjects
+ A map of subjects that is the result of the + Node Map Generation algorithm.
+
object embed flag
+ A flag specifying that node objects should be directly embedded in the output, + instead of being referred to by their IRI.
+
omit default flag
+ A flag specifying that properties that are missing from the + JSON-LD input, but present in the input frame + should be omitted from the output.
+
omit graph flag
+ A flag that determines if framing output is always contained within a + @graph member, or only if required to represent multiple node objects.
+
+
promise
+ A promise is an object that represents the eventual result of a single asynchronous operation. + Promises are defined in [ECMASCRIPT-6.0].
+
require all flag
+ A flag specifying that all properties present in the input frame + MUST either have a default value or be present in the JSON-LD + input for the frame to match.
+
+
+ +
+ +
+

1.4 Typographical conventions §

+

The following typographic conventions are used in this specification:

+ +
+
markup
+
Markup (elements, attributes, properties), machine processable values (string, characters, media types), property name, or a file name is in red-orange monospace font.
+
variable
+
A variable in pseudo-code or in an algorithm description is in italics.
+
definition
+
A definition of a term, to be used elsewhere in this or other specifications, is in bold and italics.
+
definition reference
+
A reference to a definition in this document is underlined and is also an active link to the definition itself.
+
markup definition reference
+
A references to a definition in this document, when the reference itself is also a markup, is underlined, red-orange monospace font, and is also an active link to the definition itself.
+
external definition reference
+
A reference to a definition in another document is underlined, in italics, and is also an active link to the definition itself.
+
markup external definition reference
+
A reference to a definition in another document, when the reference itself is also a markup, is underlined, in italics red-orange monospace font, and is also an active link to the definition itself.
+
hyperlink
+
A hyperlink is underlined and in blue.
+
[reference]
+
A document reference (normative or informative) is enclosed in square brackets and links to the references section.
+
Changes from Recommendation
+
Sections or phrases changed from the previous Recommendation are highlighted.
+
+ +
Note

Notes are in light green boxes with a green left border and with a "Note" header in green. Notes are normative or informative depending on the whether they are in a normative or informative section, respectively.

+ +
Example 1
Examples are in light khaki boxes, with khaki left border, and with a
+numbered "Example" header in khaki. Examples are always informative.
+The content of the example is in monospace font and may be syntax colored.
+
+
+ +
+ +
+

2. Features §

This section is non-normative.

+
+

2.1 Framing §

This section is non-normative.

+

Framing is used to shape the data in a JSON-LD document, + using an example frame document which is used to both match the + flattened + data and show an example of how the resulting data should be shaped. + Matching is performed by using properties present in in the frame + to find objects in the data that share common values. Matching can be done + either using all properties present in the frame, or any property in the frame. + By chaining together objects using matched property values, objects can be embedded + within one another.

+ +

A frame also includes a context, which is used for compacting the resulting + framed output.

+ +

For example, assume the following JSON-LD frame:

+
Example 2: Sample library frame
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@type": "Library",
+  "contains": {
+    "@type": "Book",
+    "contains": {
+      "@type": "Chapter"
+    }
+  }
+}
+ +

This frame document describes an embedding structure that would place + objects with type ex:Library at the top, with objects of + type ex:Book that were linked to the library object using + the ex:contains property embedded as property values. It also + places objects of type ex:Chapter within the referencing ex:Book object + as embedded values of the book object.

+ +

When using a flattened set of objects that match the frame components:

+
Example 3: Flattened library objects
{
+  "@context": {
+    "@vocab": "http://example.org/",
+    "contains": {"@type": "@id"}
+  },
+  "@graph": [{
+    "@id": "http://example.org/library",
+    "@type": "Library",
+    "contains": "http://example.org/library/the-republic"
+  }, {
+    "@id": "http://example.org/library/the-republic",
+    "@type": "Book",
+    "creator": "Plato",
+    "title": "The Republic",
+    "contains": "http://example.org/library/the-republic#introduction"
+  }, {
+    "@id": "http://example.org/library/the-republic#introduction",
+    "@type": "Chapter",
+    "description": "An introductory chapter on The Republic.",
+    "title": "The Introduction"
+  }]
+}
+ +

The Frame Algorithm can create a new document which follows the structure + of the frame:

+
Example 4: Framed library objects
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@graph": [{
+    "@id": "http://example.org/library",
+    "@type": "Library",
+    "contains": {
+      "@id": "http://example.org/library/the-republic",
+      "@type": "Book",
+      "contains": {
+        "@id": "http://example.org/library/the-republic#introduction",
+        "@type": "Chapter",
+        "description": "An introductory chapter on The Republic.",
+        "title": "The Introduction"
+      },
+      "creator": "Plato",
+      "title": "The Republic"
+    }
+  }]
+}
+ +

If processing mode is json-ld-1.1, or the omit graph flag is true, + the top-level @graph member may be omitted.

+
Example 5: Framed library objects with omitGraph set to false
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@id": "http://example.org/library",
+  "@type": "Library",
+  "contains": {
+    "@id": "http://example.org/library/the-republic",
+    "@type": "Book",
+    "contains": {
+      "@id": "http://example.org/library/the-republic#introduction",
+      "@type": "Chapter",
+      "description": "An introductory chapter on The Republic.",
+      "title": "The Introduction"
+    },
+    "creator": "Plato",
+    "title": "The Republic"
+  }
+}
+ +

The Framing Algorithm does this by + first expanding both the input frame and document. It then creates + a map of flattened subjects. The outer-most node object within the frame + is used to match objects in the map, in this case looking for node objects + which have an @type of Library, and a + contains property with another + frame used to match values of that property. The input document contains + exactly one such node object. The value of contains also has + a node object, which is then treated as a frame to match the set of subjects + which are contains values of the Library object, and so forth.

+
+ +
+

2.2 Default content §

+

A frame may specify properties that don't exist in an input file. If the + explicit inclusion flag is false, the framing algorithm + will add a property and value to the result. The @default property + in a node object or value object provides a default value to use in the resulting + output document. If there is no @default value, the property will be output + with a null value. (See section 2.3.3 Omit default flag + for ways to avoid this).

+ +
Note

The value of the property in the frame is not otherwise + used in the output document. It's purpose is for frame matching and + finding default values. Note the description value for Library in the following example.

+
Example 6: Sample library frame with @default value
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@type": "Library",
+  "description": "A great Library.",
+  "contains": {
+    "@type": "Book",
+    "description": {"@default": "A great book."},
+    "contains": {
+      "@type": "Chapter"
+    }
+  }
+}
+ + +
Example 7: Sample library output with @default value
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@graph": [{
+    "@id": "http://example.org/library",
+    "@type": "Library",
+    "contains": {
+      "@id": "http://example.org/library/the-republic",
+      "@type": "Book",
+      "contains": {
+        "@id": "http://example.org/library/the-republic#introduction",
+        "@type": "Chapter",
+        "description": "An introductory chapter on The Republic.",
+        "title": "The Introduction"
+      },
+      "creator": "Plato",
+      "description": "A great book.",
+      "title": "The Republic"
+    },
+  "description": null
+  }]
+}
+ +
+ +
+

2.3 Framing Flags §

+

Framing can be controlled using API options, + or by adding framing keywords within the frame as + described in section 4.1 Syntax Tokens and Keywords.

+ +
Note

Framing flags set using keywords have effect only for the + frame in which they appear, and for implicit frames which are created + for objects where no frame object exists.

+
+

2.3.1 Object Embed Flag §

+ +

The object embed flag determines if a referenced + node object is embedded as a property value of a referencing + object, or kept as a node reference. + The initial value for the object embed flag is set using the + embed option. + Consider the following frame + based on the default @last value of the object embed flag:

+ +
Example 8: Sample library frame with implicit @embed set to @last
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@type": "Library"
+}
+ +

Because, the default for the object embed flag is @last + (in addition to the explicit inclusion flag being false), + non-listed properties are added two the output, and implicitly embedded + using a default empty frame. As a result, the same output used in the + Framed library objects above is generated.

+ +

However, if the @embed property is added explicitly with a + value of @never, the values for Book and Chapter will be excluded.

+ +
Example 9: Sample library frame with explicit @embed set to @never
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@type": "Library",
+  "contains": {
+    "@type": "Book",
+    "@embed": "@never"
+  }
+}
+ +
Example 10: Framed library objects with @embed set to @never
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@graph": [{
+    "@id": "http://example.org/library",
+    "@type": "Library",
+    "contains": {
+      "@id": "http://example.org/library/the-republic"
+    }
+  }]
+}
+
+ +
+

2.3.2 Explicit inclusion flag §

+

The explicit inclusion flag used to determine + properties which will be included in the output document. + The default value is false, which means that properties + present in an input node object that are not in the associated frame will be + included in the output object. + The initial value for the explicit inclusion flag is set using the + explicit option. + If true, only properties present in + the input frame will be placed into the output.

+ +

For example, take an expanded version of the library frame which include + some properties from the input, but omit others.

+ +
Example 11: Sample library frame with @explicit set to true
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@type": "Library",
+  "description": {},
+  "contains": {
+    "@type": "Book",
+    "@explicit": true,
+    "title": {},
+    "contains": {
+      "@type": "Chapter"
+    }
+  }
+}
+ +

The resulting output will exclude properties for Book which are not explicitly + listed in the frame object:

+ +
Example 12: Framed library objects with @explicit set to true
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@graph": [{
+    "@id": "http://example.org/library",
+    "@type": "Library",
+    "contains": {
+      "@id": "http://example.org/library/the-republic",
+      "@type": "Book",
+      "contains": {
+        "@id": "http://example.org/library/the-republic#introduction",
+        "@type": "Chapter",
+        "description": "An introductory chapter on The Republic.",
+        "title": "The Introduction"
+      },
+      "creator": "Plato",
+      "title": "The Republic"
+    }
+  }]
+}
+
+ +
+

2.3.3 Omit default flag §

+

The omit default flag changes the way framing generates output when a property + described in the frame is not present in the input document. + The initial value for the omit default flag is set using the + omitDefault option. + See section 2.2 Default content for a further discussion.

+
+ +
+

2.3.4 Omit graph flag §

+

The omit graph flag determines if framed output containing a single + node object is contained within @graph, or not. + The initial value for the omit graph flag is set using the + omitGraph option, or based on + the processing mode; if processing mode is json-ld-1.0, the output + always includes a @graph member, otherwise, the @graph member is used only + to describe multiple node objects, consistent with compaction. + See section 4.2.2 Framing Algorithm for a further discussion.

+
+ +
+

2.3.5 Require all flag §

+

The require all flag is used in frame matching to determine when a + node object from an input document matches a frame. When + matching, an object may include @type and other + properties, a match is made when any property value in the + object matches the node pattern in the frame object if + the value of the require all flag is false (the + default). If the flag value is true, then all + properties in the frame object must be present in the node + object for the node to match.

+
+
+ +
+

2.4 Reverse Framing §

+

A frame may include @reverse, or a value of a term defined using @reverse + to invert the relationships in the output object. For example, the + Library example can be inverted using the following frame:

+ +
Example 13: Inverted library frame
{
+  "@context": {
+    "@vocab": "http://example.org/",
+    "within": {"@reverse": "contains"}
+  },
+  "@type": "Chapter",
+  "within": {
+    "@type": "Book",
+    "within": {
+      "@type": "Library"
+    }
+  }
+}
+ +

Using the flattened library example above, results in the following:

+ +
Example 14: Inverted library output
{
+  "@context": {
+    "@vocab": "http://example.org/",
+    "within": {"@reverse": "contains"}
+  },
+  "@graph": [{
+    "@id": "http://example.org/library/the-republic#introduction",
+    "@type": "Chapter",
+    "description": "An introductory chapter on The Republic.",
+    "title": "The Introduction",
+    "within": {
+      "@id": "http://example.org/library/the-republic",
+      "@type": "Book",
+      "contains": {"@id": "http://example.org/library/the-republic#introduction"},
+      "creator": "Plato",
+      "title": "The Republic",
+      "within": {
+        "@id": "http://example.org/library",
+        "@type": "Library",
+        "contains": {"@id": "http://example.org/library/the-republic"}
+      }
+    }
+  }]
+}
+
+ +
+

2.5 Framing Named Graphs §

+

Frames can include @graph, which allows information from named graphs + contained within a JSON-LD document to be exposed within it's proper + graph context. By default, framing uses a merged graph, composed of all + the node objects across all graphs within the input. By using @graph + within a frame, the output document can include information specifically + from named graphs contained within the input document.

+ +

The following example uses a variation on our library theme where information + is split between the default graph, and a graph named http://example.org/graphs/books:

+ +
Example 15: Frame with named graphs
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@type": "Library",
+  "contains": {
+    "@id": "http://example.org/graphs/books",
+    "@graph": {
+      "@type": "Book"
+    }
+  }
+}
+ +
Example 16: Flattened Input with named graphs
[{
+  "@context": {"@vocab": "http://example.org/"},
+  "@id": "http://example.org/graphs/books",
+  "@graph": [{
+    "@id": "http://example.org/library/the-republic",
+    "@type": "http://example.org/Book",
+    "http://example.org/contains": {
+      "@id": "http://example.org/library/the-republic#introduction"
+    },
+    "http://example.org/creator": "Plato",
+    "http://example.org/title": "The Republic"
+  }, {
+    "@id": "http://example.org/library/the-republic#introduction",
+    "@type": "http://example.org/Chapter",
+    "http://example.org/description": "An introductory chapter on The Republic.",
+    "http://example.org/title": "The Introduction"
+  }]
+}, {
+  "@context": {"@vocab": "http://example.org/"},
+  "@id": "http://example.org/library",
+  "@type": "http://example.org/Library",
+  "http://example.org/contains": {"@id": "http://example.org/graphs/books"},
+  "http://example.org/name": "Library"
+}]
+ +
Example 17: Framed output with named graphs
{
+  "@context": {"@vocab": "http://example.org/"},
+  "@graph": [{
+    "@id": "http://example.org/library",
+    "@type": "Library",
+    "name": "Library",
+    "contains": {
+      "@id": "http://example.org/graphs/books",
+      "@graph": [{
+        "@id": "http://example.org/library/the-republic",
+        "@type": "Book",
+        "creator": "Plato",
+        "title": "The Republic",
+        "contains": {
+          "@id": "http://example.org/library/the-republic#introduction",
+          "@type": "Chapter",
+          "description": "An introductory chapter on The Republic.",
+          "title": "The Introduction"
+        }
+      }]
+    }
+  }]
+}
+ +
+
+ +

3. Conformance §

+ As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, + and notes in this specification are non-normative. Everything else in this specification is + normative. +

The key words MAY, MUST, MUST NOT, RECOMMENDED, and SHOULD NOT are + to be interpreted as described in [RFC2119]. +

+

There is one class of products that can claim conformance to this + specification: JSON-LD Processors.

+ +

A conforming JSON-LD Processor is a system which can perform the + Framing operation in a manner consistent with + the algorithms defined in this specification.

+ +

JSON-LD Processors MUST NOT + attempt to correct malformed IRIs or language tags; + however, they MAY issue validation warnings. IRIs are not modified other + than conversion between relative and + absolute IRIs.

+ +

The algorithms in this specification are generally written with more concern for clarity + than efficiency. Thus, JSON-LD Processors MAY + implement the algorithms given in this specification in any way desired, + so long as the end result is indistinguishable from the result that would + be obtained by the specification's algorithms.

+ +

In algorithm steps that describe operations on keywords, those steps + also apply to keyword aliases.

+ +
Note

Implementers can partially check their level of conformance to + this specification by successfully passing the test cases of the JSON-LD test + suite [JSON-LD-TESTS]. Note, however, that passing all the tests in the test + suite does not imply complete conformance to this specification. It only implies + that the implementation conforms to aspects tested by the test suite.

+
+ +
+

4. Framing Algorithms §

+ +

All algorithms described in this section are intended to operate on + language-native data structures. That is, the serialization to a text-based + JSON document isn't required as input or output to any of these algorithms.

+ +

Reference to JSON data structures are interpreted using their internal representation for the purpose + of describing algorithms.

+ +
+

4.1 Syntax Tokens and Keywords §

+ +

This specification adds a number of keywords (framing keywords) to + the ones defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG]:

+ +
@default
+
Used in Framing to set the default value for + an output property when the framed node object does not include such a property.
+
@embed
+
Used in Framing to override the + value of object embed flag within a specific frame. Valid values for + @embed as the following: +
+
@always
+ Always embed node objects as property values, unless this would + cause a circular reference. +
+
@last
+ Only the last value within a given node object should be embedded, + previous values of other properties use a node reference. This is the + default value if neither @embed nor object embed flag + is not specified. +
+
@never
+ Always use a node reference when serializing matching values. +
+
true
(equivalent to @last).
+
false
(equivalent to @never).
+
+

Any other value for @embed is invalid and indicates that an + invalid @embed value + error has been detected and processing is aborted.

+
+
@explicit
+
Used in Framing to override the + value of explicit inclusion flag within a specific frame.
+
@null
+
Used in Framing when a value of null + should be returned, which would otherwise be removed when + Compacting.
+
@omitDefault
+
Used in Framing to override the + value of omit default flag within a specific frame. +
Issue
Is this flag really useful? Easier to simply not have a default value, + if it shouldn't match.
+
+
@requireAll
+
Used in Framing to override the + value of require all flag within a specific frame.
+ +

All JSON-LD tokens and keywords are case-sensitive.

+
+ +
+

4.2 Framing §

+

Framing is the process of taking a JSON-LD document, which expresses a + graph of information, and applying a specific graph layout + (called a Frame).

+ +

Framing makes use of the Node Map Generation algorithm + to place each object defined in the JSON-LD document into a map of flattened subjects, allowing + them to be operated upon by the Framing algorithm.

+ +
+

4.2.1 Framing Requirements §

+

A valid JSON-LD Frame is a superset of a valid JSON-LD document, + allowing additional content, which is preserved through expansion. + The Grammar defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG] + is extended as follows:

+
    +
  • Framing adds framing keywords which may be used as keys of a node object, which MUST be preserved when expanding. +
  • Values of keys in a frame object that are not keyword MAY also include a default object. + Values of @default MAY include the value @null, + or an array containing only @null, in addition to other values + allowed in the grammar for values of keys expanding to absolute IRIs. + Processors MUST preserve this value when expanding. All other key/value pairs of + a default object MUST be ignored.
    • +
  • The values of @id and @type may also be an empty dictionary, or an array + containing only an empty dictionary. + Processors MUST preserve this value when expanding.
    • +
  • Framing either operates on the merged node definitions contained in + the input document, or on the default graph depending on if the + input frame contains the @graph key at the top level. + Nodes with a subject that is also a named graph, where + the frame object contains @graph, extend framing + to node objects from the associated named graph.
    • +
+
+ +
+

4.2.2 Framing Algorithm §

+ +

The framing algorithm takes an JSON-LD input (expanded input), + which MUST be a JSON-LD document in + expanded form, + an input frame (expanded frame), + which MUST be a JSON-LD frame in + expanded form, + a context (context), + and a number of options and produces JSON-LD output.

+ +

If an error is detected in the expanded frame, a invalid frame + error has been detected and processing is aborted. + Need more specifics as to what constitutes a valid frame.

+ +

Set graph map to the result of performing the + Node Map Generation algorithm on + expanded input.

+ +

If the frameDefault option + is present with the value true, set graph name to @default. + Otherwise, create merged node map using the Merge Node Maps algorithm + with graph map and add merged node map as the value of @merged + in graph map and set graph name to @merged.

+ +

The recursive algorithm operates with a framing state (state), + created initially using + the object embed flag set to true, + the explicit inclusion flag set to false, + the require all flag set to true, + the omit default flag set to false, + graph map, graph name, + along with map of flattened subjects + set to the property associated with graph name in graph map, and + graph stack set to an empty array. The initial values of the + object embed flag, require all flag, and omit default flag + MUST be overridden by values set in options. + Also initialize results as an empty array.

+ +
Note

Processors MAY use other runtime options to set different framing state defaults + for values of state.

+ +

Invoke the recursive algorithm using framing state (state), + the keys from the map of flattened subjects as subjects, + expanded frame (frame), result as parent, and + null as active property.

+ +

The recursive algorithm adds elements to parent either by appending + the element to parent, if it is an array, or by appending it + to an array associated with active property in parent, if it is a dictionary. + Note that if parent is an array, active property MUST be null, + and if it is a dictionary, it MUST NOT be null.

+ +

The following series of steps is the recursive + portion of the framing algorithm:

+ +
    +
  1. If frame is an array, set frame to the first member of the array, which MUST be a valid frame.
    2. +
  2. Initialize flags embed, explicit, and requireAll from + object embed flag, explicit inclusion flag, and + require all flag in state overriding from any property values + for @embed, @explicit, and @requireAll in frame.
    3. +
  3. Create a list of matched subjects by filtering subjects against frame + using the Frame Matching algorithm + with state, subjects, frame, and requireAll.
    4. +
  4. For each id and associated node object node + from the set of matched subjects, ordered by id: +
    Editor's note

    Can we remove sorting, or make it subject to a processing + flag? In general, sorting is a performance problem for JSON-LD, and + inhibits stream processing.

    +
      +
    1. Initialize output to a new dictionary with @id and id.
      2. +
    2. Otherwise, if embed is @never or if a + circular reference would be created by an embed, + add output to parent + and do not perform additional processing for this node.
      3. +
    3. Otherwise, if embed is @last, + remove any existing embedded node from parent associate with + graph name in state. + Requires sorting of subjects. We could consider @sample, to embed + just the first matched node. With sorting, we could also consider @first.
      4. +
    4. If embed is @last or @always +
        +
      1. If graph map in state has an entry for id: +
          +
        1. If frame does not have the key @graph, + set recurse to true, unless graph name in state is @merged + and set subframe to a new empty dictionary.
          2. +
        2. Otherwise, set subframe to the first entry for @graph in frame, + or a new empty dictionary, if it does not exist, and + set recurse to true, unless id + is @merged or @default.
          3. +
        3. If recurse is true: +
            +
          1. Push graph name from state onto graph stack + in state.
            2. +
          2. Set the value of graph name in state to id.
            3. +
          3. Invoke the recursive algorithm using state, + the keys from the graph map in state associated with id as subjects, + subframe as frame, + output as parent, and @graph as active property. +
          4. Pop the value from graph stack in state and set graph name in state + back to that value.
            5. +
          +
          4. +
        +
        2. +
      2. For each property and objects in node, ordered by property: +
          +
        1. If property is a keyword, add property and objects + to output.
          2. +
        2. Otherwise, if property is not in frame, and explicit is true, + processors MUST NOT add any values for property to output, and the following + steps are skipped.
          3. +
        3. For each item in objects: +
            +
          1. If item is a dictionary with the property @list, then each + listitem in the list is processed in sequence and added to a new list dictionary + in output: +
              +
            1. If listitem is a node reference, + invoke the recursive algorithm using state, + the value of @id from listitem + as the sole member of a new subjects array, + the first value from @list in frame as frame, + list as parent, and @list as active property. + If frame does not exist, create a new frame using a new dictionary + with properties for @embed, @explicit and @requireAll + taken from embed, explicit and requireAll. + Could this use the list array, and null for active property?
              2. +
            2. Otherwise, append a copy of listitem to @list in list.
              3. +
            +
            2. +
          2. If item is a node reference, + invoke the recursive algorithm using state, + the value of @id from item + as the sole member of a new subjects array, + the first value from property in frame as frame, + output as parent, and property as active property. + If frame does not exist, create a new frame using a new dictionary + with properties for @embed, @explicit and @requireAll + taken from embed, explicit and requireAll.
            3. +
          3. Otherwise, append a copy of item to active property in + output.
            4. +
          +
          4. +
        +
        3. + +
      3. For each non-keyword property and objects in frame that is not in output: +
          +
        1. Let item be the first element in objects, which MUST be a frame object.
          2. +
        2. Set property frame to the first item in objects or a newly created frame object if value is objects. + property frame MUST be a dictionary.
          3. +
        3. Skip property and property frame if property frame contains + @omitDefault with a value of true, + or does not contain @omitDefault and the value of + the omit default flag is true.
          4. +
        4. Add property to output with a + new dictionary having a property @preserve and + a value that is a copy of the value of @default in + frame if it exists, or the string @null + otherwise.
          5. +
        +
        4. + +
      4. If frame has the property @reverse, then + for each reverse property and sub frame that are the values of @reverse in frame: +
          +
        1. Create a @reverse property in output with a new dictionary reverse dict as its value.
          2. +
        2. For each reverse id and node in the map of flattened subjects that has the property + reverse property containing a node reference with an @id of id: +
            +
          1. Add reverse property to reverse dict with a new empty array as its value.
            2. +
          2. Invoke the recursive algorithm using state, + the reverse id + as the sole member of a new subjects array, + sub frame as frame, + null as active property, + and the array value of reverse property in reverse dict as parent.
            3. +
          +
          3. +
        +
        5. + +
      5. Once output has been set are required in the previous steps, + add output to parent.
        6. +
      +
      5. +
    +
    5. +
+ +

If the processing mode is json-ld-1.1, + remove the @id member of each node object where the + member value is a blank node identifier which appears only once + in any property value within result.

+

Using result from the recursive algorithm, set compacted results to the result of using the + compact + method using results, context, and + options.

+

If the omit graph flag is false and + compacted results does not have a top-level @graph member, or its value is + not an array, modify compacted results to place the non @context properties + of compacted results into a dictionary contained within the array value of + @graph. If the omit graph flag is true, a + top-level @graph member is used only to contain multiple node objects.

+

Recursively, replace all key-value pairs in compacted results + where the key is @preserve with the value from the key-pair. + If the value from the key-pair is @null, replace the value with null. + If, after replacement, an array contains a single array value, replace the array with that value. + If, after replacement, an array contains only the value null remove the value, leaving + an empty array.

+

Return compacted results.

+ +
+ +
+

4.2.3 Frame Matching Algorithm §

+ +

The Frame Matching Algorithm is used as part of the Framing algorithm + to determine if a particular node object matches the criteria set in a frame. + In general, a node object matches a frame if it meets the matches on @type, + or @id, + or if it matches given one of several different properties (or all properties, if the + require all flag is present.).

+ +
Note

As matching is performed on expanded node objects, all values will be in the form of an array.

+ +

Node matching uses a combination of JSON constructs to match any, zero, or some specific values:

+
[] (match none)
+
An empty array matches no values, or a value which is, itself, an empty array.
+
[frame object] (node pattern)
+
A non-empty frame object, used to match specific values using recursive node matching.
+
[IRI+]
+
One or more strings in the form of an IRI, used for matching on @type and @id, + which allows a match on any of the listed IRIs.
+
[value object] (value pattern)
+
A value object, used to match a specific value. Within a value object, + the values for @value, @type, and @language + may also be an array of one or more string values.
{} (wildcard)
+
An array containing an empty object + (after excluding any properties which are framing keywords) + matches any value that is present, and does not match if there are no values.
+
+ +

The frame matching algorithm takes the framing state (state), + a list of subjects to match from the map of flattened subjects (subjects), + a frame to match against (frame), and the requireAll flag + and returns a list of matched subjects by filtering each node in subjects as follows:

+ +

Frame matching follows an order of precedence, first attempting to match on a particular @id, then + a particular @type (or lack of @type), then by matching on any or all + of a set of properties, if neither @id, nor @type are in the frame.

+ +
    +
  1. node matches if it has an @id property value + which is also a value of the @id property in frame. + Otherwise, node does not match if frame has a non-empty + @id property, other than an empty dictionary. + Otherwise, frame must not have a @id property; continue to the next step. +
    Note
    Framing works on map of flattened subjects, + and the act of flattening ensures that all subjects have an + @id property; thus the "@id": [] pattern would + never match any node object. the "@id": [{}] pattern would + match any node object and is equivalent to not specifying a + @id property in frame at all
    +
    2. +
  2. node matches if frame has no non-keyword properties.
    3. +
  3. If requireAll is true, node matches if all non-keyword properties (property) in frame match any of the following conditions. + Or, if requireAll is false, if any of the non-keyword properties (property) in frame match any of the following conditions. + For the values of each property from frame in node: +
      +
    1. If property is @type: +
        +
      1. property matches if the @type property in frame includes any IRI in values.
        2. +
      2. Otherwise, property matches if values is not empty and the @type property in frame is wildcard.
        3. +
      3. Otherwise, property matches if values is empty and the @type property in frame is match none.
        4. +
      4. Otherwise, property does not match.
        5. +
      +
      2. +
    2. Otherwise, the value of property in frame MUST be empty, or an array + containing a valid frame.
      3. +
    3. property matches if values is empty, or non existent, + the value of property in frame + is a dictionary containing only the key @default with any value, + and any other property in node has a non-default match.
      4. +
    4. node does not match if values is not empty and the value of property in frame is match none, and further matching is aborted.
      5. +
    5. Otherwise, property matches if values is not empty and the value of property in frame is wildcard.
      6. +
    6. Otherwise, if the value of property in frame is a value pattern (value pattern): + property matching is determined using the Value matching algorithm.
      7. +
    7. Otherwise, for any node pattern (node pattern) which is one of the values of property in frame: +
        +
      1. Let value subjects be the list of subjects from the map of flattened subjects matching the node object values from values.
        2. +
      2. Let matched subjects be the result of calling this algorithm recursively using + state, value subjects for subjects, node pattern for frame, and the requireAll flag.
        3. +
      3. property matches if matched subjects is not empty.
        4. +
      +
      8. +
    8. Otherwise, property does not match.
      9. +
    +
    4. +
+
+ +
+

4.2.4 Value Pattern Matching Algorithm §

+ +

The Value Pattern Matching Algorithm is used as part of the Framing + and Frame Matching algorithms. A value object + matches a value pattern using the match none and wildcard + patterns on @value, @type, and + @language, in addition to allowing a specific value to match a + set of values defined using the array form for each value + object property.

+ +

The algorithm takes a value pattern (pattern) and value object (value) as parameters. + Value matches pattern using the following algorithm:

+ +
    +
  1. Let v1, t1, and l1 be the values of @value, @type, and @language in value, or null if none exists.
    2. +
  2. Let v2, t2, and l2 be the values of @value, @type, and @language in value pattern, or null if none exists.
    3. +
  3. Value matches pattern when pattern is wildcard, or: +
      +
    1. v1 is in v2, or v1 is not null and v2 is wildcard, and
      2. +
    2. t1 is in t2, or t1 is not null and t2 is wildcard, or null, or t1 is null and t2 is null or match none, and
      3. +
    3. l1 is in l2, or l1 is not null and l2 is wildcard, or null, or l1 is null and l2 is null or match none.
      4. +
    +
    4. +
+
+ +
+
+ +
+

5. The Application Programming Interface §

+ +

This API provides a clean mechanism that enables developers to convert + JSON-LD data into a variety of output formats that are easier to work with in + various programming languages. If a JSON-LD API is provided in a programming + environment, the entirety of the following API MUST be implemented. +

+ +
+

5.1 JsonLdProcessor §

+ +

The JSON-LD Processor interface is the high-level programming structure that developers + use to access the JSON-LD transformation methods. The definition below is an experimental + extension of the interface defined in the JSON-LD 1.1 API [JSON-LD11CG-API].

+ + 
[Constructor]
+interface JsonLdProcessor {
+    static Promise<JsonLdDictionary> frame(JsonLdInput input,
+                                           (JsonLdDictionary or USVString) frame,
+                                           optional JsonLdOptions? options);
+};
+

The JsonLdProcessor interface + frame method + Frames + the given input using frame + according to the steps in the Framing + Algorithm:

+
    +
  1. Create a new Promise promise and return it. The + following steps are then executed asynchronously.
    2. +
  2. Set expanded input to the result of using the + expand + method using input and options. +
  3. Set expanded frame to the result of using the + expand + method using + frame and + options with + expandContext set to null + and the frameExpansion option set to true. +
  4. Set context to the value of @context + from frame, if it exists, or to + a new empty context, otherwise.
    5. +
  5. Initialize an active context using context; + the base IRI is set to + the base option from + options, if set; + otherwise, if the + compactToRelative option is + true, to the IRI of the currently being processed + document, if available; otherwise to null.
    6. +
  6. If frame has a top-level + property which expands to @graph set the frameDefault + option to options with the + value true.
    7. +
  7. Set framed to the result of using the + Framing algorithm, passing + expanded input, expanded frame, active context, and options.
    8. +
  8. Fulfill the promise passing framed.
    9. +
+ +
+
input
+
The JSON-LD object or array of JSON-LD objects to perform the framing upon or an + IRI referencing the JSON-LD document to frame.
+
frame
+
The frame to use when re-arranging the data of input; either + in the form of an dictionary or as IRI.
+
options
+
A set of options that MAY affect the framing algorithm such as, e.g., the + input document's base IRI.
+
+ +
+ +
+

5.2 Error Handling §

+

The JsonLdFramingError type is used to report processing errors.

+ + 
dictionary JsonLdFramingError {
+    JsonLdFramingErrorCode code;
+    USVString?             message = null;
+};
+
+enum JsonLdFramingErrorCode {
+    "invalid frame",
+    "invalid @embed value"
+};
+

JSON-LD Framing extends the error interface and codes defined in + the JSON-LD 1.1 API [JSON-LD11CG-API]. + +

+
code
+
a string representing the particular error type, as described in + the various algorithms in this document.
+
message
+
an optional error message containing additional debugging information. + The specific contents of error messages are outside the scope of this + specification.
+
+ +

The JsonLdFramingErrorCode represents the collection of valid JSON-LD Framing error + codes.

+
invalid @embed value
+ The value for @embed is not one recognized for the object embed flag. +
invalid frame
+ The frame is invalid. +
+
+
+ +
+

5.3 Data Structures §

+

This section describes datatype definitions used within the JSON-LD API.

+ +
+

5.3.1 JsonLdContext §

+

The JsonLdContext type is used to refer to a value that + that may be a dictionary, a string representing an + IRI, or an array of dictionaries + and strings.

+ +

See JsonLdContext definition in the JSON-LD 1.1 API [JSON-LD11CG-API].

+
+ +
+

5.3.2 JsonLdOptions §

+

The JsonLdOptions type is used to pass various options to the + JsonLdProcessor methods.

+ + 
dictionary JsonLdOptions {
+    (JsonLdEmbed or boolean) embed = "@last";
+    boolean                  explicit = false;
+    boolean                  omitDefault = false;
+    boolean                  omitGraph;
+    boolean                  requireAll = false;
+    boolean                  frameDefault = false;
+};
+
+enum JsonLdEmbed {
+    "@always",
+    "@last",
+    "@never"
+};
+ +

In addition to those options defined in the JSON-LD 1.1 API [JSON-LD11CG-API], framing defines these + additional options:

+ +
embed
+
Sets the value object embed flag used in the + Framing Algorithm. + A boolean value of true sets the flag to + @last, while an value of false sets the flag + to @never.
+
explicit
+
Sets the value explicit inclusion flag used in the + Framing Algorithm. +
+
frameDefault
+
Instead of framing a merged graph, frame only the default graph.
omitDefault
+
Sets the value omit default flag used in the + Framing Algorithm
+
omitGraph
+
Sets the value omit graph flag used in the + Framing Algorithm. If not set explicitly, + it is set to false if processing mode if json-ld-1.0, true otherwise.
+
requireAll
+
Sets the value require all flag used in the + Framing Algorithm.
+
+ +

JsonLdEmbed enumerates the values of the embed option:

+
@always
+ Always embed node objects as property values, unless this would + cause a circular reference.
+
@last
+ Only the last value within a given node object should be embedded, + previous values of other properties use a node reference. This is the + default value if neither @embed nor object embed flag + is not specified.
+
@never
+ Always use a node reference when serializing matching values.
+ +

See JsonLdOptions definition in the JSON-LD 1.1 API [JSON-LD11CG-API].

+
+
+ +
+ +
+

A. IANA Considerations §

This section is non-normative.

+ +

This section is included merely for standards community review and will be +submitted to the Internet Engineering Steering Group if this specification +becomes a W3C Recommendation.

+ +

application/ld-frame+json §

+
+
Type name:
+
application
+
Subtype name:
+
ld-frame+json
+
Required parameters:
+
None
+
Optional parameters:
+
None
+
Encoding considerations:
+
The same as the application/json MIME media type.
+
Security considerations:
+
Since a JSON-LD frame is intended to specify a deterministic layout + for a JSON-LD graph, the serialization SHOULD NOT be passed through a + code execution mechanism such as JavaScript's eval() + function. It is RECOMMENDED that a conforming parser does not attempt to + directly evaluate the JSON-LD frame and instead purely parse the + input into a language-native data structure.
+
Interoperability considerations:
+
Not Applicable
+
Published specification:
+
The JSON-LD specification.
+
Applications that use this media type:
+
Any programming environment that requires the exchange of + directed graphs. Implementations of JSON-LD have been created for + JavaScript, Python, Ruby, PHP and C++. +
+
Additional information:
+
+
+
Magic number(s):
+
Not Applicable
+
File extension(s):
+
.jsonldf
+
Macintosh file type code(s):
+
TEXT
+
+
+
Person & email address to contact for further information:
+
Manu Sporny <msporny@digitalbazaar.com>
+
Intended usage:
+
Common
+
Restrictions on usage:
+
None
+
Author(s):
+
Manu Sporny, Gregg Kellogg, Markus Lanthaler, Dave Longley
+
Change controller:
+
W3C
+
+ +

Fragment identifiers have no meaning with + application/frame-ld+json resources.

+ +
+ +
+

B. Security Considerations §

+
Editor's note

Consider requirements from Self-Review Questionnaire: Security and Privacy.

+

See, section A. IANA Considerations

+
+ +

C. IDL Index §

This section is non-normative.

+
[Constructor]
+interface JsonLdProcessor {
+    static Promise<JsonLdDictionary> frame(JsonLdInput input,
+                                           (JsonLdDictionary or USVString) frame,
+                                           optional JsonLdOptions? options);
+};
+dictionary JsonLdFramingError {
+    JsonLdFramingErrorCode code;
+    USVString?             message = null;
+};
+enum JsonLdFramingErrorCode {
+    "invalid frame",
+    "invalid @embed value"
+};
+dictionary JsonLdOptions {
+    (JsonLdEmbed or boolean) embed = "@last";
+    boolean                  explicit = false;
+    boolean                  omitDefault = false;
+    boolean                  omitGraph;
+    boolean                  requireAll = false;
+    boolean                  frameDefault = false;
+};
+enum JsonLdEmbed {
+    "@always",
+    "@last",
+    "@never"
+};
+
+ +
+

D. Changes since 1.0 Draft of 30 August 2012 §

This section is non-normative.

+ +
+ +
+

E. Open Issues §

This section is non-normative.

+

The following is a list of issues open at the time of publication.

+
Issue 542: Feature request: Could framing return properties in the order listed by the frame? apideferframing

Currently it appears that properties are sorted into alphabetical order after any JSON-LD operation (compaction, framing).

+

In the context of framing, this is sometimes a nice feature, since it means that after framing multiple input JSON files, the JSON data is at least in a consistent order.

+

I understand that ordering is semantically meaningless, but as framing exists to turn the graph (which could correspond to multiple different trees) into a predictable JSON tree as a convenience for developers, it seems natural to me that if an explicit ordering is given in the frame, that the algorithm would respect that order rather than alphabetize. For example, if my data is:

+
{
+  "@context": "http://schema.org/",
+  "@id": "document",
+  "b": "text",
+  "a": "more text"
+ 
+}
+
+

Under the frame:

+
{
+  "@context": "http://schema.org/",
+  "@id":  "document",
+  "b": {},
+  "a": {}
+}
+
+

(example in playground)

+

the returned document reverses the order of b and a (to be alphabetical), and not the order given in the frame. Framing is a really elegant way to specify the nesting order, but it would be nice for framing to also be able to dictate the ordering, so that the output data file really follows the exact structure of the given frame.

+

Related issue: there is no way to indicate that referenced nodes should occur before they are references (excluding circular references), which can be useful in streaming files. Having control of the node order via the frame would also give a mechanism to address that.

+

Hope this makes sense and apologies if I'm missing something fundamental here that makes alphabetizing the node order the only logical thing to do; or if I've misunderstood the expected behavior.

+
Issue 550: Framing document does not render correct in Safariframingspec-editorial

The CSS/JS does not render in safari, with the error:
+Cannot declare a const variable twice: 'e'.

+
Issue 579: Frame Matching & Blank Nodesframingspec-design

The current draft for JSON-LD framing (January 2018) does not mention blank nodes in the frame matching algorithm specification and a strict interpretation of the first test goes a bit against the semantics of RDF in case a frame includes blank nodes:

+
+

1 Node matches if it has an @id property value which is also a value of the @id property in frame.

+
+

According to its definition, a frame is a JSON-LD document, meaning it can include blank nodes. if it happens, blank nodes in the frame will match blank nodes in a document only if they have the same ID and I believe that the Ruby implementation performs simple string comparison.

+

In RDF, shared blank nodes require a special handling and we loose that specificity here. It would be good to either redefine JSON-LD frames such that blank nodes are not allowed or precise the specification of frame matching. I would be in favor of the latter approach.

+

Blank nodes in JSON-LD frames might be useful when nodes have multiple relations to each other. For instance, nodes matching the following frame represent all alumni of a university who still work for that university:

+
{
+  "@context": "http://schema.org",
+  "@type": "Person",
+  "alumniOf": {
+    "@id": "_:univ",
+    "@type": "CollegeOrUniversity"
+  },
+  "worksFor": { "@id": "_:univ" }
+}
+
Issue 588: Framing and @reverseframingquestion

Further to #311, should the predicate that triggered the use of an @reverse property in a frame be removed from its resource to avoid a necessarily circular reference?

+

For example, if the data shape is:

+

X includes Y
+Z is Y
+Z in X

+

And there's a @reverse of "in" called "proxies" which is then @embed always via a Frame, should the Z resources also have in back to X?

+

I would have expected:

+
{
+  "id": "X",
+  "includes":  ["Y"],
+  "uses": [{"id": "Z", "is": "Y"}]
+}
+
+

But instead the in property is still present in Z.

+

Use Case: http://openarchives.org/ore/0.9/jsonld#proxies

+
+ +
+

F. Acknowledgements §

This section is non-normative.

+ +

A large amount of thanks goes out to the JSON-LD Community Group +participants who worked through many of the technical issues on the mailing +list and the weekly telecons - of special mention are Niklas Lindström, +François Daoust, and Zdenko 'Denny' Vrandečić. +The editors would like to thank Mark Birbeck, who provided a great deal of +the initial push behind the JSON-LD work via his work on RDFj. +The work of Dave Lehn and Mike Johnson are appreciated for reviewing, +and performing several implementations of the specification. Ian Davis is +thanked for this work on RDF/JSON. Thanks also to Nathan Rixham, +Bradley P. Allen, +Kingsley Idehen, Glenn McDonald, Alexandre Passant, Danny Ayers, Ted +Thibodeau Jr., Olivier Grisel, Josh Mandel, Eric Prud'hommeaux, +David Wood, Guus Schreiber, Pat Hayes, Sandro Hawke, and Richard +Cyganiak for their input on the specification. +

+ + + +

G. References §

G.1 Normative references §

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47 +
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ +
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld/ +
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-api/ +
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/ +
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 +
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987 +
[RFC7159]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7159 +
[WEBIDL]
Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/ +

G.2 Informative references §

[ECMASCRIPT-6.0]
ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html +
[JSON-LD-TESTS]
JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ +
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-framing/ +
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/ +
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ +
\ No newline at end of file diff --git a/spec/CG-FINAL/json-ld/20180507/index.html b/spec/CG-FINAL/json-ld/20180507/index.html new file mode 100644 index 000000000..373d1d92f --- /dev/null +++ b/spec/CG-FINAL/json-ld/20180507/index.html @@ -0,0 +1,6441 @@ + +JSON-LD 1.1 + + + + + + + +
+ +

JSON-LD 1.1

+

A JSON-based Serialization for Linked Data

+

Final Community Group Report

+
+ + +
Latest editor's draft:
https://json-ld.org/spec/latest/json-ld/
+ + + +
Previous version:
https://www.w3.org/TR/2014/REC-json-ld-20140116/
+ +
Editor:
+
Gregg Kellogg (Spec-Ops) (v1.0 and v1.1)
+
Former editors:
Manu Sporny (Digital Bazaar) (v1.0)
Markus Lanthaler (Graz University of Technology) (v1.0)
+
Authors:
Manu Sporny (Digital Bazaar) (v1.0)
Dave Longley (Digital Bazaar) (v1.0)
Gregg Kellogg (Spec-Ops) (v1.0 and v1.1)
Markus Lanthaler (Graz University of Technology) (v1.0)
Niklas Lindström (v1.0)
+
Participate:
+ GitHub json-ld/json-ld.org +
+ File a bug +
+ Commit history +
+ Pull requests +
+
+ +

+ Copyright © + 2010-2018 + the Contributors to the JSON-LD 1.1 Specification, published by the + JSON for Linking Data W3C Community Group under the + W3C Community Final Specification Agreement (FSA). + A human-readable summary is available. + +

+
+
+

Abstract

+

JSON is a useful data serialization and messaging format. + This specification defines JSON-LD, a JSON-based format to serialize + Linked Data. The syntax is designed to easily integrate into deployed + systems that already use JSON, and provides a smooth upgrade path from + JSON to JSON-LD. + It is primarily intended to be a way to use Linked Data in Web-based + programming environments, to build interoperable Web services, and to + store Linked Data in JSON-based storage engines.

+
+ +

Status of This Document

+ This specification was published by the JSON for Linking Data W3C Community Group. + It is not a W3C Standard nor is it on the W3C Standards Track. + + Please note that under the + W3C Community Final Specification Agreement (FSA) + other conditions apply. + + Learn more about + W3C Community and Business Groups. +

This document has been developed by the + JSON for Linking Data W3C Community Group + as an update to the 1.0 recommendation [JSON-LD] developed + by the RDF Working Group. + The specification has undergone + significant development, review, and changes during the course of several years.

There are several independent + interoperable implementations of + this specification, a test suite [JSON-LD-TESTS] and a + live JSON-LD playground that is capable + of demonstrating the features described in this document.

If you wish to make comments regarding this document, please send them to + public-linked-json@w3.org + (subscribe, + archives).

+

Set of Documents

+

This document is one of three JSON-LD 1.1 Recommendations produced by the + JSON for Linking Data W3C Community Group:

+ + +
+ +
+

1. Introduction §

This section is non-normative.

+ +

Linked Data [LINKED-DATA] is a way to create a network of + standards-based machine interpretable data across different documents and + Web sites. It allows an application to start at one piece of Linked Data, + and follow embedded links to other pieces of Linked Data that are hosted on + different sites across the Web.

+ +

JSON-LD is a lightweight syntax to serialize Linked Data in + JSON [RFC7159]. Its design allows existing JSON to be interpreted as + Linked Data with minimal changes. JSON-LD is primarily intended to be a + way to use Linked Data in Web-based programming environments, to build + interoperable Web services, and to store Linked Data in JSON-based storage engines. Since + JSON-LD is 100% compatible with JSON, the large number of JSON parsers and libraries + available today can be reused. In addition to all the features JSON provides, + JSON-LD introduces:

+ + + +

+ JSON-LD is designed to be usable directly as JSON, with no knowledge of RDF + [RDF11-CONCEPTS]. It is also designed to be usable as RDF, if desired, for + use with other Linked Data technologies like SPARQL. Developers who + require any of the facilities listed above or need to serialize an RDF Graph + or RDF Dataset in a JSON-based syntax will find JSON-LD of interest. People + intending to use JSON-LD with RDF tools will find it can be used as another + RDF syntax, like Turtle [TURTLE]. Complete details of how JSON-LD relates + to RDF are in section 7. Relationship to RDF. +

+ +

+ The syntax is designed to not disturb already + deployed systems running on JSON, but provide a smooth upgrade path from + JSON to JSON-LD. Since the shape of such data varies wildly, JSON-LD + features mechanisms to reshape documents into a deterministic structure + which simplifies their processing.

+ +
+

1.1 How to Read this Document §

This section is non-normative.

+ +

This document is a detailed specification for a serialization of Linked + Data in JSON. The document is primarily intended for the following audiences:

+ +
    +
  • Software developers who want to encode Linked Data in a variety of + programming languages that can use JSON
    • +
  • Software developers who want to convert existing JSON to JSON-LD
    • +
  • Software developers who want to understand the design decisions and + language syntax for JSON-LD
    • +
  • Software developers who want to implement processors and APIs for + JSON-LD
    • +
  • Software developers who want to generate or consume Linked Data, + an RDF graph, or an RDF Dataset in a JSON syntax
    • +
+ +

A companion document, the JSON-LD 1.1 Processing Algorithms and API specification + [JSON-LD11CG-API], specifies how to work with JSON-LD at a higher level by + providing a standard library interface for common JSON-LD operations.

+ +

To understand the basics in this specification you must first be familiar with + JSON, which is detailed in [RFC7159].

+ +

This document almost exclusively uses the term IRI + (Internationalized Resource Indicator) + when discussing hyperlinks. Many Web developers are more familiar with the + URL (Uniform Resource Locator) + terminology. The document also uses, albeit rarely, the URI + (Uniform Resource Indicator) + terminology. While these terms are often used interchangeably among + technical communities, they do have important distinctions from one + another and the specification goes to great lengths to try and use the + proper terminology at all times. +

+
+ +
+

1.2 Contributing §

+ +

There are a number of ways that one may participate in the development of + this specification:

+ +
    +
  • Technical discussion typically occurs on the public mailing list: + public-linked-json@w3.org
    • + + + +
  • The #json-ld + IRC channel is available for real-time discussion on irc.freenode.net.
    • +
+ +
+ +
+

1.3 Terminology §

+ +

This document uses the following terms as defined in JSON [RFC7159]. Refer + to the JSON Grammar section in [RFC7159] for formal definitions.

+ +
array
+ In the JSON serialization, an array structure is represented as square brackets surrounding zero + or more values. Values are separated by commas. + In the internal representation, an array is an ordered collection of zero or more values. + While JSON-LD uses the same array representation as JSON, + the collection is unordered by default. While order is + preserved in regular JSON arrays, it is not in regular JSON-LD arrays + unless specifically defined (see + Sets and Lists in + the JSON-LD Syntax specification [JSON-LD11CG]).
+
JSON object
+ In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or + more key-value pairs. A key is a string. A single colon comes after + each key, separating the key from the value. A single comma separates a value + from a following key. In JSON-LD the keys in an object MUST be unique. + In the internal representation a JSON object is equivalent to a + dictionary (see [WEBIDL]).
+
JSON-LD internal representation
The JSON-LD + internal representation is the result of transforming a JSON syntactic structure + into the core data structures suitable for direct processing: + arrays, dictionaries, + strings, numbers, booleans, and null.
+
null
+ The use of the null value within JSON-LD is used to + ignore or reset values. A key-value pair in the @context where + the value, or the @id of the value, is null + explicitly decouples a term's association with an IRI. A key-value pair in + the body of a JSON-LD document whose value is null has the + same meaning as if the key-value pair was not defined. If + @value, @list, or @set is set to + null in expanded form, then the entire JSON + object is ignored.
+
number
+ In the JSON serialization, a number is similar to that used in most programming languages, except + that the octal and hexadecimal formats are not used and that leading + zeros are not allowed. + In the internal representation, a number is equivalent to either + a long + or double, depending + on if the number has a non-zero fractional part (see [WEBIDL]).
+
+
string
+ A string is a sequence of zero or more Unicode (UTF-8) characters, + wrapped in double quotes, using backslash escapes (if necessary). A + character is represented as a single character string.
+
true and false
+ Values that are used to express one of two possible + boolean states.
+ +

Furthermore, the following terminology is used throughout this document:

+ +
absolute IRI
+ An absolute IRI is defined in [RFC3987] containing a scheme along with a path and + optional query and fragment segments.
+
active context
+ A context that is used to resolve terms while the processing + algorithm is running.
+
base IRI
+ The base IRI is an absolute IRI established in the context, + or is based on the JSON-LD document location. The base IRI is used to turn + relative IRIs into absolute IRIs.
+
blank node
+ A node in a graph that is neither an + IRI, nor a JSON-LD value, nor a list. + A blank node does not contain a de-referenceable + identifier because it is either ephemeral in nature or does not contain information that needs to be + linked to from outside of the linked data graph. A blank node is assigned an identifier starting with + the prefix _:.
+
blank node identifier
+ A blank node identifier is a string that can be used as an identifier for a + blank node within the scope of a JSON-LD document. Blank node identifiers + begin with _:.
+
compact IRI
+ A compact IRI is has the form of prefix:suffix and is used as a way + of expressing an IRI without needing to define separate term definitions for + each IRI contained within a common vocabulary identified by prefix.
+
context
+ A a set of rules for interpreting a JSON-LD document as specified in + The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+
+
default graph
+ The default graph is the only graph in a JSON-LD document which has no graph name. + When executing an algorithm, the graph where data should be placed + if a named graph is not specified.
+
default language
+ The default language is set in the context using the @language key whose + value MUST be a string representing a [BCP47] language code or null.
+
+
edge
+ Every edge has a direction associated with it and is labeled with + an IRI or a blank node identifier. Within the JSON-LD syntax + these edge labels are called properties. Whenever possible, an + edge should be labeled with an IRI.
+
expanded term definition
+ An expanded term definition, is a term definition where the value is a JSON object + containing one or more keyword properties to define the associated absolute IRI, + if this is a reverse property, the type associated with string values, and a container mapping.
+
+
+
graph name
+ The IRI identifying a named graph.
+
graph object
+ A graph object represents a named graph represented as the + value of a property within a node object. When expanded, a + graph object MUST have an @graph member, and may also have + @id, and @index members. + A simple graph object is a + graph object which does not have an @id member. Note + that node objects may have a @graph member, but are + not considered graph objects if they include any other properties. + A top-level object consisting of @graph is also not a graph object.
+
id map
+ An id map is a JSON object value of a term defined with + @container set to @id, who's keys are + interpreted as IRIs representing the @id + of the associated node object; value MUST be a node object. + If the value contains a property expanding to @id, it's value MUST + be equivalent to the referencing key.
+
implicitly named graph
+ A named graph created from the value of a property having an + expanded term definition where @container is set to @graph.
+
index map
+ An index map is a JSON object value of a term defined with + @container set to @index, whose values MUST be any of the following types: + string, + number, + true, + false, + null, + node object, + value object, + list object, + set object, or + an array of zero or more of the above possibilities. +
+
IRI
+ An Internationalized Resource Identifier as described in [RFC3987].
+
JSON-LD document
+ A JSON-LD document is a serialization of a collection of + graphs and comprises exactly one + default graph and zero or more named graphs.
+
JSON-LD Processor
+ A JSON-LD Processor is a system which can perform the algorithms defined in [JSON-LD11CG-API].
+
JSON-LD value
+ A JSON-LD value is a string, a number, + true or false, a typed value, or a + language-tagged string.
+
keyword
+ A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] + in the section titled Syntax Tokens and Keywords.
+
language map
+ An language map is a JSON object value of a term defined with + @container set to @language, whose keys MUST be strings representing + [BCP47] language codes and the values MUST be any of the following types: + null, + string, or + an array of zero or more of the above possibilities. +
+
language-tagged string
+ A language-tagged string consists of a string and a non-empty language + tag as defined by [BCP47]. The language tag MUST be well-formed according to + section 2.2.9 Classes of Conformance + of [BCP47], and is normalized to lowercase.
+
+
linked data graph
+ A labeled directed graph, i.e., a set of nodes + connected by edges, + as specified in the Data Model + section of the JSON-LD specification [JSON-LD11CG]. + A linked data graph is a generalized representation of an + RDF graph + as defined in [RDF-CONCEPTS].
+
list
+ A list is an ordered sequence of IRIs, + blank nodes, and JSON-LD values. + See RDF collection + in [RDF-SCHEMA].
+
list object
+ A list object is a JSON object that has an @list + member.
+
+
local context
+ A context that is specified within a JSON object, + specified via the @context keyword.
+
named graph
+ A named graph is a linked data graph that is identified by an IRI or blank node.
+
nested property
+ A nested property is a property which is contained within an object referenced by + a semantically meaningless nesting property. +
+
node
+ Every node is an IRI, a blank node, + a JSON-LD value, or a list. + A piece of information that is represented in a linked data graph.
+
node object
+ A node object represents zero or more properties of a + node in the graph serialized by the + JSON-LD document. A JSON object is a node object + if it exists outside of the JSON-LD context and: +
    +
  • it does not contain the @value, @list, + or @set keywords, or
    • +
  • it is not the top-most JSON object in the JSON-LD document consisting + of no other members than @graph and @context.
    • +
+
+
+
+
prefix
+ A prefix is the first component of a compact IRI which comes from a + term that maps to a string that, when prepended to the suffix of the compact IRI + results in an absolute IRI.
+
processing mode
+ The processing mode defines how a JSON-LD document is processed. + By default, all documents are assumed to be conformant with + JSON-LD 1.0 [JSON-LD]. By defining + a different version using the @version member in a + context, or via explicit API option, other processing modes + can be accessed. This specification defines extensions for the + json-ld-1.1 processing mode.
+
property
+ The IRI label of an edge in a linked data graph. + See RDF predicate in [RDF11-CONCEPTS].
+
+
RDF dataset
+ A dataset as specified by [RDF11-CONCEPTS] representing a collection of + RDF graphs.
+
+
RDF triple
+ A triple as specified by [RDF11-CONCEPTS].
+
relative IRI
+ A relative IRI is an IRI that is relative to some other absolute IRI, + typically the base IRI of the document. Note that + properties, values of @type, and values of terms defined to be vocabulary relative + are resolved relative to the vocabulary mapping, not the base IRI.
+
set object
+ A set object is a JSON object that has an @set + member.
+
+
term
+ A term is a short word defined in a context that MAY be expanded to an IRI +
+
term definition
+ A term definition is an entry in a context, where the key defines a term which may be used within + a JSON object as a property, type, or elsewhere that a string is interpreted as a vocabulary item. + Its value is either a string (simple term definition), expanding to an absolute IRI, or an expanded term definition. +
+
type map
+ An type map is a JSON object value of a term defined with + @container set to @type, who's keys are + interpreted as IRIs representing the @type + of the associated node object; + value MUST be a node object, or array of node objects. + If the value contains a property expanding to @type, it's values + are merged with the map value when expanding.
+
+
typed value
+ A typed value consists of a value, which is a string, and a type, + which is an IRI.
+
value object
+ A value object is a JSON object that has an @value + member.
+
vocabulary mapping
+ The vocabulary mapping is set in the context using the @vocab key whose + value MUST be an absolute IRI null.
+
+
+ +
+

1.4 Typographical conventions §

+

The following typographic conventions are used in this specification:

+ +
+
markup
+
Markup (elements, attributes, properties), machine processable values (string, characters, media types), property name, or a file name is in red-orange monospace font.
+
variable
+
A variable in pseudo-code or in an algorithm description is in italics.
+
definition
+
A definition of a term, to be used elsewhere in this or other specifications, is in bold and italics.
+
definition reference
+
A reference to a definition in this document is underlined and is also an active link to the definition itself.
+
markup definition reference
+
A references to a definition in this document, when the reference itself is also a markup, is underlined, red-orange monospace font, and is also an active link to the definition itself.
+
external definition reference
+
A reference to a definition in another document is underlined, in italics, and is also an active link to the definition itself.
+
markup external definition reference
+
A reference to a definition in another document, when the reference itself is also a markup, is underlined, in italics red-orange monospace font, and is also an active link to the definition itself.
+
hyperlink
+
A hyperlink is underlined and in blue.
+
[reference]
+
A document reference (normative or informative) is enclosed in square brackets and links to the references section.
+
Changes from Recommendation
+
Sections or phrases changed from the previous Recommendation are highlighted.
+
+ +
Note

Notes are in light green boxes with a green left border and with a "Note" header in green. Notes are normative or informative depending on the whether they are in a normative or informative section, respectively.

+ +
Example 1
Examples are in light khaki boxes, with khaki left border, and with a
+numbered "Example" header in khaki. Examples are always informative.
+The content of the example is in monospace font and may be syntax colored.
+
+
+ +
+

1.5 Design Goals and Rationale §

This section is non-normative.

+ +

JSON-LD satisfies the following design goals:

+ +
+
Simplicity
+
No extra processors or software libraries are necessary to use JSON-LD + in its most basic form. The language provides developers with a very easy + learning curve. Developers only need to know JSON and two + keywords (@context + and @id) to use the basic functionality in JSON-LD.
+
Compatibility
+
A JSON-LD document is always a valid JSON document. This ensures that + all of the standard JSON libraries work seamlessly with JSON-LD documents.
+
Expressiveness
+
The syntax serializes directed graphs. This ensures that almost + every real world data model can be expressed.
+
Terseness
+
The JSON-LD syntax is very terse and human readable, requiring as + little effort as possible from the developer.
+
Zero Edits, most of the time
+
JSON-LD ensures a smooth and simple transition from existing + JSON-based systems. In many cases, + zero edits to the JSON document and the addition of one line to the HTTP response + should suffice (see section 4.9 Interpreting JSON as JSON-LD). + This allows organizations that have + already deployed large JSON-based infrastructure to use JSON-LD's features + in a way that is not disruptive to their day-to-day operations and is + transparent to their current customers. However, there are times where + mapping JSON to a graph representation is a complex undertaking. + In these instances, rather than extending JSON-LD to support + esoteric use cases, we chose not to support the use case. While Zero + Edits is a design goal, it is not always possible without adding + great complexity to the language. JSON-LD focuses on simplicity when + possible.
+
Usable as RDF
+
JSON-LD is usable by developers as + idiomatic JSON, with no need to understand RDF [RDF11-CONCEPTS]. + JSON-LD is also usable as RDF, so people intending to use JSON-LD + with RDF tools will find it can be used like any other RDF syntax. + Complete details of how JSON-LD relates to RDF are in section + 7. Relationship to RDF.
+
+
+ +
+

1.6 Data Model Overview §

This section is non-normative.

+ +

Generally speaking, the data model described by a + JSON-LD document is a labeled, + directed graph. The graph contains + nodes, which are connected by + edges. A node is typically data + such as a string, number, + typed values (like dates and times) + or an IRI. + There is also a special class of node called a + blank node, which is typically used to express data that does + not have a global identifier like an IRI. + Blank nodes are identified using a + blank node identifier. This simple data model is incredibly + flexible and powerful, capable of modeling almost any kind of + data. For a deeper explanation of the data model, see + section 5. Data Model. +

+ +

Developers who are familiar with Linked Data technologies will + recognize the data model as the RDF Data Model. To dive deeper into how + JSON-LD and RDF are related, see + section 7. Relationship to RDF.

+ +

At the surface level, a JSON-LD document is simply + JSON, detailed in [RFC7159]. + For the purpose of describing the core data structures, + this is limited to arrays, dictionaries (the parsed version of a JSON Object), + strings, numbers, booleans, and null, + called the JSON-LD internal representation. + This allows surface syntaxes other than JSON + to be manipulated using the same algorithms, when the syntax maps + to equivalent core data structures.

+
Note

Although not discussed in this specification, + parallel work using YAML [YAML] + and binary representations such as CBOR [RFC7049] + could be used to map into the internal representation, allowing + the JSON-LD 1.1 API [JSON-LD11CG-API] to operate as if the source was a + JSON document.

+
+ +
+

1.7 Syntax Tokens and Keywords §

+ +

JSON-LD specifies a number of syntax tokens and keywords + that are a core part of the language:

+ +
:
+
The separator for JSON keys and values that use + compact IRIs.
@base
+
Used to set the base IRI against which to resolve those relative IRIs + interpreted relative to the document. + This keyword is described in section 4.2 Base IRI.
+
@container
+
Used to set the default container type for a term. + This keyword is described in the following sections: +
+
@context
+
Used to define the short-hand names that are used throughout a JSON-LD + document. These short-hand names are called terms and help + developers to express specific identifiers in a compact manner. The + @context keyword is described in detail in + section 3.1 The Context.
+
@graph
Used to express a graph. + This keyword is described in section 4.15 Named Graphs.
+
@id
+
Used to uniquely identify things that are being described in the document + with IRIs or + blank node identifiers. This keyword + is described in section 3.3 Node Identifiers.
+
@index
+
Used to specify that a container is used to index information and + that processing should continue deeper into a JSON data structure. + This keyword is described in section 4.18 Data Indexing.
+
@language
+
Used to specify the language for a particular string value or the default + language of a JSON-LD document. This keyword is described in + section 4.10 String Internationalization.
+
@list
+
Used to express an ordered set of data. + This keyword is described in section 4.12 Sets and Lists.
+
@nest
Collects a set of nested properties within + a node object.
+
@none
Used as an index value + in an id map, language map, type map or elsewhere where a dictionary is + used to index into other values.
+
@prefix
+ With the value true, allows this term to be used to construct a compact IRI + when compacting.
+
@reverse
+
Used to express reverse properties. This keyword is described in + section 4.13 Reverse Properties.
+
@set
+
Used to express an unordered set of data and to ensure that values are always + represented as arrays. This keyword is described in + section 4.12 Sets and Lists.
+
@type
+
Used to set the data type of a node or + typed value. This keyword is described in + section 4.5 Typed Values.
+
@value
+
Used to specify the data that is associated with a particular + property in the graph. This keyword is described in + section 4.10 String Internationalization and + section 4.5 Typed Values.
+
@version
+ Used in a context definition to set the processing mode. + New features since JSON-LD 1.0 [JSON-LD] described in this specification are + only available when processing mode has been explicitly set to + json-ld-1.1. +
+
@vocab
+
Used to expand properties and values in @type with a common prefix + IRI. This keyword is described in section 4.3 Default Vocabulary.
+
+ +

All keys, keywords, and values in JSON-LD are case-sensitive.

+
+
+ +

2. Conformance §

+ As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, + and notes in this specification are non-normative. Everything else in this specification is + normative. +

The key words MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, and SHOULD NOT are + to be interpreted as described in [RFC2119]. +

+

Conformance criteria are relevant to authors and authoring tool implementers. As well + as sections marked as non-normative, all authoring guidelines, diagrams, examples, + and notes in this specification are non-normative. Everything else in this + specification is normative.

+ +

A JSON-LD document complies with this specification if it follows + the normative statements in appendix 6. JSON-LD Grammar. JSON documents + can be interpreted as JSON-LD by following the normative statements in + section 4.9 Interpreting JSON as JSON-LD. For convenience, normative + statements for documents are often phrased as statements on the properties of the document.

+ +

This specification makes use of the following namespaces:

+
+
dc:
+
http://purl.org/dc/terms/
+
cred:
+
https://w3id.org/credentials#
+
foaf:
+
http://xmlns.com/foaf/0.1/
+
prov
+
http://www.w3.org/ns/prov#
+
rdf:
+
http://www.w3.org/1999/02/22-rdf-syntax-ns#
+
schema:
+
http://schema.org/
+
xsd:
+
http://www.w3.org/2001/XMLSchema#
+
+
+ +
+

3. Basic Concepts §

This section is non-normative.

+ +

JSON [RFC7159] is a lightweight, language-independent data interchange format. + It is easy to parse and easy to generate. However, it is difficult to integrate JSON + from different sources as the data may contain keys that conflict with other + data sources. Furthermore, JSON has no + built-in support for hyperlinks, which are a fundamental building block on + the Web. Let's start by looking at an example that we will be using for the + rest of this section:

+ +
Example 2: Sample JSON document
{
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/",
+  "image": "http://manu.sporny.org/images/manu.png"
+}
+ +

It's obvious to humans that the data is about a person whose + name is "Manu Sporny" + and that the homepage property contains the URL of that person's homepage. + A machine doesn't have such an intuitive understanding and sometimes, + even for humans, it is difficult to resolve ambiguities in such representations. This problem + can be solved by using unambiguous identifiers to denote the different concepts instead of + tokens such as "name", "homepage", etc.

+ +

Linked Data, and the Web in general, uses IRIs + (Internationalized Resource Identifiers as described in [RFC3987]) for unambiguous + identification. The idea is to use IRIs + to assign unambiguous identifiers to data that may be of use to other developers. + It is useful for terms, + like name and homepage, to expand to IRIs + so that developers don't accidentally step on each other's terms. Furthermore, developers and + machines are able to use this IRI (by using a web browser, for instance) to go to + the term and get a definition of what the term means. This process is known as IRI + dereferencing.

+ +

Leveraging the popular schema.org vocabulary, + the example above could be unambiguously expressed as follows:

+ +
Example 3: Sample JSON-LD document using full IRIs instead of terms
{
+  "http://schema.org/name": "Manu Sporny",
+  "http://schema.org/url": { "@id": "http://manu.sporny.org/" },  ← The '@id' keyword means 'This value is an identifier that is an IRI'
+  "http://schema.org/image": { "@id": "http://manu.sporny.org/images/manu.png" }
+}
+ +

In the example above, every property is unambiguously identified by an IRI and all values + representing IRIs are explicitly marked as such by the + @id keyword. While this is a valid JSON-LD + document that is very specific about its data, the document is also overly verbose and difficult + to work with for human developers. To address this issue, JSON-LD introduces the notion + of a context as described in the next section.

+ +
+

3.1 The Context §

This section is non-normative.

+ +

When two people communicate with one another, the conversation takes + place in a shared environment, typically called + "the context of the conversation". This shared context allows the + individuals to use shortcut terms, like the first name of a mutual friend, + to communicate more quickly but without losing accuracy. A context in + JSON-LD works in the same way. It allows two applications to use shortcut + terms to communicate with one another more efficiently, but without + losing accuracy.

+ +

Simply speaking, a context is used to map terms to + IRIs. Terms are case sensitive + and any valid string that is not a reserved JSON-LD keyword + can be used as a term.

+ +

For the sample document in the previous section, a context would + look something like this:

+ +
Example 4: Context for the sample document in the previous section
{
+  "@context": {
+    "name": "http://schema.org/name",  ← This means that 'name' is shorthand for 'http://schema.org/name' 
+    "image": {
+      "@id": "http://schema.org/image",  ← This means that 'image' is shorthand for 'http://schema.org/image' 
+      "@type": "@id"  ← This means that a string value associated with 'image' should be interpreted as an identifier that is an IRI 
+    },
+    "homepage": {
+      "@id": "http://schema.org/url",  ← This means that 'homepage' is shorthand for 'http://schema.org/url' 
+      "@type": "@id"  ← This means that a string value associated with 'homepage' should be interpreted as an identifier that is an IRI 
+    }
+  }
+}
+ +

As the context above shows, the value of a term definition can + either be a simple string, mapping the term to an IRI, + or a JSON object.

+ +

When a JSON object is associated with a term, it is called + an expanded term definition. The example above specifies that + the values of image and homepage, if they are + strings, are to be interpreted as + IRIs. Expanded term definitions + also allow terms to be used for index maps + and to specify whether array values are to be + interpreted as sets or lists. + Expanded term definitions may + be defined using absolute or + compact IRIs as keys, which is + mainly used to associate type or language information with an + absolute or compact IRI.

+ +

Contexts can either be directly embedded + into the document or be referenced. Assuming the context document in the previous + example can be retrieved at https://json-ld.org/contexts/person.jsonld, + it can be referenced by adding a single line and allows a JSON-LD document to + be expressed much more concisely as shown in the example below:

+ +
Example 5: Referencing a JSON-LD context
{
+  "@context": "https://json-ld.org/contexts/person.jsonld",
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/",
+  "image": "http://manu.sporny.org/images/manu.png"
+}
+ +

The referenced context not only specifies how the terms map to + IRIs in the Schema.org vocabulary but also + specifies that string values associated with + the homepage and image property + can be interpreted as an IRI ("@type": "@id", + see section 3.2 IRIs for more details). This information allows developers + to re-use each other's data without having to agree to how their data will interoperate + on a site-by-site basis. External JSON-LD context documents may contain extra + information located outside of the @context key, such as + documentation about the terms declared in the + document. Information contained outside of the @context value + is ignored when the document is used as an external JSON-LD context document.

+ +

JSON documents can be interpreted as JSON-LD without having to be modified by + referencing a context via an HTTP Link Header + as described in section 4.9 Interpreting JSON as JSON-LD. It is also + possible to apply a custom context using the JSON-LD 1.1 API [JSON-LD11CG-API].

+ +

In JSON-LD documents, + contexts may also be specified inline. + This has the advantage that documents can be processed even in the + absence of a connection to the Web. Ultimately, this is a modeling decision + and different use cases may require different handling.

+ +
Example 6: In-line context definition
{
+  "@context": {
+    "name": "http://schema.org/name",
+    "image": {
+      "@id": "http://schema.org/image",
+      "@type": "@id"
+    },
+    "homepage": {
+      "@id": "http://schema.org/url",
+      "@type": "@id"
+    }
+  },
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/",
+  "image": "http://manu.sporny.org/images/manu.png"
+}
+ +

This section only covers the most basic features of the JSON-LD + Context. More advanced features related to the JSON-LD Context are covered + in section section 4. Advanced Concepts. +

+
+ +
+

3.2 IRIs §

This section is non-normative.

+ +

IRIs (Internationalized Resource Identifiers + [RFC3987]) are fundamental to Linked Data as that is how most + nodes and properties + are identified. In JSON-LD, IRIs may be represented as an + absolute IRI or a relative IRI. An + absolute IRI is defined in [RFC3987] as containing a + scheme along with path and optional query and + fragment segments. A relative IRI is an IRI + that is relative to some other absolute IRI. + In JSON-LD, with exceptions are as described below, all relative IRIs + are resolved relative to the base IRI.

+ +
Note

Properties, values of @type, + and values of properties with a term definition + that defines them as being relative to the vocabulary mapping, + may have the form of a relative IRI, but are resolved using the + vocabulary mapping, and not the base IRI.

+ +

A string is interpreted as an IRI when it is the + value of an @id member:

+ +
Example 7: Values of @id are interpreted as IRI
{
+  ...
+  "homepage": { "@id": "http://example.com/" }
+  ...
+}
+ +

Values that are interpreted as IRIs, can also be + expressed as relative IRIs. For example, + assuming that the following document is located at + http://example.com/about/, the relative IRI + ../ would expand to http://example.com/ (for more + information on where relative IRIs can be + used, please refer to section 6. JSON-LD Grammar).

+ +
Example 8: IRIs can be relative
{
+  ...
+  "homepage": { "@id": "../" }
+  ...
+}
+ +

Absolute IRIs can be expressed directly + in the key position like so:

+ +
Example 9: IRI as a key
{
+  ...
+  "http://schema.org/name": "Manu Sporny",
+  ...
+}
+ +

In the example above, the key http://schema.org/name + is interpreted as an absolute IRI.

+ +

Term-to-IRI expansion occurs if the key matches a term defined + within the active context:

+ +
Example 10: Term expansion from context definition
{
+  "@context": {
+    "name": "http://schema.org/name"
+  },
+  "name": "Manu Sporny",
+  "status": "trollin'"
+}
+ +

JSON keys that do not expand to an IRI, such as status + in the example above, are not Linked Data and thus ignored when processed.

+ +

If type coercion rules are specified in the @context for + a particular term or property IRI, an IRI is generated:

+ +
Example 11: Type coercion
{
+  "@context": {
+    ...
+    "homepage": {
+      "@id": "http://schema.org/url",
+      "@type": "@id"
+    }
+    ...
+  },
+  ...
+  "homepage": "http://manu.sporny.org/"
+  ...
+}
+ +

In the example above, since the value http://manu.sporny.org/ + is expressed as a JSON string, the type coercion + rules will transform the value into an IRI when processing the data. + See section 4.6 Type Coercion for more + details about this feature.

+ +

In summary, IRIs can be expressed in a variety of + different ways in JSON-LD:

+ +
    +
  1. JSON object keys that have a term mapping in + the active context expand to an IRI + (only applies outside of the context definition).
    2. +
  2. An IRI is generated for the string value specified using + @id or @type.
    3. +
  3. An IRI is generated for the string value of any key for which there + are coercion rules that contain an @type key that is + set to a value of @id or @vocab.
    4. +
+ +

This section only covers the most basic features associated with IRIs + in JSON-LD. More advanced features related to IRIs are covered in + section 4. Advanced Concepts. +

+ +
+ +
+

3.3 Node Identifiers §

This section is non-normative.

+ +

To be able to externally reference nodes + in a graph, it is important that + nodes have an identifier. IRIs + are a fundamental concept of Linked Data, for + nodes to be truly linked, dereferencing the + identifier should result in a representation of that node. + This may allow an application to retrieve further information about a + node.

+ +

In JSON-LD, a node is identified using the @id + keyword:

+ +
Example 12: Identifying a node
{
+  "@context": {
+    ...
+    "name": "http://schema.org/name"
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "name": "Markus Lanthaler",
+  ...
+}
+ +

The example above contains a node object identified by the IRI + http://me.markus-lanthaler.com/.

+ +

This section only covers the most basic features associated with + node identifiers in JSON-LD. More advanced features related to + node identifiers are covered in section 4. Advanced Concepts. +

+ +
+ +
+

3.4 Specifying the Type §

This section is non-normative.

+ +

The type of a particular node can be specified using the @type + keyword. In Linked Data, types are uniquely + identified with an IRI.

+ +
Example 13: Specifying the type for a node
{
+  ...
+  "@id": "http://example.org/places#BrewEats",
+  "@type": "http://schema.org/Restaurant",
+  ...
+}
+ +

A node can be assigned more than one type by using an array:

+ +
Example 14: Specifying multiple types for a node
{
+  ...
+  "@id": "http://example.org/places#BrewEats",
+  "@type": [ "http://schema.org/Restaurant", "http://schema.org/Brewery" ],
+  ...
+}
+ +

The value of an @type key may also be a term defined in the active context:

+
Example 15: Using a term to specify the type
{
+  "@context": {
+    ...
+    "Restaurant": "http://schema.org/Restaurant", 
+    "Brewery": "http://schema.org/Brewery"
+  },
+  "@id": "http://example.org/places#BrewEats",
+  "@type": [ "Restaurant", "Brewery" ],
+  ...
+}
+ +
Note

This section only covers the most basic features associated with + types in JSON-LD. It is worth noting that the @type + keyword is not only used to specify the type of a + node but also to express typed values + (as described in section 4.5 Typed Values) and to + type coerce values (as described in + section 4.6 Type Coercion). Specifically, @type + cannot be used in a context to define a node's + type. For a detailed description of the differences, please refer to + section 4.5 Typed Values.

+ +
+
+ +
+

4. Advanced Concepts §

+ +

JSON-LD has a number of features that provide functionality above and beyond + the core functionality described above. The following section describes this + advanced functionality in more detail.

+ +
+

4.1 JSON-LD 1.1 Processing Mode §

This section is non-normative.

+ +

New features defined in JSON-LD 1.1 are available + when the processing mode is set to json-ld-1.1. + This may be set using the @version member in a context + set to the value 1.1 as a number, or through an API option.

+ +
Example 16: Setting @version in context
{
+  "@context": {
+    "@version": 1.1,
+    ...
+  },
+  ...
+}
+ +

The first context encountered when processing a + document which contains @version determines the processing mode, + unless it is defined explicitly through an API option.

+ +
Note

Setting the processing mode explicitly + for JSON-LD 1.1 is necessary so that a JSON-LD 1.0 processor + does not attempt to process a JSON-LD 1.1 document and silently + produce different results.

+
+ +
+

4.2 Base IRI §

This section is non-normative.

+ +

JSON-LD allows IRIs + to be specified in a relative form which is + resolved against the document base according + section 5.1 Establishing a Base URI + of [RFC3986]. The base IRI may be explicitly set with a context + using the @base keyword.

+ +

For example, if a JSON-LD document was retrieved from http://example.com/document.jsonld, + relative IRIs would resolve against that IRI:

+ +
Example 17: Use a relative IRI as node identifier
{
+  "@context": {
+    "label": "http://www.w3.org/2000/01/rdf-schema#label"
+  },
+  "@id": "",
+  "label": "Just a simple document"
+}
+ +

This document uses an empty @id, which resolves to the document base. + However, if the document is moved to a different location, the IRI would change. + To prevent this without having to use an absolute IRI, a context + may define an @base mapping, to overwrite the base IRI for the document.

+ +
Example 18: Setting the document base in a document
{
+  "@context": {
+    "@base": "http://example.com/document.jsonld",
+    "label": "http://www.w3.org/2000/01/rdf-schema#label"
+  },
+  "@id": "",
+  "label": "Just a simple document"
+}
+ +

Setting @base to null will prevent + relative IRIs to be expanded to + absolute IRIs.

+ +

Please note that the @base will be ignored if used in + external contexts.

+
+ +
+

4.3 Default Vocabulary §

This section is non-normative.

+ +

At times, all properties and types may come from the same vocabulary. JSON-LD's + @vocab keyword allows an author to set a common prefix which + is used as the vocabulary mapping and is used + for all properties and types that do not match a term and are neither + a compact IRI nor an absolute IRI (i.e., they do + not contain a colon).

+ +
Example 19: Using a common vocabulary prefix
{
+  "@context": {
+    "@vocab": "http://schema.org/"
+  },
+  "@id": "http://example.org/places#BrewEats",
+  "@type": "Restaurant",
+  "name": "Brew Eats"
+  ...
+}
+ +

If @vocab is used but certain keys in an + object should not be expanded using + the vocabulary IRI, a term can be explicitly set + to null in the context. For instance, in the + example below the databaseId member would not expand to an + IRI causing the property to be dropped when expanding.

+ +
Example 20: Using the null keyword to ignore data
{
+  "@context": {
+     "@vocab": "http://schema.org/",
+     "databaseId": null
+  },
+  "@id": "http://example.org/places#BrewEats",
+  "@type": "Restaurant",
+  "name": "Brew Eats",
+  "databaseId": "23987520"
+}
+ +
+

4.3.1 Using the Document Base as the Default Vocabulary §

+

In some cases, vocabulary terms are defined directly within the document + itself, rather than in an external vocabulary. Since + json-ld-1.1, the vocabulary mapping in the active + context can be set to the empty string "", which causes terms which + are expanded relative to the vocabulary, such as the keys of node + objects, to use the base IRI to create absolute + IRIs.

+
Example 21: Using "" as the vocabulary mapping
{
+  "@context": {
+    "@base": "http://example/document",
+    "@vocab": ""
+  },
+  "@id": "http://example.org/places#BrewEats",
+  "@type": "#Restaurant",
+  "#name": "Brew Eats"
+  ...
+}
+

If this document were located at http://example/document, it would expand as follows:

+
Example 22: Using "" as the vocabulary mapping (expanded)
[{
+  "@id": "http://example.org/places#BrewEats",
+  "@type": ["http://example/document#Restaurant"],
+  "http://example/document#name": [{"@value": "Brew Eats"}]
+}]
+
+
+ +
+

4.4 Compact IRIs §

This section is non-normative.

+ +

A compact IRI is a way of expressing an IRI + using a prefix and suffix separated by a colon (:). + The prefix is a term taken from the + active context and is a short string identifying a + particular IRI in a JSON-LD document. For example, the + prefix foaf may be used as a short hand for the + Friend-of-a-Friend vocabulary, which is identified using the IRI + http://xmlns.com/foaf/0.1/. A developer may append + any of the FOAF vocabulary terms to the end of the prefix to specify a short-hand + version of the absolute IRI for the vocabulary term. For example, + foaf:name would be expanded to the IRI + http://xmlns.com/foaf/0.1/name.

+ +
Example 23: Prefix expansion
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/"
+    ...
+  },
+  "@type": "foaf:Person",
+  "foaf:name": "Dave Longley",
+  ...
+}
+ +

In the example above, foaf:name expands to the IRI + http://xmlns.com/foaf/0.1/name and foaf:Person expands + to http://xmlns.com/foaf/0.1/Person.

+ +

Prefixes are expanded when the form of the value + is a compact IRI represented as a prefix:suffix + combination, the prefix matches a term defined within the + active context, and the suffix does not begin with two + slashes (//). The compact IRI is expanded by + concatenating the IRI mapped to the prefix to the (possibly empty) + suffix. If the prefix is not defined in the active context, + or the suffix begins with two slashes (such as in http://example.com), + the value is interpreted as absolute IRI instead. If the prefix is an + underscore (_), the value is interpreted as blank node identifier + instead.

+ +

It's also possible to use compact IRIs within the context as shown in the + following example:

+ +
Example 24: Using vocabularies
{
+  "@context": {
+    "@version": 1.1,
+    "xsd": "http://www.w3.org/2001/XMLSchema#",
+    "foaf": "http://xmlns.com/foaf/0.1/",
+    "foaf:homepage": { "@type": "@id" },
+    "picture": { "@id": "foaf:depiction", "@type": "@id" }
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "@type": "foaf:Person",
+  "foaf:name": "Markus Lanthaler",
+  "foaf:homepage": "http://www.markus-lanthaler.com/",
+  "picture": "http://twitter.com/account/profile_image/markuslanthaler"
+}
+ +

In JSON-LD 1.0, terms may be chosen as compact IRI prefixes when + compacting only if a simple term definition is used where the value ends with a + URI gen-delim character (e.g, /, + # and others, see [RFC3986]). + The previous specification allows any term to be chosen as + a compact IRI prefix, which led to a poor experience.

+ +

In JSON-LD 1.1, terms may be chosen as compact IRI prefixes + when compacting only if + a simple term definition is used where the value ends with a URI gen-delim character, + or if their expanded term definition contains + a @prefix member with the value true.

+ +
Note

This represents a small change to the 1.0 algorithm to prevent IRIs + that are not really intended to be used as prefixes from being used for creating + compact IRIs.

+ +

When processing mode is set to json-ld-1.1, terms will be used as compact IRI prefixes + when compacting only if their expanded term definition contains + a @prefix member with the value true, or if it has a + a simple term definition where the value ends with a URI gen-delim character + (e.g, /, # and others, see [RFC3986]).

+ +
Example 25: Using explicit @prefix declaration to create compact IRIs
{
+  "@context": {
+    "compact-iris": {"@id": "http://example.com/compact-iris-", "@prefix": true},
+    "property": "http://example.com/property"
+  },
+  "property": {
+    "@id": "compact-iris:are-considered",
+    "property": "@prefix does not require a gen-delim"
+  }
+}
+ +

In this case, the compact-iris term would not normally be usable as a prefix, both + because it is defined with an expanded term definition, and because + it's @id does not end in a + gen-delim character. Adding + "@prefix": true allows it to be used as the prefix portion of + the compact IRI compact-iris:are-considered.

+
+ +
+

4.5 Typed Values §

This section is non-normative.

+ +

+ A value with an associated type, also known as a + typed value, is indicated by associating a value with + an IRI which indicates the value's type. Typed values may be + expressed in JSON-LD in three ways: +

+ +
    +
  1. By utilizing the @type keyword when defining + a term within an @context section.
    2. +
  2. By utilizing a value object.
    3. +
  3. By using a native JSON type such as number, true, or false.
    4. +
+ +

The first example uses the @type keyword to associate a +type with a particular term in the @context:

+ +
Example 26: Expanded term definition with type coercion
{
+  "@context": {
+    "modified": {
+      "@id": "http://purl.org/dc/terms/modified",
+      "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
+    }
+  },
+  ...
+  "@id": "http://example.com/docs/1",
+  "modified": "2010-05-29T14:17:39+02:00",
+  ...
+}
+ +

The modified key's value above is automatically type coerced to a + dateTime value because of the information specified in the + @context. A JSON-LD processor will interpret the example above + as follows:

+ + + + + + + + + + + + + + + + +
SubjectPropertyValueValue Type
http://example.com/docs/1http://purl.org/dc/terms/modified2010-05-29T14:17:39+02:00xsd:dateTime
+ +

The second example uses the expanded form of setting the type information +in the body of a JSON-LD document:

+ +
Example 27: Expanded value with type
{
+  "@context": {
+    "modified": {
+      "@id": "http://purl.org/dc/terms/modified"
+    }
+  },
+  ...
+  "modified": {
+    "@value": "2010-05-29T14:17:39+02:00",
+    "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
+  }
+  ...
+}
+ +

Both examples above would generate the value + 2010-05-29T14:17:39+02:00 with the type + http://www.w3.org/2001/XMLSchema#dateTime. Note that it is + also possible to use a term or a compact IRI to + express the value of a type.

+ +
Note

The @type keyword is also used to associate a type + with a node. The concept of a node type and + a value type are different.

+ +

A node type specifies the type of thing + that is being described, like a person, place, event, or web page. A + value type specifies the data type of a particular value, such + as an integer, a floating point number, or a date.

+ +
Example 28: Example demonstrating the context-sensitivity for @type
{
+  ...
+  "@id": "http://example.org/posts#TripToWestVirginia",
+  "@type": "http://schema.org/BlogPosting",  ← This is a node type
+  "modified": {
+    "@value": "2010-05-29T14:17:39+02:00",
+    "@type": "http://www.w3.org/2001/XMLSchema#dateTime"  ← This is a value type
+  }
+  ...
+}
+ +

The first use of @type associates a node type + (http://schema.org/BlogPosting) with the node, + which is expressed using the @id keyword. + The second use of @type associates a value type + (http://www.w3.org/2001/XMLSchema#dateTime) with the + value expressed using the @value keyword. As a + general rule, when @value and @type are used in + the same JSON object, the @type + keyword is expressing a value type. + Otherwise, the @type keyword is expressing a + node type. The example above expresses the following data:

+ + + + + + + + + + + + + + + + + + + + + + +
SubjectPropertyValueValue Type
http://example.org/posts#TripToWestVirginiardf:typeschema:BlogPosting-
http://example.org/posts#TripToWestVirginiadc:modified2010-05-29T14:17:39+02:00xsd:dateTime
+ +
+ +
+

4.6 Type Coercion §

This section is non-normative.

+ +

JSON-LD supports the coercion of values to particular data types. +Type coercion allows someone deploying JSON-LD to coerce the incoming or +outgoing values to the proper data type based on a mapping of data type IRIs to +terms. Using type coercion, value representation is preserved without requiring +the data type to be specified with each piece of data.

+ +

Type coercion is specified within an expanded term definition + using the @type key. The value of this key expands to an IRI. + Alternatively, the keyword @id or @vocab may be used + as value to indicate that within the body of a JSON-LD document, a string value of a + term coerced to @id or @vocab is to be interpreted as an + IRI. The difference between @id and @vocab is how values are expanded + to absolute IRIs. @vocab first tries to expand the value + by interpreting it as term. If no matching term is found in the + active context, it tries to expand it as compact IRI or absolute IRI + if there's a colon in the value; otherwise, it will expand the value using the + active context's vocabulary mapping, if present. + Values coerced to @id in contrast are expanded as + compact IRI or absolute IRI if a colon is present; otherwise, they are interpreted + as relative IRI.

+ +

Terms or compact IRIs used as the value of a + @type key may be defined within the same context. This means that one may specify a + term like xsd and then use xsd:integer within the same + context definition.

+ +

The example below demonstrates how a JSON-LD author can coerce values to +typed values and IRIs.

+ +
Example 29: Expanded term definition with types
{
+  "@context": {
+    "xsd": "http://www.w3.org/2001/XMLSchema#",
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "age": {
+      "@id": "http://xmlns.com/foaf/0.1/age",
+      "@type": "xsd:integer"
+    },
+    "homepage": {
+      "@id": "http://xmlns.com/foaf/0.1/homepage",
+      "@type": "@id"
+    }
+  },
+  "@id": "http://example.com/people#john",
+  "name": "John Smith",
+  "age": "41",
+  "homepage": [
+    "http://personal.example.org/",
+    "http://work.example.com/jsmith/"
+  ]
+}
+ +

The example shown above would generate the following data.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SubjectPropertyValueValue Type
http://example.com/people#johnfoaf:nameJohn Smith 
http://example.com/people#johnfoaf:age41xsd:integer
http://example.com/people#johnfoaf:homepagehttp://personal.example.org/IRI
http://work.example.com/jsmith/IRI
+ +

Terms may also be defined using absolute IRIs + or compact IRIs. This allows coercion rules + to be applied to keys which are not represented as a simple term. + For example:

+ +
Example 30: Term definitions using compact and absolute IRIs
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/",
+    "foaf:age": {
+      "@id": "http://xmlns.com/foaf/0.1/age",
+      "@type": "xsd:integer"
+    },
+    "http://xmlns.com/foaf/0.1/homepage": {
+      "@type": "@id"
+    }
+  },
+  "foaf:name": "John Smith",
+  "foaf:age": "41",
+  "http://xmlns.com/foaf/0.1/homepage": [
+    "http://personal.example.org/",
+    "http://work.example.com/jsmith/"
+  ]
+}
+ +

In this case the @id definition in the term definition is optional. + If it does exist, the compact IRI or IRI representing + the term will always be expanded to IRI defined by the @id + key—regardless of whether a prefix is defined or not.

+ +

Type coercion is always performed using the unexpanded value of the key. In the + example above, that means that type coercion is done looking for foaf:age + in the active context and not for the corresponding, expanded + IRI http://xmlns.com/foaf/0.1/age.

+ +
Note

Keys in the context are treated as terms for the purpose of + expansion and value coercion. At times, this may result in multiple representations for the same expanded IRI. + For example, one could specify that dog and cat both expanded to http://example.com/vocab#animal. + Doing this could be useful for establishing different type coercion or language specification rules. It also allows a compact IRI (or even an + absolute IRI) to be defined as something else entirely. For example, one could specify that + the term http://example.org/zoo should expand to + http://example.org/river, but this usage is discouraged because it would lead to a + great deal of confusion among developers attempting to understand the JSON-LD document.

+ + +
+ +
+

4.7 Embedding §

This section is non-normative.

+ +

Embedding is a JSON-LD feature that allows an author to + use node objects as + property values. This is a commonly used mechanism for + creating a parent-child relationship between two nodes.

+ +

Without embedding, node objects can be linked by referencing the + identifier of another node object. For example:

+ +
Example 31: Referencing node objects
[{
+  "@context": {
+    "@vocab": "http://schema.org/",
+    "knows": {"@type": "@id"}
+  },
+  "name": "Manu Sporny",
+  "@type": "Person",
+  "knows": "http://foaf.me/gkellogg#me"
+}, {
+  "@id": "http://foaf.me/gkellogg#me",
+  "@type": "Person",
+  "name": "Gregg Kellogg"
+}]
+ +

The previous example describes two node objects, for Manu and Gregg, with + the knows property defined to treat string values as identifiers. + Embedding allows the node object for Gregg to be embedded as a value + of the knows property:

+ +
Example 32: Embedding a node object as property value of another node object
{
+  "@context": {
+    "@vocab": "http://schema.org/"
+  },
+  "name": "Manu Sporny",
+  "knows": {
+    "@id": "http://foaf.me/gkellogg#me",
+    "@type": "Person",
+    "name": "Gregg Kellogg"
+  }
+}
+ +

A node object, like the one used above, may be used in + any value position in the body of a JSON-LD document. Note that type coercion of the knows property + is not required, as the value is not a string.

+
+ +
+

4.8 Advanced Context Usage §

This section is non-normative.

+ +

Section 3.1 The Context introduced the basics of what makes + JSON-LD work. This section expands on the basic principles of the + context and demonstrates how more advanced use cases can + be achieved using JSON-LD.

+ +

In general, contexts may be used at any time a + JSON object is defined. + The only time that one cannot express a context is as a direct child of another context definition. + For example, a JSON-LD document may use more than one context at different + points in a document:

+ +
Example 33: Using multiple contexts
[
+  {
+    "@context": "http://example.org/contexts/person.jsonld",
+    "name": "Manu Sporny",
+    "homepage": "http://manu.sporny.org/",
+    "depiction": "http://twitter.com/account/profile_image/manusporny"
+  },
+  {
+    "@context": "http://example.org/contexts/place.jsonld",
+    "name": "The Empire State Building",
+    "description": "The Empire State Building is a 102-story landmark in New York City.",
+    "geo": {
+      "latitude": "40.75",
+      "longitude": "73.98"
+    }
+  }
+]
+ +

Duplicate context terms are overridden using a + most-recently-defined-wins mechanism.

+ +
Example 34: Scoped contexts within node objects
{
+  "@context": {
+    "name": "http://example.com/person#name",
+    "details": "http://example.com/person#details"
+  },
+  "name": "Markus Lanthaler",
+  ...
+  "details": {
+    "@context": {
+      "name": "http://example.com/organization#name"
+    },
+    "name": "Graz University of Technology"
+  }
+}
+ +

In the example above, the name term is overridden + in the more deeply nested details structure. Note that this is + rarely a good authoring practice and is typically used when working with + legacy applications that depend on a specific structure of the + JSON object. If a term is redefined within a + context, all previous rules associated with the previous definition are + removed. If a term is redefined to null, + the term is effectively removed from the list of + terms defined in the active context.

+ +

Multiple contexts may be combined using an array, which is processed + in order. The set of contexts defined within a specific JSON object are + referred to as local contexts. The + active context refers to the accumulation of + local contexts that are in scope at a + specific point within the document. Setting a local context + to null effectively resets the active context + to an empty context. The following example specifies an external context + and then layers an embedded context on top of the external context:

+ +
Example 35: Combining external and local contexts
{
+  "@context": [
+    "https://json-ld.org/contexts/person.jsonld",
+    {
+      "pic": "http://xmlns.com/foaf/0.1/depiction"
+    }
+  ],
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/",
+  "pic": "http://twitter.com/account/profile_image/manusporny"
+}
+ +
Note

When possible, the context definition should be put + at the top of a JSON-LD document. This makes the document easier to read and + might make streaming parsers more efficient. Documents that do not have the + context at the top are still conformant JSON-LD.

+ +
Note

To avoid forward-compatibility issues, terms + starting with an @ character are to be avoided as they + might be used as keyword in future versions + of JSON-LD. Terms starting with an @ character that are not + JSON-LD 1.1 keywords are treated as any other term, i.e., + they are ignored unless mapped to an IRI. Furthermore, the use of + empty terms ("") is not allowed as + not all programming languages are able to handle empty JSON keys.

+
+ +
+

4.9 Interpreting JSON as JSON-LD §

+ +

Ordinary JSON documents can be interpreted as JSON-LD + by providing an explicit JSON-LD context document. One way + to provide this is by using referencing a JSON-LD + context document in an HTTP Link Header. + Doing so allows JSON to be unambiguously machine-readable without requiring developers to drastically + change their documents and provides an upgrade path for existing infrastructure + without breaking existing clients that rely on the application/json + media type or a media type with a +json suffix as defined in + [RFC6839].

+ +

In order to use an external context with an ordinary JSON document, + when retrieving an ordinary JSON document via HTTP, processors MUST + retrieve any JSON-LD document referenced by a + Link Header with:

+ +
    +
  • rel="http://www.w3.org/ns/json-ld#context", and
    • +
  • type="application/ld+json".
    • +
+ +

The referenced document MUST have a top-level JSON object. + The @context subtree within that object is added to the top-level + JSON object of the referencing document. If an array + is at the top-level of the referencing document and its items are + JSON objects, the @context + subtree is added to all array items. All extra information located outside + of the @context subtree in the referenced document MUST be + discarded. Effectively this means that the active context is + initialized with the referenced external context. A response MUST NOT + contain more than one HTTP Link Header [RFC5988] using the + http://www.w3.org/ns/json-ld#context link relation.

+ +

Other mechanisms for providing a JSON-LD Context MAY be described for other + URI schemes.

+ +

The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] + provides for an expandContext option for specifying + a context to use when expanding JSON documents programatically.

+ +

The following example demonstrates the use of an external context with an + ordinary JSON document over HTTP:

+ +
Example 36: Referencing a JSON-LD context from a JSON document via an HTTP Link Header
GET /ordinary-json-document.json HTTP/1.1
+Host: example.com
+Accept: application/ld+json,application/json,*/*;q=0.1
+
+====================================
+
+HTTP/1.1 200 OK
+...
+Content-Type: application/json
+Link: <https://json-ld.org/contexts/person.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
+
+{
+  "name": "Markus Lanthaler",
+  "homepage": "http://www.markus-lanthaler.com/",
+  "image": "http://twitter.com/account/profile_image/markuslanthaler"
+}
+ +

Please note that JSON-LD documents + served with the application/ld+json + media type MUST have all context information, including references to external + contexts, within the body of the document. Contexts linked via a + http://www.w3.org/ns/json-ld#context HTTP Link Header MUST be + ignored for such documents.

+
+ +
+

4.10 String Internationalization §

This section is non-normative.

+ +

At times, it is important to annotate a string + with its language. In JSON-LD this is possible in a variety of ways. + First, it is possible to define a default language for a JSON-LD document + by setting the @language key in the context:

+ +
Example 37: Setting the default language of a JSON-LD document
{
+  "@context": {
+    ...
+    "@language": "ja"
+  },
+  "name": "花澄",
+  "occupation": "科学者"
+}
+ +

The example above would associate the ja language + code with the two strings 花澄 and 科学者. + Languages codes are defined in [BCP47]. The default language applies to all + string values that are not type coerced.

+ +

To clear the default language for a subtree, @language can + be set to null in a local context as follows:

+ +
Example 38: Clearing default language
{
+  "@context": {
+    ...
+    "@language": "ja"
+  },
+  "name": "花澄",
+  "details": {
+    "@context": {
+      "@language": null
+    },
+    "occupation": "Ninja"
+  }
+}
+ +

Second, it is possible to associate a language with a specific term + using an expanded term definition:

+ +
Example 39: Expanded term definition with language
{
+  "@context": {
+    ...
+    "ex": "http://example.com/vocab/",
+    "@language": "ja",
+    "name": { "@id": "ex:name", "@language": null },
+    "occupation": { "@id": "ex:occupation" },
+    "occupation_en": { "@id": "ex:occupation", "@language": "en" },
+    "occupation_cs": { "@id": "ex:occupation", "@language": "cs" }
+  },
+  "name": "Yagyū Muneyoshi",
+  "occupation": "忍者",
+  "occupation_en": "Ninja",
+  "occupation_cs": "Nindža",
+  ...
+}
+ +

The example above would associate 忍者 with the specified default + language code ja, Ninja with the language code + en, and Nindža with the language code cs. + The value of name, Yagyū Muneyoshi wouldn't be + associated with any language code since @language was reset to + null in the expanded term definition.

+ +
Note

Language associations are only applied to plain + strings. Typed values + or values that are subject to type coercion + are not language tagged.

+ +

Just as in the example above, systems often need to express the value of a + property in multiple languages. Typically, such systems also try to ensure that + developers have a programmatically easy way to navigate the data structures for + the language-specific data. In this case, language maps + may be utilized.

+ +
Example 40: Language map expressing a property in three languages
{
+  "@context": {
+    ...
+    "occupation": { "@id": "ex:occupation", "@container": "@language" }
+  },
+  "name": "Yagyū Muneyoshi",
+  "occupation": {
+    "ja": "忍者",
+    "en": "Ninja",
+    "cs": "Nindža"
+  }
+  ...
+}
+ +

The example above expresses exactly the same information as the previous + example but consolidates all values in a single property. To access the + value in a specific language in a programming language supporting dot-notation + accessors for object properties, a developer may use the + property.language pattern. For example, to access the occupation + in English, a developer would use the following code snippet: + obj.occupation.en.

+ +

Third, it is possible to override the default language by using a + value object:

+ +
Example 41: Overriding default language using an expanded value
{
+  "@context": {
+    ...
+    "@language": "ja"
+  },
+  "name": "花澄",
+  "occupation": {
+    "@value": "Scientist",
+    "@language": "en"
+  }
+}
+ +

This makes it possible to specify a plain string by omitting the + @language tag or setting it to null when expressing + it using a value object:

+ +
Example 42: Removing language information using an expanded value
{
+  "@context": {
+    ...
+    "@language": "ja"
+  },
+  "name": {
+    "@value": "Frank"
+  },
+  "occupation": {
+    "@value": "Ninja",
+    "@language": "en"
+  },
+  "speciality": "手裏剣"
+}
+ +
+ +
+

4.11 IRI Expansion within a Context §

This section is non-normative.

+

In general, normal IRI expansion rules apply + anywhere an IRI is expected (see section 3.2 IRIs). Within + a context definition, this can mean that terms defined + within the context may also be used within that context as long as + there are no circular dependencies. For example, it is common to use + the xsd namespace when defining typed values:

+ +
Example 43: IRI expansion within a context
{
+  "@context": {
+    "xsd": "http://www.w3.org/2001/XMLSchema#",
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "age": {
+      "@id": "http://xmlns.com/foaf/0.1/age",
+      "@type": "xsd:integer"
+    },
+    "homepage": {
+      "@id": "http://xmlns.com/foaf/0.1/homepage",
+      "@type": "@id"
+    }
+  },
+  ...
+}
+ +

In this example, the xsd term is defined + and used as a prefix for the @type coercion + of the age property.

+ +

Terms may also be used when defining the IRI of another +term:

+ +
Example 44: Using a term to define the IRI of another term within a context
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/",
+    "xsd": "http://www.w3.org/2001/XMLSchema#",
+    "name": "foaf:name",
+    "age": {
+      "@id": "foaf:age",
+      "@type": "xsd:integer"
+    },
+    "homepage": {
+      "@id": "foaf:homepage",
+      "@type": "@id"
+    }
+  },
+  ...
+}
+ +

Compact IRIs + and IRIs may be used on the left-hand side of a + term definition.

+ +
Example 45: Using a compact IRI as a term
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/",
+    "xsd": "http://www.w3.org/2001/XMLSchema#",
+    "name": "foaf:name",
+    "foaf:age": {
+      "@type": "xsd:integer"
+    },
+    "foaf:homepage": {
+      "@type": "@id"
+    }
+  },
+  ...
+}
+ +

+In this example, the compact IRI form is used in two different +ways. +In the first approach, foaf:age declares both the +IRI for the term (using short-form) as well as the +@type associated with the term. In the second +approach, only the @type associated with the term is +specified. The full IRI for +foaf:homepage is determined by looking up the foaf +prefix in the +context. +

+ +

+Absolute IRIs may also be used in the key position in a context: +

+ +
Example 46: Associating context definitions with absolute IRIs
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/",
+    "xsd": "http://www.w3.org/2001/XMLSchema#",
+    "name": "foaf:name",
+    "foaf:age": {
+      "@id": "foaf:age",
+      "@type": "xsd:integer"
+    },
+    "http://xmlns.com/foaf/0.1/homepage": {
+      "@type": "@id"
+    }
+  },
+  ...
+}
+ +

In order for the absolute IRI to match above, the absolute IRI + needs to be used in the JSON-LD document. Also note that foaf:homepage + will not use the { "@type": "@id" } declaration because + foaf:homepage is not the same as http://xmlns.com/foaf/0.1/homepage. + That is, terms are looked up in a context using + direct string comparison before the prefix lookup mechanism is applied.

+ +
Note

While it is possible to define a compact IRI, or + an absolute IRI to expand to some other unrelated IRI + (for example, foaf:name expanding to + http://example.org/unrelated#species), such usage is strongly + discouraged.

+ +

The only exception for using terms in the context is that + circular definitions are not allowed. That is, + a definition of term1 cannot depend on the + definition of term2 if term2 also depends on + term1. For example, the following context definition + is illegal:

+
Example 47: Illegal circular definition of terms within a context
{
+  "@context": {
+    "term1": "term2:foo",
+    "term2": "term1:bar"
+  },
+  ...
+}
+
+ +
+

4.12 Sets and Lists §

This section is non-normative.

+ +

A JSON-LD author can express multiple values in a compact way by using + arrays. Since graphs do not describe ordering for links + between nodes, arrays in JSON-LD do not provide an ordering of the + contained elements by default. This is exactly the opposite from regular JSON + arrays, which are ordered by default. For example, consider the following + simple document:

+ +
Example 48: Multiple values with no inherent order
{
+  ...
+  "@id": "http://example.org/people#joebob",
+  "foaf:nick": [ "joe", "bob", "JB" ],
+  ...
+}
+ +

The example shown above would result in the following data being generated, + each relating the node to an individual value, with no inherent order:

+ + + + + + + + + + + + + + + + + + + + + + + + +
SubjectPropertyValue
http://example.org/people#joebobfoaf:nickjoe
http://example.org/people#joebobfoaf:nickbob
http://example.org/people#joebobfoaf:nickJB
+ +

Multiple values may also be expressed using the expanded form:

+ +
Example 49: Using an expanded form to set multiple values
{
+  "@id": "http://example.org/articles/8",
+  "dc:title":  [
+    {
+      "@value": "Das Kapital",
+      "@language": "de"
+    },
+    {
+      "@value": "Capital",
+      "@language": "en"
+    }
+  ]
+}
+ +

The example shown above would generate the following data, again with + no inherent order:

+ + + + + + + + + + + + + + + + + + + + + + +
SubjectPropertyValueLanguage
http://example.org/articles/8dc:titleDas Kapitalde
http://example.org/articles/8dc:titleCapitalen
+ +

Although multiple values of a property are typically of the same type, + JSON-LD places no restriction on this, and a property may have values + of different types:

+ +
Example 50: Multiple array values of different types
{
+  "@id": "http://example.org/people#michael",
+  "dc:name": [
+    "Michael",
+    {"@value": "Mike"},
+    {"@value": "Miguel", "@language": "es"},
+    { "@id": "https://www.wikidata.org/wiki/Q4927524" },
+    42
+  ]
+}
+ +

The example shown above would generate the following data, also with + no inherent order:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SubjectPropertyValueLanguageValue Type
http://example.org/people#michaeldc:nameMichael
http://example.org/people#michaeldc:nameMike
http://example.org/people#michaeldc:nameMigueles
http://example.org/people#michaeldc:namehttps://www.wikidata.org/wiki/Q4927524
http://example.org/people#michaeldc:name42xsd:integer
+ +

As the notion of ordered collections is rather important in data + modeling, it is useful to have specific language support. In JSON-LD, + a list may be represented using the @list keyword as follows:

+
Example 51: An ordered collection of values in JSON-LD
{
+  ...
+  "@id": "http://example.org/people#joebob",
+  "foaf:nick": {
+    "@list": [ "joe", "bob", "jaybee" ]
+  },
+  ...
+}
+ +

This describes the use of this array as being ordered, + and order is maintained when processing a document. If every use of a given multi-valued + property is a list, this may be abbreviated by setting @container + to @list in the context:

+
Example 52: Specifying that a collection is ordered in the context
{
+  "@context": {
+    ...
+    "nick": {
+      "@id": "http://xmlns.com/foaf/0.1/nick",
+      "@container": "@list"
+    }
+  },
+  ...
+  "@id": "http://example.org/people#joebob",
+  "nick": [ "joe", "bob", "jaybee" ],
+  ...
+}
+ +
Note

List of lists in the form of list objects + are not allowed in this version of JSON-LD. This decision was made due to the + extreme amount of added complexity when processing lists of lists.

+ +

While @list is used to describe ordered lists, + the @set keyword is used to describe unordered sets. + The use of @set in the body of a JSON-LD document + is optimized away when processing the document, as it is just syntactic + sugar. However, @set is helpful when used within the context + of a document. + Values of terms associated with an @set or @list container + are always represented in the form of an array, + even if there is just a single value that would otherwise be optimized to + a non-array form in compact form (see + section 4.26 Compacted Document Form). This makes post-processing of + JSON-LD documents easier as the data is always in array form, even if the + array only contains a single value.

+ +
+ +
+

4.13 Reverse Properties §

This section is non-normative.

+ +

JSON-LD serializes directed graphs. That means that + every property points from a node to another node + or value. However, in some cases, it is desirable + to serialize in the reverse direction. Consider for example the case where a person + and its children should be described in a document. If the used vocabulary does not + provide a children property but just a parent + property, every node representing a child would have to + be expressed with a property pointing to the parent as in the following + example.

+ +
Example 53: A document with children linking to their parent
[
+  {
+    "@id": "#homer",
+    "http://example.com/vocab#name": "Homer"
+  }, {
+    "@id": "#bart",
+    "http://example.com/vocab#name": "Bart",
+    "http://example.com/vocab#parent": { "@id": "#homer" }
+  }, {
+    "@id": "#lisa",
+    "http://example.com/vocab#name": "Lisa",
+    "http://example.com/vocab#parent": { "@id": "#homer" }
+  }
+]
+ +

Expressing such data is much simpler by using JSON-LD's @reverse + keyword:

+ +
Example 54: A person and its children using a reverse property
{
+  "@id": "#homer",
+  "http://example.com/vocab#name": "Homer",
+  "@reverse": {
+    "http://example.com/vocab#parent": [
+      {
+        "@id": "#bart",
+        "http://example.com/vocab#name": "Bart"
+      }, {
+        "@id": "#lisa",
+        "http://example.com/vocab#name": "Lisa"
+      }
+    ]
+  }
+}
+ +

The @reverse keyword can also be used in + expanded term definitions + to create reverse properties as shown in the following example:

+ + +
Example 55: Using @reverse to define reverse properties
{
+  "@context": { "name": "http://example.com/vocab#name",
+    "children": { "@reverse": "http://example.com/vocab#parent" }
+  },
+  "@id": "#homer",
+  "name": "Homer",
+  "children": [
+    {
+      "@id": "#bart",
+      "name": "Bart"
+    }, {
+      "@id": "#lisa",
+      "name": "Lisa"
+    }
+  ]
+}
+
+ +
+

4.14 Scoped Contexts §

This section is non-normative.

+ +

An expanded term definition can include a @context + property, which defines a context (an embedded context) for values of properties defined using that term. This allows + values to use term definitions, base IRI, + vocabulary mapping or default language which is different from the + node object they are contained in, as if the + context was specified within the value itself.

+ +
Example 56: Defining an @context within a term definition
{
+  "@context": {
+    "@version": 1.1,
+    "name": "http://schema.org/name",
+    "interest": {
+      "@id": "http://xmlns.com/foaf/0.1/interest",
+      "@context": {"@vocab": "http://xmlns.com/foaf/0.1/"}
+    }
+  },
+  "name": "Manu Sporny",
+  "interest": {
+    "@id": "https://www.w3.org/TR/json-ld/",
+    "name": "JSON-LD",
+    "topic": "Linking Data"
+  }
+}
+ +

In this case, the social profile is defined using the schema.org vocabulary, but interest is imported from FOAF, and is used to define a node describing one of Manu's interests where those properties now come from the FOAF vocabulary.

+ +

Expanding this document, uses a combination of terms defined in the outer context, and those defined specifically for that term in an embedded context.

+ +
Example 57: Expanded document using a scoped context
[{
+  "http://schema.org/name": [{"@value": "Manu Sporny"}],
+  "http://xmlns.com/foaf/0.1/interest": [{
+    "@id": "https://www.w3.org/TR/json-ld/",
+    "http://schema.org/name": [{"@value": "JSON-LD"}],
+    "http://xmlns.com/foaf/0.1/topic": [{"@value": "Linking Data"}]
+  }]
+}]
+ +

Scoping can also be performed using a term used as a value of @type:

+ +
Example 58: Defining an @context within a term definition used on @type
{
+  "@context": {
+    "@version": 1.1,
+    "name": "http://schema.org/name",
+    "interest": "http://xmlns.com/foaf/0.1/interest",
+    "Document": {
+      "@id": "http://xmlns.com/foaf/0.1/Document",
+      "@context": {"@vocab": "http://xmlns.com/foaf/0.1/"}
+    }
+  },
+  "@type": "Person",
+  "name": "Manu Sporny",
+  "interest": {
+    "@id": "https://www.w3.org/TR/json-ld/",
+    "@type": "Document",
+    "name": "JSON-LD",
+    "topic": "Linking Data"
+  }
+}
+ +

Scoping on @type is useful when common properties are used to + relate things of different types, where the vocabularies in use within + different entities calls for different context scoping. For example, + hasPart/partOf may be common terms used in a document, but mean + different things depending on the context.

+ +

When expanding, each value of @type is considered + (ordering them lexographically) where that value is also a term in + the active context having its own embedded context. If so, that + embedded context is applied to the active context. When compacting, if + a term is chosen to represent an IRI used as a value of @type where that + term definition also has an embedded context, it is then applied to the + active context to affect further compaction.

+ +
Note

The values of @type are unordered, so if multiple + types are listed, the order that scoped contexts are applied is based on + lexicographical ordering.

+ +
Note

If a term defines a scoped context, and then that term + is later re-defined, the association of the context defined in the earlier + expanded term definition is lost + within the scope of that re-definition. This is consistent with + term definitions of a term overriding previous term definitions from + earlier less deeply nested definitions, as discussed in + section 4.8 Advanced Context Usage.

+ +
Note

Scoped Contexts are a new feature in JSON-LD 1.1, requiring + processing mode set to json-ld-1.1.

+
+ + +
+

4.15 Named Graphs §

This section is non-normative.

+ +

At times, it is necessary to make statements about a graph + itself, rather than just a single node. This can be done by + grouping a set of nodes using the @graph + keyword. A developer may also name data expressed using the + @graph keyword by pairing it with an + @id keyword as shown in the following example:

+ +
Example 59: Identifying and making statements about a graph
{
+  "@context": {
+    "generatedAt": {
+      "@id": "http://www.w3.org/ns/prov#generatedAtTime",
+      "@type": "http://www.w3.org/2001/XMLSchema#date"
+    },
+    "Person": "http://xmlns.com/foaf/0.1/Person",
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows"
+  },
+  "@id": "_:graph",
+  "generatedAt": "2012-04-09",
+  "@graph": [
+    {
+      "@id": "http://manu.sporny.org/about#manu",
+      "@type": "Person",
+      "name": "Manu Sporny",
+      "knows": "http://greggkellogg.net/foaf#me"
+    }, {
+      "@id": "http://greggkellogg.net/foaf#me",
+      "@type": "Person",
+      "name": "Gregg Kellogg",
+      "knows": "http://manu.sporny.org/about#manu"
+    }
+  ]
+}
+ +

The example above expresses a named graph that is identified + by the Blank Node identifier _:graph. That + graph is composed of the statements about Manu and Gregg. Metadata about + the graph itself is expressed via the generatedAt property, + which specifies when the graph was generated. An alternative view of the + information above is represented in table form below:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
GraphSubjectPropertyValueValue Type
 _:graphprov:generatedAtTime2012-04-09xsd:date
_:graphhttp://manu.sporny.org/about#manuxsd:typefoaf:Person
_:graphhttp://manu.sporny.org/about#manufoaf:nameManu Sporny
_:graphhttp://manu.sporny.org/about#manufoaf:knowshttp://greggkellogg.net/foaf#me
_:graphhttp://greggkellogg.net/foaf#mexsd:typefoaf:Person
_:graphhttp://greggkellogg.net/foaf#mefoaf:nameGregg Kellogg
_:graphhttp://greggkellogg.net/foaf#mefoaf:knowshttp://manu.sporny.org/about#manu
+ +

When a JSON-LD document's top-level structure is an + object that contains no other + properties than @graph and + optionally @context (properties that are not mapped to an + IRI or a keyword are ignored), + @graph is considered to express the otherwise implicit + default graph. This mechanism can be useful when a number + of nodes exist at the document's top level that + share the same context, which is, e.g., the case when a + document is flattened. The + @graph keyword collects such nodes in an array + and allows the use of a shared context.

+ +
Example 60: Using @graph to explicitly express the default graph
{
+  "@context": {...},
+  "@graph": [
+    {
+      "@id": "http://manu.sporny.org/about#manu",
+      "@type": "foaf:Person",
+      "name": "Manu Sporny",
+      "knows": "http://greggkellogg.net/foaf#me"
+    }, {
+      "@id": "http://greggkellogg.net/foaf#me",
+      "@type": "foaf:Person",
+      "name": "Gregg Kellogg",
+      "knows": "http://manu.sporny.org/about#manu"
+    }
+  ]
+}
+ +

In this case, embedding doesn't work as each node object + references the other. This is equivalent to using multiple + node objects in array and defining + the @context within each node object:

+ +
Example 61: Context needs to be duplicated if @graph is not used
[
+  {
+    "@context": {...},
+    "@id": "http://manu.sporny.org/about#manu",
+    "@type": "foaf:Person",
+    "name": "Manu Sporny",
+    "knows": "http://greggkellogg.net/foaf#me"
+  },
+  {
+    "@context": {...},
+    "@id": "http://greggkellogg.net/foaf#me",
+    "@type": "foaf:Person",
+    "name": "Gregg Kellogg",
+    "knows": "http://manu.sporny.org/about#manu"
+  }
+]
+ +
+

4.15.1 Graph Containers §

+

In some cases, it is useful to logically partition data into separate + graphs, without making this explicit within the JSON expression. For + example, a JSON document may contain data against which other metadata is + asserted and it is useful to separate this data in the data model using + the notion of named graphs, without the syntactic overhead + associated with the @graph keyword.

+ +

An expanded term definition can use @graph as the + value of @container. This indicates that values of this + term should be considered to be named graphs, where the + graph name is an automatically assigned blank node identifier + creating an implicitly named graph. When expanded, these become + simple graph objects.

+ +

An alternative to our example above could use an anonymously named graph + as follows:

+ +
Example 62: Implicitly named graph
{
+  "@context": {
+    "@version": 1.1,
+    "generatedAt": {
+      "@id": "http://www.w3.org/ns/prov#generatedAtTime",
+      "@type": "http://www.w3.org/2001/XMLSchema#date"
+    },
+    "Person": "http://xmlns.com/foaf/0.1/Person",
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows",
+    "claim": {
+     "@id": "https://w3id.org/credentials#claim",
+      "@container": "@graph"
+    }
+  },
+  "generatedAt": "2012-04-09",
+  "claim": [
+    {
+      "@id": "http://manu.sporny.org/about#manu",
+      "@type": "Person",
+      "name": "Manu Sporny",
+      "knows": "http://greggkellogg.net/foaf#me"
+    }, {
+      "@id": "http://greggkellogg.net/foaf#me",
+      "@type": "Person",
+      "name": "Gregg Kellogg",
+      "knows": "http://manu.sporny.org/about#manu"
+    }
+  ]
+}
+ +

The example above expresses a named graph that is identified + by the blank node identifier _:claim. That + graph is composed of the statements about Manu and Gregg. Metadata about + the graph itself is expressed via the generatedAt property, + which specifies when the graph was generated. An alternative view of the + information above is represented in table form below:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
GraphSubjectPropertyValueValue Type
 _:metadataprov:generatedAtTime2012-04-09xsd:date
 _:metadatacred:claim_:claim
_:claimhttp://manu.sporny.org/about#manuxsd:typefoaf:Person
_:claimhttp://manu.sporny.org/about#manufoaf:nameManu Sporny
_:claimhttp://manu.sporny.org/about#manufoaf:knowshttp://greggkellogg.net/foaf#me
_:claimhttp://greggkellogg.net/foaf#mexsd:typefoaf:Person
_:claimhttp://greggkellogg.net/foaf#mefoaf:nameGregg Kellogg
_:claimhttp://greggkellogg.net/foaf#mefoaf:knowshttp://manu.sporny.org/about#manu
+ +

Expanding this graph results in the following:

+ +
Example 63: Implicitly named graph after expansion
[{
+  "http://www.w3.org/ns/prov#generatedAtTime": [{
+    "@value": "2012-04-09",
+    "@type": "http://www.w3.org/2001/XMLSchema#date"
+  }],
+  "https://w3id.org/credentials#claim": [{
+    "@graph": [{
+      "@id": "http://manu.sporny.org/about#manu",
+      "@type": ["http://xmlns.com/foaf/0.1/Person"],
+      "http://xmlns.com/foaf/0.1/knows": [{
+        "@value": "http://greggkellogg.net/foaf#me"
+      }],
+      "http://xmlns.com/foaf/0.1/name": [{
+        "@value": "Manu Sporny"
+      }]
+    }, {
+      "@id": "http://greggkellogg.net/foaf#me",
+      "@type": ["http://xmlns.com/foaf/0.1/Person"],
+      "http://xmlns.com/foaf/0.1/knows": [{
+        "@value": "http://manu.sporny.org/about#manu"
+      }],
+      "http://xmlns.com/foaf/0.1/name": [{
+        "@value": "Gregg Kellogg"
+      }]
+    }]
+  }]
+}]
+ +
Note

Strictly speaking, the value of such a term + is not a named graph, rather it is the graph name + associated with the named graph, which exists separately within + the dataset.

+ +
Note

Graph Containers are a new feature in JSON-LD 1.1, requiring + processing mode set to json-ld-1.1.

+
+
+ +
+

4.16 Identifying Blank Nodes §

This section is non-normative.

+ +

At times, it becomes necessary to be able to express information without + being able to uniquely identify the node with an IRI. + This type of node is called a blank node. JSON-LD does not require + all nodes to be identified using @id. However, some graph topologies + may require identifiers to be serializable. Graphs containing loops, e.g., cannot + be serialized using embedding alone, @id must be used to connect the nodes. + In these situations, one can use blank node identifiers, + which look like IRIs using an underscore (_) + as scheme. This allows one to reference the node locally within the document, but + makes it impossible to reference the node from an external document. The + blank node identifier is scoped to the document in which it is used.

+ +
Example 64: Specifying a local blank node identifier
{
+   ...
+   "@id": "_:n1",
+   "name": "Secret Agent 1",
+   "knows": {
+     "name": "Secret Agent 2",
+     "knows": { "@id": "_:n1" }
+   }
+}
+ +

The example above contains information about two secret agents that cannot be identified + with an IRI. While expressing that agent 1 knows agent 2 + is possible without using blank node identifiers, + it is necessary to assign agent 1 an identifier so that it can be referenced + from agent 2.

+

It is worth noting that blank node identifiers may be relabeled during processing. + If a developer finds that they refer to the blank node more than once, + they should consider naming the node using a dereferenceable IRI so that + it can also be referenced from other documents.

+
+ +
+

4.17 Aliasing Keywords §

This section is non-normative.

+ +

Each of the JSON-LD keywords, + except for @context, may be aliased to application-specific + keywords. This feature allows legacy JSON content to be utilized + by JSON-LD by re-using JSON keys that already exist in legacy documents. + This feature also allows developers to design domain-specific implementations + using only the JSON-LD context.

+ +
Example 65: Aliasing keywords
{
+  "@context": {
+    "url": "@id",
+    "a": "@type",
+    "name": "http://xmlns.com/foaf/0.1/name"
+  },
+  "url": "http://example.com/about#gregg",
+  "a": "http://xmlns.com/foaf/0.1/Person",
+  "name": "Gregg Kellogg"
+}
+ +

In the example above, the @id and @type + keywords have been given the aliases + url and a, respectively.

+ +

Since keywords cannot be redefined, they can also not be aliased to + other keywords.

+
+ +
+

4.18 Data Indexing §

This section is non-normative.

+ +

Databases are typically used to make access to + data more efficient. Developers often extend this sort of functionality into + their application data to deliver similar performance gains. Often this + data does not have any meaning from a Linked Data standpoint, but is + still useful for an application.

+ +

JSON-LD introduces the notion of index maps + that can be used to structure data into a form that is + more efficient to access. The data indexing feature allows an author to + structure data using a simple key-value map where the keys do not map + to IRIs. This enables direct access to data + instead of having to scan an array in search of a specific item. + In JSON-LD such data can be specified by associating the + @index keyword with a + @container declaration in the context:

+ +
Example 66: Indexing data in JSON-LD
{
+  "@context": {
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "body": "schema:articleBody",
+    "words": "schema:wordCount",
+    "post": {
+      "@id": "schema:blogPost",
+      "@container": "@index"
+    }
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+    "en": {
+      "@id": "http://example.com/posts/1/en",
+      "body": "World commodities were up today with heavy trading of crude oil...",
+      "words": 1539
+    },
+    "de": {
+      "@id": "http://example.com/posts/1/de",
+      "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+      "words": 1204
+    }
+  }
+}
+ +

In the example above, the post term has + been marked as an index map. The en and + de keys will be ignored semantically, but preserved + syntactically, by the JSON-LD Processor. This allows a developer to + access the German version of the post using the + following code snippet: obj.post.de.

+ +

The interpretation of the data above is expressed in + the table below. Note how the index keys do not appear in the Linked Data + below, but would continue to exist if the document were compacted or + expanded (see section 4.26 Compacted Document Form and + section 4.25 Expanded Document Form) using a JSON-LD processor:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SubjectPropertyValue
http://example.com/rdf:typeschema:Blog
http://example.com/schema:nameWorld Financial News
http://example.com/schema:blogPosthttp://example.com/posts/1/en
http://example.com/schema:blogPosthttp://example.com/posts/1/de
http://example.com/posts/1/enschema:articleBodyWorld commodities were up today with heavy trading of crude oil...
http://example.com/posts/1/enschema:wordCount1539
http://example.com/posts/1/deschema:articleBodyDie Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...
http://example.com/posts/1/deschema:wordCount1204
+ +

The value of @container can also + be an array containing both @index and @set. + When compacting, this ensures that a JSON-LD Processor will use + the array form for all values of indexes.

+ +
Example 67: Indexing data in JSON-LD with @set representation
{
+  "@context": {
+    "@version": 1.1,
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "body": "schema:articleBody",
+    "words": "schema:wordCount",
+    "post": {
+      "@id": "schema:blogPost",
+      "@container": ["@index", "@set"]
+    }
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+    "en": [{
+      "@id": "http://example.com/posts/1/en",
+      "body": "World commodities were up today with heavy trading of crude oil...",
+      "words": 1539
+    }],
+    "de": [{
+      "@id": "http://example.com/posts/1/de",
+      "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+      "words": 1204
+    }]
+  }
+}
+ +

If the processing mode is set to json-ld-1.1, + the special index @none is used for indexing + data which does not have an associated index, which is useful to maintain + a normalized representation.

+ +
Example 68: Indexing data using @none
{
+  "@context": {
+     "schema": "http://schema.org/",
+     "name": "schema:name",
+     "body": "schema:articleBody",
+     "words": "schema:wordCount",
+     "post": {
+       "@id": "schema:blogPost",
+       "@container": "@index"
+     }
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+    "en": {
+      "@id": "http://example.com/posts/1/en",
+      "body": "World commodities were up today with heavy trading of crude oil...",
+      "words": 1539
+    },
+    "de": {
+      "@id": "http://example.com/posts/1/de",
+      "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+      "words": 1204
+    },
+    "@none": {
+      "body": "Unindexed description",
+      "words": 20
+    }
+  }
+}
+
+
+

4.19 Named Graph Indexing §

+ +

In addition to indexing node objects by index, graph objects may + also be indexed by an index. By using the @graph + container type, introduced in section 4.15.1 Graph Containers + in addition to @index, an object value of such a property is + treated as a key-value map where the keys do not map to IRIs, but + are taken from an @index property associated with named graphs + which are their values. When expanded, these must be simple graph objects

+ +

The following example describes a default graph referencing multiple named + graphs using an index map.

+ +
Example 69: Indexing graph data in JSON-LD
{
+  "@context": {
+     "@version": 1.1,
+     "schema": "http://schema.org/",
+     "name": "schema:name",
+     "body": "schema:articleBody",
+     "words": "schema:wordCount",
+     "post": {
+       "@id": "schema:blogPost",
+       "@container": ["@graph", "@index"]
+     }
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+     "en": {
+       "@id": "http://example.com/posts/1/en",
+       "body": "World commodities were up today with heavy trading of crude oil...",
+       "words": 1539
+     },
+     "de": {
+       "@id": "http://example.com/posts/1/de",
+       "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+       "words": 1204
+     }
+  }
+}
+ +

This expands to the following:

+ +
Example 70: Indexed graph data after expansion
[{
+  "@id": "http://example.com/",
+  "@type": ["http://schema.org/Blog"],
+  "http://schema.org/blogPost": [{
+    "@graph": [{
+      "@id": "http://example.com/posts/1/de",
+      "http://schema.org/articleBody": [{
+        "@value": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl..."
+      }],
+      "http://schema.org/wordCount": [{"@value": 1204}]
+    }],
+    "@index": "de"
+  }, {
+    "@graph": [{
+      "@id": "http://example.com/posts/1/en",
+      "http://schema.org/articleBody": [{
+        "@value": "World commodities were up today with heavy trading of crude oil..."
+      }],
+      "http://schema.org/wordCount": [{"@value": 1539}]
+    }],
+    "@index": "en"
+  }],
+  "http://schema.org/name": [{"@value": "World Financial News"}]
+}]
+ +

When expressed as Quads, this becomes the following:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
GraphSubjectPropertyValueValue Type
 http://example.com/rdf:typeschema:Blog
 http://example.com/schema:nameWorld Financial News
 http://example.com/schema:blogPost_:b1
 http://example.com/schema:blogPost_:b2
_:b1http://example.com/posts/1/deschema:wordCount1204xsd:integer
_:b1http://example.com/posts/1/deschema:articleBodyDie Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...
_:b2http://example.com/posts/1/enschema:wordCount1539xsd:integer
_:b2http://example.com/posts/1/enschema:articleBodyWorld commodities were up today with heavy trading of crude oil...
+ +

As with index maps, when used with @graph, a container may also + include @set to ensure that key values are always contained in an array.

+ +

If the processing mode is set to json-ld-1.1, + the special index @none is used for indexing + graphs which does not have an @index key, which is useful to maintain + a normalized representation. Note, however, that + compacting a document where multiple unidentified named graphs are + compacted using the @none index will result in the content + of those graphs being merged. To prevent this, give each graph a distinct + @index key.

+ +
Example 71: Indexing graphs using @none for no index
{
+  "@context": {
+     "@version": 1.1,
+     "schema": "http://schema.org/",
+     "name": "schema:name",
+     "body": "schema:articleBody",
+     "words": "schema:wordCount",
+     "post": {
+       "@id": "schema:blogPost",
+       "@container": ["@graph", "@index"]
+     }
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+     "en": {
+       "@id": "http://example.com/posts/1/en",
+       "body": "World commodities were up today with heavy trading of crude oil...",
+       "words": 1539
+     },
+     "@none": {
+       "@id": "http://example.com/posts/1/de",
+       "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+       "words": 1204
+     }
+  }
+}
+ +

This expands to the following:

+ +
Example 72: Indexed languaged-tagged strings with @none after expansion
[{
+  "@id": "http://example.com/",
+  "@type": ["http://schema.org/Blog"],
+  "http://schema.org/blogPost": [{
+    "@graph": [{
+      "@id": "http://example.com/posts/1/de",
+      "http://schema.org/articleBody": [{
+        "@value": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl..."
+      }],
+      "http://schema.org/wordCount": [{"@value": 1204}]
+    }]
+  }, {
+    "@graph": [{
+      "@id": "http://example.com/posts/1/en",
+      "http://schema.org/articleBody": [{
+        "@value": "World commodities were up today with heavy trading of crude oil..."
+      }],
+      "http://schema.org/wordCount": [{"@value": 1539}]
+    }],
+    "@index": "en"
+  }],
+  "http://schema.org/name": [{"@value": "World Financial News"}]
+}]
+
+ +
+

4.20 Language Indexing §

This section is non-normative.

+ +

JSON which includes string values in multiple languages may be + represented using a language map to allow for easily + indexing property values by language tag. This enables direct access to + language values instead of having to scan an array in search of a specific item. + In JSON-LD such data can be specified by associating the + @language keyword with a + @container declaration in the context:

+ +
Example 73: Indexing languaged-tagged strings in JSON-LD
{
+  "@context": {
+    "vocab": "http://example.com/vocab/",
+    "label": {
+      "@id": "vocab:label",
+      "@container": "@language"
+    }
+  },
+  "@id": "http://example.com/queen",
+  "label": {
+    "en": "The Queen",
+    "de": [ "Die Königin", "Ihre Majestät" ]
+  }
+}
+ +

In the example above, the label term has + been marked as an language map. The en and + de keys are implicitly associated with their respective + values by the JSON-LD Processor. This allows a developer to + access the German version of the label using the + following code snippet: obj.label.de.

+ +

The value of @container can also + be an array containing both @language and @set. + When compacting, this ensures that a JSON-LD Processor will use + the array form for all values of language tags.

+ +
Example 74: Indexing languaged-tagged strings in JSON-LD with @set representation
{
+  "@context": {
+    "vocab": "http://example.com/vocab/",
+    "label": {
+      "@id": "vocab:label",
+      "@container": ["@language", "@set"]
+    }
+  },
+  "@id": "http://example.com/queen",
+  "label": {
+    "en": ["The Queen"],
+    "de": [ "Die Königin", "Ihre Majestät" ]
+  }
+}
+ +

If the processing mode is set to json-ld-1.1, + the special index @none is used for indexing + data which does not have a language, which is useful to maintain + a normalized representation.

+ +
Example 75: Indexing languaged-tagged strings using @none for no language
{
+  "@context": {
+    "vocab": "http://example.com/vocab/",
+    "label": {
+      "@id": "vocab:label",
+      "@container": "@language"
+    }
+  },
+  "@id": "http://example.com/queen",
+  "label": {
+    "en": "The Queen",
+    "de": [ "Die Königin", "Ihre Majestät" ],
+    "@none": "The Queen"
+  }
+}
+
+ +
+

4.21 Node Identifier Indexing §

This section is non-normative.

+ +

In addition to index maps, JSON-LD introduces the notion of id maps + for structuring data. The id indexing feature allows an author to + structure data using a simple key-value map where the keys map + to IRIs. This enables direct access to associated node objects + instead of having to scan an array in search of a specific item. + In JSON-LD such data can be specified by associating the + @id keyword with a + @container declaration in the context:

+ +
Example 76: Indexing data in JSON-LD by node identifiers
{
+  "@context": {
+    "@version": 1.1,
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "body": "schema:articleBody",
+    "words": "schema:wordCount",
+    "post": {
+      "@id": "schema:blogPost",
+      "@container": "@id"
+    }
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+    "http://example.com/posts/1/en": {
+      "body": "World commodities were up today with heavy trading of crude oil...",
+      "words": 1539
+    },
+    "http://example.com/posts/1/de": {
+      "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+      "words": 1204
+    }
+  }
+}
+ +

In the example above, the post term has + been marked as an id map. The http://example.com/posts/1/en and + http://example.com/posts/1/de keys will be interpreted + as the @id property of the node object value.

+ +

The interpretation of the data above is exactly the same + as that in section 4.18 Data Indexing + using a JSON-LD processor.

+ +

The value of @container can also + be an array containing both @id and @set. + When compacting, this ensures that a JSON-LD processor will use + the array form for all values of node identifiers.

+ +
Example 77: Indexing data in JSON-LD by node identifiers with @set representation
{
+  "@context": {
+    "@version": 1.1,
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "body": "schema:articleBody",
+    "words": "schema:wordCount",
+    "post": {
+      "@id": "schema:blogPost",
+      "@container": ["@id", "@set"]
+    }
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+    "http://example.com/posts/1/en": [{
+      "body": "World commodities were up today with heavy trading of crude oil...",
+      "words": 1539
+    }],
+    "http://example.com/posts/1/de": [{
+      "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+      "words": 1204
+    }]
+  }
+}
+ +

The special index @none is used for indexing + node objects which do not have an @id, which is useful to maintain + a normalized representation. The @none index may also be + a term which expands to @none, such as the term none + used in the example below.

+ +
Example 78: Indexing data in JSON-LD by node identifiers using @none
{
+  "@context": {
+    "@version": 1.1,
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "body": "schema:articleBody",
+    "words": "schema:wordCount",
+    "post": {
+      "@id": "schema:blogPost",
+      "@container": "@id"
+    },
+    "none": "@none"
+  },
+  "@id": "http://example.com/",
+  "@type": "schema:Blog",
+  "name": "World Financial News",
+  "post": {
+    "http://example.com/posts/1/en": {
+      "body": "World commodities were up today with heavy trading of crude oil...",
+      "words": 1539
+    },
+    "http://example.com/posts/1/de": {
+      "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
+      "words": 1204
+    },
+    "none": {
+      "body": "Description for object within an @id",
+      "words": 20
+    }
+  }
+}
+ +
Note

Id maps are a new feature in JSON-LD 1.1, requiring + processing mode set to json-ld-1.1.

+
+ +
+

4.22 Named Graph Indexing by Identifier §

+ +

In addition to indexing node objects by identifier, graph objects may + also be indexed by their graph name. By using the @graph + container type, introduced in section 4.15.1 Graph Containers + in addition to @id, an object value of such a property is + treated as a key-value map where the keys represent the identifiers of named graphs + which are their values.

+ +

The following example describes a default graph referencing multiple named + graphs using an id map.

+ +
Example 79: Referencing named graphs using an id map
{
+  "@context": {
+    "@version": 1.1,
+    "generatedAt": {
+      "@id": "http://www.w3.org/ns/prov#generatedAtTime",
+      "@type": "http://www.w3.org/2001/XMLSchema#date"
+    },
+    "Person": "http://xmlns.com/foaf/0.1/Person",
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows",
+    "graphMap": {
+      "@id": "http://example.org/graphMap",
+      "@container": ["@graph", "@id"]
+    }
+  },
+  "@id": "_:graph",
+  "generatedAt": "2012-04-09",
+  "graphMap": {
+    "_:manu": {
+      "@id": "http://manu.sporny.org/about#manu",
+      "@type": "Person",
+      "name": "Manu Sporny",
+      "knows": "http://greggkellogg.net/foaf#me"
+    },
+    "_:gregg": {
+      "@id": "http://greggkellogg.net/foaf#me",
+      "@type": "Person",
+      "name": "Gregg Kellogg",
+      "knows": "http://manu.sporny.org/about#manu"
+    }
+  }
+}
+ +

This expands to the following:

+ +
Example 80: Referencing named graphs after expansion
[{
+  "@id": "_:graph",
+  "http://example.org/graphMap": [{
+    "@id": "_:gregg",
+    "@graph": [{
+      "@id": "http://greggkellogg.net/foaf#me",
+      "@type": ["http://xmlns.com/foaf/0.1/Person"],
+      "http://xmlns.com/foaf/0.1/knows": [{"@value": "http://manu.sporny.org/about#manu"}],
+      "http://xmlns.com/foaf/0.1/name": [{"@value": "Gregg Kellogg"}]
+    }]
+  }, {
+    "@id": "_:manu",
+    "@graph": [{
+      "@id": "http://manu.sporny.org/about#manu",
+      "@type": [
+        "http://xmlns.com/foaf/0.1/Person"
+      ],
+      "http://xmlns.com/foaf/0.1/knows": [
+        {
+          "@value": "http://greggkellogg.net/foaf#me"
+        }
+      ],
+      "http://xmlns.com/foaf/0.1/name": [
+        {
+          "@value": "Manu Sporny"
+        }
+      ]
+    }]
+  }],
+  "http://www.w3.org/ns/prov#generatedAtTime": [{
+    "@value": "2012-04-09",
+    "@type": "http://www.w3.org/2001/XMLSchema#date"
+  }]
+}]
+ +

When expressed as Quads, this becomes the following:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
GraphSubjectPropertyValueValue Type
 _:graphprov:generatedAtTime2012-04-09xsd:date
 _:graphhttp://example.org/graphMaphttp://manu.sporny.org/about#manu
 _:graphhttp://example.org/graphMaphttp://greggkellogg.net/foaf#me
_:manuhttp://manu.sporny.org/about#manuxsd:typefoaf:Person
_:manuhttp://manu.sporny.org/about#manufoaf:nameManu Sporny
_:manuhttp://manu.sporny.org/about#manufoaf:knowshttp://greggkellogg.net/foaf#me
_:gregghttp://greggkellogg.net/foaf#mexsd:typefoaf:Person
_:gregghttp://greggkellogg.net/foaf#mefoaf:nameGregg Kellogg
_:gregghttp://greggkellogg.net/foaf#mefoaf:knowshttp://manu.sporny.org/about#manu
+ +

As with id maps, when used with @graph, a container may also + include @set to ensure that key values are always contained in an array.

+ +

As with id maps, the special index @none is used for indexing + named graphs which do not have an @id, which is useful to maintain + a normalized representation. The @none index may also be + a term which expands to @none. + Note, however, that if multiple graphs are represented without + an @id, they will be merged on expansion. To prevent this, + use @none judiciously, and consider giving graphs + their own distinct identifier.

+ +
Example 81: Referencing named graphs using an id map with @none
{
+  "@context": {
+    "@version": 1.1,
+    "generatedAt": {
+      "@id": "http://www.w3.org/ns/prov#generatedAtTime",
+      "@type": "http://www.w3.org/2001/XMLSchema#date"
+    },
+    "Person": "http://xmlns.com/foaf/0.1/Person",
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows",
+    "graphMap": {
+      "@id": "http://example.org/graphMap",
+      "@container": ["@graph", "@id"]
+    }
+  },
+  "@id": "_:graph",
+  "generatedAt": "2012-04-09",
+  "graphMap": {
+    "@none": [{
+      "@id": "http://manu.sporny.org/about#manu",
+      "@type": "Person",
+      "name": "Manu Sporny",
+      "knows": "http://greggkellogg.net/foaf#me"
+    }, {
+      "@id": "http://greggkellogg.net/foaf#me",
+      "@type": "Person",
+      "name": "Gregg Kellogg",
+      "knows": "http://manu.sporny.org/about#manu"
+    }]
+  }
+}
+ +
Note

Graph Containers are a new feature in JSON-LD 1.1, requiring + processing mode set to json-ld-1.1.

+
+ +
+

4.23 Node Type Indexing §

This section is non-normative.

+ +

In addition to id and index maps, JSON-LD introduces the notion of type maps + for structuring data. The type indexing feature allows an author to + structure data using a simple key-value map where the keys map + to IRIs. This enables data to be structured based on the @type + of specific node objects. + In JSON-LD such data can be specified by associating the + @type keyword with a + @container declaration in the context:

+ +
Example 82: Indexing data in JSON-LD by type
{
+  "@context": {
+    "@version": 1.1,
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "affiliation": {
+      "@id": "schema:affiliation",
+      "@container": "@type"
+    }
+  },
+  "name": "Manu Sporny",
+  "affiliation": {
+    "schema:Corporation": {
+      "@id": "https://digitalbazaar.com/",
+      "name": "Digital Bazaar"
+    },
+    "schema:ProfessionalService": {
+      "@id": "https://spec-ops.io",
+      "name": "Spec-Ops"
+    }
+  }
+}
+ +

In the example above, the affiliation term has + been marked as an type map. The schema:Corporation and + schema:ProfessionalService keys will be interpreted + as the @type property of the node object value.

+ +

The value of @container can also + be an array containing both @type and @set. + When compacting, this ensures that a JSON-LD processor will use + the array form for all values of types.

+ +
Example 83: Indexing data in JSON-LD by type with @set representation
{
+  "@context": {
+    "@version": 1.1,
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "affiliation": {
+      "@id": "schema:affiliation",
+      "@container": ["@type", "@set"]
+    }
+  },
+  "name": "Manu Sporny",
+  "affiliation": {
+    "schema:Corporation": [{
+      "@id": "https://digitalbazaar.com/",
+      "name": "Digital Bazaar"
+    }],
+    "schema:ProfessionalService": [{
+      "@id": "https://spec-ops.io",
+      "name": "Spec-Ops"
+    }]
+  }
+}
+ +

The special index @none is used for indexing + node objects which do not have an @type, which is useful to maintain + a normalized representation. The @none index may also be + a term which expands to @none, such as the term none + used in the example below.

+ +
Example 84: Indexing data in JSON-LD by type using @none
{
+  "@context": {
+    "@version": 1.1,
+    "schema": "http://schema.org/",
+    "name": "schema:name",
+    "affiliation": {
+      "@id": "schema:affiliation",
+      "@container": "@type"
+    },
+    "none": "@none"
+  },
+  "name": "Manu Sporny",
+  "affiliation": {
+    "schema:Corporation": {
+      "@id": "https://digitalbazaar.com/",
+      "name": "Digital Bazaar"
+    },
+    "schema:ProfessionalService": {
+      "@id": "https://spec-ops.io",
+      "name": "Spec-Ops"
+    },
+    "none": {
+      "@id": "http://greggkellogg.net/",
+      "name": "Gregg Kellogg"
+    }
+  }
+}
+ +

As with id maps, when used with @type, a container may also + include @set to ensure that key values are always contained in an array.

+ +
Note

Type maps are a new feature in JSON-LD 1.1, requiring + processing mode set to json-ld-1.1.

+
+ +
+

4.24 Nested Properties §

This section is non-normative.

+ +

Many JSON APIs separate properties from their entities using an + intermediate object; in JSON-LD these are called nested properties. + For example, a set of possible labels may be grouped + under a common property:

+
Example 85: Nested properties
{
+  "@context": {
+    "@version": 1.1,
+    "skos": "http://www.w3.org/2004/02/skos/core#",
+    "labels": "@nest",
+    "main_label": {"@id": "skos:prefLabel"},
+    "other_label": {"@id": "skos:altLabel"},
+    "homepage": {"@id": "http://schema.org/description", "@type": "@id"}
+  },
+  "@id": "http://example.org/myresource",
+  "homepage": "http://example.org",
+  "labels": {
+     "main_label": "This is the main label for my resource",
+     "other_label": "This is the other label"
+  }
+}
+ +

By defining labels using the keyword @nest, + a JSON-LD processor will ignore the nesting created by using the + labels property and process the contents as if it were declared + directly within containing object. In this case, the labels + property is semantically meaningless. Defining it as equivalent to + @nest causes it to be ignored when expanding, making it + equivalent to the following:

+ +
Example 86: Nested properties folded into containing object
{
+  "@context": {
+    "skos": "http://www.w3.org/2004/02/skos/core#",
+    "main_label": {"@id": "skos:prefLabel"},
+    "other_label": {"@id": "skos:altLabel"},
+    "homepage": {"@id": "http://schema.org/description", "@type": "@id"}
+  },
+  "@id": "http://example.org/myresource",
+  "homepage": "http://example.org",
+  "main_label": "This is the main label for my resource",
+  "other_label": "This is the other label"
+}
+ +

Similarly, node definitions may contain a @nest property to + reference a term aliased to @nest which causes such + values to be nested under that aliased term.

+
Example 87: Defining property nesting
{
+  "@context": {
+    "@version": 1.1,
+    "skos": "http://www.w3.org/2004/02/skos/core#",
+    "labels": "@nest",
+    "main_label": {"@id": "skos:prefLabel", "@nest": "labels"},
+    "other_label": {"@id": "skos:altLabel", "@nest": "labels"},
+    "homepage": {"@id": "http://schema.org/description", "@type": "@id"}
+  },
+  "@id": "http://example.org/myresource",
+  "homepage": "http://example.org",
+  "labels": {
+     "main_label": "This is the main label for my resource",
+     "other_label": "This is the other label"
+  }
+}
+ +
Note

Nested properties are a new feature in JSON-LD 1.1, requiring + processing mode set to json-ld-1.1.

+
+ +
+

4.25 Expanded Document Form §

This section is non-normative.

+ +

The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] + defines a method for expanding a JSON-LD document. + Expansion is the process of taking a JSON-LD document and applying a + @context such that all IRIs, types, and values + are expanded so that the @context is no longer necessary.

+ +

For example, assume the following JSON-LD input document:

+ +
Example 88: Sample JSON-LD document to be expanded
{
+   "@context": {
+      "name": "http://xmlns.com/foaf/0.1/name",
+      "homepage": {
+        "@id": "http://xmlns.com/foaf/0.1/homepage",
+        "@type": "@id"
+      }
+   },
+   "name": "Manu Sporny",
+   "homepage": "http://manu.sporny.org/"
+}
+ +

Running the JSON-LD Expansion algorithm against the JSON-LD input document + provided above would result in the following output:

+ +
Example 89: Expanded form for the previous example
[
+  {
+    "http://xmlns.com/foaf/0.1/name": [
+      { "@value": "Manu Sporny" }
+    ],
+    "http://xmlns.com/foaf/0.1/homepage": [
+      { "@id": "http://manu.sporny.org/" }
+    ]
+  }
+]
+ +

JSON-LD's media type defines a + profile parameter which can be used to signal or request + expanded document form. The profile URI identifying expanded document + form is http://www.w3.org/ns/json-ld#expanded.

+
+ +
+

4.26 Compacted Document Form §

This section is non-normative.

+ +

The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] defines + a method for compacting a JSON-LD document. Compaction is the process + of applying a developer-supplied context to shorten IRIs + to terms or compact IRIs + and JSON-LD values expressed in expanded form to simple values such as + strings or numbers. + Often this makes it simpler to work with document as the data is expressed in + application-specific terms. Compacted documents are also typically easier to read + for humans.

+ +

For example, assume the following JSON-LD input document:

+ +
Example 90: Sample expanded JSON-LD document
[
+  {
+    "http://xmlns.com/foaf/0.1/name": [ "Manu Sporny" ],
+    "http://xmlns.com/foaf/0.1/homepage": [
+      {
+       "@id": "http://manu.sporny.org/"
+      }
+    ]
+  }
+]
+ +

Additionally, assume the following developer-supplied JSON-LD context:

+ +
Example 91: Sample context
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "homepage": {
+      "@id": "http://xmlns.com/foaf/0.1/homepage",
+      "@type": "@id"
+    }
+  }
+}
+ +

Running the JSON-LD Compaction algorithm given the context supplied above + against the JSON-LD input document provided above would result in the following + output:

+ +
Example 92: Compact form of the sample document once sample context has been applied
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "homepage": {
+      "@id": "http://xmlns.com/foaf/0.1/homepage",
+      "@type": "@id"
+    }
+  },
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/"
+}
+ +

JSON-LD's media type defines a + profile parameter which can be used to signal or request + compacted document form. The profile URI identifying compacted document + form is http://www.w3.org/ns/json-ld#compacted.

+
+ +
+

4.27 Flattened Document Form §

This section is non-normative.

+ +

The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] defines + a method for flattening a JSON-LD document. Flattening collects all + properties of a node in a single JSON object and labels + all blank nodes with + blank node identifiers. + This ensures a shape of the data and consequently may drastically simplify the code + required to process JSON-LD in certain applications.

+ +

For example, assume the following JSON-LD input document:

+ +
Example 93: Sample JSON-LD document to be flattened
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows"
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "name": "Markus Lanthaler",
+  "knows": [
+    {
+      "@id": "http://manu.sporny.org/about#manu",
+      "name": "Manu Sporny"
+    }, {
+      "name": "Dave Longley"
+    }
+  ]
+}
+ +

Running the JSON-LD Flattening algorithm against the JSON-LD input document in + the example above and using the same context would result in the following + output:

+ +
Example 94: Flattened and compacted form for the previous example
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows"
+  },
+  "@graph": [
+    {
+      "@id": "_:b0",
+      "name": "Dave Longley"
+    }, {
+      "@id": "http://manu.sporny.org/about#manu",
+      "name": "Manu Sporny"
+    }, {
+      "@id": "http://me.markus-lanthaler.com/",
+      "name": "Markus Lanthaler",
+      "knows": [
+        { "@id": "http://manu.sporny.org/about#manu" },
+        { "@id": "_:b0" }
+      ]
+    }
+  ]
+}
+ +

JSON-LD's media type defines a + profile parameter which can be used to signal or request + flattened document form. The profile URI identifying flattened document + form is http://www.w3.org/ns/json-ld#flattened. It can be + combined with the profile URI identifying + expanded document form or + compacted document from.

+
+ +
+

4.28 Embedding JSON-LD in HTML Documents §

This section is non-normative.

+ +

HTML script tags can be used to embed blocks of data in documents. + This way, JSON-LD content can be easily embedded in HTML by placing + it in a script element with the type attribute set to + application/ld+json.

+ +
Example 95: Embedding JSON-LD in HTML
<script type="application/ld+json">
+{
+  "@context": "https://json-ld.org/contexts/person.jsonld",
+  "@id": "http://dbpedia.org/resource/John_Lennon",
+  "name": "John Lennon",
+  "born": "1940-10-09",
+  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
+}
+</script>
+ +

Depending on how the HTML document is served, certain strings may need + to be escaped.

+ +

Defining how such data may be used is beyond the scope of this specification. + The embedded JSON-LD document might be extracted as is or, e.g., be + interpreted as RDF.

+ +

If JSON-LD content is extracted as RDF [RDF11-CONCEPTS], it should be expanded into an + RDF Dataset using the + Deserialize JSON-LD to RDF Algorithm + [JSON-LD11CG-API].

+
+ +
+ +
+

5. Data Model §

+ +

JSON-LD is a serialization format for Linked Data based on JSON. + It is therefore important to distinguish between the syntax, which is + defined by JSON in [RFC7159], and the data model which is + an extension of the RDF data model [RDF11-CONCEPTS]. The precise + details of how JSON-LD relates to the RDF data model are given in + section 7. Relationship to RDF.

+ +

To ease understanding for developers unfamiliar with the RDF model, the + following summary is provided:

+ + + +

JSON-LD documents MAY contain data + that cannot be represented by the data model + defined above. Unless otherwise specified, such data is ignored when a + JSON-LD document is being processed. One result of this rule + is that properties which are not mapped to an IRI, + a blank node, or keyword will be ignored.

+ +

Additionally, the JSON serialization format is internally represented using + the JSON-LD internal representation, which uses the generic + concepts of arrays, dictionaries, + strings, numbers, booleans, and null to describe + the data represented by a JSON document.

+

An illustration of the data model

+

Figure 1: An illustration of the data model.

+
+ +
+

6. JSON-LD Grammar §

+ +

This appendix restates the syntactic conventions described in the + previous sections more formally.

+ +

A JSON-LD document MUST be valid JSON text as described + in [RFC7159], or some format that can be represented + in the JSON-LD internal representation that is equivalent to + valid JSON text.

+ +

A JSON-LD document MUST be a single node object, + a JSON object consisting of only + the members @context and/or @graph, + or an array or zero or more node objects.

+ +

In contrast to JSON, in JSON-LD the keys in objects + MUST be unique.

+ +
Note

JSON-LD allows keywords to be aliased + (see section 4.17 Aliasing Keywords for details). Whenever a keyword is + discussed in this grammar, the statements also apply to an alias for + that keyword. For example, if the active context + defines the term id as an alias for @id, + that alias may be legitimately used as a substitution for @id. + Note that keyword aliases are not expanded during context + processing.

+ +
+

6.1 Terms §

+ +

A term is a short-hand string that expands + to an IRI or a blank node identifier.

+ +

A term MUST NOT equal any of the JSON-LD + keywords.

+ +

When used as the prefix in a Compact IRI, to avoid + the potential ambiguity of a prefix being confused with an IRI + scheme, terms SHOULD NOT come from the list of URI schemes as defined in + [IANA-URI-SCHEMES]. Similarly, to avoid confusion between a + Compact IRI and a term, terms SHOULD NOT include a colon (:) + and SHOULD be restricted to the form of + isegment-nz-nc + as defined in [RFC3987].

+ +

To avoid forward-compatibility issues, a term SHOULD NOT start + with an @ character as future versions of JSON-LD may introduce + additional keywords. Furthermore, the term MUST NOT + be an empty string ("") as not all programming languages + are able to handle empty JSON keys.

+ +

See section 3.1 The Context and + section 3.2 IRIs for further discussion + on mapping terms to IRIs.

+
+ +
+

6.2 Node Objects §

+ +

A node object represents zero or more properties of a + node in the graph serialized by the + JSON-LD document. A JSON object is a + node object if it exists outside of a JSON-LD + context and:

+ +
    +
  • it is not the top-most JSON object in the JSON-LD document consisting + of no other members than @graph and @context,
    • +
  • it does not contain the @value, @list, + or @set keywords, and
    • +
  • it is not a graph object.
    • +
+ +

The properties of a node in + a graph may be spread among different + node objects within a document. When + that happens, the keys of the different + node objects need to be merged to create the + properties of the resulting node.

+ +

A node object MUST be a JSON object. All keys + which are not IRIs, compact IRIs, terms valid in the + active context, or one of the following keywords + (or alias of such a keyword) + MUST be ignored when processed:

+ +
    +
  • @context,
    • +
  • @id,
    • +
  • @graph,
    • +
  • @nest,
    • +
  • @type,
    • +
  • @reverse, or
    • +
  • @index
    • +
+ +

If the node object contains the @context + key, its value MUST be null, an absolute IRI, + a relative IRI, a context definition, or + an array composed of any of these.

+ +

If the node object contains the @id key, + its value MUST be an absolute IRI, a relative IRI, + or a compact IRI (including + blank node identifiers). + See section 3.3 Node Identifiers, + section 4.4 Compact IRIs, and + section 4.16 Identifying Blank Nodes for further discussion on + @id values.

+ +

If the node object contains the @graph + key, its value MUST be + a node object or + an array of zero or more node objects. + If the node object contains an @id keyword, + its value is used as the graph name of a named graph. + See section 4.15 Named Graphs for further discussion on + @graph values. As a special case, if a JSON object + contains no keys other than @graph and @context, and the + JSON object is the root of the JSON-LD document, the + JSON object is not treated as a node object; this + is used as a way of defining node objects + that may not form a connected graph. This allows a + context to be defined which is shared by all of the constituent + node objects.

+ +

If the node object contains the @type + key, its value MUST be either an absolute IRI, a + relative IRI, a compact IRI + (including blank node identifiers), + a term defined in the active context expanding into an absolute IRI, or + an array of any of these. + See section 3.4 Specifying the Type for further discussion on + @type values.

+ +

If the node object contains the @reverse key, + its value MUST be a JSON object containing members representing reverse + properties. Each value of such a reverse property MUST be an absolute IRI, + a relative IRI, a compact IRI, a blank node identifier, + a node object or an array containing a combination of these.

+ +

If the node object contains the @index key, + its value MUST be a string. See + section 4.18 Data Indexing for further discussion + on @index values.

+ +

If the node object contains the @nest key, + its value MUST be an JSON object or an array of JSON objects + which MUST NOT include a value object. See + section 6.10 Property Nesting for further discussion + on @nest values.

+ +

Keys in a node object that are not + keywords MAY expand to an absolute IRI + using the active context. The values associated with keys that expand + to an absolute IRI MUST be one of the following:

+ + +
+ +
+

6.3 Graph Objects §

+ +

A graph object represents a named graph, which MAY include + include an explicit graph name. + A JSON object is a graph object if + it exists outside of a JSON-LD context, + it is not a node object, + it is not the top-most JSON object in the JSON-LD document, and + it consists of no members other than @graph, + @index, @id + and @context, or an alias of one of these keywords.

+ +

If the graph object contains the @context + key, its value MUST be null, an absolute IRI, + a relative IRI, a context definition, or + an array composed of any of these.

+ +

If the graph object contains the @id key, + its value is used as the identifier (graph name) of a named graph, and + MUST be an absolute IRI, a relative IRI, + or a compact IRI (including + blank node identifiers). + See section 3.3 Node Identifiers, + section 4.4 Compact IRIs, and + section 4.16 Identifying Blank Nodes for further discussion on + @id values.

+ +

A graph object without an @id member is also a + simple graph object and represents a named graph without an + explicit identifier, although in the data model it still has a + graph name, which is an implicitly allocated + blank node identifier.

+ +

The value of the @graph key MUST be + a node object or + an array of zero or more node objects. + See section 4.15 Named Graphs for further discussion on + @graph values..

+
+ +
+

6.4 Value Objects §

+ +

A value object is used to explicitly associate a type or a + language with a value to create a typed value or a language-tagged + string.

+ +

A value object MUST be a JSON object containing the + @value key. It MAY also contain an @type, + an @language, an @index, or an @context key but MUST NOT contain + both an @type and an @language key at the same time. + A value object MUST NOT contain any other keys that expand to an + absolute IRI or keyword.

+ +

The value associated with the @value key MUST be either a + string, a number, true, + false or null.

+ +

The value associated with the @type key MUST be a + term, a compact IRI, + an absolute IRI, a string which can be turned + into an absolute IRI using the vocabulary mapping, or null.

+ +

The value associated with the @language key MUST have the + lexical form described in [BCP47], or be null.

+ +

The value associated with the @index key MUST be a + string.

+ +

See section 4.5 Typed Values and + section 4.10 String Internationalization + for more information on value objects.

+
+ +
+

6.5 Lists and Sets §

+ +

A list represents an ordered set of values. A set + represents an unordered set of values. Unless otherwise specified, + arrays are unordered in JSON-LD. As such, the + @set keyword, when used in the body of a JSON-LD document, + represents just syntactic sugar which is optimized away when processing the document. + However, it is very helpful when used within the context of a document. Values + of terms associated with an @set or @list container + will always be represented in the form of an array when a document + is processed—even if there is just a single value that would otherwise be optimized to + a non-array form in compact document form. + This simplifies post-processing of the data as the data is always in a + deterministic form.

+ +

A list object MUST be a JSON object that contains no + keys that expand to an absolute IRI or keyword other + than @list, @context, and @index.

+ +

A set object MUST be a JSON object that contains no + keys that expand to an absolute IRI or keyword other + than @set, @context, and @index. + Please note that the @index key will be ignored when being processed.

+ +

In both cases, the value associated with the keys @list and @set + MUST be one of the following types:

+ + +

See section 4.12 Sets and Lists for further discussion on sets and lists.

+
+ +
+

6.6 Language Maps §

+ +

A language map is used to associate a language with a value in a + way that allows easy programmatic access. A language map may be + used as a term value within a node object if the term is defined + with @container set to @language, + + or an array containing both @language and @set + . The keys of a + language map MUST be strings representing + [BCP47] language codes, the keyword @none, + or a term which expands to @none, + and the values MUST be any of the following types:

+ + + +

See section 4.10 String Internationalization for further discussion + on language maps.

+
+ +
+

6.7 Index Maps §

+ +

An index map allows keys that have no semantic meaning, + but should be preserved regardless, to be used in JSON-LD documents. + An index map may + be used as a term value within a node object if the + term is defined with @container set to @index, + + or an array containing both @index and @set + . + The values of the members of an index map MUST be one + of the following types:

+ + + +

See section 4.18 Data Indexing for further information on this topic.

+ +

Index Maps may also be used to map indexes to associated + named graphs, if the term is defined with @container + set to an array containing both @graph and + @index, and optionally including @set. The + value consists of the node objects contained within the named + graph which is named using the referencing key, which can be + represented as a simple graph object.

+
+ +
+

6.8 Id Maps §

+ +

An id map is used to associate an IRI with a value that allows easy + programmatic access. An id map may be used as a term value within a node object if the term + is defined with @container set to @id, + or an array containing both @id and @set. + The keys of an id map MUST be IRIs + (relative IRI, compact IRI (including blank node identifiers), or absolute IRI), + the keyword @none, + or a term which expands to @none, + and the values MUST be node objects.

+ +

If the value contains a property expanding to @id, it's value MUST + be equivalent to the referencing key. Otherwise, the property from the value is used as + the @id of the node object value when expanding.

+ +

Id Maps may also be used to map graph names to their + named graphs, if the term is defined with @container + set to an array containing both @graph and @id, + and optionally including @set. The value consists of the + node objects contained within the named graph + which is named using the referencing key.

+
+ +
+

6.9 Type Maps §

+ +

A type map is used to associate an IRI with a value that allows easy + programmatic access. A type map may be used as a term value within a node object if the term + is defined with @container set to @type, + or an array containing both @type and @set. + The keys of a type map MUST be IRIs + (relative IRI, compact IRI (including blank node identifiers), or absolute IRI), + the keyword @none, + or a term which expands to @none, + and the values MUST be node objects.

+ +

If the value contains a property expanding to @type, and it's value + is contains the referencing key after suitable expansion of both the referencing key + and the value, then the node object already contains the type. Otherwise, the property from the value is + added as a @type of the node object value when expanding.

+
+ +
+

6.10 Property Nesting §

+ +

A nested property is used to gather properties of a node object in a separate + JSON object, or array of JSON objects which are not + value objects. It is semantically transparent and is removed + during the process of expansion. Property nesting is recursive, and + collections of nested properties may contain further nesting.

+ +

Semantically, nesting is treated as if the properties and values were declared directly + within the containing node object.

+
+ +
+

6.11 Context Definitions §

+ +

A context definition defines a local context in a + node object.

+ +

A context definition MUST be a JSON object whose + keys MUST be either terms, compact IRIs, absolute IRIs, + or one of the keywords @language, @base, + @vocab, or @version.

+ +

If the context definition has an @language key, + its value MUST have the lexical form described in [BCP47] or be null.

+ +

If the context definition has an @base key, + its value MUST be an absolute IRI, a relative IRI, + or null.

+ +

If the context definition has an @vocab key, + its value MUST be a absolute IRI, a compact IRI, + a blank node identifier, + an empty string (""), + a term, or null.

+ +

If the context definition has an @version key, + its value MUST be a number with the value 1.1.

+ +

The value of keys that are not keywords MUST be either an + absolute IRI, a compact IRI, a term, + a blank node identifier, a keyword, null, + or an expanded term definition.

+ +

An expanded term definition is used to describe the mapping + between a term and its expanded identifier, as well as other + properties of the value associated with the term when it is + used as key in a node object.

+ +

An expanded term definition MUST be a JSON object + composed of zero or more keys from + @id, + @reverse, + @type, + @language, + @context, + @prefix, or + @container. An + expanded term definition SHOULD NOT contain any other keys.

+ +

If the term being defined is not a compact IRI or + absolute IRI and the active context does not have an + @vocab mapping, the expanded term definition MUST + include the @id key.

+ +

If the expanded term definition contains the @id + keyword, its value MUST be null, an absolute IRI, + a blank node identifier, a compact IRI, a term, + or a keyword.

+ +

If an expanded term definition has an @reverse member, + it MUST NOT have @id or @nest members at the same time, + its value MUST be an absolute IRI, + a blank node identifier, a compact IRI, or a term. If an + @container member exists, its value MUST be null, + @set, or @index.

+ +

If the expanded term definition contains the @type + keyword, its value MUST be an absolute IRI, a + compact IRI, a term, null, or one of the + keywords @id or @vocab.

+ +

If the expanded term definition contains the @language keyword, + its value MUST have the lexical form described in [BCP47] or be null.

+ +

If the expanded term definition contains the @container + keyword, its value MUST be either + @list, + @set, + @language, + @index, + @id, + @graph, + @type, or be + null + + or an array containing exactly any one of those keywords, or a + combination of @set and any of @index, + @id, @graph, @type, + @language in any order + . + @container may also be an array + containing @graph along with either @id or + @index and also optionally including @set. + If the value + is @language, when the term is used outside of the + @context, the associated value MUST be a language map. + If the value is @index, when the term is used outside of + the @context, the associated value MUST be an + index map.

+ +

If an expanded term definition has an @context member, + it MUST be a valid context definition.

+ +

If the expanded term definition contains the @nest + keyword, its value MUST be either @nest, or a term + which expands to @nest.

+ +

If the expanded term definition contains the @prefix + keyword, its value MUST be true or false.

+ +

Terms MUST NOT be used in a circular manner. That is, + the definition of a term cannot depend on the definition of another term if that other + term also depends on the first term.

+ +

See section 3.1 The Context for further discussion on contexts.

+
+ +
+ +
+

7. Relationship to RDF §

+ +

JSON-LD is a + concrete RDF syntax + as described in [RDF11-CONCEPTS]. Hence, a JSON-LD document is both an + RDF document and a JSON document and correspondingly represents an + instance of an RDF data model. However, JSON-LD also extends the RDF data + model to optionally allow JSON-LD to serialize + generalized RDF Datasets. + The JSON-LD extensions to the RDF data model are:

+ + + +

Summarized, these differences mean that JSON-LD is capable of serializing any RDF + graph or dataset and most, but not all, JSON-LD documents can be directly + interpreted as RDF as described in RDF 1.1 Concepts [RDF11-CONCEPTS].

+ +

For authors and developers working with blank nodes + as properties when deserializing to RDF, + three potential approaches are suggested:

+ + + +

The normative algorithms for interpreting JSON-LD as RDF and serializing + RDF as JSON-LD are specified in the JSON-LD 1.1 Processing Algorithms and API + specification [JSON-LD11CG-API].

+ +

Even though JSON-LD serializes + generalized RDF Datasets, it can + also be used as a RDF graph source. + In that case, a consumer MUST only use the default graph and ignore all named graphs. + This allows servers to expose data in languages such as Turtle and JSON-LD + using content negotiation.

+ +
Note

Publishers supporting both dataset and graph syntaxes have to ensure that + the primary data is stored in the default graph to enable consumers that do not support + datasets to process the information.

+ +
+

7.1 Serializing/Deserializing RDF §

This section is non-normative.

+ +

The process of serializing RDF as JSON-LD and deserializing JSON-LD to RDF + depends on executing the algorithms defined in + RDF Serialization-Deserialization Algorithms + in the JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API]. + It is beyond the scope of this document to detail these algorithms any further, + but a summary of the necessary operations is provided to illustrate the process.

+ +

The procedure to deserialize a JSON-LD document to RDF involves the + following steps:

+ +
    +
  1. Expand the JSON-LD document, removing any context; this ensures + that properties, types, and values are given their full representation + as IRIs and expanded values. Expansion + is discussed further in section 4.25 Expanded Document Form.
    2. +
  2. Flatten the document, which turns the document into an array of + node objects. Flattening is discussed + further in section 4.27 Flattened Document Form.
    3. +
  3. Turn each node object into a series of RDF triples.
    4. +
+ +

For example, consider the following JSON-LD document in compact form:

+ +
Example 97: Sample JSON-LD document
{
+  "@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "knows": "http://xmlns.com/foaf/0.1/knows"
+  },
+  "@id": "http://me.markus-lanthaler.com/",
+  "name": "Markus Lanthaler",
+  "knows": [
+    {
+      "@id": "http://manu.sporny.org/about#manu",
+      "name": "Manu Sporny"
+    }, {
+      "name": "Dave Longley"
+    }
+  ]
+}
+ +

Running the JSON-LD Expansion and Flattening algorithms against the + JSON-LD input document in the example above would result in the + following output:

+ +
Example 98: Flattened and expanded form for the previous example
[
+  {
+    "@id": "_:b0",
+    "http://xmlns.com/foaf/0.1/name": "Dave Longley"
+  }, {
+    "@id": "http://manu.sporny.org/about#manu",
+    "http://xmlns.com/foaf/0.1/name": "Manu Sporny"
+  }, {
+    "@id": "http://me.markus-lanthaler.com/",
+    "http://xmlns.com/foaf/0.1/name": "Markus Lanthaler",
+    "http://xmlns.com/foaf/0.1/knows": [
+      { "@id": "http://manu.sporny.org/about#manu" },
+      { "@id": "_:b0" }
+    ]
+  }
+]
+ +

Deserializing this to RDF now is a straightforward process of turning + each node object into one or more RDF triples. This can be + expressed in Turtle as follows:

+ +
Example 99: Turtle representation of expanded/flattened document
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+
+_:b0 foaf:name "Dave Longley" .
+
+<http://manu.sporny.org/about#manu> foaf:name "Manu Sporny" .
+
+<http://me.markus-lanthaler.com/> foaf:name "Markus Lanthaler" ;
+    foaf:knows <http://manu.sporny.org/about#manu>, _:b0 .
+ +

The process of serializing RDF as JSON-LD can be thought of as the + inverse of this last step, creating an expanded JSON-LD document closely + matching the triples from RDF, using a single node object + for all triples having a common subject, and a single property + for those triples also having a common predicate.

+
+
+ +
+

A. Changes since 1.0 Recommendation of 16 January 2014 §

This section is non-normative.

+ +
+ +
+

B. Open Issues §

This section is non-normative.

+

The following is a list of issues open at the time of publication.

+
Issue 246: Ignoring semantically meaningless nestingapideferspec-designsyntax

Thanks for the great work with JSON-LD! However, when trying to use JSON-LD for to present data in the company I'm working in, I noticed the following missing feature:

+

FEATURE PROPOSAL: ABILITY TO DEFINE ANY KEY AS AN INDEX KEY

+

In addition to JSON-LD's existing index container structure, I propose that any key under a JSON-LD node could be defined as a index key.

+

This would help clustering data under a node into coder friendly logical groups without messing up the Linked Data interpretation with e.g. blank nodes. I encountered the need for this feature at our company where our problem is that the amount of attributes a single JSON-LD node can have can potentially be quite many, say, tens or hundreds of attributes.

+

As far as I know, this can not be currently done with JSON-LD without 1) ending up with blank nodes or 2) the need to create a deeper JSON structure by using a separate index term (using "@container":"@index") which then contains the data underneath.

+

In addition, if a single key could be defined as a index term, this would make it more flexible to attach the JSON-LD Linked Data interpretation to even a wider amount of existing JSON data, without having to change the structure of such data (and without ending up with e.g. lots of blank nodes).

+

DEFINING AN INDIVIDUAL INDEX KEY IN @context

+

The "@context" definition could be done e.g. using the existing reserved keyword "@index" in the following way:

+
"indexkey":"@index"
+
+

which should be interpreted in the following way: 1) the "indexkey" is an index key and should be skipped when traversing the JSON tree while doing the JSON-LD to RDF interpretation, 2) any data directly under the "indexkey" should be interpreted as data directly attached to the node of the indexkey (same RDF subject).

+

EXAMPLE

+

To give a full example, in the following a single key "labels" is defined as an index index key to help grouping the data into coder friendly logical groups without messing up the Linked Data interpretation):

+
{
+  "@context": {
+     "labels":"@index",
+     "main_label":"http://example.org/my-schema#main_label",
+     "other_label":"http://example.org/my-schema#other_label",
+     "homepage":{ "@id":"http://example.org/my-schema#homepage", "@type":"@id"}
+  },
+  "@id":"http://example.org/myresource",
+  "homepage": "http://example.org",
+  "labels": {
+     "main_label": "This is the main label for my resource",
+     "other_label": "This is the other label"
+  }
+}
+

This example JSON-LD should generate the following RDF triplets:

+
<http://example.org/myresource> <http://example.org/my-schema#homepage> <http://example.org>. 
+<http://example.org/myresource> <http://example.org/my-schema#main_label> "This is the main label for my resource".
+<http://example.org/myresource> <http://example.org/my-schema#other_label> "This is the other label".
+
+
Issue 316: When using JSON-LD in a browser it is impossible to discover the Base IRI after a redirectapispec-editorialsyntax

When using JSON-LD in a browser (XMLHttpRequest) it is impossible to discover the Base IRI after a redirect because the XHR object hides the final URL of the resource.

+

This means documents without an explicit base URI cannot be resolved into triples in a browser

+
Issue 333: Support JSON values that aren't mappedapideferspec-designsyntax

This has already been discussed several times usingvarious terms.. the most recent request has come from David Janes on the mailing list. The basic idea is to support JSON values/subtrees that aren't mapped to an IRI in the context. They should survive algorithmic transformations (basically without being touched at all).

+
Issue 368: JSON-LD 1.1 Feature Request: Object-level @languageapideferspec-designsyntax

See: digitalbazaar/jsonld.js#72

+

It would be helpful to have the ability to use @language within an object as a shorthand for "@context": {"@language": "..."} ... for instance... make:

+
{
+  "@language": "en",
+  "displayName": "foo"
+}
+

equivalent to:

+
{
+  "@context": {"@language": "en"}, 
+  "displayName": "foo"
+}
+
Issue 371: JSON-LD 1.1 Feature Request: New @label keywordapideferspec-designsyntax

In the spirit of "Labeling Everything" (http://patterns.dataincubator.org/book/label-everything.html) ... it would be worthwhile, IMO, for JSON-LD to provide a basic @Label keyword for use both in @context and nodes. It's largely syntactic sugar but would be useful.

+

For example:

+
{
+  "@context": {
+    "@label": "An Example Context",
+    "displayName": "@label",
+  },
+  "displayName": "A Simple Label"
+}
+

Which would expand to:

+
_:c14n0 <http://www.w3.org/2000/01/rdf-schema#label> "A Simple Label" .
+
+
Issue 397: JSON-LD 1.1 Feature Request: support @values for describing multidimensional containers (list of lists)apideferspec-designsyntax

Problem description §

+

Many JSON specs existed before JSON-LD. A couple of these specs may not be compatible with JSON-LD as they contain multidimensional containers, such as GeoJSON.

+

Example of a multidimensional array:

+
[ [3.1,51.06,30],
+  [3.1,51.06,20] ]
+

This issue is a result from the discussion on the GeoJSON-LD repository: geojson/geojson-ld#32. If this issue will not get resolved, the GeoJSON-LD community would suggest creating custom JSON-LD parsers for JSON-LD dialects. This situation would be far from desirable.

+

Suggested solution §

+

Introduce a new @values keyword, which can be used to describe the values of a @set or a @list container in more detail.

+

When an array is given in the @values, then the precise amount of objects within this array corresponds with the array in the graph in this order.

+

When an object is given in the @values, each value of the array in the graph is mapped according to this template.

+

Example §

+
{
+  "@context": {
+     "coordinates": {
+        "@id": "geojson:coordinates",
+        "@container" : "@list",
+        "@values" : { 
+           "@type" : "geojson:Coordinate",
+           "@container" : "@set",
+           "@values" : [
+               {"@type" : "xsd:double", "@id":"geo:longitude"},
+               {"@type" : "xsd:double", "@id":"geo:latitude"}
+           ]
+        }
+     }
+  },
+  "@graph" : [{
+   "@id" : "ex:LineString1",
+    "coordinates" : [
+          [
+            3.1057405471801753,
+            51.064216229943476
+          ],
+          [
+            3.1056976318359375,
+            51.063434090307574
+          ]
+    ]
+  }]
+}
+

Would transform to (and vice versa):

+
ex:LineString1 geojson:coordinates _:b0 .
+_:b0 rdf:first _:b1 .
+_:b1 a geojson:Coordinate ;
+      geo:longitude "3.105740547180175E0"^^xsd:double ;
+      geo:latitude "5.106421622994348E1"^^xsd:double .
+_:b0 rdf:rest _:b2 .
+_:b2 rdf:first a geojson:Coordinate ;
+      geo:longitude "3.1056976318359375"^^xsd:double ;
+      geo:latitude "51.063434090307574"^^xsd:double .
+_:b2 rdf:rest rdf:nil .
+
Issue 443: Semantic Free JSON-LDdefersyntax

Hi all,

+

I've recently been trying to design a JSON format to act as a bridge between the RDF world and the typical JSON developer. However due to complexities in the underlying RDF ontology, it is proving almost impossible with the current JSON-LD features to create both an easy to use JSON format and an isomorphic representation of the semantic graph from which the data is derived.

+

My primary goal is basically to create a useful JSON format and I don't really care about the semantics expressed via the RDF interpreatation of the JSON at all. My feeling is that if our users want the RDF interpretation they can Accept: text/turtle or another appropriate serialisation.

+

I really want to leverage only the JSON side semantics of JSON-LD as a means to give JSON users access to linked data URI's (which are syntactically @identified as such, @language tags, RDF data-types, e.g. xsd:dateTime's and prefix URI's. Basically I want to use JSON-LD as a means to augment RDF with JSON, and perhaps even give JSON developers hooks into documentation on certain keys, e.g. answering the question what does the dimension key mean, by letting them dereference it?

+

For me this is perhaps the most exciting application of JSON-LD, and I think it'd be nice if there was a way to formally tell processors and users, to not process it as RDF.

+

Basically I can get the syntax I want at the expense of RDF semantics, and I'd like to inform users "not to interpret this as RDF".

+

I realise I can achieve this by taking advantage of the fact that processors don't pursue keys that they don't know about in the context. However it might be nice to flag this to users, incase they think it's going to yield some meaningful RDF.

+

I'm sure you've thought about cases like these, so I'm curious what you think the best way to tackle it is.

+

Also please pass on my thanks to everyone in the Working Group for coming up with what looks to be a great new standard.

+
Issue 491: JSON-LD 1.1 Feature Request : define how to specify the json-ld profile in a request to a server and include framing as an optiondeferspec-designsyntax

the current descriptions provide means to specify encoding and framing options through a programmatic api. these include the context to apply, whether to frame the result.
+they also provide means in http headers to specify the variant which applies to the given document in terms of a link to a context and/or a media type profile.

+

the 1.0 descriptions do not appear to provide a way to specify that same information to a json-ld source as part of an http request.
+is this now included somewhere in 1.1 document?
+are there plans to provide for this?

+
Issue 547: Content addressable contextsdeferspec-designsyntax

In the Verifiable Claims (and other) groups, the concern about things such as JSON-LD contexts changing meaning over time came up. On thought would be to create a convention, or rely upon some other standard, to allow URIs to be "content addressable", in the sense that it can be determined that the content derived from dereferencing a remote resource can be determined to be the same content as was originally intended.

+

There's also a desire to be able to pre-load contexts, without requiring that they be downloaded when accessed, which could be addressed using such a mechanism.

+

There are also some proposed RFCs that attempt to address this problem (thanks to @mesinter):

+
    +
  • +

    'duri' URI takes the form:

    +
      duri:<timestamp>:<embeddedURI>
+
    +
    • +
  • +

    'tdb' URI takes a similar form:

    +
      tdb:<timestamp>:<embeddedURI>
+
    +
    • +
+

See w3c-ccg/did-spec#32

+
Issue 548: Use version 2.0 instead of 1.1apideferspec-designsyntax

Comments at TPAC suggested that as our work is a breaking change (causing 1.0 processors that are not 1.1 compatible to intentionally break when they see "@version": 1.1), semantic versioning would suggest that we use a major release number, rather than a minor number.

+

This could impact a potential WG, which may want to make further changes, and then be in the place of using either 2.1 or 3.0, which is odd given that the previous recommendation is 1.0.

+

In some situations it is important/necessary to include the base direction of a text, alongside its language; see the “Requirements for Language and Direction Metadata in Data Formats” for further details. In practice, in a vanilla JSON, it would require something like:

+
"title": [ { "value": "Moby Dick", "lang": "en" },
+           { "value": "موبي ديك", "lang": "ar"  "dir": "rtl"}
+         ]  
+
+

(the example comes from that document).

+

At this moment, I believe the only way you can reasonably express that in JSON-LD is via cheating a bit:

+
"title": [ { "@value": "Moby Dick", "@language": "en" },
+           { "@value": "موبي ديك",  "@language": "ar"  "dir": "rtl"}
+         ]  
+
+

and making sure that the dir term is not defined in the relevant @context so that, when generating the RDF output, that term is simply ignored. But that also means that there is no round-tripping, that term will disappear after expansion.

+

The difficulty lies in the RDF layer, in fact; RDF does not have any means (alas!) to express text direction. On the other hand, this missing feature is a general I18N problem whenever JSON-LD is used (there were issues when developing the Web Annotation Model, these issues are popping up in the Web Publication work, etc.).

+

Here is what I would propose as a non-complete solution

+
    +
  1. Let us introduce a @dir term, alongside @language. This means this term can be used in place of dir above, ie, it is a bona-fide part of a string representation, and would therefore be kept in the compaction/expansion steps, can also be used for framing.
    2. +
  2. In JSON-LD 1.1, @dir is ignored when transforming into RDF. I.e., only the language tag would be used.
    3. +
  3. We may initiate some work in the RDF community to solve this issue. There may be several ways, each of them require the RDF community to chime in
    +3.1. Define a mechanism of "parametrized" standard datatypes that represent a (language,direction) pair. One would then get something like[] ex:title "موبي ديك"^^rdf:internationalText(ar,rtl) ;
    +3.2. Go for a "generalized" RDF where strings can also appear as subjects (that has been a matter of dispute for a long time...). That would give the possibility to add such attribute to texts like directions
    +3.3. Some other mechanisms that I cannot think about
    4. +
  4. In a future JSON-LD 1.* the @dir value can be properly mapped onto an RDF representing the right choices (if such choices are worked out)
    5. +
+

Cc: @BigBlueHat @r12a

+
Issue 584: Revisit empty string as termdeferspec-editorialsyntax

JSON-LD has a restriction that terms must not be the empty string

+

From JSON-LD Syntax 6.1:

+
+

Furthermore, the term MUST NOT be an empty string ("") as not all programming languages are able to handle empty JSON keys.

+
+

IIRC, this was added due to an issue in an earlier version of PHP, and I suspect it is no longer an issue. Furthermore, the use of empty prefixes is common in other RDF syntaxes, so allowing it here for 1.1 documents would be reasonable, if tooling supports it.

+

As evidence, consider this stackoverflow question.

+

Also, note that while the syntax document makes such a normative statement, the API algorithms don't call this out as an error condition.

+
Issue 585: Allow @value, @language and @type simultaneouslydeferspec-designsyntax

It is currently not possible to have all three of @value, @language and @type. Meaning that for text with embedded mark up, it is impossible to have both language and format (the datatype given in @type) ... neither of which can be reliably introspected from the value.

+

Any time there is markdown, html, xml, json, yaml, latex, or any other formatting instructions beyond simply print the string to the user, this becomes extremely valuable. Given the usage of those formats on the web, it would enable appropriate management of internationalized texts.

+

Example:

+
{
+  "description": {
+    "@value":"<p>Some <b>description</b></p>",
+    "@type": "rdf:XMLLiteral",
+    "@language" : "en-latn"
+  }
+}
+
+

Reference: https://lists.w3.org/Archives/Public/public-linked-json/2014Aug/0031.html
+Door-Opened-By: #583

+

One of my chief concerns for using JSON-LD in the Beaker/Dat ecosystem is that vocabulary IRIs will be too burdensome for developers to create and maintain consistently. I think often it will be done, but many times devs won't be bothered.

+

To counter that, I'd like to investigate a "Lax" IRI form which allows an arbitrary string to be used. The string would not be registered to any global ownership system (not DNS, not a urn registry, not a public key, not a content hash). Users would be encouraged to use a string that is long and unlikely to collide with other strings, but there would be no enforcement mechanism. For instance, 'pfrazee-social-media-feed-item'.

+

The goal would be to create identifiers which behave like IRIs, but which are human readable and which don't require any registration and maintenance of the ID. Rather than a locator to documentation, the Lax IRI would be a label which could be used to discover documentation (on Google, etc). The original author of the identifier would ideally publish documentation somewhere searchable, but it would not be required. To continue from my example, I'd publish a document labeled pfrazee-social-media-feed-item.

+

I've not found any existing IRI scheme that matches my description yet.

+

There are probably two discussions to have in response to this exploration:

+
    +
  1. Whether a "Lax" IRI would be a net benefit.
    2. +
  2. Whether there's an alternative that achieves the same goals.
    3. +
+

As for whether it would be a net benefit, the reasoning I'd give is that some information is better than no information, and if developers are going to abstain from providing a vocabulary IRI because of the difficulty, wouldn't it be better to have a low-effort solution? A "lax" IRI trades total specificity for improved specificity. And, bear in mind, many developers in my audience are going to be building for fun.

+

A valid counter-argument to my reasoning is, if you create the "lax" option, you may get more IRIs overall, but you risk getting fewer "non-lax" IRIs overall. (Once the option to be lazy is given, then won't everybody be lazy?) So the precision of the global system might suffer overall.

+
Issue 595: Native support for schema:ListItemapideferspec-designsyntax

Per a suggestion by @danbri, we may want to add a container type, similar to @list for encoding schema:ItemList serializations, when the values are schema:ListItem and order is set through schema:position. ItemList can be used with text values as well, but this is already reasonably supported natively.

+

Markup might look like the following:

+
{
+  "@context": {
+    "@vocab": "http://schema.org/",
+    "itemListElement": {"@container": "@listItem"}
+  },
+  "@type": "ItemList",
+  "@url": "http://en.wikipedia.org/wiki/Billboard_200",
+  "name": "Top music artists",
+  "description": "The artists with the most cumulative weeks at number one according to Billboard 200",
+  "itemListElement": [
+    {"@type": "MusicGroup", "name": "Beatles"},
+    {"@type": "MusicGroup", "name": "Elvis Presley"},
+    {"@type": "MusicGroup", "name": "Michael Jackson"},
+    {"@type": "MusicGroup", "name": "Garth Brooks" }
+  ]
+

This would expand to the following:

+
[
+  {
+    "@id": "http://en.wikipedia.org/wiki/Billboard_200",
+    "@type": ["http://schema.org/ItemList"],
+    "http://schema.org/description": [{
+      "@value": "The artists with the most cumulative weeks at number one according to Billboard 200"
+    }],
+    "http://schema.org/itemListElement": [{
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Beatles"}]
+      }],
+      "http://schema.org/position": [{"@value": 1}]
+    },  {
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Elvis Presley"}]
+      }],
+      "http://schema.org/position": [{"@value": 2}]
+    }, {
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Michael Jackson"}]
+      }],
+      "http://schema.org/position": [{"@value": 3}]
+    }, {
+      "@type": ["http://schema.org/ListItem"],
+      "http://schema.org/item": [{
+        "@type": ["http://schema.org/MusicGroup"],
+        "http://schema.org/name": [{"@value": "Garth Brooks"}]
+      }],
+      "http://schema.org/position": [{"@value": 3}]
+    }
+  ],
+  "http://schema.org/name": [{"@value": "Top music artists"}]
+}]
+

Otherwise, it works like @list.

+

When compacting, the processor will re-order items based on position, and ignore any nextItem or previousItem entries.

+

Expansion shows 1-base position, but could be 0-base as well. Note that specific position values are lost when compacting, and duplicate values may lead to undefined relative ordering.

+
Issue 598: Warn or error if non-keyword strings having "@" are encounteredapibest-practicesdeferspec-designsyntax

Looking at a schema.org example for ItemList, there is a JSON-LD example which includes the fictitious @url keyword, where they likely meant @id.

+
{
+  "@context": "http://schema.org",
+  "@type": "ItemList",
+  "@url": "http://en.wikipedia.org/wiki/Billboard_200",
+  "name": "Top music artists",
+  "description": "The artists with the most cumulative weeks at number one according to Billboard 200",
+  "itemListElement": [
+    {
+      "@type": "ListItem",
+      "position": 1,
+      "item": {
+        "@type": "MusicGroup",
+        "name": "Beatles"
+      }
+    },
+    {
+      "@type": "ListItem",
+      "position": 2,
+      "item": {
+        "@type": "MusicGroup",
+        "name": "Elvis Presley"
+      }
+    },
+    {
+      "@type": "ListItem",
+      "position": 3,
+      "item": {
+        "@type": "MusicGroup",
+        "name": "Michael Jackson"
+      }
+    },
+    {
+      "@type": "ListItem",
+      "position": 3,
+      "item": {
+        "@type": "MusicGroup",
+        "name": "Garth Brooks"
+      }
+    }
+  ]
+}
+

There's nothing to signal an issue, and a JSON-LD processor will happily resolve this relative to @vocab as http://schema.org/@url. This creates a potential forward-compatibility issue if new keywords are introduced, as they are in 1.1. We might want to describe normative or suggested behavior if a processor encounters a string which could hold a keyword, but holds something else starting with @.

+

cc/ @danbri

+
+ +
+

C. Relationship to Other Linked Data Formats §

This section is non-normative.

+ +

The JSON-LD examples below demonstrate how JSON-LD can be used to + express semantic data marked up in other linked data formats such as Turtle, + RDFa, Microformats, and Microdata. These sections are merely provided as + evidence that JSON-LD is very flexible in what it can express across different + Linked Data approaches.

+ +
+

C.1 Turtle §

This section is non-normative.

+ +

The following are examples of transforming RDF expressed in Turtle [TURTLE] + into JSON-LD.

+ +
+

C.1.1 Prefix definitions §

+ +

The JSON-LD context has direct equivalents for the Turtle + @prefix declaration:

+ +
Example 100: A set of statements serialized in Turtle
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+
+<http://manu.sporny.org/about#manu> a foaf:Person;
+  foaf:name "Manu Sporny";
+  foaf:homepage <http://manu.sporny.org/> .
+ +
Example 101: The same set of statements serialized in JSON-LD
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/"
+  },
+  "@id": "http://manu.sporny.org/about#manu",
+  "@type": "foaf:Person",
+  "foaf:name": "Manu Sporny",
+  "foaf:homepage": { "@id": "http://manu.sporny.org/" }
+}
+
+ +
+

C.1.2 Embedding §

+ +

Both Turtle and JSON-LD allow embedding, although Turtle only allows embedding of + blank nodes.

+ +
Example 102: Embedding in Turtle
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+
+<http://manu.sporny.org/about#manu>
+  a foaf:Person;
+  foaf:name "Manu Sporny";
+  foaf:knows [ a foaf:Person; foaf:name "Gregg Kellogg" ] .
+ +
Example 103: Same embedding example in JSON-LD
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/"
+  },
+  "@id": "http://manu.sporny.org/about#manu",
+  "@type": "foaf:Person",
+  "foaf:name": "Manu Sporny",
+  "foaf:knows": {
+    "@type": "foaf:Person",
+    "foaf:name": "Gregg Kellogg"
+  }
+}
+
+ +
+

C.1.3 Conversion of native data types §

+ +

In JSON-LD numbers and boolean values are native data types. While Turtle + has a shorthand syntax to express such values, RDF's abstract syntax requires + that numbers and boolean values are represented as typed literals. Thus, + to allow full round-tripping, the JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] + defines conversion rules between JSON-LD's native data types and RDF's + counterparts. Numbers without fractions are + converted to xsd:integer-typed literals, numbers with fractions + to xsd:double-typed literals and the two boolean values + true and false to a xsd:boolean-typed + literal. All typed literals are in canonical lexical form.

+ +
Example 104: JSON-LD using native data types for numbers and boolean values
{
+  "@context": {
+    "ex": "http://example.com/vocab#"
+  },
+  "@id": "http://example.com/",
+  "ex:numbers": [ 14, 2.78 ],
+  "ex:booleans": [ true, false ]
+}
+ +
Example 105: Same example in Turtle using typed literals
@prefix ex: <http://example.com/vocab#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+<http://example.com/>
+  ex:numbers "14"^^xsd:integer, "2.78E0"^^xsd:double ;
+  ex:booleans "true"^^xsd:boolean, "false"^^xsd:boolean .
+ +
+ +
+

C.1.4 Lists §

+

Both JSON-LD and Turtle can represent sequential lists of values.

+ +
Example 106: A list of values in Turtle
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+
+<http://example.org/people#joebob> a foaf:Person;
+  foaf:name "Joe Bob";
+  foaf:nick ( "joe" "bob" "jaybee" ) .
+ +
Example 107: Same example with a list of values in JSON-LD
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/"
+  },
+  "@id": "http://example.org/people#joebob",
+  "@type": "foaf:Person",
+  "foaf:name": "Joe Bob",
+  "foaf:nick": {
+    "@list": [ "joe", "bob", "jaybee" ]
+  }
+}
+
+
+ +
+

C.2 RDFa §

This section is non-normative.

+ +

The following example describes three people with their respective names and + homepages in RDFa [RDFA-CORE].

+ +
Example 108: RDFa fragment that describes three people
<div prefix="foaf: http://xmlns.com/foaf/0.1/">
+   <ul>
+      <li typeof="foaf:Person">
+        <a property="foaf:homepage" href="http://example.com/bob/">
+          <span property="foaf:name">Bob</span>
+        </a>
+      </li>
+      <li typeof="foaf:Person">
+        <a property="foaf:homepage" href="http://example.com/eve/">
+         <span property="foaf:name">Eve</span>
+        </a>
+      </li>
+      <li typeof="foaf:Person">
+        <a property="foaf:homepage" href="http://example.com/manu/">
+          <span property="foaf:name">Manu</span>
+        </a>
+      </li>
+   </ul>
+</div>
+ +

An example JSON-LD implementation using a single context is + described below.

+ +
Example 109: Same description in JSON-LD (context shared among node objects)
{
+  "@context": {
+    "foaf": "http://xmlns.com/foaf/0.1/"
+  },
+  "@graph": [
+    {
+      "@type": "foaf:Person",
+      "foaf:homepage": "http://example.com/bob/",
+      "foaf:name": "Bob"
+    }, {
+      "@type": "foaf:Person",
+      "foaf:homepage": "http://example.com/eve/",
+      "foaf:name": "Eve"
+    }, {
+      "@type": "foaf:Person",
+      "foaf:homepage": "http://example.com/manu/",
+      "foaf:name": "Manu"
+    }
+  ]
+}
+
+ +
+

C.3 Microformats §

This section is non-normative.

+ +

The following example uses a simple Microformats hCard example to express + how Microformats [MICROFORMATS] are represented in JSON-LD.

+ +
Example 110: HTML fragment with a simple Microformats hCard
<div class="vcard">
+ <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
+</div>
+ +

The representation of the hCard expresses the Microformat terms in the + context and uses them directly for the url and fn + properties. Also note that the Microformat to JSON-LD processor has + generated the proper URL type for http://tantek.com/.

+ +
Example 111: Same hCard representation in JSON-LD
{
+  "@context": {
+    "vcard": "http://microformats.org/profile/hcard#vcard",
+    "url": {
+      "@id": "http://microformats.org/profile/hcard#url",
+      "@type": "@id"
+    },
+    "fn": "http://microformats.org/profile/hcard#fn"
+  },
+  "@type": "vcard",
+  "url": "http://tantek.com/",
+  "fn": "Tantek Çelik"
+}
+
+ +
+

C.4 Microdata §

This section is non-normative.

+ +

The HTML Microdata [MICRODATA] example below expresses book information as + a Microdata Work item.

+ +
Example 112: HTML fragments that describes a book using microdata
<dl itemscope
+    itemtype="http://purl.org/vocab/frbr/core#Work"
+    itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N">
+ <dt>Title</dt>
+ <dd><cite itemprop="http://purl.org/dc/terms/title">Just a Geek</cite></dd>
+ <dt>By</dt>
+ <dd><span itemprop="http://purl.org/dc/terms/creator">Wil Wheaton</span></dd>
+ <dt>Format</dt>
+ <dd itemprop="http://purl.org/vocab/frbr/core#realization"
+     itemscope
+     itemtype="http://purl.org/vocab/frbr/core#Expression"
+     itemid="http://purl.oreilly.com/products/9780596007683.BOOK">
+  <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK">
+  Print
+ </dd>
+ <dd itemprop="http://purl.org/vocab/frbr/core#realization"
+     itemscope
+     itemtype="http://purl.org/vocab/frbr/core#Expression"
+     itemid="http://purl.oreilly.com/products/9780596802189.EBOOK">
+  <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK">
+  Ebook
+ </dd>
+</dl>
+ +

Note that the JSON-LD representation of the Microdata information stays + true to the desires of the Microdata community to avoid contexts and + instead refer to items by their full IRI.

+ +
Example 113: Same book description in JSON-LD (avoiding contexts)
[
+  {
+    "@id": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
+    "@type": "http://purl.org/vocab/frbr/core#Work",
+    "http://purl.org/dc/terms/title": "Just a Geek",
+    "http://purl.org/dc/terms/creator": "Whil Wheaton",
+    "http://purl.org/vocab/frbr/core#realization":
+    [
+      "http://purl.oreilly.com/products/9780596007683.BOOK",
+      "http://purl.oreilly.com/products/9780596802189.EBOOK"
+    ]
+  }, {
+    "@id": "http://purl.oreilly.com/products/9780596007683.BOOK",
+    "@type": "http://purl.org/vocab/frbr/core#Expression",
+    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/BOOK"
+  }, {
+    "@id": "http://purl.oreilly.com/products/9780596802189.EBOOK",
+    "@type": "http://purl.org/vocab/frbr/core#Expression",
+    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
+  }
+]
+
+
+ +
+

D. IANA Considerations §

+ +

This section has been submitted to the Internet Engineering Steering + Group (IESG) for review, approval, and registration with IANA.

+ +

application/ld+json §

+
+
Type name:
+
application
+
Subtype name:
+
ld+json
+
Required parameters:
+
None
+
Optional parameters:
+
+
+
profile
+
+

A non-empty list of space-separated URIs identifying specific + constraints or conventions that apply to a JSON-LD document according to [RFC6906]. + A profile does not change the semantics of the resource representation + when processed without profile knowledge, so that clients both with + and without knowledge of a profiled resource can safely use the same + representation. The profile parameter MAY be used by + clients to express their preferences in the content negotiation process. + If the profile parameter is given, a server SHOULD return a document that + honors the profiles in the list which are recognized by the server. + It is RECOMMENDED that profile URIs are dereferenceable and provide + useful documentation at that URI. For more information and background + please refer to [RFC6906].

+

This specification defines three values for the profile parameter. + To request or specify expanded JSON-LD document form, + the URI http://www.w3.org/ns/json-ld#expanded SHOULD be used. + To request or specify compacted JSON-LD document form, + the URI http://www.w3.org/ns/json-ld#compacted SHOULD be used. + To request or specify flattened JSON-LD document form, + the URI http://www.w3.org/ns/json-ld#flattened SHOULD be used. + Please note that, according [HTTP11], the value of the profile + parameter has to be enclosed in quotes (") because it contains + special characters and, if multiple profiles are combined, whitespace.

+

When processing the "profile" media type parameter, it is important to + note that its value contains one or more URIs and not IRIs. In some cases + it might therefore be necessary to convert between IRIs and URIs as specified in + section 3 Relationship between IRIs and URIs + of [RFC3987].

+
+
+
+
Encoding considerations:
+
See RFC 6839, section 3.1.
+
Security considerations:
+
See [RFC7159] +

Since JSON-LD is intended to be a pure data exchange format for + directed graphs, the serialization SHOULD NOT be passed through a + code execution mechanism such as JavaScript's eval() + function to be parsed. An (invalid) document may contain code that, + when executed, could lead to unexpected side effects compromising + the security of a system.

+

When processing JSON-LD documents, links to remote contexts are + typically followed automatically, resulting in the transfer of files + without the explicit request of the user for each one. If remote + contexts are served by third parties, it may allow them to gather + usage patterns or similar information leading to privacy concerns. + Specific implementations, such as the API defined in the + JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API], + may provide fine-grained mechanisms to control this behavior.

+

JSON-LD contexts that are loaded from the Web over non-secure connections, + such as HTTP, run the risk of being altered by an attacker such that + they may modify the JSON-LD active context in a way that + could compromise security. It is advised that any application that + depends on a remote context for mission critical purposes vet and + cache the remote context before allowing the system to use it.

+

Given that JSON-LD allows the substitution of long IRIs with short terms, + JSON-LD documents may expand considerably when processed and, in the worst case, + the resulting data might consume all of the recipient's resources. Applications + should treat any data with due skepticism.

+
+
Interoperability considerations:
+
Not Applicable
+
Published specification:
+
http://www.w3.org/TR/json-ld
+
Applications that use this media type:
+
Any programming environment that requires the exchange of + directed graphs. Implementations of JSON-LD have been created for + JavaScript, Python, Ruby, PHP, and C++. +
+
Additional information:
+
+
+
Magic number(s):
+
Not Applicable
+
File extension(s):
+
.jsonld
+
Macintosh file type code(s):
+
TEXT
+
+
+
Person & email address to contact for further information:
+
Manu Sporny <msporny@digitalbazaar.com>
+
Intended usage:
+
Common
+
Restrictions on usage:
+
None
+
Author(s):
+
Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, Niklas Lindström
+
Change controller:
+
W3C
+
+ +

Fragment identifiers used with application/ld+json + are treated as in RDF syntaxes, as per + RDF 1.1 Concepts and Abstract Syntax + [RDF11-CONCEPTS].

+
+ +
+

E. Security Considerations §

+
Editor's note

Consider requirements from Self-Review Questionnaire: Security and Privacy.

+

See, section D. IANA Considerations

+
+ +
+

F. Acknowledgements §

This section is non-normative.

+ +

The authors would like to extend a deep appreciation and the most sincere + thanks to Mark Birbeck, who contributed foundational concepts + to JSON-LD via his work on RDFj. JSON-LD uses a number of core concepts + introduced in RDFj, such as the context as a mechanism to provide an + environment for interpreting JSON data. Mark had also been very involved in + the work on RDFa as well. RDFj built upon that work. JSON-LD exists + because of the work and ideas he started nearly a decade ago in 2004.

+ +

A large amount of thanks goes out to the JSON-LD Community Group + participants who worked through many of the technical issues on the mailing + list and the weekly telecons - of special mention are François Daoust, + Stéphane Corlosquet, Lin Clark, and Zdenko 'Denny' Vrandečić.

+ +

The work of David I. Lehn and Mike Johnson are appreciated for + reviewing, and performing several early implementations + of the specification. Thanks also to Ian Davis for this work on RDF/JSON.

+ +

Thanks to the following individuals, in order of their first name, for + their input on the specification: Adrian Walker, Alexandre Passant, + Andy Seaborne, Ben Adida, Blaine Cook, Bradley Allen, Brian Peterson, + Bryan Thompson, Conal Tuohy, Dan Brickley, Danny Ayers, Daniel Leja, + Dave Reynolds, David Booth, David I. Lehn, David Wood, Dean Landolt, + Ed Summers, elf Pavlik, + Eric Prud'hommeaux, Erik Wilde, Fabian Christ, Jon A. Frost, Gavin Carothers, + Glenn McDonald, Guus Schreiber, Henri Bergius, Jose María Alvarez Rodríguez, + Ivan Herman, Jack Moffitt, Josh Mandel, KANZAKI Masahide, Kingsley Idehen, + Kuno Woudt, Larry Garfield, Mark Baker, Mark MacGillivray, Marko Rodriguez, + Marios Meimaris, Matt Wuerstl, + Melvin Carvalho, Nathan Rixham, Olivier Grisel, Paolo Ciccarese, Pat Hayes, + Patrick Logan, Paul Kuykendall, Pelle Braendgaard, + Peter Patel-Schneider, Peter Williams, Pierre-Antoine Champin, + Richard Cyganiak, Roy T. Fielding, Sandro Hawke, Simon Grant, Srecko Joksimovic, + Stephane Fellah, Steve Harris, Ted Thibodeau Jr., Thomas Steiner, Tim Bray, + Tom Morris, Tristan King, Sergio Fernández, Werner Wilms, and William Waites.

+
+ + + +

G. References §

G.1 Normative references §

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47 +
[IANA-URI-SCHEMES]
Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml +
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ +
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-api/ +
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/ +
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ +
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 +
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986 +
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987 +
[RFC5988]
Web Linking. M. Nottingham. IETF. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5988 +
[RFC7159]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7159 +

G.2 Informative references §

[HTTP11]
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7230 +
[JSON-LD-TESTS]
JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ +
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld/ +
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-framing/ +
[ld-glossary]
Linked Data Glossary. Bernadette Hyland; Ghislain Auguste Atemezing; Michael Pendleton; Biplav Srivastava. W3C. 27 June 2013. W3C Note. URL: https://www.w3.org/TR/ld-glossary/ +
[LINKED-DATA]
Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html +
[MICRODATA]
HTML Microdata. Charles McCathie Nevile; Dan Brickley; Ian Hickson. W3C. 26 April 2018. W3C Working Draft. URL: https://www.w3.org/TR/microdata/ +
[MICROFORMATS]
Microformats. URL: http://microformats.org +
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/ +
[RDF11-MT]
RDF 1.1 Semantics. Patrick Hayes; Peter Patel-Schneider. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-mt/ +
[RDFA-CORE]
RDFa Core 1.1 - Third Edition. Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/rdfa-core/ +
[RFC6839]
Additional Media Type Structured Syntax Suffixes. T. Hansen; A. Melnikov. IETF. January 2013. Informational. URL: https://tools.ietf.org/html/rfc6839 +
[RFC6906]
The 'profile' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://tools.ietf.org/html/rfc6906 +
[RFC7049]
Concise Binary Object Representation (CBOR). C. Bormann; P. Hoffman. IETF. October 2013. Proposed Standard. URL: https://tools.ietf.org/html/rfc7049 +
[TURTLE]
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/ +
[WEBIDL]
Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/ +
[YAML]
YAML Ain’t Markup Language (YAML™) Version 1.2. Oren Ben-Kiki; Clark Evans; Ingy döt Net.1 October 2009. URL: http://yaml.org/spec/1.2/spec.html +
\ No newline at end of file diff --git a/spec/CG-FINAL/json-ld/20180507/linked-data-graph.dia b/spec/CG-FINAL/json-ld/20180507/linked-data-graph.dia new file mode 100644 index 0000000000000000000000000000000000000000..3e3fa6ba838fb57d55dd6632f1126a4201993cf7 GIT binary patch literal 2150 zcmV-s2$}aEiwFP!000021MOW~Z{xNSe&1hVcwZfw_eSPDDmTfJ zEbl!=$!-7R=j!SYS7L@+a^8@=jAnM6+vrQXXbhJzr-)wKd{^vZnH4b%a*0hKi1V+J>1A^s%$Gzxrp*vobF>m|0H#1P$Zafmn2#+Och)A z%kgmI%fcm>h08As7Z>--EHCpYF83kFS(ex+tx?PT!Jdv&Oriu-?5$>DWQ0+i6CpU3 zMi6s4+~>F~Gp`K-gr|5~&i6s$w5$P0C+Tw=&*o)E@%7^u`Z$(~W_dh)n~Ancv`DG? z>Hh0m-@Zdv)zY6mNq>xsc%0a#+MnY)uf;!~NBr*Bsm#&l^^V$5OKY`vQ*DJ6$J@Kv zLp-&`0X5q$(;{iUDmFaS>$~ON+cEW{9q*%pNTO$(uf+eh@jH5}54>WVUNkA=$MxN- zKFP*^+ex`!XT>U+Jl%wAMVBc&ua z1BSRzYPTQuS)>hRJl+M#p&3y+OY92}6~+uGl17RVVMr080asxCn%|EBo@8lyZ_{bj zo>N-6UlQsig;uU4CRm(dayqT2gi zE3{`-!3ot&5^OLgTuH3NX=u>p_fei_PrG0?eOT0BtfS=n#HO>iThq1jhx_ZD2u=+_ z*Yh(*^Pb}xn%|;mymvM^J{SB_O!C$WwL&mZoe$|32diI_2Zgc-oZAX z?AP)Y-H;XCkgjw?kv3Y3fkZ?Kk8HEX5lC|-M#_z5=3ps55w>(aa=^&$lxcH-s}O6e z+)hNc3W1Bs+%6)N<+GuCvn4`%!xLz8DYLX}f_Kk*pQA;bJVPyQ9)Irlit^bho(8q8 zU;Y#?Y;p5jmP}tO?D3UoaB3SyAg8RlgvMAdK~DkOc9Pzh8o;<45X4in zbYYu6>V}fvi_+)<9XD7Wt16vt9nQm6w7YYpjbx5R4D;$5tzjggm1`up)}VrzTq9R~ zNwcRSkktjqs#!k+S6v}jv94St5ayDLfkMisW3_?d%yAV)hG+w~nq3W7*{{)Jnb?Y~ zmNtX`4nYSd!NIx&XEp0-;H)d;EZ&u~2tiy{?4ht%*4h9uGa?ER&MH)`#5J?lI2#Af zx&UXj>1klCD`YLvm9=g#5=skE%_e&!trr}M;OFQSto-&#>%zPgrNs*^y|B`sHhHvV zJc%wrN*Zrp+&3w;sA1rwE94}3hIw^xX&hBB2+RCVtgnDD5hIC=($yVU;j5fjk7gn4 zyU@IPqk;yyxfv~=1!fMXhG+p^hA%;2E1CBJ)hI@_nutNYO zr3s}YK$euc%ml8r@|?8U+RUctf?zBM0x3@X=WG%sTvnOET4^o_Ga+a5$IRIz_^6~! zw*59fchY7v-4J{(zVV(T?k1H$$-&A|MJTE0hKMRj93Gns@y+2Raj2(a#HF$`-*kha zE4WnLFha4BLKzj<=Er0kc@)`jA7t}Kl08l4QCYCCBDbfJ!cZiN zNS_`KAaUcidjQ`kIx>jBKvUpJ5EygxMEyzZ;(n6l>Hf~#bGNaAI-sS%RvOv{9-PFO zxoM9MSbOo&?gl$#1Y?qca|9G3wKx%MoaIxSUyiVfISluPZQ_TwiynirjHc7=D0{C# zOfUgGXs|GhDt4;X3$vBq(`==NfD3a2p%CMY(eEq%Cm!PeGa9qby9fw#gWCC(gm_JI z102lUCPyp<)*~VicliNe%ZR4hr!6}}6N4oSmMmDZ@7|ITFkuEle2%D=QU^f|z)t3#RRliYyW9S|d$R7bgCL%{_SoC(j1^lhzd zKl80qmQ*;&Ev(ZYT&JgZei7#;gNRhtI-qZb$%DTf{N-jH4F2*po^Fi0r*lY6>f>X*`pX*}H&HbrNRs-9ZH%vg zlYR|HgI;KpbBjI(cDhD(BHh_(z2#jo&-C=Nx1Kn5Vx+#)S8=2jqk)?)!cEQE7|7{g cC8zqn`jcCCAGZD`*WHKz1G@?~2#9n50H^6c`~Uy| literal 0 HcmV?d00001 diff --git a/spec/CG-FINAL/json-ld/20180507/linked-data-graph.png b/spec/CG-FINAL/json-ld/20180507/linked-data-graph.png new file mode 100644 index 0000000000000000000000000000000000000000..f1c0d76d0cd617f0dae2d89ce05fec32e36e7a61 GIT binary patch literal 27844 zcmbTdbyQo?w>6qVu@*{kX>oTgZp9snOK}ZFin|qxySp_w!KJvn2lwJu-2FTK-TU6S zW4!U*KVC8*2Xc~aYtOajT62dgD@vigA$$V@fzV{6#Z^EcxEA0C4H*vjkE$Yn5AZ_Z zB%$S`YG>}`YUE%B`fO@vY(^?$V`O2bVrFFOZa-)y00LQ?%ZPtgb6fnIDQr#IpS5N& z&i>~nPEYjBSjWDLyZ{0}NJgtkB6LFwdJtdG`*aB+U`X63|HLSJWq;yQKl z-ChMxX2wy_QMvlPjzem>`TpCl#t%(PcHqj<5FYcl1L*?B)0J0iJHyq;CFkzTrI%1= zPGNIXNmEm)PkYJzOvUl?^0FGxV^Gr>KlUr&HHY)xU$XH3*USIyz5nsy|Icj^Y00#3 zexJ{d8rGfHTTcQlSuVxxnJs6mKneg!NA|=K8n`$d7 zm7y9O7|%xWm(0DzYjXy^t8fbGX z-LCEK@nZbyu-(Axtd}O+>%1FXxMfxx^XBPht)T^d;blFTggzy(0giSno<_-O_-4&F zTe2wLp4wJ^b8t{h^576QhZ1(TEBtb2=lihqLpH!RyD2&Ehf39jJsc|x#5&o!q$K=w zX(9Ze?KJ94N(PN5CW|Q&;^CRFhiZg3JE_Quwd(ucthjDMIDzRSjP_Py(V~XuNtV7-9c?+!PE|-}_1(jDD~1DM;3_?N6rbYAk!Mt@pAnRD&fA z!hr|BUMT!j>=csy^0*6(>L<*Gzv*;4*?@i=s!GOpcek5;sEs{H@^VH}=pHUZKu2!Z zdX+>hOC$X7x5g=pD)a9tl|)hP<;^JfnwmAS!k~CL4~|xQ>IJdu7g3M*dNclEIz|aS zzyu#rE-Eg7I-rIgaE7$fwlbD79MYr6PAZ~0?U*rqYqPYSG&b9Yl;TvXhgTlvamLCX z0p#QJeE7w5Sq$z+b#s(XOp{`6ax=;xz578WpAC$JOJ;-#D)bDudoe=EG+DldT=IW z!K$&Qr=p-T^+P*PQP9NIg$ZE=!A`=T!v(QUM?vMgUpzKl`;BKijm(;deyXOTK<3%3 zuAPirh+N#n{nMWSbZhbA;J7~xsTPNN2TvA=YC5svn$~=7fGw{2zIe;rUshBXR>vvk zr2KjSmJ8YBFI|53yPjt!C0g3C%L364uvQ{z zb2&+KRARA~e3h>o7b~u7dIkm!uX2v#Fej{*ik@rxXLP5|DJ7bYzr+?@9Bpa{{vs`& z+zz~0^*m9K(|9F|GKB^5&Mo(~s!cJLd#>+BPu%fq!H&`(L4k1z2u*tY!b6~4{4Ixh zd4yNnn$G}i->@TKIz}=YtQAQ{hu@Ra>{E?nv@B9OCJ*h#D+z%W8f*r){-jI|W}dXa zw5g)N1Ax&%xzX#7si)6oncgq!=$s$*a?bL?PQB8aK#C0)>W(6sIeA2EqUlGYltufv zxTr(J64_RIn9`DWf6x!veB+OeonQ1=d(_r`HLE+6ev;^>NHIx8l^c)ylI{C^H_Xyr zmUlYUt9PFWXXJh&ftGaEbXH$a6t-{|DlTlJa_VBv2111UH&C+eKkZKqFXq_+nAUMO zWLv;22+D2OKIoUuh>|ITLPb9CiTjmPoMu4=#??zXpSD?i_XBFz?4&R@;<3``H zWOgk2vAC;?hS>C8?D{_Mwq1_#pFEy+qsNAEqV#TBA41;BqSK;vY`kbl97#Fm(f7Ho zc{h|EBIHwLntOW-?#jH%A$7I2wWUSy6SD7bf>t(g7s^iUE$;1<+l!0r|I#2u6@?u$9ey1&S35Y55VT7wPy{Qe6c|4 zGj*(|NMxKP60T5=upasl=6teIz|~Zwv_Ic}lX@sMcp7S8kRW0Z{%4>{KId4)EJL|@ zR-A-Q65MU8lnQFQ?T_bj2%Z*tTrB3dZ*mN#R!Gt(iOsd%Jh4fOKFuu%frAxOpOn|LUiD>Ky>IZ z@vqZgWVfVW%ks(QNoUYP0!!iM-=DKQZ?G_$Q07zSQPOd=-YL>zmXhN75S$gu@tqWv z;X+;|V7+xa{CNNEjFB=Lzdt8ZNEB2Z4%4aufo#Cc3&rLt6K=e3!%t zJ2Y7;Pc8Kr$R?}X+wD+j7G_;Ka&}wjCY6OKAK70eT<|2(*7cF*7Rh_alcNzlnMc3U zQaxL9^ZGfsJRfG8Ag^8yp{XMpR6?R57hTyVi|5ozi^P^7ZoKlRh!sb77XKOF$W4C3 z^o3{N&;M9ut7-B?ZL%a#3>xYNp_A47Z7KQ-1nQ9P7IwB$&Bg2|Ce!S%t;=3<`7QdR zpWWJTYP~++a#WW_`#Asom=W~{==i)k?_OYFd2Re&c;OBlFHfUT&HCqeg1>ACJ!q{~ z@DV?LCX9wM3q+j*DC+cS{~w(B`5v^nW}3xB#Mag~b~9A8klSnmo`t|$BeAHb@;t|2 z+r7xWGBH2!CfUH}Zfg)r_fr94v{;^g1;ZC5f_W8o4g=NKE2~!Db-+<%`}P7&0Zkx~ za$stDR*aW|RAF~cXFLWtdAh(CI!xi*+#7*3<2b9d>H^*d=J~ROBX#i4D@0vMAn zY0}w~hye%+%;(|9fNOmM%+q;7-K|-GV6GQoUW^s>Dwd&ZJpEQhcRU)v)-<@s zh3qG7Mgru|rBM~ep66SkQJLe4uxWDMS(*Eat-SndLB3lTVF!%-T$K(bG1Izl_=3*> z-n_q{9+G5yq8$Lh7Yg?kh)YCw@{%Ogdy2>vrWu$vnH~tvMnRzOy8pNeDz`tsm{K0n z^ur^7@07thRKZ*2o_TlP%C0#}L4%7IINKG9O4zd_sGR&d5s*% z(HFx+u5xGM>oxOa9Yxx*0}+k;S*P=uc_3^tg@%Lx>C4Yma|>Gs5V1DE^s4gg(`yhY zzB@uuNuIq}cYBpH=%2^WAe{JqP*e%e5fBx8M(gipIc4{(ygwpcAzl=gXvnE zT3bhF6g987TT42=ZqsWv>ij58Pfvf76W`z8Kb|ctr94&y`|jeR@hvXP>-Ln41Ze9u zz?066Ei9y3hZ-9jTU%QRSYlFZz^8|E6;UTE&92_w3Q(XyMcM9|nVGx0yR);ZcfezI zc9vQ(#sry{@^UtxNk>mhUtizAK#4mY=+wX$QfgJx98T0&tGbegw&rGrR)0RAudP)L z4Grz>zD`b@E(&n@fbkmUrDkWhH#MoeT>SZC=^WLzP5G~=^}sy*{7b8=Nj~q- z`5|sJ&^)Z&-QCjC(l&2<`>NX{a+OcAEt4OCneH~^vFR!$!o!^5=jZ2}Ut7CT>s?>Z z_05;uQ;|1XZgjM;v$M0cRYYRT$YHf-q!O!gZ|7NgzCAO^7XB7j;VU2Bm*YiDLUOSH zgs9xgX5LMhgrZ3^?z^?8e>&kAY&3 zhE=_mQMFS%*@Qxwh}24FWF7HTLv?%0bOp+DmT;mm)kTK_aNf}|^J(enIkQIpbVC-m zXd%(F4lg-HPm8Gj4M7$3x{Vn}%;EgK!cfXfIfcdQmY;icH*fen`Af=PMP&_6*I@-7 z6Nc%fl97?ovm9uv$+~~S*Y^8&%%Z)M6J=(10G0}!lS-Xhalgn<^68_)!$S?aGI#0S z+vDbwGOyp^Csk-O7nzxvcX#gl+!qQvJ3Ge45}K_Enyz(3-O6f9OG{1MsB{8Ezt-?E zz)LUEI20g1nO*aN2+~kGQ3qzz-K`u(Ium&J4k)$I^>@)74rzGES`ZuyGjqWgfW*nk zou2je1#yP*6r&!VY;WgR97q~CgCw>Gy#Ig{)#!UWJ3qI)eR586%K4BPv*9`txBczg zxBVj_I(8+f;ZR(c8>HtT{J5Iy&j4N;BUdPrrgXo{ggDz?33;g0RHO%Irc(CYxY=kZ z9|9{lLb5(eZj2qq$~TRrr>&jZ(dc3(L!f#sneB8rJcBTf&wC*6)VVp2xzde!adAd#hXmPzo;&UtR&@uEOy8dX z)H&xEx*jjvgWWE>EH1-4UxQc$WBW}#0@ap?s!iFyT;Jod65pY#2#T=JuxqKXa?;4j zX5Og%FslrZDGC-rLlapHpsW@DjZjHLlpq`8OZ4~Xs7{@b(SF6=zy|Yzw3t*W_=lH% zv9zHseZzs*kV;dT*kq8#`r~2T8y9cy6`JlQat`iXCw1{KS+-mI%hKiqnM`3mzH`%H zc)8rk&C>S*Yh)6#{X>N~6vckT%9DCS7dDz@0L6-du~w10up@wEDd@5o19V@eHpHF?b4q~&1@m>MJ~Jgu*xck6vcAr z_; Ms5SQ$_wo%3r!HD4h>}v*CvEv@wxg%ua7^0OE+#^5<6VtBZe9K|9WOpWmlyZ zMyrcwVTIOJfLP&RGGXWbANDcWa2P-jA6szXP;O`2>LjXRVUuwC1gVgvxFJuL{!@;oHM?$v zQbyeM+#%C2s!zcY0cr$IzArw9dkGHBZEfYqiDAi+;=Hv?j+x1ekP)qy3${9RkTRj6 z%4LL6ic7&8DZVTNFmr{ao^8w*A?wen`gNoYy?GW!5M8ZH^CWHaC>;HRD8Bo+Hbp)? zm0Yzl#CJxG)s^%3jp9xdeue!hJu1sk$kn^7#nT~-htdhE zr-DNkm^zKVbRLHavRATtsun)1-seus$QU8m$9aVOtsksn4qscxHHc~ac$vThlR)5+ zAIzK;wq))hW7O2G8X@oi@$3^j=b61SE2e=mJEX|V-bT)UfN`pn&S+?AJ}KDR*$I2! zb6P}nj@1harmokiR!R#Q&%d)a3B}drqFJ zy>^=iz9IdDt5(lVLKkb+E7rF@gt9y^)>Lc~aEx109{npUez889qT^qjK^W1TMN1xT zZu4Bc6;jeK=1Ih+K}vj7X`zJ)Jrk3)0@lAK=a-j9T5jZbI5fM1xvz*UkEG~sCFv~K z0y7w=O=>7i>&C8qznb!OyUI`#k&pyGWj5De8^vUuDEx7bV}J%Y1mu_2voTo>?YY+N zA%Vk;8u!Wa`=d!3h#V%k|3C*W{rBOEG)m!9-@o!hQ4hrjrxe8^Dmhn_m01H18=KM5 z(Yh#3WIcyKOrNZQ%Gef2^U0#>R9p2yb*|aUuqrp&}l8I2|ruDvl{e7e%pucTLXNf?*NxG*YD<QEME4$APzUWP3&a^E{wM(P2oU1sI(3iDIweqGhp#%zzX*>oLP z6x1BwVxOL+e}(U-YqgIBC7SZL7BgJ?d>|{UT@|HL&=9lcO%jBCNxf*IscJk`mh}nI zHy%nt3^?(GAem0daI3?qb<3wj>ew_0PN6fqab>37c9Q#{e+)~O)T}mo_LK^eJvj<6 zJgm`!gOXsEsdz4N&6f(BVD_ZbUeu?)zP_i28sxA>vFusMD{Tht|;mLad0qn z487+yrfg^%xi4`viSV(MW$3(~>Kk#p0NnepV)piZ1?A|hxG;zG5%e;*YxZ}BpnRj9 zy{0zOesMMpP*7fsHWn>YF7(aXzJN&Kc!itX5e`X%bJ>3Lx$2}VaawRx>y+#L_O9pJ zftvTC`KJr)%<5g~bCTH`m#c?;btY)^#J<;=SHU)}#iHb15=7d+c8B%l6+e#Xj$j`w zOR=i%9Y^g79R0@UZhSgxtxtpnT^|Kk$_UJZ@iF%ZVc-0wxO9HdN9Mvf>BCG;&W^OB zD=QK*LYSJpOqzr>@*8z{;+E#;PwfxrhkO7;aLot5d{`=3K-?>6yzxj=dMF9AoO*P7 zTZR0QKaAIoEOZJVW^I9~auEB1nkpsj`o+$>cH?d&A^j~S;m4oRf!IPgu>IA`riA)0 z`;teA1rjbr7+)59-{wwv%9~tt2Tg~dy45tyN{wXz&eyoR1S4NvDBtLkr3|_II)mpu zb;(9&NFrigi$nrYWN|-rjz2{v2iq)|e;|}2%(TZkX=aqhhGmY$$Q19zA)^c$`J%51 zO!1f9^I!#VoX8!M>weAO^_COJx!81qx@a-?8Q85I;9Gxy@I3kPjSUR{q!y~!YT1=r z%2b?E6K#|kw;+ZZ3UO>F$v$xk&lWu%UuvEOj?pAo3P^a+sfi?;dK4RyK~5&CcsrFm#V0 z;E-;oecQh0(bQ{Knk!4Mg~_88a;MhvlQ9&ZQEvHXBvBJp7)%%T*DNdVsv^9rL7X1f z=a@jsn%Q6Nt2T-yk@YF5!ed?f(ffwf)t^{QDdX~uW1q8LP*3ePp_8(py95 z_?xfx^MCw|X_NXH>Sf-RT`wCDAJU~Jy{#SV2BP-H71T)^)HX>VM^6u$tZHqA4%OGx zaOg*O*;r7i@t)oC=YJ$2$rPb~Q=LA;23W={ zS4I`ErMtVkM^KwgCYWZdobBw!iH>he5{+B+{}D~K)WTr_2@H~)>xo4di#ex-5T;n1 zvY8#yBd#9WR?&i8j-RTO*{KetkMlX|{nyJSq65|Q~ym+gcq__*1uNkoZ6nndffbr>u6=;$0NpT}F1*VSsCLd~h zRrl8Y#uWY-Q-9fn`jU}Zah ze{yw*O0St%D{OqhqI+LuH)b<=lxjhjD(nfQYyk>Bl7p|0{_ojmV1^COZYDl)y zL3{fiBqR-7XC8sd#VaV+2Cke`IDCyI07OB_7I6jK{{fs3`iud*^VJ>4eAjCNru+9*%OxN9^k=TssRNpSGFZFwvk7IN?ebpB&p%*SDfMO+D_wfga!S zavaJZ3q^G@eSD=AnX}Yx=z}=Xzj#2C&)<@HN9QI7^1%+^xdSdf8bleZ(q}b)u@%c! z7QH9-Ag;yd*}g^|jFa<|k-}t?pSOm$o2rZe>-UWuX^3aHm6DlSv7{1KFO=)2R(;Mu z8nFr6TWz<&5!89l6=x*ByA3irFL;Ew*l-QZ!PB=ixYRIZ$x&2q3C!n=D?y~cvM1?| z>F&_+Jw-}T$xaS)lWSRN?29|op$056Q#fgCV$cu5`H$SyH@M!X({Xb*V&wKqbn#3t zsM52g;`Bw=SDjJ~UunJh;%+pKkqo<{yZagA9{sK$ek|QU){D|6`D;+(xBE8%AZzdJbO8L+etlO##Q|0bF{A$gi4c^ZGY6Mi}LeX2;>yML$+ z-HN#{ZhvTQf0&daaia{yl2q|5(FbP^f{ij{y_46kNN$R`g9Y z?sE)E`zlzWNPn@~D^Xc$Vdz zj%>pgL(qFmc0v5~16z`eMA+wX&i85VzO-~merI1aUwNHYRB-s^mgI#(-+xTY_41Ch zJKm4xK@td4=`9F=Dy-@BjOzHv4{ahwma~RW0sLNBjjjVee7d&3ev$BsuxdnxfVtsE)j(m8IGU~?M@fL*o z*;OzK;-^3$Iv_K2%(*@ziUOoglAHb{HXR(f`!`P`&|$&g>l+$?^2eC5T*deJ#mO1@ zR#?XPwX$QYK1rE^wz;ymPDs_weqQ|X{0FutakIb|79$fzGdFUtd70V*EpXJ#sf!Vz z3^!VJ;j8p$^)$qTCi#DBkzV@qnn2XdKz0Yv8}!i~|*ar>$Po47-iy4PP0u*{l;RJ*eQSc18Zny6O!-H`}6huh$o1&B(6 zP}XwFQ1k1QW#{XfJ|L6neFUwjI1Go*SOICe^>NM%?%<;%8-9oHEC$tHq)FedJiIL| zXq?HGXI`^>eDi9A5nx2~oS+1f3J>L*6>8)xgo)21bf(WPY11KXZBOv;1hR*;+B8j~ z#VQj>48Q(bi2!cSZfxWobh8`(U0Z94VC?DnaC&-re$L*+n0e38RH{+hs1(mfHb%m` zXCascJ0FVT!BV7fO9vHCmqxfCkN|p=?VftLdaE+d2Gq)3udAJW+TS(h?RU5+O~X+s zT|qemgh}t8a?PN7bu`?Eyb3uT%yPmAJ0(n$j-O{;3VlEy&zM<52 z%B(A9yVo#bh?TXSook(;au^K_O?}3nR*=Z}f4)LGNf-T8?MLmaW_`f8<_JPhWvB3d zw0`z{yNQ2c$Io9`TMKc+o*$-@=xjthak{$PSJi*>Py8cK9!)HG-WGM`A^4T90t%J+ z0#Lc-`T2>@bvlXkIR?$)wjZKvU+=$pL*2=OX7cUZ;rV&>K#ISuz_&a|z7e)PH5$k} zPEjS{`fSK_iZyK)ZZAx{8B%wI;$`?ZpmPU-%WQy6R(ejUZ!AdysLnXOMc4bvdB%>W zk0vr$Mk|?&3)oQyl*nZN7o={Km;HK;+*u0c-qe32zEmUWsZbo@#6{2zMrneLy@;TXA8xqs@XOBcnD@ z?Qv}?V+C)0vvMR|unT1!sSs?&pT+x~DRRT;;B6gu!)S4{8gD!quKR{04Yt>C9hI zwo1d*<|eQzB4HX2)3SW~%h#Jzy6-Ub zc~q)L+23)Ss1o)Q{cg?ug*nd-;lF#BlMyIr(uBxfUtAmetC0RY8KYpB4yi4Q&53Ya z$jy?>i`I-QeSq~n&=SI23}{nD^*`g%l18tzlS01=Zl~s_dow<9M;L&|-a}7GgboSL zl+258cc2_0o@!-ssP7`o3E$K8|0ew(pGUidAHd)9{4JT-sO%4&UwN!nX~@I>dv8P`1lzu4Pw4yj2uO3dXJ$1xk$ZK5j z$*Xl1r$vpOsQa`}jW=Bubr5K)GJGVXwHhQlzGwFS9}vg9j%02o!aJBFx+$7JnB8@a zYONv&D?? zA#RcTyS3?5@v8fsFR`f#F-tbwaX}C;CLr~7g zcj@6Gynwq~TV9_2{A*H6TU%R4r)2K%-t*=8AEyMWnec;~KoS+G#h~ZPtvW5P4lZf% z5)-+N2!FD~=NYnrYB+N174uxg;T~go9_1@~l$QLKLqGhelPkj#`4;cXbC4jt3qnZO z4Wi+fztE+Zp0=;hlY#N_P2l0i|0cUHJ8PsT#`Zoj+c?dFYLT$Lfo|w7Z&9+8<7~i& z11L7@h6#)MP~N2?8Ftgt;v8Fg7>ZQS`Vb2~#&|egBm2%3soX@Vuml}c4h-fizJqlJ zrJGV%XUcn?QaECGFWu#QoQv@Y`-vAgXxilP>74++A{bKguG70^bxKs7e`!CXH`a@+)`y$-CRX}K zcckswwdnhMoY96I2F0{?vIEuqaV+A7(*5(+d&pCH?+x4&yAWNF@t z^4&w~1X*@2o0T8WRGd5$;v{~bgxx-|F>;6MIr5ZG zgVv4=7Y}}-DmNFi@)2)341L5%-|5^$OYID*Z@r6c1hxrpIoVX>9X`jv7s8GGMa2Ut zzj^QoykgRZ(I#y1VSJu*o__Xc`xP8Z(jeu^{ybmy)pP_b#{K90jC=%X7^`P!FTO;#wgn+s_)XUThk~4(pF8TZk>gt zrJAb%DT+m*NjLY$+bSP`Pd!A_@9qmMoPdDvPjQ;aK2umgAR{|_PVR(I>7D@M3uG#? z`JP6M@ssZ= zY)*<<*;ZM>T4OSdXySEmBv@? zG>5k5m-DIxdZna^sY*w+L7Z1{k#m8c5ubO+;i3Bu0p<1Y0=&sl0#dvylM&Fxm&n;U z6taXW9Qp6kMYT2RaKU4j;t}1Y-@EuaOGR70a;>J37+5?eO%-RbYE1a6_od?nh25)T zuG&D3=ATF3uHj257#qYr?xRFs@JmF?_aK^Ju;(d^YOvRQh!Qs{t2FgSW>gC#B5<26l@i>L@+rDl7ykrwuz@mm%I^ z!9AO=ptW?B`l-ZgSn?iP!r*+c(VsRu`B~bLsY0bz7(3rAP_mCL-^y=$vtrhrkkbFf zJRwk2=eVGPzknB8{?&Clk16#yv|q88&IgdGvl&4OL!vqI)QLB)%<>#4gM)+FX!7vM z<1yxglI~lYg+$Ym-jek(VUs3-Ynj;gkXYKxAVyY_ggKl$kwVH0`$9$hzFaG^Pj})5 zvPcs3TJp)NQS&hq0rO)mp5v+0&~x+aQCT7(#o_vQdU|5GcOdh^s|oH@TaQ(6C%wE} zdwbUbN&+JOS%Ub$hZEByHuXa!Vx;SV%H1pOG}C4L+C)nwRK}IN$fC+aKw8@%?whbW;n#Ro44k zMwq)3Z9!c>MWTNF{JzE+`J*Rb9hyYYyS-P&OK4mp_>Yz*Ansutz7kTru?f?t3$g1@ z$9u*VTRIiO{^k48&Og=)J`t~Ui~oo&hR-Xb58;ydbywv(Wx^p!3pq<<_d=9Do~fun zh56Y1`5+0*?CTkp>zf-uwQxak<{+yJbKf)O9H!H4^t`dPssVFwo>)z~WM*Z};pXTI zO*Bc{(XZx^1QMYEv5*g;VRg*wI-mDpqWO(O%b1!QyFjf922ZK%%-)X?`O_AvF~y{> z$g4luTwhP^OoNL+t64RrqN_(UgHJu-t%_l6-y`yo3nV{x4yU0cKYH1-7aU|*iM3uO zLTZhp+B`shfl)Owa!f?CH7T(22jRx$FrA~sPVm=jNBM2H_kJkZ?~Od*%#j};7gd}= zS_-z@E=f;u)pt=uqkwn>DEjhW#;IpTr^NKDHRyT-5SPF%sbRBoKOEAVLb9&8`9*+e zsY4o`0u4C&G$Exi;vJ_yuIDqqg|2WdE7J?SDfQvVPP@(Zp=7L$C2i*C$AG48tdN7H)cP| zDFFm@KeNNpl8p*<8Zm}R6A)?1^f~dPj;RPuXf}{35XfDsllJOP3Nqe#nDd$)V1Xmp zVM?Y zbvYV-^y^)k(~3aXIgg$q@AX|sIv&O8kP=VeHEY03j$)TXiJth{8z2A%*irWuJz7~7 zezVWS?7=7&7Mn%IW=z2~+_bY$S5jP6lAS|Pb88Z;8&M<3*setJK~}yQh)Z*kE_Ksi zqoMy7mp1xw8WC{6V6=uO2+oYS!VpTzBmLB+i0()k1{ZkIbH-d~eI#~>k%w;6+KGk5 zb^Z5}Czov``%KOd|bK|@H%FSuoh6p|DbSHbo!H(-0)><|k$K9WXO zli`rJ)BE&QUj^SozJ%L}K4Zeiyl^-2zvJUQSdILP2U%XS_F|%gB(LSwjkRO&ptfSF zv5CCJU_qu)a!!2BAM*S9UbDLBlK056@ax~RGZQMg-rm47OxZ6{4qqAK@A z10V=+b1|&^Pd*w-Ih-Oa5QewsRoWe|nG5BeNzs|ysJnhq0}QD&>x(hoWb3B_AW;8r zwBd1!5jKorE>z=oGA>MlP`Moi%}MnX;PW0zSakju2LSj@bH)=97gF&0x$ zb|6-G)~%RR7s7tq!TF^v77>7k;SmYs#f+y6YAeX+`_Fs?u@|YMQGjj4HU(YkU|J{n z$08QcC=>pn_7x%rtPpH0cFx$-B86Nw)sv;$mS8)uAY+n3ccXCE^yB8N$$hf+*p%Yj!_X6OKv*M)d_V`Efp1+naX zd;qS@H%ec;2XD0Fp3C(iQx2)*7rlqCQsS(atsprqRK;q9|rI7zqQ;K0=Vm7$I z;agl^UjtwH=nCkYOiWCS5lSFF00{u}hnIV?HW*%gvVIA~c9shsCawCK($P7!>U8F~ zOF#BFfRhm^w!FiDY|i9fIJ5j(1DlNm5WyUmF_^j}3}oA;XyZ*HRAmQYa}6V=@bT() z&0t;k{XFJnK2Q*7`tzL6x0VHsnU_W*qz3ZFDi~bc+)r~1q>oNE-3*X^dL5_igcrI%+%i>TwZrq-dY91rR)&KQDB(Y)7RXanTH zwBOp>e`F*2kr$xWzq&N|&?X}-9S=-aRv23xAfy@|mNU~@F^*>DBt%0e(|Q1Z1Ff$I z11Y3pw~@2z=H?GOq(Jg8Uj$U}7Vxb2fRu{BKoFf+KzY}beutt5km~7u(JtB7hM-B? z0kdq&KffpODwj?Ek8BJ|Pf5y51^ABjpCk}*O~DR0rqk3Er$}G9 z(Qscp!s8`wviI2zm_?vwChVGaY9$qFYB7&mPd>?CW&TH?C>zu%*cqWznupp&&cxS^@K2&S>@kUazV){WpyhDE=L1r3 za|FXRnVCe*e6}+&e;qmqyG?~Qx4P$16A~RfNje*`MsNX*EMVIDIN;!DmqF!&1|E9nm*3W01{j@a*PmvewTZKrBH46rq{2SC!=K`OHz4B z`KMu2oE#}C_sO3D#6&ExX-F$fNt(05z^UWAgx?p0(Oi;d2E7NemJ|4hA!-djG-BRx z;qWJdOd>rO32G-Jh7WuZEBre)6p@E;?|}F^DdeXP^d0zlrGX7jg%- z6F@)!1&ibf_RY!K+!=82V$L$|IG8S zxKl{?-YbutjSX_5Zq@bOkKu` zrXxen8}T?S&7@ajV|@*f?f_I>>uen%NeBQ1a4C45+`})>F?=W-ZRCwls|HI;0-gSw zZ4_3?Q)J#Z)AMMb1hyQVoUrL*dlD0Z0O4ydo+%uly@i&Q1@`%=TW3qpmkNlPggDdo zE&!_5YeRH`FnXd|P|66w5~eWG2MuQ$4!l2XM{3AFEx#P@@Gb(GP}atZT6u0p7M3OI zmUwyDZUzy?Z}LA42$k#|FUj3cttB8lt<7%$<ZCRRAWyMdd_B071vkCUqyFybydaUeM-zz29J3ib{vl73)0HtFZEZA z^QVxjWy|#2zV@cW(oe<~=}bz$<-v-MtI?R$=&Gv&R|3cN!pb~;tf7}$deg;s+k1<) z8l`(FHA5s(d<<+>Fc*bqSAx4$BEct zO;y=O^VO;oimofuJn#Jc;0M(5nO8VlF(rKE2KOuA3%QJoqhRV_5L=7aP3(1&81PeJ&-pH1*d&x)hx=l(^jK`|0l+~xl0PEt}|**z^R z`r*-^Jsli2N{@f1Kir%wbyV6|vv~uVb7EniWx5rqXkt1)DOZM3g~XlR-A%i{+Whb6H=ne9OGnaE8Jj|? zGUr%l(Mz4yjcEd^CzP2YN&sYJjfM16)Y8AkwASFUZutQifcg>=paH%kyP7T2ubn|K zK~}(#m36dBmC@9vWnzepmsI49V3VULe@<5j3yip#7i)Bv7>^;gDVEVb{8UO~JNYO> zC==3TP|k7SD;GKO8F{4=vpw-~Y%Z3AU7qgxC6^%{0QFJ#`9W(Hes!Pdn~y|9#d)%) zo|#!uRCWU4TdbKnwEVPx`{mIWjawB+z6&?!%HsDN+Y7q(K-;7Y$b%5qHMY6Hr^H_f zsrBqClMMY!5bd3vKRq9mq}4}8M(*Jh11B2vY}6?zv&-;2FUh|m*FtfCnCi_=JeH5LtLTDuNy-R8ZYeQ-igT#H#UbYCj@WG%PK!l`@_azV*k`lQ*3UF-Od5PE@g6 z#SyhBfP2@c(ZY)x>rZ@__V>)uXF{IWBZt~ff8yJ$^pxBAel=t;lU5rO$>=s|ySg)^xBYMSaj0<0K4 z=dtJ#rpA}ak~LntT%NW!KOCzg<>**lB5-@PuaaVMhp=DqcCE?hSu@vC^@!twn8Ng1 ztP6cM=Wgl=(m8E5*;bA`oi3HP6`JjbzG>OX9p^Z~5=9s>a0sEhmfQq+A16*f{k_~k zSXoxcDfrI_6BJGMP$u1`?*L`#>E~q790resuv#0RuuHm>Qt`ZAj?~)>8^Pq6>e=R& z)1JHj^-bl&FR@QkVjYKajz7=kLha;tRnOkL$l;>zcV%n6Nw`Ozqhj%R6F%qE8ljh; zZxA~rD;V5F9kftwL9ZufvR{3H6*YI6{v3HS5%)=;BtMIJYUBK-n3b7eN!(TE9IHx# zY_BCQ>f+3@_aZeZ{cTTYMz+&My`r|dA~}i$^+6hZ`emfWYG$cpf=g5W*L&ir6B<>> z-F8m%qK~i%cb~;o&vZrB_rshMMx2p*D-QU@rUP7Yl5Be2qFMrOSaEcqlbN_KH;mXV z+GFDsY761#W&X>lm*;`${@r>~SXxjF+kTZ>e-JxTloLyX;u6`a#rjta_`5xZpueox zJtC8d&UTSRa`e+vFyoEN7IG@zyM{axUueYx$M*`(CwkGZ+9~@GEa%AYYGC@axx3IM z?_{j7_AxQF`H63v-Kf>Ha;a3Y3eJK{EMKmC>`t;+!CshG=|7Glkr+g0CcV=c|BLgt^S333 zMg@CatYlFWLzaM06+)F>X7zXHi9z_nm48swDL8Nwfojoqj71r2EPq@pwH~|5TJEBt z)LyPcj7K=vrs3(^m$Wzg?>iJZji+eRCY_uMoGn~f4iw*hj@~&N7`cgPm7%HDM?- zuwIUYqu>K^!1Nk$#z>xC;yg7;_ZwJ>o>zOuZY+MslqE|M!p4vr!nmITX`6y&>b`oJtTVu6a9K@J zIZf47n5^I4&OgbK1PhwTV>zjaw=nYJQ1Zkko9knc~9QlA$|VGqPusVKehD0W?cb!P;d5csH@uW7N`_c z?ZG;U*zQi;|FrV=pFAw-+mOJl_8-Y2rPW>vv!G z_qy&s?teIr_xrrx@7H+F$K!FVh2kZ@pT>=)4xL-!8Hu%TcydSO&ONTr!&w_N%o2=+ zRK%`%g3IH{1oYFdxY!HpM~`xo@Gk!j$~;$7WWix4sXm{x-J7iT#79PSIXXdMdXr#E zQ!)kLNdJIRc6#~wpmJ!`;mK4o=SlICszI@(l!xY8klOWJsXk<0MTu+wE?bp-ni3q& zWTd9`k}20-d8KoNcRVrfO2c+bX4Q zTf)g^lD11uM?HNO_l)rMx;-B7$2_ErDRX^tv%YcZO1W3unlXv#!FwThWVq!kJomD1 z0>%P~#bqR|mSKUFg3-vCk-g9|wn1N=)+fjnyw7BeVW&JQ4rrm=ALlow8mq3gX?f#D zmelMlQC&-74KnXZsu(S`g-sA9vPi``py5%aqyH=M(NXx4np>c9;v+-xkmXFD(D4JB zcKIUtWK%N9$)l4}j~g$=+fBF~R|W=SY3AbQ1_soT-#PImZ)WM|FlzXoM5#i9Gyi@_ zP#%A2>g)PfT?kn(u(y@FM@ui+~hG?~?` zIZ`Bezm9d2o!w7~Hf3oI)Z-b&-OAgYx^uQ-#vGI5wzEc$4DM&IMUqMi{0tUYzGRXs zppi&4p7QMNar3J3l@D~XoH+ZPqie1CI{G*1Q^hAgl^5jB@>d;shaTp%EO8pnTYhMM ze?z?(|Hq7S$%MAoV=B8`r-T^%H`;gWqnG|+GJH`iVN5gk$eiRC3G;X4%-v_Dq9OVjLzRG3PSox9M=Fgu3U3|A#Xl6Eb4IGB6EzbEda4f8a z3|%B`rLodJTu@hJMk_y%Q#NivAG;6T-1?xXy=383?|V7EzImh;Gw_U3$6yHms=0Lt zn_6rjPsV+y8*wu)To#|p=2s)srn~!+XYZDJ~u$*jtd{)LeDypT;c^*wa zMV*9#IonQM)z#Gnn2BG^eP3Hct^Fb}3q3lC-w|`WhxA*Or3=`_Pg(R#el*N_`;8xR zJ>mBk6G9!+z<+!EO(XvZ3H%{nxyeX)Mws^1O{R%YSwY<+#bQi3sM9S0Gf=saCO;reMCIzer}Rz3s9bp-7J zIXDo~jE#)iyBHAG30l3Ai5&KCsG)%Io`0snO(WEQ6fgA-oUJQko{N(g1hh>MJOKWK zXN?umz4?X**?~0aC5!&Hv-A2M!jI_fj7bPw0vLcw`39|6+90Cu4hL!U^5G#!6wD<( z*Cpg$!o`xNBLOf3G>MMyofYB4GV-mFeFy|jA^TTFOA?CMIN4z6^pD#D&#?FU?f3VP zG#7z_&mXK0LMFhkFgEj+-R<1YY(8rFb~u)bECUJ(}*97phNT#+T8Cwa(?mvZ#EwP z1Qah4YT*+}LV>@i@|-m5O}gLR(M`zb#$LE(?km%$-i8dI$!*gFLk--y(=l{TPEJq| zp7Gv16h534RXV@^CLw?ETqVkfm4Z zRhhX>7Xh~ebwDVlT$IN^@kq6x1)x7J%H@-&7iV0LpRlkc6)B}l`4<0*EFF9CIa?yy`ZO(E+3;{6pU+W1(=m?1c)b!432z4iBDvz-WCSv*2q)m zepWZMkkXnWAETmD{*_fz#l=(a4&EgCqrkQYFEkOI*V<`Rv=XNxl`Dk<`|6Ch-)bov z56%}e(|TP+I2HywcW_2>7g07Qc4#!EE9H;`E$%ytKNk^ku zXQz?0D`1b=;%Txu?q$@#vQs&~8-#njxM+d8T|1NOPQqXoEm!j8he`Y7IH4BN^D%|e zvNA2NB-#HQ{OR=c6t>02kB@Zit*xzak738$>8Mfjz2)+qK+{B$BZX?*X`v{AcSpnQ=?;vemAuDr16>C*aWTqJEa zWWP*@*=Bn&AT%49=&f>E$0zvGwE|%u=6`biFwDns7!1&}EdTrGbDMmLfpu&R#kvEp zVa+53omO%ZK{FX5gc(qJ`H!-)h8?}U8q3S?i9QDGUj10PHsTGktalf;kB}n5$jB&8 zHk23_gaATyeo}dHkZv&psH~|_SU&5XrdH+879s>+1s_&{g|FW~b(IL#7;uGaKe1Yp zz+1N(y*{Te_Yw@G!Tb1}dtC3+;e{V90hXJMu+~GiFayiFh0p9GEBw0rDHCgH+*{#) z0ogOg`v2Lv@V6#*6PtAab`XAs|iAx9Q#>+|BoNI!p3md9jZ50B^zsN zp`WiH5DFh*`n2fs!Z$WHV8=q*Cuxd6(69n4y%~^%TtChy3|`tfJao6Rk`J9*US>6g zl43YT)Uzn3Qu8>c>eNE^CygFJEG{i=xdP9`8azgMQeIu1XKKyy_qz2^JS>>^Jovfo z4>y7@k4zH>(-}YELxn)Fg&G#+%@-9F4TUlMeV9CK{RdVieQJ7oN@1&=-AQ?=be|^SvH9U z>+-Pl18?*F0B;Gs?zyr*kx#8P0cH3JoL%79Ss<@H3o4lM7U z68pVqK?(kIz=Eyp1g<-#ND6j30SAbDL^BU~mDbkQR#gd$7T#3kvT+FRBYce^ZQ7~4 zwtH09J63MeUujR=r&sK>S8XuX{>aEkTtXsE=;>`0(LdT&`jhrfUS2c*2my^uwedt0 z?&Z{FaNJM{`(pK7*mO^nE+RP6 z_h=;J!|(4Y#Q960*0XQWd^83^DOvL+&8LQmKKm6JO~*T*umWkPYtsCUM{9+V-wHv4 z0c3rs^uBxTBCkDDCu0rkzm&zGr!z&xV#PvNZ< zl+Iyt_F{73WbTmFP9=9@Lj(yKI&rTdpzdJZ@@t!R=kFr+j9~BY; zIJhw2Y_It=k!+OEy8P{%cv55ShP>|@F=vTqJEk*oT=-VXB3wQvdTdgMUjsmDM4_m0 z>dx}Y@$oTG+ihRi-Zspzg-V(`(AsTxo}AuzB|r4a)b`9 z>aDjqI_P=W^i{7>jIi9Nr@OwA4>+&u_7|TP$Syt9V_!&55SOLBJD%JXUE%*of(!j_ zf5@_^h*mvT=PG?pH)50!g$vC{Q+H<}wHBZ4Fw>da_%%ftK1cbUS}5F$WMq+|)@I+KW^+1}pmaCTt7{9twe`c*&d zsL)(j(@?`%bDeNB#FQM}H1V?f@zekKcg9(reUyxr{5wHOh)wEuPycK-oL#1#rA?gy zHJ*HYb#oKnlRb6gLQu0(o%{oWQaAfojjSHr&l+E7U zY`3C&G>h)~nb>@cW_+vjj0B9%8)?x`O6{Z3Bkoiy%WQVME_Owu>^g6->T5e~jHahN zzYPd>?nuMZ0yhP7-YdS@xWsStXZ8&U%L>2&2qq?p|dV=*MX)6tQ`0ujl?7YA_x3a7Tfmm?_WY83OQMFHl^2&xN8=& zbUi$oi%PU@;_Tp2{poNxNSAX>N+7d!DG-JDbh}2saIadn?lpk%!<$tGihtyxuXVja zSIz{#WO#(!bG1C;a(Psw&%U*+4W`L5pB$XD(c{sLIaJIYQPGD0Wxg|J{Hj^AbcXHM zFC|m-sd{pF7Och3&)Z;Yi#Q8;7QA-Mq!m){`CBIdKdo@CqB*5*HElQtxCtYE$OoaE#Ce9l9?f?4;kI1sV`Q?<*si@6pA90mW4l+1m zR5AC&u99nf&q|d$y0yc|=N-TH?1u@SrWuTkMVGDI-MEplCgKoB9v%@{Yh2|SVuO3$ z<3}CFY0h5W-t_T0;QG7D+Az0HZZ)=yegFFPdIaAhkU_P1LYs*pjQn9armct}t}83c zid8XONDFlw4%O)f*8f2=rhsyf2kEo;T3cC`>uQXM2u5AEyJ!-`J_eg^U1G$j*$#0Q zMt0J6vq6;(3Ii&UicGx657dpJg> z=yR#Jx4$?E_G6ca_xP(_OUJt^7<`2uj^*`mF47_GT4g8Fk3z0Py7K)Y&BdN5x|wLS zg)F~f&=6YX*@%&1y1r=5xer=;vvx02RLAOHacMuzj*(dDuK81})Z?2*Af;8wt8(LK z=u4MFj!QKGPgQM)dFX**^U*x;$V6(o?J-AldV^0nTk z=&tVR9ZKOrm+Ac6c%FFep9$!b_}bBb-hqmo<{@xjDQ!WT45S^t{g9Z)w{WvON$jlNZBZz+PJT+}4QZWxdyflVj17LiszEicSS)+FMI^jBn>L z#QS&tlXY@#QZLeH?*N18VJ@pO!G|ILrOMBX36{ zOuUwx*Phi%#ffH6t8e@0#ib;=zS|`!@L9SpTyg?US}8R)yQIL#Y%^W^)6=^BpH{q7}5wg%hS+I}2DkpL=_6 zXbqO$Q@H}2g7)caeKjxZoKOR^s}A+a10f0t!%mvnWon-Y>=Hj$-D0^=v6hNwZTu^V zQ)JpmzJ@#DT=mrA@)a%Chw|U`Q06KLAuQfqed0TwNbmS%!N6R&8;@f0q_-`X%4dS3 z1#5&|y95e%+E$cnC5RGv7uMuX82+5<^w*fijeb;?!}v&(989jND9|Q;w|A3XIAd{n z6dSpCq}ElW@>p1~a$>c_sn{ekxm5oPe-VTG`Wy7fh?UsQ8YipR42_E})nu{tQg3sO z5A8#S6UT1P5@uf1*hscNNUGF{4`KNgK6Eu~5%q^_)+1eA{E=fNu^(=*}x8z3Qe?^PMZcZ0|QGJm$94%22V}O z{P7M_w0c5IOzM@TRX>djV%|*S>Ed{$HXn!Gb#oQ?hWY9Zd<7pXM0e~ufk+(aCE2i; zo7@Wey1QGc!)IJhm(@~lH5E4S`3Byrl2>#wt+wPR`9MBg{p6N}S~VcI$gxGoO|kaFweau6~wb$?u4MM~97WAb0x zC%xohpD)uFY4HL@z z3v-%2R#s@CKRO5!HBqb0kf)*~n-yLbydfZ%TRg47;rG%!Y*P=1PhQwU(^KP}tNYtR z-Pq{#{_kWhbCevUBSk_peQVit9!7%{;?G>#A6|X^%bStj&!5+UbB+9{yfHUB zYZvhwgCUf^h9!Une?rEdF2zt>+DH~TBdwAqKxQbns^svK6zpa`-W1x!U+o4cV(8%F zBUpS%51yo!@IQ9;r%8I%8tyEjzDhlpo{kOl0s7@fCpRtfEfbM65Pe#(k)kbZA@s|Z zF9H)gaFF-DP{M0Jy;>>JaH6>9JcT7=SB^raP&nf5y@XI$E?`&z38;``KB81*fm#A+ zO=Dx@4C*&<2Ae7>a`@IV)n>I_j^|}0!Nvlpf0d#)hz-v3wjaz4t!{2ME&0-pco@%t zdek~4w6(6qY)w6*)c#6Sum%{yw{7Y6@ROBj#D|Ai4+R_g+=}iOJcT4o^d=fD1cckU zYDsNoXpkUOZ`maOGkec7QwRZu1X@KzzB$Q9+tnJm1_ktNc#qVHb4`jo-J;?tSCFO}eEKSbS;f zyfo1kO}qPj*T$8w%7kJ|5~O#fx9mmnN#GZ@yxYT%YDiv8LExy-F__Vm41e7ag3KW- z%9SHG;;P5QM`~E(ffE7KxND^QlvQcG|3y^HxBPwwzJ@=F`KmU5t(k<@$h%s)&aa3(S#wjx3hGiZE@zOmhFM* z))!u`4!wX9gNJa=94{~_*<4@GW#{kl=d|jmj@B*#t${bVddYuOcB64#c59r6aHSIY@SlHy{ht|cTS03>t9bo9mP+PB=Iu|V2yrzd}ouu2rcA}xRn z)7RH`zRqg2XXWWBPFgzA(MsHvA5FY@^?3jvXQ?^W^skvvY+*G+;LneV5?M0hL8K>x zA9!}RBUbO1m!GfmXK6I)@F6M4z}k-s4{R;X)&HPsp#cYcUPadQoqX7LZJr&7Hb5PU zcU9UqCpOni$d|8}&iqADl;c#=_6Ks2+hLOE`6)0s-h}C!(cGgQwkrF{EPQ9O?3Wl z!{F#aX0V_TBr#ZG)@syo?#^Wz34CBg1UF@yKYOOrtWO6_6qsu%Ti!iVs4n~#1Y4It zOi@9E7jtey3upD#>M#qv=ekU39|arbe!3sSbU%Bo9#lw7J1>v)anRL1WF|B9@`Cs%p%LrQP;PKDi)Q&!p!$w&nx<=VhVq z4~@y^YR-ovl-=?Pi!v;>H}A$pZB2b!4G0;g0Uu(0Pa^d}RP=99+SIjg{_HTbIE|yA z!wj8XZ5|nvTukd3hzcQzvLqfi-rkea#pjD?lp~kEIKk?3QPRfaSIazguzA)U0s?|` z&6|g_!B^Pw$-v_6rx%wPY^%Mm!Vx}4gY+Zn6zq_2u2!hVLr8~y7<;g}g&E2zUTBY9 z1;Vs2euF}%B)Ro95~gm$BOTk?QH=rqFaBj-SGDyD#|m^`6qh#-{loFNz%kdp7r|D# zXhujx8S&-8erbLnJ6rv&AzYd+Ed9W!Ba^8@BJjg6^G#fx-8hS`7^M>vgN@$q^_q+k%;3&kFC&~+Q# zf>IOoWhB4QyN}Er#~{$zmAm6>pp$aylZ(L@!hiDgC+@Or#yd%Oy;x+WS*AiCH{=%K zLTW=a?b37Z1MadD(-JLu~?LZrZxqv8sKO$!`E^M%}35AtC%|w zJbU)+{KI?>R_UFF4JC!H>Ee4}3{<;n(k>AhIg1Z}&JYSQr*MdtxFoA|q$g;?>=Aah zwZ$hq`0yW4OEL8Cgk7mXM}y3?i6*_9o5;|hnde+}mu7Q(Vz&@;^NNkqRaJpu1Y|u} z0fRvkOFrYb6r%&dF8;~0qbN0k)iu{B{;gs2T?^hPPw#$V;~9U3I@;5Z<=;g|H{wYn z%{;P6+C$Foe#}rV8&TmwQkaa+xvZIkS9EaTWe<;wO8?@G5YA?V*2~E)_a>{ib+?1I z$0>-Jg)OctgO2Uy=H>xkAtp&?c7Poxmd!>B_BuXjD#uUF{B^(!`oqNC(7zmeP|hY|x`(L%;&fd`QrX zZiX1rwi>b{^4QHn73mZ{m-1|6;hMgx{{zCFs>Zin=$W?Yven6y8eb{bcY<=BaCkL| zXAvcoMphujQb+93(ce=~sL_RsI!EPfxq}0GW*? zk3#o%P$NW0p$6Ev82pI3+3>(i)YN}kXuq~F5H&eD84?X<1bn?VJ^0s)Dez?>LM@k` zUa@gnq~&D@>HI)Z&qZ1zjC4Mfw4=e68xidVYj}S+Ah9}eAj_xeEsOlrUM&<;@raq& zX*#P)?eN+KMQyN%t*Dcfw88))( zFnnJ2J-a9h*H{cnpQfgpM`ICIFiaM%c%p^u*0|Hi!UBz1+%=Z1OrmA!2u$GHUt&c8 zn85a$G~&3OvW5onGE;i2SL%(TA18CYOYKLe^}LL15wH}8BtiG4l6LLBJbG+aLv-KVfP~t*gZsZ3sT*J<2c#V$RGe+ zU`9=GQF7|KzpaVu3;0F}&2pJC5(kIaUV>%7{M4i?diPWp>>!4)K?@~!aUTcPqAm(X`tn`YOV0}eTY7;Msz{<9`>i|z8~mjsh*WDUdHCqj3|F6URh?ddhxldOH=!vlndUVzW xpozx`KsNydCb2jB-`lQ#-_4vkHpRh5T>B?hJ&XGewhw_&mRFZ6zGvqDzW^y9YU%(0 literal 0 HcmV?d00001 diff --git a/spec/latest/json-ld-api/index.html b/spec/latest/json-ld-api/index.html index b074c5440..0783c38ec 100644 --- a/spec/latest/json-ld-api/index.html +++ b/spec/latest/json-ld-api/index.html @@ -5050,7 +5050,6 @@

Open Issues

-

diff --git a/spec/latest/json-ld-framing/index.html b/spec/latest/json-ld-framing/index.html index b9d8785da..699f7f11f 100644 --- a/spec/latest/json-ld-framing/index.html +++ b/spec/latest/json-ld-framing/index.html @@ -807,7 +807,7 @@

Framing Named Graphs

be obtained by the specification's algorithms.

In algorithm steps that describe operations on keywords, those steps - also apply to keyword aliases.

+ also apply to keyword aliases.

Implementers can partially check their level of conformance to this specification by successfully passing the test cases of the JSON-LD test @@ -1576,7 +1576,6 @@

Open Issues

-

From b3338349b81cb5d38f60e3c03ec552921c87c716 Mon Sep 17 00:00:00 2001 From: Gregg Kellogg Date: Sat, 28 Apr 2018 11:28:43 -0700 Subject: [PATCH 2/6] Update does with CG-FINAL bibliography references. --- spec/CG-FINAL/json-ld-api/20180507/index.html | 122 +++++++++--------- .../json-ld-framing/20180507/index.html | 98 +++++++------- spec/CG-FINAL/json-ld/20180507/index.html | 120 ++++++++--------- 3 files changed, 170 insertions(+), 170 deletions(-) diff --git a/spec/CG-FINAL/json-ld-api/20180507/index.html b/spec/CG-FINAL/json-ld-api/20180507/index.html index eaf0dd6da..47c2d9b2f 100644 --- a/spec/CG-FINAL/json-ld-api/20180507/index.html +++ b/spec/CG-FINAL/json-ld-api/20180507/index.html @@ -549,41 +549,6 @@ JSON-LD 1.1 Processing Algorithms and API - - - @@ -1316,9 +1316,9 @@

Set of Documents

JSON for Linking Data W3C Community Group:

@@ -1339,7 +1339,7 @@

Set of Documents

To understand the basics in this specification you must first be familiar with JSON, which is detailed in [RFC7159]. You must also understand the - JSON-LD syntax defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all + JSON-LD syntax defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all of the algorithms in this document. To understand the API and how it is intended to operate in a programming environment, it is useful to have working knowledge of the JavaScript programming language [ECMASCRIPT-6.0] and @@ -1379,7 +1379,7 @@

1.2 Terminology unordered by default. While order is preserved in regular JSON arrays, it is not in regular JSON-LD arrays unless specifically defined (see - Sets and Lists in + Sets and Lists in the JSON-LD Syntax specification [JSON-LD11CG]).
JSON object
In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or @@ -1451,7 +1451,7 @@

1.2 Terminology IRI contained within a common vocabulary identified by prefix.

context
A a set of rules for interpreting a JSON-LD document as specified in - The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+ The Context of the JSON-LD Syntax specification [JSON-LD11CG].
datatype IRI
A datatype IRI as specified by [RDF11-CONCEPTS].
@@ -1526,7 +1526,7 @@

1.2 Terminology language-tagged string.
keyword
A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] - in the section titled Syntax Tokens and Keywords.
+ in the section titled Syntax Tokens and Keywords.
language map
An language map is a JSON object value of a term defined with @container set to @language, whose keys MUST be strings representing @@ -1544,7 +1544,7 @@

1.2 Terminology linked data graph
A labeled directed graph, i.e., a set of nodes connected by edges, - as specified in the Data Model + as specified in the Data Model section of the JSON-LD specification [JSON-LD11CG]. A linked data graph is a generalized representation of an RDF graph @@ -2833,7 +2833,7 @@

5.1.2 Algorithm active context, an active property, and an element to be expanded. The optional input is the flag frame expansion the allows - special forms of input used for frame expansion. + special forms of input used for frame expansion. To begin, the active property is set to null, and element is set to the JSON-LD input. If not passed, the frame expansion flag is set to false.

@@ -4742,7 +4742,7 @@

7.1.1 Overview node in a single dictionary. In the next step, the node map is converted to a JSON-LD document in - flattened document form. + flattened document form. Finally, if a context has been passed, the flattened document is compacted using the Compaction algorithm before being returned.

@@ -7014,7 +7014,7 @@

Example 

F. References §

F.1 Normative references §

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[IEEE-754-2008]
IEEE 754-2008 Standard for Floating-Point Arithmetic. Institute of Electrical and Electronics Engineers. 2008. URL: http://standards.ieee.org/findstds/standard/754-2008.html
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ -
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld/ +
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld/20180507/
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
[RDF11-MT]
RDF 1.1 Semantics. Patrick Hayes; Peter Patel-Schneider. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-mt/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 @@ -7026,8 +7026,8 @@

Example 

F.2 Informative references §

[ECMASCRIPT-6.0]
ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html
[JSON-LD-API]
JSON-LD 1.0 Processing Algorithms and API. Markus Lanthaler; Gregg Kellogg; Manu Sporny. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld-api/
[JSON-LD-TESTS]
JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ -
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-api/ -
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-framing/ +
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-api/20180507/ +
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180507/
[promises-guide]
Writing Promise-Using Specifications. Domenic Denicola. W3C. 16 February 2016. Finding of the W3C TAG. URL: https://www.w3.org/2001/tag/doc/promises-guide
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ diff --git a/spec/CG-FINAL/json-ld-framing/20180507/index.html b/spec/CG-FINAL/json-ld-framing/20180507/index.html index 3a58e21ee..2f780950f 100644 --- a/spec/CG-FINAL/json-ld-framing/20180507/index.html +++ b/spec/CG-FINAL/json-ld-framing/20180507/index.html @@ -869,30 +869,30 @@ "localBiblio": { "JSON-LD11CG": { "title": "JSON-LD 1.1", - "href": "https://json-ld.org/spec/latest/json-ld/", + "href": "https://json-ld.org/spec/CG-FINAL/json-ld/20180507/", "authors": [ "Gregg Kellogg" ], "publisher": "W3C", - "status": "CG Draft" + "status": "CG Final" }, "JSON-LD11CG-API": { "title": "JSON-LD 1.1 Processing Algorithms and API", - "href": "https://json-ld.org/spec/latest/json-ld-api/", + "href": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180507/", "authors": [ "Gregg Kellogg" ], "publisher": "W3C", - "status": "CG Draft" + "status": "CG Final" }, "JSON-LD11CG-FRAMING": { "title": "JSON-LD 1.1 Framing", - "href": "https://json-ld.org/spec/latest/json-ld-framing/", + "href": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180507/", "authors": [ "Gregg Kellogg" ], "publisher": "W3C", - "status": "CG Draft" + "status": "CG Final" }, "JSON-LD-TESTS": { "title": "JSON-LD 1.1 Test Suite", @@ -1112,16 +1112,16 @@ "url": "https://tools.ietf.org/html/rfc7159" }, { - "id": "https://json-ld.org/spec/latest/json-ld/", + "id": "https://json-ld.org/spec/CG-FINAL/json-ld/20180507/", "type": "TechArticle", "name": "JSON-LD 1.1", - "url": "https://json-ld.org/spec/latest/json-ld/" + "url": "https://json-ld.org/spec/CG-FINAL/json-ld/20180507/" }, { - "id": "https://json-ld.org/spec/latest/json-ld-api/", + "id": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180507/", "type": "TechArticle", "name": "JSON-LD 1.1 Processing Algorithms and API", - "url": "https://json-ld.org/spec/latest/json-ld-api/" + "url": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180507/" }, { "id": "https://heycam.github.io/webidl/", @@ -1184,10 +1184,10 @@ "url": "https://www.w3.org/TR/rdf-schema/" }, { - "id": "https://json-ld.org/spec/latest/json-ld-framing/", + "id": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180507/", "type": "TechArticle", "name": "JSON-LD 1.1 Framing", - "url": "https://json-ld.org/spec/latest/json-ld-framing/" + "url": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180507/" } ] } @@ -1265,9 +1265,9 @@

Set of Documents

JSON for Linking Data W3C Community Group:

@@ -1342,7 +1342,7 @@

1.3 Terminology unordered by default. While order is preserved in regular JSON arrays, it is not in regular JSON-LD arrays unless specifically defined (see - Sets and Lists in + Sets and Lists in the JSON-LD Syntax specification [JSON-LD11CG]).

JSON object
In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or @@ -1409,7 +1409,7 @@

1.3 Terminology 
context
A a set of rules for interpreting a JSON-LD document as specified in - The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+ The Context of the JSON-LD Syntax specification [JSON-LD11CG].

default graph
The default graph is the only graph in a JSON-LD document which has no graph name. @@ -1453,7 +1453,7 @@

1.3 Terminology language-tagged string.

keyword
A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] - in the section titled Syntax Tokens and Keywords.
+ in the section titled Syntax Tokens and Keywords.

language-tagged string
A language-tagged string consists of a string and a non-empty language @@ -1465,7 +1465,7 @@

1.3 Terminology linked data graph
A labeled directed graph, i.e., a set of nodes connected by edges, - as specified in the Data Model + as specified in the Data Model section of the JSON-LD specification [JSON-LD11CG]. A linked data graph is a generalized representation of an RDF graph @@ -1575,7 +1575,7 @@

1.3.1 Algorithm Terms The JSON-LD data structure that is produced as output by the algorithm.

map of flattened subjects
A map of subjects that is the result of the - Node Map Generation algorithm.
+ Node Map Generation algorithm.

object embed flag
A flag specifying that node objects should be directly embedded in the output, instead of being referred to by their IRI.
@@ -1642,7 +1642,7 @@

1.4 Typograph

2.1 Framing §

This section is non-normative.

Framing is used to shape the data in a JSON-LD document, using an example frame document which is used to both match the - flattened + flattened data and show an example of how the resulting data should be shaped. Matching is performed by using properties present in in the frame to find objects in the data that share common values. Matching can be done @@ -1803,7 +1803,7 @@

2.2 Default content&nbs

2.3 Framing Flags §

-

Framing can be controlled using API options, +

Framing can be controlled using API options, or by adding framing keywords within the frame as described in section 4.1 Syntax Tokens and Keywords.

@@ -2153,7 +2153,7 @@

4.1 Syntax T
@null
Used in Framing when a value of null should be returned, which would otherwise be removed when - Compacting.
+ Compacting.
@omitDefault
Used in Framing to override the value of omit default flag within a specific frame. @@ -2173,7 +2173,7 @@

4.2 Framing Frame).

-

Framing makes use of the Node Map Generation algorithm +

Framing makes use of the Node Map Generation algorithm to place each object defined in the JSON-LD document into a map of flattened subjects, allowing them to be operated upon by the Framing algorithm.

@@ -2181,7 +2181,7 @@

4.2 Framing 4.2.1 Framing Requirements §

A valid JSON-LD Frame is a superset of a valid JSON-LD document, allowing additional content, which is preserved through expansion. - The Grammar defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG] + The Grammar defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG] is extended as follows:

@@ -2803,7 +2803,7 @@

application/ld-frame+json JsonLdProcessor { static Promise<JsonLdDictionary> frame(JsonLdInput input, (JsonLdDictionary or USVString) frame, - optional JsonLdOptions? options); + optional JsonLdOptions? options); }; dictionary JsonLdFramingError { JsonLdFramingErrorCode code; @@ -2813,7 +2813,7 @@

application/ld-frame+json "invalid frame", "invalid @embed value" }; -dictionary JsonLdOptions { +dictionary JsonLdOptions { (JsonLdEmbed or boolean) embed = "@last"; boolean explicit = false; boolean omitDefault = false; @@ -2950,8 +2950,8 @@

application/ld-frame+json 

G. References §

G.1 Normative references §

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ -
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld/ -
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-api/ +
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld/20180507/ +
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-api/20180507/
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987 @@ -2959,7 +2959,7 @@

application/ld-frame+json [WEBIDL]
Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/

G.2 Informative references §

[ECMASCRIPT-6.0]
ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html
[JSON-LD-TESTS]
JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ -
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Draft. URL: https://json-ld.org/spec/latest/json-ld-framing/ +
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180507/
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
\ No newline at end of file diff --git a/spec/CG-FINAL/json-ld/20180507/index.html b/spec/CG-FINAL/json-ld/20180507/index.html index 373d1d92f..3a6369232 100644 --- a/spec/CG-FINAL/json-ld/20180507/index.html +++ b/spec/CG-FINAL/json-ld/20180507/index.html @@ -142,28 +142,6 @@ JSON-LD 1.1 - - - @@ -1244,7 +1244,7 @@

JSON-LD 1.1 Processing Algorithms and API

-

Final Community Group Report

+

Final Community Group Report

@@ -1259,13 +1259,13 @@

Final Community Group Report <
Former editors:
Markus Lanthaler (Graz University of Technology) (v1.0)
Manu Sporny (Digital Bazaar) (v1.0)
Authors:
Dave Longley (Digital Bazaar) (v1.0)
Gregg Kellogg (Spec-Ops) (v1.0 and v1.1)
Markus Lanthaler (Graz University of Technology) (v1.0)
Manu Sporny (Digital Bazaar) (v1.0)
Niklas Lindström (v1.0)
Participate:
- GitHub json-ld/json-ld.org + GitHub json-ld/json-ld.org
- File a bug + File a bug
- Commit history + Commit history
- Pull requests + Pull requests

@@ -1316,9 +1316,9 @@

Set of Documents

JSON for Linking Data W3C Community Group:

@@ -1339,7 +1339,7 @@

Set of Documents

To understand the basics in this specification you must first be familiar with JSON, which is detailed in [RFC7159]. You must also understand the - JSON-LD syntax defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all + JSON-LD syntax defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all of the algorithms in this document. To understand the API and how it is intended to operate in a programming environment, it is useful to have working knowledge of the JavaScript programming language [ECMASCRIPT-6.0] and @@ -1379,7 +1379,7 @@

1.2 Terminology unordered by default. While order is preserved in regular JSON arrays, it is not in regular JSON-LD arrays unless specifically defined (see - Sets and Lists in + Sets and Lists in the JSON-LD Syntax specification [JSON-LD11CG]).
JSON object
In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or @@ -1451,7 +1451,7 @@

1.2 Terminology IRI contained within a common vocabulary identified by prefix.

context
A a set of rules for interpreting a JSON-LD document as specified in - The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+ The Context of the JSON-LD Syntax specification [JSON-LD11CG].
datatype IRI
A datatype IRI as specified by [RDF11-CONCEPTS].
@@ -1526,7 +1526,7 @@

1.2 Terminology language-tagged string.
keyword
A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] - in the section titled Syntax Tokens and Keywords.
+ in the section titled Syntax Tokens and Keywords.
language map
An language map is a JSON object value of a term defined with @container set to @language, whose keys MUST be strings representing @@ -1544,7 +1544,7 @@

1.2 Terminology linked data graph
A labeled directed graph, i.e., a set of nodes connected by edges, - as specified in the Data Model + as specified in the Data Model section of the JSON-LD specification [JSON-LD11CG]. A linked data graph is a generalized representation of an RDF graph @@ -2833,7 +2833,7 @@

5.1.2 Algorithm active context, an active property, and an element to be expanded. The optional input is the flag frame expansion the allows - special forms of input used for frame expansion. + special forms of input used for frame expansion. To begin, the active property is set to null, and element is set to the JSON-LD input. If not passed, the frame expansion flag is set to false.

@@ -4742,7 +4742,7 @@

7.1.1 Overview node in a single dictionary. In the next step, the node map is converted to a JSON-LD document in - flattened document form. + flattened document form. Finally, if a context has been passed, the flattened document is compacted using the Compaction algorithm before being returned.

@@ -6491,8 +6491,8 @@

9.4.2 JsonLdErrorCode <http://example.org/myresource> <http://example.org/my-schema#main_label> "This is the main label for my resource". <http://example.org/myresource> <http://example.org/my-schema#other_label> "This is the other label". -
Issue 333: Support JSON values that aren't mappedapideferspec-designsyntax

This has already been discussed several times usingvarious terms.. the most recent request has come from David Janes on the mailing list. The basic idea is to support JSON values/subtrees that aren't mapped to an IRI in the context. They should survive algorithmic transformations (basically without being touched at all).

-
Issue 338: Option to compact terms but not valuesapidefer

_This was raised by Fabian Steeg:_

+
Issue 333: Support JSON values that aren't mappedapideferspec-designsyntax

This has already been discussed several times usingvarious terms.. the most recent request has come from David Janes on the mailing list. The basic idea is to support JSON values/subtrees that aren't mapped to an IRI in the context. They should survive algorithmic transformations (basically without being touched at all).

+
Issue 338: Option to compact terms but not valuesapidefer

_This was raised by Fabian Steeg:_

The JSON-LD API document states: "Expansion has two important goals: removing any contextual information from the document, and ensuring all values are represented in a regular form."

Is there a way to achieve only the second goal, the regular form, but with compact terms? Using compaction with compactArrays=false is pretty close, but there is still at least one thing that is irregular and causing issues for me.

@@ -6544,7 +6544,7 @@

9.4.2 JsonLdErrorCode

So I guess I'm looking for something like a compactValues=false option.

Is there some way to get this output?

-
Issue 357: Lists shared between graphs are not correctly serializedapispec-bug

_Reported by @afs:_

+
Issue 357: Lists shared between graphs are not correctly serializedapispec-bug

_Reported by @afs:_

We are encountering an issue when converting RDF Datasets to JSON-LD.

The problem is with blank nodes that are shared between graphs and lists.

In TriG (yes, this is a synthetic reduced test case that captures a
@@ -6612,7 +6612,7 @@

9.4.2 JsonLdErrorCode

If it is all the same graph (s/:G1/:G/), the RDF dataset structure is
correctly serialized.

Andy

-
Issue 368: JSON-LD 1.1 Feature Request: Object-level @languageapideferspec-designsyntax

See: digitalbazaar/jsonld.js#72

+
Issue 368: JSON-LD 1.1 Feature Request: Object-level @languageapideferspec-designsyntax

See: digitalbazaar/jsonld.js#72

It would be helpful to have the ability to use @language within an object as a shorthand for "@context": {"@language": "..."} ... for instance... make:

{
   "@language": "en",
@@ -6623,7 +6623,7 @@ 
9.4.2 JsonLdErrorCode
   "@context": {"@language": "en"}, 
   "displayName": "foo"
 }
-
Issue 371: JSON-LD 1.1 Feature Request: New @label keywordapideferspec-designsyntax

In the spirit of "Labeling Everything" (http://patterns.dataincubator.org/book/label-everything.html) ... it would be worthwhile, IMO, for JSON-LD to provide a basic @Label keyword for use both in @context and nodes. It's largely syntactic sugar but would be useful.

+
Issue 371: JSON-LD 1.1 Feature Request: New @label keywordapideferspec-designsyntax

In the spirit of "Labeling Everything" (http://patterns.dataincubator.org/book/label-everything.html) ... it would be worthwhile, IMO, for JSON-LD to provide a basic @Label keyword for use both in @context and nodes. It's largely syntactic sugar but would be useful.

For example:

{
   "@context": {
@@ -6635,7 +6635,7 @@ 
9.4.2 JsonLdErrorCode
 
Which would expand to:

 
_:c14n0 <http://www.w3.org/2000/01/rdf-schema#label> "A Simple Label" .
-
Issue 397: JSON-LD 1.1 Feature Request: support @values for describing multidimensional containers (list of lists)apideferspec-designsyntax

Problem description §

+
Issue 397: JSON-LD 1.1 Feature Request: support @values for describing multidimensional containers (list of lists)apideferspec-designsyntax

Problem description §

Many JSON specs existed before JSON-LD. A couple of these specs may not be compatible with JSON-LD as they contain multidimensional containers, such as GeoJSON.

Example of a multidimensional array:

[ [3.1,51.06,30],
@@ -6686,7 +6686,7 @@ 
Example geo:longitude "3.1056976318359375"^^xsd:double ;
       geo:latitude "51.063434090307574"^^xsd:double .
 _:b2 rdf:rest rdf:nil .
-
Issue 402: Relax the colliding keywords constraint for @typeapideferspec-design

I want the following:

+
Issue 402: Relax the colliding keywords constraint for @typeapideferspec-design

I want the following:

{
   "@context": {
     "type": "@type",
@@ -6706,10 +6706,10 @@ 
Example "profile": "cov:GridCoverage"
 }

I understand that this restriction probably makes sense for other keywords, but could it do any harm for @type?

-
Issue 434: Streaming Profiles for JSON-LD to/from RDFapideferspec-design

There have been some discussions on what it would take to be able to do a streaming parse of JSON-LD into Quads, and similarly to generate compliant JSON-LD from a stream of quads. Describing these as some kind of a profile would be useful for implementations that expect to work in a streaming environment, when it's not feasible to work on an entire document basis.

+
Issue 434: Streaming Profiles for JSON-LD to/from RDFapideferspec-design

There have been some discussions on what it would take to be able to do a streaming parse of JSON-LD into Quads, and similarly to generate compliant JSON-LD from a stream of quads. Describing these as some kind of a profile would be useful for implementations that expect to work in a streaming environment, when it's not feasible to work on an entire document basis.

As currently stated, the JSON-LD to RDF algorithm requires expanding the document and creating a node map. A profile of JSON-LD which used a flattened array of node objects, where each node object could be independently expanded and no flattening is required could facilitate deserializing an arbitrarily long JSON-LD source to Quads. (Some simplifying restrictions on shared lists may be necessary). Outer document is an object, containing @context and @graph only; obviously, this only will work for systems that can access key/values in order, and for systems that ensure that @context comes lexically before @graph in the output. Obviously, only implementations that can read and write JSON objects with key ordering intact will be able to take advantage of such streaming capability.

Fo serializing RDF to JSON-LD, expectations on the grouping of quads with the same graph name and subject are necessary to reduce serialization cost, and marshaling components of RDF Lists is likely not feasible. Even if graph name/subject grouping is not maintained in the input, the resulting output will still represent a valid JSON-LD document, although it may require flattening for further processing. (Many triple stores will, in fact, generate statements/quads properly grouped, so this is likely not an issue in real world applications).

-
Issue 460: "Stratified" or "Dictionaried" API featureapideferspec-design

Hi there,

+
Issue 460: "Stratified" or "Dictionaried" API featureapideferspec-design

Hi there,

I was looking for a way to access properties in a JSON-LD document based on triples (to patch the document). This would mean having a view which creates a dictionary for a given document. The term Normalisation is already used, but this approach would be close to the way https://github.com/paularmstrong/normalizr. D3 uses https://github.com/d3/d3-hierarchy/blob/master/README.md#stratify in a slightly different way but with the same general intent.

The goal would be to be able to address document values with this syntax stratified_doc[triple.subject][triple.predicate] or even better stratified[triple.graph][triple.subject][triple.predicate].

This could also be a @stratified parameter for expansion.

@@ -6774,7 +6774,7 @@

Example 
Issue 507: JSON-LD 1.1: method to require {"id": "uri"} resource compaction resultapidefer

Issue: The compaction algorithm prefers the most compact format, which for resources without relationships is a string containing the URI. This causes problems in systems that cannot handle arrays of mixed data types (for example ElasticSearch) when there are also resources that have relationships, resulting in both objects and strings in the same array.

+
Issue 507: JSON-LD 1.1: method to require {"id": "uri"} resource compaction resultapidefer

Issue: The compaction algorithm prefers the most compact format, which for resources without relationships is a string containing the URI. This causes problems in systems that cannot handle arrays of mixed data types (for example ElasticSearch) when there are also resources that have relationships, resulting in both objects and strings in the same array.

For example:

"seeAlso": [
     "http://example.org/reference1",
@@ -6788,14 +6788,14 @@ 
Example "id": "http://example.org/reference2", "format": "text/html"}
   ]
-
Issue 512: @type as @container:@set?apispec-design

The purpose of the @container:@set functionality (AFAIU) is to ensure that the output is consistent in shape. Thus if there can ever be multiple values, the structure is always an array.

+
Issue 512: @type as @container:@set?apispec-design

The purpose of the @container:@set functionality (AFAIU) is to ensure that the output is consistent in shape. Thus if there can ever be multiple values, the structure is always an array.

There are two situations in which this functionality could be desirable but is currently not possible:

  1. @type As it's a keyword, we can only alias it (e.g. as type) but not define it to have @container:@set functionality. Meaning that there's a gotcha waiting to happen for ontologies that require or use multiple classes for a single resource instance. See playground
  2. @context Less useful, but @context will also compact to a single string/object when there might be multiple contexts. See playground

@context modifying itself seems particularly strange, but the inconsistency for @type seems solvable if the restrictions in its definition were loosened?

-
Issue 526: precedence of @vocab for compaction too strong?apideferspec-design

This is related to #235: When I have the following document:

+ -
Issue 530: Losing Last Element in RDF Listapiquestion

We have web application that needs to be able to modify RDF lists from a triple store and propagate the changes back. To do this, we are utilizing jsonld-java to serialize the RDF into JSON-LD, modifying it in the web app, and then sending it back to be deserialized and stored in the triple store. Originally, we were using blank nodes like the ones shown in Turtle below.

+
Issue 530: Losing Last Element in RDF Listapiquestion

We have web application that needs to be able to modify RDF lists from a triple store and propagate the changes back. To do this, we are utilizing jsonld-java to serialize the RDF into JSON-LD, modifying it in the web app, and then sending it back to be deserialized and stored in the triple store. Originally, we were using blank nodes like the ones shown in Turtle below.

<http://example.com> <http://example.com/property> _:a .
 _:a a <http://www.w3.org/1999/02/22-rdf-syntax-ns#List> ;
     <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "a" ;
@@ -6870,7 +6870,7 @@ 
Example #277   seems to be the point where the implementation changed from serializing lists in the manner we expect to this new compact way. Is there any way we can get around this so that the last blank node of a list is not collapsed?
-
Issue 542: Feature request: Could framing return properties in the order listed by the frame? apideferframing

Currently it appears that properties are sorted into alphabetical order after any JSON-LD operation (compaction, framing).

+
Issue 542: Feature request: Could framing return properties in the order listed by the frame? apideferframing

Currently it appears that properties are sorted into alphabetical order after any JSON-LD operation (compaction, framing).

In the context of framing, this is sometimes a nice feature, since it means that after framing multiple input JSON files, the JSON data is at least in a consistent order.

I understand that ordering is semantically meaningless, but as framing exists to turn the graph (which could correspond to multiple different trees) into a predictable JSON tree as a convenience for developers, it seems natural to me that if an explicit ordering is given in the frame, that the algorithm would respect that order rather than alphabetize. For example, if my data is:

{
@@ -6893,9 +6893,9 @@ 
Example 
Issue 548: Use version 2.0 instead of 1.1apideferspec-designsyntax
Comments at TPAC suggested that as our work is a breaking change (causing 1.0 processors that are not 1.1 compatible to intentionally break when they see "@version": 1.1), semantic versioning would suggest that we use a major release number, rather than a minor number.

+  
Issue 548: Use version 2.0 instead of 1.1apideferspec-designsyntax
Comments at TPAC suggested that as our work is a breaking change (causing 1.0 processors that are not 1.1 compatible to intentionally break when they see "@version": 1.1), semantic versioning would suggest that we use a major release number, rather than a minor number.

 
This could impact a potential WG, which may want to make further changes, and then be in the place of using either 2.1 or 3.0, which is odd given that the previous recommendation is 1.0.

-  
In some situations it is important/necessary to include the base direction of a text, alongside its language; see the “Requirements for Language and Direction Metadata in Data Formats” for further details. In practice, in a vanilla JSON, it would require something like:

+  
In some situations it is important/necessary to include the base direction of a text, alongside its language; see the “Requirements for Language and Direction Metadata in Data Formats” for further details. In practice, in a vanilla JSON, it would require something like:

 
"title": [ { "value": "Moby Dick", "lang": "en" },
            { "value": "موبي ديك", "lang": "ar"  "dir": "rtl"}
          ]  
@@ -6919,7 +6919,7 @@ 
Example @BigBlueHat @r12a

-  
Issue 595: Native support for schema:ListItemapideferspec-designsyntax
Per a suggestion by @danbri, we may want to add a container type, similar to @list for encoding schema:ItemList serializations, when the values are schema:ListItem and order is set through schema:position. ItemList can be used with text values as well, but this is already reasonably supported natively.

+  
Issue 595: Native support for schema:ListItemapideferspec-designsyntax
Per a suggestion by @danbri, we may want to add a container type, similar to @list for encoding schema:ItemList serializations, when the values are schema:ListItem and order is set through schema:position. ItemList can be used with text values as well, but this is already reasonably supported natively.

 
Markup might look like the following:

 
{
   "@context": {
@@ -6979,7 +6979,7 @@ 
Example 
Issue 589: JSON-LD version on playgroundplayground
During the last meeting it was resolved to have one playground for 1.0 and 1.1 processing.  Some notes on that related to jsonld.js:

+  
Issue 589: JSON-LD version on playgroundplayground
During the last meeting it was resolved to have one playground for 1.0 and 1.1 processing.  Some notes on that related to jsonld.js:

 
    
 
  • 0.4.x passes older 1.0 test suites
    • 
 
  • 0.4.x does not pass more recent tests added for 1.0
    • 
@@ -7014,7 +7014,7 @@ 
    Example 
    F. References §
    F.1 Normative references §
    [BCP47]
    Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
 
    [IEEE-754-2008]
    IEEE 754-2008 Standard for Floating-Point Arithmetic.  Institute of Electrical and Electronics Engineers. 2008. URL: http://standards.ieee.org/findstds/standard/754-2008.html
 
    [JSON-LD]
    JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
-
    [JSON-LD11CG]
    JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld/20180507/
+
    [JSON-LD11CG]
    JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld/20180607/
 
    [RDF-CONCEPTS]
    Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
 
    [RDF11-MT]
    RDF 1.1 Semantics. Patrick Hayes; Peter Patel-Schneider. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-mt/
 
    [RFC2119]
    Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
@@ -7026,8 +7026,8 @@ 
    Example 
    F.2 Informative references §
    [ECMASCRIPT-6.0]
    ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html
 
    [JSON-LD-API]
    JSON-LD 1.0 Processing Algorithms and API. Markus Lanthaler; Gregg Kellogg; Manu Sporny. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld-api/
 
    [JSON-LD-TESTS]
    JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/
-
    [JSON-LD11CG-API]
    JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-api/20180507/
-
    [JSON-LD11CG-FRAMING]
    JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180507/
+
    [JSON-LD11CG-API]
    JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/
+
    [JSON-LD11CG-FRAMING]
    JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/
 
    [promises-guide]
    Writing Promise-Using Specifications. Domenic Denicola. W3C. 16 February 2016. Finding of the W3C TAG. URL: https://www.w3.org/2001/tag/doc/promises-guide
 
    [RDF-SCHEMA]
    RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
 
    [RDF11-CONCEPTS]
    RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
diff --git a/spec/CG-FINAL/json-ld-framing/20180507/index.html b/spec/CG-FINAL/json-ld-framing/20180607/index.html
similarity index 96%
rename from spec/CG-FINAL/json-ld-framing/20180507/index.html
rename to spec/CG-FINAL/json-ld-framing/20180607/index.html
index 11cd75b00..922847e91 100644
--- a/spec/CG-FINAL/json-ld-framing/20180507/index.html
+++ b/spec/CG-FINAL/json-ld-framing/20180607/index.html
@@ -1,4 +1,4 @@
-
+
 
 
 
diff --git a/spec/FCGS/json-ld-api/20180607/index.html b/spec/FCGS/json-ld-api/20180607/index.html
index 20399bef0..d0feb8694 100644
--- a/spec/FCGS/json-ld-api/20180607/index.html
+++ b/spec/FCGS/json-ld-api/20180607/index.html
@@ -861,7 +861,7 @@
   "localBiblio": {
     "JSON-LD11CG": {
       "title": "JSON-LD 1.1",
-      "href": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/",
+      "href": "https://json-ld.org/spec/FCGS/json-ld/20180607/",
       "authors": [
         "Gregg Kellogg"
       ],
@@ -870,7 +870,7 @@
     },
     "JSON-LD11CG-API": {
       "title": "JSON-LD 1.1 Processing Algorithms and API",
-      "href": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/",
+      "href": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/",
       "authors": [
         "Gregg Kellogg"
       ],
@@ -879,7 +879,7 @@
     },
     "JSON-LD11CG-FRAMING": {
       "title": "JSON-LD 1.1 Framing",
-      "href": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/",
+      "href": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/",
       "authors": [
         "Gregg Kellogg"
       ],
@@ -1104,10 +1104,10 @@
       "url": "https://tools.ietf.org/html/rfc7159"
     },
     {
-      "id": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/",
+      "id": "https://json-ld.org/spec/FCGS/json-ld/20180607/",
       "type": "TechArticle",
       "name": "JSON-LD 1.1",
-      "url": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/"
+      "url": "https://json-ld.org/spec/FCGS/json-ld/20180607/"
     },
     {
       "id": "https://tools.ietf.org/html/rfc3987",
@@ -1200,10 +1200,10 @@
       "url": "https://www.w3.org/TR/rdf11-concepts/"
     },
     {
-      "id": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/",
+      "id": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/",
       "type": "TechArticle",
       "name": "JSON-LD 1.1 Processing Algorithms and API",
-      "url": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/"
+      "url": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/"
     },
     {
       "id": "https://www.w3.org/TR/rdf-schema/",
@@ -1230,10 +1230,10 @@
       "url": "https://tools.ietf.org/html/rfc6839"
     },
     {
-      "id": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/",
+      "id": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/",
       "type": "TechArticle",
       "name": "JSON-LD 1.1 Framing",
-      "url": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/"
+      "url": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/"
     }
   ]
 }
@@ -1316,9 +1316,9 @@ 
    Set of Documents
    
       JSON for Linking Data W3C Community Group:
    
 
     
   
    
 
@@ -1339,7 +1339,7 @@ 
    Set of Documents
    
 
   
    To understand the basics in this specification you must first be familiar with
     JSON, which is detailed in [RFC7159]. You must also understand the
-    JSON-LD syntax defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all
+    JSON-LD syntax defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG], which is the base syntax used by all
     of the algorithms in this document. To understand the API and how it is
     intended to operate in a programming environment, it is useful to have working
     knowledge of the JavaScript programming language [ECMASCRIPT-6.0] and
@@ -1379,7 +1379,7 @@ 
    1.2 Terminology unordered by default. While order is
     preserved in regular JSON arrays, it is not in regular JSON-LD arrays
     unless specifically defined (see
-    Sets and Lists in
+    Sets and Lists in
     the JSON-LD Syntax specification [JSON-LD11CG]).

JSON object
In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or @@ -1451,7 +1451,7 @@

1.2 Terminology IRI contained within a common vocabulary identified by prefix.

context
A a set of rules for interpreting a JSON-LD document as specified in - The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+ The Context of the JSON-LD Syntax specification [JSON-LD11CG].

datatype IRI
A datatype IRI as specified by [RDF11-CONCEPTS].
@@ -1526,7 +1526,7 @@

1.2 Terminology language-tagged string.
keyword
A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] - in the section titled Syntax Tokens and Keywords.
+ in the section titled Syntax Tokens and Keywords.
language map
An language map is a JSON object value of a term defined with @container set to @language, whose keys MUST be strings representing @@ -1544,7 +1544,7 @@

1.2 Terminology linked data graph
A labeled directed graph, i.e., a set of nodes connected by edges, - as specified in the Data Model + as specified in the Data Model section of the JSON-LD specification [JSON-LD11CG]. A linked data graph is a generalized representation of an RDF graph @@ -2833,7 +2833,7 @@

5.1.2 Algorithm active context, an active property, and an element to be expanded. The optional input is the flag frame expansion the allows - special forms of input used for frame expansion. + special forms of input used for frame expansion. To begin, the active property is set to null, and element is set to the JSON-LD input. If not passed, the frame expansion flag is set to false.

@@ -4742,7 +4742,7 @@

7.1.1 Overview node in a single dictionary. In the next step, the node map is converted to a JSON-LD document in - flattened document form. + flattened document form. Finally, if a context has been passed, the flattened document is compacted using the Compaction algorithm before being returned.

@@ -7014,7 +7014,7 @@

Example 

F. References §

F.1 Normative references §

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[IEEE-754-2008]
IEEE 754-2008 Standard for Floating-Point Arithmetic. Institute of Electrical and Electronics Engineers. 2008. URL: http://standards.ieee.org/findstds/standard/754-2008.html
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ -
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld/20180607/ +
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld/20180607/
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
[RDF11-MT]
RDF 1.1 Semantics. Patrick Hayes; Peter Patel-Schneider. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-mt/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 @@ -7026,8 +7026,8 @@

Example 

F.2 Informative references §

[ECMASCRIPT-6.0]
ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html
[JSON-LD-API]
JSON-LD 1.0 Processing Algorithms and API. Markus Lanthaler; Gregg Kellogg; Manu Sporny. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld-api/
[JSON-LD-TESTS]
JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ -
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/ -
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/ +
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld-api/20180607/ +
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld-framing/20180607/
[promises-guide]
Writing Promise-Using Specifications. Domenic Denicola. W3C. 16 February 2016. Finding of the W3C TAG. URL: https://www.w3.org/2001/tag/doc/promises-guide
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ diff --git a/spec/FCGS/json-ld-framing/index.html b/spec/FCGS/json-ld-framing/index.html index 922847e91..845cf38c5 100644 --- a/spec/FCGS/json-ld-framing/index.html +++ b/spec/FCGS/json-ld-framing/index.html @@ -869,7 +869,7 @@ "localBiblio": { "JSON-LD11CG": { "title": "JSON-LD 1.1", - "href": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/", + "href": "https://json-ld.org/spec/FCGS/json-ld/20180607/", "authors": [ "Gregg Kellogg" ], @@ -878,7 +878,7 @@ }, "JSON-LD11CG-API": { "title": "JSON-LD 1.1 Processing Algorithms and API", - "href": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/", + "href": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/", "authors": [ "Gregg Kellogg" ], @@ -887,7 +887,7 @@ }, "JSON-LD11CG-FRAMING": { "title": "JSON-LD 1.1 Framing", - "href": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/", + "href": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/", "authors": [ "Gregg Kellogg" ], @@ -1112,16 +1112,16 @@ "url": "https://tools.ietf.org/html/rfc7159" }, { - "id": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/", + "id": "https://json-ld.org/spec/FCGS/json-ld/20180607/", "type": "TechArticle", "name": "JSON-LD 1.1", - "url": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/" + "url": "https://json-ld.org/spec/FCGS/json-ld/20180607/" }, { - "id": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/", + "id": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/", "type": "TechArticle", "name": "JSON-LD 1.1 Processing Algorithms and API", - "url": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/" + "url": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/" }, { "id": "https://heycam.github.io/webidl/", @@ -1184,10 +1184,10 @@ "url": "https://www.w3.org/TR/rdf-schema/" }, { - "id": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/", + "id": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/", "type": "TechArticle", "name": "JSON-LD 1.1 Framing", - "url": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/" + "url": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/" } ] } @@ -1265,9 +1265,9 @@

Set of Documents

JSON for Linking Data W3C Community Group:

@@ -1342,7 +1342,7 @@

1.3 Terminology unordered by default. While order is preserved in regular JSON arrays, it is not in regular JSON-LD arrays unless specifically defined (see - Sets and Lists in + Sets and Lists in the JSON-LD Syntax specification [JSON-LD11CG]).

JSON object
In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or @@ -1409,7 +1409,7 @@

1.3 Terminology 
context
A a set of rules for interpreting a JSON-LD document as specified in - The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+ The Context of the JSON-LD Syntax specification [JSON-LD11CG].

default graph
The default graph is the only graph in a JSON-LD document which has no graph name. @@ -1453,7 +1453,7 @@

1.3 Terminology language-tagged string.

keyword
A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] - in the section titled Syntax Tokens and Keywords.
+ in the section titled Syntax Tokens and Keywords.

language-tagged string
A language-tagged string consists of a string and a non-empty language @@ -1465,7 +1465,7 @@

1.3 Terminology linked data graph
A labeled directed graph, i.e., a set of nodes connected by edges, - as specified in the Data Model + as specified in the Data Model section of the JSON-LD specification [JSON-LD11CG]. A linked data graph is a generalized representation of an RDF graph @@ -1575,7 +1575,7 @@

1.3.1 Algorithm Terms The JSON-LD data structure that is produced as output by the algorithm.

map of flattened subjects
A map of subjects that is the result of the - Node Map Generation algorithm.
+ Node Map Generation algorithm.

object embed flag
A flag specifying that node objects should be directly embedded in the output, instead of being referred to by their IRI.
@@ -1642,7 +1642,7 @@

1.4 Typograph

2.1 Framing §

This section is non-normative.

Framing is used to shape the data in a JSON-LD document, using an example frame document which is used to both match the - flattened + flattened data and show an example of how the resulting data should be shaped. Matching is performed by using properties present in in the frame to find objects in the data that share common values. Matching can be done @@ -1803,7 +1803,7 @@

2.2 Default content&nbs

2.3 Framing Flags §

-

Framing can be controlled using API options, +

Framing can be controlled using API options, or by adding framing keywords within the frame as described in section 4.1 Syntax Tokens and Keywords.

@@ -2153,7 +2153,7 @@

4.1 Syntax T
@null
Used in Framing when a value of null should be returned, which would otherwise be removed when - Compacting.
+ Compacting.
@omitDefault
Used in Framing to override the value of omit default flag within a specific frame. @@ -2173,7 +2173,7 @@

4.2 Framing Frame).

-

Framing makes use of the Node Map Generation algorithm +

Framing makes use of the Node Map Generation algorithm to place each object defined in the JSON-LD document into a map of flattened subjects, allowing them to be operated upon by the Framing algorithm.

@@ -2181,7 +2181,7 @@

4.2 Framing 4.2.1 Framing Requirements §

A valid JSON-LD Frame is a superset of a valid JSON-LD document, allowing additional content, which is preserved through expansion. - The Grammar defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG] + The Grammar defined in the JSON-LD 1.1 Syntax specification [JSON-LD11CG] is extended as follows:

@@ -2803,7 +2803,7 @@

application/ld-frame+json JsonLdProcessor { static Promise<JsonLdDictionary> frame(JsonLdInput input, (JsonLdDictionary or USVString) frame, - optional JsonLdOptions? options); + optional JsonLdOptions? options); }; dictionary JsonLdFramingError { JsonLdFramingErrorCode code; @@ -2813,7 +2813,7 @@

application/ld-frame+json "invalid frame", "invalid @embed value" }; -dictionary JsonLdOptions { +dictionary JsonLdOptions { (JsonLdEmbed or boolean) embed = "@last"; boolean explicit = false; boolean omitDefault = false; @@ -2950,8 +2950,8 @@

application/ld-frame+json 

G. References §

G.1 Normative references §

[BCP47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ -
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld/20180607/ -
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/ +
[JSON-LD11CG]
JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld/20180607/ +
[JSON-LD11CG-API]
JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld-api/20180607/
[RDF-CONCEPTS]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987 @@ -2959,7 +2959,7 @@

application/ld-frame+json [WEBIDL]
Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/

G.2 Informative references §

[ECMASCRIPT-6.0]
ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html
[JSON-LD-TESTS]
JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ -
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/ +
[JSON-LD11CG-FRAMING]
JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld-framing/20180607/
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
\ No newline at end of file diff --git a/spec/FCGS/json-ld/20180607/index.html b/spec/FCGS/json-ld/20180607/index.html index 054cee5eb..346d406a6 100644 --- a/spec/FCGS/json-ld/20180607/index.html +++ b/spec/FCGS/json-ld/20180607/index.html @@ -441,7 +441,7 @@ "localBiblio": { "JSON-LD11CG": { "title": "JSON-LD 1.1", - "href": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/", + "href": "https://json-ld.org/spec/FCGS/json-ld/20180607/", "authors": [ "Gregg Kellogg" ], @@ -450,7 +450,7 @@ }, "JSON-LD11CG-API": { "title": "JSON-LD 1.1 Processing Algorithms and API", - "href": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/", + "href": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/", "authors": [ "Gregg Kellogg" ], @@ -459,7 +459,7 @@ }, "JSON-LD11CG-FRAMING": { "title": "JSON-LD 1.1 Framing", - "href": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/", + "href": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/", "authors": [ "Gregg Kellogg" ], @@ -740,10 +740,10 @@ "url": "https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml" }, { - "id": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/", + "id": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/", "type": "TechArticle", "name": "JSON-LD 1.1 Processing Algorithms and API", - "url": "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/" + "url": "https://json-ld.org/spec/FCGS/json-ld-api/20180607/" }, { "id": "https://json-ld.org/test-suite/", @@ -764,10 +764,10 @@ "url": "https://www.w3.org/TR/turtle/" }, { - "id": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/", + "id": "https://json-ld.org/spec/FCGS/json-ld/20180607/", "type": "TechArticle", "name": "JSON-LD 1.1", - "url": "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/" + "url": "https://json-ld.org/spec/FCGS/json-ld/20180607/" }, { "id": "https://heycam.github.io/webidl/", @@ -833,10 +833,10 @@ "type": "TechArticle" }, { - "id": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/", + "id": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/", "type": "TechArticle", "name": "JSON-LD 1.1 Framing", - "url": "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/" + "url": "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/" }, { "id": "https://www.w3.org/TR/ld-glossary/", @@ -928,9 +928,9 @@

Set of Documents

JSON for Linking Data W3C Community Group:

@@ -1054,7 +1054,7 @@

1.3 Terminology unordered by default. While order is preserved in regular JSON arrays, it is not in regular JSON-LD arrays unless specifically defined (see - Sets and Lists in + Sets and Lists in the JSON-LD Syntax specification [JSON-LD11CG]).
JSON object
In the JSON serialization, an object structure is represented as a pair of curly brackets surrounding zero or @@ -1124,7 +1124,7 @@

1.3 Terminology IRI contained within a common vocabulary identified by prefix.

context
A a set of rules for interpreting a JSON-LD document as specified in - The Context of the JSON-LD Syntax specification [JSON-LD11CG].
+ The Context of the JSON-LD Syntax specification [JSON-LD11CG].
default graph
The default graph is the only graph in a JSON-LD document which has no graph name. @@ -1195,7 +1195,7 @@

1.3 Terminology language-tagged string.

keyword
A JSON key that is specific to JSON-LD, specified in the JSON-LD Syntax specification [JSON-LD11CG] - in the section titled Syntax Tokens and Keywords.
+ in the section titled Syntax Tokens and Keywords.
language map
An language map is a JSON object value of a term defined with @container set to @language, whose keys MUST be strings representing @@ -1213,7 +1213,7 @@

1.3 Terminology linked data graph
A labeled directed graph, i.e., a set of nodes connected by edges, - as specified in the Data Model + as specified in the Data Model section of the JSON-LD specification [JSON-LD11CG]. A linked data graph is a generalized representation of an RDF graph @@ -2623,7 +2623,7 @@

4.9 Interp URI schemes.

The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] - provides for an expandContext option for specifying + provides for an expandContext option for specifying a context to use when expanding JSON documents programatically.

The following example demonstrates the use of an external context with an @@ -4648,7 +4648,7 @@

4.25 Expanded D

The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] defines a method for expanding a JSON-LD document. - Expansion is the process of taking a JSON-LD document and applying a + Expansion is the process of taking a JSON-LD document and applying a @context such that all IRIs, types, and values are expanded so that the @context is no longer necessary.

@@ -4666,7 +4666,7 @@

4.25 Expanded D "homepage": "http://manu.sporny.org/" } -

Running the JSON-LD Expansion algorithm against the JSON-LD input document +

Running the JSON-LD Expansion algorithm against the JSON-LD input document provided above would result in the following output:

Example 89: Expanded form for the previous example
[
@@ -4690,7 +4690,7 @@ 
4.25 Expanded D
   
4.26 Compacted Document Form §
This section is non-normative.

 
   
The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] defines
-    a method for compacting a JSON-LD document. Compaction is the process
+    a method for compacting a JSON-LD document. Compaction is the process
     of applying a developer-supplied context to shorten IRIs
     to terms or compact IRIs
     and JSON-LD values expressed in expanded form to simple values such as
@@ -4724,7 +4724,7 @@ 
4.26 Compacted
   }
 }
-

Running the JSON-LD Compaction algorithm given the context supplied above +

Running the JSON-LD Compaction algorithm given the context supplied above against the JSON-LD input document provided above would result in the following output:

@@ -4750,7 +4750,7 @@

4.26 Compacted

4.27 Flattened Document Form §

This section is non-normative.

The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] defines - a method for flattening a JSON-LD document. Flattening collects all + a method for flattening a JSON-LD document. Flattening collects all properties of a node in a single JSON object and labels all blank nodes with blank node identifiers. @@ -4776,7 +4776,7 @@

4.27 Flattened ] } -

Running the JSON-LD Flattening algorithm against the JSON-LD input document in +

Running the JSON-LD Flattening algorithm against the JSON-LD input document in the example above and using the same context would result in the following output:

@@ -4839,7 +4839,7 @@

4.28 If JSON-LD content is extracted as RDF [RDF11-CONCEPTS], it should be expanded into an RDF Dataset using the - Deserialize JSON-LD to RDF Algorithm + Deserialize JSON-LD to RDF Algorithm [JSON-LD11CG-API].

@@ -5347,7 +5347,7 @@

6.10 Property Nesting

A nested property is used to gather properties of a node object in a separate JSON object, or array of JSON objects which are not value objects. It is semantically transparent and is removed - during the process of expansion. Property nesting is recursive, and + during the process of expansion. Property nesting is recursive, and collections of nested properties may contain further nesting.

Semantically, nesting is treated as if the properties and values were declared directly @@ -5498,7 +5498,7 @@

6.11 Context Defin JSON-LD also supports JSON's native data types, i.e., number, strings, and the boolean values true and false. The JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API] - defines the conversion rules + defines the conversion rules between JSON's native data types and RDF's counterparts to allow round-tripping. @@ -5517,8 +5517,8 @@

6.11 Context Defin as properties and also wishes to interpret the data as a generalized RDF Dataset, - there is an option, produce generalized RDF, in the - Deserialize JSON-LD to RDF algorithm [JSON-LD11CG-API] to do so. Note that a + there is an option, produce generalized RDF, in the + Deserialize JSON-LD to RDF algorithm [JSON-LD11CG-API] to do so. Note that a generalized RDF Dataset is an extension of RDF; it does not conform to the RDF standard.
  • If the author or developer wishes to use blank nodes @@ -5553,7 +5553,7 @@

    7.1 Seria

    The process of serializing RDF as JSON-LD and deserializing JSON-LD to RDF depends on executing the algorithms defined in - RDF Serialization-Deserialization Algorithms + RDF Serialization-Deserialization Algorithms in the JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11CG-API]. It is beyond the scope of this document to detail these algorithms any further, but a summary of the necessary operations is provided to illustrate the process.

    @@ -5564,7 +5564,7 @@

    7.1 Seria
    1. Expand the JSON-LD document, removing any context; this ensures that properties, types, and values are given their full representation - as IRIs and expanded values. Expansion + as IRIs and expanded values. Expansion is discussed further in section 4.25 Expanded Document Form.
    2. Flatten the document, which turns the document into an array of node objects. Flattening is discussed @@ -5591,7 +5591,7 @@

      7.1 Seria ] } -

      Running the JSON-LD Expansion and Flattening algorithms against the +

      Running the JSON-LD Expansion and Flattening algorithms against the JSON-LD input document in the example above would result in the following output:

      @@ -6314,7 +6314,7 @@

      application/ld+json 

      G. References §

      G.1 Normative references §

      [BCP47]
      Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
      [IANA-URI-SCHEMES]
      Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
      [JSON-LD]
      JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/ -
      [JSON-LD11CG-API]
      JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/ +
      [JSON-LD11CG-API]
      JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld-api/20180607/
      [RDF-CONCEPTS]
      Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
      [RDF11-CONCEPTS]
      RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
      [RFC2119]
      Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 @@ -6324,8 +6324,8 @@

      application/ld+json 
      [RFC7159]
      The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. March 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7159

      G.2 Informative references §

      [HTTP11]
      Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7230
      [JSON-LD-TESTS]
      JSON-LD 1.1 Test Suite. Gregg Kellogg. Linking Data in JSON Community Group. URL: https://json-ld.org/test-suite/ -
      [JSON-LD11CG]
      JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld/20180607/ -
      [JSON-LD11CG-FRAMING]
      JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/ +
      [JSON-LD11CG]
      JSON-LD 1.1. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld/20180607/ +
      [JSON-LD11CG-FRAMING]
      JSON-LD 1.1 Framing. Gregg Kellogg. W3C. CG Final. URL: https://json-ld.org/spec/FCGS/json-ld-framing/20180607/
      [ld-glossary]
      Linked Data Glossary. Bernadette Hyland; Ghislain Auguste Atemezing; Michael Pendleton; Biplav Srivastava. W3C. 27 June 2013. W3C Note. URL: https://www.w3.org/TR/ld-glossary/
      [LINKED-DATA]
      Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html
      [MICRODATA]
      HTML Microdata. Charles McCathie Nevile; Dan Brickley; Ian Hickson. W3C. 26 April 2018. W3C Working Draft. URL: https://www.w3.org/TR/microdata/ diff --git a/spec/latest/common/common.js b/spec/latest/common/common.js index 29103b638..848eafc9e 100644 --- a/spec/latest/common/common.js +++ b/spec/latest/common/common.js @@ -5,21 +5,21 @@ var jsonld = { localBiblio: { "JSON-LD11CG": { title: "JSON-LD 1.1", - href: "https://json-ld.org/spec/CG-FINAL/json-ld/20180607/", + href: "https://json-ld.org/spec/FCGS/json-ld/20180607/", authors: ["Gregg Kellogg"], publisher: "W3C", status: 'CG Final' }, "JSON-LD11CG-API": { title: "JSON-LD 1.1 Processing Algorithms and API", - href: "https://json-ld.org/spec/CG-FINAL/json-ld-api/20180607/", + href: "https://json-ld.org/spec/FCGS/json-ld-api/20180607/", authors: ["Gregg Kellogg"], publisher: "W3C", status: 'CG Final' }, "JSON-LD11CG-FRAMING": { title: "JSON-LD 1.1 Framing", - href: "https://json-ld.org/spec/CG-FINAL/json-ld-framing/20180607/", + href: "https://json-ld.org/spec/FCGS/json-ld-framing/20180607/", authors: ["Gregg Kellogg"], publisher: "W3C", status: 'CG Final'