Restore changes accidentally overwritten by Manu
authorMarkus Lanthaler <mark_lanthaler@gmx.net>
Mon, 21 Jan 2013 17:22:46 +0100
changeset 1141 f75010f49dd7
parent 1140 7974e0ea5efc
child 1142 fc0c93f1476a
Restore changes accidentally overwritten by Manu

Manu's changes in e35b2acd997c4a15e4c6957610510df2ed89f329, e8972c75b46289f84ee0666c8661acf357aa0261, and e8972c75b46289f84ee0666c8661acf357aa0261 were based on an outdated version. This restores the lost changes while maintaining Manu's edits.

After discussing it with Manu, I also updated the authors and added @niklasl instead of Mark Birbeck.
contexts/person
contexts/person.jsonld
spec/latest/json-ld-syntax/index.html
--- a/contexts/person	Sun Jan 20 21:01:59 2013 -0500
+++ b/contexts/person	Mon Jan 21 17:22:46 2013 +0100
@@ -6,37 +6,42 @@
       "name": "http://xmlns.com/foaf/0.1/name",
       "nickname": "http://xmlns.com/foaf/0.1/nick",
       "affiliation": "http://schema.org/affiliation",
-      "depiction": 
+      "depiction":
       {
          "@id": "http://xmlns.com/foaf/0.1/depiction",
          "@type": "@id"
       },
-      "born": 
+      "image":
+      {
+         "@id": "http://xmlns.com/foaf/0.1/img",
+         "@type": "@id"
+      },
+      "born":
       {
          "@id": "http://schema.org/birthDate",
          "@type": "xsd:dateTime"
       },
-      "child": 
+      "child":
       {
          "@id": "http://schema.org/children",
          "@type": "@id"
       },
-      "colleague": 
+      "colleague":
       {
          "@id": "http://schema.org/colleagues",
          "@type": "@id"
       },
-      "knows": 
+      "knows":
       {
          "@id": "http://xmlns.com/foaf/0.1/knows",
          "@type": "@id"
       },
-      "died": 
+      "died":
       {
          "@id": "http://schema.org/deathDate",
          "@type": "xsd:dateTime"
       },
-      "email": 
+      "email":
       {
          "@id": "http://xmlns.com/foaf/0.1/mbox",
          "@type": "@id"
@@ -44,7 +49,7 @@
       "familyName": "http://xmlns.com/foaf/0.1/familyName",
       "givenName": "http://xmlns.com/foaf/0.1/givenName",
       "gender": "http://schema.org/gender",
-      "homepage": 
+      "homepage":
       {
          "@id": "http://xmlns.com/foaf/0.1/homepage",
          "@type": "@id"
@@ -53,22 +58,22 @@
       "honorificSuffix": "http://schema.org/honorificSuffix",
       "jobTitle": "http://xmlns.com/foaf/0.1/title",
       "nationality": "http://schema.org/nationality",
-      "parent": 
+      "parent":
       {
          "@id": "http://schema.org/parent",
          "@type": "@id"
       },
-      "sibling": 
+      "sibling":
       {
          "@id": "http://schema.org/sibling",
          "@type": "@id"
       },
-      "spouse": 
+      "spouse":
       {
          "@id": "http://schema.org/spouse",
          "@type": "@id"
       },
-      "telephone": "http://schema.org/telephone",      
+      "telephone": "http://schema.org/telephone",
       "Address": "http://www.w3.org/2006/vcard/ns#Address",
       "address": "http://www.w3.org/2006/vcard/ns#address",
       "street": "http://www.w3.org/2006/vcard/ns#street-address",
--- a/contexts/person.jsonld	Sun Jan 20 21:01:59 2013 -0500
+++ b/contexts/person.jsonld	Mon Jan 21 17:22:46 2013 +0100
@@ -6,37 +6,42 @@
       "name": "http://xmlns.com/foaf/0.1/name",
       "nickname": "http://xmlns.com/foaf/0.1/nick",
       "affiliation": "http://schema.org/affiliation",
-      "depiction": 
+      "depiction":
       {
          "@id": "http://xmlns.com/foaf/0.1/depiction",
          "@type": "@id"
       },
-      "born": 
+      "image":
+      {
+         "@id": "http://xmlns.com/foaf/0.1/img",
+         "@type": "@id"
+      },
+      "born":
       {
          "@id": "http://schema.org/birthDate",
          "@type": "xsd:dateTime"
       },
-      "child": 
+      "child":
       {
          "@id": "http://schema.org/children",
          "@type": "@id"
       },
-      "colleague": 
+      "colleague":
       {
          "@id": "http://schema.org/colleagues",
          "@type": "@id"
       },
-      "knows": 
+      "knows":
       {
          "@id": "http://xmlns.com/foaf/0.1/knows",
          "@type": "@id"
       },
-      "died": 
+      "died":
       {
          "@id": "http://schema.org/deathDate",
          "@type": "xsd:dateTime"
       },
-      "email": 
+      "email":
       {
          "@id": "http://xmlns.com/foaf/0.1/mbox",
          "@type": "@id"
@@ -44,7 +49,7 @@
       "familyName": "http://xmlns.com/foaf/0.1/familyName",
       "givenName": "http://xmlns.com/foaf/0.1/givenName",
       "gender": "http://schema.org/gender",
-      "homepage": 
+      "homepage":
       {
          "@id": "http://xmlns.com/foaf/0.1/homepage",
          "@type": "@id"
@@ -53,22 +58,22 @@
       "honorificSuffix": "http://schema.org/honorificSuffix",
       "jobTitle": "http://xmlns.com/foaf/0.1/title",
       "nationality": "http://schema.org/nationality",
-      "parent": 
+      "parent":
       {
          "@id": "http://schema.org/parent",
          "@type": "@id"
       },
-      "sibling": 
+      "sibling":
       {
          "@id": "http://schema.org/sibling",
          "@type": "@id"
       },
-      "spouse": 
+      "spouse":
       {
          "@id": "http://schema.org/spouse",
          "@type": "@id"
       },
-      "telephone": "http://schema.org/telephone",      
+      "telephone": "http://schema.org/telephone",
       "Address": "http://www.w3.org/2006/vcard/ns#Address",
       "address": "http://www.w3.org/2006/vcard/ns#address",
       "street": "http://www.w3.org/2006/vcard/ns#street-address",
--- 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/">[email protected]</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/">[email protected]</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/">[email protected]</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/">[email protected]</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&nbsp;<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)&nbsp;a simple string mapping the <tref>term</tref> to an <tref>IRI</tref>,
+      or 2)&nbsp;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>