Created JSON-LD syntax document.
authorManu Sporny <msporny@digitalbazaar.com>
Sat, 15 Oct 2011 19:56:40 -0400
changeset 214 a44b97b077a5
parent 213 3f3c47b2816d
child 215 71f9e8333bc7
Created JSON-LD syntax document.
spec/latest/index.html
spec/latest/json-ld-syntax/index.html
spec/latest/json-ld-syntax/spec.css
spec/latest/spec.css
--- a/spec/latest/index.html	Fri Oct 14 17:34:09 2011 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,4334 +0,0 @@
-<!DOCTYPE html>
-<html>
-<head>
-<title>JSON-LD 1.0</title>
-<meta http-equiv="content-type" content="text/html; charset=UTF-8">
-<!--
-  === NOTA BENE ===
-  For the three scripts below, if your spec resides on dev.w3 you can check them
-  out in the same tree and use relative links so that they'll work offline,
-  -->
-<script type="text/javascript"
-  src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove">
- </script>
-<script type="text/javascript" class="remove">
-
-    var preProc = {
-          apply:  function(c) {
-                    // extend the bibliography entries
-                    berjon.biblio["MICRODATA"] = "Ian Hickson; et al. <a href=\"http://www.w3.org/TR/microdata/\"><cite>Microdata</cite></a> 04 March 2010. W3C Working Draft. URL: <a href=\"http://www.w3.org/TR/microdata/\">http://www.w3.org/TR/microdata/</a> ";
-                    berjon.biblio["HTML-RDFA"] = "Manu Sporny; et al. <a href=\"http://www.w3.org/TR/rdfa-in-html/\"><cite>HTML+RDFa</cite></a> 04 March 2010. W3C Working Draft. URL: <a href=\"http://www.w3.org/TR/rdfa-in-html/\">http://www.w3.org/TR/rdfa-in-html/</a> ";
-                    berjon.biblio["BCP47"] = "A. Phillips, M. Davis. <a href=\"http://tools.ietf.org/rfc/bcp/bcp47.txt\"><cite>Tags for Identifying Languages</cite></a> September 2009. IETF Best Current Practice. URL: <a href=\"http://tools.ietf.org/rfc/bcp/bcp47.txt\">http://tools.ietf.org/rfc/bcp/bcp47.txt</a>";
-                    berjon.biblio["RDF-API"] = "Manu Sporny, Benjamin Adrian, Nathan Rixham; et al. <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-api/\"><cite>RDF API</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-api/\">http://www.w3.org/2010/02/rdfa/sources/rdf-api/</a>";
-                    berjon.biblio["RDF-INTERFACES"] = "Nathan Rixham, Manu Sporny, Benjamin Adrian; et al. <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/\"><cite>RDF Interfaces</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/\">http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/</a>";
-
-                    // process the document before anything else is done
-                    var refs = document.querySelectorAll('adef') ;
-                    for (var i = 0; i < refs.length; i++) {
-                        var item = refs[i];
-                        var p = item.parentNode ;
-                        var con = item.innerHTML ;
-                        var sp = document.createElement( 'dfn' ) ;
-                        var tit = item.getAttribute('title') ;
-                        if (!tit) {
-                            tit = con;
-                        }
-                        sp.className = 'adef' ;
-                        sp.title=tit ;
-                        sp.innerHTML = con ;
-                        p.replaceChild(sp, item) ;
-                    }
-                    refs = document.querySelectorAll('aref') ;
-                    for (var i = 0; i < refs.length; i++) {
-                        var item = refs[i];
-                        var p = item.parentNode ;
-                        var con = item.innerHTML ;
-                        var sp = document.createElement( 'a' ) ;
-                        sp.className = 'aref' ;
-                        sp.setAttribute('title', con);
-                        sp.innerHTML = '@'+con ;
-                        p.replaceChild(sp, item) ;
-                    }
-                    // local datatype references
-                    refs = document.querySelectorAll('ldtref') ;
-                    for (var i = 0; i < refs.length; i++) {
-                        var item = refs[i];
-                        if (!item) continue ;
-                        var p = item.parentNode ;
-                        var con = item.innerHTML ;
-                        var ref = item.getAttribute('title') ;
-                        if (!ref) {
-                            ref = item.textContent ;
-                        }
-                        if (ref) {
-                            ref = ref.replace(/\n/g, '_') ;
-                            ref = ref.replace(/\s+/g, '_') ;
-                        }
-                        var sp = document.createElement( 'a' ) ;
-                        sp.className = 'datatype';
-                        sp.title = ref ;
-                        sp.innerHTML = con ;
-                        p.replaceChild(sp, item) ;
-                    }
-                    // external datatype references
-                    refs = document.querySelectorAll('dtref') ;
-                    for (var i = 0; i < refs.length; i++) {
-                        var item = refs[i];
-                        if (!item) continue ;
-                        var p = item.parentNode ;
-                        var con = item.innerHTML ;
-                        var ref = item.getAttribute('title') ;
-                        if (!ref) {
-                            ref = item.textContent ;
-                        }
-                        if (ref) {
-                            ref = ref.replace(/\n/g, '_') ;
-                            ref = ref.replace(/\s+/g, '_') ;
-                        }
-                        var sp = document.createElement( 'a' ) ;
-                        sp.className = 'externalDFN';
-                        sp.title = ref ;
-                        sp.innerHTML = con ;
-                        p.replaceChild(sp, item) ;
-                    }
-                    // now do terms
-                    refs = document.querySelectorAll('tdef') ;
-                    for (var i = 0; i < refs.length; i++) {
-                        var item = refs[i];
-                        if (!item) continue ;
-                        var p = item.parentNode ;
-                        var con = item.innerHTML ;
-                        var ref = item.getAttribute('title') ;
-                        if (!ref) {
-                            ref = item.textContent ;
-                        }
-                        if (ref) {
-                            ref = ref.replace(/\n/g, '_') ;
-                            ref = ref.replace(/\s+/g, '_') ;
-                        }
-                        var sp = document.createElement( 'dfn' ) ;
-                        sp.title = ref ;
-                        sp.innerHTML = con ;
-                        p.replaceChild(sp, item) ;
-                    }
-                    // now term references
-                    refs = document.querySelectorAll('tref') ;
-                    for (var i = 0; i < refs.length; i++) {
-                        var item = refs[i];
-                        if (!item) continue ;
-                        var p = item.parentNode ;
-                        var con = item.innerHTML ;
-                        var ref = item.getAttribute('title') ;
-                        if (!ref) {
-                            ref = item.textContent ;
-                        }
-                        if (ref) {
-                            ref = ref.replace(/\n/g, '_') ;
-                            ref = ref.replace(/\s+/g, '_') ;
-                        }
-
-                        var sp = document.createElement( 'a' ) ;
-                        var id = item.textContent ;
-                        sp.className = 'tref' ;
-                        sp.title = ref ;
-                        sp.innerHTML = con ;
-                        p.replaceChild(sp, item) ;
-                    }
-                }
-        } ;
-
-
-      var respecConfig = {
-          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
-          specStatus:           "unofficial",
-          //publishDate:          "2010-04-29",
-          copyrightStart:       "2010",
-
-          // the specification's short name, as in http://www.w3.org/TR/short-name/
-          shortName:            "json-ld",
-          subtitle:             "A Context-based JSON Serialization for Linking Data",
-          // if you wish the publication date to be other than today, set this
-          // publishDate:  "2009-08-06",
-
-          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
-          // and its maturity status
-          previousPublishDate:  "2011-08-17",
-          previousMaturity:     "ED",
-          previousDiffURI:      "http://json-ld.org/spec/ED/20110817/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://json-ld.org/spec/latest/",
-
-          // if this is a LCWD, uncomment and set the end of its review period
-          // lcEnd: "2009-08-05",
-
-          // if you want to have extra CSS, append them to this list
-          // it is recommended that the respec.css stylesheet be kept
-          extraCSS:             [
-              "http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css",
-              "spec.css"
-          ],
-
-          // editors, add as many as you like
-          // only "name" is required
-          editors:  [
-              { name: "Manu Sporny", url: "http://manu.sporny.org/",
-                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
-              { name: "Gregg Kellogg", url: "http://greggkellogg.net/",
-                company: "Kellogg Associates" },
-              { name: "Dave Longley", url: "http://digitalbazaar.com/",
-                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"}
-          ],
-
-          // authors, add as many as you like.
-          // This is optional, uncomment if you have authors as well as editors.
-          // only "name" is required. Same format as editors.
-
-          authors:  [
-              { name: "Manu Sporny", url: "http://digitalbazaar.com/",
-                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
-              { name: "Gregg Kellogg", url: "http://greggkellogg.net/",
-                company: "Kellogg Associates" },
-              { name: "Dave Longley", url: "http://digitalbazaar.com/",
-                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"},
-              { name: "Mark Birbeck", url: "http://webbackplane.com/",
-                company: "Backplane Ltd.", companyURL: "http://webbackplane.com/" },
-          ],
-
-          // name of the WG
-          wg:           "Linking Data in JSON Community Group",
-
-          // URI of the public WG page
-          wgURI:        "http://json-ld.org/",
-
-          // name (with the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "[email protected]",
-
-          // URI of the patent status for this WG, for Rec-track documents
-          // !!!! IMPORTANT !!!!
-          // This is important for Rec-track documents, do not copy a patent URI from a random
-          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
-          // Team Contact.
-          wgPatentURI:  "",
-          maxTocLevel: 4,
-          preProcess: [ preProc ],
-          alternateFormats: [ {uri: "diff-20110817.html", label: "diff to previous version"} ],
-      };
-
-      function updateExample(doc, content) {
-        // perform transformations to make it render and prettier
-        content = content.replace(/<!--/, '');
-        content = content.replace(/-->/, '');
-        content = doc._esc(content);
-        content = content.replace(/\*\*\*\*([^*]*)\*\*\*\*/g, '<span class="diff">$1</span>') ;
-        return content ;
-      }
-
-      function updateDTD(doc, content) {
-        // perform transformations to
-        // make it render and prettier
-        content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
-        content = content.replace(/!ENTITY % ([^ \t\r\n]*)/g, '!ENTITY <span class="entity">% $1</span>');
-        content = content.replace(/!ELEMENT ([^ \t$]*)/mg, '!ELEMENT <span class="element">$1</span>');
-        return content;
-      }
-
-      function updateSchema(doc, content) {
-        // perform transformations to
-        // make it render and prettier
-        content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
-        content = content.replace(/&lt;xs:element\s+name=&quot;([^&]*)&quot;/g, '&lt;xs:element name="<span class="element" id="schema_element_$1">$1</span>"') ;
-        return content;
-      }
-
-      function updateTTL(doc, content) {
-        // perform transformations to
-        // make it render and prettier
-        content = '<pre class="sh_sourceCode">' + doc._esc(content) + '</pre>';
-        content = content.replace(/@prefix/g, '<span class="sh_keyword">@prefix</span>');
-        return content;
-      }
-  </script>
-<style>
-.diff { font-weight:bold; color:#0a3; }
-ol.algorithm.update { margin-left: 2em; }
-ol.algorithm.update>li { list-style-type: none; }
-ol.algorithm.update>li>span.list-number {
-  display:block;
-  float: left;
-  margin-left: -3.5em;
-}
-</style>
-</head>
-
-<body>
-<section id="abstract">
-<p>
-JSON [[!RFC4627]] has proven to be a highly useful object serialization and
-messaging format. In an attempt to harmonize the representation of Linked Data
-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 is an experimental work in progress.</p>
-<!-- <p>
-This document has been reviewed by W3C Members, by software
-developers, and by other W3C groups and interested parties, and is
-endorsed by the Director as a W3C Recommendation. It is a stable
-document and may be used as reference material or cited from another
-document. W3C's role in making the Recommendation is to draw attention
-to the specification and to promote its widespread deployment. This
-enhances the functionality and interoperability of the Web.
-</p> -->
-</section>
-
-<section>
-<h1>Introduction</h1>
-
-<p>
-JSON, as specified in [[!RFC4627]], is a simple language for representing
-data on the Web. Linked Data is a technique for creating a graph of interlinked data across
-different
-documents or Web sites. Data entities are described using <tref>IRI</tref>s,
-which are typically dereferencable and thus may be used to find more
-information about an entity, creating a "Web of Knowledge". JSON-LD is intended to be a simple
-publishing method for expressing not only Linked Data in JSON, but also for adding
-semantics to existing JSON.
-</p>
-
-<p>
-JSON-LD is designed as a light-weight syntax that can be used to express
-Linked Data. It is primarily intended to be a way to use Linked Data
-in Javascript and other Web-based programming environments. It is also
-useful when building interoperable Web services and when storing Linked
-Data in JSON-based document storage engines. It is practical and designed
-to be as simple as possible, utilizing the large number of JSON parsers
-and libraries available today. It is designed to be able to
-express key-value pairs, RDF data, RDFa [[RDFA-CORE]] data, Microformats
-[[MICROFORMATS]] data, and Microdata [[MICRODATA]]. That is, it supports
-every major Web-based structured data model in use today.
-</p>
-
-<p>
-The syntax does not necessarily require applications to change their JSON, but
-allows to easily add meaning by adding context in a way that is either in-band or
-out-of-band. The syntax is designed to not disturb already deployed systems
-running on JSON, but provide a smooth upgrade path from JSON to JSON with
-added semantics. Finally, the format is intended to be easy to parse, efficient to
-generate, convertible to RDF in one pass, and require a very small memory footprint
-in order to operate.
-</p>
-
-<section>
-<h2>How to Read this Document</h2>
-
-<p>
-This document is a detailed specification for a serialization of Linked
-Data in JSON. The document is primarily intended for the following audiences:
-</p>
-
-<ul>
-  <li>Web developers that want to understand the design decisions and
-  language syntax for JSON-LD.</li>
-  <li>Software developers that want to encode Microformats, RDFa, or Microdata
-  in a way that is cross-language compatible via JSON.</li>
-  <li>Software developers that want to implement processors and APIs for
-  JSON-LD.</li>
-</ul>
-
-<p>
-To understand the basics in this specification you must first be familiar with
-JSON, which is detailed in [[!RFC4627]]. To understand the API and how it is
-intended to operate  in a programming environment, it is useful to have working
-knowledge of the JavaScript programming language [[ECMA-262]] and
-WebIDL [[!WEBIDL]]. To understand how JSON-LD maps to RDF, it is helpful to be
-familiar with the basic RDF concepts [[!RDF-CONCEPTS]].</p>
-
-<p>
-  Examples may contain references to existing vocabularies and use <tref>prefix</tref>es to refer to Web Vocabularies. The following is a list of all vocabularies and their <tref>prefix</tref> abbreviations, as used in this document:
-</p>
-<ul>
-  <li>The <a href="http://purl.org/dc/terms/">Dublin Core</a>
-  vocabulary (abbreviation: <code>dc</code>, e.g., <code>dc:title</code>)</li>
-  <li>The <a href="http://xmlns.com/foaf/0.1/">Friend of a Friend</a>
-  vocabulary (abbreviation: <code>foaf</code>, e.g., <code>foaf:knows</code>)</li>
-  <li>The <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">RDF</a>
-  vocabulary (abbreviation: <code>rdf</code>, e.g., <code>rdf:type</code>)</li>
-  <li>The <a href="http://www.w3.org/2001/XMLSchema#">XSD</a>
-  vocabulary (abbreviation: <code>xsd</code>, e.g., <code>xsd:integer</code>)</li>
-</ul>
-
-<p>
-  JSON [[RFC4627]] defines several terms which are used throughout this document:
-  <dl>
-    <dt><tdef>JSON Object</tdef></dt><dd>
-      An object structure is represented as a pair of curly brackets surrounding zero or
-      more name/value pairs (or members). A name is a <tref>string</tref>. A single colon comes after
-      each name, separating the name from the value. A single comma separates a value
-      from a following name. The names within an object SHOULD be unique.
-    </dd>
-    <dt><tdef>array</tdef></dt>
-    <dd>
-      An array is an ordered collection of values. An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas.  Within JSON-LD, array order is not preserved by default, unless
-      specific markup is provided (see <a href="#lists">Lists</a>). This is because the basic data model of JSON-LD
-      is a directed <tref>graph</tref>, which is inherently unordered.
-    </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. A
-      character is represented as a single character string.
-    </dd>
-    <dt><tdef>number</tdef></dt>
-    <dd>
-      A number is 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>
-      Boolean values.
-    </dd>
-    <dt><tdef>null</tdef></dt><dd>
-      The use of the <em>null</em> value is undefined within JSON-LD.
-      <div class="issue">Supporting <em>null</em> in JSON-LD might have a number of advantages and should be evaluated. This is currently an <a href="https://github.com/json-ld/json-ld.org/issues/11">open issue</a>.</div>
-    </dd>
-  </dl>
-</p>
-</section>
-
-<section>
-<h2>Contributing</h2>
-
-<p>There are a number of ways that one may participate in the development of
-this specification:</p>
-
-<ul>
-<li>Technical discussion typically occurs on the public 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 teleconferences</a> are held
-on Tuesdays at 1500UTC on the second and fourth week of each month.
-</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>.</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>
-
-<section>
-<h1>Design</h1>
-
-<p>The following section outlines the design goals and rationale behind the
-JSON-LD markup language.
-</p>
-
-<section>
-<h2>Goals and Rationale</h2>
-
-<p>
-A number of design considerations were explored during the creation of this
-markup language:
-</p>
-
-<dl>
- <dt>Simplicity</dt>
- <dd>Developers need only know JSON and three keywords to use the basic
- functionality in JSON-LD. No extra processors or software libraries are
- necessary to use JSON-LD in its most basic form. The language attempts to
- ensure that developers have an easy learning curve.</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 simply 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 as possible effort 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 provides a mechanism that allows developers to specify
- context in a way that is out-of-band. This allows organizations that have
- already deployed large JSON-based infrastructure to add meaning to their
- JSON documents in a way that is not disruptive to their day-to-day operations and is
- transparent to their current customers. At times, mapping JSON to
- a graph representation can become difficult. In these instances, rather than
- having JSON-LD support esoteric markup, we chose not to support the use case
- and support a simplified syntax instead. So, while Zero Edits is a goal,
- it is not always possible without adding great complexity to the language.
- </dd>
- <dt>One-pass Conversion to RDF</dt>
- <dd>JSON-LD supports one-pass conversion to RDF with a very small memory footprint.</dd>
-</dl>
-</section>
-
-<section>
-<h2>Linked Data</h2>
-<p>
-The following definition for <tref>Linked Data</tref> is the one that will
-be used for this specification.
-</p>
-<ol>
-  <li><tdef>Linked Data</tdef> is a set of documents, each containing a representation of a linked data graph.</li>
-  <li>A <tdef>linked data graph</tdef> is an unordered labeled directed graph, where nodes are <tref>subject</tref>s or <tref>object</tref>s, and edges are properties.</li>
-  <li>A <tdef>subject</tdef> is any node in a <tref>linked data graph</tref> with at least one outgoing edge.</li>
-  <li>A <tref>subject</tref> SHOULD be labeled with an <tref>IRI</tref> (an Internationalized Resource Identifier as described in [[!RFC3987]]).</li>
-  <li>An <tdef>object</tdef> is a node in a <tref>linked data graph</tref> with at least one incoming edge.</li>
-  <li>An <tref>object</tref> MAY be labeled with an <tref>IRI</tref>.</li>
-  <li>An object MAY be a <tdef>subject</tdef> and <tref>object</tref> at the same time.</li>
-  <li>A <tdef>property</tdef> is an edge of the <tref>linked data graph</tref>.</li>
-  <li>A <tref>property</tref> SHOULD be labeled with an <tref>IRI</tref>.</li>
-  <li>An <tref>IRI</tref> that is a label in a <tref>linked data graph</tref> SHOULD be dereferencable to a <tref>Linked Data</tref> document describing the labeled <tref>subject</tref>, <tref>object</tref> or <tref>property</tref>.</li>
-  <li>A <tdef>literal</tdef> is an <tref>object</tref> with a label that is not an <tref>IRI</tref></li>
-</ol>
-
-<p>
-Note that the definition for <tref>Linked Data</tref> above is silent on the
-topic of unlabeled nodes. Unlabeled nodes are not considered
-<tref>Linked Data</tref>. However, this specification allows for the expression
-of unlabled nodes, as most graph-based data sets on the Web contain a number
-of associated nodes that are not named and thus are not directly
-de-referenceable.
-</p>
-</section>
-
-<section>
-<h2>Linking Data</h2>
-
-<p>
-An Internationalized Resource Identifier
-(<tdef><abbr title="Internationalized Resource Identifier">IRI</abbr></tdef>),
-as described in [[!RFC3987]], is a mechanism for representing unique
-identifiers on the web. In <tref>Linked Data</tref>, an IRI is commonly
-used for expressing a <tref>subject</tref>, a <tref>property</tref> or an
-<tref>object</tref>.
-</p>
-
-<p>JSON-LD defines a mechanism to map JSON terms, i.e., keys and values, to IRIs. This does not mean
-that JSON-LD requires every key or value to be an IRI, but rather ensures that
-keys and values can be mapped to IRIs if the developer desires to transform
-their data into Linked Data. There are a few techniques that can ensure
-that developers will generate good Linked Data for the Web. JSON-LD
-formalizes those techniques.
-</p>
-
-<p>We will be using the following JSON markup as the example for the
-rest of this section:
-</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "name": "Manu Sporny",
-  "homepage": "http://manu.sporny.org/",
-  "avatar": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-</section>
-
-<section>
-<h3>The Context</h3>
-
-<p>In JSON-LD, a context is used to map <tref>term</tref>s, i.e., keys and values
-  in an JSON document, to
-  <tref>IRI</tref>s. A <tdef>term</tdef> is a short word that MAY be expanded
-to an <tref>IRI</tref>. The Web uses IRIs for unambiguous identification. The
-idea is that these <tref>term</tref>s mean 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>term</tref>s to expand to IRIs so that
-developers don't accidentally step on each other's Web Vocabulary terms.
-For example, the term <code>name</code> may map directly to the IRI
-<code>http://xmlns.com/foaf/0.1/name</code>. This allows JSON-LD documents to
-be constructed using the common JSON practice of simple name/value pairs while
-ensuring that the data is useful outside of the page, API or database in which it
-resides.
-</p>
-
-<p>These Linked Data <tref>term</tref>s are typically collected in a context document that would look something like this:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-    "name": "http://xmlns.com/foaf/0.1/name",
-    "homepage": "http://xmlns.com/foaf/0.1/homepage",
-    "avatar": "http://xmlns.com/foaf/0.1/avatar"
-}
--->
-</pre>
-
-<p>This context document can then be used in an JSON-LD document by adding a single line. The JSON markup as shown in the previous section could be changed as follows to link to the context document:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  ****"@context": "http://example.org/json-ld-contexts/person",****
-  "name": "Manu Sporny",
-  "homepage": "http://manu.sporny.org/",
-  "avatar": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-
-<p>The addition above transforms 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>avatar</strong>
-terms map to IRIs.
-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 inter-operate on a
-site-by-site basis. Contexts may also contain datatype information
-for certain <tref>term</tref>s as well as other processing instructions for
-the JSON-LD processor.</p>
-<p>Contexts may be specified in-line. This ensures that JSON-LD documents
-can be processed when a JSON-LD processor does not have access to the Web.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  ****"@context": {
-    "name": "http://xmlns.com/foaf/0.1/name",
-    "homepage": "http://xmlns.com/foaf/0.1/homepage",
-    "avatar": "http://xmlns.com/foaf/0.1/avatar"
-  },****
-  "name": "Manu Sporny",
-  "homepage": "http://manu.sporny.org/",
-  "avatar": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-
-<p>JSON-LD strives to ensure that developers don't have to change the JSON
-  that is going into and being returned from their Web APIs. This means
-  that developers can also specify a context for JSON data in an out-of-band
-  fashion. This is described later in this document. </p>
-
-<p>
-  JSON-LD uses a special type of machine-readable document called a
-  <tdef>Web Vocabulary</tdef> to define <tref>term</tref>s that are then used
-  to describe concepts and "things" in the world.
-  Typically, these Web Vocabulary documents have <tref>prefix</tref>es associated
-  with them and contain a number of <tref>term</tref> declarations. A
-  <tdef>prefix</tdef>, like a <tref>term</tref>, is a short word that expands
-  to a Web Vocabulary base IRI. <tref>Prefix</tref>es are helpful when a developer
-  wants to mix multiple vocabularies together in a context, but does not want
-  to go to the trouble of defining every single term in every single vocabulary.
-  Some Web Vocabularies may have dozens of terms defined. If a developer wants to use
-  3-4 different vocabularies, the number of terms that
-  would have to be declared in a single context could become quite large. To
-  reduce the number of different terms that must be defined, JSON-LD also allows
-  prefixes to be used to compact IRIs.
-<p>
-
-<p>For example, the IRI <code>http://xmlns.com/foaf/0.1/</code>
-specifies a <tref>Web Vocabulary</tref> which may be represented using the
-<code>foaf</code> <tref>prefix</tref>. The <code>foaf</code> Web Vocabulary
-contains a term called <strong>name</strong>. If you join the
-<code>foaf</code> <tref>prefix</tref> with the <strong>name</strong> suffix,
-you can build a compact IRI that will expand out into an absolute IRI for the
-<code>http://xmlns.com/foaf/0.1/name</code> vocabulary term.
-That is, the compact IRI, or short-form, is <code>foaf:name</code> and the
-expanded-form is <code>http://xmlns.com/foaf/0.1/name</code>. This vocabulary
-term is used to specify a person's name.
-</p>
-
-<p>Developers, and machines, are able to use this IRI (plugging it
-directly into a web browser, for instance) to go to the term and get a
-definition of what the term means. Much like we can use <a href="http://wordnet.princeton.edu/">WordNet</a> today to
-see the definition
-of words in the English language. Developers and machines need the same sort of
-definition of terms. IRIs provide a way to ensure that these terms
-are unambiguous.
-</p>
-
-<p>The context provides a collection of vocabulary <tref>term</tref>s and
-<tref>prefix</tref>es that can be used to expand JSON keys and values into
-<tref>IRI</tref>s.</p>
-
-<p class="note">To ensure the best possible performance, it is a best practice to
-put the context 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 context is processed.
-This creates a memory and complexity burden for one-pass processors.</p>
-
-</section>
-
-<section>
-<h3>From JSON to JSON-LD</h3>
-
-<p>If a set of terms such as, <strong>name</strong>, <strong>homepage</strong>,
-and <strong>avatar</strong>,
-are defined in a context, and that context is used to resolve the
-names in JSON objects, machines are able to automatically expand the terms to
-something meaningful and unambiguous, like this:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "****http://xmlns.com/foaf/0.1/name****": "Manu Sporny",
-  "****http://xmlns.com/foaf/0.1/homepage****": "http://manu.sporny.org"
-  "****http://rdfs.org/sioc/ns#avatar****": "http://twitter.com/account/profile_image/manusporny"
-}
- -->
-</pre>
-
-<p>Doing this allows JSON to be unambiguously machine-readable without
-requiring developers to drastically change their workflow.</p>
-<p class="note">Please note that this JSON-LD document doesn't define the
-subject and will thus result in an unlabeled or blank node.</p>
-
-</section>
-
-</section>
-
-</section>
-
-<section>
-<h1>Basic Concepts</h1>
-
-<p>JSON-LD is designed to ensure that Linked Data concepts can be marked
-up in a way that is simple to understand and author by Web developers. In many
-cases, regular JSON markup can become Linked Data with the simple addition
-of a context. As more JSON-LD features are used, more semantics are added
-to the JSON markup.</p>
-
-<section>
-<h2>IRIs</h2>
-
-<p>Expressing IRIs are fundamental to Linked Data as that is how most
-<tref>subject</tref>s and many <tref>object</tref> are named. IRIs can be
-expressed in a variety of different ways in JSON-LD.</p>
-
-<ol>
-  <li>In general, <tref>term</tref>s in the key position in
-    a <tref>JSON object</tref> that have a mapping to an IRI or another key in the context are
-    expanded to an IRI by JSON-LD processors. There are special rules for
-    processing keys in <code>@context</code> and when dealing with keys that
-    start with the <code>@subject</code> character.</li>
-  <li>An IRI is generated for the value specified using <code>@subject</code>,
-    if it is a <tref>string</tref>.</li>
-  <li>An IRI is generated for the value specified using <code>@type</code>.</li>
-  <li>An IRI is generated for the value specified using the <code>@iri</code>
-    keyword.</li>
-  <li>An IRI is generated when there are <code>@coerce</code> rules in
-    effect for a key named <code>@iri</code>.</li>
-</ol>
-
-<p>IRIs can be expressed directly in the key position like so:
-</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "****http://xmlns.com/foaf/0.1/name****": "Manu Sporny",
-...
-}
--->
-</pre>
-
-<p>In the example above, the key
-<code>http://xmlns.com/foaf/0.1/name</code> is interpreted as an IRI, as
-opposed to being interpreted as a string.</p>
-
-<p>Term expansion occurs for IRIs if a term is defined within the
-<tref>active context</tref>:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "****@context****": {"****name****": "****http://xmlns.com/foaf/0.1/name****"},
-...
-  "****name****": "Manu Sporny",
-...
-}
--->
-</pre>
-
-<p><tref>Prefix</tref>es are expanded when used in keys:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "****@context****": {"****foaf****": "****http://xmlns.com/foaf/0.1/****"},
-...
-  "****foaf:name****": "Manu Sporny",
-...
-}
--->
-</pre>
-
-<p><code>foaf:name</code> above will automatically expand out to the IRI
-<code>http://xmlns.com/foaf/0.1/name</code>.</p>
-
-<p>An IRI is generated when a value is associated with a key using
-the <code>@iri</code> keyword:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "homepage": { "****@iri****": "http://manu.sporny.org" }
-...
-}
--->
-</pre>
-
-<p>If type coercion rules are specified in the <code>@context</code> for
-a particular vocabulary term, an IRI is generated:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{****
-  "@context":
-  {
-    ...
-    "@coerce":
-    {
-      "@iri": "homepage"
-    }
-  }****
-...
-  "homepage": "http://manu.sporny.org/",
-...
-}
--->
-</pre>
-
-<p>Even though the value <code>http://manu.sporny.org/</code> is a <tref>string</tref>,
-the type coercion rules will transform the value into an IRI when processed
-by a JSON-LD Processor</p>
-
-</section>
-
-<section>
-<h2>Identifying the Subject</h2>
-
-<p>
-  To be able to externally reference nodes, it is important that each node has an unambiguous identifier.
-  <tref>IRI</tref>s are a fundamental concept of Linked Data, and nodes should have a de-referencable
-  identifier used to name and locate them. For nodes to be truely 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>subject</tref>
-   of an object in JSON is declared using the <code>@subject</code> key. The subject is the
-first piece of information needed by the JSON-LD processor in order to
-create the (subject, property, object) tuple, also known as a triple.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "****@subject****": "****http://example.org/people#joebob****",
-...
-}
--->
-</pre>
-
-<p>The example above would set the subject to the IRI
-<code>http://example.org/people#joebob</code>.
-</p>
-
-<p class="note">To ensure the best possible performance, it is a best practice to
-put the <code>@subject</code> key before other key-value pairs in an object. If
-it isn't listed first, processors have to save each key-value pair until
-<code>@subject</code> is processed before they can create valid triples. This
-creates a memory and complexity burden for one-pass processors.</p>
-
-</section>
-
-<section>
-<h2>Specifying the Type</h2>
-
-<p>The type of a particular subject can be specified using the
-<code>@type</code> key. Specifying the type in this way will generate a
-triple of the form (subject, type, type-iri).</p>
-
-<p>To be Linked Data, types MUST be uniquely identified by an
-  <tref>IRI</tref>.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "@subject": "http://example.org/people#joebob",
-  "****@type****": "****http://xmlns.com/foaf/0.1/Person****",
-...
-}
--->
-</pre>
-
-<p>The example above would generate the following triple if the JSON-LD
-document is mapped to RDF (in N-Triples notation):</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<http://example.org/people#joebob>
-   <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
-      <http://xmlns.com/foaf/0.1/Person> .
--->
-</pre>
-
-</section>
-
-<section>
-<h2>Strings</h2>
-
-<p>Regular text strings, also referred to as <tdef>plain literal</tdef>s, are
-easily expressed using regular JSON <tref>string</tref>s.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "name": "****Mark Birbeck****",
-...
-}
- -->
-</pre>
-
-</section>
-
-<section>
-<h2>String Internationalization</h2>
-
-<p>JSON-LD makes an assumption that strings with associated language encoding
-information are not very common when used in JavaScript and Web Services.
-Thus, it takes a little more effort to express strings with associated
-language information.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "name": ****
-  {
-    "@literal": "花澄",
-    "@language": "ja"
-  }****
-...
-}
--->
-</pre>
-
-<p>The example above would generate a <tref>plain literal</tref> for
-<em>花澄</em> and associate the <code>ja</code> language code with the triple
-that is generated. Languages MUST be expressed in [[!BCP47]] format.</p>
-
-</section>
-
-<section>
-<h2>Datatypes</h2>
-
-<p>
-  A value with an associated datatype, also known as a
-  <tdef>typed literal</tdef>, is indicated by associating a literal with
-  an IRI which indicates the literal's datatype. Typed literals may be
-  expressed in JSON-LD in three ways:
-</p>
-
-<ol>
-  <li>By utilizing the <code>@coerce</code> keyword.</li>
-  <li>By utilizing the expanded form for specifying objects.</li>
-  <li>By using a native JSON datatype.</li>
-</ol>
-
-<p>The first example uses the <code>@coerce</code> keyword to express a
-typed literal:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{****
-  "@context":
-  {
-    "modified":  "http://purl.org/dc/terms/modified",
-    "dateTime": "http://www.w3.org/2001/XMLSchema#dateTime"
-    "@coerce":
-    {
-      "dateTime": "modified"
-    }
-  }****
-...
-  "modified": "2010-05-29T14:17:39+02:00",
-...
-}
--->
-</pre>
-
-<p>The second example uses the expanded form for specifying objects:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "modified": ****
-  {
-    "@literal": "2010-05-29T14:17:39+02:00",
-    "@datatype": "dateTime"
-  }****
-...
-}
--->
-</pre>
-
-<p>Both examples above would generate an object with the literal value of
-<code>2010-05-29T14:17:39+02:00</code> and the datatype of
-<code>http://www.w3.org/2001/XMLSchema#dateTime</code>.</p>
-
-<p>The third example uses a built-in native JSON type, a
-  <tref>number</tref>, to express a datatype:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "@subject": "http://example.org/people#joebob",
-  "age": ****31****
-...
-}
--->
-</pre>
-
-<p>The example above would generate the following triple:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<http://example.org/people#joebob>
-   <http://xmlns.com/foaf/0.1/age>
-      "31"^^<http://www.w3.org/2001/XMLSchema#integer> .
--->
-</pre>
-
-</section>
-
-<section>
-<h2>Multiple Objects for a Single Property</h2>
-
-<p>A JSON-LD author can express multiple triples in a compact way by using
-<tref>array</tref>s. If a subject has multiple values for the same property, the author
-MAY express each property as an <tref>array</tref>.</p>
-
-<p class="note">In JSON-LD, multiple objects on a property are not ordered. This is because typically graphs
-are not inherently ordered data structures. To see more on creating ordered collections
-in JSON-LD, see <a href="#lists">Lists</a>.
-</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "@subject": "http://example.org/people#joebob",
-  "nick": ****["joe", "bob", "jaybee"]****,
-...
-}
--->
-</pre>
-
-<p>The markup shown above would generate the following triples:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<http://example.org/people#joebob>
-   <http://xmlns.com/foaf/0.1/nick>
-      "joe" .
-<http://example.org/people#joebob>
-   <http://xmlns.com/foaf/0.1/nick>
-      "bob" .
-<http://example.org/people#joebob>
-   <http://xmlns.com/foaf/0.1/nick>
-      "jaybee" .
--->
-</pre>
-
-</section>
-
-<section>
-<h2>Multiple Typed Literals for a Single Property</h2>
-
-<p>Multiple <tref>typed literal</tref>s may also be expressed using the expanded
-form for objects:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "@subject": "http://example.org/articles/8",
-  "modified": ****
-  [
-    {
-      "@literal": "2010-05-29T14:17:39+02:00",
-      "@datatype": "dateTime"
-    },
-    {
-      "@literal": "2010-05-30T09:21:28-04:00",
-      "@datatype": "dateTime"
-    }
-  ]****
-...
-}
--->
-</pre>
-
-<p>The markup shown above would generate the following triples:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<http://example.org/articles/8>
-   <http://purl.org/dc/terms/modified>
-      "2010-05-29T14:17:39+02:00"^^http://www.w3.org/2001/XMLSchema#dateTime .
-<http://example.org/articles/8>
-   <http://purl.org/dc/terms/modified>
-      "2010-05-30T09:21:28-04:00"^^http://www.w3.org/2001/XMLSchema#dateTime .
--->
-</pre>
-
-</section>
-
-<section>
-<h2>Expansion</h2>
-
-<p>Expansion is the process of taking a JSON-LD document and applying a
-context such that all IRI, datatypes, and literal values are expanded so
-that the context is no longer necessary. JSON-LD document expansion
-is typically used as a part of <a href="#normalization">Framing</a> or
-<a href="#normalization">Normalization</a>.</p>
-
-<p>For example, assume the following JSON-LD input document:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-   "@context":
-   {
-      "name": "http://xmlns.com/foaf/0.1/name",
-      "homepage": "http://xmlns.com/foaf/0.1/homepage",
-      "@coerce":
-      {
-         "@iri": "homepage"
-      }
-   },
-   "name": "Manu Sporny",
-   "homepage": "http://manu.sporny.org/"
-}
--->
-</pre>
-
-<p>Running the JSON-LD Expansion algorithm against the JSON-LD input document
-provided above would result in the following output:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-   "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
-   "http://xmlns.com/foaf/0.1/homepage":
-   {
-      "@iri": "http://manu.sporny.org/"
-   }
-}
--->
-</pre>
-
-</section>
-
-<section>
-<h2>Compaction</h2>
-
-<p>Compaction is the process of taking a JSON-LD document and applying a
-context such that the most compact form of the document is generated. JSON
-is typically expressed in a very compact, key-value format. That is, full
-IRIs are rarely used as keys. At times, a JSON-LD document may be received
-that is not in its most compact form. JSON-LD, via the API, provides a way
-to compact a JSON-LD document.
-</p>
-
-<p>For example, assume the following JSON-LD input document:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-   "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
-   "http://xmlns.com/foaf/0.1/homepage":
-   {
-      "@iri": "http://manu.sporny.org/"
-   }
-}
--->
-</pre>
-
-<p>Additionally, assume the following developer-supplied JSON-LD context:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-   "name": "http://xmlns.com/foaf/0.1/name",
-   "homepage": "http://xmlns.com/foaf/0.1/homepage",
-   "@coerce":
-   {
-      "@iri": "homepage"
-   }
-}
--->
-</pre>
-
-<p>Running the JSON-LD Compaction algorithm given the context supplied above
-against the JSON-LD input document provided above would result in the following
-output:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-   "@context":
-   {
-      "name": "http://xmlns.com/foaf/0.1/name",
-      "homepage": "http://xmlns.com/foaf/0.1/homepage",
-      "@coerce":
-      {
-         "@iri": "homepage"
-      }
-   },
-   "name": "Manu Sporny",
-   "homepage": "http://manu.sporny.org/"
-}
--->
-</pre>
-
-<p>The compaction algorithm also enables the developer to map any expanded
-format into an application-specific compacted format. While the context
-provided above mapped <code>http://xmlns.com/foaf/0.1/name</code> to
-<strong>name</strong>, it could have also mapped it to any arbitrary string
-provided by the developer.
-</p>
-
-</section>
-
-<section>
-<h2>Framing</h2>
-
-<p>A JSON-LD document is a representation of a directed graph. A single
-directed graph can have many different serializations, each expressing
-exactly the same information. Developers typically work with trees, represented as
-<tref>JSON object</tref>s. While mapping a graph to
-a tree can be done, the layout of the end result must be specified in advance.
-A <tdef>Frame</tdef> can be used by a developer on a JSON-LD document to
-specify a deterministic layout for a graph.
-</p>
-
-<p>Framing is the process of taking a JSON-LD document, which expresses a
-graph of information, and applying a specific graph layout
-(called a <tref>Frame</tref>).
-</p>
-
-<p>The JSON-LD document below expresses a library, a book and a chapter:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context": {
-    "Book":         "http://example.org/vocab#Book",
-    "Chapter":      "http://example.org/vocab#Chapter",
-    "contains":     "http://example.org/vocab#contains",
-    "creator":      "http://purl.org/dc/terms/creator"
-    "description":  "http://purl.org/dc/terms/description"
-    "Library":      "http://example.org/vocab#Library",
-    "title":        "http://purl.org/dc/terms/title",
-    "@coerce":
-    {
-      "@iri": "contains"
-    },
-  },
-  "@subject":
-  [{
-    "@subject": "http://example.com/library",
-    "@type": "Library",
-    "contains": "http://example.org/library/the-republic"
-  },
-  {
-    "@subject": "http://example.org/library/the-republic",
-    "@type": "Book",
-    "creator": "Plato",
-    "title": "The Republic",
-    "contains": "http://example.org/library/the-republic#introduction"
-  },
-  {
-    "@subject": "http://example.org/library/the-republic#introduction",
-    "@type": "Chapter",
-    "description": "An introductory chapter on The Republic.",
-    "title": "The Introduction"
-  }]
-}-->
-</pre>
-
-<p>Developers typically like to operate on items in a hierarchical, tree-based
-fashion. Ideally, a developer would want the data above sorted into top-level
-libraries, then the books that are contained in each library, and then the
-chapters contained in each book. To achieve that layout, the developer can
-define the following <tref>frame</tref>:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context": {
-    "Book":         "http://example.org/vocab#Book",
-    "Chapter":      "http://example.org/vocab#Chapter",
-    "contains":     "http://example.org/vocab#contains",
-    "creator":      "http://purl.org/dc/terms/creator"
-    "description":  "http://purl.org/dc/terms/description"
-    "Library":      "http://example.org/vocab#Library",
-    "title":        "http://purl.org/dc/terms/title"
-  },
-  "@type": "Library",
-  "contains": {
-    "@type": "Book",
-    "contains": {
-      "@type": "Chapter"
-    }
-  }
-}
--->
-</pre>
-
-<p>When the framing algorithm is run against the previously defined
-JSON-LD document, paired with the <tref>frame</tref> above, the following
-JSON-LD document is the end result:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context": {
-    "Book":         "http://example.org/vocab#Book",
-    "Chapter":      "http://example.org/vocab#Chapter",
-    "contains":     "http://example.org/vocab#contains",
-    "creator":      "http://purl.org/dc/terms/creator"
-    "description":  "http://purl.org/dc/terms/description"
-    "Library":      "http://example.org/vocab#Library",
-    "title":        "http://purl.org/dc/terms/title"
-  },
-  "@subject": "http://example.org/library",
-  "@type": "Library",
-  "contains": {
-    ****"@subject": "http://example.org/library/the-republic",****
-    "@type": "Book",
-    ****"creator": "Plato",****
-    ****"title": "The Republic",****
-    "contains": {
-      ****"@subject": "http://example.org/library/the-republic#introduction",****
-      "@type": "Chapter",
-      ****"description": "An introductory chapter on The Republic.",****
-      ****"title": "The Introduction"****
-    },
-  },
-}
--->
-</pre>
-
-<p>The JSON-LD framing algorithm allows developers to query by example and
-force a specific tree layout to a JSON-LD document.
-</p>
-
-</section>
-
-</section>
-
-<section>
-<h1>Advanced Concepts</h1>
-
-<p>JSON-LD has a number of features that provide functionality above and beyond
-the core functionality described above. The following sections outline the
-features that are specific to JSON-LD.
-</p>
-
-<section>
-  <h2>Vocabulary Prefixes</h2>
-  <p>
-    Vocabulary terms in Linked Data documents may draw from a number of
-    different Web vocabularies. At times, declaring every single term that
-    a document uses can require the developer to declare tens, if not
-    hundreds of potential vocabulary terms that may be used across an
-    application. This is a concern for at least three reasons; the
-    first is the cognitive load on the developer, the second is
-    the serialized size of the context, the third is future-proofing
-    application contexts. In order to address these issues, the concept of a
-    <tref>prefix</tref> mechanism is introduced.</p>
-  <p>
-    A <tdef>prefix</tdef> is a compact way of expressing a base
-    <tref>IRI</tref> to a <tref>Web Vocabulary</tref>.
-    Generally, these prefixes are used by concatenating the <em>prefix</em> and
-    a <em>term</em> separated by a colon (<code>:</code>).
-    The prefix is a short string that identifies a particular Web vocabulary.
-    For example, the prefix <code>foaf</code> may be used as a short
-    hand for the Friend-of-a-Friend Web Vocabulary, which is identified using
-    the IRI <code>http://xmlns.com/foaf/0.1/</code>. A developer may append any of
-    the FOAF Vocabulary terms to the end of the prefix to specify a short-hand
-    version of the full IRI 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>
-    The ability to use <tref>prefix</tref>es reduces the need for developers
-    to declare every vocabulary term that they intend to use in
-    the JSON-LD context. This reduces document serialization size because
-    every vocabulary term need not be declared in the context.
-    <tref>Prefix</tref> also
-    reduce the cognitive load on the developer. It is far easier to
-    remember <code>foaf:name</code> than it is to remember
-    <code>http://xmlns.com/foaf/0.1/name</code>. The use of prefixes also
-    ensures that a context document does not have to be updated in lock-step
-    with an externally defined <tref>Web Vocabulary</tref>. Without prefixes, a developer
-    would need to keep their application context terms in lock-step with an
-    externally defined Web Vocabulary. Rather, by just declaring the
-    Web Vocabulary prefix, one can use new terms as they're declared
-    without having to update the application's JSON-LD context.
-  </p>
-  <p>Consider the following example:</p>
-  <pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context": {
-    ****"dc": "http://purl.org/dc/elements/1.1/",****
-    ****"ex": "http://example.org/vocab#"****
-  },
-  "@subject": "http://example.org/library",
-  "@type": ****"ex:Library"****,
-  ****"ex:contains"****: {
-    "@subject": "http://example.org/library/the-republic",
-    "@type": ****"ex:Book"****,
-    ****"dc:creator"****: "Plato",
-    ****"dc:title"****: "The Republic",
-    ****"ex:contains"****: {
-      "@subject": "http://example.org/library/the-republic#introduction",
-      "@type": ****"ex:Chapter"****,
-      ****"dc:description"****: "An introductory chapter on The Republic.",
-      ****"dc:title"****: "The Introduction"
-    },
-  },
-}
--->
-  </pre>
-  <p>
-    In this example, two different vocabularies are referred to using
-    prefixes. Those prefixes are then used as type and property values using
-    the <code>prefix:term</code> notation.
-  </p>
-  <p>
-    Prefixes, also known as CURIEs, are defined more formally in RDFa Core 1.1,
-    <cite><a href="http://www.w3.org/TR/rdfa-core/#s_curies">Section 6
-    &quot;CURIE Syntax Definition&quot;</a></cite> [[RDFA-CORE]].
-    JSON-LD does not support the square-bracketed CURIE syntax as the
-    mechanism is not required to disambiguate IRIs in a JSON-LD document like
-    it is in HTML documents.
-  </p>
-</section>
-
-<section>
-<h2>Automatic Typing</h2>
-
-<p>Since JSON is capable of expressing typed information such as doubles,
-integers, and boolean values. As demonstrated below, JSON-LD utilizes that
-information to create <tref>typed literal</tref>s:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  // The following two values are automatically converted to a type of xsd:double
-  // and both values are equivalent to each other.
-  "measure:cups": ****5.3****,
-  "measure:cups": ****5.3e0****,
-  // The following value is automatically converted to a type of xsd:double as well
-  "space:astronomicUnits": ****6.5e73****,
-  // The following value should never be converted to a language-native type
-  "measure:stones": ****{ "@literal": "4.8", "@datatype": "xsd:decimal" }****,
-  // This value is automatically converted to having a type of xsd:integer
-  "chem:protons": ****12****,
-  // This value is automatically converted to having a type of xsd:boolean
-  "sensor:active": ****true****,
-...
-}
--->
-</pre>
-
-<p class="note">When dealing with a number of modern programming languages,
-including JavaScript ECMA-262, there is no distinction between
-<strong>xsd:decimal</strong> and <strong>xsd:double</strong> values. That is,
-the <tref>number</tref> <code>5.3</code> and the <tref>number</tref>
-<code>5.3e0</code> are treated as if they were the same. When converting from
-JSON-LD to a language-native format and back, datatype information is lost in a
-number of these languages. Thus, one could say that <code>5.3</code> is a
-<strong>xsd:decimal</strong> and <code>5.3e0</code> is an
-<strong>xsd:double</strong> in JSON-LD, but when both values are
-converted to a language-native format the datatype difference between the two
-is lost because the machine-level representation will almost always be a
-<strong>double</strong>.
-Implementers should be aware of this potential round-tripping issue between
-<strong>xsd:decimal</strong> and <strong>xsd:double</strong>. Specifically
-objects with a datatype of <strong>xsd:decimal</strong> MUST NOT be converted
-to a language native type.
-</p>
-
-</section>
-
-<section>
-<h2>Type Coercion</h2>
-
-<p>JSON-LD supports the coercion of values to particular data types.
-Type coercion allows someone deploying JSON-LD to coerce the incoming or
-outgoing types to the proper data type based on a mapping of data type IRIs to
-property types. Using type coercion, one may convert simple JSON data to
-properly typed RDF data.</p>
-
-<p>The example below demonstrates how a JSON-LD author can coerce values to
-<tref>plain literal</tref>s, <tref>typed literal</tref>s and IRIs.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context":
-  {
-     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
-     "xsd": "http://www.w3.org/2001/XMLSchema#",
-     "name": "http://xmlns.com/foaf/0.1/name",
-     "age": "http://xmlns.com/foaf/0.1/age",
-     "homepage": "http://xmlns.com/foaf/0.1/homepage",
-****     "@coerce":
-     {
-        "xsd:integer": "age",
-        "@iri": "homepage"
-     }****
-  },
-  "name": "John Smith",
-  "age": ****"41"****,
-  "homepage": ****"http://example.org/home/"****
-}
--->
-</pre>
-
-<p>The example above would generate the following triples:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-_:bnode1
-   <http://xmlns.com/foaf/0.1/name>
-      "John Smith" .
-_:bnode1
-   <http://xmlns.com/foaf/0.1/age>
-      "41"^^http://www.w3.org/2001/XMLSchema#integer .
-_:bnode1
-   <http://xmlns.com/foaf/0.1/homepage>
-      <http://example.org/home/> .
--->
-</pre>
-
-</section>
-
-<section>
-  <h2>Chaining</h2>
-  <p>
-    Object <tdef>chaining</tdef> is a JSON-LD feature that allows an author to
-    use the definition of JSON-LD objects as <tref>property</tref> values. This
-    is a commonly used mechanism for creating a parent-child relationship
-    between two <tref>subject</tref>s.
-  </p>
-  <p>The example shows an two subjects related by a property from the first
-  subject:</p>
-
-  <pre class="example" data-transform="updateExample">
-  <!--
-  {
-  ...
-    "name": "Manu Sporny",
-    "****knows****": {
-      "****@type****": "****Person****",
-      "****name****": "****Gregg Kellogg****",
-    }
-  ...
-  }
-  -->
-  </pre>
-
-  <p>
-    An object definition, like the one used above, MAY be used as a
-    JSON value at any point in JSON-LD.
-  </p>
-</section>
-
-<section>
-<h2>Identifying Unlabeled Nodes</h2>
-
-<p>At times, it becomes necessary to be able to express information without
-being able to specify the subject. Typically, this type of node is called
-an unlabeled node or a blank node. In JSON-LD, unlabeled node identifiers are
-automatically created if a subject is not specified using the
-<code>@subject</code> keyword. However, authors may provide identifiers for
-unlabeled nodes by using the special <code>_</code> (underscore)
-<tref>prefix</tref>. This allows to reference the node locally within the
-document but not in an external document.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  "@subject": "****_:foo****",
-...
-}
- -->
-</pre>
-
-<p>The example above would set the subject to <code>_:foo</code>, which can
-then be used later on in the JSON-LD markup to refer back to the
-unlabeled node. This practice, however, is usually frowned upon when
-generating Linked Data. If a developer finds that they refer to the unlabeled
-node more than once, they should consider naming the node using a resolve-able
-IRI.
-</p>
-
-</section>
-
-<section>
-<h2>Aliasing Keywords</h2>
-
-<p>JSON-LD allows all of the syntax keywords, except for <code>@context</code>,
-to be aliased. This feature allows more legacy JSON content to be supported
-by JSON-LD. It also allows developers to design domain-specific implementations
-using only the JSON-LD context.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context":
-  {
-     ****"url": "@subject"****,
-     ****"a": "@type"****,
-     "name": "http://schema.org/name"
-  },
-  "url": "http://example.com/about#gregg",
-  "a": "http://schema.org/Person",
-  "name": "Gregg Kellogg"
-}
--->
-</pre>
-
-<p>In the example above, the <code>@subject</code> and <code>@type</code>
-keywords have been given the aliases <strong>url</strong> and
-<strong>a</strong>, respectively.
-</p>
-
-</section>
-
-<section>
-<h2>Normalization</h2>
-
-<p>Normalization is the process of taking <tref>JSON-LD input</tref> and
-performing a deterministic transformation on that input that results in a
-<tref>JSON-LD output</tref> that any conforming JSON-LD processor would have
-generated given the same input. The problem is a fairly difficult technical
-problem to solve because it requires a directed graph to be ordered into a
-set of nodes and edges in a deterministic way. This is easy to do when all of
-the nodes have unique names, but very difficult to do when some of the nodes
-are not labeled.
-</p>
-
-<p>Normalization is useful when comparing two graphs against one another,
-when generating a detailed list of differences between two graphs, and
-when generating a cryptographic digital signature for information contained
-in a graph or when generating a hash of the information contained in a graph.
-</p>
-
-<p>The example below is an un-normalized JSON-LD document:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-   "@context":
-   {
-      "name": "http://xmlns.com/foaf/0.1/name",
-      "homepage": "http://xmlns.com/foaf/0.1/homepage",
-      "xsd": "http://www.w3.org/2001/XMLSchema#",
-      "@coerce":
-      {
-         "@iri": ["homepage"]
-      }
-   },
-   "name": "Manu Sporny",
-   "homepage": "http://manu.sporny.org/"
-}
--->
-</pre>
-
-<p>The example below is the normalized form of the JSON-LD document above:</p>
-
-<p class="note">Whitespace is used below to aid readability. The normalization
-algorithm for JSON-LD removes all unnecessary whitespace in the fully
-normalized form.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-[{
-    "@subject":
-    {
-        "@iri": "_:c14n0"
-    },
-    "http://xmlns.com/foaf/0.1/homepage":
-    {
-        "@iri": "http://manu.sporny.org/"
-    },
-    "http://xmlns.com/foaf/0.1/name": "Manu Sporny"
-}]
--->
-</pre>
-
-<p>Notice how all of the <tref>term</tref>s have been expanded and sorted in
-alphabetical order. Also, notice how the <tref>subject</tref> has been
-labeled with a <tref>blank node identifier</tref>. Normalization ensures that any arbitrary
-graph containing exactly the same information would be normalized to exactly
-the same form shown above.</p>
-
-</section>
-
-</section>
-
-<section>
-<h2>The Application Programming Interface</h2>
-
-<p>This API provides a clean mechanism that enables developers to convert
-JSON-LD data into a a variety of output formats that are easier to work with in
-various programming languages. If a JSON-LD API is provided in a programming
-environment, the entirety of the following API MUST be implemented.
-</p>
-
-<section>
-<h3>JsonLdProcessor</h3>
-<dl title="[NoInterfaceObject] interface JsonLdProcessor" class="idl">
-
-  <dt>object expand()</dt>
-  <dd><a href="#expansion">Expands</a> the given <code>input</code>
-    according to the steps in the
-    <a href="#expansion-algorithm">Expansion Algorithm</a>. The
-    <code>input</code> MUST be copied, expanded and returned if there are
-    no errors. If the expansion fails, an appropriate exception MUST be thrown.
-
-    <dl class="parameters">
-     <dt>object input</dt>
-     <dd>The JSON-LD object to copy and perform the expansion upon.</dd>
-     <dt>object optional? context</dt>
-     <dd>An external context to use additionally to the context embedded in <code>input</code> when expanding the <code>input</code>.</dd>
-    </dl>
-
-    <dl class="exception" title="InvalidContext">
-     <dt>INVALID_SYNTAX</dt>
-     <dd>A general syntax error was detected in the <code>@context</code>.
-     For example, if a <code>@coerce</code> key maps to anything other than
-     a string or an array of strings, this exception would be raised.</dd>
-     <dt>MULTIPLE_DATATYPES</dt>
-     <dd>There is more than one target datatype specified for a single
-     property in the list of coercion rules. This means that the processor
-     does not know what the developer intended for the target datatype for a
-     property.</dd>
-    </dl>
-
-  </dd>
-
-  <dt>object compact()</dt>
-  <dd><a href="#compaction">Compacts</a> the given <code>input</code>
-    according to the steps in the
-    <a href="#compaction-algorithm">Compaction Algorithm</a>. The
-    <code>input</code> MUST be copied, compacted and returned if there are
-    no errors. If the compaction fails, an appropirate exception MUST be
-    thrown.
-  <dl class="parameters">
-     <dt>object input</dt>
-     <dd>The JSON-LD object to perform compaction on.</dd>
-     <dt>object optional? context</dt>
-     <dd>The base context to use when compacting the <code>input</code>.</dd>
-  </dl>
-
-    <dl class="exception" title="InvalidContext">
-     <dt>INVALID_SYNTAX</dt>
-     <dd>A general syntax error was detected in the <code>@context</code>.
-     For example, if a <code>@coerce</code> key maps to anything other than
-     a string or an array of strings, this exception would be raised.</dd>
-     <dt>MULTIPLE_DATATYPES</dt>
-     <dd>There is more than one target datatype specified for a single
-     property in the list of coercion rules. This means that the processor
-     does not know what the developer intended for the target datatype for a
-     property.</dd>
-    </dl>
-
-    <dl class="exception" title="ProcessingError">
-     <dt>LOSSY_COMPACTION</dt>
-     <dd>The compaction would lead to a loss of information, such as a
-     <code>@language</code> value.</dd>
-     <dt>CONFLICTING_DATATYPES</dt>
-     <dd>The target datatype specified in the coercion rule and the
-     datatype for the typed literal do not match.</dd>
-    </dl>
-
-  </dd>
-
-  <dt>object frame()</dt>
-  <dd><a href="#framing">Frames</a> the given <code>input</code>
-    using the <code>frame</code> according to the steps in the
-    <a href="#framing-algorithm">Framing Algorithm</a>. The
-    <code>input</code> is used to build the framed output and is returned if
-    there are no errors. If there are no matches for the frame,
-    <code>null</code> MUST be returned. Exceptions MUST be thrown if there are
-    errors.
-  <dl class="parameters">
-     <dt>object input</dt>
-     <dd>The JSON-LD object to perform framing on.</dd>
-     <dt>object frame</dt>
-     <dd>The frame to use when re-arranging the data.</dd>
-     <dt>object options</dt>
-     <dd>A set of options that will affect the framing algorithm.</dd>
-  </dl>
-
-    <dl class="exception" title="InvalidFrame">
-    <dt>INVALID_SYNTAX</dt>
-    <dd>A frame must be either an object or an array of objects, if the frame
-    is neither of these types, this exception is thrown.</dd>
-    <dt>MULTIPLE_EMBEDS</dt>
-    <dd>A subject IRI was specified in more than one place in the input
-    frame. More than one embed of a given subject IRI is not allowed, and if
-    requested, MUST result in this exception.</dd>
-    </dl>
-
-  </dd>
-
-  <dt>object normalize()</dt>
-  <dd><a href="#normalization">Normalizes</a> the given <code>input</code>
-    according to the steps in the
-    <a href="#normalization-algorithm">Normalization Algorithm</a>. The
-    <code>input</code> MUST be copied, normalized and returned if there are
-    no errors. If the compaction fails, <code>null</code> MUST be returned.
-  <dl class="parameters">
-     <dt>object input</dt>
-     <dd>The JSON-LD object to perform normalization upon.</dd>
-     <dt>object optional? context</dt>
-     <dd>An external context to use additionally to the context embedded in <code>input</code> when expanding the <code>input</code>.</dd>
-  </dl>
-
-    <dl class="exception" title="InvalidContext">
-     <dt>INVALID_SYNTAX</dt>
-     <dd>A general syntax error was detected in the <code>@context</code>.
-     For example, if a <code>@coerce</code> key maps to anything other than
-     a string or an array of strings, this exception would be raised.</dd>
-     <dt>MULTIPLE_DATATYPES</dt>
-     <dd>There is more than one target datatype specified for a single
-     property in the list of coercion rules. This means that the processor
-     does not know what the developer intended for the target datatype for a
-     property.</dd>
-    </dl>
-
-  </dd>
-
-  <dt>object triples()</dt>
-  <dd>Processes the <code>input</code> according to the
-    <a href="#rdf-conversion-algorithm">RDF Conversion Algorithm</a>, calling
-    the provided <code>tripleCallback</code> for each triple generated.
-  <dl class="parameters">
-     <dt>object input</dt>
-     <dd>The JSON-LD object to process when outputting triples.</dd>
-     <dt>JsonLdTripleCallback tripleCallback</dt>
-     <dd>A callback that is called whenever a processing error occurs on
-     the given <code>input</code>.
-     <div class="issue">This callback should be aligned with the
-       RDF API.</div></dd>
-     <dt>object optional? context</dt>
-     <dd>An external context to use additionally to the context embedded in <code>input</code> when expanding the <code>input</code>.</dd>
-  </dl>
-
-    <dl class="exception" title="InvalidContext">
-     <dt>INVALID_SYNTAX</dt>
-     <dd>A general syntax error was detected in the <code>@context</code>.
-     For example, if a <code>@coerce</code> key maps to anything other than
-     a string or an array of strings, this exception would be raised.</dd>
-     <dt>MULTIPLE_DATATYPES</dt>
-     <dd>There is more than one target datatype specified for a single
-     property in the list of coercion rules. This means that the processor
-     does not know what the developer intended for the target datatype for a
-     property.</dd>
-    </dl>
-
-  </dd>
-
-</dl>
-
-</section>
-
-<section>
-<h3>JsonLdTripleCallback</h3>
-<p>The JsonLdTripleCallback is called whenever the processor generates a
-triple during the <code>triple()</code> call.</p>
-
-<dl title="[NoInterfaceObject Callback] interface JsonLdTripleCallback"
-    class="idl">
-
-  <dt>void triple()</dt>
-  <dd>This callback is invoked whenever a triple is generated by the processor.
-  <dl class="parameters">
-     <dt>DOMString subject</dt>
-     <dd>The subject IRI that is associated with the triple.</dd>
-     <dt>DOMString property</dt>
-     <dd>The property IRI that is associated with the triple.</dd>
-     <dt>DOMString objectType</dt>
-     <dd>The type of object that is associated with the triple. Valid values
-       are <code>IRI</code> and <code>literal</code>.</dd>
-     <dt>DOMString object</dt>
-     <dd>The object value associated with the subject and the property.</dd>
-     <dt>DOMString? datatype</dt>
-     <dd>The datatype associated with the object.</dd>
-     <dt>DOMString? language</dt>
-     <dd>The language associated with the object in BCP47 format.</dd>
-  </dl>
-  </dd>
-</dl>
-</section>
-
-
-</section>
-
-<section>
-<h1>Algorithms</h1>
-
-<p>All algorithms described in this section are intended to operate on
-language-native data structures. That is, the serialization to a text-based
-JSON document isn't required as input or output to any of these algorithms and
-language-native data structures MUST be used where applicable.</p>
-
-<section>
-  <h2>Syntax Tokens and Keywords</h2>
-
-  <p>JSON-LD specifies a number of syntax tokens and keywords that are using
-  in all algorithms described in this section:</p>
-
-  <dl>
-  <dt><code>@context</code></dt><dd>Used to set the <tref>local context</tref>.</dd>
-  <dt><code>@base</code></dt><dd>Used to set the base IRI for all object IRIs affected  by the <tref>active context</tref>.</dd>
-  <dt><code>@vocab</code></dt><dd>Used to set the base IRI for all property IRIs affected by the <tref>active context</tref>.</dd>
-  <dt><code>@coerce</code></dt><dd>Used to specify type coercion rules.</dd>
-  <dt><code>@literal</code></dt><dd>Used to specify a literal value.</dd>
-  <dt><code>@iri</code></dt><dd>Used to specify an IRI value.</dd>
-  <dt><code>@language</code></dt><dd>Used to specify the language for a literal.</dd>
-  <dt><code>@datatype</code></dt><dd>Used to specify the datatype for a literal.</dd>
-  <dt><code>:</code></dt><dd>The separator for JSON keys and values that use the <tref>prefix</tref> mechanism.</dd>
-  <dt><code>@subject</code></dt><dd>Sets the active subject.</dd>
-  <dt><code>@type</code></dt><dd>Used to set the type of the active subject.</dd>
-  </dl>
-</section>
-
-<section>
-  <h2>Algorithm Terms</h2>
-  <dl>
-    <dt><tdef>initial context</tdef></dt>
-    <dd>
-      a context that is specified to the algorithm before processing begins.
-    </dd>
-    <dt><tdef>active subject</tdef></dt>
-    <dd>
-      the currently active subject that the processor should use when
-      processing.
-    </dd>
-    <dt><tdef>active property</tdef></dt>
-    <dd>
-      the currently active property that the processor should use when
-      processing.
-    </dd>
-    <dt><tdef>active object</tdef></dt>
-    <dd>
-      the currently active object that the processor should use when
-      processing.
-    </dd>
-    <dt><tdef>active context</tdef></dt>
-    <dd>
-      a context that is used to resolve <tref>prefix</tref>es and
-      <tref>term</tref>s while the processing
-      algorithm is running. The <tref>active context</tref> is the context
-      contained within the <tref>processor state</tref>.
-    </dd>
-    <dt><tdef>local context</tdef></dt>
-    <dd>
-      a context that is specified within a <tref>JSON object</tref>,
-      specified via the <code>@context</code> keyword.
-    </dd>
-    <dt><tdef>processor state</tdef></dt>
-    <dd>
-      the <tref>processor state</tref>, which includes the <tref>active
-      context</tref>, <tref>current subject</tref>, and
-      <tref>current property</tref>. The <tref>processor state</tref> is managed
-      as a stack with elements from the previous <tref>processor state</tref>
-      copied into a new <tref>processor state</tref> when entering a new
-      <tref>JSON object</tref>.
-    </dd>
-    <dt><tdef>JSON-LD input</tdef></dt>
-    <dd>
-      The JSON-LD data structure that is provided as input to the algorithm.
-    </dd>
-    <dt><tdef>JSON-LD output</tdef></dt>
-    <dd>
-      The JSON-LD data structure that is produced as output by the algorithm.
-    </dd>
-
-  </dl>
-</section>
-
-<section>
-  <h2 id="context">Context</h2>
-  <p>
-    Processing of JSON-LD data structure is managed recursively.
-    During processing, each rule is applied using information provided by the <tref>active context</tref>.
-    Processing begins by pushing a new <tref>processor state</tref> onto the <tref>processor state</tref> stack and
-    initializing the <tref>active context</tref> with the <tref>initial context</tref>. If a <tref>local context</tref> is encountered,
-    information from the <tref>local context</tref> is merged into the <tref>active context</tref>.
-  </p>
-  <p>
-    The <tref>active context</tref> is used for expanding keys and values of a <tref>JSON object</tref> (or elements
-    of a list (see <span a="#list-processing">List Processing</span>)).
-  </p>
-  <p>
-    A <tref>local context</tref> is identified within a <tref>JSON object</tref> having a key of
-    <code>@context</code> with <tref>string</tref> or a <tref>JSON object</tref> value. When processing a <tref>local
-    context</tref>, special processing rules apply:
-  </p>
-  <ol class="algorithm">
-    <li>Create a new, empty <tref>local context</tref>.</li>
-    <li>
-      If the value is a simple <tref>string</tref>, it MUST have a lexical form of IRI and used to initialize
-      a new JSON document which replaces the value for subsequent processing.
-    </li>
-    <li>If the value is a <tref>JSON object</tref>, perform the following steps:
-      <ol class="algorithm">
-        <li>
-          If the <tref>JSON object</tref> has a <code>@base</code> key, it MUST have a value of a simple
-          <tref>string</tref> with the lexical form of an absolute IRI. Add the base mapping to the <tref>local
-          context</tref>. <p class="issue">Turtle allows @base to be relative. If we did this, we
-          would have to add <a href="#iri-expansion">IRI Expansion</a>.</p>
-        </li>
-        <li>
-          If the <tref>JSON object</tref> has a <code>@vocab</code> key, it MUST have a value of a simple
-          <tref>string</tref> with the lexical form of an absolute IRI. Add the vocabulary mapping to the
-          <tref>local context</tref> after performing <a href="#iri-expansion">IRI Expansion</a> on
-          the associated value.
-        </li>
-        <li>
-          If the <tref>JSON object</tref> has a <code>@coerce</code> key, it MUST have a value of a
-          <tref>JSON object</tref>. Add the <code>@coerce</code> mapping to the <tref>local context</tref>
-          performing <a href="#iri-expansion">IRI Expansion</a> on the associated value(s).
-        </li>
-        <li>
-          Otherwise, the key MUST have the lexical form of <cite><a
-          href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NCName</a></cite> and
-          MUST have the value of a simple <tref>string</tref> with the lexical form of IRI. Merge the key-value
-          pair into the <tref>local context</tref>.
-        </li>
-      </ol>
-    </li>
-    <li>
-      Merge the of <tref>local context</tref>'s <code>@coerce</code> mapping into  the
-      <tref>active context</tref>'s <code>@coerce</code> mapping as described <a href="#coerce">below</a>.
-    </li>
-    <li>
-      Merge all entries other than the <code>@coerce</code> mapping from the <tref>local context</tref> to the
-      <tref>active context</tref> overwriting any duplicate values.
-    </li>
-  </ol>
-
-  <section>
-    <h3>Coerce</h3>
-    <p>
-      Map each key-value pair in the <tref>local context</tref>'s
-      <code>@coerce</code> mapping into the <tref>active context</tref>'s
-      <code>@coerce</code> mapping, overwriting any duplicate values in
-      the <tref>active context</tref>'s <code>@coerce</code> mapping.
-      The <code>@coerce</code> mapping has either a single
-      <code>prefix:term</code> value, a single <tref>term</tref> value or an
-      <tref>array</tref> of <code>prefix:term</code> or <tref>term</tref> values.
-      When merging with an existing mapping in the <tref>active context</tref>,
-      map all <tref>prefix</tref> and <tref>term</tref> values to
-      <tref>array</tref> form and replace with the union of the value from
-      the <tref>local context</tref> and the value of the
-      <tref>active context</tref>. If the result is an <tref>array</tref>
-      with a single value, the processor MAY represent this as a string value.
-    </p>
-  </section>
-
-  <section>
-    <h3>Initial Context</h3>
-    <p>The <tref>initial context</tref> is initialized as follows:</p>
-    <ul>
-      <li>
-        <code>@base</code> is set using <cite><href="http://www.ietf.org/rfc/rfc2396.txt">section 5.1 Establishing a
-        Base URI</href="http://www.ietf.org/rfc/rfc2396.txt"></cite> of [[RFC3986]]. Processors MAY provide a means
-        of setting the base IRI programatically.
-      </li>
-      <li><code>@coerce</code> is set with a single mapping from <code>@iri</code> to <code>@type</code>.</li>
-    </ul>
-    <pre class="example" data-transform="updateExample">
-    <!--
-    {
-        "@base": ****document-location****,
-        "@coerce": {
-          "@iri": "@type"
-        }
-    }
-    -->
-    </pre>
-  </section>
-</section>
-
-<section>
-  <h2>IRI Expansion</h2>
-  <p>Keys and some values are evaluated to produce an IRI. This section defines an algorithm for
-    transforming a value representing an IRI into an actual IRI.</p>
-  <p>IRIs may be represented as an absolute IRI, a <tref>term</tref>, a <tref>prefix</tref>:<tref>term</tref> construct, or as a value relative to <code>@base</code>
-    or <code>@vocab</code>.</p>
-  <p>The algorithm for generating an IRI is:
-    <ol class="algorithm">
-      <li>Split the value into a <em>prefix</em> and <em>suffix</em> from the first occurrence of ':'.</li>
-      <li>If the prefix is a '_' (underscore), the IRI is unchanged.</li>
-      <li>If the <tref>active context</tref> contains a mapping for <em>prefix</em>, generate an IRI
-        by prepending the mapped prefix to the (possibly empty) suffix using textual concatenation. Note that an empty
-        suffix and no suffix (meaning the value contains no ':' string at all) are treated equivalently.</li>
-      <li>If the IRI being processed is for a property (i.e., a key's value in a <tref>JSON object</tref>, or a
-        value in a <code>@coerce</code> mapping) and the active context has a <code>@vocab</code> mapping,
-        join the mapped value to the suffix using textual concatenation.</li>
-      <li>If the IRI being processed is for a subject or object (i.e., not a property) and the active context has a <code>@base</code> mapping,
-        join the mapped value to the suffix using the method described in [[!RFC3986]].</li>
-      <li>Otherwise, use the value directly as an IRI.</li>
-    </ol>
-  </p>
-</section>
-
-<section>
-  <h2>IRI Compaction</h2>
-  <p>Some keys and values are expressed using IRIs. This section defines an
-    algorithm for transforming an IRI to a compact IRI using the
-    <tref>term</tref>s and <tref>prefix</tref>es specified in the
-    <tref>local context</tref>.</p>
-
-  <p>The algorithm for generating a compacted IRI is:
-    <ol class="algorithm">
-      <li>Search every key-value pair in the <tref>active context</tref> for
-        a <tref>term</tref> that is a complete match
-        against the IRI. If a complete match is found, the resulting compacted
-        IRI is the <tref>term</tref> associated with the IRI in the
-        <tref>active context</tref>.</li>
-      <li>If a complete match is not found, search for a partial match from
-        the beginning of the IRI. For all matches that are found, the resulting
-        compacted IRI is the <tref>prefix</tref> associated with the partially
-        matched IRI in the <tref>active context</tref> concatenated with a
-        colon (:) character and the unmatched part of the string. If there is
-        more than one compacted IRI produced, the final value is the
-        shortest and lexicographically least value of the entire set of compacted IRIs.</li>
-    </ol>
-  </p>
-</section>
-
-<section>
-  <h2>Value Expansion</h2>
-  <p>Some values in JSON-LD can be expressed in a compact form. These values
-    are required to be expanded at times when processing JSON-LD documents.
-  </p>
-
-  <p>The algorithm for expanding a value is:
-    <ol class="algorithm">
-      <li>If the key that is associated with the value has an associated
-        coercion entry in the <tref>local context</tref>, the resulting
-        expansion is an object populated according to the following steps:
-        <ol class="algorithm">
-          <li>If the coercion target is <code>@iri</code>, expand the value
-            by adding a new key-value pair where the key is <code>@iri</code>
-            and the value is the expanded IRI according to the
-            <a href="#iri-expansion">IRI Expansion</a> rules.</li>
-          <li>If the coercion target is a typed literal, expand the value
-            by adding two new key-value pairs. The first key-value pair
-            will be <code>@literal</code> and the unexpanded value. The second
-            key-value pair will be <code>@datatype</code> and the associated
-            coercion datatype expanded according to the
-            <a href="#iri-expansion">IRI Expansion</a> rules.</li>
-        </ol>
-      </li>
-    </ol>
-  </p>
-</section>
-
-<section>
-  <h2>Value Compaction</h2>
-  <p>Some values, such as IRIs and typed literals, may be expressed in an
-    expanded form in JSON-LD. These values are required to be compacted at
-    times when processing JSON-LD documents.
-  </p>
-
-  <p>The algorithm for compacting a value is:
-    <ol class="algorithm">
-      <li>If the <tref>local context</tref> contains a coercion target for the
-        key that is associated with the value, compact the value using the
-        following steps:
-        <ol class="algorithm">
-          <li>If the coercion target is an <code>@iri</code>, the compacted
-            value is the value associated with the <code>@iri</code> key,
-            processed according to the
-            <a href="#iri-compaction">IRI Compaction</a> steps.</li>
-          <li>If the coercion target is a typed literal, the compacted
-            value is the value associated with the <code>@literal</code> key.
-          </li>
-          <li>Otherwise, the value is not modified.</li>
-        </ol>
-      </li>
-    </ol>
-  </p>
-</section>
-
-<section>
-<h2>Expansion</h2>
-
-<p class="issue">This algorithm is a work in progress, do not implement it.</p>
-
-<p>As stated previously, expansion is the process of taking a JSON-LD
-input and expanding all IRIs and typed literals to their fully-expanded form.
-The output will not contain a single context declaration and will have all IRIs
-and typed literals fully expanded.
-</p>
-
-<section>
-<h3>Expansion Algorithm</h3>
-
-<ol class="algorithm">
-  <li>If the top-level item in the <tref>JSON-LD input</tref> is an <tref>array</tref>,
-  process each item in the <tref>array</tref> recursively using this algorithm.</li>
-  <li>If the top-level item in the <tref>JSON-LD input</tref> is an object,
-  update the <tref>local context</tref> according to the steps outlined in
-  the <a href="#context">context</a> section. Process each key, expanding
-  the key according to the <a href="#iri-expansion">IRI Expansion</a> rules.</li>
-  <ol class="algorithm">
-    <li>Process each value associated with each key:
-      <ol class="algorithm">
-        <li>If the value is an <tref>array</tref>, process each item in the <tref>array</tref>
-        recursively using this algorithm.</li>
-        <li>If the value is an object, process the object recursively
-        using this algorithm.</li>
-        <li>Otherwise, check to see the associated key has an associated
-        coercion rule. If the value should be coerced, expand the value
-        according to the <a href="#value-expansion">Value Expansion</a> rules.
-        If the value does not need to be coerced, leave the value as-is.
-        </li>
-      </ol>
-    <li>Remove the context from the object.</li>
-  </ol>
-</ol>
-</section>
-
-</section>
-
-<section>
-<h2>Compaction</h2>
-
-<p class="issue">This algorithm is a work in progress, do not implement it.</p>
-
-<p>As stated previously, compaction is the process of taking a JSON-LD
-input and compacting all IRIs using a given context. The output
-will contain a single top-level context declaration and will only use
-<tref>term</tref>s and <tref>prefix</tref>es and will ensure that all
-typed literals are fully compacted.
-</p>
-
-<section>
-<h3>Compaction Algorithm</h3>
-
-<ol class="algorithm">
-  <li>Perform the <a href="#expansion-algorithm">Expansion Algorithm</a> on
-  the <tref>JSON-LD input</tref>. This removes any existing context to allow the given context to be cleanly applied.</li>
-  <li>Set the <tref>active context</tref> to the given context.
-  <li>If the top-level item is an <tref>array</tref>, process each item in the <tref>array</tref>
-    recursively, starting at this step.
-  <li>If the top-level item is an object, compress each key using the steps
-    defined in <a href="#iri-compaction">IRI Compaction</a> and compress each
-    value using the steps defined in
-    <a href="#value-compaction">Value Compaction</a>.</li>
-  </li>
-</ol>
-</section>
-
-</section>
-
-
-<section>
-<h2>Framing</h2>
-
-<p class="issue">This algorithm is a work in progress, do not implement it.</p>
-
-<p>A JSON-LD document is a representation of a directed graph. A single
-directed graph can have many different serializations, each expressing
-exactly the same information. Developers typically don't work directly with
-graphs, but rather, prefer trees when dealing with JSON. While mapping a graph
-to a tree can be done, the layout of the end result must be specified in
-advance. This section defines an algorithm for mapping a graph to
-a tree given a <tref>frame</tref>.
-</p>
-
-<section>
-<h3>Framing Algorithm Terms</h3>
- <dl>
-   <dt><tdef>input frame</tdef></dt>
-   <dd>
-     the initial <tref>frame</tref> provided to the framing algorithm.
-   </dd>
-   <dt><tdef>framing context</tdef></dt>
-   <dd>
-     a context containing the <tref>object embed flag</tref>, the
-     <tref>explicit inclusion flag</tref> and the
-     <tref>omit default flag</tref>.
-   </dd>
-   <dt><tdef>object embed flag</tdef></dt>
-   <dd>
-     a flag specifying that objects should be directly embedded in the output,
-     instead of being referred to by their IRI.
-   </dd>
-   <dt><tdef>explicit inclusion flag</tdef></dt>
-   <dd>
-     a flag specifying that for properties to be included in the output, they
-     must be explicitly declared in the <tref>framing context</tref>.
-   </dd>
-   <dt><tdef>omit missing properties flag</tdef></dt>
-   <dd>
-     a flag specifying that properties that are missing from the
-     <tref>JSON-LD input</tref> should be omitted from the output.
-   </dd>
-   <dt><tdef>match limit</tdef></dt>
-   <dd>
-     A value specifying the maximum number of matches to accept when building
-     arrays of values during the framing algorithm. A value of -1 specifies
-     that there is no match limit.
-   </dd>
-   <dt><tdef>map of embedded subjects</tdef></dt>
-   <dd>
-     A map that tracks if a subject has been embedded in the output of the
-     <a href="#framing-algorithm">Framing Algorithm</a>.
-   </dd>
- </dl>
-</section>
-
-<section>
-<h3>Framing Algorithm</h3>
-
-<p>The framing algorithm takes <tref>JSON-LD input</tref> that has been
-normalized according to the
-<a href="#normalization-algorithm">Normalization Algorithm</a>
-(<strong>normalized input</strong>), an
-<tref>input frame</tref> that has been expanded according to the
-<a href="#expansion-algorithm">Expansion Algorithm</a>
-(<strong>expanded frame</strong>), and a number of options and produces
-<tref>JSON-LD output</tref>. The following series of steps is the recursive
-portion of the framing algorithm:
-</p>
-
-<ol class="algorithm">
-  <li>Initialize the <tref>framing context</tref> by setting the
-   <tref>object embed flag</tref>, clearing the
-   <tref>explicit inclusion flag</tref>, and clearing the
-   <tref>omit missing properties flag</tref>. Override these values
-   based on input options provided to the algorithm by the application.
-  </li>
-  <li>Generate a <tdef>list of frames</tdef> by processing the
-    <strong>expanded frame</strong>:
-    <ol class="algorithm">
-      <li>If the <strong>expanded frame</strong> is not an <tref>array</tref>, set
-        <tref>match limit</tref> to 1, place the
-        <strong>expanded frame</strong> into the <tref>list of frames</tref>,
-        and set the <tref>JSON-LD output</tref> to <code>null</code>.</li>
-      <li>If the <strong>expanded frame</strong> is an empty <tref>array</tref>, place an
-        empty object into the <tref>list of frames</tref>,
-        set the <tref>JSON-LD output</tref> to an <tref>array</tref>, and set
-        <tref>match limit</tref> to -1.</li>
-      <li>If the <strong>expanded frame</strong> is a non-empty <tref>array</tref>, add
-        each item in the <strong>expanded frame</strong> into the
-        <tref>list of frames</tref>, set the <tref>JSON-LD output</tref> to an
-        <tref>array</tref>, and set <tref>match limit</tref> to -1.</li>
-    </ol></li>
-  <li>Create a <tdef>match array</tdef> for each <strong>expanded frame</strong>
-    in the <tref>list of frames</tref> halting when either the
-    <tref>match limit</tref> is zero or the end of the
-    <tref>list of frames</tref> is reached. If an
-    <strong>expanded frame</strong> is
-    not an object, the processor MUST throw a <code>Invalid Frame Format</code>
-    exception. Add each matching item from the <strong>normalized input</strong>
-    to the <tref>matches array</tref> and decrement the
-    <tref>match limit</tref> by 1 if:
-    <ol class="algorithm">
-       <li>The <strong>expanded frame</strong> has an <code>rdf:type</code>
-         that exists in the item's list of <code>rdf:type</code>s. Note:
-         the <code>rdf:type</code> can be an <tref>array</tref>, but only one value needs
-         to be in common between the item and the
-         <strong>expanded frame</strong> for a match.</li>
-       <li>The <strong>expanded frame</strong> does not have an
-         <code>rdf:type</code> property, but every property in the
-         <strong>expanded frame</strong> exists in the item.</li>
-    </ol></li>
-  <li>Process each item in the <tref>match array</tref> with its associated
-    <tdef>match frame</tdef>:
-    <ol class="algorithm">
-      <li>If the <tref>match frame</tref> contains an <code>@embed</code>
-        keyword, set the <tref>object embed flag</tref> to its value.
-        If the <tref>match frame</tref> contains an <code>@explicit</code>
-        keyword, set the <tref>explicit inclusion flag</tref> to its value.
-        Note: if the keyword exists, but the value is neither
-        <code>true</code> or <code>false</code>, set the associated flag to
-        <code>true</code>.</li>
-      <li>If the <tref>object embed flag</tref> is cleared and the item has
-        the <code>@subject</code> property, replace the item with the value
-        of the <code>@subject</code> property.</li>
-      <li>If the <tref>object embed flag</tref> is set and the item has
-        the <code>@subject</code> property, and its IRI is in the
-        <tref>map of embedded subjects</tref>, throw a
-        <code>Duplicate Embed</code> exception.</li>
-      <li>If the <tref>object embed flag</tref> is set and the item has
-        the <code>@subject</code> property and its IRI is not in the
-        <tref>map of embedded subjects</tref>:
-        <ol class="algorithm">
-          <li>If the <tref>explicit inclusion flag</tref> is set,
-            then delete any key from the item that does not exist in the
-            <tref>match frame</tref>, except <code>@subject</code>.</li>
-          <li>For each key in the <tref>match frame</tref>, except for
-            keywords and <code>rdf:type</code>:
-          <ol class="algorithm">
-            <li>If the key is in the item, then build a new
-              <tdef>recursion input list</tdef> using the object or objects
-              associated with the key. If any object contains an
-              <code>@iri</code> value that exists in the
-              <tref>normalized input</tref>, replace the object in the
-              <tref>recusion input list</tref> with a new object containing
-              the <code>@subject</code> key where the value is the value of
-              the <code>@iri</code>, and all of the other key-value pairs for
-              that subject. Set the <tdef>recursion match frame</tdef> to the
-              value associated with the <tref>match frame</tref>'s key. Replace
-              the value associated with the key by recursively calling this
-              algorithm using <tref>recursion input list</tref>,
-              <tref>recursion match frame</tref> as input.</li>
-            <li>If the key is not in the item, add the key to the item and
-              set the associated value to an empty array if the
-              <tref>match frame</tref> key's value is an array
-              or <code>null</code> otherwise.</li>
-            <li>If value associated with the item's key is <code>null</code>,
-              process the <tref>omit missing properties flag</tref>:
-              <ol class="algorithm">
-                <li>If the value associated with the key in the
-                  <tref>match frame</tref> is an array, use the first frame
-                  from the array as the <tdef>property frame</tdef>, otherwise
-                  set the <tref>property frame</tref> to an empty object.</li>
-                <li>If the <tref>property frame</tref> contains an
-                <code>@omitDefault</code> keyword, set the
-                <tref>omit missing properties flag</tref> to its value.
-                Note: if the keyword exists, but the value is neither
-                <code>true</code> or <code>false</code>, set the associated
-                flag to <code>true</code>.</li>
-                <li>If the <tref>omit missing properties flag</tref> is set,
-                  delete the key in the item. Otherwise, if the
-                  <code>@default</code> keyword is set in the
-                  <tref>property frame</tref> set the item's value to the value
-                  of <code>@default</code>.</li>
-              </ol></li>
-          </ol></li>
-        </ol>
-      <li>If the <tref>JSON-LD output</tref> is <code>null</code> set it to
-        the item, otherwise, append the item to the
-        <tref>JSON-LD output</tref>.
-    </ol>
-  <li>Return the <tref>JSON-LD output</tref>.</li>
-</ol>
-
-The final, non-recursive step of the framing algorithm requires the
-<tref>JSON-LD output</tref> to be compacted according to the
-<a href="#compaction-algorithm">Compaction Algorithm</a> by using the
-context provided in the <tref>input frame</tref>. The resulting value is the
-final output of the compaction algorithm and is what should be returned to the
-application.
-
-</section>
-
-</section>
-
-<section>
-<h2>Normalization</h2>
-
-<p class="issue">This algorithm is a work in progress, do not implement it.</p>
-
-<p>Normalization is the process of taking <tref>JSON-LD input</tref> and
-performing a deterministic transformation on that input that results in all
-aspects of the graph being fully expanded and named in the
-<tref>JSON-LD output</tref>. The normalized output is generated in such a way
-that any conforming JSON-LD processor will generate identical output
-given the same input. The problem is a fairly difficult technical
-problem to solve because it requires a directed graph to be ordered into a
-set of nodes and edges in a deterministic way. This is easy to do when all of
-the nodes have unique names, but very difficult to do when some of the nodes
-are not labeled.
-</p>
-
-<p>In time, there may be more than one normalization algorithm that will need
-to be identified. For identification purposes, this algorithm is named
-"Universal Graph Normalization Algorithm 2011"
-(<abbr title="Universal Graph Normalization Algorithm 2011">UGNA2011</abbr>).
-</p>
-
-<section>
-<h3>Normalization Algorithm Terms</h3>
- <dl>
-   <dt><tdef>label</tdef></dt>
-   <dd>
-     The subject IRI associated with a graph node. The subject IRI is expressed
-     using a key-value pair in a <tref>JSON object</tref> where the key is
-     <code>@subject</code> and the value is a string that is an IRI or
-     a <tref>JSON object</tref> containing the key <code>@iri</code> and
-     a value that is a string that is an IRI.
-   </dd>
-   <dt><tdef>list of expanded nodes</tdef></dt>
-   <dd>
-     A list of all nodes in the <tref>JSON-LD input</tref> graph containing no
-     embedded objects and having all keys and values expanded according to the
-     steps in the <a href="#expansion-algorithm">Expansion Algorithm</a>.
-   </dd>
-   <dt><tdef>alpha</tdef> and <tdef>beta</tdef> values</dt>
-   <dd>
-     The words <tref>alpha</tref> and <tref>beta</tref> refer to the first and
-     second nodes or values being examined in an algorithm. The names are
-     merely used to refer to each input value to a comparison algorithm.
-   </dd>
-   <dt><tdef>renaming counter</tdef></dt>
-   <dd>
-     A counter that is used during the
-     <a href="#node-relabeling-algorithm">Node Relabeling Algorithm</a>. The
-     counter typically starts at one (1) and counts up for every node that is
-     relabeled. There will be two such renaming counters in an implementation
-     of the normalization algorithm. The first is the
-     <tref>labeling counter</tref> and the second is the
-     <tref>deterministic labeling counter</tref>.
-   </dd>
-   <dt><tdef>serialization label</tdef></dt>
-   <dd>
-     An identifier that is created to aid in the normalization process in the
-     <a href="#deep-comparison-algorithm">Deep Comparison Algorithm</a>. The
-     value typically takes the form of <code>s&lt;NUMBER&gt;</code> or
-     <code>c&lt;NUMBER&gt;</code>.
-   </dd>
-</dl>
-</section>
-
-<section>
-<h3>Normalization State</h3>
-
-<p>When performing the steps required by the normalization algorithm,
-it is helpful to track the many pieces of information in a
-data structure called the <tdef>normalization state</tdef>. Many of these
-pieces simply provide indexes into the graph. The information
-contained in the <tref>normalization state</tref> is described below.</p>
-
-<dl>
-   <dt><tdef>node state</tdef></dt>
-   <dd>
-     Each node in the graph will be assigned a <tref>node state</tref>. This
-     state contains the information necessary to deterministically
-     <tref>label</tref> all nodes in the graph. A <tref>node state</tref>
-     includes:
-     <dl>
-        <dt><tdef>node reference</tdef></dt>
-        <dd>
-          A <tref>node reference</tref> is a reference to a node in the graph.
-          For a given <tref>node state</tref>, its <tref>node reference</tref>
-          refers to the node that the state is for. When a
-          <tref>node state</tref> is created, its <tref>node reference</tref>
-          should be to the node it is created for.
-        </dd>
-        <dt><tdef>outgoing list</tdef></dt>
-        <dd>
-          Lists the <tref>label</tref>s for all nodes that are properties of
-          the <tref>node reference</tref>. This list should be initialized
-          by iterating over every object associated with a property in the
-          <tref>node reference</tref> adding its label if it is another node.
-        </dd>
-        <dt><tdef>incoming list</tdef></dt>
-        <dd>
-          Lists the <tref>label</tref>s for all nodes in the graph for which
-          the <tref>node reference</tref> is a property. This list is
-          initialized to an empty list.
-        </dd>
-        <dt><tdef>outgoing serialization map</tdef></dt>
-        <dd>
-          Maps node <tref>label</tref>s to <tref>serialization label</tref>s.
-          This map is initialized to an empty map. When this map is populated,
-          it will be filled with keys that are the <tref>label</tref>s of every node in the
-          graph with a label that begins with <code>_:</code> and that has a
-          path, via properties, that starts with the
-          <tref>node reference</tref>.
-        </dd>
-        <dt><tdef>outgoing serialization</tdef></dt>
-        <dd>
-          A string that can be lexicographically compared to the
-          <tref>outgoing serialization</tref>s of other
-          <tref>node state</tref>s. It is a representation of the
-          <tref>outgoing serialization map</tref> and other related
-          information. This string is initialized to an empty string.
-        </dd>
-        <dt><tdef>incoming serialization map</tdef></dt>
-        <dd>
-          Maps node <tref>label</tref>s to <tref>serialization label</tref>s.
-          This map is initialized to an empty map. When this map is populated,
-          it will be filled with keys that are the <tref>label</tref>s of every
-          node in the graph with a <tref>label</tref> that begins with
-          <code>_:</code> and that has a path, via properties, that ends with
-          the <tref>node reference</tref>.
-        </dd>
-        <dt><tdef>incoming serialization</tdef></dt>
-        <dd>
-          A string that can be lexicographically compared to the
-          <tref>outgoing serialization</tref>s of other
-          <tref>node state</tref>s. It is a representation of the
-          <tref>incoming serialization map</tref> and other related
-          information. This string is initialized to an empty string.
-        </dd>
-     </dl>
-   </dd>
-   <dt><tdef>node state map</tdef></dt>
-   <dd>
-     A mapping from a node's <tref>label</tref> to a <tref>node state</tref>.
-     It is initialized to an empty map.
-   </dd>
-   <dt><tdef>labeling prefix</tdef></dt>
-   <dd>
-     The labeling prefix is a string that is used as the beginning of a node
-     <tref>label</tref>. It should be initialized to a random base string that
-     starts with the characters <code>_:</code>, is not used by any other
-     node's <tref>label</tref> in the <tref>JSON-LD input</tref>, and does not
-     start with the characters <code>_:c14n</code>. The prefix has two uses.
-     First it is used to temporarily name nodes during the normalization
-     algorithm in a way that doesn't collide with the names that already
-     exist as well as the names that will be generated by the normalization
-     algorithm. Second, it will eventually be set to <code>_:c14n</code> to
-     generate the final, deterministic labels for nodes in the graph. This
-     prefix will be concatenated with the <tref>labeling counter</tref> to
-     produce a node <tref>label</tref>. For example, <code>_:j8r3k</code> is
-     a proper initial value for the <tref>labeling prefix</tref>.
-   </dd>
-   <dt><tdef>labeling counter</tdef></dt>
-   <dd>
-     A counter that is used to label nodes. It is appended to the
-     <tref>labeling prefix</tref> to create a node <tref>label</tref>. It is
-     initialized to <code>1</code>.
-   </dd>
-   <dt><tdef>map of flattened nodes</tdef></dt>
-   <dd>
-     A map containing a representation of all nodes in the graph where the
-     key is a node <tref>label</tref> and the value is a single
-     <tref>JSON object</tref> that has no nested sub-objects
-     and has had all properties for the same node merged into a single
-     <tref>JSON object</tref>.
-   </dd>
-</dl>
-
-</section>
-
-<section>
-<h3>Normalization Algorithm</h3>
-
-<p>The normalization algorithm expands the <tref>JSON-LD input</tref>,
-flattens the data structure, and creates an initial set of names for all
-nodes in the graph. The flattened data structure is then processed by a
-node labeling algorithm in order to get a fully expanded and named list of
-nodes which is then sorted. The result is a deterministically named and
-ordered list of graph nodes.
-</p>
-
-<ol class="algorithm">
-<li>Expand the <tref>JSON-LD input</tref> according to the steps in
-the <a href="#expansion-algorithm">Expansion Algorithm</a> and store the
-result as the <strong>expanded input</strong>.</li>
-<li>Create a <tref>normalization state</tref>.</li>
-<li>Initialize the <tref>map of flattened nodes</tref> by recursively
-processing every <tdef>expanded node</tdef> in the
-<strong>expanded input</strong> in depth-first order:
-  <ol class="algorithm">
-    <li>If the <tref>expanded node</tref> is an unlabeled node, add a
-      new key-value pair to the <tref>expanded node</tref>
-      where the key is <code>@subject</code> and the value is the
-      concatenation of the <tref>labeling prefix</tref>
-      and the string value of the <tref>labeling counter</tref>.
-      Increment the <tref>labeling counter</tref>.</li>
-    <li>Add the <tref>expanded node</tref> to the
-      <tref>map of flattened nodes</tref>:
-      <ol class="algorithm">
-        <li>If the <tref>expanded node</tref>'s <tref>label</tref> is already
-          in the
-          <tref>map of flattened nodes</tref> merge all properties from the
-          entry in the <tref>map of flattened nodes</tref> into the
-          <tref>expanded node</tref>.</li>
-        <li>Go through every property associated with an array in the
-          <tref>expanded node</tref> and remove any duplicate IRI entries from
-          the array. If the resulting array only has one IRI entry, change it
-          from an array to an object.</li>
-        <li>Set the entry for the <tref>expanded node</tref>'s <tref>label</tref>
-          in the <tref>map of flattened nodes</tref> to the
-          <tref>expanded node</tref>.
-        </li></ol></li>
-    <li>After exiting the recursive step, replace the reference to the
-      <tref>expanded node</tref> with an object containing a single
-       key-value pair where the key is <code>@iri</code> and the value is
-       the value of the <code>@subject</code> key in the node.</li>
-  </ol></li>
-<li>For every entry in the <tref>map of flattened nodes</tref>, insert a
-  key-value pair into the <tref>node state map</tref> where the key is the
-  key from the <tref>map of flattened nodes</tref> and the value is a
-  <tref>node state</tref> where its <tref>node reference</tref> refers to
-  the value from the <tref>map of flattened nodes</tref>.
-<li>Populate the <tref>incoming list</tref> for each <tref>node state</tref>
-  by iterating over every node in the graph and adding its <tref>label</tref>
-  to the <tref>incoming list</tref> associated with each node found in its
-  properties.</li>
-<li>For every entry in the <tref>node state map</tref> that has a
-<tref>label</tref> that begins with <code>_:c14n</code>, relabel the node
-using the <a href="#node-relabeling-algorithm">Node Relabeling Algorithm</a>.
-<li>Label all of the nodes that contain a <code>@subject</code> key associated
-with a value starting with <code>_:</code> according to the steps in the
-<a href="#deterministic-labeling-algorithm">Deterministic Labeling Algorithm</a>.
-</li>
-</ol>
-</section>
-
-<section>
-<h4>Node Relabeling Algorithm</h4>
-
-<p>This algorithm renames a node by generating a unique
-<tdef>new label</tdef> and updating all references to that <tref>label</tref>
-in the <tref>node state map</tref>. The <tdef>old label</tdef> and the
-<tref>normalization state</tref> must be given as an input to the
-algorithm. The <tref>old label</tref> is the current <tref>label</tref> of
-the node that is to be relabeled.
-
-<p>The node relabeling algorithm is as follows:</p>
-
-<ol class="algorithm">
-  <li>If the <tref>labeling prefix</tref> is <code>_:c14n</code> and the
-    <tref>old label</tref> begins with <code>_:c14n</code> then return as
-    the node has already been renamed.
-  </li>
-  <li>Generate the <tdef>new label</tdef> by concatenating the
-    <tref>labeling prefix</tref> with the string value of the
-    <tref>labeling counter</tref>. Increment the <tref>labeling counter</tref>.
-  </li>
-  <li>For the <tref>node state</tref> associated with the
-  <tref>old label</tref>, update every node in the <tref>incoming list</tref>
-  by changing all the properties that reference the <tref>old label</tref> to
-  the <tref>new label</tref>.
-  </li>
-  <li>Change the <tref>old label</tref> key in the <tref>node state map</tref>
-    to the <tref>new label</tref> and set the associated
-    <tref>node reference</tref>'s <tref>label</tref> to the
-    <tref>new label</tref>.
-  </li>
-</ol>
-</section>
-
-<section>
-<h4>Deterministic Labeling Algorithm</h4>
-
-<p>The deterministic labeling algorithm takes the
-<tref>normalization state</tref>
-and produces a <tdef>list of finished nodes</tdef> that is sorted and
-contains deterministically named and expanded nodes from the graph.
-
-<ol class="algorithm">
-  <li>Set the <tref>labeling prefix</tref> to <code>_:c14n</code>, the
-    <tref>labeling counter</tref> to <code>1</code>,
-    the <tdef>list of finished nodes</tdef> to an empty array, and create
-    an empty array, the <tdef>list of unfinished nodes</tdef>.</li>
-  <li>For each <tref>node reference</tref> in the <tref>node state map</tref>:
-    <ol class="algorithm">
-      <li>If the node's <tref>label</tref> does not start with <code>_:</code>
-        then put the <tref>node reference</tref> in the
-        <tref>list of finished nodes</tref>.
-      </li>
-      <li>If the node's <tref>label</tref> does start with <code>_:</code>
-        then put the <tref>node reference</tref> in the
-        <tref>list of unfinished nodes</tref>.
-      </li>
-    </ol>
-  </li>
-  <li>Append to the <tref>list of finished nodes</tref> by processing
-    the remainder of the <tref>list of unfinished nodes</tref> until it is
-    empty:
-    <ol class="algorithm">
-      <li>Sort the <tref>list of unfinished nodes</tref> in descending order
-        according to the
-        <a href="#deep-comparison-algorithm">Deep Comparison Algorithm</a> to
-        determine the sort order.</li>
-      <li>Create a <tdef>list of labels</tdef> and initialize it to an
-        empty array.</li>
-      <li>For the first node from the <tref>list of unfinished nodes</tref>:
-        <ol class="algorithm">
-          <li>Add its <tref>label</tref> to the <tref>list of labels</tref>.
-          </li>
-          <li>For each key-value pair from its associated
-            <tref>outgoing serialization map</tref>, add the key to a list and
-            then sort the list according to the lexicographical order of the
-            keys' associated values. Append the list to the
-            <tref>list of nodes to label</tref>.
-          </li>
-          <li>For each key-value pair from its associated
-            <tref>incoming serialization map</tref>, add the key to a list and
-            then sort the list according to the lexicographical order of the
-            keys' associated values. Append the list to the
-            <tref>list of nodes to label</tref>.
-          </li></ol></li>
-      <li>For each <tref>label</tref> in the <tref>list of labels</tref>,
-        relabel the associated node according to the
-        <a href="#node-relabeling-algorithm">Node Relabeling Algorithm</a>. If
-        any <tref>outgoing serialization map</tref> contains a key that
-        matches the <tref>label</tref>, clear the map and set the associated
-        <tref>outgoing serialization</tref> to an empty string. If any
-        <tref>incoming serialization map</tref> contains a key that
-        matches the <tref>label</tref>, clear the map and set the associated
-        <tref>incoming serialization</tref> to an empty string.
-      </li>
-      <li>
-        Remove each node with a <tref>label</tref> that starts with
-        <code>_:c14n</code> from the <tref>list of unfinished nodes</tref> and
-        add it to the <tref>list of finished nodes</tref>.
-      </li>
-    </ol>
-  </li>
-  <li>Sort the <tref>list of finished nodes</tref> in descending order
-    according to the
-    <a href="#deep-comparison-algorithm">Deep Comparison Algorithm</a> to
-    determine the sort order.</li>
-</ol>
-</section>
-
-<section>
-<h4>Shallow Comparison Algorithm</h4>
-
-<p>
-The shallow comparison algorithm takes two unlabeled nodes,
-<tref>alpha</tref> and <tref>beta</tref>, as input and
-determines which one should come first in a sorted list. The following
-algorithm determines the steps that are executed in order to determine the
-node that should come first in a list:
-</p>
-
-<ol class="algorithm">
-  <li>Compare the total number of node properties. The node with fewer
-    properties is first.</li>
-  <li>Lexicographically sort the property IRIs for each node and compare
-    the sorted lists. If an IRI is found to be lexicographically smaller, the
-    node containing that IRI is first.</li>
-  <li>Compare the values of each property against one another:
-    <ol class="algorithm">
-      <li>The node associated with fewer property values is first.
-      </li>
-      <li>Create an <tdef>alpha list</tdef> by adding all values associated
-        with the <tref>alpha</tref> property that are not unlabeled nodes.
-      </li>
-      <li>Create a <tdef>beta list</tdef> by adding all values associated
-        with the <tref>beta</tref> property that is not an unlabeled node.
-      </li>
-      <li>Compare the length of <tref>alpha list</tref> and
-        <tref>beta list</tref>. The node associated with the list containing
-        the fewer number of items is first.</li>
-      <li>Sort <tref>alpha list</tref> and <tref>beta list</tref> according to
-        the
-        <a href="#object-comparison-algorithm">Object Comparison Algorithm</a>.
-        For each offset into the <tref>alpha list</tref>, compare the item
-        at the offset against the item at the same offset in the
-        <tref>beta list</tref> according to the
-        <a href="#object-comparison-algorithm">Object Comparison Algorithm</a>.
-        The node associated with the lesser item is first.
-    </ol></li>
-  <li>Process the <tref>incoming list</tref>s associated with each node to
-    determine order:
-    <ol class="algorithm">
-      <li>The node with the shortest <tref>incoming list</tref> is first.</li>
-      <li>Sort the <tref>incoming list</tref>s according to incoming property
-         and then incoming <tref>label</tref>.
-      <li>The node associated with the fewest number of incoming nodes is
-        first.</li>
-      <li>For each offset into the <tref>incoming list</tref>s,
-        compare the associated properties and <tref>label</tref>s:
-        <ol class="algorithm">
-          <li>The node associated with a <tref>label</tref> that does not begin with
-            <code>_:</code> is first.
-          </li>
-          <li>If the nodes' <tref>label</tref>s do not begin with
-            <code>_:</code>, then the node associated with the
-            lexicographically lesser <tref>label</tref> is first.</li>
-          </li>
-          <li>The node associated with the lexicographically lesser associated
-            property is first.
-          </li>
-          <li>The node with the <tref>label</tref> that does not begin with
-            <code>_:c14n</code> is first.
-          </li>
-          <li>The node with the lexicographically lesser <tref>label</tref>
-            is first.
-          </li>
-        </ol>
-    </ol></li>
-  <li>Otherwise, the nodes are equivalent.</li>
-</section>
-
-<section>
-<h4>Object Comparison Algorithm</h4>
-
-<p>
-The object comparison algorithm is designed to compare two graph node
-property values, <tref>alpha</tref> and <tref>beta</tref>, against the other.
-The algorithm is useful when sorting two lists of graph node properties.
-</p>
-
-<ol class="algorithm">
-  <li>If one of the values is a <tref>string</tref> and the other is not, the value that is
-    a string is first.
-  </li>
-  <li>If both values are <tref>string</tref>s, the lexicographically lesser string is
-    first.
-  </li>
-  <li>If one of the values is a literal and the other is not, the value that is
-    a literal is first.
-  </li>
-  <li>If both values are literals:
-    <ol class="algorithm">
-      <li>The lexicographically lesser string associated with
-        <code>@literal</code> is first.
-      </li>
-      <li>The lexicographically lesser string associated with
-        <code>@datatype</code> is first.
-      </li>
-      <li>The lexicographically lesser string associated with
-        <code>@language</code> is first.
-      </li>
-    </ol>
-  </li>
-  <li>If both values are expanded IRIs, the
-    lexicographically lesser string associated with <code>@iri</code>
-    is first.</li>
-  <li>Otherwise, the two values are equivalent.</li>
-</ol>
-
-</section>
-
-<section>
-<h4>Deep Comparison Algorithm</h4>
-
-<p>
-The deep comparison algorithm is used to compare the difference between two
-nodes, <tref>alpha</tref> and <tref>beta</tref>.
-A deep comparison takes the incoming and outgoing node edges in
-a graph into account if the number of properties and value of those properties
-are identical. The algorithm is helpful when sorting a list of nodes and will
-return whichever node should be placed first in a list if the two nodes are
-not truly equivalent.
-</p>
-
-<p>When performing the steps required by the deep comparison algorithm, it
-is helpful to track state information about mappings. The information
-contained in a <tref>mapping state</tref> is described below.</p>
-
-<dl class="algorithm">
-   <dt><tdef>mapping state</tdef></dt>
-   <dd>
-     <dl>
-        <dt><tdef>mapping counter</tdef></dt>
-        <dd>
-          Keeps track of the number of nodes that have been mapped to
-          <tref>serialization labels</tref>. It is initialized to
-          <code>1</code>.
-        </dd>
-        <dt><tdef>processed labels map</tdef></dt>
-        <dd>
-          Keeps track of the <tref>label</tref>s of nodes that have already
-          been assigned <tref>serialization label</tref>s. It is initialized
-          to an empty map.
-        </dd>
-        <dt><tdef>serialized labels map</tdef></dt>
-        <dd>
-          Maps a node <tref>label</tref> to its associated
-          <tref>serialization label</tref>. It is initialized to an empty map.
-        </dd>
-        <dt><tdef>adjacent info map</tdef></dt>
-        <dd>
-          Maps a <tref>serialization label</tref> to the node
-          <tref>label</tref> associated with it, the list of sorted
-          <tref>serialization label</tref>s for adjacent nodes, and the map of
-          adjacent node <tref>serialiation label</tref>s to their associated
-          node <tref>label</tref>s. It is initialized to an empty map.
-        </dd>
-        <dt><tdef>key stack</tdef></dt>
-        <dd>
-          A stack where each element contains an array of adjacent
-          <tref>serialization label</tref>s and an index into that array. It
-          is initialized to a stack containing a single element where its
-          array contains a single string element <code>s1</code> and its
-          index is set to <code>0</code>.
-        </dd>
-        <dt><tdef>serialized keys</tdef></dt>
-        <dd>
-          Keeps track of which <tref>serialization label</tref>s have already
-          been written at least once to the <tref>serialization string</tref>.
-          It is initialized to an empty map.
-        </dd>
-        <dt><tdef>serialization string</tdef></dt>
-        <dd>
-          A string that is incrementally updated as a serialization is built.
-          It is initialized to an empty string.
-        </dd>
-     </dl>
-   </dd>
-</dl>
-
-<p>The deep comparison algorithm is as follows:</p>
-
-<ol class="algorithm">
-  <li>Perform a comparison between <tref>alpha</tref> and <tref>beta</tref>
-    according to the
-    <a href="#shallow-comparison-algorithm">Shallow Comparison Algorithm</a>.
-    If the result does not show that the two nodes are equivalent, return
-    the result.
-    </li>
-  <li>Compare incoming and outgoing edges for each node, updating their
-    associated <tref>node state</tref> as each node is processed:
-    <ol class="algorithm">
-      <li>If the <tref>outgoing serialization map</tref> for <tref>alpha</tref>
-        is empty, generate the serialization according to the
-        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
-        Provide <tref>alpha</tref>'s <tref>node state</tref>, a new
-        <tref>mapping state</tref>,
-        <code>outgoing direction</code> to the algorithm as inputs.
-      <li>If the <tref>outgoing serialization map</tref> for <tref>beta</tref>
-        is empty, generate the serialization according to the
-        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
-        Provide <tref>beta</tref>'s <tref>node state</tref>, a new
-        <tref>mapping state</tref>, and
-        <code>outgoing direction</code> to the algorithm as inputs.
-      <li>If <tref>alpha</tref>'s <tref>outgoing serialization</tref> is
-        lexicographically less than <tref>beta</tref>'s, then
-        <tref>alpha</tref> is first. If it is greater, then <tref>beta</tref>
-        is first.</li>
-      <li>If the <tref>incoming serialization map</tref> for <tref>alpha</tref>
-        is empty, generate the serialization according to the
-        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
-        Provide <tref>alpha</tref>'s <tref>node state</tref>, a new
-        <tref>mapping state</tref> with its <tref>serialized labels map</tref>
-        set to a copy of <tref>alpha</tref>'s
-        <tref>outgoing serialization map</tref>, and
-        <code>incoming direction</code> to the algorithm as inputs.
-      <li>If the <tref>incoming serialization map</tref> for <tref>beta</tref>
-        is empty, generate the serialization according to the
-        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
-        Provide <tref>beta</tref>'s <tref>node state</tref>, a new
-        <tref>mapping state</tref> with its <tref>serialized labels map</tref>
-        set to a copy of <tref>beta</tref>'s
-        <tref>outgoing serialization map</tref>, and
-        <code>incoming direction</code> to the algorithm as inputs.
-      <li>If <tref>alpha</tref>'s <tref>incoming serialization</tref> is
-        lexicographically less than <tref>beta</tref>'s, then
-        <tref>alpha</tref> is first. If it is greater, then <tref>beta</tref>
-        is first.</li>
-    </ol></li>
-</ol>
-</section>
-
-<section>
-<h4>Node Serialization Algorithm</h4>
-
-<p>
-The node serialization algorithm takes a <tref>node state</tref>, a
-<tref>mapping state</tref>, and a <tdef>direction</tdef> (either
-<code>outgoing direction</code> or <code>incoming direction</code>) as
-inputs and generates a deterministic serialization for the
-<tref>node reference</tref>.
-</p>
-
-<ol class="algorithm">
-<li>If the <tref>label</tref> exists in the
-  <tref>processed labels map</tref>, terminate the algorithm as the
-  <tref>serialization label</tref> has already been created.
-</li>
-<li>Set the value associated with the <tref>label</tref> in the
-  <tref>processed labels map</tref> to <code>true</code>.
-</li>
-<li>Generate the next <tdef>serialization label</tdef> for the
-  <tref>label</tref> according to the
-  <a href="#serialization-label-generation-algorithm">Serialization Label Generation Algorithm</a>.
-</li>
-<li>Create an empty map called the <tdef>adjacent serialized labels map</tdef>
-that will store mappings from <tref>serialized label</tref>s to adjacent
-node <tref>label</tref>s.</li>
-<li>Create an empty array called the
-<tdef>adjacent unserialized labels list</tdef> that will store
-<tref>label</tref>s of adjacent nodes that haven't been assigned
-<tref>serialization label</tref>s yet.
-</li>
-<li>For every <tref>label</tref> in a list, where the list the <tref>outgoing list</tref> if
-the <tref>direction</tref> is <code>outgoing direction</code> and the
-<tref>incoming list</tref> otherwise, if the <tref>label</tref> starts with
-<code>_:</code>, it is the <tdef>target node label</tdef>:
-  <ol class="algorithm">
-    <li>Look up the <tref>target node label</tref> in the
-      <tref>processed labels map</tref> and if a mapping exists,
-      update the <tref>adjacent serialized labels map</tref> where the key is
-      the value in the <tref>serialization map</tref> and the value is the
-      <tref>target node label</tref>.</li>
-    <li>Otherwise, add the <tref>target node label</tref> to the
-      <tref>adjacent unserialized labels list</tref>.
-  </ol>
-</li>
-<li>Set the <tdef>maximum serialization combinations</tdef> to
-  <code>1</code> or the length of the
-  <tref>adjacent unserialized labels list</tref>, whichever is greater.</li>
-<li>While the <tref>maximum serialization combinations</tref> is greater than
-  <code>0</code>, perform the
-  <a href="#combinatorial-serialization-algorithm">Combinatorial Serialization Algorithm</a>
-  passing the <tref>node state</tref>, the <tref>mapping state</tref> for the
-  first iteration and a copy of it for each subsequent iteration, the
-  generated <tref>serialization label</tref>, the <tref>direction</tref>,
-  the <tref>adjacent serialized labels map</tref>, and the
-  <tref>adjacent unserialized labels list</tref>.
-  Decrement the <tref>maximum serialization combinations</tref> by
-  <code>1</code> for each iteration.
-</ol>
-
-</section>
-
-<section>
-<h4>Serialization Label Generation Algorithm</h4>
-
-<p>
-The algorithm generates a <tref>serialization label</tref> given a
-<tref>label</tref> and a <tref>mapping state</tref> and returns the
-<tref>serialization label</tref>.
-</p>
-
- <ol class="algorithm">
-   <li>If the <tref>label</tref> is already in the
-     <tref>serialization labels map</tref>, return its associated value.
-   </li>
-   <li>If the <tref>label</tref> starts with the string <code>_:c14n</code>,
-     the <tref>serialization label</tref> is the letter <code>c</code>
-     followed by the number that follows <code>_:c14n</code> in the
-     <tref>label</tref>.
-   </li>
-   <li>Otherwise, the <tref>serialization label</tref> is the
-     letter <code>s</code> followed by the string value of
-     <tref>mapping count</tref>. Increment the <tref>mapping count</tref> by
-     <code>1</code>.
-   </li>
-   <li>Create a new key-value pair in the <tref>serialization labels map</tref>
-     where the key is the <tref>label</tref> and the value is the
-     generated <tref>serialization label</tref>.
-   </li>
- </ol>
-</section>
-
-<section>
-<h4>Combinatorial Serialization Algorithm</h4>
-
-<p>
-The combinatorial serialization algorithm takes a <tref>node state</tref>, a
-<tref>mapping state</tref>, a <tref>serialization label</tref>, a
-<tref>direction</tref>, a <tref>adjacent serialized labels map</tref>,
-and a <tref>adjacent unserialized labels list</tref> as inputs and generates
-the lexicographically least serialization of nodes relating to the
-<tref>node reference</tref>.
-</p>
-
-<ol class="algorithm">
-  <li>If the <tref>adjacent unserialized labels list</tref> is not empty:
-    <ol class="algorithm">
-      <li>Copy the <tref>adjacent serialized labels map</tref> to the
-        <tdef>adjacent serialized labels map copy</tdef>.</li>
-      <li>Remove the first <tref>unserialized label</tref> from the
-        <tref>adjacent unserialized labels list</tref> and create a new
-        <tdef>new serialization label</tdef> according to the
-        <a href="#serialization-label-generation-algorithm">Serialization Label Generation Algorithm</a>.
-      <li>Create a new key-value mapping in the
-        <tref>adjacent serialized labels map copy</tref>
-        where the key is the <tref>new serialization label</tref> and the value
-        is the <tref>unserialized label</tref>.
-      <li>Set the <tdef>maximum serialization rotations</tdef> to
-        <code>1</code> or the length of the
-        <tref>adjacent unserialized labels list</tref>, whichever is greater.
-      </li>
-      <li>While the <tref>maximum serialization rotations</tref> is greater than
-        <code>0</code>:
-        <ol class="algorithm">
-          <li>Recursively perform the
-            <a href="#combinatorial-serialization-algorithm">Combinatorial Serialization Algorithm</a>
-            passing the <tref>mapping state</tref> for the first iteration of the
-            loop, and a copy of it for each subsequent iteration.
-          </li>
-          <li>Rotate the elements in the
-            <tref>adjacent unserialized labels list</tref> by shifting each of
-            them once to the right, moving the element at the end of the list
-            to the beginning of the list.
-          </li>
-          <li>Decrement the <tref>maximum serialization rotations</tref> by
-            <code>1</code> for each iteration.
-          </li>
-        </ol>
-      </li>
-    </ol>
-  </li>
-  <li>If the <tref>adjacent unserialized labels list</tref> is empty:
-    <ol class="algorithm">
-      <li>Create a <tdef>list of keys</tdef> from the keys in the
-        <tref>adjacent serialized labels map</tref> and sort it
-        lexicographically.
-      </li>
-      <li>Add a key-value pair to the <tref>adjacent info map</tref> where
-        the key is the <tref>serialization label</tref> and the value is
-        an object containing the <tref>node reference</tref>'s label, the
-        <tref>list of keys</tref> and the
-        <tref>adjacent serialized labels map</tref>.
-      </li>
-      <li>Update the <tref>serialization string</tref> according to the
-        <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>.
-      </li>
-      <li>If the <tref>direction</tref> is <code>outgoing direction</code>
-        then <tdef>directed serialization</tdef> refers to the
-        <tref>outgoing serialization</tref> and the
-        <tdef>directed serialization map</tdef> refers to the
-        <tref>outgoing serialization map</tref>, otherwise it refers to the
-        <tref>incoming serialization</tref> and the
-        <tref>directed serialization map</tref> refers to the
-        <tref>incoming serialization map</tref>. Compare the
-        <tref>serialization string</tref> to the
-        <tref>directed serialization</tref> according to the
-        <a href="#mapping-serialization-algorithm">Serialization Comparison Algorithm</a>.
-        If the <tref>serialization string</tref> is less than or equal to
-        the <tref>directed serialization</tref>:
-        <ol class="algorithm">
-          <li>For each value in the <tref>list of keys</tref>, run the
-            <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
-          </li>
-	       <li>Update the <tref>serialization string</tref> according to the
-	         <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>.
-	       </li>
-	       <li>Compare the <tref>serialization string</tref> to the
-	         <tref>directed serialization</tref> again and if it is less than
-	         or equal and the length of the <tref>serialization string</tref> is
-	         greater than or equal to the length of the
-	         <tref>directed serialization</tref>, then set the
-	         <tref>directed serialization</tref> to the
-	         <tref>serialization string</tref> and set the
-	         <tref>directed serialization map</tref> to the
-	         <tref>serialized labels map</tref>.
-	       </li>
-        </ol>
-      </li>
-    </ol>
-  </li>
-</ol>
-
-</section>
-
-<section>
-<h4>Serialization Comparison Algorithm</h4>
-
-<p>
-The serialization comparison algorithm takes two serializations,
-<tref>alpha</tref> and <tref>beta</tref> and returns either which of the two
-is less than the other or that they are equal.
-</p>
-
-<ol class="algorithm">
-  <li>Whichever serialization is an empty string is greater. If they are
-    both empty strings, they are equal.</li>
-  <li>Return the result of a lexicographical comparison of <tref>alpha</tref>
-    and <tref>beta</tref> up to the number of characters in the shortest of
-    the two serializations.
-  </li>
-</ol>
-</section>
-
-<section>
-<h4>Mapping Serialization Algorithm</h4>
-
-<p>
-The mapping serialization algorithm incrementally updates the
-<tref>serialization string</tref> in a <tref>mapping state</tref>.
-</p>
-
-<ol class="algorithm">
-  <li>If the <tref>key stack</tref> is not empty:
-    <ol class="algorithm">
-      <li>Pop the <tdef>serialization key info</tdef> off of the
-        <tref>key stack</tref>.
-      </li>
-      <li>For each <tdef>serialization key</tdef> in the
-        <tref>serialization key info</tref> array, starting at
-        the <tdef>serialization key index</tdef> from the
-        <tref>serialization key info</tref>:
-        <ol class="algorithm">
-          <li>If the <tref>serialization key</tref> is not in the
-            <tref>adjacent info map</tref>, push the
-            <tref>serialization key info</tref> onto the
-            <tref>key stack</tref> and exit from this loop.
-          </li>
-          <li>If the <tref>serialization key</tref> is a key in
-            <tref>serialized keys</tref>, a cycle has been detected. Append
-            the concatenation of the <code>_</code> character and the
-            <tref>serialization key</tref> to the
-            <tref>serialization string</tref>.
-          <li>Otherwise, serialize all outgoing and incoming edges in the
-            related node by performing the following steps:
-            <ol class="algorithm">
-              <li>Mark the <tref>serialization key</tref> as having
-                been processed by adding a new key-value pair to
-                <tref>serialized keys</tref> where the key
-                is the <tref>serialization key</tref> and the value is
-                <code>true</code>.
-              </li>
-              <li>Set the <tdef>serialization fragment</tdef> to the value of
-                the <tref>serialization key</tref>.</li>
-              <li>Set the <tref>adjacent info</tref> to the value of the
-                <tref>serialization key</tref> in the
-                <tref>adjacent info map</tref>.
-              </li>
-              <li>Set the <tref>adjacent node label</tref> to the node
-                <tref>label</tref> from the <tref>adjacent info</tref>.
-              </li>
-              <li>If a mapping for the <tref>adjacent node label</tref>
-                exists in the <tref>map of all labels</tref>:
-                <ol class="algorithm">
-                  <li>Append the result of the
-                    <a href="">Label Serialization Algorithm</a> to the
-                    <tref>serialization fragment</tref>.
-                  </li>
-                </ol>
-              </li>
-              <li>Append all of the keys in the <tref>adjacent info</tref>
-                to the <tref>serialization fragment</tref>.
-              </li>
-              <li>Append the <tref>serialization fragment</tref> to the
-                <tref>serialization string</tref>.
-              </li>
-              <li>Push a new key info object containing the keys from the
-                <tref>adjacent info</tref> and an index of <code>0</code>
-                onto the <tref>key stack</tref>.
-              </li>
-              <li>Recursively update the <tref>serialization string</tref>
-                according to the
-                <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>.
-              </li>
-            </ol>
-          </li>
-        </ol>
-      </li>
-    </ol>
-  </li>
-</ol>
-
-</section>
-
-<section>
-<h4>Label Serialization Algorithm</h4>
-
-<p>
-The label serialization algorithm serializes information about a node that
-has been assigned a particular <tref>serialization label</tref>.
-</p>
-
-<ol class="algorithm">
-  <li>Initialize the <tref>label serialization</tref> to an empty string.</li>
-  <li>Append the <code>[</code> character to the
-    <tref>label serialization</tref>.</li>
-  <li>Append all properties to the <tref>label serialization</tref> by
-    processing each key-value pair in the <tref>node reference</tref>,
-    excluding the
-    <code>@subject</code> property. The keys should be processed in
-    lexicographical order and their associated values should be processed
-    in the order produced by the
-    <a href="#object-comparison-algorithm">Object Comparison Algorithm</a>:
-    <ol class="algorithm">
-      <li>Build a string using the pattern <code>&lt;</code><strong>KEY</strong><code>&gt;</code>
-        where <strong>KEY</strong> is the current key. Append string to the
-        <tref>label serialization</tref>.</li>
-      <li>The value may be a single object or an array of objects.
-        Process all of the objects that are associated with the key, building
-        an <tdef>object string</tdef> for each item:
-        <ol class="algorithm">
-          <li>If the object contains an <code>@iri</code> key with a
-            value that starts
-            with <code>_:</code>, set the <tref>object string</tref> to
-            the value <code>_:</code>. If the value does not
-            start with <code>_:</code>, build the <tref>object string</tref>
-            using the pattern
-            <code>&lt;</code><strong>IRI</strong><code>&gt;</code>
-            where <strong>IRI</strong> is the value associated with the
-            <code>@iri</code> key.</li>
-          <li>If the object contains a <code>@literal</code> key and a
-            <code>@datatype</code> key, build the <tref>object string</tref>
-            using the pattern
-            <code>"</code><strong>LITERAL</strong><code>"^^&lt;</code><strong>DATATYPE</strong><code>&gt;</code>
-            where <strong>LITERAL</strong> is the value associated with the
-            <code>@literal</code> key and <strong>DATATYPE</strong> is the
-            value associated with the <code>@datatype</code> key.</li>
-          <li>If the object contains a <code>@literal</code> key and a
-            <code>@language</code> key, build the <tref>object string</tref>
-            using the pattern
-            <code>"</code><strong>LITERAL</strong><code>"@</code><strong>LANGUAGE</strong>
-            where <strong>LITERAL</strong> is the value associated with the
-            <code>@literal</code> key and <strong>LANGUAGE</strong> is the
-            value associated with the <code>@language</code> key.</li>
-          <li>Otherwise, the value is a string. Build the
-            <tref>object string</tref> using the pattern
-            <code>"</code><strong>LITERAL</strong><code>"</code>
-            where <strong>LITERAL</strong> is the value associated with the
-            current key.</li>
-          <li>If this is the second iteration of the loop,
-            append a <code>|</code> separator character to the
-            <tref>label serialization</tref>.</li>
-          <li>Append the <tref>object string</tref> to the
-            <tref>label serialization</tref>.</li>
-        </ol>
-    </ol>
-  </li>
-  <li>Append the <code>]</code> character to the
-    <tref>label serialization</tref>.</li>
-  <li>Append the <code>[</code> character to the
-    <tref>label serialization</tref>.</li>
-  <li>Append all incoming references for the current
-    <tref>label</tref> to the <tref>label serialization</tref> by
-    processing all of the items associated with the <tref>incoming list</tref>:
-    <ol class="algorithm">
-      <li>Build a <tdef>reference string</tdef>
-        using the pattern <code>&lt;</code><strong>PROPERTY</strong><code>&gt;</code><code>&lt;</code><strong>REFERER</strong><code>&gt;</code>
-        where <strong>PROPERTY</strong> is the property associated with the
-        incoming reference and <strong>REFERER</strong> is either the subject of
-        the node referring to the <tref>label</tref> in the incoming reference
-        or <code>_:</code> if <strong>REFERER</strong> begins with
-        <code>_:</code>.
-      <li>If this is the second iteration of the loop,
-        append a <code>|</code> separator character to the
-        <tref>label serialization</tref>.</li>
-      <li>Append the <tref>reference string</tref> to the
-        <tref>label serialization</tref>.</li>
-    </ol>
-  <li>Append the <code>]</code> character to the
-    <tref>label serialization</tref>.</li>
-  <li>Append all <tref>adjacent node labels</tref> to the
-    <tref>label serialization</tref> by concatenating the string value
-    for all of them, one after the other, to the
-    <tref>label serialization</tref>.</li>
-  <li>Push the <tref>adjacent node labels</tref> onto the
-    <tref>key stack</tref> and append the result of the
-    <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>
-    to the <tref>label serialization</tref>.
-</ol>
-
-</section>
-
-</section>
-
-<section>
-
-<h3>Data Round Tripping</h3>
-
-<p>When normalizing <strong>xsd:double</strong> values, implementers MUST
-ensure that the normalized value is a string. In order to generate the
-string from a <strong>double</strong> value, output equivalent to the
-<code>printf("%1.6e", value)</code> function in C MUST be used where
-<strong>"%1.6e"</strong> is the string formatter and <strong>value</strong>
-is the value to be converted.</p>
-
-<p>To convert the a double value in JavaScript, implementers can use the
-following snippet of code:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-// the variable 'value' below is the JavaScript native double value that is to be converted
-(value).toExponential(6).replace(/(e(?:\+|-))([0-9])$/, '$10$2')
--->
-</pre>
-
-<p class="note">When data needs to be normalized, JSON-LD authors should
-not use values that are going to undergo automatic conversion. This is due
-to the lossy nature of <strong>xsd:double</strong> values.</p>
-
-<p class="note">Some JSON serializers, such as PHP's native implementation,
-backslash-escapes the forward slash character. For example, the value
-<code>http://example.com/</code> would be serialized as
-<code>http:\/\/example.com\/</code> in some
-versions of PHP. This is problematic when generating a byte
-stream for processes such as normalization. There is no need to
-backslash-escape forward-slashes in JSON-LD. To aid interoperability between
-JSON-LD processors, a JSON-LD serializer MUST NOT backslash-escape
-forward slashes.</p>
-
-<p class="issue">Round-tripping data can be problematic if we mix and
-match @coerce rules with JSON-native datatypes, like integers. Consider the
-following code example:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-var myObj = { "@context" : {
-                "number" : "http://example.com/vocab#number",
-                "@coerce": {
-                   "xsd:nonNegativeInteger": "number"
-                }
-              },
-              "number" : 42 };
-
-// Map the language-native object to JSON-LD
-var jsonldText = jsonld.normalize(myObj);
-
-// Convert the normalized object back to a JavaScript object
-var myObj2 = jsonld.parse(jsonldText);
--->
-</pre>
-
-<p class="issue">At this point, myObj2 and myObj will have different
-values for the "number" value. myObj will be the number 42, while
-myObj2 will be the string "42". This type of data round-tripping
-error can bite developers. We are currently wondering if having a
-"coerce validation" phase in the parsing/normalization phases would be a
-good idea. It would prevent data round-tripping issues like the
-one mentioned above.</p>
-
-</section>
-
-<section>
-<h2>RDF Conversion</h2>
-
-<p>A JSON-LD document MAY be converted to any other RDF-compatible document
-format using the algorithm specified in this section.</p>
-
-<p>
-  The JSON-LD Processing Model describes processing rules for extracting RDF
-  from a JSON-LD document. Note that many uses of JSON-LD may not require
-  generation of RDF.
-</p>
-
-<p>
-The processing algorithm described in this section is provided in
-order to demonstrate how one might implement a JSON-LD to RDF processor.
-Conformant implementations are only required to produce the same type and
-number of triples during the output process and are not required to
-implement the algorithm exactly as described.
-</p>
-
-<p class="issue">The RDF Conversion Algorithm is a work in progress.</p>
-
-<section class="informative">
-  <h4>Overview</h4>
-  <p>
-    JSON-LD is intended to have an easy to parse grammar that closely models existing
-    practice in using JSON for describing object representations. This allows the use
-    of existing libraries for parsing JSON.
-  </p>
-  <p>
-    As with other grammars used for describing <tref>Linked Data</tref>, a key concept is that of
-    a <em>resource</em>. Resources may be of three basic types: <em>IRI</em>s, for describing
-    externally named entities, <em>BNodes</em>, resources for which an external name does not
-    exist, or is not known, and Literals, which describe terminal entities such as strings,
-    dates and other representations having a lexical representation possibly including
-    an explicit language or datatype.
-  </p>
-  <p>
-    Data described with JSON-LD may be considered to be the representation of a graph made
-    up of <tref>subject</tref> and <tref>object</tref> resources related via a <tref>property</tref> resource.
-    However, specific implementations may choose to operate on the document as a normal
-    JSON description of objects having attributes.
-  </p>
-</section>
-
-<section>
-  <h4>RDF Conversion Algorithm Terms</h4>
-  <dl>
-    <dt><tdef>default graph</tdef></dt>
-    <dd>
-      the destination graph for all triples generated by JSON-LD markup.
-    </dd>
-  </dl>
-</section>
-
-<section>
-  <h3>RDF Conversion Algorithm</h3>
-  <p>
-    The algorithm below is designed for in-memory implementations with random access to <tref>JSON object</tref> elements.
-  </p>
-  <p>
-    A conforming JSON-LD processor implementing RDF conversion MUST implement a
-    processing algorithm that results in the same <tref>default graph</tref> that the following
-    algorithm generates:
-  </p>
-
-  <ol class="algorithm">
-    <li id="processing-step-default-context">
-      Create a new <tref>processor state</tref> with with the <tref>active context</tref> set to the
-      <tref>initial context</tref> and <tref>active subject</tref> and <tref>active property</tref>
-      initialized to NULL.
-    </li>
-
-    <li id="processing-step-associative">
-      If a <tref>JSON object</tref> is detected, perform the following steps:
-      <ol class="algorithm">
-        <li>
-          If the <tref>JSON object</tref> has a <code>@context</code> key, process the local context as
-          described in <a href="#context">Context</a>.
-        </li>
-        <li>
-          Create a new <tref>JSON object</tref> by mapping the keys from the current <tref>JSON object</tref> using the
-          <tref>active context</tref> to new keys using the associated value from the current <tref>JSON object</tref>.
-          Repeat the mapping until no entry is found within the <tref>active context</tref> for the key. Use the new
-          <tref>JSON object</tref> in subsequent steps.
-        </li>
-        <li>
-          If the <tref>JSON object</tref> has an <code>@iri</code> key, set the <tref>active object</tref> by
-          performing <a href="#iri-expansion">IRI Expansion</a> on the associated value. Generate a
-          triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
-          <tref>active object</tref>. Return the <tref>active object</tref> to the calling location.
-          <p class="issue"><code>@iri</code> really just behaves the same as <code>@subject</code>, consider consolidating them.</p>
-        </li>
-        <li>
-          If the <tref>JSON object</tref> has a <code>@literal</code> key, set the <tref>active object</tref>
-          to a literal value as follows:
-          <ol class="algorithm">
-            <li>
-              as a <tref>typed literal</tref> if the <tref>JSON object</tref> contains a <code>@datatype</code> key
-              after performing <a href="#iri-expansion">IRI Expansion</a> on the specified<code>@datatype</code>.
-            </li>
-            <li>
-              otherwise, as a <tref>plain literal</tref>. If the <tref>JSON object</tref> contains
-              a <code>@language</code> key, use it's value to set the language of the plain literal.
-            </li>
-            <li>
-              Generate a triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
-              <tref>active object</tref>. Return the <tref>active object</tref> to the calling location.
-            </li>
-          </ol>
-        </li>
-        <li id="processing-step-subject">If the <tref>JSON object</tref> has a <code>@subject</code> key:
-          <ol class="algorithm">
-            <li>
-              If the value is a <tref>string</tref>, set the <tref>active object</tref> to the result of performing
-              <a href="#iri-expansion">IRI Expansion</a>. Generate a
-              triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
-              <tref>active object</tref>. Set the <tref>active subject</tref> to the <tref>active object</tref>.
-            </li>
-            <li>
-              Create a new <tref>processor state</tref> using copies of the <tref>active context</tref>,
-              <tref>active subject</tref> and <tref>active property</tref> and process the value
-              starting at <a href="#processing-step-associative">Step 2</a>, set the <tref>active
-              subject</tref> to the result and proceed using the previous <tref>processor state</tref>.
-            </li>
-          </ol>
-        </li>
-        <li>
-          If the <tref>JSON object</tref> does not have a <code>@subject</code> key, set the <tref>active
-          object</tref> to newly generated <tdef>blank node identifier</tdef>. Generate a triple
-          representing the <tref>active subject</tref>, the <tref>active property</tref> and the
-          <tref>active object</tref>. Set the <tref>active subject</tref> to the <tref>active
-          object</tref>.
-        </li>
-        <li>
-          For each key in the <tref>JSON object</tref> that has not already been processed, perform
-          the following steps:
-          <ol class="algorithm">
-            <li>
-              If the key is <code>@type</code>, set the <tref>active property</tref>
-              to <code>rdf:type</code>.
-            </li>
-            <li>Otherwise, set the <tref>active property</tref> to the result of performing
-            <a href="#iri-expansion">IRI Expansion</a> on the key.</li>
-            <li>
-              Create a new <tref>processor state</tref> copies of the <tref>active context</tref>,
-              <tref>active subject</tref> and <tref>active property</tref> and process the value
-              starting at <a href="#processing-step-associative">Step 2</a> and proceed using the
-              previous <tref>processor state</tref>.
-            </li>
-          </ol>
-        </li>
-        <li>
-          Return the <tref>active object</tref> to the calling location.
-        </li>
-      </ol>
-    </li>
-
-    <li>
-      If a regular <tref>array</tref> is detected, process each value in the <tref>array</tref> by doing the following
-      returning the result of processing the last value in the <tref>array</tref>:
-
-      <ol class="algorithm">
-        <li>
-          Create a new <tref>processor state</tref> using copies of the <tref>active
-          context</tref>, <tref>active subject</tref> and <tref>active property</tref> and process the value
-          starting at <a href="#processing-step-associative">Step 2</a> then proceed using the previous
-          <tref>processor state</tref>.
-        </li>
-      </ol>
-    </li>
-
-    <li>
-      If a <tref>string</tref> is detected:
-      <ol class="algorithm">
-        <li>
-          If the <tref>active property</tref> is the target of a <code>@iri</code> coercion,
-          set the <tref>active object</tref> by
-          performing <a href="#iri-expansion">IRI Expansion</a> on the string.
-        </li>
-        <li>
-          Otherwise, if the <tref>active property</tref> is the target of coercion,
-          set the <tref>active object</tref> by creating a <tref>typed literal</tref> using
-          the string and the coercion key as the datatype IRI.
-        </li>
-        <li>
-          Otherwise, set the <tref>active object</tref> to a <tref>plain literal</tref> value created from
-          the string.
-        </li>
-      </ol>
-      Generate a
-      triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
-      <tref>active object</tref>.
-    </li>
-
-    <li>
-      If a <tref>number</tref> is detected, generate a <tref>typed literal</tref> using a string representation of
-      the value with datatype set to either <code>xsd:integer</code> or
-      <code>xsd:double</code>, depending on if the value contains a
-      fractional and/or an exponential component. Generate a triple using the <tref>active
-      subject</tref>, <tref>active property</tref> and the generated typed literal.
-    </li>
-
-    <li>
-      Otherwise, if <strong>true</strong> or <strong>false</strong> is detected,
-      generate a triple using the <tref>active subject</tref>, <tref>active property</tref>
-      and a <tref>typed literal</tref> value created from the string representation of the
-      value with datatype set to <code>xsd:boolean</code>.
-    </li>
-  </ol>
-</section>
-
-<!-- THIS SHOULD BE SPLIT OUT INTO A SEPARATE DOCUMENT
-
-<section>
-<h1>Best Practices</h1>
-
-<p>The nature of Web programming allows one to use basic technologies, such as
-JSON-LD, across a variety of systems and environments. This section attempts to
-describe some of those environments and the way in which JSON-LD can be
-integrated in order to help alleviate certain development headaches.
-</p>
-
-<section>
-<h2>JavaScript</h2>
-
-<p class="issue">It is expected that JSON-LD will be used quite a bit in
-JavaScript environments, however, features like the expanded form for
-object values mean that using JSON-LD directly in JavaScript may be
-annoying without a middleware layer such as a simple library that
-converts JSON-LD markup before JavaScript uses it. One could say that JSON-LD
-is a good fit for the RDF API, which enables a variety of RDF-based
-Web Applications, but some don't want to require that level of functionality
-just to use JSON-LD. The group is still discussing the best way to proceed,
-so input on how JSON-LD could more easily be utilized in JavaScript
-environments would be very much appreciated.
-</p>
-</section>
-
-<section>
-<h2>Schema-less Databases</h2>
-
-<p class="issue">Databases such as CouchDB and MongoDB allow the creation of
-schema-less data stores. RDF is a type of schema-less data model and thus
-lends itself to databases such as CouchDB and MongoDB. Both of these databases
-can use JSON-LD as their storage format. The group needs feedback from
-CouchDB and MongoDB experts regarding the usefulness of JSON-LD in those
-environments.</p>
-
-<p class="issue">MongoDB does not allow the '.' character to be used in
-key names. This prevents developers from storing IRIs as keys, which also
-prevents storage of the data in normalized form. While this issue can
-be avoided by using <tref>prefix</tref>es for key values, it is not known if this
-mechanism is enough to allow JSON-LD to be used in MongoDB in a way that
-is useful to developers.
-</p>
-
--->
-</section>
-
-</section>
-
-<section class="appendix">
-<h1>Experimental Concepts</h1>
-
-<p class="issue">There are a few advanced concepts where it is not clear
-whether or not the JSON-LD specification is going to support the complexity
-necessary to support each concept. The entire section on Advanced Concepts
-should be considered as discussion points; it is merely a list of
-possibilities where all of the benefits and drawbacks have not been explored.
-</p>
-
-<section>
-<h2>Disjoint Graphs</h2>
-
-<p>When serializing an RDF graph that contains two or more sections of the
-graph which are entirely disjoint, one must use an <tref>array</tref> to express the graph
-as two graphs. This may not be acceptable to some authors, who would rather
-express the information as one graph. Since, by definition, disjoint graphs
-require there to be two top-level objects, JSON-LD utilizes a mechanism that
-allows disjoint graphs to be expressed using a single graph.</p>
-
-<p>Assume the following RDF graph:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<http://example.org/people#john>
-   <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
-      <http://xmlns.com/foaf/0.1/Person> .
-<http://example.org/people#jane>
-   <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
-      <http://xmlns.com/foaf/0.1/Person> .
--->
-</pre>
-
-<p>Since the two subjects are entirely disjoint with one another, it is
-impossible to express the RDF graph above using a single <tref>JSON object</tref>.</p>
-
-<p>In JSON-LD, one can use the subject to express disjoint graphs as a
-single graph:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context": {
-    "Person": "http://xmlns.com/foaf/0.1/Person"
-  },
-  "@subject":
-  [
-    {
-      "@subject": "http://example.org/people#john",
-      "@type": "Person"
-    },
-    {
-      "@subject": "http://example.org/people#jane",
-      "@type": "Person"
-    }
-  ]
-}
--->
-</pre>
-
-<p>A disjoint graph could also be expressed like so:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-[
-  {
-    "@subject": "http://example.org/people#john",
-    "@type": "http://xmlns.com/foaf/0.1/Person"
-  },
-  {
-    "@subject": "http://example.org/people#jane",
-    "@type": "http://xmlns.com/foaf/0.1/Person"
-  }
-]
--->
-</pre>
-
-<p class="note">Warning: Using this serialisation format it is impossible to include <code>@context</code>
-  given that the document's data structure is an array and not an object.</p>
-
-</section>
-
-<section>
-  <h2>Lists</h2>
-  <p>
-    Because graphs do not describe ordering for links between nodes,  in contrast to plain JSON, multi-valued properties
-    in JSON-LD do not provide an ordering of the listed objects. For example, consider the following
-    simple document:
-  </p>
-  <pre class="example" data-transform="updateExample">
-  <!--
-  {
-  ...
-    "@subject": "http://example.org/people#joebob",
-    "nick": ****["joe", "bob", "jaybee"]****,
-  ...
-  }
-  -->
-  </pre>
-  <p>
-    This results in three triples being generated, each relating the subject to an individual
-    object, with no inherent order.</p>
-  <p>To preserve the order of the objects, RDF-based languages, such as [[TURTLE]]
-    use the concept of an <code>rdf:List</code> (as described in [[RDF-SCHEMA]]). This uses a sequence
-    of unlabeled nodes with properties describing a value, a null-terminated next property. Without
-    specific syntactical support, this could be represented in JSON-LD as follows:
-  </p>
-  <pre class="example" data-transform="updateExample">
-  <!--
-  {
-  ...
-    "@subject": "http://example.org/people#joebob",
-    "nick": ****{****,
-      ****"@first": "joe"****,
-      ****"@rest": {****
-        ****"@first": "bob"****,
-        ****"@rest": {****
-          ****"@first": "jaybee"****,
-          ****"@rest": "@nil"****
-          ****}****
-        ****}****
-      ****}****
-    ****}****,
-  ...
-  }
-  -->
-  </pre>
-  <p>
-    As this notation is rather unwieldy and the notion of ordered collections is rather important
-    in data modeling, it is useful to have specific language support. In JSON-LD, a list may
-    be represented using the <code>@list</code> keyword as follows:
-  </p>
-  <pre class="example" data-transform="updateExample">
-  <!--
-  {
-  ...
-    "@subject": "http://example.org/people#joebob",
-    "foaf:nick": ****{"@list": ["joe", "bob", "jaybee"]}****,
-  ...
-  }
-  -->
-  </pre>
-  <p>
-    This describes the use of this <tref>array</tref> as being ordered, and order is maintained through
-    normalization and RDF conversion. If every use of a given multi-valued property is a
-    list, this may be abbreviated by adding an <code>@coerce</code> term:
-  </p>
-  <pre class="example" data-transform="updateExample">
-  <!--
-  {
-    ****"@context": {****
-      ...
-      ****"@coerce": {****
-        ****"@list": ["foaf:nick"]****
-      ****}****
-    ****}****,
-  ...
-    "@subject": "http://example.org/people#joebob",
-    "foaf:nick": ****["joe", "bob", "jaybee"]****,
-  ...
-  }
-  -->
-  </pre>
-  <p class="issue">There is an ongoing discussion about this issue. One of the <a href="https://github.com/json-ld/json-ld.org/issues/12">proposed solutions</a> is allowing to change the default behaviour so that arrays are considered as ordered lists by default.</p>
-  <section><h3 id="list-expansion">Expansion</h3>
-    <p class="issue">TBD.</p>
-  </section>
-  <section><h3 id="list-normalization">Normalization</h3>
-    <p class="issue">TBD.</p>
-  </section>
-  <section><h3 id="list-rdf">RDF Conversion</h3>
-    <p>
-      To support RDF Conversion of lists, <a href="#rdf-conversion-algorithm">RDF Conversion Algorithm</a>
-      is updated as follows:
-    </p>
-    <ol class="algorithm update">
-      <li>
-        <span class="list-number">2.4a.</span>
-        If the <tref>JSON object</tref> has a <code>@list</code> key and the value is an <tref>array</tref>
-        process the value as a list starting at <a href="#processing-step-list">Step 3a</a>.
-      </li>
-      <li>
-        <span class="list-number">2.7.3.</span>
-        Create a new <tref>processor state</tref> copies of the <tref>active context</tref>,
-        <tref>active subject</tref> and <tref>active property</tref>.
-        <ol class="algorithm">
-          <li>
-            If the <tref>active property</tref> is the target of a <code>@list</code> coercion,
-            and the value is an <tref>array</tref>,
-            process the value as a list starting at <a href="#processing-step-list">Step 3a</a>.
-          </li>
-          <li>
-            Otherwise, process the value starting at
-            <a href="#processing-step-associative">Step 2</a>.
-          </li>
-          <li>Proceed using the previous <tref>processor state</tref>.</li>
-        </ol>
-      </li>
-      <li id="processing-step-list">
-        <span class="list-number">3a.</span>
-        Generate an RDF List by linking
-        each element of the list using <code>rdf:first</code> and <code>rdf:next</code>, terminating the list with <code>rdf:nil</code>
-        using the following sequence:
-        <ol class="algorithm">
-          <li>
-            If the list has no element, generate a triple using the <tref>active subject</tref>, <tref>active property</tref>
-            and <code>rdf:nil</code>.
-          </li>
-          <li>
-            Otherwise, generate a triple using using the <tref>active subject</tref>, <tref>active property</tref>
-            and a newly generated BNode identified as <em>first <tdef>blank node identifier</tdef></em>.
-          </li>
-          <li>
-            For each element other than the last element in the list:
-            <ol class="algorithm">
-              <li>Create a processor state using the active context, <em>first <tdef>blank node identifier</tdef></em> as the <tref>active subject</tref>, and <code>rdf:first</code> as the <tref>active property</tref>.</li>
-              <li>Unless this is the last element in the list, generate a new BNode identified as <em>rest <tdef>blank node identifier</tdef></em>, otherwise use <code>rdf:nil</code>.</li>
-              <li>Generate a new triple using <em>first <tdef>blank node identifier</tdef></em>, <code>rdf:rest</code> and <em>rest <tdef>blank node identifier</tdef></em>.</li>
-              <li>Set <em>first <tdef>blank node identifier</tdef></em> to <em>rest <tdef>blank node identifier</tdef></em>.</li>
-            </ol>
-          </li>
-        </ol>
-      </li>
-    </ol>
-  </section>
-</section>
-
-</section>
-
-<section class="appendix">
-<h2>Markup Examples</h2>
-
-<p>The JSON-LD markup examples below demonstrate how JSON-LD can be used to
-express semantic data marked up in other languages such as RDFa, Microformats,
-and Microdata. These sections are merely provided as proof that JSON-LD is
-very flexible in what it can express across different Linked Data approaches.
-</p>
-
-<section>
-<h3>RDFa</h3>
-
-<p>The following example describes three people with their respective names and
-homepages.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<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>
-      </li>
-      <li ****typeof="foaf:Person"****>
-        <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>
-      </li>
-   </ul>
-</div>
--->
-</pre>
-
-<p>An example JSON-LD implementation is described below, however, there are
-other ways to mark-up this information such that the context is not
-repeated.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context": { "foaf": "http://xmlns.com/foaf/0.1/"},
-  "@subject": [
-   {
-     "@subject": "_:bnode1",
-     "@type": "foaf:Person",
-     "foaf:homepage": "http://example.com/bob/",
-     "foaf:name": "Bob"
-   },
-   {
-     "@subject": "_:bnode2",
-     "@type": "foaf:Person",
-     "foaf:homepage": "http://example.com/eve/",
-     "foaf:name": "Eve"
-   },
-   {
-     "@subject": "_:bnode3",
-     "@type": "foaf:Person",
-     "foaf:homepage": "http://example.com/manu/",
-     "foaf:name": "Manu"
-   }
-  ]
-}
--->
-</pre>
-
-</section>
-
-<section>
-<h3>Microformats</h3>
-
-<p>The following example uses a simple Microformats hCard example to express
-how the Microformat is represented in JSON-LD.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<div class="vcard">
- <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
-</div>
--->
-</pre>
-
-<p>The representation of the hCard expresses the Microformat terms in the
-context and uses them directly for the <code>url</code> and <code>fn</code>
-properties. Also note that the Microformat to JSON-LD processor has
-generated the proper URL type for <code>http://tantek.com</code>.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "@context":
-  {
-    "vcard": "http://microformats.org/profile/hcard#vcard",
-    "url": "http://microformats.org/profile/hcard#url",
-    "fn": "http://microformats.org/profile/hcard#fn",
-    "@coerce": { "@iri": "url" }
-  },
-  "@subject": "_:bnode1",
-  "@type": "vcard",
-  "url": "http://tantek.com/",
-  "fn": "Tantek Çelik"
-}
--->
-</pre>
-
-</section>
-
-<section>
-<h3>Microdata</h3>
-
-<p>The Microdata example below expresses book information as a Microdata Work
-item.
-</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-<dl itemscope
-    itemtype="http://purl.org/vocab/frbr/core#Work"
-    itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N">
- <dt>Title</dt>
- <dd><cite itemprop="http://purl.org/dc/terms/title">Just a Geek</cite></dd>
- <dt>By</dt>
- <dd><span itemprop="http://purl.org/dc/terms/creator">Wil Wheaton</span></dd>
- <dt>Format</dt>
- <dd itemprop="http://purl.org/vocab/frbr/core#realization"
-     itemscope
-     itemtype="http://purl.org/vocab/frbr/core#Expression"
-     itemid="http://purl.oreilly.com/products/9780596007683.BOOK">
-  <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK">
-  Print
- </dd>
- <dd itemprop="http://purl.org/vocab/frbr/core#realization"
-     itemscope
-     itemtype="http://purl.org/vocab/frbr/core#Expression"
-     itemid="http://purl.oreilly.com/products/9780596802189.EBOOK">
-  <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK">
-  Ebook
- </dd>
-</dl>
--->
-</pre>
-
-<p>Note that the JSON-LD representation of the Microdata information stays
-true to the desires of the Microdata community to avoid contexts and
-instead refer to items by their full IRI.</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-[
-  {
-    "@subject": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
-    "@type": "http://purl.org/vocab/frbr/core#Work",
-    "http://purl.org/dc/terms/title": "Just a Geek",
-    "http://purl.org/dc/terms/creator": "Whil Wheaton",
-    "http://purl.org/vocab/frbr/core#realization":
-      ["http://purl.oreilly.com/products/9780596007683.BOOK", "http://purl.oreilly.com/products/9780596802189.EBOOK"]
-  },
-  {
-    "@subject": "http://purl.oreilly.com/products/9780596007683.BOOK",
-    "@type": "http://purl.org/vocab/frbr/core#Expression",
-    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/BOOK"
-  },
-  {
-    "@subject": "http://purl.oreilly.com/products/9780596802189.EBOOK",
-    "@type": "http://purl.org/vocab/frbr/core#Expression",
-    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
-  }
-]
--->
-</pre>
-</section>
-</section>
-
-<section class="appendix">
-<h3>Mashing Up Vocabularies</h3>
-
-<p>Developers would also benefit by allowing other vocabularies to be used
-automatically with their JSON API. There are over 200
-<tref>Web Vocabulary</tref> Documents that are available for use on the Web
-today. Some of these vocabularies are:
-</p>
-
-<ul>
-   <li>RDF - for describing information about objects and concepts on the Web.</li>
-   <li>RDFS - for expressing things like labels and comments.</li>
-   <li>XSD - for specifying basic types like strings, integers, dates and times.</li>
-   <li>Dublin Core - for describing creative works.</li>
-   <li>FOAF - for describing social networks.</li>
-   <li>Calendar - for specifying events.</li>
-   <li>SIOC - for describing discussions on blogs and websites.</li>
-   <li>CCrel - for describing Creative Commons and other types of licenses.</li>
-   <li>GEO - for describing geographic location.</li>
-   <li>VCard - for describing organizations and people.</li>
-   <li>DOAP - for describing projects.</li>
-</ul>
-
-<p>You can use these vocabularies in combination, like so:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  "****@type****": "****foaf:Person****",
-  "****foaf:name****": "Manu Sporny",
-  "****foaf:homepage****": "http://manu.sporny.org/",
-  "****sioc:avatar****": "http://twitter.com/account/profile_image/manusporny"
-}
--->
-</pre>
-
-<p>Developers can also specify their own Vocabulary documents by modifying the
-<tref>active context</tref> in-line using the <code>@context</code> keyword,
-like so:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-  ****"@context": { "myvocab": "http://example.org/myvocab#" }****,
-  "@type": "foaf:Person",
-  "foaf:name": "Manu Sporny",
-  "foaf:homepage": "http://manu.sporny.org/",
-  "sioc:avatar": "http://twitter.com/account/profile_image/manusporny"****,
-  "myvocab:personality": "friendly"****
-}
-
--->
-</pre>
-
-<p>The <code>@context</code> keyword is used to change how the JSON-LD
-processor evaluates key-value pairs. In this case, it was used to
-map one string ('myvocab') to another string, which is interpreted as
-a <tref>IRI</tref>. In the example above, the <code>myvocab</code> string is replaced
-with "<code>http://example.org/myvocab#</code>" when it
-is detected. In the example above, "<code>myvocab:personality</code>" would
-expand to "<code>http://example.org/myvocab#personality</code>".</p>
-
-<p>This mechanism is a short-hand, called a <tref>Web Vocabulary</tref> <tref>prefix</tref>,
-and provides developers an unambiguous way to map any JSON value to RDF.<p>
-
-</section>
-
-<section class="appendix">
-<h1>IANA Considerations</h1>
-
-<p>This section is included merely for standards community review and will be
-submitted to the Internet Engineering Steering Group if this specification
-becomes a W3C Recommendation.</p>
-
-<dl>
-  <dt>Type name:</dt>
-  <dd>application</dd>
-  <dt>Subtype name:</dt>
-  <dd>ld+json</dd>
-  <dt>Required parameters:</dt>
-  <dd>None</dd>
-  <dt>Optional parameters:</dt>
-  <dd>
-    <dl>
-      <dt><code>form</code></dt>
-      <dd>Determines the serialization form for the JSON-LD document. Valid
-        values include; <code>compacted</code>, <code>expanded</code>,
-        <code>framed</code>, and <code>normalized</code>. Other values are
-        allowed, but must be pre-pended with a <code>x-</code> string until
-        they are clearly defined by a stable specification. If no form
-        is specified in an HTTP request header to a responding application,
-        such as a Web server, the application MAY choose any form. If no
-        form is specified for a receiving application, the form MUST NOT
-        be assumed to take any particular form.</dd>
-      <div class="issue">It is currently <a href="https://github.com/json-ld/json-ld.org/issues/14"> being discussed to remove form=framed</a> from this specification as there are several issues with it.</div>
-    </dl>
-  </dd>
-  <dt>Encoding considerations:</dt>
-  <dd>The same as the <code>application/json</code> MIME media type.</dd>
-  <dt>Security considerations:</dt>
-  <dd>Since JSON-LD is intended to be a pure data exchange format for
-    directed graphs, the serialization SHOULD NOT be passed through a
-    code execution mechanism such as JavaScript's <code>eval()</code>
-    function. It is RECOMMENDED that a conforming parser does not attempt to
-    directly evaluate the JSON-LD serialization and instead purely parse the
-    input into a language-native data structure. </dd>
-  <dt>Interoperability considerations:</dt>
-  <dd>Not Applicable</dd>
-  <dt>Published specification:</dt>
-  <dd>The <a href="http://json-ld/spec/latest/">JSON-LD</a> specification.</dd>
-  <dt>Applications that use this media type:</dt>
-  <dd>Any programming environment that requires the exchange of
-    directed graphs. Implementations of JSON-LD have been created for
-    JavaScript, Python, Ruby, PHP and C++.
-  </dd>
-  <dt>Additional information:</dt>
-  <dd>
-    <dl>
-      <dt>Magic number(s):</dt>
-      <dd>Not Applicable</dd>
-      <dt>File extension(s):</dt>
-      <dd>.jsonld</dd>
-      <dt>Macintosh file type code(s):</dt>
-      <dd>TEXT</dd>
-    </dl>
-  </dd>
-  <dt>Person &amp; email address to contact for further information:</dt>
-  <dd>Manu Sporny &lt;[email protected]&gt;</dd>
-  <dt>Intended usage:</dt>
-  <dd>Common</dd>
-  <dt>Restrictions on usage:</dt>
-  <dd>None</dd>
-  <dt>Author(s):</dt>
-  <dd>Manu Sporny, Gregg Kellogg, Dave Longley</dd>
-  <dt>Change controller:</dt>
-  <dd>W3C</dd>
-</dl>
-
-</section>
-
-<section class="appendix">
-<h1>Acknowledgements</h1>
-
-<p>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,
-Dave Longley, Dave Lehn and Mike Johnson who reviewed, provided feedback, and
-performed several implementations of the specification, and Ian Davis, who
-created RDF/JSON. Thanks also to Nathan Rixham, Bradley P. Allen,
-Kingsley Idehen, Glenn McDonald, Alexandre Passant, Danny Ayers, Ted
-Thibodeau Jr., Olivier Grisel, Niklas Lindström, Markus Lanthaler, and Richard
-Cyganiak for their input on the specification. Another huge thank you goes out
-to Dave Longley who designed many of the algorithms used in this specification,
-including the normalization algorithm which was a monumentally difficult
-design challenge.
-</p>
-</section>
-
-</body>
-</html>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/spec/latest/json-ld-syntax/index.html	Sat Oct 15 19:56:40 2011 -0400
@@ -0,0 +1,4334 @@
+<!DOCTYPE html>
+<html>
+<head>
+<title>JSON-LD 1.0</title>
+<meta http-equiv="content-type" content="text/html; charset=UTF-8">
+<!--
+  === NOTA BENE ===
+  For the three scripts below, if your spec resides on dev.w3 you can check them
+  out in the same tree and use relative links so that they'll work offline,
+  -->
+<script type="text/javascript"
+  src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove">
+ </script>
+<script type="text/javascript" class="remove">
+
+    var preProc = {
+          apply:  function(c) {
+                    // extend the bibliography entries
+                    berjon.biblio["MICRODATA"] = "Ian Hickson; et al. <a href=\"http://www.w3.org/TR/microdata/\"><cite>Microdata</cite></a> 04 March 2010. W3C Working Draft. URL: <a href=\"http://www.w3.org/TR/microdata/\">http://www.w3.org/TR/microdata/</a> ";
+                    berjon.biblio["HTML-RDFA"] = "Manu Sporny; et al. <a href=\"http://www.w3.org/TR/rdfa-in-html/\"><cite>HTML+RDFa</cite></a> 04 March 2010. W3C Working Draft. URL: <a href=\"http://www.w3.org/TR/rdfa-in-html/\">http://www.w3.org/TR/rdfa-in-html/</a> ";
+                    berjon.biblio["BCP47"] = "A. Phillips, M. Davis. <a href=\"http://tools.ietf.org/rfc/bcp/bcp47.txt\"><cite>Tags for Identifying Languages</cite></a> September 2009. IETF Best Current Practice. URL: <a href=\"http://tools.ietf.org/rfc/bcp/bcp47.txt\">http://tools.ietf.org/rfc/bcp/bcp47.txt</a>";
+                    berjon.biblio["RDF-API"] = "Manu Sporny, Benjamin Adrian, Nathan Rixham; et al. <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-api/\"><cite>RDF API</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-api/\">http://www.w3.org/2010/02/rdfa/sources/rdf-api/</a>";
+                    berjon.biblio["RDF-INTERFACES"] = "Nathan Rixham, Manu Sporny, Benjamin Adrian; et al. <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/\"><cite>RDF Interfaces</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/\">http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/</a>";
+
+                    // process the document before anything else is done
+                    var refs = document.querySelectorAll('adef') ;
+                    for (var i = 0; i < refs.length; i++) {
+                        var item = refs[i];
+                        var p = item.parentNode ;
+                        var con = item.innerHTML ;
+                        var sp = document.createElement( 'dfn' ) ;
+                        var tit = item.getAttribute('title') ;
+                        if (!tit) {
+                            tit = con;
+                        }
+                        sp.className = 'adef' ;
+                        sp.title=tit ;
+                        sp.innerHTML = con ;
+                        p.replaceChild(sp, item) ;
+                    }
+                    refs = document.querySelectorAll('aref') ;
+                    for (var i = 0; i < refs.length; i++) {
+                        var item = refs[i];
+                        var p = item.parentNode ;
+                        var con = item.innerHTML ;
+                        var sp = document.createElement( 'a' ) ;
+                        sp.className = 'aref' ;
+                        sp.setAttribute('title', con);
+                        sp.innerHTML = '@'+con ;
+                        p.replaceChild(sp, item) ;
+                    }
+                    // local datatype references
+                    refs = document.querySelectorAll('ldtref') ;
+                    for (var i = 0; i < refs.length; i++) {
+                        var item = refs[i];
+                        if (!item) continue ;
+                        var p = item.parentNode ;
+                        var con = item.innerHTML ;
+                        var ref = item.getAttribute('title') ;
+                        if (!ref) {
+                            ref = item.textContent ;
+                        }
+                        if (ref) {
+                            ref = ref.replace(/\n/g, '_') ;
+                            ref = ref.replace(/\s+/g, '_') ;
+                        }
+                        var sp = document.createElement( 'a' ) ;
+                        sp.className = 'datatype';
+                        sp.title = ref ;
+                        sp.innerHTML = con ;
+                        p.replaceChild(sp, item) ;
+                    }
+                    // external datatype references
+                    refs = document.querySelectorAll('dtref') ;
+                    for (var i = 0; i < refs.length; i++) {
+                        var item = refs[i];
+                        if (!item) continue ;
+                        var p = item.parentNode ;
+                        var con = item.innerHTML ;
+                        var ref = item.getAttribute('title') ;
+                        if (!ref) {
+                            ref = item.textContent ;
+                        }
+                        if (ref) {
+                            ref = ref.replace(/\n/g, '_') ;
+                            ref = ref.replace(/\s+/g, '_') ;
+                        }
+                        var sp = document.createElement( 'a' ) ;
+                        sp.className = 'externalDFN';
+                        sp.title = ref ;
+                        sp.innerHTML = con ;
+                        p.replaceChild(sp, item) ;
+                    }
+                    // now do terms
+                    refs = document.querySelectorAll('tdef') ;
+                    for (var i = 0; i < refs.length; i++) {
+                        var item = refs[i];
+                        if (!item) continue ;
+                        var p = item.parentNode ;
+                        var con = item.innerHTML ;
+                        var ref = item.getAttribute('title') ;
+                        if (!ref) {
+                            ref = item.textContent ;
+                        }
+                        if (ref) {
+                            ref = ref.replace(/\n/g, '_') ;
+                            ref = ref.replace(/\s+/g, '_') ;
+                        }
+                        var sp = document.createElement( 'dfn' ) ;
+                        sp.title = ref ;
+                        sp.innerHTML = con ;
+                        p.replaceChild(sp, item) ;
+                    }
+                    // now term references
+                    refs = document.querySelectorAll('tref') ;
+                    for (var i = 0; i < refs.length; i++) {
+                        var item = refs[i];
+                        if (!item) continue ;
+                        var p = item.parentNode ;
+                        var con = item.innerHTML ;
+                        var ref = item.getAttribute('title') ;
+                        if (!ref) {
+                            ref = item.textContent ;
+                        }
+                        if (ref) {
+                            ref = ref.replace(/\n/g, '_') ;
+                            ref = ref.replace(/\s+/g, '_') ;
+                        }
+
+                        var sp = document.createElement( 'a' ) ;
+                        var id = item.textContent ;
+                        sp.className = 'tref' ;
+                        sp.title = ref ;
+                        sp.innerHTML = con ;
+                        p.replaceChild(sp, item) ;
+                    }
+                }
+        } ;
+
+
+      var respecConfig = {
+          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+          specStatus:           "unofficial",
+          //publishDate:          "2010-04-29",
+          copyrightStart:       "2010",
+
+          // the specification's short name, as in http://www.w3.org/TR/short-name/
+          shortName:            "json-ld",
+          subtitle:             "A Context-based JSON Serialization for Linking Data",
+          // if you wish the publication date to be other than today, set this
+          // publishDate:  "2009-08-06",
+
+          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+          // and its maturity status
+          previousPublishDate:  "2011-08-17",
+          previousMaturity:     "ED",
+          previousDiffURI:      "http://json-ld.org/spec/ED/20110817/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://json-ld.org/spec/latest/",
+
+          // if this is a LCWD, uncomment and set the end of its review period
+          // lcEnd: "2009-08-05",
+
+          // if you want to have extra CSS, append them to this list
+          // it is recommended that the respec.css stylesheet be kept
+          extraCSS:             [
+              "http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css",
+              "spec.css"
+          ],
+
+          // editors, add as many as you like
+          // only "name" is required
+          editors:  [
+              { name: "Manu Sporny", url: "http://manu.sporny.org/",
+                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
+              { name: "Gregg Kellogg", url: "http://greggkellogg.net/",
+                company: "Kellogg Associates" },
+              { name: "Dave Longley", url: "http://digitalbazaar.com/",
+                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"}
+          ],
+
+          // authors, add as many as you like.
+          // This is optional, uncomment if you have authors as well as editors.
+          // only "name" is required. Same format as editors.
+
+          authors:  [
+              { name: "Manu Sporny", url: "http://digitalbazaar.com/",
+                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
+              { name: "Gregg Kellogg", url: "http://greggkellogg.net/",
+                company: "Kellogg Associates" },
+              { name: "Dave Longley", url: "http://digitalbazaar.com/",
+                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"},
+              { name: "Mark Birbeck", url: "http://webbackplane.com/",
+                company: "Backplane Ltd.", companyURL: "http://webbackplane.com/" },
+          ],
+
+          // name of the WG
+          wg:           "Linking Data in JSON Community Group",
+
+          // URI of the public WG page
+          wgURI:        "http://json-ld.org/",
+
+          // name (with the @w3c.org) of the public mailing to which comments are due
+          wgPublicList: "[email protected]",
+
+          // URI of the patent status for this WG, for Rec-track documents
+          // !!!! IMPORTANT !!!!
+          // This is important for Rec-track documents, do not copy a patent URI from a random
+          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+          // Team Contact.
+          wgPatentURI:  "",
+          maxTocLevel: 4,
+          preProcess: [ preProc ],
+          alternateFormats: [ {uri: "diff-20110817.html", label: "diff to previous version"} ],
+      };
+
+      function updateExample(doc, content) {
+        // perform transformations to make it render and prettier
+        content = content.replace(/<!--/, '');
+        content = content.replace(/-->/, '');
+        content = doc._esc(content);
+        content = content.replace(/\*\*\*\*([^*]*)\*\*\*\*/g, '<span class="diff">$1</span>') ;
+        return content ;
+      }
+
+      function updateDTD(doc, content) {
+        // perform transformations to
+        // make it render and prettier
+        content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
+        content = content.replace(/!ENTITY % ([^ \t\r\n]*)/g, '!ENTITY <span class="entity">% $1</span>');
+        content = content.replace(/!ELEMENT ([^ \t$]*)/mg, '!ELEMENT <span class="element">$1</span>');
+        return content;
+      }
+
+      function updateSchema(doc, content) {
+        // perform transformations to
+        // make it render and prettier
+        content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
+        content = content.replace(/&lt;xs:element\s+name=&quot;([^&]*)&quot;/g, '&lt;xs:element name="<span class="element" id="schema_element_$1">$1</span>"') ;
+        return content;
+      }
+
+      function updateTTL(doc, content) {
+        // perform transformations to
+        // make it render and prettier
+        content = '<pre class="sh_sourceCode">' + doc._esc(content) + '</pre>';
+        content = content.replace(/@prefix/g, '<span class="sh_keyword">@prefix</span>');
+        return content;
+      }
+  </script>
+<style>
+.diff { font-weight:bold; color:#0a3; }
+ol.algorithm.update { margin-left: 2em; }
+ol.algorithm.update>li { list-style-type: none; }
+ol.algorithm.update>li>span.list-number {
+  display:block;
+  float: left;
+  margin-left: -3.5em;
+}
+</style>
+</head>
+
+<body>
+<section id="abstract">
+<p>
+JSON [[!RFC4627]] has proven to be a highly useful object serialization and
+messaging format. In an attempt to harmonize the representation of Linked Data
+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 is an experimental work in progress.</p>
+<!-- <p>
+This document has been reviewed by W3C Members, by software
+developers, and by other W3C groups and interested parties, and is
+endorsed by the Director as a W3C Recommendation. It is a stable
+document and may be used as reference material or cited from another
+document. W3C's role in making the Recommendation is to draw attention
+to the specification and to promote its widespread deployment. This
+enhances the functionality and interoperability of the Web.
+</p> -->
+</section>
+
+<section>
+<h1>Introduction</h1>
+
+<p>
+JSON, as specified in [[!RFC4627]], is a simple language for representing
+data on the Web. Linked Data is a technique for creating a graph of interlinked data across
+different
+documents or Web sites. Data entities are described using <tref>IRI</tref>s,
+which are typically dereferencable and thus may be used to find more
+information about an entity, creating a "Web of Knowledge". JSON-LD is intended to be a simple
+publishing method for expressing not only Linked Data in JSON, but also for adding
+semantics to existing JSON.
+</p>
+
+<p>
+JSON-LD is designed as a light-weight syntax that can be used to express
+Linked Data. It is primarily intended to be a way to use Linked Data
+in Javascript and other Web-based programming environments. It is also
+useful when building interoperable Web services and when storing Linked
+Data in JSON-based document storage engines. It is practical and designed
+to be as simple as possible, utilizing the large number of JSON parsers
+and libraries available today. It is designed to be able to
+express key-value pairs, RDF data, RDFa [[RDFA-CORE]] data, Microformats
+[[MICROFORMATS]] data, and Microdata [[MICRODATA]]. That is, it supports
+every major Web-based structured data model in use today.
+</p>
+
+<p>
+The syntax does not necessarily require applications to change their JSON, but
+allows to easily add meaning by adding context in a way that is either in-band or
+out-of-band. The syntax is designed to not disturb already deployed systems
+running on JSON, but provide a smooth upgrade path from JSON to JSON with
+added semantics. Finally, the format is intended to be easy to parse, efficient to
+generate, convertible to RDF in one pass, and require a very small memory footprint
+in order to operate.
+</p>
+
+<section>
+<h2>How to Read this Document</h2>
+
+<p>
+This document is a detailed specification for a serialization of Linked
+Data in JSON. The document is primarily intended for the following audiences:
+</p>
+
+<ul>
+  <li>Web developers that want to understand the design decisions and
+  language syntax for JSON-LD.</li>
+  <li>Software developers that want to encode Microformats, RDFa, or Microdata
+  in a way that is cross-language compatible via JSON.</li>
+  <li>Software developers that want to implement processors and APIs for
+  JSON-LD.</li>
+</ul>
+
+<p>
+To understand the basics in this specification you must first be familiar with
+JSON, which is detailed in [[!RFC4627]]. To understand the API and how it is
+intended to operate  in a programming environment, it is useful to have working
+knowledge of the JavaScript programming language [[ECMA-262]] and
+WebIDL [[!WEBIDL]]. To understand how JSON-LD maps to RDF, it is helpful to be
+familiar with the basic RDF concepts [[!RDF-CONCEPTS]].</p>
+
+<p>
+  Examples may contain references to existing vocabularies and use <tref>prefix</tref>es to refer to Web Vocabularies. The following is a list of all vocabularies and their <tref>prefix</tref> abbreviations, as used in this document:
+</p>
+<ul>
+  <li>The <a href="http://purl.org/dc/terms/">Dublin Core</a>
+  vocabulary (abbreviation: <code>dc</code>, e.g., <code>dc:title</code>)</li>
+  <li>The <a href="http://xmlns.com/foaf/0.1/">Friend of a Friend</a>
+  vocabulary (abbreviation: <code>foaf</code>, e.g., <code>foaf:knows</code>)</li>
+  <li>The <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">RDF</a>
+  vocabulary (abbreviation: <code>rdf</code>, e.g., <code>rdf:type</code>)</li>
+  <li>The <a href="http://www.w3.org/2001/XMLSchema#">XSD</a>
+  vocabulary (abbreviation: <code>xsd</code>, e.g., <code>xsd:integer</code>)</li>
+</ul>
+
+<p>
+  JSON [[RFC4627]] defines several terms which are used throughout this document:
+  <dl>
+    <dt><tdef>JSON Object</tdef></dt><dd>
+      An object structure is represented as a pair of curly brackets surrounding zero or
+      more name/value pairs (or members). A name is a <tref>string</tref>. A single colon comes after
+      each name, separating the name from the value. A single comma separates a value
+      from a following name. The names within an object SHOULD be unique.
+    </dd>
+    <dt><tdef>array</tdef></dt>
+    <dd>
+      An array is an ordered collection of values. An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas.  Within JSON-LD, array order is not preserved by default, unless
+      specific markup is provided (see <a href="#lists">Lists</a>). This is because the basic data model of JSON-LD
+      is a directed <tref>graph</tref>, which is inherently unordered.
+    </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. A
+      character is represented as a single character string.
+    </dd>
+    <dt><tdef>number</tdef></dt>
+    <dd>
+      A number is 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>
+      Boolean values.
+    </dd>
+    <dt><tdef>null</tdef></dt><dd>
+      The use of the <em>null</em> value is undefined within JSON-LD.
+      <div class="issue">Supporting <em>null</em> in JSON-LD might have a number of advantages and should be evaluated. This is currently an <a href="https://github.com/json-ld/json-ld.org/issues/11">open issue</a>.</div>
+    </dd>
+  </dl>
+</p>
+</section>
+
+<section>
+<h2>Contributing</h2>
+
+<p>There are a number of ways that one may participate in the development of
+this specification:</p>
+
+<ul>
+<li>Technical discussion typically occurs on the public 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 teleconferences</a> are held
+on Tuesdays at 1500UTC on the second and fourth week of each month.
+</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>.</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>
+
+<section>
+<h1>Design</h1>
+
+<p>The following section outlines the design goals and rationale behind the
+JSON-LD markup language.
+</p>
+
+<section>
+<h2>Goals and Rationale</h2>
+
+<p>
+A number of design considerations were explored during the creation of this
+markup language:
+</p>
+
+<dl>
+ <dt>Simplicity</dt>
+ <dd>Developers need only know JSON and three keywords to use the basic
+ functionality in JSON-LD. No extra processors or software libraries are
+ necessary to use JSON-LD in its most basic form. The language attempts to
+ ensure that developers have an easy learning curve.</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 simply 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 as possible effort 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 provides a mechanism that allows developers to specify
+ context in a way that is out-of-band. This allows organizations that have
+ already deployed large JSON-based infrastructure to add meaning to their
+ JSON documents in a way that is not disruptive to their day-to-day operations and is
+ transparent to their current customers. At times, mapping JSON to
+ a graph representation can become difficult. In these instances, rather than
+ having JSON-LD support esoteric markup, we chose not to support the use case
+ and support a simplified syntax instead. So, while Zero Edits is a goal,
+ it is not always possible without adding great complexity to the language.
+ </dd>
+ <dt>One-pass Conversion to RDF</dt>
+ <dd>JSON-LD supports one-pass conversion to RDF with a very small memory footprint.</dd>
+</dl>
+</section>
+
+<section>
+<h2>Linked Data</h2>
+<p>
+The following definition for <tref>Linked Data</tref> is the one that will
+be used for this specification.
+</p>
+<ol>
+  <li><tdef>Linked Data</tdef> is a set of documents, each containing a representation of a linked data graph.</li>
+  <li>A <tdef>linked data graph</tdef> is an unordered labeled directed graph, where nodes are <tref>subject</tref>s or <tref>object</tref>s, and edges are properties.</li>
+  <li>A <tdef>subject</tdef> is any node in a <tref>linked data graph</tref> with at least one outgoing edge.</li>
+  <li>A <tref>subject</tref> SHOULD be labeled with an <tref>IRI</tref> (an Internationalized Resource Identifier as described in [[!RFC3987]]).</li>
+  <li>An <tdef>object</tdef> is a node in a <tref>linked data graph</tref> with at least one incoming edge.</li>
+  <li>An <tref>object</tref> MAY be labeled with an <tref>IRI</tref>.</li>
+  <li>An object MAY be a <tdef>subject</tdef> and <tref>object</tref> at the same time.</li>
+  <li>A <tdef>property</tdef> is an edge of the <tref>linked data graph</tref>.</li>
+  <li>A <tref>property</tref> SHOULD be labeled with an <tref>IRI</tref>.</li>
+  <li>An <tref>IRI</tref> that is a label in a <tref>linked data graph</tref> SHOULD be dereferencable to a <tref>Linked Data</tref> document describing the labeled <tref>subject</tref>, <tref>object</tref> or <tref>property</tref>.</li>
+  <li>A <tdef>literal</tdef> is an <tref>object</tref> with a label that is not an <tref>IRI</tref></li>
+</ol>
+
+<p>
+Note that the definition for <tref>Linked Data</tref> above is silent on the
+topic of unlabeled nodes. Unlabeled nodes are not considered
+<tref>Linked Data</tref>. However, this specification allows for the expression
+of unlabled nodes, as most graph-based data sets on the Web contain a number
+of associated nodes that are not named and thus are not directly
+de-referenceable.
+</p>
+</section>
+
+<section>
+<h2>Linking Data</h2>
+
+<p>
+An Internationalized Resource Identifier
+(<tdef><abbr title="Internationalized Resource Identifier">IRI</abbr></tdef>),
+as described in [[!RFC3987]], is a mechanism for representing unique
+identifiers on the web. In <tref>Linked Data</tref>, an IRI is commonly
+used for expressing a <tref>subject</tref>, a <tref>property</tref> or an
+<tref>object</tref>.
+</p>
+
+<p>JSON-LD defines a mechanism to map JSON terms, i.e., keys and values, to IRIs. This does not mean
+that JSON-LD requires every key or value to be an IRI, but rather ensures that
+keys and values can be mapped to IRIs if the developer desires to transform
+their data into Linked Data. There are a few techniques that can ensure
+that developers will generate good Linked Data for the Web. JSON-LD
+formalizes those techniques.
+</p>
+
+<p>We will be using the following JSON markup as the example for the
+rest of this section:
+</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/",
+  "avatar": "http://twitter.com/account/profile_image/manusporny"
+}
+-->
+</pre>
+</section>
+
+<section>
+<h3>The Context</h3>
+
+<p>In JSON-LD, a context is used to map <tref>term</tref>s, i.e., keys and values
+  in an JSON document, to
+  <tref>IRI</tref>s. A <tdef>term</tdef> is a short word that MAY be expanded
+to an <tref>IRI</tref>. The Web uses IRIs for unambiguous identification. The
+idea is that these <tref>term</tref>s mean 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>term</tref>s to expand to IRIs so that
+developers don't accidentally step on each other's Web Vocabulary terms.
+For example, the term <code>name</code> may map directly to the IRI
+<code>http://xmlns.com/foaf/0.1/name</code>. This allows JSON-LD documents to
+be constructed using the common JSON practice of simple name/value pairs while
+ensuring that the data is useful outside of the page, API or database in which it
+resides.
+</p>
+
+<p>These Linked Data <tref>term</tref>s are typically collected in a context document that would look something like this:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "homepage": "http://xmlns.com/foaf/0.1/homepage",
+    "avatar": "http://xmlns.com/foaf/0.1/avatar"
+}
+-->
+</pre>
+
+<p>This context document can then be used in an JSON-LD document by adding a single line. The JSON markup as shown in the previous section could be changed as follows to link to the context document:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  ****"@context": "http://example.org/json-ld-contexts/person",****
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/",
+  "avatar": "http://twitter.com/account/profile_image/manusporny"
+}
+-->
+</pre>
+
+<p>The addition above transforms 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>avatar</strong>
+terms map to IRIs.
+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 inter-operate on a
+site-by-site basis. Contexts may also contain datatype information
+for certain <tref>term</tref>s as well as other processing instructions for
+the JSON-LD processor.</p>
+<p>Contexts may be specified in-line. This ensures that JSON-LD documents
+can be processed when a JSON-LD processor does not have access to the Web.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  ****"@context": {
+    "name": "http://xmlns.com/foaf/0.1/name",
+    "homepage": "http://xmlns.com/foaf/0.1/homepage",
+    "avatar": "http://xmlns.com/foaf/0.1/avatar"
+  },****
+  "name": "Manu Sporny",
+  "homepage": "http://manu.sporny.org/",
+  "avatar": "http://twitter.com/account/profile_image/manusporny"
+}
+-->
+</pre>
+
+<p>JSON-LD strives to ensure that developers don't have to change the JSON
+  that is going into and being returned from their Web APIs. This means
+  that developers can also specify a context for JSON data in an out-of-band
+  fashion. This is described later in this document. </p>
+
+<p>
+  JSON-LD uses a special type of machine-readable document called a
+  <tdef>Web Vocabulary</tdef> to define <tref>term</tref>s that are then used
+  to describe concepts and "things" in the world.
+  Typically, these Web Vocabulary documents have <tref>prefix</tref>es associated
+  with them and contain a number of <tref>term</tref> declarations. A
+  <tdef>prefix</tdef>, like a <tref>term</tref>, is a short word that expands
+  to a Web Vocabulary base IRI. <tref>Prefix</tref>es are helpful when a developer
+  wants to mix multiple vocabularies together in a context, but does not want
+  to go to the trouble of defining every single term in every single vocabulary.
+  Some Web Vocabularies may have dozens of terms defined. If a developer wants to use
+  3-4 different vocabularies, the number of terms that
+  would have to be declared in a single context could become quite large. To
+  reduce the number of different terms that must be defined, JSON-LD also allows
+  prefixes to be used to compact IRIs.
+<p>
+
+<p>For example, the IRI <code>http://xmlns.com/foaf/0.1/</code>
+specifies a <tref>Web Vocabulary</tref> which may be represented using the
+<code>foaf</code> <tref>prefix</tref>. The <code>foaf</code> Web Vocabulary
+contains a term called <strong>name</strong>. If you join the
+<code>foaf</code> <tref>prefix</tref> with the <strong>name</strong> suffix,
+you can build a compact IRI that will expand out into an absolute IRI for the
+<code>http://xmlns.com/foaf/0.1/name</code> vocabulary term.
+That is, the compact IRI, or short-form, is <code>foaf:name</code> and the
+expanded-form is <code>http://xmlns.com/foaf/0.1/name</code>. This vocabulary
+term is used to specify a person's name.
+</p>
+
+<p>Developers, and machines, are able to use this IRI (plugging it
+directly into a web browser, for instance) to go to the term and get a
+definition of what the term means. Much like we can use <a href="http://wordnet.princeton.edu/">WordNet</a> today to
+see the definition
+of words in the English language. Developers and machines need the same sort of
+definition of terms. IRIs provide a way to ensure that these terms
+are unambiguous.
+</p>
+
+<p>The context provides a collection of vocabulary <tref>term</tref>s and
+<tref>prefix</tref>es that can be used to expand JSON keys and values into
+<tref>IRI</tref>s.</p>
+
+<p class="note">To ensure the best possible performance, it is a best practice to
+put the context 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 context is processed.
+This creates a memory and complexity burden for one-pass processors.</p>
+
+</section>
+
+<section>
+<h3>From JSON to JSON-LD</h3>
+
+<p>If a set of terms such as, <strong>name</strong>, <strong>homepage</strong>,
+and <strong>avatar</strong>,
+are defined in a context, and that context is used to resolve the
+names in JSON objects, machines are able to automatically expand the terms to
+something meaningful and unambiguous, like this:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "****http://xmlns.com/foaf/0.1/name****": "Manu Sporny",
+  "****http://xmlns.com/foaf/0.1/homepage****": "http://manu.sporny.org"
+  "****http://rdfs.org/sioc/ns#avatar****": "http://twitter.com/account/profile_image/manusporny"
+}
+ -->
+</pre>
+
+<p>Doing this allows JSON to be unambiguously machine-readable without
+requiring developers to drastically change their workflow.</p>
+<p class="note">Please note that this JSON-LD document doesn't define the
+subject and will thus result in an unlabeled or blank node.</p>
+
+</section>
+
+</section>
+
+</section>
+
+<section>
+<h1>Basic Concepts</h1>
+
+<p>JSON-LD is designed to ensure that Linked Data concepts can be marked
+up in a way that is simple to understand and author by Web developers. In many
+cases, regular JSON markup can become Linked Data with the simple addition
+of a context. As more JSON-LD features are used, more semantics are added
+to the JSON markup.</p>
+
+<section>
+<h2>IRIs</h2>
+
+<p>Expressing IRIs are fundamental to Linked Data as that is how most
+<tref>subject</tref>s and many <tref>object</tref> are named. IRIs can be
+expressed in a variety of different ways in JSON-LD.</p>
+
+<ol>
+  <li>In general, <tref>term</tref>s in the key position in
+    a <tref>JSON object</tref> that have a mapping to an IRI or another key in the context are
+    expanded to an IRI by JSON-LD processors. There are special rules for
+    processing keys in <code>@context</code> and when dealing with keys that
+    start with the <code>@subject</code> character.</li>
+  <li>An IRI is generated for the value specified using <code>@subject</code>,
+    if it is a <tref>string</tref>.</li>
+  <li>An IRI is generated for the value specified using <code>@type</code>.</li>
+  <li>An IRI is generated for the value specified using the <code>@iri</code>
+    keyword.</li>
+  <li>An IRI is generated when there are <code>@coerce</code> rules in
+    effect for a key named <code>@iri</code>.</li>
+</ol>
+
+<p>IRIs can be expressed directly in the key position like so:
+</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "****http://xmlns.com/foaf/0.1/name****": "Manu Sporny",
+...
+}
+-->
+</pre>
+
+<p>In the example above, the key
+<code>http://xmlns.com/foaf/0.1/name</code> is interpreted as an IRI, as
+opposed to being interpreted as a string.</p>
+
+<p>Term expansion occurs for IRIs if a term is defined within the
+<tref>active context</tref>:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "****@context****": {"****name****": "****http://xmlns.com/foaf/0.1/name****"},
+...
+  "****name****": "Manu Sporny",
+...
+}
+-->
+</pre>
+
+<p><tref>Prefix</tref>es are expanded when used in keys:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "****@context****": {"****foaf****": "****http://xmlns.com/foaf/0.1/****"},
+...
+  "****foaf:name****": "Manu Sporny",
+...
+}
+-->
+</pre>
+
+<p><code>foaf:name</code> above will automatically expand out to the IRI
+<code>http://xmlns.com/foaf/0.1/name</code>.</p>
+
+<p>An IRI is generated when a value is associated with a key using
+the <code>@iri</code> keyword:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "homepage": { "****@iri****": "http://manu.sporny.org" }
+...
+}
+-->
+</pre>
+
+<p>If type coercion rules are specified in the <code>@context</code> for
+a particular vocabulary term, an IRI is generated:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{****
+  "@context":
+  {
+    ...
+    "@coerce":
+    {
+      "@iri": "homepage"
+    }
+  }****
+...
+  "homepage": "http://manu.sporny.org/",
+...
+}
+-->
+</pre>
+
+<p>Even though the value <code>http://manu.sporny.org/</code> is a <tref>string</tref>,
+the type coercion rules will transform the value into an IRI when processed
+by a JSON-LD Processor</p>
+
+</section>
+
+<section>
+<h2>Identifying the Subject</h2>
+
+<p>
+  To be able to externally reference nodes, it is important that each node has an unambiguous identifier.
+  <tref>IRI</tref>s are a fundamental concept of Linked Data, and nodes should have a de-referencable
+  identifier used to name and locate them. For nodes to be truely 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>subject</tref>
+   of an object in JSON is declared using the <code>@subject</code> key. The subject is the
+first piece of information needed by the JSON-LD processor in order to
+create the (subject, property, object) tuple, also known as a triple.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "****@subject****": "****http://example.org/people#joebob****",
+...
+}
+-->
+</pre>
+
+<p>The example above would set the subject to the IRI
+<code>http://example.org/people#joebob</code>.
+</p>
+
+<p class="note">To ensure the best possible performance, it is a best practice to
+put the <code>@subject</code> key before other key-value pairs in an object. If
+it isn't listed first, processors have to save each key-value pair until
+<code>@subject</code> is processed before they can create valid triples. This
+creates a memory and complexity burden for one-pass processors.</p>
+
+</section>
+
+<section>
+<h2>Specifying the Type</h2>
+
+<p>The type of a particular subject can be specified using the
+<code>@type</code> key. Specifying the type in this way will generate a
+triple of the form (subject, type, type-iri).</p>
+
+<p>To be Linked Data, types MUST be uniquely identified by an
+  <tref>IRI</tref>.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "@subject": "http://example.org/people#joebob",
+  "****@type****": "****http://xmlns.com/foaf/0.1/Person****",
+...
+}
+-->
+</pre>
+
+<p>The example above would generate the following triple if the JSON-LD
+document is mapped to RDF (in N-Triples notation):</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<http://example.org/people#joebob>
+   <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
+      <http://xmlns.com/foaf/0.1/Person> .
+-->
+</pre>
+
+</section>
+
+<section>
+<h2>Strings</h2>
+
+<p>Regular text strings, also referred to as <tdef>plain literal</tdef>s, are
+easily expressed using regular JSON <tref>string</tref>s.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "name": "****Mark Birbeck****",
+...
+}
+ -->
+</pre>
+
+</section>
+
+<section>
+<h2>String Internationalization</h2>
+
+<p>JSON-LD makes an assumption that strings with associated language encoding
+information are not very common when used in JavaScript and Web Services.
+Thus, it takes a little more effort to express strings with associated
+language information.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "name": ****
+  {
+    "@literal": "花澄",
+    "@language": "ja"
+  }****
+...
+}
+-->
+</pre>
+
+<p>The example above would generate a <tref>plain literal</tref> for
+<em>花澄</em> and associate the <code>ja</code> language code with the triple
+that is generated. Languages MUST be expressed in [[!BCP47]] format.</p>
+
+</section>
+
+<section>
+<h2>Datatypes</h2>
+
+<p>
+  A value with an associated datatype, also known as a
+  <tdef>typed literal</tdef>, is indicated by associating a literal with
+  an IRI which indicates the literal's datatype. Typed literals may be
+  expressed in JSON-LD in three ways:
+</p>
+
+<ol>
+  <li>By utilizing the <code>@coerce</code> keyword.</li>
+  <li>By utilizing the expanded form for specifying objects.</li>
+  <li>By using a native JSON datatype.</li>
+</ol>
+
+<p>The first example uses the <code>@coerce</code> keyword to express a
+typed literal:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{****
+  "@context":
+  {
+    "modified":  "http://purl.org/dc/terms/modified",
+    "dateTime": "http://www.w3.org/2001/XMLSchema#dateTime"
+    "@coerce":
+    {
+      "dateTime": "modified"
+    }
+  }****
+...
+  "modified": "2010-05-29T14:17:39+02:00",
+...
+}
+-->
+</pre>
+
+<p>The second example uses the expanded form for specifying objects:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "modified": ****
+  {
+    "@literal": "2010-05-29T14:17:39+02:00",
+    "@datatype": "dateTime"
+  }****
+...
+}
+-->
+</pre>
+
+<p>Both examples above would generate an object with the literal value of
+<code>2010-05-29T14:17:39+02:00</code> and the datatype of
+<code>http://www.w3.org/2001/XMLSchema#dateTime</code>.</p>
+
+<p>The third example uses a built-in native JSON type, a
+  <tref>number</tref>, to express a datatype:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "@subject": "http://example.org/people#joebob",
+  "age": ****31****
+...
+}
+-->
+</pre>
+
+<p>The example above would generate the following triple:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<http://example.org/people#joebob>
+   <http://xmlns.com/foaf/0.1/age>
+      "31"^^<http://www.w3.org/2001/XMLSchema#integer> .
+-->
+</pre>
+
+</section>
+
+<section>
+<h2>Multiple Objects for a Single Property</h2>
+
+<p>A JSON-LD author can express multiple triples in a compact way by using
+<tref>array</tref>s. If a subject has multiple values for the same property, the author
+MAY express each property as an <tref>array</tref>.</p>
+
+<p class="note">In JSON-LD, multiple objects on a property are not ordered. This is because typically graphs
+are not inherently ordered data structures. To see more on creating ordered collections
+in JSON-LD, see <a href="#lists">Lists</a>.
+</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "@subject": "http://example.org/people#joebob",
+  "nick": ****["joe", "bob", "jaybee"]****,
+...
+}
+-->
+</pre>
+
+<p>The markup shown above would generate the following triples:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<http://example.org/people#joebob>
+   <http://xmlns.com/foaf/0.1/nick>
+      "joe" .
+<http://example.org/people#joebob>
+   <http://xmlns.com/foaf/0.1/nick>
+      "bob" .
+<http://example.org/people#joebob>
+   <http://xmlns.com/foaf/0.1/nick>
+      "jaybee" .
+-->
+</pre>
+
+</section>
+
+<section>
+<h2>Multiple Typed Literals for a Single Property</h2>
+
+<p>Multiple <tref>typed literal</tref>s may also be expressed using the expanded
+form for objects:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "@subject": "http://example.org/articles/8",
+  "modified": ****
+  [
+    {
+      "@literal": "2010-05-29T14:17:39+02:00",
+      "@datatype": "dateTime"
+    },
+    {
+      "@literal": "2010-05-30T09:21:28-04:00",
+      "@datatype": "dateTime"
+    }
+  ]****
+...
+}
+-->
+</pre>
+
+<p>The markup shown above would generate the following triples:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<http://example.org/articles/8>
+   <http://purl.org/dc/terms/modified>
+      "2010-05-29T14:17:39+02:00"^^http://www.w3.org/2001/XMLSchema#dateTime .
+<http://example.org/articles/8>
+   <http://purl.org/dc/terms/modified>
+      "2010-05-30T09:21:28-04:00"^^http://www.w3.org/2001/XMLSchema#dateTime .
+-->
+</pre>
+
+</section>
+
+<section>
+<h2>Expansion</h2>
+
+<p>Expansion is the process of taking a JSON-LD document and applying a
+context such that all IRI, datatypes, and literal values are expanded so
+that the context is no longer necessary. JSON-LD document expansion
+is typically used as a part of <a href="#normalization">Framing</a> or
+<a href="#normalization">Normalization</a>.</p>
+
+<p>For example, assume the following JSON-LD input document:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+   "@context":
+   {
+      "name": "http://xmlns.com/foaf/0.1/name",
+      "homepage": "http://xmlns.com/foaf/0.1/homepage",
+      "@coerce":
+      {
+         "@iri": "homepage"
+      }
+   },
+   "name": "Manu Sporny",
+   "homepage": "http://manu.sporny.org/"
+}
+-->
+</pre>
+
+<p>Running the JSON-LD Expansion algorithm against the JSON-LD input document
+provided above would result in the following output:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+   "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
+   "http://xmlns.com/foaf/0.1/homepage":
+   {
+      "@iri": "http://manu.sporny.org/"
+   }
+}
+-->
+</pre>
+
+</section>
+
+<section>
+<h2>Compaction</h2>
+
+<p>Compaction is the process of taking a JSON-LD document and applying a
+context such that the most compact form of the document is generated. JSON
+is typically expressed in a very compact, key-value format. That is, full
+IRIs are rarely used as keys. At times, a JSON-LD document may be received
+that is not in its most compact form. JSON-LD, via the API, provides a way
+to compact a JSON-LD document.
+</p>
+
+<p>For example, assume the following JSON-LD input document:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+   "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
+   "http://xmlns.com/foaf/0.1/homepage":
+   {
+      "@iri": "http://manu.sporny.org/"
+   }
+}
+-->
+</pre>
+
+<p>Additionally, assume the following developer-supplied JSON-LD context:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+   "name": "http://xmlns.com/foaf/0.1/name",
+   "homepage": "http://xmlns.com/foaf/0.1/homepage",
+   "@coerce":
+   {
+      "@iri": "homepage"
+   }
+}
+-->
+</pre>
+
+<p>Running the JSON-LD Compaction algorithm given the context supplied above
+against the JSON-LD input document provided above would result in the following
+output:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+   "@context":
+   {
+      "name": "http://xmlns.com/foaf/0.1/name",
+      "homepage": "http://xmlns.com/foaf/0.1/homepage",
+      "@coerce":
+      {
+         "@iri": "homepage"
+      }
+   },
+   "name": "Manu Sporny",
+   "homepage": "http://manu.sporny.org/"
+}
+-->
+</pre>
+
+<p>The compaction algorithm also enables the developer to map any expanded
+format into an application-specific compacted format. While the context
+provided above mapped <code>http://xmlns.com/foaf/0.1/name</code> to
+<strong>name</strong>, it could have also mapped it to any arbitrary string
+provided by the developer.
+</p>
+
+</section>
+
+<section>
+<h2>Framing</h2>
+
+<p>A JSON-LD document is a representation of a directed graph. A single
+directed graph can have many different serializations, each expressing
+exactly the same information. Developers typically work with trees, represented as
+<tref>JSON object</tref>s. While mapping a graph to
+a tree can be done, the layout of the end result must be specified in advance.
+A <tdef>Frame</tdef> can be used by a developer on a JSON-LD document to
+specify a deterministic layout for a graph.
+</p>
+
+<p>Framing is the process of taking a JSON-LD document, which expresses a
+graph of information, and applying a specific graph layout
+(called a <tref>Frame</tref>).
+</p>
+
+<p>The JSON-LD document below expresses a library, a book and a chapter:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context": {
+    "Book":         "http://example.org/vocab#Book",
+    "Chapter":      "http://example.org/vocab#Chapter",
+    "contains":     "http://example.org/vocab#contains",
+    "creator":      "http://purl.org/dc/terms/creator"
+    "description":  "http://purl.org/dc/terms/description"
+    "Library":      "http://example.org/vocab#Library",
+    "title":        "http://purl.org/dc/terms/title",
+    "@coerce":
+    {
+      "@iri": "contains"
+    },
+  },
+  "@subject":
+  [{
+    "@subject": "http://example.com/library",
+    "@type": "Library",
+    "contains": "http://example.org/library/the-republic"
+  },
+  {
+    "@subject": "http://example.org/library/the-republic",
+    "@type": "Book",
+    "creator": "Plato",
+    "title": "The Republic",
+    "contains": "http://example.org/library/the-republic#introduction"
+  },
+  {
+    "@subject": "http://example.org/library/the-republic#introduction",
+    "@type": "Chapter",
+    "description": "An introductory chapter on The Republic.",
+    "title": "The Introduction"
+  }]
+}-->
+</pre>
+
+<p>Developers typically like to operate on items in a hierarchical, tree-based
+fashion. Ideally, a developer would want the data above sorted into top-level
+libraries, then the books that are contained in each library, and then the
+chapters contained in each book. To achieve that layout, the developer can
+define the following <tref>frame</tref>:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context": {
+    "Book":         "http://example.org/vocab#Book",
+    "Chapter":      "http://example.org/vocab#Chapter",
+    "contains":     "http://example.org/vocab#contains",
+    "creator":      "http://purl.org/dc/terms/creator"
+    "description":  "http://purl.org/dc/terms/description"
+    "Library":      "http://example.org/vocab#Library",
+    "title":        "http://purl.org/dc/terms/title"
+  },
+  "@type": "Library",
+  "contains": {
+    "@type": "Book",
+    "contains": {
+      "@type": "Chapter"
+    }
+  }
+}
+-->
+</pre>
+
+<p>When the framing algorithm is run against the previously defined
+JSON-LD document, paired with the <tref>frame</tref> above, the following
+JSON-LD document is the end result:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context": {
+    "Book":         "http://example.org/vocab#Book",
+    "Chapter":      "http://example.org/vocab#Chapter",
+    "contains":     "http://example.org/vocab#contains",
+    "creator":      "http://purl.org/dc/terms/creator"
+    "description":  "http://purl.org/dc/terms/description"
+    "Library":      "http://example.org/vocab#Library",
+    "title":        "http://purl.org/dc/terms/title"
+  },
+  "@subject": "http://example.org/library",
+  "@type": "Library",
+  "contains": {
+    ****"@subject": "http://example.org/library/the-republic",****
+    "@type": "Book",
+    ****"creator": "Plato",****
+    ****"title": "The Republic",****
+    "contains": {
+      ****"@subject": "http://example.org/library/the-republic#introduction",****
+      "@type": "Chapter",
+      ****"description": "An introductory chapter on The Republic.",****
+      ****"title": "The Introduction"****
+    },
+  },
+}
+-->
+</pre>
+
+<p>The JSON-LD framing algorithm allows developers to query by example and
+force a specific tree layout to a JSON-LD document.
+</p>
+
+</section>
+
+</section>
+
+<section>
+<h1>Advanced Concepts</h1>
+
+<p>JSON-LD has a number of features that provide functionality above and beyond
+the core functionality described above. The following sections outline the
+features that are specific to JSON-LD.
+</p>
+
+<section>
+  <h2>Vocabulary Prefixes</h2>
+  <p>
+    Vocabulary terms in Linked Data documents may draw from a number of
+    different Web vocabularies. At times, declaring every single term that
+    a document uses can require the developer to declare tens, if not
+    hundreds of potential vocabulary terms that may be used across an
+    application. This is a concern for at least three reasons; the
+    first is the cognitive load on the developer, the second is
+    the serialized size of the context, the third is future-proofing
+    application contexts. In order to address these issues, the concept of a
+    <tref>prefix</tref> mechanism is introduced.</p>
+  <p>
+    A <tdef>prefix</tdef> is a compact way of expressing a base
+    <tref>IRI</tref> to a <tref>Web Vocabulary</tref>.
+    Generally, these prefixes are used by concatenating the <em>prefix</em> and
+    a <em>term</em> separated by a colon (<code>:</code>).
+    The prefix is a short string that identifies a particular Web vocabulary.
+    For example, the prefix <code>foaf</code> may be used as a short
+    hand for the Friend-of-a-Friend Web Vocabulary, which is identified using
+    the IRI <code>http://xmlns.com/foaf/0.1/</code>. A developer may append any of
+    the FOAF Vocabulary terms to the end of the prefix to specify a short-hand
+    version of the full IRI 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>
+    The ability to use <tref>prefix</tref>es reduces the need for developers
+    to declare every vocabulary term that they intend to use in
+    the JSON-LD context. This reduces document serialization size because
+    every vocabulary term need not be declared in the context.
+    <tref>Prefix</tref> also
+    reduce the cognitive load on the developer. It is far easier to
+    remember <code>foaf:name</code> than it is to remember
+    <code>http://xmlns.com/foaf/0.1/name</code>. The use of prefixes also
+    ensures that a context document does not have to be updated in lock-step
+    with an externally defined <tref>Web Vocabulary</tref>. Without prefixes, a developer
+    would need to keep their application context terms in lock-step with an
+    externally defined Web Vocabulary. Rather, by just declaring the
+    Web Vocabulary prefix, one can use new terms as they're declared
+    without having to update the application's JSON-LD context.
+  </p>
+  <p>Consider the following example:</p>
+  <pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context": {
+    ****"dc": "http://purl.org/dc/elements/1.1/",****
+    ****"ex": "http://example.org/vocab#"****
+  },
+  "@subject": "http://example.org/library",
+  "@type": ****"ex:Library"****,
+  ****"ex:contains"****: {
+    "@subject": "http://example.org/library/the-republic",
+    "@type": ****"ex:Book"****,
+    ****"dc:creator"****: "Plato",
+    ****"dc:title"****: "The Republic",
+    ****"ex:contains"****: {
+      "@subject": "http://example.org/library/the-republic#introduction",
+      "@type": ****"ex:Chapter"****,
+      ****"dc:description"****: "An introductory chapter on The Republic.",
+      ****"dc:title"****: "The Introduction"
+    },
+  },
+}
+-->
+  </pre>
+  <p>
+    In this example, two different vocabularies are referred to using
+    prefixes. Those prefixes are then used as type and property values using
+    the <code>prefix:term</code> notation.
+  </p>
+  <p>
+    Prefixes, also known as CURIEs, are defined more formally in RDFa Core 1.1,
+    <cite><a href="http://www.w3.org/TR/rdfa-core/#s_curies">Section 6
+    &quot;CURIE Syntax Definition&quot;</a></cite> [[RDFA-CORE]].
+    JSON-LD does not support the square-bracketed CURIE syntax as the
+    mechanism is not required to disambiguate IRIs in a JSON-LD document like
+    it is in HTML documents.
+  </p>
+</section>
+
+<section>
+<h2>Automatic Typing</h2>
+
+<p>Since JSON is capable of expressing typed information such as doubles,
+integers, and boolean values. As demonstrated below, JSON-LD utilizes that
+information to create <tref>typed literal</tref>s:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  // The following two values are automatically converted to a type of xsd:double
+  // and both values are equivalent to each other.
+  "measure:cups": ****5.3****,
+  "measure:cups": ****5.3e0****,
+  // The following value is automatically converted to a type of xsd:double as well
+  "space:astronomicUnits": ****6.5e73****,
+  // The following value should never be converted to a language-native type
+  "measure:stones": ****{ "@literal": "4.8", "@datatype": "xsd:decimal" }****,
+  // This value is automatically converted to having a type of xsd:integer
+  "chem:protons": ****12****,
+  // This value is automatically converted to having a type of xsd:boolean
+  "sensor:active": ****true****,
+...
+}
+-->
+</pre>
+
+<p class="note">When dealing with a number of modern programming languages,
+including JavaScript ECMA-262, there is no distinction between
+<strong>xsd:decimal</strong> and <strong>xsd:double</strong> values. That is,
+the <tref>number</tref> <code>5.3</code> and the <tref>number</tref>
+<code>5.3e0</code> are treated as if they were the same. When converting from
+JSON-LD to a language-native format and back, datatype information is lost in a
+number of these languages. Thus, one could say that <code>5.3</code> is a
+<strong>xsd:decimal</strong> and <code>5.3e0</code> is an
+<strong>xsd:double</strong> in JSON-LD, but when both values are
+converted to a language-native format the datatype difference between the two
+is lost because the machine-level representation will almost always be a
+<strong>double</strong>.
+Implementers should be aware of this potential round-tripping issue between
+<strong>xsd:decimal</strong> and <strong>xsd:double</strong>. Specifically
+objects with a datatype of <strong>xsd:decimal</strong> MUST NOT be converted
+to a language native type.
+</p>
+
+</section>
+
+<section>
+<h2>Type Coercion</h2>
+
+<p>JSON-LD supports the coercion of values to particular data types.
+Type coercion allows someone deploying JSON-LD to coerce the incoming or
+outgoing types to the proper data type based on a mapping of data type IRIs to
+property types. Using type coercion, one may convert simple JSON data to
+properly typed RDF data.</p>
+
+<p>The example below demonstrates how a JSON-LD author can coerce values to
+<tref>plain literal</tref>s, <tref>typed literal</tref>s and IRIs.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context":
+  {
+     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
+     "xsd": "http://www.w3.org/2001/XMLSchema#",
+     "name": "http://xmlns.com/foaf/0.1/name",
+     "age": "http://xmlns.com/foaf/0.1/age",
+     "homepage": "http://xmlns.com/foaf/0.1/homepage",
+****     "@coerce":
+     {
+        "xsd:integer": "age",
+        "@iri": "homepage"
+     }****
+  },
+  "name": "John Smith",
+  "age": ****"41"****,
+  "homepage": ****"http://example.org/home/"****
+}
+-->
+</pre>
+
+<p>The example above would generate the following triples:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+_:bnode1
+   <http://xmlns.com/foaf/0.1/name>
+      "John Smith" .
+_:bnode1
+   <http://xmlns.com/foaf/0.1/age>
+      "41"^^http://www.w3.org/2001/XMLSchema#integer .
+_:bnode1
+   <http://xmlns.com/foaf/0.1/homepage>
+      <http://example.org/home/> .
+-->
+</pre>
+
+</section>
+
+<section>
+  <h2>Chaining</h2>
+  <p>
+    Object <tdef>chaining</tdef> is a JSON-LD feature that allows an author to
+    use the definition of JSON-LD objects as <tref>property</tref> values. This
+    is a commonly used mechanism for creating a parent-child relationship
+    between two <tref>subject</tref>s.
+  </p>
+  <p>The example shows an two subjects related by a property from the first
+  subject:</p>
+
+  <pre class="example" data-transform="updateExample">
+  <!--
+  {
+  ...
+    "name": "Manu Sporny",
+    "****knows****": {
+      "****@type****": "****Person****",
+      "****name****": "****Gregg Kellogg****",
+    }
+  ...
+  }
+  -->
+  </pre>
+
+  <p>
+    An object definition, like the one used above, MAY be used as a
+    JSON value at any point in JSON-LD.
+  </p>
+</section>
+
+<section>
+<h2>Identifying Unlabeled Nodes</h2>
+
+<p>At times, it becomes necessary to be able to express information without
+being able to specify the subject. Typically, this type of node is called
+an unlabeled node or a blank node. In JSON-LD, unlabeled node identifiers are
+automatically created if a subject is not specified using the
+<code>@subject</code> keyword. However, authors may provide identifiers for
+unlabeled nodes by using the special <code>_</code> (underscore)
+<tref>prefix</tref>. This allows to reference the node locally within the
+document but not in an external document.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+...
+  "@subject": "****_:foo****",
+...
+}
+ -->
+</pre>
+
+<p>The example above would set the subject to <code>_:foo</code>, which can
+then be used later on in the JSON-LD markup to refer back to the
+unlabeled node. This practice, however, is usually frowned upon when
+generating Linked Data. If a developer finds that they refer to the unlabeled
+node more than once, they should consider naming the node using a resolve-able
+IRI.
+</p>
+
+</section>
+
+<section>
+<h2>Aliasing Keywords</h2>
+
+<p>JSON-LD allows all of the syntax keywords, except for <code>@context</code>,
+to be aliased. This feature allows more legacy JSON content to be supported
+by JSON-LD. It also allows developers to design domain-specific implementations
+using only the JSON-LD context.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context":
+  {
+     ****"url": "@subject"****,
+     ****"a": "@type"****,
+     "name": "http://schema.org/name"
+  },
+  "url": "http://example.com/about#gregg",
+  "a": "http://schema.org/Person",
+  "name": "Gregg Kellogg"
+}
+-->
+</pre>
+
+<p>In the example above, the <code>@subject</code> and <code>@type</code>
+keywords have been given the aliases <strong>url</strong> and
+<strong>a</strong>, respectively.
+</p>
+
+</section>
+
+<section>
+<h2>Normalization</h2>
+
+<p>Normalization is the process of taking <tref>JSON-LD input</tref> and
+performing a deterministic transformation on that input that results in a
+<tref>JSON-LD output</tref> that any conforming JSON-LD processor would have
+generated given the same input. The problem is a fairly difficult technical
+problem to solve because it requires a directed graph to be ordered into a
+set of nodes and edges in a deterministic way. This is easy to do when all of
+the nodes have unique names, but very difficult to do when some of the nodes
+are not labeled.
+</p>
+
+<p>Normalization is useful when comparing two graphs against one another,
+when generating a detailed list of differences between two graphs, and
+when generating a cryptographic digital signature for information contained
+in a graph or when generating a hash of the information contained in a graph.
+</p>
+
+<p>The example below is an un-normalized JSON-LD document:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+   "@context":
+   {
+      "name": "http://xmlns.com/foaf/0.1/name",
+      "homepage": "http://xmlns.com/foaf/0.1/homepage",
+      "xsd": "http://www.w3.org/2001/XMLSchema#",
+      "@coerce":
+      {
+         "@iri": ["homepage"]
+      }
+   },
+   "name": "Manu Sporny",
+   "homepage": "http://manu.sporny.org/"
+}
+-->
+</pre>
+
+<p>The example below is the normalized form of the JSON-LD document above:</p>
+
+<p class="note">Whitespace is used below to aid readability. The normalization
+algorithm for JSON-LD removes all unnecessary whitespace in the fully
+normalized form.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+[{
+    "@subject":
+    {
+        "@iri": "_:c14n0"
+    },
+    "http://xmlns.com/foaf/0.1/homepage":
+    {
+        "@iri": "http://manu.sporny.org/"
+    },
+    "http://xmlns.com/foaf/0.1/name": "Manu Sporny"
+}]
+-->
+</pre>
+
+<p>Notice how all of the <tref>term</tref>s have been expanded and sorted in
+alphabetical order. Also, notice how the <tref>subject</tref> has been
+labeled with a <tref>blank node identifier</tref>. Normalization ensures that any arbitrary
+graph containing exactly the same information would be normalized to exactly
+the same form shown above.</p>
+
+</section>
+
+</section>
+
+<section>
+<h2>The Application Programming Interface</h2>
+
+<p>This API provides a clean mechanism that enables developers to convert
+JSON-LD data into a a variety of output formats that are easier to work with in
+various programming languages. If a JSON-LD API is provided in a programming
+environment, the entirety of the following API MUST be implemented.
+</p>
+
+<section>
+<h3>JsonLdProcessor</h3>
+<dl title="[NoInterfaceObject] interface JsonLdProcessor" class="idl">
+
+  <dt>object expand()</dt>
+  <dd><a href="#expansion">Expands</a> the given <code>input</code>
+    according to the steps in the
+    <a href="#expansion-algorithm">Expansion Algorithm</a>. The
+    <code>input</code> MUST be copied, expanded and returned if there are
+    no errors. If the expansion fails, an appropriate exception MUST be thrown.
+
+    <dl class="parameters">
+     <dt>object input</dt>
+     <dd>The JSON-LD object to copy and perform the expansion upon.</dd>
+     <dt>object optional? context</dt>
+     <dd>An external context to use additionally to the context embedded in <code>input</code> when expanding the <code>input</code>.</dd>
+    </dl>
+
+    <dl class="exception" title="InvalidContext">
+     <dt>INVALID_SYNTAX</dt>
+     <dd>A general syntax error was detected in the <code>@context</code>.
+     For example, if a <code>@coerce</code> key maps to anything other than
+     a string or an array of strings, this exception would be raised.</dd>
+     <dt>MULTIPLE_DATATYPES</dt>
+     <dd>There is more than one target datatype specified for a single
+     property in the list of coercion rules. This means that the processor
+     does not know what the developer intended for the target datatype for a
+     property.</dd>
+    </dl>
+
+  </dd>
+
+  <dt>object compact()</dt>
+  <dd><a href="#compaction">Compacts</a> the given <code>input</code>
+    according to the steps in the
+    <a href="#compaction-algorithm">Compaction Algorithm</a>. The
+    <code>input</code> MUST be copied, compacted and returned if there are
+    no errors. If the compaction fails, an appropirate exception MUST be
+    thrown.
+  <dl class="parameters">
+     <dt>object input</dt>
+     <dd>The JSON-LD object to perform compaction on.</dd>
+     <dt>object optional? context</dt>
+     <dd>The base context to use when compacting the <code>input</code>.</dd>
+  </dl>
+
+    <dl class="exception" title="InvalidContext">
+     <dt>INVALID_SYNTAX</dt>
+     <dd>A general syntax error was detected in the <code>@context</code>.
+     For example, if a <code>@coerce</code> key maps to anything other than
+     a string or an array of strings, this exception would be raised.</dd>
+     <dt>MULTIPLE_DATATYPES</dt>
+     <dd>There is more than one target datatype specified for a single
+     property in the list of coercion rules. This means that the processor
+     does not know what the developer intended for the target datatype for a
+     property.</dd>
+    </dl>
+
+    <dl class="exception" title="ProcessingError">
+     <dt>LOSSY_COMPACTION</dt>
+     <dd>The compaction would lead to a loss of information, such as a
+     <code>@language</code> value.</dd>
+     <dt>CONFLICTING_DATATYPES</dt>
+     <dd>The target datatype specified in the coercion rule and the
+     datatype for the typed literal do not match.</dd>
+    </dl>
+
+  </dd>
+
+  <dt>object frame()</dt>
+  <dd><a href="#framing">Frames</a> the given <code>input</code>
+    using the <code>frame</code> according to the steps in the
+    <a href="#framing-algorithm">Framing Algorithm</a>. The
+    <code>input</code> is used to build the framed output and is returned if
+    there are no errors. If there are no matches for the frame,
+    <code>null</code> MUST be returned. Exceptions MUST be thrown if there are
+    errors.
+  <dl class="parameters">
+     <dt>object input</dt>
+     <dd>The JSON-LD object to perform framing on.</dd>
+     <dt>object frame</dt>
+     <dd>The frame to use when re-arranging the data.</dd>
+     <dt>object options</dt>
+     <dd>A set of options that will affect the framing algorithm.</dd>
+  </dl>
+
+    <dl class="exception" title="InvalidFrame">
+    <dt>INVALID_SYNTAX</dt>
+    <dd>A frame must be either an object or an array of objects, if the frame
+    is neither of these types, this exception is thrown.</dd>
+    <dt>MULTIPLE_EMBEDS</dt>
+    <dd>A subject IRI was specified in more than one place in the input
+    frame. More than one embed of a given subject IRI is not allowed, and if
+    requested, MUST result in this exception.</dd>
+    </dl>
+
+  </dd>
+
+  <dt>object normalize()</dt>
+  <dd><a href="#normalization">Normalizes</a> the given <code>input</code>
+    according to the steps in the
+    <a href="#normalization-algorithm">Normalization Algorithm</a>. The
+    <code>input</code> MUST be copied, normalized and returned if there are
+    no errors. If the compaction fails, <code>null</code> MUST be returned.
+  <dl class="parameters">
+     <dt>object input</dt>
+     <dd>The JSON-LD object to perform normalization upon.</dd>
+     <dt>object optional? context</dt>
+     <dd>An external context to use additionally to the context embedded in <code>input</code> when expanding the <code>input</code>.</dd>
+  </dl>
+
+    <dl class="exception" title="InvalidContext">
+     <dt>INVALID_SYNTAX</dt>
+     <dd>A general syntax error was detected in the <code>@context</code>.
+     For example, if a <code>@coerce</code> key maps to anything other than
+     a string or an array of strings, this exception would be raised.</dd>
+     <dt>MULTIPLE_DATATYPES</dt>
+     <dd>There is more than one target datatype specified for a single
+     property in the list of coercion rules. This means that the processor
+     does not know what the developer intended for the target datatype for a
+     property.</dd>
+    </dl>
+
+  </dd>
+
+  <dt>object triples()</dt>
+  <dd>Processes the <code>input</code> according to the
+    <a href="#rdf-conversion-algorithm">RDF Conversion Algorithm</a>, calling
+    the provided <code>tripleCallback</code> for each triple generated.
+  <dl class="parameters">
+     <dt>object input</dt>
+     <dd>The JSON-LD object to process when outputting triples.</dd>
+     <dt>JsonLdTripleCallback tripleCallback</dt>
+     <dd>A callback that is called whenever a processing error occurs on
+     the given <code>input</code>.
+     <div class="issue">This callback should be aligned with the
+       RDF API.</div></dd>
+     <dt>object optional? context</dt>
+     <dd>An external context to use additionally to the context embedded in <code>input</code> when expanding the <code>input</code>.</dd>
+  </dl>
+
+    <dl class="exception" title="InvalidContext">
+     <dt>INVALID_SYNTAX</dt>
+     <dd>A general syntax error was detected in the <code>@context</code>.
+     For example, if a <code>@coerce</code> key maps to anything other than
+     a string or an array of strings, this exception would be raised.</dd>
+     <dt>MULTIPLE_DATATYPES</dt>
+     <dd>There is more than one target datatype specified for a single
+     property in the list of coercion rules. This means that the processor
+     does not know what the developer intended for the target datatype for a
+     property.</dd>
+    </dl>
+
+  </dd>
+
+</dl>
+
+</section>
+
+<section>
+<h3>JsonLdTripleCallback</h3>
+<p>The JsonLdTripleCallback is called whenever the processor generates a
+triple during the <code>triple()</code> call.</p>
+
+<dl title="[NoInterfaceObject Callback] interface JsonLdTripleCallback"
+    class="idl">
+
+  <dt>void triple()</dt>
+  <dd>This callback is invoked whenever a triple is generated by the processor.
+  <dl class="parameters">
+     <dt>DOMString subject</dt>
+     <dd>The subject IRI that is associated with the triple.</dd>
+     <dt>DOMString property</dt>
+     <dd>The property IRI that is associated with the triple.</dd>
+     <dt>DOMString objectType</dt>
+     <dd>The type of object that is associated with the triple. Valid values
+       are <code>IRI</code> and <code>literal</code>.</dd>
+     <dt>DOMString object</dt>
+     <dd>The object value associated with the subject and the property.</dd>
+     <dt>DOMString? datatype</dt>
+     <dd>The datatype associated with the object.</dd>
+     <dt>DOMString? language</dt>
+     <dd>The language associated with the object in BCP47 format.</dd>
+  </dl>
+  </dd>
+</dl>
+</section>
+
+
+</section>
+
+<section>
+<h1>Algorithms</h1>
+
+<p>All algorithms described in this section are intended to operate on
+language-native data structures. That is, the serialization to a text-based
+JSON document isn't required as input or output to any of these algorithms and
+language-native data structures MUST be used where applicable.</p>
+
+<section>
+  <h2>Syntax Tokens and Keywords</h2>
+
+  <p>JSON-LD specifies a number of syntax tokens and keywords that are using
+  in all algorithms described in this section:</p>
+
+  <dl>
+  <dt><code>@context</code></dt><dd>Used to set the <tref>local context</tref>.</dd>
+  <dt><code>@base</code></dt><dd>Used to set the base IRI for all object IRIs affected  by the <tref>active context</tref>.</dd>
+  <dt><code>@vocab</code></dt><dd>Used to set the base IRI for all property IRIs affected by the <tref>active context</tref>.</dd>
+  <dt><code>@coerce</code></dt><dd>Used to specify type coercion rules.</dd>
+  <dt><code>@literal</code></dt><dd>Used to specify a literal value.</dd>
+  <dt><code>@iri</code></dt><dd>Used to specify an IRI value.</dd>
+  <dt><code>@language</code></dt><dd>Used to specify the language for a literal.</dd>
+  <dt><code>@datatype</code></dt><dd>Used to specify the datatype for a literal.</dd>
+  <dt><code>:</code></dt><dd>The separator for JSON keys and values that use the <tref>prefix</tref> mechanism.</dd>
+  <dt><code>@subject</code></dt><dd>Sets the active subject.</dd>
+  <dt><code>@type</code></dt><dd>Used to set the type of the active subject.</dd>
+  </dl>
+</section>
+
+<section>
+  <h2>Algorithm Terms</h2>
+  <dl>
+    <dt><tdef>initial context</tdef></dt>
+    <dd>
+      a context that is specified to the algorithm before processing begins.
+    </dd>
+    <dt><tdef>active subject</tdef></dt>
+    <dd>
+      the currently active subject that the processor should use when
+      processing.
+    </dd>
+    <dt><tdef>active property</tdef></dt>
+    <dd>
+      the currently active property that the processor should use when
+      processing.
+    </dd>
+    <dt><tdef>active object</tdef></dt>
+    <dd>
+      the currently active object that the processor should use when
+      processing.
+    </dd>
+    <dt><tdef>active context</tdef></dt>
+    <dd>
+      a context that is used to resolve <tref>prefix</tref>es and
+      <tref>term</tref>s while the processing
+      algorithm is running. The <tref>active context</tref> is the context
+      contained within the <tref>processor state</tref>.
+    </dd>
+    <dt><tdef>local context</tdef></dt>
+    <dd>
+      a context that is specified within a <tref>JSON object</tref>,
+      specified via the <code>@context</code> keyword.
+    </dd>
+    <dt><tdef>processor state</tdef></dt>
+    <dd>
+      the <tref>processor state</tref>, which includes the <tref>active
+      context</tref>, <tref>current subject</tref>, and
+      <tref>current property</tref>. The <tref>processor state</tref> is managed
+      as a stack with elements from the previous <tref>processor state</tref>
+      copied into a new <tref>processor state</tref> when entering a new
+      <tref>JSON object</tref>.
+    </dd>
+    <dt><tdef>JSON-LD input</tdef></dt>
+    <dd>
+      The JSON-LD data structure that is provided as input to the algorithm.
+    </dd>
+    <dt><tdef>JSON-LD output</tdef></dt>
+    <dd>
+      The JSON-LD data structure that is produced as output by the algorithm.
+    </dd>
+
+  </dl>
+</section>
+
+<section>
+  <h2 id="context">Context</h2>
+  <p>
+    Processing of JSON-LD data structure is managed recursively.
+    During processing, each rule is applied using information provided by the <tref>active context</tref>.
+    Processing begins by pushing a new <tref>processor state</tref> onto the <tref>processor state</tref> stack and
+    initializing the <tref>active context</tref> with the <tref>initial context</tref>. If a <tref>local context</tref> is encountered,
+    information from the <tref>local context</tref> is merged into the <tref>active context</tref>.
+  </p>
+  <p>
+    The <tref>active context</tref> is used for expanding keys and values of a <tref>JSON object</tref> (or elements
+    of a list (see <span a="#list-processing">List Processing</span>)).
+  </p>
+  <p>
+    A <tref>local context</tref> is identified within a <tref>JSON object</tref> having a key of
+    <code>@context</code> with <tref>string</tref> or a <tref>JSON object</tref> value. When processing a <tref>local
+    context</tref>, special processing rules apply:
+  </p>
+  <ol class="algorithm">
+    <li>Create a new, empty <tref>local context</tref>.</li>
+    <li>
+      If the value is a simple <tref>string</tref>, it MUST have a lexical form of IRI and used to initialize
+      a new JSON document which replaces the value for subsequent processing.
+    </li>
+    <li>If the value is a <tref>JSON object</tref>, perform the following steps:
+      <ol class="algorithm">
+        <li>
+          If the <tref>JSON object</tref> has a <code>@base</code> key, it MUST have a value of a simple
+          <tref>string</tref> with the lexical form of an absolute IRI. Add the base mapping to the <tref>local
+          context</tref>. <p class="issue">Turtle allows @base to be relative. If we did this, we
+          would have to add <a href="#iri-expansion">IRI Expansion</a>.</p>
+        </li>
+        <li>
+          If the <tref>JSON object</tref> has a <code>@vocab</code> key, it MUST have a value of a simple
+          <tref>string</tref> with the lexical form of an absolute IRI. Add the vocabulary mapping to the
+          <tref>local context</tref> after performing <a href="#iri-expansion">IRI Expansion</a> on
+          the associated value.
+        </li>
+        <li>
+          If the <tref>JSON object</tref> has a <code>@coerce</code> key, it MUST have a value of a
+          <tref>JSON object</tref>. Add the <code>@coerce</code> mapping to the <tref>local context</tref>
+          performing <a href="#iri-expansion">IRI Expansion</a> on the associated value(s).
+        </li>
+        <li>
+          Otherwise, the key MUST have the lexical form of <cite><a
+          href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName">NCName</a></cite> and
+          MUST have the value of a simple <tref>string</tref> with the lexical form of IRI. Merge the key-value
+          pair into the <tref>local context</tref>.
+        </li>
+      </ol>
+    </li>
+    <li>
+      Merge the of <tref>local context</tref>'s <code>@coerce</code> mapping into  the
+      <tref>active context</tref>'s <code>@coerce</code> mapping as described <a href="#coerce">below</a>.
+    </li>
+    <li>
+      Merge all entries other than the <code>@coerce</code> mapping from the <tref>local context</tref> to the
+      <tref>active context</tref> overwriting any duplicate values.
+    </li>
+  </ol>
+
+  <section>
+    <h3>Coerce</h3>
+    <p>
+      Map each key-value pair in the <tref>local context</tref>'s
+      <code>@coerce</code> mapping into the <tref>active context</tref>'s
+      <code>@coerce</code> mapping, overwriting any duplicate values in
+      the <tref>active context</tref>'s <code>@coerce</code> mapping.
+      The <code>@coerce</code> mapping has either a single
+      <code>prefix:term</code> value, a single <tref>term</tref> value or an
+      <tref>array</tref> of <code>prefix:term</code> or <tref>term</tref> values.
+      When merging with an existing mapping in the <tref>active context</tref>,
+      map all <tref>prefix</tref> and <tref>term</tref> values to
+      <tref>array</tref> form and replace with the union of the value from
+      the <tref>local context</tref> and the value of the
+      <tref>active context</tref>. If the result is an <tref>array</tref>
+      with a single value, the processor MAY represent this as a string value.
+    </p>
+  </section>
+
+  <section>
+    <h3>Initial Context</h3>
+    <p>The <tref>initial context</tref> is initialized as follows:</p>
+    <ul>
+      <li>
+        <code>@base</code> is set using <cite><href="http://www.ietf.org/rfc/rfc2396.txt">section 5.1 Establishing a
+        Base URI</href="http://www.ietf.org/rfc/rfc2396.txt"></cite> of [[RFC3986]]. Processors MAY provide a means
+        of setting the base IRI programatically.
+      </li>
+      <li><code>@coerce</code> is set with a single mapping from <code>@iri</code> to <code>@type</code>.</li>
+    </ul>
+    <pre class="example" data-transform="updateExample">
+    <!--
+    {
+        "@base": ****document-location****,
+        "@coerce": {
+          "@iri": "@type"
+        }
+    }
+    -->
+    </pre>
+  </section>
+</section>
+
+<section>
+  <h2>IRI Expansion</h2>
+  <p>Keys and some values are evaluated to produce an IRI. This section defines an algorithm for
+    transforming a value representing an IRI into an actual IRI.</p>
+  <p>IRIs may be represented as an absolute IRI, a <tref>term</tref>, a <tref>prefix</tref>:<tref>term</tref> construct, or as a value relative to <code>@base</code>
+    or <code>@vocab</code>.</p>
+  <p>The algorithm for generating an IRI is:
+    <ol class="algorithm">
+      <li>Split the value into a <em>prefix</em> and <em>suffix</em> from the first occurrence of ':'.</li>
+      <li>If the prefix is a '_' (underscore), the IRI is unchanged.</li>
+      <li>If the <tref>active context</tref> contains a mapping for <em>prefix</em>, generate an IRI
+        by prepending the mapped prefix to the (possibly empty) suffix using textual concatenation. Note that an empty
+        suffix and no suffix (meaning the value contains no ':' string at all) are treated equivalently.</li>
+      <li>If the IRI being processed is for a property (i.e., a key's value in a <tref>JSON object</tref>, or a
+        value in a <code>@coerce</code> mapping) and the active context has a <code>@vocab</code> mapping,
+        join the mapped value to the suffix using textual concatenation.</li>
+      <li>If the IRI being processed is for a subject or object (i.e., not a property) and the active context has a <code>@base</code> mapping,
+        join the mapped value to the suffix using the method described in [[!RFC3986]].</li>
+      <li>Otherwise, use the value directly as an IRI.</li>
+    </ol>
+  </p>
+</section>
+
+<section>
+  <h2>IRI Compaction</h2>
+  <p>Some keys and values are expressed using IRIs. This section defines an
+    algorithm for transforming an IRI to a compact IRI using the
+    <tref>term</tref>s and <tref>prefix</tref>es specified in the
+    <tref>local context</tref>.</p>
+
+  <p>The algorithm for generating a compacted IRI is:
+    <ol class="algorithm">
+      <li>Search every key-value pair in the <tref>active context</tref> for
+        a <tref>term</tref> that is a complete match
+        against the IRI. If a complete match is found, the resulting compacted
+        IRI is the <tref>term</tref> associated with the IRI in the
+        <tref>active context</tref>.</li>
+      <li>If a complete match is not found, search for a partial match from
+        the beginning of the IRI. For all matches that are found, the resulting
+        compacted IRI is the <tref>prefix</tref> associated with the partially
+        matched IRI in the <tref>active context</tref> concatenated with a
+        colon (:) character and the unmatched part of the string. If there is
+        more than one compacted IRI produced, the final value is the
+        shortest and lexicographically least value of the entire set of compacted IRIs.</li>
+    </ol>
+  </p>
+</section>
+
+<section>
+  <h2>Value Expansion</h2>
+  <p>Some values in JSON-LD can be expressed in a compact form. These values
+    are required to be expanded at times when processing JSON-LD documents.
+  </p>
+
+  <p>The algorithm for expanding a value is:
+    <ol class="algorithm">
+      <li>If the key that is associated with the value has an associated
+        coercion entry in the <tref>local context</tref>, the resulting
+        expansion is an object populated according to the following steps:
+        <ol class="algorithm">
+          <li>If the coercion target is <code>@iri</code>, expand the value
+            by adding a new key-value pair where the key is <code>@iri</code>
+            and the value is the expanded IRI according to the
+            <a href="#iri-expansion">IRI Expansion</a> rules.</li>
+          <li>If the coercion target is a typed literal, expand the value
+            by adding two new key-value pairs. The first key-value pair
+            will be <code>@literal</code> and the unexpanded value. The second
+            key-value pair will be <code>@datatype</code> and the associated
+            coercion datatype expanded according to the
+            <a href="#iri-expansion">IRI Expansion</a> rules.</li>
+        </ol>
+      </li>
+    </ol>
+  </p>
+</section>
+
+<section>
+  <h2>Value Compaction</h2>
+  <p>Some values, such as IRIs and typed literals, may be expressed in an
+    expanded form in JSON-LD. These values are required to be compacted at
+    times when processing JSON-LD documents.
+  </p>
+
+  <p>The algorithm for compacting a value is:
+    <ol class="algorithm">
+      <li>If the <tref>local context</tref> contains a coercion target for the
+        key that is associated with the value, compact the value using the
+        following steps:
+        <ol class="algorithm">
+          <li>If the coercion target is an <code>@iri</code>, the compacted
+            value is the value associated with the <code>@iri</code> key,
+            processed according to the
+            <a href="#iri-compaction">IRI Compaction</a> steps.</li>
+          <li>If the coercion target is a typed literal, the compacted
+            value is the value associated with the <code>@literal</code> key.
+          </li>
+          <li>Otherwise, the value is not modified.</li>
+        </ol>
+      </li>
+    </ol>
+  </p>
+</section>
+
+<section>
+<h2>Expansion</h2>
+
+<p class="issue">This algorithm is a work in progress, do not implement it.</p>
+
+<p>As stated previously, expansion is the process of taking a JSON-LD
+input and expanding all IRIs and typed literals to their fully-expanded form.
+The output will not contain a single context declaration and will have all IRIs
+and typed literals fully expanded.
+</p>
+
+<section>
+<h3>Expansion Algorithm</h3>
+
+<ol class="algorithm">
+  <li>If the top-level item in the <tref>JSON-LD input</tref> is an <tref>array</tref>,
+  process each item in the <tref>array</tref> recursively using this algorithm.</li>
+  <li>If the top-level item in the <tref>JSON-LD input</tref> is an object,
+  update the <tref>local context</tref> according to the steps outlined in
+  the <a href="#context">context</a> section. Process each key, expanding
+  the key according to the <a href="#iri-expansion">IRI Expansion</a> rules.</li>
+  <ol class="algorithm">
+    <li>Process each value associated with each key:
+      <ol class="algorithm">
+        <li>If the value is an <tref>array</tref>, process each item in the <tref>array</tref>
+        recursively using this algorithm.</li>
+        <li>If the value is an object, process the object recursively
+        using this algorithm.</li>
+        <li>Otherwise, check to see the associated key has an associated
+        coercion rule. If the value should be coerced, expand the value
+        according to the <a href="#value-expansion">Value Expansion</a> rules.
+        If the value does not need to be coerced, leave the value as-is.
+        </li>
+      </ol>
+    <li>Remove the context from the object.</li>
+  </ol>
+</ol>
+</section>
+
+</section>
+
+<section>
+<h2>Compaction</h2>
+
+<p class="issue">This algorithm is a work in progress, do not implement it.</p>
+
+<p>As stated previously, compaction is the process of taking a JSON-LD
+input and compacting all IRIs using a given context. The output
+will contain a single top-level context declaration and will only use
+<tref>term</tref>s and <tref>prefix</tref>es and will ensure that all
+typed literals are fully compacted.
+</p>
+
+<section>
+<h3>Compaction Algorithm</h3>
+
+<ol class="algorithm">
+  <li>Perform the <a href="#expansion-algorithm">Expansion Algorithm</a> on
+  the <tref>JSON-LD input</tref>. This removes any existing context to allow the given context to be cleanly applied.</li>
+  <li>Set the <tref>active context</tref> to the given context.
+  <li>If the top-level item is an <tref>array</tref>, process each item in the <tref>array</tref>
+    recursively, starting at this step.
+  <li>If the top-level item is an object, compress each key using the steps
+    defined in <a href="#iri-compaction">IRI Compaction</a> and compress each
+    value using the steps defined in
+    <a href="#value-compaction">Value Compaction</a>.</li>
+  </li>
+</ol>
+</section>
+
+</section>
+
+
+<section>
+<h2>Framing</h2>
+
+<p class="issue">This algorithm is a work in progress, do not implement it.</p>
+
+<p>A JSON-LD document is a representation of a directed graph. A single
+directed graph can have many different serializations, each expressing
+exactly the same information. Developers typically don't work directly with
+graphs, but rather, prefer trees when dealing with JSON. While mapping a graph
+to a tree can be done, the layout of the end result must be specified in
+advance. This section defines an algorithm for mapping a graph to
+a tree given a <tref>frame</tref>.
+</p>
+
+<section>
+<h3>Framing Algorithm Terms</h3>
+ <dl>
+   <dt><tdef>input frame</tdef></dt>
+   <dd>
+     the initial <tref>frame</tref> provided to the framing algorithm.
+   </dd>
+   <dt><tdef>framing context</tdef></dt>
+   <dd>
+     a context containing the <tref>object embed flag</tref>, the
+     <tref>explicit inclusion flag</tref> and the
+     <tref>omit default flag</tref>.
+   </dd>
+   <dt><tdef>object embed flag</tdef></dt>
+   <dd>
+     a flag specifying that objects should be directly embedded in the output,
+     instead of being referred to by their IRI.
+   </dd>
+   <dt><tdef>explicit inclusion flag</tdef></dt>
+   <dd>
+     a flag specifying that for properties to be included in the output, they
+     must be explicitly declared in the <tref>framing context</tref>.
+   </dd>
+   <dt><tdef>omit missing properties flag</tdef></dt>
+   <dd>
+     a flag specifying that properties that are missing from the
+     <tref>JSON-LD input</tref> should be omitted from the output.
+   </dd>
+   <dt><tdef>match limit</tdef></dt>
+   <dd>
+     A value specifying the maximum number of matches to accept when building
+     arrays of values during the framing algorithm. A value of -1 specifies
+     that there is no match limit.
+   </dd>
+   <dt><tdef>map of embedded subjects</tdef></dt>
+   <dd>
+     A map that tracks if a subject has been embedded in the output of the
+     <a href="#framing-algorithm">Framing Algorithm</a>.
+   </dd>
+ </dl>
+</section>
+
+<section>
+<h3>Framing Algorithm</h3>
+
+<p>The framing algorithm takes <tref>JSON-LD input</tref> that has been
+normalized according to the
+<a href="#normalization-algorithm">Normalization Algorithm</a>
+(<strong>normalized input</strong>), an
+<tref>input frame</tref> that has been expanded according to the
+<a href="#expansion-algorithm">Expansion Algorithm</a>
+(<strong>expanded frame</strong>), and a number of options and produces
+<tref>JSON-LD output</tref>. The following series of steps is the recursive
+portion of the framing algorithm:
+</p>
+
+<ol class="algorithm">
+  <li>Initialize the <tref>framing context</tref> by setting the
+   <tref>object embed flag</tref>, clearing the
+   <tref>explicit inclusion flag</tref>, and clearing the
+   <tref>omit missing properties flag</tref>. Override these values
+   based on input options provided to the algorithm by the application.
+  </li>
+  <li>Generate a <tdef>list of frames</tdef> by processing the
+    <strong>expanded frame</strong>:
+    <ol class="algorithm">
+      <li>If the <strong>expanded frame</strong> is not an <tref>array</tref>, set
+        <tref>match limit</tref> to 1, place the
+        <strong>expanded frame</strong> into the <tref>list of frames</tref>,
+        and set the <tref>JSON-LD output</tref> to <code>null</code>.</li>
+      <li>If the <strong>expanded frame</strong> is an empty <tref>array</tref>, place an
+        empty object into the <tref>list of frames</tref>,
+        set the <tref>JSON-LD output</tref> to an <tref>array</tref>, and set
+        <tref>match limit</tref> to -1.</li>
+      <li>If the <strong>expanded frame</strong> is a non-empty <tref>array</tref>, add
+        each item in the <strong>expanded frame</strong> into the
+        <tref>list of frames</tref>, set the <tref>JSON-LD output</tref> to an
+        <tref>array</tref>, and set <tref>match limit</tref> to -1.</li>
+    </ol></li>
+  <li>Create a <tdef>match array</tdef> for each <strong>expanded frame</strong>
+    in the <tref>list of frames</tref> halting when either the
+    <tref>match limit</tref> is zero or the end of the
+    <tref>list of frames</tref> is reached. If an
+    <strong>expanded frame</strong> is
+    not an object, the processor MUST throw a <code>Invalid Frame Format</code>
+    exception. Add each matching item from the <strong>normalized input</strong>
+    to the <tref>matches array</tref> and decrement the
+    <tref>match limit</tref> by 1 if:
+    <ol class="algorithm">
+       <li>The <strong>expanded frame</strong> has an <code>rdf:type</code>
+         that exists in the item's list of <code>rdf:type</code>s. Note:
+         the <code>rdf:type</code> can be an <tref>array</tref>, but only one value needs
+         to be in common between the item and the
+         <strong>expanded frame</strong> for a match.</li>
+       <li>The <strong>expanded frame</strong> does not have an
+         <code>rdf:type</code> property, but every property in the
+         <strong>expanded frame</strong> exists in the item.</li>
+    </ol></li>
+  <li>Process each item in the <tref>match array</tref> with its associated
+    <tdef>match frame</tdef>:
+    <ol class="algorithm">
+      <li>If the <tref>match frame</tref> contains an <code>@embed</code>
+        keyword, set the <tref>object embed flag</tref> to its value.
+        If the <tref>match frame</tref> contains an <code>@explicit</code>
+        keyword, set the <tref>explicit inclusion flag</tref> to its value.
+        Note: if the keyword exists, but the value is neither
+        <code>true</code> or <code>false</code>, set the associated flag to
+        <code>true</code>.</li>
+      <li>If the <tref>object embed flag</tref> is cleared and the item has
+        the <code>@subject</code> property, replace the item with the value
+        of the <code>@subject</code> property.</li>
+      <li>If the <tref>object embed flag</tref> is set and the item has
+        the <code>@subject</code> property, and its IRI is in the
+        <tref>map of embedded subjects</tref>, throw a
+        <code>Duplicate Embed</code> exception.</li>
+      <li>If the <tref>object embed flag</tref> is set and the item has
+        the <code>@subject</code> property and its IRI is not in the
+        <tref>map of embedded subjects</tref>:
+        <ol class="algorithm">
+          <li>If the <tref>explicit inclusion flag</tref> is set,
+            then delete any key from the item that does not exist in the
+            <tref>match frame</tref>, except <code>@subject</code>.</li>
+          <li>For each key in the <tref>match frame</tref>, except for
+            keywords and <code>rdf:type</code>:
+          <ol class="algorithm">
+            <li>If the key is in the item, then build a new
+              <tdef>recursion input list</tdef> using the object or objects
+              associated with the key. If any object contains an
+              <code>@iri</code> value that exists in the
+              <tref>normalized input</tref>, replace the object in the
+              <tref>recusion input list</tref> with a new object containing
+              the <code>@subject</code> key where the value is the value of
+              the <code>@iri</code>, and all of the other key-value pairs for
+              that subject. Set the <tdef>recursion match frame</tdef> to the
+              value associated with the <tref>match frame</tref>'s key. Replace
+              the value associated with the key by recursively calling this
+              algorithm using <tref>recursion input list</tref>,
+              <tref>recursion match frame</tref> as input.</li>
+            <li>If the key is not in the item, add the key to the item and
+              set the associated value to an empty array if the
+              <tref>match frame</tref> key's value is an array
+              or <code>null</code> otherwise.</li>
+            <li>If value associated with the item's key is <code>null</code>,
+              process the <tref>omit missing properties flag</tref>:
+              <ol class="algorithm">
+                <li>If the value associated with the key in the
+                  <tref>match frame</tref> is an array, use the first frame
+                  from the array as the <tdef>property frame</tdef>, otherwise
+                  set the <tref>property frame</tref> to an empty object.</li>
+                <li>If the <tref>property frame</tref> contains an
+                <code>@omitDefault</code> keyword, set the
+                <tref>omit missing properties flag</tref> to its value.
+                Note: if the keyword exists, but the value is neither
+                <code>true</code> or <code>false</code>, set the associated
+                flag to <code>true</code>.</li>
+                <li>If the <tref>omit missing properties flag</tref> is set,
+                  delete the key in the item. Otherwise, if the
+                  <code>@default</code> keyword is set in the
+                  <tref>property frame</tref> set the item's value to the value
+                  of <code>@default</code>.</li>
+              </ol></li>
+          </ol></li>
+        </ol>
+      <li>If the <tref>JSON-LD output</tref> is <code>null</code> set it to
+        the item, otherwise, append the item to the
+        <tref>JSON-LD output</tref>.
+    </ol>
+  <li>Return the <tref>JSON-LD output</tref>.</li>
+</ol>
+
+The final, non-recursive step of the framing algorithm requires the
+<tref>JSON-LD output</tref> to be compacted according to the
+<a href="#compaction-algorithm">Compaction Algorithm</a> by using the
+context provided in the <tref>input frame</tref>. The resulting value is the
+final output of the compaction algorithm and is what should be returned to the
+application.
+
+</section>
+
+</section>
+
+<section>
+<h2>Normalization</h2>
+
+<p class="issue">This algorithm is a work in progress, do not implement it.</p>
+
+<p>Normalization is the process of taking <tref>JSON-LD input</tref> and
+performing a deterministic transformation on that input that results in all
+aspects of the graph being fully expanded and named in the
+<tref>JSON-LD output</tref>. The normalized output is generated in such a way
+that any conforming JSON-LD processor will generate identical output
+given the same input. The problem is a fairly difficult technical
+problem to solve because it requires a directed graph to be ordered into a
+set of nodes and edges in a deterministic way. This is easy to do when all of
+the nodes have unique names, but very difficult to do when some of the nodes
+are not labeled.
+</p>
+
+<p>In time, there may be more than one normalization algorithm that will need
+to be identified. For identification purposes, this algorithm is named
+"Universal Graph Normalization Algorithm 2011"
+(<abbr title="Universal Graph Normalization Algorithm 2011">UGNA2011</abbr>).
+</p>
+
+<section>
+<h3>Normalization Algorithm Terms</h3>
+ <dl>
+   <dt><tdef>label</tdef></dt>
+   <dd>
+     The subject IRI associated with a graph node. The subject IRI is expressed
+     using a key-value pair in a <tref>JSON object</tref> where the key is
+     <code>@subject</code> and the value is a string that is an IRI or
+     a <tref>JSON object</tref> containing the key <code>@iri</code> and
+     a value that is a string that is an IRI.
+   </dd>
+   <dt><tdef>list of expanded nodes</tdef></dt>
+   <dd>
+     A list of all nodes in the <tref>JSON-LD input</tref> graph containing no
+     embedded objects and having all keys and values expanded according to the
+     steps in the <a href="#expansion-algorithm">Expansion Algorithm</a>.
+   </dd>
+   <dt><tdef>alpha</tdef> and <tdef>beta</tdef> values</dt>
+   <dd>
+     The words <tref>alpha</tref> and <tref>beta</tref> refer to the first and
+     second nodes or values being examined in an algorithm. The names are
+     merely used to refer to each input value to a comparison algorithm.
+   </dd>
+   <dt><tdef>renaming counter</tdef></dt>
+   <dd>
+     A counter that is used during the
+     <a href="#node-relabeling-algorithm">Node Relabeling Algorithm</a>. The
+     counter typically starts at one (1) and counts up for every node that is
+     relabeled. There will be two such renaming counters in an implementation
+     of the normalization algorithm. The first is the
+     <tref>labeling counter</tref> and the second is the
+     <tref>deterministic labeling counter</tref>.
+   </dd>
+   <dt><tdef>serialization label</tdef></dt>
+   <dd>
+     An identifier that is created to aid in the normalization process in the
+     <a href="#deep-comparison-algorithm">Deep Comparison Algorithm</a>. The
+     value typically takes the form of <code>s&lt;NUMBER&gt;</code> or
+     <code>c&lt;NUMBER&gt;</code>.
+   </dd>
+</dl>
+</section>
+
+<section>
+<h3>Normalization State</h3>
+
+<p>When performing the steps required by the normalization algorithm,
+it is helpful to track the many pieces of information in a
+data structure called the <tdef>normalization state</tdef>. Many of these
+pieces simply provide indexes into the graph. The information
+contained in the <tref>normalization state</tref> is described below.</p>
+
+<dl>
+   <dt><tdef>node state</tdef></dt>
+   <dd>
+     Each node in the graph will be assigned a <tref>node state</tref>. This
+     state contains the information necessary to deterministically
+     <tref>label</tref> all nodes in the graph. A <tref>node state</tref>
+     includes:
+     <dl>
+        <dt><tdef>node reference</tdef></dt>
+        <dd>
+          A <tref>node reference</tref> is a reference to a node in the graph.
+          For a given <tref>node state</tref>, its <tref>node reference</tref>
+          refers to the node that the state is for. When a
+          <tref>node state</tref> is created, its <tref>node reference</tref>
+          should be to the node it is created for.
+        </dd>
+        <dt><tdef>outgoing list</tdef></dt>
+        <dd>
+          Lists the <tref>label</tref>s for all nodes that are properties of
+          the <tref>node reference</tref>. This list should be initialized
+          by iterating over every object associated with a property in the
+          <tref>node reference</tref> adding its label if it is another node.
+        </dd>
+        <dt><tdef>incoming list</tdef></dt>
+        <dd>
+          Lists the <tref>label</tref>s for all nodes in the graph for which
+          the <tref>node reference</tref> is a property. This list is
+          initialized to an empty list.
+        </dd>
+        <dt><tdef>outgoing serialization map</tdef></dt>
+        <dd>
+          Maps node <tref>label</tref>s to <tref>serialization label</tref>s.
+          This map is initialized to an empty map. When this map is populated,
+          it will be filled with keys that are the <tref>label</tref>s of every node in the
+          graph with a label that begins with <code>_:</code> and that has a
+          path, via properties, that starts with the
+          <tref>node reference</tref>.
+        </dd>
+        <dt><tdef>outgoing serialization</tdef></dt>
+        <dd>
+          A string that can be lexicographically compared to the
+          <tref>outgoing serialization</tref>s of other
+          <tref>node state</tref>s. It is a representation of the
+          <tref>outgoing serialization map</tref> and other related
+          information. This string is initialized to an empty string.
+        </dd>
+        <dt><tdef>incoming serialization map</tdef></dt>
+        <dd>
+          Maps node <tref>label</tref>s to <tref>serialization label</tref>s.
+          This map is initialized to an empty map. When this map is populated,
+          it will be filled with keys that are the <tref>label</tref>s of every
+          node in the graph with a <tref>label</tref> that begins with
+          <code>_:</code> and that has a path, via properties, that ends with
+          the <tref>node reference</tref>.
+        </dd>
+        <dt><tdef>incoming serialization</tdef></dt>
+        <dd>
+          A string that can be lexicographically compared to the
+          <tref>outgoing serialization</tref>s of other
+          <tref>node state</tref>s. It is a representation of the
+          <tref>incoming serialization map</tref> and other related
+          information. This string is initialized to an empty string.
+        </dd>
+     </dl>
+   </dd>
+   <dt><tdef>node state map</tdef></dt>
+   <dd>
+     A mapping from a node's <tref>label</tref> to a <tref>node state</tref>.
+     It is initialized to an empty map.
+   </dd>
+   <dt><tdef>labeling prefix</tdef></dt>
+   <dd>
+     The labeling prefix is a string that is used as the beginning of a node
+     <tref>label</tref>. It should be initialized to a random base string that
+     starts with the characters <code>_:</code>, is not used by any other
+     node's <tref>label</tref> in the <tref>JSON-LD input</tref>, and does not
+     start with the characters <code>_:c14n</code>. The prefix has two uses.
+     First it is used to temporarily name nodes during the normalization
+     algorithm in a way that doesn't collide with the names that already
+     exist as well as the names that will be generated by the normalization
+     algorithm. Second, it will eventually be set to <code>_:c14n</code> to
+     generate the final, deterministic labels for nodes in the graph. This
+     prefix will be concatenated with the <tref>labeling counter</tref> to
+     produce a node <tref>label</tref>. For example, <code>_:j8r3k</code> is
+     a proper initial value for the <tref>labeling prefix</tref>.
+   </dd>
+   <dt><tdef>labeling counter</tdef></dt>
+   <dd>
+     A counter that is used to label nodes. It is appended to the
+     <tref>labeling prefix</tref> to create a node <tref>label</tref>. It is
+     initialized to <code>1</code>.
+   </dd>
+   <dt><tdef>map of flattened nodes</tdef></dt>
+   <dd>
+     A map containing a representation of all nodes in the graph where the
+     key is a node <tref>label</tref> and the value is a single
+     <tref>JSON object</tref> that has no nested sub-objects
+     and has had all properties for the same node merged into a single
+     <tref>JSON object</tref>.
+   </dd>
+</dl>
+
+</section>
+
+<section>
+<h3>Normalization Algorithm</h3>
+
+<p>The normalization algorithm expands the <tref>JSON-LD input</tref>,
+flattens the data structure, and creates an initial set of names for all
+nodes in the graph. The flattened data structure is then processed by a
+node labeling algorithm in order to get a fully expanded and named list of
+nodes which is then sorted. The result is a deterministically named and
+ordered list of graph nodes.
+</p>
+
+<ol class="algorithm">
+<li>Expand the <tref>JSON-LD input</tref> according to the steps in
+the <a href="#expansion-algorithm">Expansion Algorithm</a> and store the
+result as the <strong>expanded input</strong>.</li>
+<li>Create a <tref>normalization state</tref>.</li>
+<li>Initialize the <tref>map of flattened nodes</tref> by recursively
+processing every <tdef>expanded node</tdef> in the
+<strong>expanded input</strong> in depth-first order:
+  <ol class="algorithm">
+    <li>If the <tref>expanded node</tref> is an unlabeled node, add a
+      new key-value pair to the <tref>expanded node</tref>
+      where the key is <code>@subject</code> and the value is the
+      concatenation of the <tref>labeling prefix</tref>
+      and the string value of the <tref>labeling counter</tref>.
+      Increment the <tref>labeling counter</tref>.</li>
+    <li>Add the <tref>expanded node</tref> to the
+      <tref>map of flattened nodes</tref>:
+      <ol class="algorithm">
+        <li>If the <tref>expanded node</tref>'s <tref>label</tref> is already
+          in the
+          <tref>map of flattened nodes</tref> merge all properties from the
+          entry in the <tref>map of flattened nodes</tref> into the
+          <tref>expanded node</tref>.</li>
+        <li>Go through every property associated with an array in the
+          <tref>expanded node</tref> and remove any duplicate IRI entries from
+          the array. If the resulting array only has one IRI entry, change it
+          from an array to an object.</li>
+        <li>Set the entry for the <tref>expanded node</tref>'s <tref>label</tref>
+          in the <tref>map of flattened nodes</tref> to the
+          <tref>expanded node</tref>.
+        </li></ol></li>
+    <li>After exiting the recursive step, replace the reference to the
+      <tref>expanded node</tref> with an object containing a single
+       key-value pair where the key is <code>@iri</code> and the value is
+       the value of the <code>@subject</code> key in the node.</li>
+  </ol></li>
+<li>For every entry in the <tref>map of flattened nodes</tref>, insert a
+  key-value pair into the <tref>node state map</tref> where the key is the
+  key from the <tref>map of flattened nodes</tref> and the value is a
+  <tref>node state</tref> where its <tref>node reference</tref> refers to
+  the value from the <tref>map of flattened nodes</tref>.
+<li>Populate the <tref>incoming list</tref> for each <tref>node state</tref>
+  by iterating over every node in the graph and adding its <tref>label</tref>
+  to the <tref>incoming list</tref> associated with each node found in its
+  properties.</li>
+<li>For every entry in the <tref>node state map</tref> that has a
+<tref>label</tref> that begins with <code>_:c14n</code>, relabel the node
+using the <a href="#node-relabeling-algorithm">Node Relabeling Algorithm</a>.
+<li>Label all of the nodes that contain a <code>@subject</code> key associated
+with a value starting with <code>_:</code> according to the steps in the
+<a href="#deterministic-labeling-algorithm">Deterministic Labeling Algorithm</a>.
+</li>
+</ol>
+</section>
+
+<section>
+<h4>Node Relabeling Algorithm</h4>
+
+<p>This algorithm renames a node by generating a unique
+<tdef>new label</tdef> and updating all references to that <tref>label</tref>
+in the <tref>node state map</tref>. The <tdef>old label</tdef> and the
+<tref>normalization state</tref> must be given as an input to the
+algorithm. The <tref>old label</tref> is the current <tref>label</tref> of
+the node that is to be relabeled.
+
+<p>The node relabeling algorithm is as follows:</p>
+
+<ol class="algorithm">
+  <li>If the <tref>labeling prefix</tref> is <code>_:c14n</code> and the
+    <tref>old label</tref> begins with <code>_:c14n</code> then return as
+    the node has already been renamed.
+  </li>
+  <li>Generate the <tdef>new label</tdef> by concatenating the
+    <tref>labeling prefix</tref> with the string value of the
+    <tref>labeling counter</tref>. Increment the <tref>labeling counter</tref>.
+  </li>
+  <li>For the <tref>node state</tref> associated with the
+  <tref>old label</tref>, update every node in the <tref>incoming list</tref>
+  by changing all the properties that reference the <tref>old label</tref> to
+  the <tref>new label</tref>.
+  </li>
+  <li>Change the <tref>old label</tref> key in the <tref>node state map</tref>
+    to the <tref>new label</tref> and set the associated
+    <tref>node reference</tref>'s <tref>label</tref> to the
+    <tref>new label</tref>.
+  </li>
+</ol>
+</section>
+
+<section>
+<h4>Deterministic Labeling Algorithm</h4>
+
+<p>The deterministic labeling algorithm takes the
+<tref>normalization state</tref>
+and produces a <tdef>list of finished nodes</tdef> that is sorted and
+contains deterministically named and expanded nodes from the graph.
+
+<ol class="algorithm">
+  <li>Set the <tref>labeling prefix</tref> to <code>_:c14n</code>, the
+    <tref>labeling counter</tref> to <code>1</code>,
+    the <tdef>list of finished nodes</tdef> to an empty array, and create
+    an empty array, the <tdef>list of unfinished nodes</tdef>.</li>
+  <li>For each <tref>node reference</tref> in the <tref>node state map</tref>:
+    <ol class="algorithm">
+      <li>If the node's <tref>label</tref> does not start with <code>_:</code>
+        then put the <tref>node reference</tref> in the
+        <tref>list of finished nodes</tref>.
+      </li>
+      <li>If the node's <tref>label</tref> does start with <code>_:</code>
+        then put the <tref>node reference</tref> in the
+        <tref>list of unfinished nodes</tref>.
+      </li>
+    </ol>
+  </li>
+  <li>Append to the <tref>list of finished nodes</tref> by processing
+    the remainder of the <tref>list of unfinished nodes</tref> until it is
+    empty:
+    <ol class="algorithm">
+      <li>Sort the <tref>list of unfinished nodes</tref> in descending order
+        according to the
+        <a href="#deep-comparison-algorithm">Deep Comparison Algorithm</a> to
+        determine the sort order.</li>
+      <li>Create a <tdef>list of labels</tdef> and initialize it to an
+        empty array.</li>
+      <li>For the first node from the <tref>list of unfinished nodes</tref>:
+        <ol class="algorithm">
+          <li>Add its <tref>label</tref> to the <tref>list of labels</tref>.
+          </li>
+          <li>For each key-value pair from its associated
+            <tref>outgoing serialization map</tref>, add the key to a list and
+            then sort the list according to the lexicographical order of the
+            keys' associated values. Append the list to the
+            <tref>list of nodes to label</tref>.
+          </li>
+          <li>For each key-value pair from its associated
+            <tref>incoming serialization map</tref>, add the key to a list and
+            then sort the list according to the lexicographical order of the
+            keys' associated values. Append the list to the
+            <tref>list of nodes to label</tref>.
+          </li></ol></li>
+      <li>For each <tref>label</tref> in the <tref>list of labels</tref>,
+        relabel the associated node according to the
+        <a href="#node-relabeling-algorithm">Node Relabeling Algorithm</a>. If
+        any <tref>outgoing serialization map</tref> contains a key that
+        matches the <tref>label</tref>, clear the map and set the associated
+        <tref>outgoing serialization</tref> to an empty string. If any
+        <tref>incoming serialization map</tref> contains a key that
+        matches the <tref>label</tref>, clear the map and set the associated
+        <tref>incoming serialization</tref> to an empty string.
+      </li>
+      <li>
+        Remove each node with a <tref>label</tref> that starts with
+        <code>_:c14n</code> from the <tref>list of unfinished nodes</tref> and
+        add it to the <tref>list of finished nodes</tref>.
+      </li>
+    </ol>
+  </li>
+  <li>Sort the <tref>list of finished nodes</tref> in descending order
+    according to the
+    <a href="#deep-comparison-algorithm">Deep Comparison Algorithm</a> to
+    determine the sort order.</li>
+</ol>
+</section>
+
+<section>
+<h4>Shallow Comparison Algorithm</h4>
+
+<p>
+The shallow comparison algorithm takes two unlabeled nodes,
+<tref>alpha</tref> and <tref>beta</tref>, as input and
+determines which one should come first in a sorted list. The following
+algorithm determines the steps that are executed in order to determine the
+node that should come first in a list:
+</p>
+
+<ol class="algorithm">
+  <li>Compare the total number of node properties. The node with fewer
+    properties is first.</li>
+  <li>Lexicographically sort the property IRIs for each node and compare
+    the sorted lists. If an IRI is found to be lexicographically smaller, the
+    node containing that IRI is first.</li>
+  <li>Compare the values of each property against one another:
+    <ol class="algorithm">
+      <li>The node associated with fewer property values is first.
+      </li>
+      <li>Create an <tdef>alpha list</tdef> by adding all values associated
+        with the <tref>alpha</tref> property that are not unlabeled nodes.
+      </li>
+      <li>Create a <tdef>beta list</tdef> by adding all values associated
+        with the <tref>beta</tref> property that is not an unlabeled node.
+      </li>
+      <li>Compare the length of <tref>alpha list</tref> and
+        <tref>beta list</tref>. The node associated with the list containing
+        the fewer number of items is first.</li>
+      <li>Sort <tref>alpha list</tref> and <tref>beta list</tref> according to
+        the
+        <a href="#object-comparison-algorithm">Object Comparison Algorithm</a>.
+        For each offset into the <tref>alpha list</tref>, compare the item
+        at the offset against the item at the same offset in the
+        <tref>beta list</tref> according to the
+        <a href="#object-comparison-algorithm">Object Comparison Algorithm</a>.
+        The node associated with the lesser item is first.
+    </ol></li>
+  <li>Process the <tref>incoming list</tref>s associated with each node to
+    determine order:
+    <ol class="algorithm">
+      <li>The node with the shortest <tref>incoming list</tref> is first.</li>
+      <li>Sort the <tref>incoming list</tref>s according to incoming property
+         and then incoming <tref>label</tref>.
+      <li>The node associated with the fewest number of incoming nodes is
+        first.</li>
+      <li>For each offset into the <tref>incoming list</tref>s,
+        compare the associated properties and <tref>label</tref>s:
+        <ol class="algorithm">
+          <li>The node associated with a <tref>label</tref> that does not begin with
+            <code>_:</code> is first.
+          </li>
+          <li>If the nodes' <tref>label</tref>s do not begin with
+            <code>_:</code>, then the node associated with the
+            lexicographically lesser <tref>label</tref> is first.</li>
+          </li>
+          <li>The node associated with the lexicographically lesser associated
+            property is first.
+          </li>
+          <li>The node with the <tref>label</tref> that does not begin with
+            <code>_:c14n</code> is first.
+          </li>
+          <li>The node with the lexicographically lesser <tref>label</tref>
+            is first.
+          </li>
+        </ol>
+    </ol></li>
+  <li>Otherwise, the nodes are equivalent.</li>
+</section>
+
+<section>
+<h4>Object Comparison Algorithm</h4>
+
+<p>
+The object comparison algorithm is designed to compare two graph node
+property values, <tref>alpha</tref> and <tref>beta</tref>, against the other.
+The algorithm is useful when sorting two lists of graph node properties.
+</p>
+
+<ol class="algorithm">
+  <li>If one of the values is a <tref>string</tref> and the other is not, the value that is
+    a string is first.
+  </li>
+  <li>If both values are <tref>string</tref>s, the lexicographically lesser string is
+    first.
+  </li>
+  <li>If one of the values is a literal and the other is not, the value that is
+    a literal is first.
+  </li>
+  <li>If both values are literals:
+    <ol class="algorithm">
+      <li>The lexicographically lesser string associated with
+        <code>@literal</code> is first.
+      </li>
+      <li>The lexicographically lesser string associated with
+        <code>@datatype</code> is first.
+      </li>
+      <li>The lexicographically lesser string associated with
+        <code>@language</code> is first.
+      </li>
+    </ol>
+  </li>
+  <li>If both values are expanded IRIs, the
+    lexicographically lesser string associated with <code>@iri</code>
+    is first.</li>
+  <li>Otherwise, the two values are equivalent.</li>
+</ol>
+
+</section>
+
+<section>
+<h4>Deep Comparison Algorithm</h4>
+
+<p>
+The deep comparison algorithm is used to compare the difference between two
+nodes, <tref>alpha</tref> and <tref>beta</tref>.
+A deep comparison takes the incoming and outgoing node edges in
+a graph into account if the number of properties and value of those properties
+are identical. The algorithm is helpful when sorting a list of nodes and will
+return whichever node should be placed first in a list if the two nodes are
+not truly equivalent.
+</p>
+
+<p>When performing the steps required by the deep comparison algorithm, it
+is helpful to track state information about mappings. The information
+contained in a <tref>mapping state</tref> is described below.</p>
+
+<dl class="algorithm">
+   <dt><tdef>mapping state</tdef></dt>
+   <dd>
+     <dl>
+        <dt><tdef>mapping counter</tdef></dt>
+        <dd>
+          Keeps track of the number of nodes that have been mapped to
+          <tref>serialization labels</tref>. It is initialized to
+          <code>1</code>.
+        </dd>
+        <dt><tdef>processed labels map</tdef></dt>
+        <dd>
+          Keeps track of the <tref>label</tref>s of nodes that have already
+          been assigned <tref>serialization label</tref>s. It is initialized
+          to an empty map.
+        </dd>
+        <dt><tdef>serialized labels map</tdef></dt>
+        <dd>
+          Maps a node <tref>label</tref> to its associated
+          <tref>serialization label</tref>. It is initialized to an empty map.
+        </dd>
+        <dt><tdef>adjacent info map</tdef></dt>
+        <dd>
+          Maps a <tref>serialization label</tref> to the node
+          <tref>label</tref> associated with it, the list of sorted
+          <tref>serialization label</tref>s for adjacent nodes, and the map of
+          adjacent node <tref>serialiation label</tref>s to their associated
+          node <tref>label</tref>s. It is initialized to an empty map.
+        </dd>
+        <dt><tdef>key stack</tdef></dt>
+        <dd>
+          A stack where each element contains an array of adjacent
+          <tref>serialization label</tref>s and an index into that array. It
+          is initialized to a stack containing a single element where its
+          array contains a single string element <code>s1</code> and its
+          index is set to <code>0</code>.
+        </dd>
+        <dt><tdef>serialized keys</tdef></dt>
+        <dd>
+          Keeps track of which <tref>serialization label</tref>s have already
+          been written at least once to the <tref>serialization string</tref>.
+          It is initialized to an empty map.
+        </dd>
+        <dt><tdef>serialization string</tdef></dt>
+        <dd>
+          A string that is incrementally updated as a serialization is built.
+          It is initialized to an empty string.
+        </dd>
+     </dl>
+   </dd>
+</dl>
+
+<p>The deep comparison algorithm is as follows:</p>
+
+<ol class="algorithm">
+  <li>Perform a comparison between <tref>alpha</tref> and <tref>beta</tref>
+    according to the
+    <a href="#shallow-comparison-algorithm">Shallow Comparison Algorithm</a>.
+    If the result does not show that the two nodes are equivalent, return
+    the result.
+    </li>
+  <li>Compare incoming and outgoing edges for each node, updating their
+    associated <tref>node state</tref> as each node is processed:
+    <ol class="algorithm">
+      <li>If the <tref>outgoing serialization map</tref> for <tref>alpha</tref>
+        is empty, generate the serialization according to the
+        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
+        Provide <tref>alpha</tref>'s <tref>node state</tref>, a new
+        <tref>mapping state</tref>,
+        <code>outgoing direction</code> to the algorithm as inputs.
+      <li>If the <tref>outgoing serialization map</tref> for <tref>beta</tref>
+        is empty, generate the serialization according to the
+        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
+        Provide <tref>beta</tref>'s <tref>node state</tref>, a new
+        <tref>mapping state</tref>, and
+        <code>outgoing direction</code> to the algorithm as inputs.
+      <li>If <tref>alpha</tref>'s <tref>outgoing serialization</tref> is
+        lexicographically less than <tref>beta</tref>'s, then
+        <tref>alpha</tref> is first. If it is greater, then <tref>beta</tref>
+        is first.</li>
+      <li>If the <tref>incoming serialization map</tref> for <tref>alpha</tref>
+        is empty, generate the serialization according to the
+        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
+        Provide <tref>alpha</tref>'s <tref>node state</tref>, a new
+        <tref>mapping state</tref> with its <tref>serialized labels map</tref>
+        set to a copy of <tref>alpha</tref>'s
+        <tref>outgoing serialization map</tref>, and
+        <code>incoming direction</code> to the algorithm as inputs.
+      <li>If the <tref>incoming serialization map</tref> for <tref>beta</tref>
+        is empty, generate the serialization according to the
+        <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
+        Provide <tref>beta</tref>'s <tref>node state</tref>, a new
+        <tref>mapping state</tref> with its <tref>serialized labels map</tref>
+        set to a copy of <tref>beta</tref>'s
+        <tref>outgoing serialization map</tref>, and
+        <code>incoming direction</code> to the algorithm as inputs.
+      <li>If <tref>alpha</tref>'s <tref>incoming serialization</tref> is
+        lexicographically less than <tref>beta</tref>'s, then
+        <tref>alpha</tref> is first. If it is greater, then <tref>beta</tref>
+        is first.</li>
+    </ol></li>
+</ol>
+</section>
+
+<section>
+<h4>Node Serialization Algorithm</h4>
+
+<p>
+The node serialization algorithm takes a <tref>node state</tref>, a
+<tref>mapping state</tref>, and a <tdef>direction</tdef> (either
+<code>outgoing direction</code> or <code>incoming direction</code>) as
+inputs and generates a deterministic serialization for the
+<tref>node reference</tref>.
+</p>
+
+<ol class="algorithm">
+<li>If the <tref>label</tref> exists in the
+  <tref>processed labels map</tref>, terminate the algorithm as the
+  <tref>serialization label</tref> has already been created.
+</li>
+<li>Set the value associated with the <tref>label</tref> in the
+  <tref>processed labels map</tref> to <code>true</code>.
+</li>
+<li>Generate the next <tdef>serialization label</tdef> for the
+  <tref>label</tref> according to the
+  <a href="#serialization-label-generation-algorithm">Serialization Label Generation Algorithm</a>.
+</li>
+<li>Create an empty map called the <tdef>adjacent serialized labels map</tdef>
+that will store mappings from <tref>serialized label</tref>s to adjacent
+node <tref>label</tref>s.</li>
+<li>Create an empty array called the
+<tdef>adjacent unserialized labels list</tdef> that will store
+<tref>label</tref>s of adjacent nodes that haven't been assigned
+<tref>serialization label</tref>s yet.
+</li>
+<li>For every <tref>label</tref> in a list, where the list the <tref>outgoing list</tref> if
+the <tref>direction</tref> is <code>outgoing direction</code> and the
+<tref>incoming list</tref> otherwise, if the <tref>label</tref> starts with
+<code>_:</code>, it is the <tdef>target node label</tdef>:
+  <ol class="algorithm">
+    <li>Look up the <tref>target node label</tref> in the
+      <tref>processed labels map</tref> and if a mapping exists,
+      update the <tref>adjacent serialized labels map</tref> where the key is
+      the value in the <tref>serialization map</tref> and the value is the
+      <tref>target node label</tref>.</li>
+    <li>Otherwise, add the <tref>target node label</tref> to the
+      <tref>adjacent unserialized labels list</tref>.
+  </ol>
+</li>
+<li>Set the <tdef>maximum serialization combinations</tdef> to
+  <code>1</code> or the length of the
+  <tref>adjacent unserialized labels list</tref>, whichever is greater.</li>
+<li>While the <tref>maximum serialization combinations</tref> is greater than
+  <code>0</code>, perform the
+  <a href="#combinatorial-serialization-algorithm">Combinatorial Serialization Algorithm</a>
+  passing the <tref>node state</tref>, the <tref>mapping state</tref> for the
+  first iteration and a copy of it for each subsequent iteration, the
+  generated <tref>serialization label</tref>, the <tref>direction</tref>,
+  the <tref>adjacent serialized labels map</tref>, and the
+  <tref>adjacent unserialized labels list</tref>.
+  Decrement the <tref>maximum serialization combinations</tref> by
+  <code>1</code> for each iteration.
+</ol>
+
+</section>
+
+<section>
+<h4>Serialization Label Generation Algorithm</h4>
+
+<p>
+The algorithm generates a <tref>serialization label</tref> given a
+<tref>label</tref> and a <tref>mapping state</tref> and returns the
+<tref>serialization label</tref>.
+</p>
+
+ <ol class="algorithm">
+   <li>If the <tref>label</tref> is already in the
+     <tref>serialization labels map</tref>, return its associated value.
+   </li>
+   <li>If the <tref>label</tref> starts with the string <code>_:c14n</code>,
+     the <tref>serialization label</tref> is the letter <code>c</code>
+     followed by the number that follows <code>_:c14n</code> in the
+     <tref>label</tref>.
+   </li>
+   <li>Otherwise, the <tref>serialization label</tref> is the
+     letter <code>s</code> followed by the string value of
+     <tref>mapping count</tref>. Increment the <tref>mapping count</tref> by
+     <code>1</code>.
+   </li>
+   <li>Create a new key-value pair in the <tref>serialization labels map</tref>
+     where the key is the <tref>label</tref> and the value is the
+     generated <tref>serialization label</tref>.
+   </li>
+ </ol>
+</section>
+
+<section>
+<h4>Combinatorial Serialization Algorithm</h4>
+
+<p>
+The combinatorial serialization algorithm takes a <tref>node state</tref>, a
+<tref>mapping state</tref>, a <tref>serialization label</tref>, a
+<tref>direction</tref>, a <tref>adjacent serialized labels map</tref>,
+and a <tref>adjacent unserialized labels list</tref> as inputs and generates
+the lexicographically least serialization of nodes relating to the
+<tref>node reference</tref>.
+</p>
+
+<ol class="algorithm">
+  <li>If the <tref>adjacent unserialized labels list</tref> is not empty:
+    <ol class="algorithm">
+      <li>Copy the <tref>adjacent serialized labels map</tref> to the
+        <tdef>adjacent serialized labels map copy</tdef>.</li>
+      <li>Remove the first <tref>unserialized label</tref> from the
+        <tref>adjacent unserialized labels list</tref> and create a new
+        <tdef>new serialization label</tdef> according to the
+        <a href="#serialization-label-generation-algorithm">Serialization Label Generation Algorithm</a>.
+      <li>Create a new key-value mapping in the
+        <tref>adjacent serialized labels map copy</tref>
+        where the key is the <tref>new serialization label</tref> and the value
+        is the <tref>unserialized label</tref>.
+      <li>Set the <tdef>maximum serialization rotations</tdef> to
+        <code>1</code> or the length of the
+        <tref>adjacent unserialized labels list</tref>, whichever is greater.
+      </li>
+      <li>While the <tref>maximum serialization rotations</tref> is greater than
+        <code>0</code>:
+        <ol class="algorithm">
+          <li>Recursively perform the
+            <a href="#combinatorial-serialization-algorithm">Combinatorial Serialization Algorithm</a>
+            passing the <tref>mapping state</tref> for the first iteration of the
+            loop, and a copy of it for each subsequent iteration.
+          </li>
+          <li>Rotate the elements in the
+            <tref>adjacent unserialized labels list</tref> by shifting each of
+            them once to the right, moving the element at the end of the list
+            to the beginning of the list.
+          </li>
+          <li>Decrement the <tref>maximum serialization rotations</tref> by
+            <code>1</code> for each iteration.
+          </li>
+        </ol>
+      </li>
+    </ol>
+  </li>
+  <li>If the <tref>adjacent unserialized labels list</tref> is empty:
+    <ol class="algorithm">
+      <li>Create a <tdef>list of keys</tdef> from the keys in the
+        <tref>adjacent serialized labels map</tref> and sort it
+        lexicographically.
+      </li>
+      <li>Add a key-value pair to the <tref>adjacent info map</tref> where
+        the key is the <tref>serialization label</tref> and the value is
+        an object containing the <tref>node reference</tref>'s label, the
+        <tref>list of keys</tref> and the
+        <tref>adjacent serialized labels map</tref>.
+      </li>
+      <li>Update the <tref>serialization string</tref> according to the
+        <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>.
+      </li>
+      <li>If the <tref>direction</tref> is <code>outgoing direction</code>
+        then <tdef>directed serialization</tdef> refers to the
+        <tref>outgoing serialization</tref> and the
+        <tdef>directed serialization map</tdef> refers to the
+        <tref>outgoing serialization map</tref>, otherwise it refers to the
+        <tref>incoming serialization</tref> and the
+        <tref>directed serialization map</tref> refers to the
+        <tref>incoming serialization map</tref>. Compare the
+        <tref>serialization string</tref> to the
+        <tref>directed serialization</tref> according to the
+        <a href="#mapping-serialization-algorithm">Serialization Comparison Algorithm</a>.
+        If the <tref>serialization string</tref> is less than or equal to
+        the <tref>directed serialization</tref>:
+        <ol class="algorithm">
+          <li>For each value in the <tref>list of keys</tref>, run the
+            <a href="#node-serialization-algorithm">Node Serialization Algorithm</a>.
+          </li>
+	       <li>Update the <tref>serialization string</tref> according to the
+	         <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>.
+	       </li>
+	       <li>Compare the <tref>serialization string</tref> to the
+	         <tref>directed serialization</tref> again and if it is less than
+	         or equal and the length of the <tref>serialization string</tref> is
+	         greater than or equal to the length of the
+	         <tref>directed serialization</tref>, then set the
+	         <tref>directed serialization</tref> to the
+	         <tref>serialization string</tref> and set the
+	         <tref>directed serialization map</tref> to the
+	         <tref>serialized labels map</tref>.
+	       </li>
+        </ol>
+      </li>
+    </ol>
+  </li>
+</ol>
+
+</section>
+
+<section>
+<h4>Serialization Comparison Algorithm</h4>
+
+<p>
+The serialization comparison algorithm takes two serializations,
+<tref>alpha</tref> and <tref>beta</tref> and returns either which of the two
+is less than the other or that they are equal.
+</p>
+
+<ol class="algorithm">
+  <li>Whichever serialization is an empty string is greater. If they are
+    both empty strings, they are equal.</li>
+  <li>Return the result of a lexicographical comparison of <tref>alpha</tref>
+    and <tref>beta</tref> up to the number of characters in the shortest of
+    the two serializations.
+  </li>
+</ol>
+</section>
+
+<section>
+<h4>Mapping Serialization Algorithm</h4>
+
+<p>
+The mapping serialization algorithm incrementally updates the
+<tref>serialization string</tref> in a <tref>mapping state</tref>.
+</p>
+
+<ol class="algorithm">
+  <li>If the <tref>key stack</tref> is not empty:
+    <ol class="algorithm">
+      <li>Pop the <tdef>serialization key info</tdef> off of the
+        <tref>key stack</tref>.
+      </li>
+      <li>For each <tdef>serialization key</tdef> in the
+        <tref>serialization key info</tref> array, starting at
+        the <tdef>serialization key index</tdef> from the
+        <tref>serialization key info</tref>:
+        <ol class="algorithm">
+          <li>If the <tref>serialization key</tref> is not in the
+            <tref>adjacent info map</tref>, push the
+            <tref>serialization key info</tref> onto the
+            <tref>key stack</tref> and exit from this loop.
+          </li>
+          <li>If the <tref>serialization key</tref> is a key in
+            <tref>serialized keys</tref>, a cycle has been detected. Append
+            the concatenation of the <code>_</code> character and the
+            <tref>serialization key</tref> to the
+            <tref>serialization string</tref>.
+          <li>Otherwise, serialize all outgoing and incoming edges in the
+            related node by performing the following steps:
+            <ol class="algorithm">
+              <li>Mark the <tref>serialization key</tref> as having
+                been processed by adding a new key-value pair to
+                <tref>serialized keys</tref> where the key
+                is the <tref>serialization key</tref> and the value is
+                <code>true</code>.
+              </li>
+              <li>Set the <tdef>serialization fragment</tdef> to the value of
+                the <tref>serialization key</tref>.</li>
+              <li>Set the <tref>adjacent info</tref> to the value of the
+                <tref>serialization key</tref> in the
+                <tref>adjacent info map</tref>.
+              </li>
+              <li>Set the <tref>adjacent node label</tref> to the node
+                <tref>label</tref> from the <tref>adjacent info</tref>.
+              </li>
+              <li>If a mapping for the <tref>adjacent node label</tref>
+                exists in the <tref>map of all labels</tref>:
+                <ol class="algorithm">
+                  <li>Append the result of the
+                    <a href="">Label Serialization Algorithm</a> to the
+                    <tref>serialization fragment</tref>.
+                  </li>
+                </ol>
+              </li>
+              <li>Append all of the keys in the <tref>adjacent info</tref>
+                to the <tref>serialization fragment</tref>.
+              </li>
+              <li>Append the <tref>serialization fragment</tref> to the
+                <tref>serialization string</tref>.
+              </li>
+              <li>Push a new key info object containing the keys from the
+                <tref>adjacent info</tref> and an index of <code>0</code>
+                onto the <tref>key stack</tref>.
+              </li>
+              <li>Recursively update the <tref>serialization string</tref>
+                according to the
+                <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>.
+              </li>
+            </ol>
+          </li>
+        </ol>
+      </li>
+    </ol>
+  </li>
+</ol>
+
+</section>
+
+<section>
+<h4>Label Serialization Algorithm</h4>
+
+<p>
+The label serialization algorithm serializes information about a node that
+has been assigned a particular <tref>serialization label</tref>.
+</p>
+
+<ol class="algorithm">
+  <li>Initialize the <tref>label serialization</tref> to an empty string.</li>
+  <li>Append the <code>[</code> character to the
+    <tref>label serialization</tref>.</li>
+  <li>Append all properties to the <tref>label serialization</tref> by
+    processing each key-value pair in the <tref>node reference</tref>,
+    excluding the
+    <code>@subject</code> property. The keys should be processed in
+    lexicographical order and their associated values should be processed
+    in the order produced by the
+    <a href="#object-comparison-algorithm">Object Comparison Algorithm</a>:
+    <ol class="algorithm">
+      <li>Build a string using the pattern <code>&lt;</code><strong>KEY</strong><code>&gt;</code>
+        where <strong>KEY</strong> is the current key. Append string to the
+        <tref>label serialization</tref>.</li>
+      <li>The value may be a single object or an array of objects.
+        Process all of the objects that are associated with the key, building
+        an <tdef>object string</tdef> for each item:
+        <ol class="algorithm">
+          <li>If the object contains an <code>@iri</code> key with a
+            value that starts
+            with <code>_:</code>, set the <tref>object string</tref> to
+            the value <code>_:</code>. If the value does not
+            start with <code>_:</code>, build the <tref>object string</tref>
+            using the pattern
+            <code>&lt;</code><strong>IRI</strong><code>&gt;</code>
+            where <strong>IRI</strong> is the value associated with the
+            <code>@iri</code> key.</li>
+          <li>If the object contains a <code>@literal</code> key and a
+            <code>@datatype</code> key, build the <tref>object string</tref>
+            using the pattern
+            <code>"</code><strong>LITERAL</strong><code>"^^&lt;</code><strong>DATATYPE</strong><code>&gt;</code>
+            where <strong>LITERAL</strong> is the value associated with the
+            <code>@literal</code> key and <strong>DATATYPE</strong> is the
+            value associated with the <code>@datatype</code> key.</li>
+          <li>If the object contains a <code>@literal</code> key and a
+            <code>@language</code> key, build the <tref>object string</tref>
+            using the pattern
+            <code>"</code><strong>LITERAL</strong><code>"@</code><strong>LANGUAGE</strong>
+            where <strong>LITERAL</strong> is the value associated with the
+            <code>@literal</code> key and <strong>LANGUAGE</strong> is the
+            value associated with the <code>@language</code> key.</li>
+          <li>Otherwise, the value is a string. Build the
+            <tref>object string</tref> using the pattern
+            <code>"</code><strong>LITERAL</strong><code>"</code>
+            where <strong>LITERAL</strong> is the value associated with the
+            current key.</li>
+          <li>If this is the second iteration of the loop,
+            append a <code>|</code> separator character to the
+            <tref>label serialization</tref>.</li>
+          <li>Append the <tref>object string</tref> to the
+            <tref>label serialization</tref>.</li>
+        </ol>
+    </ol>
+  </li>
+  <li>Append the <code>]</code> character to the
+    <tref>label serialization</tref>.</li>
+  <li>Append the <code>[</code> character to the
+    <tref>label serialization</tref>.</li>
+  <li>Append all incoming references for the current
+    <tref>label</tref> to the <tref>label serialization</tref> by
+    processing all of the items associated with the <tref>incoming list</tref>:
+    <ol class="algorithm">
+      <li>Build a <tdef>reference string</tdef>
+        using the pattern <code>&lt;</code><strong>PROPERTY</strong><code>&gt;</code><code>&lt;</code><strong>REFERER</strong><code>&gt;</code>
+        where <strong>PROPERTY</strong> is the property associated with the
+        incoming reference and <strong>REFERER</strong> is either the subject of
+        the node referring to the <tref>label</tref> in the incoming reference
+        or <code>_:</code> if <strong>REFERER</strong> begins with
+        <code>_:</code>.
+      <li>If this is the second iteration of the loop,
+        append a <code>|</code> separator character to the
+        <tref>label serialization</tref>.</li>
+      <li>Append the <tref>reference string</tref> to the
+        <tref>label serialization</tref>.</li>
+    </ol>
+  <li>Append the <code>]</code> character to the
+    <tref>label serialization</tref>.</li>
+  <li>Append all <tref>adjacent node labels</tref> to the
+    <tref>label serialization</tref> by concatenating the string value
+    for all of them, one after the other, to the
+    <tref>label serialization</tref>.</li>
+  <li>Push the <tref>adjacent node labels</tref> onto the
+    <tref>key stack</tref> and append the result of the
+    <a href="#mapping-serialization-algorithm">Mapping Serialization Algorithm</a>
+    to the <tref>label serialization</tref>.
+</ol>
+
+</section>
+
+</section>
+
+<section>
+
+<h3>Data Round Tripping</h3>
+
+<p>When normalizing <strong>xsd:double</strong> values, implementers MUST
+ensure that the normalized value is a string. In order to generate the
+string from a <strong>double</strong> value, output equivalent to the
+<code>printf("%1.6e", value)</code> function in C MUST be used where
+<strong>"%1.6e"</strong> is the string formatter and <strong>value</strong>
+is the value to be converted.</p>
+
+<p>To convert the a double value in JavaScript, implementers can use the
+following snippet of code:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+// the variable 'value' below is the JavaScript native double value that is to be converted
+(value).toExponential(6).replace(/(e(?:\+|-))([0-9])$/, '$10$2')
+-->
+</pre>
+
+<p class="note">When data needs to be normalized, JSON-LD authors should
+not use values that are going to undergo automatic conversion. This is due
+to the lossy nature of <strong>xsd:double</strong> values.</p>
+
+<p class="note">Some JSON serializers, such as PHP's native implementation,
+backslash-escapes the forward slash character. For example, the value
+<code>http://example.com/</code> would be serialized as
+<code>http:\/\/example.com\/</code> in some
+versions of PHP. This is problematic when generating a byte
+stream for processes such as normalization. There is no need to
+backslash-escape forward-slashes in JSON-LD. To aid interoperability between
+JSON-LD processors, a JSON-LD serializer MUST NOT backslash-escape
+forward slashes.</p>
+
+<p class="issue">Round-tripping data can be problematic if we mix and
+match @coerce rules with JSON-native datatypes, like integers. Consider the
+following code example:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+var myObj = { "@context" : {
+                "number" : "http://example.com/vocab#number",
+                "@coerce": {
+                   "xsd:nonNegativeInteger": "number"
+                }
+              },
+              "number" : 42 };
+
+// Map the language-native object to JSON-LD
+var jsonldText = jsonld.normalize(myObj);
+
+// Convert the normalized object back to a JavaScript object
+var myObj2 = jsonld.parse(jsonldText);
+-->
+</pre>
+
+<p class="issue">At this point, myObj2 and myObj will have different
+values for the "number" value. myObj will be the number 42, while
+myObj2 will be the string "42". This type of data round-tripping
+error can bite developers. We are currently wondering if having a
+"coerce validation" phase in the parsing/normalization phases would be a
+good idea. It would prevent data round-tripping issues like the
+one mentioned above.</p>
+
+</section>
+
+<section>
+<h2>RDF Conversion</h2>
+
+<p>A JSON-LD document MAY be converted to any other RDF-compatible document
+format using the algorithm specified in this section.</p>
+
+<p>
+  The JSON-LD Processing Model describes processing rules for extracting RDF
+  from a JSON-LD document. Note that many uses of JSON-LD may not require
+  generation of RDF.
+</p>
+
+<p>
+The processing algorithm described in this section is provided in
+order to demonstrate how one might implement a JSON-LD to RDF processor.
+Conformant implementations are only required to produce the same type and
+number of triples during the output process and are not required to
+implement the algorithm exactly as described.
+</p>
+
+<p class="issue">The RDF Conversion Algorithm is a work in progress.</p>
+
+<section class="informative">
+  <h4>Overview</h4>
+  <p>
+    JSON-LD is intended to have an easy to parse grammar that closely models existing
+    practice in using JSON for describing object representations. This allows the use
+    of existing libraries for parsing JSON.
+  </p>
+  <p>
+    As with other grammars used for describing <tref>Linked Data</tref>, a key concept is that of
+    a <em>resource</em>. Resources may be of three basic types: <em>IRI</em>s, for describing
+    externally named entities, <em>BNodes</em>, resources for which an external name does not
+    exist, or is not known, and Literals, which describe terminal entities such as strings,
+    dates and other representations having a lexical representation possibly including
+    an explicit language or datatype.
+  </p>
+  <p>
+    Data described with JSON-LD may be considered to be the representation of a graph made
+    up of <tref>subject</tref> and <tref>object</tref> resources related via a <tref>property</tref> resource.
+    However, specific implementations may choose to operate on the document as a normal
+    JSON description of objects having attributes.
+  </p>
+</section>
+
+<section>
+  <h4>RDF Conversion Algorithm Terms</h4>
+  <dl>
+    <dt><tdef>default graph</tdef></dt>
+    <dd>
+      the destination graph for all triples generated by JSON-LD markup.
+    </dd>
+  </dl>
+</section>
+
+<section>
+  <h3>RDF Conversion Algorithm</h3>
+  <p>
+    The algorithm below is designed for in-memory implementations with random access to <tref>JSON object</tref> elements.
+  </p>
+  <p>
+    A conforming JSON-LD processor implementing RDF conversion MUST implement a
+    processing algorithm that results in the same <tref>default graph</tref> that the following
+    algorithm generates:
+  </p>
+
+  <ol class="algorithm">
+    <li id="processing-step-default-context">
+      Create a new <tref>processor state</tref> with with the <tref>active context</tref> set to the
+      <tref>initial context</tref> and <tref>active subject</tref> and <tref>active property</tref>
+      initialized to NULL.
+    </li>
+
+    <li id="processing-step-associative">
+      If a <tref>JSON object</tref> is detected, perform the following steps:
+      <ol class="algorithm">
+        <li>
+          If the <tref>JSON object</tref> has a <code>@context</code> key, process the local context as
+          described in <a href="#context">Context</a>.
+        </li>
+        <li>
+          Create a new <tref>JSON object</tref> by mapping the keys from the current <tref>JSON object</tref> using the
+          <tref>active context</tref> to new keys using the associated value from the current <tref>JSON object</tref>.
+          Repeat the mapping until no entry is found within the <tref>active context</tref> for the key. Use the new
+          <tref>JSON object</tref> in subsequent steps.
+        </li>
+        <li>
+          If the <tref>JSON object</tref> has an <code>@iri</code> key, set the <tref>active object</tref> by
+          performing <a href="#iri-expansion">IRI Expansion</a> on the associated value. Generate a
+          triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
+          <tref>active object</tref>. Return the <tref>active object</tref> to the calling location.
+          <p class="issue"><code>@iri</code> really just behaves the same as <code>@subject</code>, consider consolidating them.</p>
+        </li>
+        <li>
+          If the <tref>JSON object</tref> has a <code>@literal</code> key, set the <tref>active object</tref>
+          to a literal value as follows:
+          <ol class="algorithm">
+            <li>
+              as a <tref>typed literal</tref> if the <tref>JSON object</tref> contains a <code>@datatype</code> key
+              after performing <a href="#iri-expansion">IRI Expansion</a> on the specified<code>@datatype</code>.
+            </li>
+            <li>
+              otherwise, as a <tref>plain literal</tref>. If the <tref>JSON object</tref> contains
+              a <code>@language</code> key, use it's value to set the language of the plain literal.
+            </li>
+            <li>
+              Generate a triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
+              <tref>active object</tref>. Return the <tref>active object</tref> to the calling location.
+            </li>
+          </ol>
+        </li>
+        <li id="processing-step-subject">If the <tref>JSON object</tref> has a <code>@subject</code> key:
+          <ol class="algorithm">
+            <li>
+              If the value is a <tref>string</tref>, set the <tref>active object</tref> to the result of performing
+              <a href="#iri-expansion">IRI Expansion</a>. Generate a
+              triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
+              <tref>active object</tref>. Set the <tref>active subject</tref> to the <tref>active object</tref>.
+            </li>
+            <li>
+              Create a new <tref>processor state</tref> using copies of the <tref>active context</tref>,
+              <tref>active subject</tref> and <tref>active property</tref> and process the value
+              starting at <a href="#processing-step-associative">Step 2</a>, set the <tref>active
+              subject</tref> to the result and proceed using the previous <tref>processor state</tref>.
+            </li>
+          </ol>
+        </li>
+        <li>
+          If the <tref>JSON object</tref> does not have a <code>@subject</code> key, set the <tref>active
+          object</tref> to newly generated <tdef>blank node identifier</tdef>. Generate a triple
+          representing the <tref>active subject</tref>, the <tref>active property</tref> and the
+          <tref>active object</tref>. Set the <tref>active subject</tref> to the <tref>active
+          object</tref>.
+        </li>
+        <li>
+          For each key in the <tref>JSON object</tref> that has not already been processed, perform
+          the following steps:
+          <ol class="algorithm">
+            <li>
+              If the key is <code>@type</code>, set the <tref>active property</tref>
+              to <code>rdf:type</code>.
+            </li>
+            <li>Otherwise, set the <tref>active property</tref> to the result of performing
+            <a href="#iri-expansion">IRI Expansion</a> on the key.</li>
+            <li>
+              Create a new <tref>processor state</tref> copies of the <tref>active context</tref>,
+              <tref>active subject</tref> and <tref>active property</tref> and process the value
+              starting at <a href="#processing-step-associative">Step 2</a> and proceed using the
+              previous <tref>processor state</tref>.
+            </li>
+          </ol>
+        </li>
+        <li>
+          Return the <tref>active object</tref> to the calling location.
+        </li>
+      </ol>
+    </li>
+
+    <li>
+      If a regular <tref>array</tref> is detected, process each value in the <tref>array</tref> by doing the following
+      returning the result of processing the last value in the <tref>array</tref>:
+
+      <ol class="algorithm">
+        <li>
+          Create a new <tref>processor state</tref> using copies of the <tref>active
+          context</tref>, <tref>active subject</tref> and <tref>active property</tref> and process the value
+          starting at <a href="#processing-step-associative">Step 2</a> then proceed using the previous
+          <tref>processor state</tref>.
+        </li>
+      </ol>
+    </li>
+
+    <li>
+      If a <tref>string</tref> is detected:
+      <ol class="algorithm">
+        <li>
+          If the <tref>active property</tref> is the target of a <code>@iri</code> coercion,
+          set the <tref>active object</tref> by
+          performing <a href="#iri-expansion">IRI Expansion</a> on the string.
+        </li>
+        <li>
+          Otherwise, if the <tref>active property</tref> is the target of coercion,
+          set the <tref>active object</tref> by creating a <tref>typed literal</tref> using
+          the string and the coercion key as the datatype IRI.
+        </li>
+        <li>
+          Otherwise, set the <tref>active object</tref> to a <tref>plain literal</tref> value created from
+          the string.
+        </li>
+      </ol>
+      Generate a
+      triple representing the <tref>active subject</tref>, the <tref>active property</tref> and the
+      <tref>active object</tref>.
+    </li>
+
+    <li>
+      If a <tref>number</tref> is detected, generate a <tref>typed literal</tref> using a string representation of
+      the value with datatype set to either <code>xsd:integer</code> or
+      <code>xsd:double</code>, depending on if the value contains a
+      fractional and/or an exponential component. Generate a triple using the <tref>active
+      subject</tref>, <tref>active property</tref> and the generated typed literal.
+    </li>
+
+    <li>
+      Otherwise, if <strong>true</strong> or <strong>false</strong> is detected,
+      generate a triple using the <tref>active subject</tref>, <tref>active property</tref>
+      and a <tref>typed literal</tref> value created from the string representation of the
+      value with datatype set to <code>xsd:boolean</code>.
+    </li>
+  </ol>
+</section>
+
+<!-- THIS SHOULD BE SPLIT OUT INTO A SEPARATE DOCUMENT
+
+<section>
+<h1>Best Practices</h1>
+
+<p>The nature of Web programming allows one to use basic technologies, such as
+JSON-LD, across a variety of systems and environments. This section attempts to
+describe some of those environments and the way in which JSON-LD can be
+integrated in order to help alleviate certain development headaches.
+</p>
+
+<section>
+<h2>JavaScript</h2>
+
+<p class="issue">It is expected that JSON-LD will be used quite a bit in
+JavaScript environments, however, features like the expanded form for
+object values mean that using JSON-LD directly in JavaScript may be
+annoying without a middleware layer such as a simple library that
+converts JSON-LD markup before JavaScript uses it. One could say that JSON-LD
+is a good fit for the RDF API, which enables a variety of RDF-based
+Web Applications, but some don't want to require that level of functionality
+just to use JSON-LD. The group is still discussing the best way to proceed,
+so input on how JSON-LD could more easily be utilized in JavaScript
+environments would be very much appreciated.
+</p>
+</section>
+
+<section>
+<h2>Schema-less Databases</h2>
+
+<p class="issue">Databases such as CouchDB and MongoDB allow the creation of
+schema-less data stores. RDF is a type of schema-less data model and thus
+lends itself to databases such as CouchDB and MongoDB. Both of these databases
+can use JSON-LD as their storage format. The group needs feedback from
+CouchDB and MongoDB experts regarding the usefulness of JSON-LD in those
+environments.</p>
+
+<p class="issue">MongoDB does not allow the '.' character to be used in
+key names. This prevents developers from storing IRIs as keys, which also
+prevents storage of the data in normalized form. While this issue can
+be avoided by using <tref>prefix</tref>es for key values, it is not known if this
+mechanism is enough to allow JSON-LD to be used in MongoDB in a way that
+is useful to developers.
+</p>
+
+-->
+</section>
+
+</section>
+
+<section class="appendix">
+<h1>Experimental Concepts</h1>
+
+<p class="issue">There are a few advanced concepts where it is not clear
+whether or not the JSON-LD specification is going to support the complexity
+necessary to support each concept. The entire section on Advanced Concepts
+should be considered as discussion points; it is merely a list of
+possibilities where all of the benefits and drawbacks have not been explored.
+</p>
+
+<section>
+<h2>Disjoint Graphs</h2>
+
+<p>When serializing an RDF graph that contains two or more sections of the
+graph which are entirely disjoint, one must use an <tref>array</tref> to express the graph
+as two graphs. This may not be acceptable to some authors, who would rather
+express the information as one graph. Since, by definition, disjoint graphs
+require there to be two top-level objects, JSON-LD utilizes a mechanism that
+allows disjoint graphs to be expressed using a single graph.</p>
+
+<p>Assume the following RDF graph:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<http://example.org/people#john>
+   <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
+      <http://xmlns.com/foaf/0.1/Person> .
+<http://example.org/people#jane>
+   <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
+      <http://xmlns.com/foaf/0.1/Person> .
+-->
+</pre>
+
+<p>Since the two subjects are entirely disjoint with one another, it is
+impossible to express the RDF graph above using a single <tref>JSON object</tref>.</p>
+
+<p>In JSON-LD, one can use the subject to express disjoint graphs as a
+single graph:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context": {
+    "Person": "http://xmlns.com/foaf/0.1/Person"
+  },
+  "@subject":
+  [
+    {
+      "@subject": "http://example.org/people#john",
+      "@type": "Person"
+    },
+    {
+      "@subject": "http://example.org/people#jane",
+      "@type": "Person"
+    }
+  ]
+}
+-->
+</pre>
+
+<p>A disjoint graph could also be expressed like so:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+[
+  {
+    "@subject": "http://example.org/people#john",
+    "@type": "http://xmlns.com/foaf/0.1/Person"
+  },
+  {
+    "@subject": "http://example.org/people#jane",
+    "@type": "http://xmlns.com/foaf/0.1/Person"
+  }
+]
+-->
+</pre>
+
+<p class="note">Warning: Using this serialisation format it is impossible to include <code>@context</code>
+  given that the document's data structure is an array and not an object.</p>
+
+</section>
+
+<section>
+  <h2>Lists</h2>
+  <p>
+    Because graphs do not describe ordering for links between nodes,  in contrast to plain JSON, multi-valued properties
+    in JSON-LD do not provide an ordering of the listed objects. For example, consider the following
+    simple document:
+  </p>
+  <pre class="example" data-transform="updateExample">
+  <!--
+  {
+  ...
+    "@subject": "http://example.org/people#joebob",
+    "nick": ****["joe", "bob", "jaybee"]****,
+  ...
+  }
+  -->
+  </pre>
+  <p>
+    This results in three triples being generated, each relating the subject to an individual
+    object, with no inherent order.</p>
+  <p>To preserve the order of the objects, RDF-based languages, such as [[TURTLE]]
+    use the concept of an <code>rdf:List</code> (as described in [[RDF-SCHEMA]]). This uses a sequence
+    of unlabeled nodes with properties describing a value, a null-terminated next property. Without
+    specific syntactical support, this could be represented in JSON-LD as follows:
+  </p>
+  <pre class="example" data-transform="updateExample">
+  <!--
+  {
+  ...
+    "@subject": "http://example.org/people#joebob",
+    "nick": ****{****,
+      ****"@first": "joe"****,
+      ****"@rest": {****
+        ****"@first": "bob"****,
+        ****"@rest": {****
+          ****"@first": "jaybee"****,
+          ****"@rest": "@nil"****
+          ****}****
+        ****}****
+      ****}****
+    ****}****,
+  ...
+  }
+  -->
+  </pre>
+  <p>
+    As this notation is rather unwieldy and the notion of ordered collections is rather important
+    in data modeling, it is useful to have specific language support. In JSON-LD, a list may
+    be represented using the <code>@list</code> keyword as follows:
+  </p>
+  <pre class="example" data-transform="updateExample">
+  <!--
+  {
+  ...
+    "@subject": "http://example.org/people#joebob",
+    "foaf:nick": ****{"@list": ["joe", "bob", "jaybee"]}****,
+  ...
+  }
+  -->
+  </pre>
+  <p>
+    This describes the use of this <tref>array</tref> as being ordered, and order is maintained through
+    normalization and RDF conversion. If every use of a given multi-valued property is a
+    list, this may be abbreviated by adding an <code>@coerce</code> term:
+  </p>
+  <pre class="example" data-transform="updateExample">
+  <!--
+  {
+    ****"@context": {****
+      ...
+      ****"@coerce": {****
+        ****"@list": ["foaf:nick"]****
+      ****}****
+    ****}****,
+  ...
+    "@subject": "http://example.org/people#joebob",
+    "foaf:nick": ****["joe", "bob", "jaybee"]****,
+  ...
+  }
+  -->
+  </pre>
+  <p class="issue">There is an ongoing discussion about this issue. One of the <a href="https://github.com/json-ld/json-ld.org/issues/12">proposed solutions</a> is allowing to change the default behaviour so that arrays are considered as ordered lists by default.</p>
+  <section><h3 id="list-expansion">Expansion</h3>
+    <p class="issue">TBD.</p>
+  </section>
+  <section><h3 id="list-normalization">Normalization</h3>
+    <p class="issue">TBD.</p>
+  </section>
+  <section><h3 id="list-rdf">RDF Conversion</h3>
+    <p>
+      To support RDF Conversion of lists, <a href="#rdf-conversion-algorithm">RDF Conversion Algorithm</a>
+      is updated as follows:
+    </p>
+    <ol class="algorithm update">
+      <li>
+        <span class="list-number">2.4a.</span>
+        If the <tref>JSON object</tref> has a <code>@list</code> key and the value is an <tref>array</tref>
+        process the value as a list starting at <a href="#processing-step-list">Step 3a</a>.
+      </li>
+      <li>
+        <span class="list-number">2.7.3.</span>
+        Create a new <tref>processor state</tref> copies of the <tref>active context</tref>,
+        <tref>active subject</tref> and <tref>active property</tref>.
+        <ol class="algorithm">
+          <li>
+            If the <tref>active property</tref> is the target of a <code>@list</code> coercion,
+            and the value is an <tref>array</tref>,
+            process the value as a list starting at <a href="#processing-step-list">Step 3a</a>.
+          </li>
+          <li>
+            Otherwise, process the value starting at
+            <a href="#processing-step-associative">Step 2</a>.
+          </li>
+          <li>Proceed using the previous <tref>processor state</tref>.</li>
+        </ol>
+      </li>
+      <li id="processing-step-list">
+        <span class="list-number">3a.</span>
+        Generate an RDF List by linking
+        each element of the list using <code>rdf:first</code> and <code>rdf:next</code>, terminating the list with <code>rdf:nil</code>
+        using the following sequence:
+        <ol class="algorithm">
+          <li>
+            If the list has no element, generate a triple using the <tref>active subject</tref>, <tref>active property</tref>
+            and <code>rdf:nil</code>.
+          </li>
+          <li>
+            Otherwise, generate a triple using using the <tref>active subject</tref>, <tref>active property</tref>
+            and a newly generated BNode identified as <em>first <tdef>blank node identifier</tdef></em>.
+          </li>
+          <li>
+            For each element other than the last element in the list:
+            <ol class="algorithm">
+              <li>Create a processor state using the active context, <em>first <tdef>blank node identifier</tdef></em> as the <tref>active subject</tref>, and <code>rdf:first</code> as the <tref>active property</tref>.</li>
+              <li>Unless this is the last element in the list, generate a new BNode identified as <em>rest <tdef>blank node identifier</tdef></em>, otherwise use <code>rdf:nil</code>.</li>
+              <li>Generate a new triple using <em>first <tdef>blank node identifier</tdef></em>, <code>rdf:rest</code> and <em>rest <tdef>blank node identifier</tdef></em>.</li>
+              <li>Set <em>first <tdef>blank node identifier</tdef></em> to <em>rest <tdef>blank node identifier</tdef></em>.</li>
+            </ol>
+          </li>
+        </ol>
+      </li>
+    </ol>
+  </section>
+</section>
+
+</section>
+
+<section class="appendix">
+<h2>Markup Examples</h2>
+
+<p>The JSON-LD markup examples below demonstrate how JSON-LD can be used to
+express semantic data marked up in other languages such as RDFa, Microformats,
+and Microdata. These sections are merely provided as proof that JSON-LD is
+very flexible in what it can express across different Linked Data approaches.
+</p>
+
+<section>
+<h3>RDFa</h3>
+
+<p>The following example describes three people with their respective names and
+homepages.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<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>
+      </li>
+      <li ****typeof="foaf:Person"****>
+        <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>
+      </li>
+   </ul>
+</div>
+-->
+</pre>
+
+<p>An example JSON-LD implementation is described below, however, there are
+other ways to mark-up this information such that the context is not
+repeated.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context": { "foaf": "http://xmlns.com/foaf/0.1/"},
+  "@subject": [
+   {
+     "@subject": "_:bnode1",
+     "@type": "foaf:Person",
+     "foaf:homepage": "http://example.com/bob/",
+     "foaf:name": "Bob"
+   },
+   {
+     "@subject": "_:bnode2",
+     "@type": "foaf:Person",
+     "foaf:homepage": "http://example.com/eve/",
+     "foaf:name": "Eve"
+   },
+   {
+     "@subject": "_:bnode3",
+     "@type": "foaf:Person",
+     "foaf:homepage": "http://example.com/manu/",
+     "foaf:name": "Manu"
+   }
+  ]
+}
+-->
+</pre>
+
+</section>
+
+<section>
+<h3>Microformats</h3>
+
+<p>The following example uses a simple Microformats hCard example to express
+how the Microformat is represented in JSON-LD.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<div class="vcard">
+ <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
+</div>
+-->
+</pre>
+
+<p>The representation of the hCard expresses the Microformat terms in the
+context and uses them directly for the <code>url</code> and <code>fn</code>
+properties. Also note that the Microformat to JSON-LD processor has
+generated the proper URL type for <code>http://tantek.com</code>.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "@context":
+  {
+    "vcard": "http://microformats.org/profile/hcard#vcard",
+    "url": "http://microformats.org/profile/hcard#url",
+    "fn": "http://microformats.org/profile/hcard#fn",
+    "@coerce": { "@iri": "url" }
+  },
+  "@subject": "_:bnode1",
+  "@type": "vcard",
+  "url": "http://tantek.com/",
+  "fn": "Tantek Çelik"
+}
+-->
+</pre>
+
+</section>
+
+<section>
+<h3>Microdata</h3>
+
+<p>The Microdata example below expresses book information as a Microdata Work
+item.
+</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+<dl itemscope
+    itemtype="http://purl.org/vocab/frbr/core#Work"
+    itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N">
+ <dt>Title</dt>
+ <dd><cite itemprop="http://purl.org/dc/terms/title">Just a Geek</cite></dd>
+ <dt>By</dt>
+ <dd><span itemprop="http://purl.org/dc/terms/creator">Wil Wheaton</span></dd>
+ <dt>Format</dt>
+ <dd itemprop="http://purl.org/vocab/frbr/core#realization"
+     itemscope
+     itemtype="http://purl.org/vocab/frbr/core#Expression"
+     itemid="http://purl.oreilly.com/products/9780596007683.BOOK">
+  <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK">
+  Print
+ </dd>
+ <dd itemprop="http://purl.org/vocab/frbr/core#realization"
+     itemscope
+     itemtype="http://purl.org/vocab/frbr/core#Expression"
+     itemid="http://purl.oreilly.com/products/9780596802189.EBOOK">
+  <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK">
+  Ebook
+ </dd>
+</dl>
+-->
+</pre>
+
+<p>Note that the JSON-LD representation of the Microdata information stays
+true to the desires of the Microdata community to avoid contexts and
+instead refer to items by their full IRI.</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+[
+  {
+    "@subject": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
+    "@type": "http://purl.org/vocab/frbr/core#Work",
+    "http://purl.org/dc/terms/title": "Just a Geek",
+    "http://purl.org/dc/terms/creator": "Whil Wheaton",
+    "http://purl.org/vocab/frbr/core#realization":
+      ["http://purl.oreilly.com/products/9780596007683.BOOK", "http://purl.oreilly.com/products/9780596802189.EBOOK"]
+  },
+  {
+    "@subject": "http://purl.oreilly.com/products/9780596007683.BOOK",
+    "@type": "http://purl.org/vocab/frbr/core#Expression",
+    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/BOOK"
+  },
+  {
+    "@subject": "http://purl.oreilly.com/products/9780596802189.EBOOK",
+    "@type": "http://purl.org/vocab/frbr/core#Expression",
+    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
+  }
+]
+-->
+</pre>
+</section>
+</section>
+
+<section class="appendix">
+<h3>Mashing Up Vocabularies</h3>
+
+<p>Developers would also benefit by allowing other vocabularies to be used
+automatically with their JSON API. There are over 200
+<tref>Web Vocabulary</tref> Documents that are available for use on the Web
+today. Some of these vocabularies are:
+</p>
+
+<ul>
+   <li>RDF - for describing information about objects and concepts on the Web.</li>
+   <li>RDFS - for expressing things like labels and comments.</li>
+   <li>XSD - for specifying basic types like strings, integers, dates and times.</li>
+   <li>Dublin Core - for describing creative works.</li>
+   <li>FOAF - for describing social networks.</li>
+   <li>Calendar - for specifying events.</li>
+   <li>SIOC - for describing discussions on blogs and websites.</li>
+   <li>CCrel - for describing Creative Commons and other types of licenses.</li>
+   <li>GEO - for describing geographic location.</li>
+   <li>VCard - for describing organizations and people.</li>
+   <li>DOAP - for describing projects.</li>
+</ul>
+
+<p>You can use these vocabularies in combination, like so:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  "****@type****": "****foaf:Person****",
+  "****foaf:name****": "Manu Sporny",
+  "****foaf:homepage****": "http://manu.sporny.org/",
+  "****sioc:avatar****": "http://twitter.com/account/profile_image/manusporny"
+}
+-->
+</pre>
+
+<p>Developers can also specify their own Vocabulary documents by modifying the
+<tref>active context</tref> in-line using the <code>@context</code> keyword,
+like so:</p>
+
+<pre class="example" data-transform="updateExample">
+<!--
+{
+  ****"@context": { "myvocab": "http://example.org/myvocab#" }****,
+  "@type": "foaf:Person",
+  "foaf:name": "Manu Sporny",
+  "foaf:homepage": "http://manu.sporny.org/",
+  "sioc:avatar": "http://twitter.com/account/profile_image/manusporny"****,
+  "myvocab:personality": "friendly"****
+}
+
+-->
+</pre>
+
+<p>The <code>@context</code> keyword is used to change how the JSON-LD
+processor evaluates key-value pairs. In this case, it was used to
+map one string ('myvocab') to another string, which is interpreted as
+a <tref>IRI</tref>. In the example above, the <code>myvocab</code> string is replaced
+with "<code>http://example.org/myvocab#</code>" when it
+is detected. In the example above, "<code>myvocab:personality</code>" would
+expand to "<code>http://example.org/myvocab#personality</code>".</p>
+
+<p>This mechanism is a short-hand, called a <tref>Web Vocabulary</tref> <tref>prefix</tref>,
+and provides developers an unambiguous way to map any JSON value to RDF.<p>
+
+</section>
+
+<section class="appendix">
+<h1>IANA Considerations</h1>
+
+<p>This section is included merely for standards community review and will be
+submitted to the Internet Engineering Steering Group if this specification
+becomes a W3C Recommendation.</p>
+
+<dl>
+  <dt>Type name:</dt>
+  <dd>application</dd>
+  <dt>Subtype name:</dt>
+  <dd>ld+json</dd>
+  <dt>Required parameters:</dt>
+  <dd>None</dd>
+  <dt>Optional parameters:</dt>
+  <dd>
+    <dl>
+      <dt><code>form</code></dt>
+      <dd>Determines the serialization form for the JSON-LD document. Valid
+        values include; <code>compacted</code>, <code>expanded</code>,
+        <code>framed</code>, and <code>normalized</code>. Other values are
+        allowed, but must be pre-pended with a <code>x-</code> string until
+        they are clearly defined by a stable specification. If no form
+        is specified in an HTTP request header to a responding application,
+        such as a Web server, the application MAY choose any form. If no
+        form is specified for a receiving application, the form MUST NOT
+        be assumed to take any particular form.</dd>
+      <div class="issue">It is currently <a href="https://github.com/json-ld/json-ld.org/issues/14"> being discussed to remove form=framed</a> from this specification as there are several issues with it.</div>
+    </dl>
+  </dd>
+  <dt>Encoding considerations:</dt>
+  <dd>The same as the <code>application/json</code> MIME media type.</dd>
+  <dt>Security considerations:</dt>
+  <dd>Since JSON-LD is intended to be a pure data exchange format for
+    directed graphs, the serialization SHOULD NOT be passed through a
+    code execution mechanism such as JavaScript's <code>eval()</code>
+    function. It is RECOMMENDED that a conforming parser does not attempt to
+    directly evaluate the JSON-LD serialization and instead purely parse the