JSON-LD 1.1

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-LD11-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 [ RFC8259 ].

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.

This document can highlight changes since the JSON-LD 1.0 version. Select to changes.

This section is non-normative.

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

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

This section is non-normative.

Cannot
GET
/uploads/wHEglh/common/typographical-conventions.html

/uploads/R9Ikes/common/typographical-conventions.html

This section is non-normative.

This document uses the following terms as defined in external specifications and defines terms specific to JSON-LD.

Cannot
GET
/uploads/wHEglh/common/terms.html

/uploads/R9Ikes/common/terms.html

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 not concerned with Linked Data only need to understand JSON, and know to include but ignore the @context property, 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 labeled 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 6.1 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 RDF12-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 10. Relationship to RDF .

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 directed-arcs. A node is either a resource with properties , or the data values of those properties including strings , numbers , typed values (like dates and times) and IRIs .

Within a directed graph, nodes are resources , and may be unnamed , i.e., not identified by an IRI ; which are called blank nodes , and may be identified using a blank node identifier . These identifiers may be required to represent a fully connected graph using a tree structure, such as JSON, but otherwise have no intrinsic meaning. Literal values, such as strings and numbers , are also considered resources , and JSON-LD distinguishes between node objects and value objects to distinguish between the different kinds of resources .

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 8. 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 10. Relationship to RDF .

