--- a/spec/latest/json-ld-syntax/index.html Sun Jan 20 21:01:59 2013 -0500
+++ b/spec/latest/json-ld-syntax/index.html Mon Jan 21 17:22:46 2013 +0100
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<html>
<head>
-<title>JSON-LD Syntax 1.0</title>
+<title>JSON-LD 1.0</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<!--
=== NOTA BENE ===
@@ -32,7 +32,6 @@
previousPublishDate: "2012-09-30",
previousMaturity: "ED",
previousDiffURI: "http://dvcs.w3.org/hg/json-ld/raw-file/66d980964784/spec/ED/json-ld-syntax/20120930/index.html",
- diffTool: "http://www.aptest.com/standards/htmldiff/htmldiff.pl",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html",
@@ -63,14 +62,13 @@
authors: [
{ name: "Manu Sporny", url: "http://digitalbazaar.com/",
company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
- { name: "Dave Longley", url: "http://digitalbazaar.com/",
- company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"},
{ name: "Gregg Kellogg", url: "http://greggkellogg.net/",
company: "Kellogg Associates", companyURL: "http://kellogg-assoc.com/" },
{ name: "Markus Lanthaler", url: "http://www.markus-lanthaler.com/",
company: "Graz University of Technology", companyURL: "http://www.tugraz.at/" },
- { name: "Mark Birbeck", url: "http://webbackplane.com/",
- company: "Backplane Ltd.", companyURL: "http://webbackplane.com/" }
+ { name: "Dave Longley", url: "http://digitalbazaar.com/",
+ company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"},
+ { name: "Niklas Lindström", url: "http://neverspace.net/" }
],
// name of the WG
@@ -102,64 +100,60 @@
<body>
<section id="abstract">
-<p>
-JSON has proven to be a highly useful object serialization and messaging format.
-In an attempt to harmonize the representation of <tref>Linked Data</tref>
-in JSON, this specification outlines a common JSON representation format for
-expressing directed graphs; mixing both Linked Data and non-Linked Data in
-a single document.
-</p>
+ <p>JSON has proven to be a highly useful object serialization and messaging format.
+ In an attempt to harmonize the representation of <tref>Linked Data</tref>
+ in JSON, this specification outlines a common JSON representation format for
+ expressing directed graphs; mixing both Linked Data and non-Linked Data in
+ a single document.</p>
</section>
-<section id='sotd'>
-<p>This document has been under development for over 25 months in the
-JSON for Linking Data Community Group. The document has recently been
-transferred to the RDF Working Group for review, improvement, and publication.
-The specification has undergone significant
-development, review, and changes during the course of the last 25 months.
-</p>
-<p>There are several independent
-<a href="http://json-ld.org/#impl">interoperable implementations</a> of
-this specification. There is
-a <a href="https://github.com/json-ld/json-ld.org/tree/master/test-suite">fairly complete test suite</a>
-and a <a href="http://json-ld.org/playground/">live JSON-LD editor</a>
-that is capable of demonstrating the features described in
-this document. While development on implementations, the test suite
-and the live editor will continue, they are believed to be mature enough
-to be integrated into a non-production system at this point in time with
-the expectation that they could be used in a production system within the
-next year.
-</p>
-
-<p>There are a number of ways that one may participate in the development of
-this specification:</p>
-
-<ul>
- <li>If you want to make sure that your feedback is formally addressed by
- the RDF Working Group, you should send it to public-rdf-comments:
- <a href="http://lists.w3.org/Archives/Public/public-rdf-comments/">public-rdf-comments@w3.org</a></li>
-
- <li>Ad-hoc technical discussion primarily occurs on the public community mailing list:
- <a href="http://lists.w3.org/Archives/Public/public-linked-json/">public-linked-json@w3.org</a></li>
-
- <li><a href="http://json-ld.org/minutes/">Public JSON-LD Community Group teleconferences</a>
- are held on Tuesdays at 1500UTC every week.</li>
-
- <li>RDF Working Group teleconferences are held on Wednesdays at 1500UTC
- every week. Participation is limited to RDF Working Group members.</li>
-
- <li>Specification bugs and issues should be reported in the
- <a href="https://github.com/json-ld/json-ld.org/issues">issue tracker</a>
- if you do not want to send an e-mail to the public-rdf-comments mailing
- list.</li>
-
- <li><a href="https://github.com/json-ld/json-ld.org/tree/master/spec">Source code</a>
- for the specification can be found on Github.</li>
-
- <li>The <a href="http://webchat.freenode.net/?channels=json-ld">#json-ld</a>
- IRC channel is available for real-time discussion on irc.freenode.net.</li>
-</ul>
-
+<section id="sotd">
+ <p>This document has been under development for over 25 months in the
+ JSON for Linking Data Community Group. The document has recently been
+ transferred to the RDF Working Group for review, improvement, and publication.
+ The specification has undergone significant development, review, and changes
+ during the course of the last 25 months.</p>
+
+ <p>There are several independent
+ <a href="http://json-ld.org/#impl">interoperable implementations</a> of
+ this specification. There is a
+ <a href="https://github.com/json-ld/json-ld.org/tree/master/test-suite">fairly complete test suite</a>
+ and a <a href="http://json-ld.org/playground/">live JSON-LD editor</a>
+ that is capable of demonstrating the features described in
+ this document. While development on implementations, the test suite
+ and the live editor will continue, they are believed to be mature enough
+ to be integrated into a non-production system at this point in time with
+ the expectation that they could be used in a production system within the
+ next year.</p>
+
+ <p>There are a number of ways that one may participate in the development of
+ this specification:</p>
+
+ <ul>
+ <li>If you want to make sure that your feedback is formally addressed by
+ the RDF Working Group, you should send it to public-rdf-comments:
+ <a href="http://lists.w3.org/Archives/Public/public-rdf-comments/">public-rdf-comments@w3.org</a></li>
+
+ <li>Ad-hoc technical discussion primarily occurs on the public community mailing list:
+ <a href="http://lists.w3.org/Archives/Public/public-linked-json/">public-linked-json@w3.org</a></li>
+
+ <li><a href="http://json-ld.org/minutes/">Public JSON-LD Community Group teleconferences</a>
+ are held on Tuesdays at 1500UTC every week.</li>
+
+ <li>RDF Working Group teleconferences are held on Wednesdays at 1500UTC
+ every week. Participation is limited to RDF Working Group members.</li>
+
+ <li>Specification bugs and issues should be reported in the
+ <a href="https://github.com/json-ld/json-ld.org/issues">issue tracker</a>
+ if you do not want to send an e-mail to the public-rdf-comments mailing
+ list.</li>
+
+ <li><a href="https://github.com/json-ld/json-ld.org/tree/master/spec">Source code</a>
+ for the specification can be found on Github.</li>
+
+ <li>The <a href="http://webchat.freenode.net/?channels=json-ld">#json-ld</a>
+ IRC channel is available for real-time discussion on irc.freenode.net.</li>
+ </ul>
</section>
<section class="informative">
@@ -185,8 +179,8 @@
JSON-LD introduces:</p>
<ul>
- <li>a universal identifier mechanism for <tref title="JSON object">JSON objects</tref> via the
- use of <tref title="IRI">IRIs</tref>,</li>
+ <li>a universal identifier mechanism for <tref title="JSON object">JSON objects</tref>
+ via the use of <tref title="IRI">IRIs</tref>,</li>
<li>a way to disambiguate the keys used between multiple JSON documents
by mapping them to <tref title="IRI">IRIs</tref> via a <tref>context</tref>,</li>
<li>a mechanism in which a value in a <tref>JSON object</tref> may refer
@@ -230,434 +224,540 @@
</section>
<section class="informative">
-<h1>Design Goals and Rationale</h1>
-
-<p>A number of design goals were established before the creation of this
- markup language:</p>
-
-<dl>
- <dt>Simplicity</dt>
- <dd>No extra
- processors or software libraries should be necessary to use JSON-LD in its most
- basic form. The language will provide developers with a very easy
- learning curve. Developers only need to know JSON and two
- <tref title="keyword">keywords</tref> (<code>@context</code>
- and <code>@id</code>) to use the basic functionality in JSON-LD.</dd>
- <dt>Compatibility</dt>
- <dd>The JSON-LD markup must be 100% compatible with JSON. This ensures that
- all of the standard JSON libraries work seamlessly with JSON-LD documents.</dd>
- <dt>Expressiveness</dt>
- <dd>The syntax must be able to express directed graphs, which have been proven
- to be able to express almost every real world data model.</dd>
- <dt>Terseness</dt>
- <dd>The JSON-LD syntax must be very terse and human readable, requiring as
- little effort as possible from the developer.</dd>
- <!--<dt>Pragmatism</dt>
- <dd>Mixing the expression of pure Linked Data with data that is not
- linked was an approach that was driven by pragmatism. JSON-LD attempts to be
- more practical than theoretical in its approach to Linked Data.</dd>-->
- <dt>Zero Edits, most of the time</dt>
- <dd>JSON-LD must make the transition to JSON-LD as simple as possible. In
- many cases, zero edits to the JSON document and the addition of one line to the HTTP
- response should suffice (see <a href="#referencing-contexts-from-json-documents"></a>).
- 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 more complex than a simple one-line
- change. In these instances, rather than extending JSON-LD to support an
- esoteric use case, 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. We should focus on simplicity when possible.
- </dd>
- <dt>One-pass Processing</dt>
- <dd>JSON-LD supports one-pass processing, which results in a very small memory
- footprint when processing documents. For example, to expand a JSON-LD document
- from a compacted form, only one pass is required over the data. This mechanism
- should make some forms of JSON-LD very useful when used in streaming
- protocols.</dd>
-</dl>
+ <h1>Design Goals and Rationale</h1>
+
+ <p>A number of design goals were established before the creation of this
+ markup language:</p>
+
+ <dl>
+ <dt>Simplicity</dt>
+ <dd>No extra processors or software libraries should be necessary to use JSON-LD
+ in its most basic form. The language will provide developers with a very easy
+ learning curve. Developers only need to know JSON and two
+ <tref title="keyword">keywords</tref> (<code>@context</code>
+ and <code>@id</code>) to use the basic functionality in JSON-LD.</dd>
+ <dt>Compatibility</dt>
+ <dd>The JSON-LD markup must be 100% compatible with JSON. This ensures that
+ all of the standard JSON libraries work seamlessly with JSON-LD documents.</dd>
+ <dt>Expressiveness</dt>
+ <dd>The syntax must be able to express directed graphs, which have been proven
+ to be able to express almost every real world data model.</dd>
+ <dt>Terseness</dt>
+ <dd>The JSON-LD syntax must be very terse and human readable, requiring as
+ little effort as possible from the developer.</dd>
+ <dt>Zero Edits, most of the time</dt>
+ <dd>JSON-LD must make the transition to JSON-LD as simple as possible. In many cases,
+ zero edits to the JSON document and the addition of one line to the HTTP response
+ should suffice (see <a href="#referencing-contexts-from-json-documents"></a>).
+ 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 more complex than a simple one-line
+ change. In these instances, rather than extending JSON-LD to support an
+ esoteric use case, 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. We should focus on simplicity when possible.</dd>
+ <dt>One-pass Processing</dt>
+ <dd>JSON-LD supports one-pass processing, which results in a very small memory
+ footprint when processing documents. For example, to expand a JSON-LD document
+ from a compacted form, only one pass is required over the data. This mechanism
+ should make some forms of JSON-LD very useful when used in streaming protocols.</dd>
+ </dl>
</section>
<section class="normative">
<h1>Terminology</h1>
-<section>
- <h2>General Terminology</h2>
-
- <p>This document uses the following terms as defined in JSON [[!RFC4627]]. Refer
- to the <em>JSON Grammar</em> section in [[!RFC4627]] for formal definitions.</p>
-
- <dl>
- <dt><tdef>JSON object</tdef></dt><dd>
- An object structure is represented as a pair of curly brackets
- surrounding zero or more key-value pairs. A key is a
- <tref>string</tref>. A single colon comes after each key, separating the
- key from the value. A single comma separates a value from a following
- key.
- </dd>
- <dt><tdef>array</tdef></dt>
- <dd>
- An array structure is represented as square brackets surrounding zero
- or more values. Values are separated by commas.
- In JSON, an array is an <em>ordered</em> sequence of zero or more values.
- While JSON-LD uses the same array representation as JSON,
- the collection is <em>unordered</em> by default. While order is
- preserved in regular JSON arrays, it is not in regular JSON-LD arrays
- unless specific markup is provided (see <a href="#sets-and-lists"></a>).</dd>
- <dt><tdef>string</tdef></dt><dd>
- A string is a sequence of zero or more Unicode characters,
- wrapped in double quotes, using backslash escapes (if necessary). A
- character is represented as a single character string.</dd>
- <dt><tdef>number</tdef></dt>
- <dd>
- 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.</dd>
- <dt><tdef>true</tdef> and <tdef>false</tdef></dt><dd>
- Values that are used to express one of two possible boolean states.</dd>
- <dt><tdef>null</tdef></dt>
- <dd>The <tref>null</tref> value, which is typically used to clear or forget
- data. For example, A key-value pair in the
- <code>@context</code> where the value is <tref>null</tref> explicitly
- decouples a <tref>term</tref>'s association with an <tref>IRI</tref>.
- A key-value pair in the body of a JSON-LD document whose
- value is <tref>null</tref> has the same meaning as if the key-value pair
- was not defined. If <code>@value</code>, <code>@list</code>, or
- <code>@set</code> is set to <tref>null</tref> in expanded form, then
- the entire <tref>JSON object</tref> is ignored.</dd>
- </dl>
-</section>
-
-<section>
-<h2>Syntax Tokens and Keywords</h2>
-
-<p>JSON-LD specifies a number of syntax tokens and <tdef title="keyword">keywords</tdef>
-that are a core part of the language:</p>
-
-<dl>
-<dt><code>@context</code></dt>
-<dd>Used to define the short-hand names that are used throughout a JSON-LD
- document. These short-hand names are called <tref title="term">terms</tref> and help
- developers to express specific identifiers in a compact manner. The
- <code>@context</code> keyword is described in detail in the section titled
- <a href="#the-context"></a>.</dd>
-<dt><code>@id</code></dt>
-<dd>Used to uniquely identify <em>things</em> that are being described in the document.
- This keyword is described in <a href="#node-identifiers"></a>.</dd>
-<dt><code>@value</code></dt>
-<dd>Used to specify the data that is associated with a particular
- <tref>property</tref> in the graph. This keyword is described in
- <a href="#string-internationalization"></a> and
- <a href="#typed-values"></a>.</dd>
-<dt><code>@language</code></dt>
-<dd>Used to specify the native language for a particular value or the default
- language of a JSON-LD document. This keyword is described in the section titled
- <a href="#string-internationalization"></a>.</dd>
-<dt><code>@type</code></dt>
-<dd>Used to set the data type of a <tref>node</tref> or
- <tref>typed value</tref>. This keyword is described in the section titled
- <a href="#typed-values"></a>.</dd>
-<dt><code>@container</code></dt>
-<dd>Used to set the default container type for a <tref>term</tref>.
- This keyword is described in the section titled <a href="#sets-and-lists"></a>.</dd>
-<dt><code>@list</code></dt>
-<dd>Used to express an ordered set of data.
- This keyword is described in the section titled <a href="#sets-and-lists"></a>.</dd>
-<dt><code>@set</code></dt>
-<dd>Used to express an unordered set of data and to ensure that values are
- always represented as arrays. This keyword is described in the section titled
- <a href="#sets-and-lists"></a>.</dd>
-<dt><code>@annotation</code></dt>
-<dd>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 the section titled
- <a href="#data-annotations"></a>.</dd>
-<dt><code>@vocab</code></dt>
-<dd>Used to expand properties and values in <code>@type</code> with a common prefix
- <tref>IRI</tref>. This keyword is described in section <a href="#iris"></a>.</dd>
-<dt><code>@graph</code></dt><dd>Used to explicitly label a <tref>JSON-LD graph</tref>.
- This keyword is described in <a href="#named-graphs"></a>.</dd>
-<dt><code>:</code></dt>
-<dd>The separator for JSON keys and values that use
- <tref title="compact_iri">compact IRIs</tref>.</dd>
-</dl>
-
-<p>For the avoidance of doubt, all keys, <tref title="keyword">keywords</tref>, and values in JSON-LD are
-case-sensitive.</p>
-</section>
-
-</section>
-
-<section class="normative">
-<h1>Conformance</h1>
-
-<p>This specification describes the conformance criteria for JSON-LD documents.
-This criteria is relevant to authors and authoring tool implementors.</p>
-
-<p>A <tref>JSON-LD document</tref> complies with this specification if it
-follows the normative statements for documents defined in sections
-<a href="#referencing-contexts-from-json-documents"></a> and
-<a href="#json-ld-grammar"></a>. For convenience, normative statements for
-documents are often phrased as statements on the properties of the document.</p>
-
-<p>The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
-SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
-Recommendation have the meaning defined in [[!RFC2119]].</p>
-
+ <section>
+ <h2>General Terminology</h2>
+
+ <p>This document uses the following terms as defined in JSON [[!RFC4627]]. Refer
+ to the <em>JSON Grammar</em> section in [[!RFC4627]] for formal definitions.</p>
+
+ <dl>
+ <dt><tdef>JSON object</tdef></dt><dd>
+ An object structure is represented as a pair of curly brackets
+ surrounding zero or more key-value pairs. A key is a
+ <tref>string</tref>. A single colon comes after each key, separating the
+ key from the value. A single comma separates a value from a following
+ key.
+ </dd>
+ <dt><tdef>array</tdef></dt>
+ <dd>
+ An array structure is represented as square brackets surrounding zero
+ or more values. Values are separated by commas.
+ In JSON, an array is an <em>ordered</em> sequence of zero or more values.
+ While JSON-LD uses the same array representation as JSON,
+ the collection is <em>unordered</em> by default. While order is
+ preserved in regular JSON arrays, it is not in regular JSON-LD arrays
+ unless specific markup is provided (see <a href="#sets-and-lists"></a>).</dd>
+ <dt><tdef>string</tdef></dt><dd>
+ A string is a sequence of zero or more Unicode characters,
+ wrapped in double quotes, using backslash escapes (if necessary). A
+ character is represented as a single character string.</dd>
+ <dt><tdef>number</tdef></dt>
+ <dd>
+ 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.</dd>
+ <dt><tdef>true</tdef> and <tdef>false</tdef></dt><dd>
+ Values that are used to express one of two possible boolean states.</dd>
+ <dt><tdef>null</tdef></dt>
+ <dd>The <tref>null</tref> value, which is typically used to clear or forget
+ data. For example, A key-value pair in the
+ <code>@context</code> where the value is <tref>null</tref> explicitly
+ decouples a <tref>term</tref>'s association with an <tref>IRI</tref>.
+ A key-value pair in the body of a JSON-LD document whose
+ value is <tref>null</tref> has the same meaning as if the key-value pair
+ was not defined. If <code>@value</code>, <code>@list</code>, or
+ <code>@set</code> is set to <tref>null</tref> in expanded form, then
+ the entire <tref>JSON object</tref> is ignored.</dd>
+ </dl>
+ </section>
+
+ <section>
+ <h2>Syntax Tokens and Keywords</h2>
+
+ <p>JSON-LD specifies a number of syntax tokens and <tdef title="keyword">keywords</tdef>
+ that are a core part of the language:</p>
+
+ <dl>
+ <dt><code>@context</code></dt>
+ <dd>Used to define the short-hand names that are used throughout a JSON-LD
+ document. These short-hand names are called <tref title="term">terms</tref> and help
+ developers to express specific identifiers in a compact manner. The
+ <code>@context</code> keyword is described in detail in the section titled
+ <a href="#the-context"></a>.</dd>
+ <dt><code>@id</code></dt>
+ <dd>Used to uniquely identify <em>things</em> that are being described in the document.
+ This keyword is described in <a href="#node-identifiers"></a>.</dd>
+ <dt><code>@value</code></dt>
+ <dd>Used to specify the data that is associated with a particular
+ <tref>property</tref> in the graph. This keyword is described in
+ <a href="#string-internationalization"></a> and
+ <a href="#typed-values"></a>.</dd>
+ <dt><code>@language</code></dt>
+ <dd>Used to specify the native language for a particular value or the default
+ language of a JSON-LD document. This keyword is described in the section titled
+ <a href="#string-internationalization"></a>.</dd>
+ <dt><code>@type</code></dt>
+ <dd>Used to set the data type of a <tref>node</tref> or
+ <tref>typed value</tref>. This keyword is described in the section titled
+ <a href="#typed-values"></a>.</dd>
+ <dt><code>@container</code></dt>
+ <dd>Used to set the default container type for a <tref>term</tref>.
+ This keyword is described in the section titled <a href="#sets-and-lists"></a>.</dd>
+ <dt><code>@list</code></dt>
+ <dd>Used to express an ordered set of data.
+ This keyword is described in the section titled <a href="#sets-and-lists"></a>.</dd>
+ <dt><code>@set</code></dt>
+ <dd>Used to express an unordered set of data and to ensure that values are always
+ represented as arrays. This keyword is described in the section titled
+ <a href="#sets-and-lists"></a>.</dd>
+ <dt><code>@annotation</code></dt>
+ <dd>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 the section titled
+ <a href="#data-annotations"></a>.</dd>
+ <dt><code>@vocab</code></dt>
+ <dd>Used to expand properties and values in <code>@type</code> with a common prefix
+ <tref>IRI</tref>. This keyword is described in section <a href="#iris"></a>.</dd>
+ <dt><code>@graph</code></dt><dd>Used to explicitly label a <tref>JSON-LD graph</tref>.
+ This keyword is described in <a href="#named-graphs"></a>.</dd>
+ <dt><code>:</code></dt>
+ <dd>The separator for JSON keys and values that use
+ <tref title="compact IRI">compact IRIs</tref>.</dd>
+ </dl>
+
+ <p>For the avoidance of doubt, all keys, <tref title="keyword">keywords</tref>,
+ and values in JSON-LD are case-sensitive.</p>
+ </section>
</section>
<section class="normative">
-<h1>Basic Concepts</h1>
-
-<section>
-<h2>The Context</h2>
-
-<p>A <tref>JSON object</tref> often contains one or more key-value pairs.
- JSON-LD uses a mechanism called a <tdef>context</tdef> to map
- keys to <tref title="IRI">IRIs</tref>. This key-to-IRI mapping in a
- <tref>context</tref> is called a <tref>term</tref> mapping.
- By mapping keys to IRIs,
- a JSON-LD <tref>context</tref> creates an environment for an application to
- easily and unambiguously interpret hyper-linked data in a JSON document.</p>
-<p>The basic idea is that the <tref title="term">terms</tref> used in a
- JSON-LD document mean something and may be of use to other developers.
- If developers want to share <tref title="term">terms</tref> between applications, it is useful to
- give them an unambiguous identifier. The Web uses <tref title="IRI">IRIs</tref> for unambiguous identification.
- It is useful for <tref title="term">terms</tref> to expand to IRIs so that
- developers don't accidentally step on each other's terminology. Furthermore, developers, and
- machines, are able to use this <tref>IRI</tref> (by plugging it directly into a web browser, for instance) to go to
- the term and get a definition of what the term means. This allows JSON-LD documents to be constructed
- using the common JSON practice of simple key-value pairs while ensuring that the data is useful outside of the
- file, API or database in which it resides.</p>
-
-<p>
-Let's assume that a developer starts with the following JSON document:
-</p>
-
-<pre class="example" data-transform="updateExample"
- title="Sample JSON document">
-<!--
-{
- "name": "Manu Sporny",
- "homepage": "http://manu.sporny.org/",
- "depiction": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-
-<p>The developer can add a single line to the JSON document above
-to reference the context and transform it into a JSON-LD document:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Referencing a JSON-LD context">
-<!--
-{
- ****"@context": "http://json-ld.org/contexts/person.jsonld",****
- "name": "Manu Sporny",
- "homepage": "http://manu.sporny.org/",
- "depiction": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-
-<p>It is not important to understand how the context works at this stage. What
-is important is to understand that the <code>@context</code> provides
-instructions on how to interpret the document in an unambiguous way.
-The additions above transform the previous JSON document into a JSON document
-with added semantics because the <code>@context</code> specifies how the
-<strong>name</strong>, <strong>homepage</strong>, and <strong>depiction</strong>
-terms map to <tref title="IRI">IRIs</tref>.
-Mapping those keys to IRIs gives the data global context. If two
-developers use the same IRI to describe a property, they are more than likely
-expressing the same concept. This allows both developers to re-use each others'
-data without having to agree to how their data will interoperate on a
-site-by-site basis. Contexts may also contain type, language or additional
-information for certain <tref title="term">terms</tref>.</p>
-
-<p>Contexts may also be specified in-line. This ensures that
- <tref title="JSON-LD document">JSON-LD documents</tref> can be understood
- even in the absence of a connection to the Web.</p>
-
-<pre class="example" data-transform="updateExample"
- title="In-line context definition">
-<!--
-{
- ****"@context":
+ <h1>Conformance</h1>
+
+ <p>This specification describes the conformance criteria for JSON-LD documents.
+ This criteria is relevant to authors and authoring tool implementors.</p>
+
+ <p>A <tref>JSON-LD document</tref> complies with this specification if it follows
+ the normative statements in section <a href="#json-ld-grammar"></a>. JSON documents
+ can be interpreted as JSON-LD by following the normative statements in section
+ <a href="#referencing-contexts-from-json-documents"></a>. For convenience, normative
+ statements for documents are often phrased as statements on the properties of the document.</p>
+
+ <p>The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT,
+ RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this specification have the
+ meaning defined in [[!RFC2119]].</p>
+</section>
+
+<section class="normative">
+ <h1>Basic Concepts</h1>
+
+ <p>JSON [[RFC4627]] 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 has just local meaning. Furthermore, JSON has no
+ built-in support for hyperlinks - a fundamental building block on the Web. Let's look
+ at an example that we will be using for the rest of this section:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Sample JSON document">
+ <!--
{
- "name": "http://xmlns.com/foaf/0.1/name",
- "depiction":
- {
- "@id": "http://xmlns.com/foaf/0.1/depiction",
- "@type": "@id"
- },
- "homepage":
- {
- "@id": "http://xmlns.com/foaf/0.1/homepage",
- "@type": "@id"
- },
- },****
- "name": "Manu Sporny",
- "homepage": "http://manu.sporny.org/",
- "depiction": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-
-<p>Contexts may be used at any time a <tref>node object</tref> is defined.
- In particular, a <tref>JSON-LD document</tref> may use more than one context:</p>
-<pre class="example" data-transform="updateExample"
- title="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"
- }
- }
-]
--->
-</pre>
-
-<p>Duplicate context <tref title="term">terms</tref> are overridden using a
- last-defined-wins mechanism.</p>
-
-<pre class="example" data-transform="updateExample"
- title="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"
+ "image": "http://twitter.com/account/profile_image/manusporny",
+ "knows": [
+ {
+ "name": "Markus Lanthaler"
+ },
+ {
+ "name": "Gregg Kellogg"
+ }
+ ]
}
-}
--->
-</pre>
-
-<p>In the example above, the <code>name</code> <tref>term</tref> is overridden
- in the more deeply nested <code>details</code> 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
- <tref>JSON object</tref>. If a <tref>term</tref> is redefined within a
- context, all previous rules associated with the previous definition are
- removed. If a <tref>term</tref> is redefined to <code>null</code>,
- the <tref>term</tref> is effectively removed from the list of
- <tref title="term">terms</tref> defined in the <tref>active context</tref>.</p>
-
-<p>A <tref>node object</tref> may specify multiple contexts, using an
- <tref>array</tref>, which is processed in order. The set of contexts defined within a specific <tref>node object</tref> are
- referred to as <tdef title="local context">local contexts</tdef>. The
- <tdef>active context</tdef> refers to the accumulation of <tref title="local context">local contexts</tref>
- that are in scope at a specific point within the document. Setting <code>@context</code> to <code>null</code>
- effectively resets the <tref>active context</tref> to an empty context. The following example
- specifies an external context and then layers a local context on top of the external
- context:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Combining external and local contexts">
-<!--
-{
- ****"@context": [
- "http://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"****
-}
--->
-</pre>
-
-<p class="note">External JSON-LD context documents may contain
-extra information located outside of the <code>@context</code> key, such as
-documentation about the
-<tref title="term">terms</tref> declared in the document. Information contained
-outside of the <code>@context</code> value is simply discarded when the document
-is used as an external JSON-LD context document
-(see <a href="#referencing-contexts-from-json-documents"></a>).</p>
-
-<p class="note">To ensure the best possible performance, it is a best practice to
- put the <tref>context</tref> definition at the top of the JSON-LD document. If it isn't listed
- first, processors have to save each key-value pair until the <tref>context</tref> is processed.
- This creates a memory and complexity burden for certain types of
- low-memory footprint JSON-LD processors.</p>
-
-<p class="note">To avoid forward-compatibility issues, terms starting with an
- <code>@</code> character are to be avoided as they might be used as keywords
- in future versions of JSON-LD. Furthermore, the use of empty
- <tref title="term">terms</tref> (<code>""</code>)
- is discouraged as not all programming languages are able to handle empty
- property names.
-</p>
-
-</section>
-
-<section>
- <h2>From JSON to JSON-LD</h2>
-
- <p>If a set of <tref title="term">terms</tref> such as, <strong>name</strong>,
- <strong>homepage</strong>, and <strong>depiction</strong>,
- are defined in a <tref>context</tref>, and that context is used to resolve the
- names in <tref title="JSON object">JSON objects</tref>, machines are able to automatically expand the terms to
- something unambiguous like this:</p>
+ -->
+ </pre>
+
+ <p>It's obvious for humans that the data is about a person whose name is "Manu Sporny"
+ and that the <code>homepage</code> property contains the URL of that person's homepage.
+ On the other hand, 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
+ <tref title="term">terms</tref> such as "name", "homepage", etc.</p>
+
+ <p><tref>Linked Data</tref>, and the Web in general, uses <tref title="IRI">IRIs</tref>
+ (Internationalized Resource Identifiers as described in [[!RFC3987]]) for unambiguous
+ identification. The idea is to assign <tref title="IRI">IRIs</tref> to something that may
+ be of use to other developers and that it is useful to give them an unambiguous identifier.
+ That is, it is useful for <tref title="term">terms</tref> to expand to <tref title="IRI">IRIs</tref>
+ so that developers don't accidentally step on each other's terms. Furthermore, developers and
+ machines, are able to use this <tref>IRI</tref> (by using a web browser, for instance) to go to
+ the term and get a definition of what the term means.</p>
+
+ <p>Leveraging the well-known <a href="http://xmlns.com/foaf/spec/">FOAF vocabulary</a>,
+ the example above could thus be unambiguously expressed as follows:</p>
<pre class="example" data-transform="updateExample"
- title="Expanded terms">
+ title="Sample JSON-LD document using full IRIs instead of terms">
<!--
{
"****http://xmlns.com/foaf/0.1/name****": "Manu Sporny",
- "****http://xmlns.com/foaf/0.1/homepage****": "http://manu.sporny.org"
- "****http://xmlns.com/foaf/0.1/depiction****": "http://twitter.com/account/profile_image/manusporny"
+ "****http://xmlns.com/foaf/0.1/homepage****": { "****@id****": "http://manu.sporny.org/" },
+ "****http://xmlns.com/foaf/0.1/img****": { "****@id****": "http://twitter.com/account/profile_image/manusporny" },
+ "****http://xmlns.com/foaf/0.1/knows****": [
+ {
+ "****http://xmlns.com/foaf/0.1/name****": "Markus Lanthaler"
+ },
+ {
+ "****http://xmlns.com/foaf/0.1/name****": "Gregg Kellogg"
+ }
+ ]
}
- -->
+ -->
</pre>
- <p>Doing this allows JSON to be unambiguously machine-readable without
- requiring developers to drastically change their workflow. A <tref>JSON object</tref>
- used to define property values of a <tref>node</tref> is called a <tref>node object</tref>.</p>
-
- <p class="note">The example above does not use the <code>@id</code> <tref>keyword</tref>
- to identify the node being described above. This type of node is called a
- <tref>blank node</tref>. It is advised that all <tref title="node object">node objects</tref>
- in JSON-LD are identified by <tref title="IRI">IRIs</tref> via the <code>@id</code>
- keyword unless the data is not intended to be linked to from other data sets.</p>
-</section>
+ <p>Every property is unambiguously identified by an <tref>IRI</tref> and all values
+ representing <tref title="IRI">IRIs</tref> are explicitly marked as such by the
+ <code>@id</code> <tref>keyword</tref>. While this is a completely valid JSON-LD
+ document that is unambiguous and very specific, it also very verbose and difficult
+ to work with for human users. To address this issue, JSON-LD introduces the notion
+ of a <tref>context</tref> as described in the next section.</p>
+
+ <section>
+ <h2>The Context</h2>
+
+ <p>Simply speaking, a <tdef>context</tdef> is used to map <tref title="term">terms</tref>,
+ i.e., <tref title="property">properties</tref> with associated values, to
+ <tref title="IRI">IRIs</tref>. Any valid <tref>string</tref> that is not a
+ reserved JSON-LD <tref>keyword</tref> can be used as a <tref>term</tref>. To
+ avoid forward-compatibility issues, <tref title="term">terms</tref> starting with
+ an <code>@</code> character are to be avoided as they might be used as
+ keywords in future versions of JSON-LD. Furthermore, the use of empty
+ <tref title="term">terms</tref> (<code>""</code>) is discouraged as not all
+ programming languages are able to handle empty property names.</p>
+
+ <p>For the sample document in the previous section, a <tref>context</tref> would
+ look something like this:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Context for the sample document in the previous section">
+ <!--
+ {
+ "****@context****":
+ {
+ "name": "http://xmlns.com/foaf/0.1/name",
+ "image": {
+ "@id": "http://xmlns.com/foaf/0.1/img",
+ "@type": "@id"
+ },
+ "homepage": {
+ "@id": "http://xmlns.com/foaf/0.1/homepage",
+ "@type": "@id"
+ },
+ "knows": "http://xmlns.com/foaf/0.1/knows"
+ }
+ }
+ -->
+ </pre>
+
+ <p>As <tref>context</tref> above shows, the value of a <tdef>term definition</tdef> can
+ either be 1) a simple string mapping the <tref>term</tref> to an <tref>IRI</tref>,
+ or 2) an <tref>expanded term definition</tref> in the form of a <tref>JSON object</tref>
+ to allow additional information to be associated with the term.</p>
+
+ <p><tref title="expanded term definition">Expanded term definitions</tref> may
+ be used to associate <a href="#type-coercion">type</a> or
+ <a href="#string-internationalization">language information</a> (as in the
+ example above which specifies that the values of <code>image</code> and
+ <code>homepage</code> are <tref title="IRI">IRIs</tref>) with a term.
+ Furthermore, they allow terms to be used for <a href="#data-annotations">annotation maps</a>
+ and to specify whether <tref title="array">array</tref> values are to be
+ interpreted as <a href="#sets-and-lists">sets or lists</a>.
+ <tref title="expanded term definition">Expanded term definitions</tref> may
+ be defined using <tref title="absolute IRI">absolute</tref> or
+ <tref title="compact IRI">compact IRIs</tref> as keys. This mechanism is
+ mainly used to associate type or language information with an
+ <tref title="absolute IRI">absolute</tref> or <tref>compact IRI</tref>.</p>
+
+ <p class="note">While it is possible to define a <tref>compact IRI</tref>, or
+ an <tref>absolute IRI</tref> to expand to some other unrelated <tref>IRI</tref>
+ (for example, <code>foaf:name</code> expanding to
+ <code>http://example.org/unrelated#species</code>), such usage is strongly
+ discouraged.</p>
+
+ <p><tref title="context">Contexts</tref> can either be directly embedded
+ into the document or be referenced. Assuming the context document in the previous
+ example can be retrieved at <code>http://json-ld.org/contexts/person.jsonld</code>,
+ 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:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Referencing a JSON-LD context">
+ <!--
+ {
+ ****"@context": "http://json-ld.org/contexts/person.jsonld",****
+ "name": "Manu Sporny",
+ "homepage": "http://manu.sporny.org/",
+ "image": "http://twitter.com/account/profile_image/manusporny",
+ "knows": [
+ {
+ "name": "Markus Lanthaler"
+ },
+ {
+ "name": "Gregg Kellogg"
+ }
+ ]
+ }
+ -->
+ </pre>
+
+ <p>The referenced context not only specifies how the terms map to
+ <tref title="IRI">IRIs</tref> in the FOAF vocabulary but also specifies that
+ the values of the <code>homepage</code> and <code>image</code> property
+ can be interpreted as an <tref>IRI</tref> (<code>"@type": "@id"</code>,
+ see section <a href="#iris"></a> for more details). This information gives the
+ data global context and allows developers to re-use each others 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 <code>@context</code> key, such as
+ documentation about the <tref title="term">terms</tref> declared in the
+ document. Information contained outside of the <code>@context</code> value
+ is ignored when the document is used as an external JSON-LD context document.</p>
+
+ <p>Contexts may also be specified in-line. This has the advantage that
+ <tref title="JSON-LD document">JSON-LD documents</tref> can be processed
+ even in the absence of a connection to the Web.</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="In-line context definition">
+ <!--
+ {
+ ****"@context":
+ {
+ "name": "http://xmlns.com/foaf/0.1/name",
+ "image": {
+ "@id": "http://xmlns.com/foaf/0.1/img",
+ "@type": "@id"
+ },
+ "homepage": {
+ "@id": "http://xmlns.com/foaf/0.1/homepage",
+ "@type": "@id"
+ }
+ },****
+ "name": "Manu Sporny",
+ "homepage": "http://manu.sporny.org/",
+ "image": "http://twitter.com/account/profile_image/manusporny"
+ }
+ -->
+ </pre>
+
+ <p>Contexts may be used at any time a <tref>JSON object</tref> is defined
+ (except inside a context definition). In particular, a
+ <tref>JSON-LD document</tref> may may use more than one context:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="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"
+ }
+ }
+ ]
+ -->
+ </pre>
+
+ <p>Duplicate context <tref title="term">terms</tref> are overridden using a
+ last-defined-wins mechanism.</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="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"
+ }
+ }
+ -->
+ </pre>
+
+ <p>In the example above, the <code>name</code> <tref>term</tref> is overridden
+ in the more deeply nested <code>details</code> 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
+ <tref>JSON object</tref>. If a <tref>term</tref> is redefined within a
+ context, all previous rules associated with the previous definition are
+ removed. If a <tref>term</tref> is redefined to <code>null</code>,
+ the <tref>term</tref> is effectively removed from the list of
+ <tref title="term">terms</tref> defined in the <tref>active context</tref>.</p>
+
+ <p>Multiple contexts may be combined using an <tref>array</tref>, which is processed
+ in order. The set of contexts defined within a specific <tref>JSON object</tref> are
+ referred to as <tdef title="local context">local contexts</tdef>. The
+ <tdef>active context</tdef> refers to the accumulation of
+ <tref title="local context">local contexts</tref> that are in scope at a
+ specific point within the document. Setting a <tref>local context</tref>
+ to <code>null</code> effectively resets the <tref>active context</tref>
+ to an empty context. The following example specifies an external context
+ and then layers an embedded context on top of the external context:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Combining external and local contexts">
+ <!--
+ {
+ ****"@context": [
+ "http://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"****
+ }
+ -->
+ </pre>
+
+ <p class="note">To ensure the best possible performance, it is a best practice to
+ put the <tref>context</tref> definition at the top of the JSON-LD document. If it isn't listed
+ first, processors have to save each key-value pair until the <tref>context</tref> is processed.
+ This creates a memory and complexity burden for certain types of
+ low-memory footprint JSON-LD processors.</p>
+
+ <section>
+ <h2>Referencing Contexts from JSON Documents</h2>
+
+ <p>Ordinary JSON documents can be interpreted as JSON-LD by referencing a JSON-LD
+ <tref>context</tref> document in an HTTP Link Header. Doing so allows JSON to
+ be unambiguously machine-readable without requiring developers to drastically
+ change their workflow and provides an upgrade path for existing infrastructure
+ without breaking existing clients that rely on the <code>application/json</code>
+ media type.</p>
+
+ <p>In order to use an external context with an ordinary JSON document, an author
+ MUST specify an <tref>IRI</tref> to a valid <tref>JSON-LD document</tref> in
+ an HTTP Link Header [[!RFC5988]] using the <code>http://www.w3.org/ns/json-ld#context</code>
+ link relation. The referenced document MUST have a top-level <tref>JSON object</tref>.
+ The <code>@context</code> subtree within that object is added to the top-level
+ <tref>JSON object</tref> of the referencing document. If an <tref>array</tref>
+ is at the top-level of the referencing document and its items are
+ <tref title="JSON object">JSON objects</tref>, the <code>@context</code>
+ subtree is added to all <tref>array</tref> items. All extra information located outside
+ of the <code>@context</code> subtree in the referenced document MUST be
+ discarded. Effectively this means that the <tref>active context</tref> is
+ initialized with the referenced external <tref>context</tref>.</p>
+
+ <p>The following example demonstrates the use of an external context with an
+ ordinary JSON document:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Referening 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.0 200 OK
+ ...
+ Content-Type: ****application/json****
+ ****Link: <http://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"
+ }
+ -->
+ </pre>
+
+ <p>Please note that <tref title="JSON-LD document">JSON-LD documents</tref>
+ served with the <code>application/ld+json</code>
+ media type MUST have all context information, including references to external
+ contexts, within the body of the document. Contexts linked via a
+ <code>http://www.w3.org/ns/json-ld#context</code> HTTP Link Header MUST be
+ ignored for such documents.</p>
+ </section>
+ </section>
<section>
<h2>IRIs</h2>
-<p><tref title="IRI">IRIs</tref> (Internationalized Resource Identifiers
- [[!RFC3987]]) are fundamental to <tref>Linked Data</tref> as that is how most
+<p><tref title="IRI">IRIs</tref> (Internationalized Resource Identifiers
+ [[!RFC3987]]) are fundamental to <tref>Linked Data</tref> as that is how most
<tref title="node">nodes</tref> and <tref title="property">properties</tref>
- are identified. In JSON-LD, IRIs may be represented as an
- <tref>absolute IRI</tref> or a <tref>relative IRI</tref>. An
- <tdef>absolute IRI</tdef> is defined in [[!RFC3987]] as containing a
- <em>scheme</em> along with <em>path</em> and optional <em>query</em> and
+ are identified. In JSON-LD, IRIs may be represented as an
+ <tref>absolute IRI</tref> or a <tref>relative IRI</tref>. An
+ <tdef>absolute IRI</tdef> is defined in [[!RFC3987]] as containing a
+ <em>scheme</em> along with <em>path</em> and optional <em>query</em> and
<em>fragment</em> segments. A <tdef>relative IRI</tdef> is an IRI
- that is relative to some other <tref>absolute IRI</tref>.
- In JSON-LD all <tref title="relative IRI">relative IRIs</tref> are resolved
+ that is relative to some other <tref>absolute IRI</tref>.
+ In JSON-LD all <tref title="relative IRI">relative IRIs</tref> are resolved
relative to the <tdef>base IRI</tdef> associated with the document, which
is typically the directory path containing the document.</p>
@@ -679,8 +779,8 @@
(<code>:</code>) and the 'http' <tref>prefix</tref> does not exist in
the context.</p>
-<p>Term-to-IRI expansion occurs if the key matches a <tref>term</tref> defined
-within the <tref>active context</tref>:</p>
+<p>Term-to-IRI expansion occurs if the key matches a <tref>term</tref> defined
+ within the <tref>active context</tref>:</p>
<pre class="example" data-transform="updateExample"
title="Term expansion from context definition">
@@ -728,10 +828,11 @@
<p><code>foaf:name</code> above will automatically expand out to the IRI
<code>http://xmlns.com/foaf/0.1/name</code>. See <a href="#compact-iris"></a> for more details.</p>
-<p>At times, all properties and types may come from the same <tref>vocabulary</tref>. JSON-LD's
- <code>@vocab</code> keyword allows an author to set a common prefix to be used for all properties and types
- that do not match a <tref>term</tref> or a <tref>compact IRI</tref> or an <tref>absolute IRI</tref>
- (i.e., the string does not contain a colon).</p>
+<p>At times, all properties and types may come from the same vocabulary. JSON-LD's
+ <code>@vocab</code> keyword allows an author to set a common prefix to be used
+ for all properties and types that do not match a <tref>term</tref> or a
+ <tref>compact IRI</tref> or an <tref>absolute IRI</tref> (i.e., the string does
+ not contain a colon).</p>
<pre class="example" data-transform="updateExample"
title="Using a common vocabulary prefix">
@@ -746,7 +847,7 @@
-->
</pre>
-<p>An <tref>IRI</tref> is generated when a <tref>JSON object</tref> is used in
+<p>An <tref>IRI</tref> is generated when a <tref>JSON object</tref> is used in
the value position and contains an <code>@id</code> keyword:</p>
<pre class="example" data-transform="updateExample"
@@ -796,14 +897,14 @@
<tref>string</tref>, the type <tref>coercion</tref> rules will transform
the value into an IRI when generating the <tref>JSON-LD graph</tref>.</p>
-In summary, <tref title="IRI">IRIs</tref> can be expressed in a variety of
+In summary, <tref title="IRI">IRIs</tref> can be expressed in a variety of
different ways in JSON-LD:</p>
<ol>
- <li><tref>JSON object</tref> keys that have a <tref>term</tref> mapping in
- the <tref>active context</tref> expand to an <tref>IRI</tref>
+ <li><tref>JSON object</tref> keys that have a <tref>term</tref> mapping in
+ the <tref>active context</tref> expand to an <tref>IRI</tref>
(only applies outside of the <tref>context definition</tref>).</li>
- <li>If there is a <code>@vocab</code> mapping in the active context,
+ <li>If there is a <code>@vocab</code> mapping in the active context,
<tref>JSON object</tref> keys without an explicit mapping
in the <tref>active context</tref> are expanded to an <tref>IRI</tref>.</li>
<li>An <tref>IRI</tref> is generated for the <tref>string</tref> value specified using
@@ -816,47 +917,45 @@
</section>
<section>
-<h2>Node Identifiers</h2>
-
-<p>To be able to externally reference nodes in a graph, it is important that each <tref>node</tref> has
- an unambiguous identifier. <tref title="IRI">IRIs</tref> are a fundamental concept of
- <tref>Linked Data</tref>, and nodes should have a de-referencable
- identifier used to name and locate them. For nodes to be truly linked,
- de-referencing the identifier should result in a representation of that node
- (for example, using a URL to retrieve a web page).
- Associating an IRI with a node tells an application that the returned
- document contains a description of the node requested.</p>
-
-<p>JSON-LD documents may also contain descriptions of other nodes, so it is necessary to be able to
- uniquely identify each node which may be externally referenced.</p>
-
-<p>A <tref>node</tref> is identified using the <code>@id</code>
- <tref>keyword</tref>:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Identifying a node">
-<!--
-{
- "@context":
+ <h2>Node Identifiers</h2>
+
+ <p>To be able to externally reference nodes in a graph, it is important that each <tref>node</tref> has
+ an unambiguous identifier. <tref title="IRI">IRIs</tref> are a fundamental concept of
+ <tref>Linked Data</tref>, and nodes should have a de-referencable
+ identifier used to name and locate them. For nodes to be truly linked,
+ de-referencing the identifier should result in a representation of that node.
+ Associating an IRI with a node tells an application that the returned
+ document contains a description of the node requested.</p>
+
+ <p>JSON-LD documents may also contain descriptions of other nodes, so it is necessary to be able to
+ uniquely identify each node which may be externally referenced.</p>
+
+ <p>A <tref>node</tref> is identified using the <code>@id</code>
+ <tref>keyword</tref>:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Identifying a node">
+ <!--
{
- ...
- "homepage":
+ "@context":
{
- "@id": "http://xmlns.com/foaf/0.1/homepage",
- "@type": "@id"
- }
- ...
- },
- "****@id****": "****http://example.org/people#joebob****",
- "homepage": "http://manu.sporny.org/",
-...
-}
--->
-</pre>
-
-<p>The example above contains a <tref>node object</tref> identified by the IRI
- <code>http://example.org/people#joebob</code>.</p>
-
+ ...
+ "homepage":
+ {
+ "@id": "http://xmlns.com/foaf/0.1/homepage",
+ "@type": "@id"
+ }
+ ...
+ },
+ "****@id****": "****http://example.org/people#joebob****",
+ "homepage": "http://manu.sporny.org/",
+ ...
+ }
+ -->
+ </pre>
+
+ <p>The example above contains a <tref>node object</tref> identified by the IRI
+ <code>http://example.org/people#joebob</code>.</p>
</section>
<section>
@@ -911,106 +1010,133 @@
</section>
<section>
-<h2>String Internationalization</h2>
-
-<p>At times, it is important to annotate a <tref>string</tref>
- 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 <code>@language</code> key in the <code>@context</code>:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Setting the default language of a JSON-LD document">
-<!--
-{
- ****"@context":
+ <h2>String Internationalization</h2>
+
+ <p>At times, it is important to annotate a <tref>string</tref>
+ 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 <code>@language</code> key in the <tref>context</tref>:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Setting the default language of a JSON-LD document">
+ <!--
{
- ...
- "@language": "ja"
- },****
- "name": ****"花澄"****,
- "occupation": ****"科学者"****
-}
--->
-</pre>
-
-<p>The example above would associate the <code>ja</code> language
- code with the two <tref title="string">strings</tref> <em>花澄</em> and <em>科学者</em>.
- Languages codes are defined in [[!BCP47]].</p>
-
-<p>Second, it is possible to override the default language by using an <tref>expanded value</tref>:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Overriding default language using an expanded value">
-<!--
-{
- "@context": {
+ ****"@context":
+ {
+ ...
+ "@language": "ja"
+ }****,
+ "name": ****"花澄"****,
+ "occupation": ****"科学者"****
+ }
+ -->
+ </pre>
+
+ <p>The example above would associate the <code>ja</code> language
+ code with the two <tref title="string">strings</tref> <em>花澄</em> and <em>科学者</em>.
+ Languages codes are defined in [[!BCP47]].</p>
+
+ <p>Second, it is possible to associate a language with a specific <tref>term</tref>
+ using an <tref>expanded term definition</tref>:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="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",****
...
- "@language": "ja"
- },
- "name": "花澄",
- "occupation": ****{
- "@value": "Scientist",
- "@language": "en"
- }****
-}
--->
-</pre>
-
-<p>Third, it is possible to override the default language or specify a plain
-value by omitting the <code>@language</code> tag or setting it to
-<code>null</code> when expressing the <tref>expanded value</tref>:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Removing language information using an expanded value">
-<!--
-{
- "@context": {
- ...
- "@language": "ja"
- },
- "name": ****{
- "@value": "Frank"
- },****
- "occupation": {
- "@value": "Ninja",
- "@language": "en"
- },
- "speciality": "手裏剣"
-}
--->
-</pre>
-
-<p>Please note that language associations can only be applied to plain
- literal <tref title="string">strings</tref>. That is,
- <tref title="typed value">typed values</tref> or values that are subject
- to <a href="#type-coercion"></a> cannot be language tagged.</p>
-
-<p>To clear the default language for a subtree, <code>@language</code> can
-be set to <code>null</code> in a <tref>local context</tref> as follows:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Clearing default language">
-<!--
-{
- "@context": {
- ...
- "@language": "ja"
- },
- "name": "花澄",
- "details": {
-**** "@context": {
- "@language": null
- },****
- "occupation": "Ninja"
}
-}
--->
-</pre>
-
-<p class="note">JSON-LD allows one to associate language information with
- <tref title="term">terms</tref>. See <a href="#expanded-term-definition"></a> for
- more details.</p>
-
+ -->
+ </pre>
+
+ <p>The example above would associate <em>忍者</em> with the specified default
+ language code <code>ja</code>, <em>Ninja</em> with the language code
+ <code>en</code>, and <em>Nindža</em> with the language code <code>cs</code>.
+ The value of <code>name</code>, <em>Yagyū Muneyoshi</em> wouldn't be
+ associated with any language code since <code>@language</code> was reset to
+ <tref>null</tref> in the <tref>expanded term definition</tref>.</p>
+
+ <p>Second, it is possible to override the default language by using an <tref>expanded value</tref>:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Overriding default language using an expanded value">
+ <!--
+ {
+ "@context": {
+ ...
+ "@language": "ja"
+ },
+ "name": "花澄",
+ "occupation": ****{
+ "@value": "Scientist",
+ "@language": "en"
+ }****
+ }
+ -->
+ </pre>
+
+ <p>Third, it is possible to override the default language or specify a plain
+ value by omitting the <code>@language</code> tag or setting it to
+ <code>null</code> when expressing the <tref>expanded value</tref>:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Removing language information using an expanded value">
+ <!--
+ {
+ "@context": {
+ ...
+ "@language": "ja"
+ },
+ "name": ****{
+ "@value": "Frank"
+ }****,
+ "occupation": {
+ "@value": "Ninja",
+ "@language": "en"
+ },
+ "speciality": "手裏剣"
+ }
+ -->
+ </pre>
+
+ <p>Please note that language associations can only be applied to plain
+ literal <tref title="string">strings</tref>. That is,
+ <tref title="typed value">typed values</tref> or values that are subject
+ to <a href="#type-coercion"></a> cannot be language tagged.</p>
+
+ <p>To clear the default language for a subtree, <code>@language</code> can
+ be set to <code>null</code> in a <tref>local context</tref> as follows:</p>
+
+ <pre class="example" data-transform="updateExample"
+ title="Clearing default language">
+ <!--
+ {
+ "@context": {
+ ...
+ "@language": "ja"
+ },
+ "name": "花澄",
+ "details": {
+ **** "@context": {
+ "@language": null
+ }****,
+ "occupation": "Ninja"
+ }
+ }
+ -->
+ </pre>
</section>
</section>
@@ -1026,15 +1152,12 @@
<section>
<h2>Compact IRIs</h2>
- <p>A document on the Web that defines one or more IRIs for use as
- <tref title="property">properties</tref> in Linked Data
- is called a <tdef>vocabulary</tdef>.
- <tref title="term">Terms</tref> in <tref>Linked Data</tref> documents may
- draw from a number of different <tref title="vocabulary">vocabularies</tref>.
-
- At times, declaring every single <tref>term</tref> that a document uses can require the
- developer to declare tens, if not hundreds of potential
- <tref>vocabulary</tref> <tref title="term">terms</tref> that are used across an
+ <p>A document on the Web that defines one or more IRIs for use as
+ <tref title="property">properties</tref> in Linked Data is called a vocabulary.
+ <tref title="term">Terms</tref> in <tref>Linked Data</tref> documents may draw from
+ a number of different vocabularies. At times, declaring every single <tref>term</tref>
+ that a document uses can require the developer to declare tens, if not hundreds of potential
+ vocabulary <tref title="term">terms</tref> that are used across an
application. This is a concern for at least two reasons: the
first is the cognitive load on the developer of remembering all of the
<tref title="term">terms</tref>, and the second is the serialized size of the
@@ -1050,12 +1173,11 @@
For example, the prefix <code>foaf</code> may be used as a short
hand for the Friend-of-a-Friend vocabulary, which is identified using
the IRI <code>http://xmlns.com/foaf/0.1/</code>. A developer may append
- any of the FOAF <tref>vocabulary</tref> terms to the end of the prefix
- to specify a short-hand version of the <tref>absolute IRI</tref> for the
- <tref>vocabulary</tref> term. For example, <code>foaf:name</code> would
- be expanded out to the IRI <code>http://xmlns.com/foaf/0.1/name</code>.
- Instead of having to remember and type out the entire IRI, the developer
- can instead use the prefix in their JSON-LD markup.
+ any of the FOAF vocabulary terms to the end of the prefix to specify a short-hand
+ version of the <tref>absolute IRI</tref> for the vocabulary term. For example,
+ <code>foaf:name</code> would be expanded out to the IRI
+ <code>http://xmlns.com/foaf/0.1/name</code>. Instead of having to remember and
+ type out the entire IRI, the developer can instead use the prefix in their JSON-LD markup.
</p>
<p>Terms are interpreted as <tref title="compact IRI">compact IRIs</tref> if they contain at least one
colon and the first colon is not followed by two slashes (<code>//</code>, as in
@@ -1097,13 +1219,14 @@
}
-->
</pre>
- <p>
- In this example, two different <tref title="vocabulary">vocabularies</tref>
- are referred to using prefixes. Those prefixes are then used as type and
- property values using the compact IRI <code>prefix:suffix</code> notation.
- </p>
+
+ <p>In this example, two different vocabularies are referred to using prefixes.
+ Those prefixes are then used as type and property values using the compact
+ IRI <code>prefix:suffix</code> notation.</p>
+
<p>It's also possible to use compact IRIs within the context as shown in the
following example:</p>
+
<pre class="example" data-transform="updateExample"
title="Using vocabularies">
<!--
@@ -1353,144 +1476,6 @@
</section>
<section>
-<h2>Referencing Contexts from JSON Documents</h2>
-
-<p>Ordinary JSON documents can be transformed into JSON-LD documents by referencing
-to an external JSON-LD <tref>context</tref> in an HTTP Link Header. Doing this
-allows JSON to be unambiguously machine-readable without requiring developers to
-drastically change their workflow and provides an upgrade path for existing
-infrastructure without breaking existing clients that rely on the <code>application/json</code>
-media type.
-</p>
-
-<p>
-In order to use an external context with an ordinary JSON document, an author
-MUST specify an <tref>IRI</tref> to a valid <tref>JSON-LD document</tref> in an HTTP Link
-Header [[!RFC5988]] using the <code>http://www.w3.org/ns/json-ld#context</code> link relation.
-
-The referenced document MUST have a top-level <tref>node object</tref>. The
-<code>@context</code> subtree within that object is added to the top-level
-<tref>node object</tref> of the referencing document. If an <tref>array</tref> is at the top-level of the
-referencing document and its items are <tref title="node object">node objects</tref>, the <code>@context</code>
-subtree is added to all <tref>array</tref> items. All extra information located outside
-of the <code>@context</code> subtree in the referenced document MUST be
-discarded.
-</p>
-
-<p>The following example demonstrates the use of an external context with an
-ordinary JSON document:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Specifing context through HTTP header">
-<!--
-GET /ordinary-json-document.json HTTP/1.1
-Host: example.com
-Accept: application/ld+json,application/json,*/*;q=0.1
-
-====================================
-
-HTTP/1.0 200 OK
-...
-Content-Type: ****application/json****
-****Link: <http://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/",
- "depiction": "http://twitter.com/account/profile_image/markuslanthaler"
-}
--->
-</pre>
-
-<p>Please note that <tref title="JSON-LD document">JSON-LD documents</tref>
- served with the <code>application/ld+json</code>
- media type MUST have all context information, including references to external
- contexts, within the body of the document. Contexts linked via a
- <code>http://www.w3.org/ns/json-ld#context</code> HTTP Link Header MUST be
- ignored for such documents.</p>
-
-</section>
-
-<section>
-<h3>Expanded Term Definition</h3>
-
-<p>Within a <tref>context</tref> definition, <tref title="term">terms</tref> may be
- defined using an <tref>expanded term definition</tref> to allow for additional information
- associated with the <tref>term</tref> to be specified (see also
- <a href="#type-coercion"></a> and
- <a href="#sets-and-lists"></a>).</p>
-
-<p>Instead of using a string representation of an IRI, the IRI may be
-specified using a <tref>JSON object</tref> having an <code>@id</code> key,
-and a <tref>term</tref>, a <tref>compact IRI</tref>, or an
-<tref>absolute IRI</tref> as value.</p>
-
-<pre class="example" data-transform="updateExample"
- title="Expanded term definition">
-<!--
-{
- "@context":
- {
- "foaf": ****{ "@id": "http://xmlns.com/foaf/0.1/" }****,
- "name": ****{ "@id": "http://xmlns.com/foaf/0.1/name" }****,
- "homepage": ****{ "@id": "foaf:homepage" }****,
- "depiction": ****{ "@id": "foaf:depiction" }****
- },
- "name": "Manu Sporny",
- "homepage": "http://manu.sporny.org/",
- "depiction": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-
-<p>This allows additional information to be associated with the term. This
- may be used for <a href="#type-coercion"></a>,
- <a href="#sets-and-lists"></a>, or to associate language
- information with a <tref>term</tref> as shown in the following example:</p>
-
-<pre class="example" data-transform="updateExample"
- title="Expanded term definition with language">
-<!--
-{
- "@context": {
- ...
- "ex": "http://example.com/",
- "@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",****
- ...
-}
--->
-</pre>
-
-<p>The example above would associate <em>忍者</em> with the specified default
- language code <code>ja</code>, <em>Ninja</em> with the language code
- <code>en</code>, and <em>Nindža</em> with the language code <code>cs</code>.
- The value of <code>name</code>, <em>Yagyū Muneyoshi</em> wouldn't be
- associated with any language code since <code>@language</code> was reset to
- <tref>null</tref> in the <tref>expanded term definition</tref>.</p>
-
-<p>Expanded terms may also be defined using <tref title="compact_iri">compact IRIs</tref> or
- <tref title="absolute_IRI">absolute IRIs</tref> as keys. If the definition does not include an
- <code>@id</code> key, the expanded IRI is determined by performing expansion of the key
- within the current <tref>active context</tref>. This mechanism is mainly used to associate type or language
- information with a <tref>compact IRI</tref> or an <tref>absolute IRI</tref>.</p>
-
-<p class="note">While it is possible to define a
- <tref>compact IRI</tref>, or an absolute IRI to expand to some
- other unrelated IRI (for example, <code>foaf:name</code> expanding to
- <code>http://example.org/unrelated#species</code>),
- such usage is strongly discouraged.</p>
-</section>
-
-<section>
<h2>Type Coercion</h2>
<p>JSON-LD supports the coercion of values to particular data types.
@@ -1505,7 +1490,7 @@
that within the body of a JSON-LD document, a string value of a <tref>term</tref> coerced to
<code>@id</code> is to be interpreted as an <tref>IRI</tref>.</p>
-<p><tref title="term">Terms</tref> or <tref title="compact_iri">compact IRIs</tref> used as the value of a
+<p><tref title="term">Terms</tref> or <tref title="compact IRI">compact IRIs</tref> used as the value of a
<code>@type</code> key may be defined within the same context. This means that one may specify a
<tref>term</tref> like <code>xsd</code> and then use <code>xsd:integer</code> within the same
context definition.</p>
@@ -1582,7 +1567,7 @@
</tbody>
</table>
-<p>Terms may also be defined using <tref title="absolute iri">absolute IRIs</tref> or <tref title="compact_iri">compact IRIs</tref>.
+<p>Terms may also be defined using <tref title="absolute iri">absolute IRIs</tref> or <tref title="compact IRI">compact IRIs</tref>.
This allows coercion rules to be applied to keys which are not represented as a simple <tref>term</tref>.
For example:</p>
@@ -1773,8 +1758,8 @@
-->
</pre>
-<p><tref title="compact iri">Compact IRIs</tref>
- and <tref title="iri">IRIs</tref> may be used on the left-hand side of a
+<p><tref title="compact IRI">Compact IRIs</tref>
+ and <tref title="IRI">IRIs</tref> may be used on the left-hand side of a
<tref>term</tref> definition.</p>
<pre class="example" data-transform="updateExample"
@@ -1814,7 +1799,7 @@
</p>
<p>
-<tref title="absolute iri">Absolute IRIs</tref> may also be used in the key position in a <tref>context</tref>:
+<tref title="absolute IRI">Absolute IRIs</tref> may also be used in the key position in a <tref>context</tref>:
</p>
<pre class="example" data-transform="updateExample"
@@ -2631,7 +2616,7 @@
a <tref>JSON-LD value</tref>, or a <tref>list</tref>.</li>
<li>A node having an outgoing edge MUST be an <tref>IRI</tref> or a
<tref>blank node</tref>.</li>
- <li>A <tref>JSON-LD graph</tref> SHOULD NOT contain unconnected <tref title="node">nodes</tref>,
+ <li>A <tref>JSON-LD graph</tref> MUST NOT contain unconnected <tref title="node">nodes</tref>,
i.e., nodes which are not connected by an <tref>edge</tref> to any other <tref>node</tref>.</li>
<li>An <tdef><abbr title="Internationalized Resource Identifier">IRI</abbr></tdef>
(Internationalized Resource Identifier) is a string that conforms to the syntax
@@ -2675,8 +2660,6 @@
<h2>JSON-LD Grammar</h2>
<em>This section is normative</em>
-<p class="issue" data-number="114">This section is an attempt to formalize
-a normative grammar for JSON-LD.</p>
<p>This appendix restates the syntactic conventions described in the
previous sections more formally.</p>
@@ -2745,16 +2728,16 @@
</ul>
<p>If the <tref>node object</tref> contains the <code>@id</code> key,
- its value MUST be an <tref>IRI</tref>, a <tref>compact IRI</tref>
- (including <tref title="blank node identifier">blank node identifiers</tref>), or
- a <tref>term</tref> defined in the <tref>active context</tref> expanding
- into an <tref>IRI</tref> or a <tref>blank node identifier</tref>.
+ its value MUST be an <tref>absolute IRI</tref>, a <tref>relative IRI</tref>,
+ or a <tref>compact IRI</tref> (including
+ <tref title="blank node identifier">blank node identifiers</tref>).
See <a href="#node-identifiers"></a>, <a href="#compact-iris"></a>,
and <a href="#identifying-blank-nodes"></a> for further discussion on
<code>@id</code> values.</p>
<p>If the <tref>node object</tref> contains the <code>@type</code>
- key, its value MUST be either an <tref>IRI</tref>, a <tref>compact IRI</tref>
+ key, its value MUST be either an <tref>absolute IRI</tref>, a
+ <tref>relative IRI</tref>, a <tref>compact IRI</tref>
(including <tref title="blank node identifier">blank node identifiers</tref>),
a <tref>term</tref> defined in the <tref>active context</tref> expanding into an <tref>absolute IRI</tref>, or
an <tref>array</tref> of any of these.
@@ -2885,7 +2868,7 @@
<p>The value associated with the <code>@type</code> key MUST be a
<tref>term</tref>, a <tref>compact IRI</tref>,
- an <tref>IRI</tref>, or <tref>null</tref>.</p>
+ an <tref>absolute IRI</tref>, a <tref>relative IRI</tref>, or <tref>null</tref>.</p>
<p>The value associated with the <code>@language</code> key MUST have the
lexical form described in [[!BCP47]], or be <tref>null</tref>.</p>
@@ -3007,9 +2990,6 @@
<tref title="IRI">IRIs</tref> or <tref title="blank node">blank nodes</tref>
whereas in RDF properties (predicates) have to be
<tref title="IRI">IRIs</tref>.</li>
- <li>In contrast to RDF graphs <tref title="JSON-LD graph">JSON-LD graphs</tref>
- support unconnected <tref title="node">nodes</tref>, i.e., nodes which are not
- connected to any other node.</li>
<li>In JSON-LD lists are part of the data model whereas in RDF they are part of
a vocabulary, namely [[RDF-SCHEMA]].</li>
<li>RDF values are either typed <em>literals</em>
@@ -3175,13 +3155,13 @@
<div ****prefix="foaf: http://xmlns.com/foaf/0.1/"****>
<ul>
<li ****typeof="foaf:Person"****>
- <a ****rel="foaf:homepage" href="http://example.com/bob/" property="foaf:name" ****>Bob</a>
+ <a ****rel="foaf:homepage" href="http://example.com/bob/" property="foaf:name"****>Bob</a>
</li>
<li ****typeof="foaf:Person"****>
- <a ****rel="foaf:homepage" href="http://example.com/eve/" property="foaf:name" ****>Eve</a>
+ <a ****rel="foaf:homepage" href="http://example.com/eve/" property="foaf:name"****>Eve</a>
</li>
<li ****typeof="foaf:Person"****>
- <a ****rel="foaf:homepage" href="http://example.com/manu/" property="foaf:name" ****>Manu</a>
+ <a ****rel="foaf:homepage" href="http://example.com/manu/" property="foaf:name"****>Manu</a>
</li>
</ul>
</div>
@@ -3427,23 +3407,19 @@
</section>
<section class="appendix informative">
-<h1>Acknowledgements</h1>
-
-<p>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 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.
-</p>
+ <h1>Acknowledgements</h1>
+
+ <p>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, 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 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.</p>
</section>
</body>