At the surface level, a JSON-LD document is simply JSON , detailed in [ RFC8259 ]. For the purpose of describing the core data structures, this is limited to arrays , maps (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 .

This section is non-normative.

JSON-LD specifies a number of syntax tokens and keywords that are a core part of the language. A normative description of the keywords is given in 9.16 Keywords .

:

The separator for JSON keys and values that use compact IRIs .

@base

Used to set the base IRI against which to resolve those relative IRI references which are otherwise interpreted relative to the document. This keyword is described in 4.1.3 Base IRI .

@container

Used to set the default container type for a term . This keyword is described in the following sections:

• 4.3 Value Ordering ,
• 4.6.1 Data Indexing ,
• 4.6.2 Language Indexing ,
• 4.6.3 Node Identifier Indexing ,
• 4.6.4 Node Type Indexing
• 4.9 Named Graphs ,
• 4.9.3 Named Graph Indexing , and
• 4.9.2 Named Graph Data Indexing

@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 3.1 The Context .

@direction

Used to set the base direction of a JSON-LD value , which are not typed values (e.g. strings , or language-tagged strings ). This keyword is described in 4.2.4 String Internationalization .

@graph

Used to express a graph . This keyword is described in 4.9 Named Graphs .

@id

Used to uniquely identify node objects that are being described in the document with IRIs or blank node identifiers . This keyword is described in 3.3 Node Identifiers . A node reference is a node object containing only the @id property, which may represent a reference to a node object found elsewhere in the document.

@import

Used in a context definition to load an external context within which the containing context definition is merged. This can be useful to add JSON-LD 1.1 features to JSON-LD 1.0 contexts.

@included

Used in a top-level node object to define an included block , for including secondary node objects within another node object .

@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 4.6.1 Data Indexing .

@json

Used as the @type value of a JSON literal . This keyword is described in 4.2.2 JSON Literals .

@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 4.2.4 String Internationalization .

@list

Used to express an ordered set of data. This keyword is described in 4.3.1 Lists .

@nest

Used to define a property of a node object that groups together properties of that node, but is not an edge in the graph.

@none

Used as an index value in an index map , id map , language map , type map , or elsewhere where a map is used to index into other values, when the indexed node does not have the feature being indexed.

@prefix

With the value true , allows this term to be used to construct a compact IRI when compacting. With the value false prevents the term from being used to construct a compact IRI . Also determines if the term will be considered when expanding compact IRIs .

@propagate

Used in a context definition to change the scope of that context. By default, it is true , meaning that contexts propagate across node objects (other than for type-scoped contexts , which default to false ). Setting this to false causes term definitions created within that context to be removed when entering a new node object .

@protected

Used to prevent term definitions of a context to be overridden by other contexts. This keyword is described in 4.1.11 Protected Term Definitions .

@reverse

Used to express reverse properties. This keyword is described in 4.8 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 4.3.2 Sets .

@type

Used to set the type of a node or the datatype of a typed value . This keyword is described further in 3.5 Specifying the Type and 4.2.1 Typed Values .

Note

The use of @type to define a type for both node objects and value objects addresses the basic need to type data, be it a literal value or a more complicated resource. Experts may find the overloaded use of the @type keyword for both purposes concerning, but should note that Web developer usage of this feature over multiple years has not resulted in its misuse due to the far less frequent use of @type to express typed literal values.

@value

Used to specify the data that is associated with a particular property in the graph. This keyword is described in 4.2.4 String Internationalization and 4.2.1 Typed Values .

@version

Used in a context definition to set the processing mode . New features since JSON-LD 1.0 [ JSON-LD10 ] described in this specification are not available when processing mode has been explicitly set to json-ld-1.0 .

Note

Within a context definition @version takes the specific value 1.1 , not "json-ld-1.1" , as a JSON-LD 1.0 processor may accept a string value for @version , but will reject a numeric value.

Note

The use of 1.1 for the value of @version is intended to cause a JSON-LD 1.0 processor to stop processing. Although it is clearly meant to be related to JSON-LD 1.1, it does not otherwise adhere to the requirements for Semantic Versioning .

@vocab

Used to expand properties and values in @type with a common prefix IRI . This keyword is described in 4.1.2 Default Vocabulary .

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

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 most valid strings that are not reserved JSON-LD keywords can be used as a term . Exceptions are the empty string "" and strings that have the form of a keyword (i.e., starting with "@" followed exclusively by one or more ALPHA characters (see [ RFC5234 ])), which must not be used as terms. Strings that have the form of an IRI (e.g., containing a ":" ) should not be used as terms.

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

{
  "@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 map .

A context is introduced using an entry with the key @context and may appear within a node object or a value object .

When an entry with a term key has a map value, the map 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 IRIs or compact IRIs as keys, which is mainly used to associate type or language information with an IRIs or compact IRI .

Contexts can either be directly embedded into the document (an embedded context ) or be referenced using a URL. 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:

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

A remote context may also be referenced using a relative URL, which is resolved relative to the location of the document containing the reference. For example, if a document were located at http://example.org/document.jsonld and contained a relative reference to context.jsonld , the referenced context document would be found relative at http://example.org/context.jsonld .

{
  "@context": "context.jsonld",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

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 6.1 Interpreting JSON as JSON-LD . It is also possible to apply a custom context using the JSON-LD 1.1 API [ JSON-LD11-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. See Security Considerations in C. IANA Considerations for a discussion on using remote contexts.

This section only covers the most basic features of the JSON-LD Context. The Context can also be used to help interpret other more complex JSON data structures, such as indexed values , ordered values , and nested properties . More advanced features related to the JSON-LD Context are covered in 4. Advanced Concepts .

This section is non-normative.

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

A string is interpreted as an IRI when it is the value of a map entry with the key @id :

{
  ...
  "homepage": { "@id": "http://example.com/" }
  ...
}

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

{
  ...
  "homepage": { "@id": "../" }
  ...
}

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

{
  ...
  "http://schema.org/name": "Manu Sporny",
  ...
}

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

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

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:

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 4.2.3 Type Coercion for more details about this feature.

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

1. Map entries that have a key mapping to a term in the active context expand to an IRI (only applies outside of the context definition ).
2. An IRI is generated for the string value specified using @id or @type .
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 .

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 .

This section is non-normative.

To be able to externally reference nodes in an RDF 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 :

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 .

This section is non-normative.

In Linked Data, it is common to specify the type of a graph node; in many cases, this can be inferred based on the properties used within a given node object , or the property for which a node is a value. For example, in the schema.org vocabulary, the givenName property is associated with a Person . Therefore, one may reason that if a node object contains the property givenName , that the type is a Person ; making this explicit with @type helps to clarify the association.

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

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

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

In addition to setting the type of nodes, @type can also be used to set the type of a value to create a typed value . This use of @type is similar to that used to define the type of a node object , but value objects are restricted to having just a single type. The use of @type to create typed values is discussed more fully in 4.2.1 Typed Values .

Typed values can also be defined implicitly, by specifying @type in an expanded term definition. This is covered more fully in 4.2.3 Type Coercion .

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 any time a map is defined. The only time that one cannot express a context is as a direct child of another context definition (other than as part of an expanded term definition ). For example, a JSON-LD document may have the form of an array composed of one or more node objects , which use a context definition in each top-level node object :

The outer array is standard for a document in expanded document form and flattened document form , and may be necessary when describing a disconnected graph, where nodes may not reference each other. In such cases, using a top-level map with a @graph property can be useful for saving the repetition of @context . See 4.5 Embedding for more.

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

In the example above, the name term is overridden in the more deeply nested details structure, which uses its own embedded context . 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 map . 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 map 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, without term definitions , default language , or other things defined within previous contexts. The following example specifies an external context and then layers an embedded context on top of the external context:

In JSON-LD 1.1, there are other mechanisms for introducing contexts, including scoped contexts and imported contexts, and there are new ways of protecting term definitions, so there are cases where the last defined inline context is not necessarily one which defines the scope of terms. See 4.1.8 Scoped Contexts , 4.1.9 Context Propagation , 4.1.10 Imported Contexts , and 4.1.11 Protected Term Definitions for further information.

{
  "@context": {
    "@version": 1.1,
    ...
  },
  ...
}

{
  "@context": {
    "label": "http://www.w3.org/2000/01/rdf-schema#label"
  },
  "@id": "",
  "label": "Just a simple document"
}

{
  "@context": {
    "@version": 1.1,
    "@base": "http://example/document",
    "@vocab": "#"
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "Restaurant",
  "name": "Brew Eats"
  ...
}

[{
  "http://example.com/vocab/property": [{"@value": "property"}],
  "http://example.com/vocab/propertyOne": [{"@value": "propertyOne"}]
}]

{
  "@context": {
    "vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property"
  }
}

{
  "@context": {
    "@version": 1.1,
    "vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@prefix": true
    }
  }
}

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

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

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
     "@id": "http://schema.org/url",
     "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "http://xmlns.com/foaf/0.1/homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "term1": "term2:foo",
    "term2": "term1:bar"
  },
  ...
}

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@context": {
        "term1": "http://example.com/vocab/term1"
         ↑ Scoped context for "property" defines term1
      }
    },
    "Type1": {
      "@id": "http://example.com/vocab/Type1",
      "@context": {
        "term3": "http://example.com/vocab/term3"
         ↑ Scoped context for "Type1" defines term3
      }
    },
    "Type2": {
      "@id": "http://example.com/vocab/Type2",
      "@context": {
        "term4": "http://example.com/vocab/term4"
         ↑ Scoped context for "Type2" defines term4
      }
    }
  },
  "property": {
    "@context": {
      "term2": "http://example.com/vocab/term2"
         ↑ Embedded context defines term2
    },
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "@vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property",
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2"
  },
  "property": {
    "@context": [{
        "term1": "http://example.com/vocab/term1"
         ↑ Previously scoped context for "property" defines term1
      }, {
        "term2": "http://example.com/vocab/term2"
         ↑ Embedded context defines term2
      }, {
        "term3": "http://example.com/vocab/term3"
         ↑ Previously scoped context for "Type1" defines term3
      }, {
      "term4": "http://example.com/vocab/term4"
         ↑ Previously scoped context for "Type2" defines term4
    }],
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": "http://example.com/vocab#term1",
    "term2": "http://example.com/vocab#term2",
    ...
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "@import": "https://json-ld.org/contexts/remote-context.jsonld",
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "Type1": "http://example.com/vocab/Type1",
        "Type2": "http://example.com/vocab/Type2",
        "term1": "http://example.com/vocab#term1",
        "term2": "http://example.com/vocab#term2",
        ...
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "@import": "https://json-ld.org/contexts/remote-context.jsonld",
    "@vocab": "http://example.org/vocab#",
     ↑ This will replace any previous @vocab definition prior to processing it
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    }
     ↑ This will replace the old term1 definition prior to processing it
  }
}

{
  "@context": {
    "@version": 1.1,
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    },
     ↑ Note term1 has been replaced prior to processing
    "term2": "http://example.com/vocab#term2",
    ...,
    "@vocab": "http://example.org/vocab#"
  }
}

{
  "@context": [
    {
      "@version": 1.1,
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "knows": "http://xmlns.com/foaf/0.1/knows",
      "name": {
        "@id": "http://xmlns.com/foaf/0.1/name",
        "@protected": true
      }
    },
    {
      – this attempt will fail with an error
      "name": "http://schema.org/name"
    }
  ],
  "@type": "Person",
  "name": "Manu Sporny",
  "knows": {
    "@context": [
      – this attempt would also fail with an error
      null,
      "http://schema.org/"
    ],
    "name": "Gregg Kellogg"
  }
}

This section is non-normative.

Values are leaf nodes in a graph associated with scalar values such as strings , dates, times, and other such atomic values.

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

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ja",
    "details": {
      "@context": {
        "@language": null
      }
    }
  },
  "name": "花澄",
  "details": {"occupation": "Ninja"}
}

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

{
  "@context": {
    ...
    "occupation": { "@id": "ex:occupation", "@container": "@language" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža"
  }
  ...
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": "花澄",
  "occupation": {
    "@value": "Scientist",
    "@language": "en"
  }
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": {
    "@value": "Frank"
  },
  "occupation": {
    "@value": "Ninja",
    "@language": "en"
  },
  "speciality": "手裏剣"
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ar-EG",
    "@direction": "rtl",
    "details": {
      "@context": {
        "@direction": null
      }
    }
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "details": {"genre": "Technical Publication"}
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@language": "ar-EG",
    "@direction": "rtl",
    "ex": "http://example.com/vocab/",
    "publisher": { "@id": "ex:publisher", "@direction": null },
    "title": { "@id": "ex:title" },
    "title_en": { "@id": "ex:title", "@language": "en", "@direction": "ltr" }
  },
  "publisher": "مكتبة",
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "title_en": "HTML and CSS: Design and Build Websites",
  ...
}

{
  "@context": {
    ...
    "@language": "ar-EG",
    "@direction": "rtl"
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "author": {
    "@value": "Jon Duckett",
    "@language": "en",
    "@direction": null
  }
}

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 convey any 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:

Multiple values may also be expressed using the expanded form:

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:

{
  "type": "Feature",
  "bbox": [-10.0, -10.0, 10.0, 10.0],
  "geometry": {
    "type": "Polygon",
    "coordinates": [
        [
            [-10.0, -10.0],
            [10.0, -10.0],
            [10.0, 10.0],
            [-10.0, -10.0]
        ]
    ]
  }
  //...
}

{
  "@context": {
    "@version": 1.1,
    "@type": {"@container": "@set"}
  },
  "@type": ["http:/example.org/type"]
}

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:

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:

A node object , like the one used above, may be used in any value position in the body of a JSON-LD document.

While it is considered a best practice to identify nodes in a graph, at times this is impractical. In the data model, nodes without an explicit identifier are called blank nodes , which can be represented in a serialization such as JSON-LD using a blank node identifier . In the previous example, the top-level node for Manu does not have an identifier, and does not need one to describe it within the data model. However, if we were to want to describe a knows relationship from Gregg to Manu, we would need to introduce a blank node identifier (here _:b0 ).

Blank node identifiers may be automatically introduced by algorithms such as flattening , but they are also useful for authors to describe such relationships directly.

This section is non-normative.

Sometimes multiple property values need to be accessed in a more direct fashion than iterating through multiple array values. JSON-LD provides an indexing mechanism to allow the use of an intermediate map to associate specific indexes with associated values.

Data Indexing

As described in 4.6.1 Data Indexing , data indexing allows an arbitrary key to reference a node or value.

Language Indexing

As described in 4.6.2 Language Indexing , language indexing allows a language to reference a string and be interpreted as the language associated with that string.

Node Identifier Indexing

As described in 4.6.3 Node Identifier Indexing , node identifier indexing allows an IRI to reference a node and be interpreted as the identifier of that node .

Node Type Indexing

As described in 4.6.4 Node Type Indexing , node type indexing allows an IRI to reference a node and be interpreted as a type of that node .

See 4.9 Named Graphs for other uses of indexing in JSON-LD.

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.

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

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

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:

The example above expresses a named graph that is identified by the IRI http://example.org/foaf-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.

When a JSON-LD document's top-level structure is a map that contains no other keys 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.

In this case, embedding can not be used as the graph contains unrelated nodes. This is equivalent to using multiple node objects in array and defining the @context within each node object :

This section is non-normative.

The JSON-LD 1.1 Processing Algorithms and API specification [ JSON-LD11-API ] defines the interface to a JSON-LD Processor and includes a number of methods used for manipulating different forms of JSON-LD (see 5. Forms of JSON-LD ). This includes a general mechanism for loading remote documents, including referenced JSON-LD documents and remote contexts, and potentially extracting embedded JSON-LD from other formats such as [ HTML ]. This is more fully described in Remote Document and Context Retrieval in [ JSON-LD11-API ].

A documentLoader can be useful in a number of contexts where loading remote documents can be problematic:

• Remote context documents should be cached to prevent overloading the location of the remote context for each request. Normally, an HTTP caching infrastructure might be expected to handle this, but in some contexts this might not be feasible. A documentLoader implementation might provide separate logic for performing such caching.
• Non-standard URL schemes may not be widely implemented, or may have behavior specific to a given application domain. A documentLoader can be defined to implement document retrieval semantics.
• Certain well-known contexts may be statically cached within a documentLoader implementation. This might be particularly useful in embedded applications, where it is not feasible, or even possible, to access remote documents.
• For security purposes, the act of remotely retrieving a document may provide a signal of application behavior. The judicious use of a documentLoader can isolate the application and reduce its online fingerprint.

This section is non-normative.

The JSON-LD 1.1 Processing Algorithms and API specification [ JSON-LD11-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:

{
   "@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:

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 .

This section is non-normative.

The JSON-LD 1.1 Processing Algorithms and API specification [ JSON-LD11-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:

[
  {
    "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:

{
  "@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:

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 .

The details of Compaction are described in the Compaction algorithm in [ JSON-LD11-API ]. This section provides a short description of how the algorithm operates as a guide to authors creating contexts to be used for compacting JSON-LD documents.

The purpose of compaction is to apply the term definitions , vocabulary mapping , default language , and base IRI to an existing JSON-LD document to cause it to be represented in a form that is tailored to the use of the JSON-LD document directly as JSON. This includes representing values as strings , rather than value objects , where possible, shortening the use of list objects into simple arrays , reversing the relationship between nodes , and using data maps to index into multiple values instead of representing them as an array of values.

This section is non-normative.

The JSON-LD 1.1 Processing Algorithms and API specification [ JSON-LD11-API ] defines a method for flattening a JSON-LD document. Flattening collects all properties of a node in a single map 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:

{
  "@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:

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

This section is non-normative.

The JSON-LD 1.1 Framing specification [ JSON-LD11-FRAMING ] defines a method for framing a JSON-LD document. 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.

For example, assume the following JSON-LD frame:

{
  "@context": {
    "@version": 1.1,
    "@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 Library at the top, with objects of type Book that were linked to the library object using the contains property embedded as property values. It also places objects of type Chapter within the referencing Book object as embedded values of the Book object.

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

{
  "@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:

JSON-LD's media type defines a profile parameter which can be used to signal or request framed document form . The profile URI identifying framed document form is http://www.w3.org/ns/json-ld#framed .

JSON-LD's media type also defines a profile parameter which can be used to identify a script element in an HTML document containing a frame. The first script element of type application/ld+json;profile=http://www.w3.org/ns/json-ld#frame will be used to find a frame ..