Some minor fixes. Mostly typos and grammar
I also included myself as an editor and author in both the syntax and the API spec.
--- a/spec/latest/json-ld-api/index.html Mon Apr 16 16:33:24 2012 -0400
+++ b/spec/latest/json-ld-api/index.html Mon Apr 16 23:41:50 2012 +0200
@@ -19,7 +19,7 @@
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["JSON-LD"] = "Manu Sporny, Gregg Kellogg. <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\"><cite>The JSON-LD Syntax</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\">http://json-ld.org/spec/latest/json-ld-syntax/</a>";
+ berjon.biblio["JSON-LD"] = "Manu Sporny, Gregg Kellogg, Markus Lanthaler. <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\"><cite>The JSON-LD Syntax</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\">http://json-ld.org/spec/latest/json-ld-syntax/</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>";
berjon.biblio["JSON-POINTER"] = "P. Bryan, Ed. <cite><a href=\"http://www.ietf.org/id/draft-pbryan-zyp-json-pointer-01.txt\">JSON Pointer</a></cite> Latest. IETF Draft. URL: <a href=\"http://www.ietf.org/id/draft-pbryan-zyp-json-pointer-01.txt\">http://www.ietf.org/id/draft-pbryan-zyp-json-pointer-01.txt</a>";
@@ -188,7 +188,9 @@
{ name: "Gregg Kellogg", url: "http://greggkellogg.net/",
company: "Kellogg Associates", companyURL: "http://kellogg-assoc.com/" },
{ name: "Dave Longley", url: "http://digitalbazaar.com/",
- company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"}
+ company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"},
+ { name: "Markus Lanthaler", url: "http://www.markus-lanthaler.com/",
+ company: "Graz University of Technology", companyURL: "http://www.tugraz.at/" }
],
// authors, add as many as you like.
@@ -202,6 +204,8 @@
company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
{ name: "Gregg Kellogg", url: "http://greggkellogg.net/",
company: "Kellogg Associates", companyURL: "http://kellogg-assoc.com/" },
+ { name: "Markus Lanthaler", url: "http://www.markus-lanthaler.com/",
+ company: "Graz University of Technology", companyURL: "http://www.tugraz.at/" }
],
// name of the WG
@@ -376,7 +380,7 @@
<p>
JSON [[RFC4627]] defines several terms which are used throughout this document:
<dl>
- <dt><tdef>JSON Object</tdef></dt><dd>
+ <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
@@ -402,11 +406,11 @@
The use of the <tref>null</tref> value within JSON-LD is used to ignore or reset values.
</dd>
<dt><tdef>subject definition</tdef></dt><dd>
- A <tref>JSON Object</tref> used to represent a <tref>subject</tref> and one or more properties
- of that subject. A <tref>JSON Object</tref> is a subject definition if it does not contain they keys
+ A <tref>JSON object</tref> used to represent a <tref>subject</tref> and one or more properties
+ of that subject. A <tref>JSON object</tref> is a subject definition if it does not contain they keys
<code>@value</code>, <code>@list</code> or <code>@set</code> and it has one or more keys other than <code>@id</code>.</dd>
<dt><tdef>subject reference</tdef></dt><dd>
- A <tref>JSON Object</tref> used to reference a subject having only the <code>@id</code> key.</dd>
+ A <tref>JSON object</tref> used to reference a subject having only the <code>@id</code> key.</dd>
</dl>
</p>
</section>
@@ -707,11 +711,11 @@
<div title="typedef DOMString URL" class="idl">
This datatype indicates that the <tref>IRI</tref> is interpreted as a Universal Resource
Locator
- identifying a document, which when parsed as JSON yields either a <code>JSON Object</code>
+ identifying a document, which when parsed as JSON yields either a <code>JSON object</code>
or <code>array</code>.
</div>
</section>
-
+
<section>
<h3>JsonLdOptions</h3>
<p>The <a>JsonLdOptiones</a> type is used to convery a set of options to an interface method.</p>
@@ -1276,7 +1280,7 @@
Expand the <em>value</em> according to <a href="#iri-expansion">IRI Expansion</a>.</li>
<li>Otherwise, if the <em>property</em> is <code>@type</code> the <em>value</em>
MUST be a <tref>string</tref>, an <tref>array</tref> of <tref>string</tref>s, or an empty
- <tref>JSON Object</tref>. Expand <em>value</em> or each of it's entries according to
+ <tref>JSON object</tref>. Expand <em>value</em> or each of it's entries according to
<a href="#iri-expansion">IRI Expansion</a>.</li>
<li>Otherwise, if the <em>property</em> is <code>@value</code> or <code>@language</code> the <em>value</em> MUST NOT be a
<tref>JSON object</tref> or an <tref>array</tref>.</li>
@@ -1652,7 +1656,7 @@
<section>
<h3>Subject Flattening</h3>
-<p>Subject Flattening takes as input an expanded JSON-LD document, and results in a <tref>JSON Object</tref>
+<p>Subject Flattening takes as input an expanded JSON-LD document, and results in a <tref>JSON object</tref>
<em>subjects</em> with a mapping from each object represented in the document to a single entry within
the input document, assigning <tref>blank node</tref> identifiers to objects without a @id, or with an @id that
references a blank node identifier.</p>
@@ -1662,34 +1666,34 @@
<ol class="algorithm">
<li>If <em>element</em> is an array, process each entry in element recursively, using this algorithm.</li>
- <li>Otherwise, if element is a JSON Object:
+ <li>Otherwise, if element is a JSON object:
<ol class="algorithm">
<li>If element is a <tref>subject definition</tref> or <tref>subject reference</tref>:
<ol class="algorithm">
<li>If the property <cide>@id</cide> is not an <tref>IRI</tref>, return a
- <tref>blank node</tref> identifer using<a
- href="generate-blank-node-identifier">Generate Blank Node Identifier</a> as
- <em>name</em>, otherwise use the value of the @id property as
+ <tref>blank node</tref> identifer using<a
+ href="generate-blank-node-identifier">Generate Blank Node Identifier</a> as
+ <em>name</em>, otherwise use the value of the @id property as
<em>name</em>.</li>
- <li>Unless <em>subjects</em> as an entry for <em>name</em> create a new entry in
- <em>subjects</em> initialized using a new <tref>JSON Object</tref>
- with <code>@id</code> set to <em>name</em> as <em>subject</em>.
+ <li>Unless <em>subjects</em> as an entry for <em>name</em> create a new entry in
+ <em>subjects</em> initialized using a new <tref>JSON object</tref>
+ with <code>@id</code> set to <em>name</em> as <em>subject</em>.
Otherwise, use that existing entrpy as <em>subject</em>.</li>
<li>For each <em>property</em> and <em>value</em> in <em>element</em> other than <code>@id</code>:
<ol class="algorithm">
<li>If <em>property</em> is a keyword, copy <code>property</code> and <code>value</code>
to <code>subject</code>.</li>
- <li>Otherwise, if value is a <tref>JSON Object</tref>, it MUST only have the key <code>@list.</code>
- Create a new <tref>JSON Object</tref> containing
- <code>@list</code> and an <tref>array</tref> created by
- performing this algorithm recursively on each item in the list
+ <li>Otherwise, if value is a <tref>JSON object</tref>, it MUST only have the key <code>@list.</code>
+ Create a new <tref>JSON object</tref> containing
+ <code>@list</code> and an <tref>array</tref> created by
+ performing this algorithm recursively on each item in the list
and add to <em>subject</em> along with <em>property</em>.</li>
<li>Otherwise, value MUST be an <tref>array</tref>. Add property to <em>subject</em>
- and an array value created by performing this algorithm
+ and an array value created by performing this algorithm
recursively on each item in the array.</li>
</ol>
</li>
- <li>Return a new <tref>JSON Object</tref> created as a <tref>subject reference</tref> to <em>name</em>.</li>
+ <li>Return a new <tref>JSON object</tref> created as a <tref>subject reference</tref> to <em>name</em>.</li>
</ol>
</li>
<li>Otherwise, return <em>element</em>.</li>
@@ -2072,7 +2076,7 @@
<li>Construct a <tref>JSON object</tref> <em>restMap</em> to map graph names and subjects to objects
derived from statements having a property of <code>rdf:rest</code>.</li>
<li>Construct a <tref>JSON object</tref> <em>subjectMap</em> to map graph names and subjects to
- <tref>JSON Object</tref> instances contained in <em>array</em>.</li>
+ <tref>JSON object</tref> instances contained in <em>array</em>.</li>
<li>For each statement in <em>input</em>:
<ol class="algorithm">
<li>If <em>property</em> is <code>rdf:first</code>,
@@ -2086,7 +2090,7 @@
<ol class="algorithm">
<li>If <em>subjectMap</em> does not have an entry for <tref>null</tref> as name and <em>name</em> as subject:
<ol class="algorithm">
- <li>Create a new <tref>JSON Object</tref> with key/value pair of <code>@id</code> and
+ <li>Create a new <tref>JSON object</tref> with key/value pair of <code>@id</code> and
a string representation of <em>name</em> and use as <em>value</em>.</li>
<li>Save <em>value</em> in <em>subjectMap</em> and append to <em>array</em>.</li>
</ol>
@@ -2096,7 +2100,7 @@
<li>Otherwise, let <em>ary</em> be that array.</li>
<li>If <em>subjectMap</em> does not have an entry for <code>name</code> and <em>subject</em>:
<ol class="algorithm">
- <li>Create a new <tref>JSON Object</tref> with key/value pair of <code>@id</code> and
+ <li>Create a new <tref>JSON object</tref> with key/value pair of <code>@id</code> and
a string representation of <em>subject</em> and use as <em>value</em>.</li>
<li>Save <em>value</em> in <em>subjectMap</em> and append to <em>ary</em>.</li>
</ol>
@@ -2106,7 +2110,7 @@
</li>
<li>Otherwise, if <em>subjectMap</em> does not have an entry for <tref>null</tref> as name and <em>subject</em>:
<ol class="algorithm">
- <li>Create a new <tref>JSON Object</tref> with key/value pair of <code>@id</code> and
+ <li>Create a new <tref>JSON object</tref> with key/value pair of <code>@id</code> and
a string representation of <em>subject</em> and use as <em>value</em>.</li>
<li>Save <em>value</em> in <em>subjectMap</em> and append to <em>array</em>.</li>
</ol>
--- a/spec/latest/json-ld-syntax/index.html Mon Apr 16 16:33:24 2012 -0400
+++ b/spec/latest/json-ld-syntax/index.html Mon Apr 16 23:41:50 2012 +0200
@@ -21,7 +21,7 @@
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>";
- berjon.biblio["JSON-LD-API"] = "Manu Sporny, Gregg Kellogg, Dave Longley, Eds. <cite><a href=\"http://json-ld.org/spec/latest/json-ld-api/\">JSON-LD API</a></cite> Latest. W3C Editor's Draft. URL: <a href=\"http://json-ld.org/spec/latest/json-ld-api/\">http://json-ld.org/spec/latest/json-ld-api/</a>";
+ berjon.biblio["JSON-LD-API"] = "Manu Sporny, Gregg Kellogg, Dave Longley, Markus Lanthaler, Eds. <cite><a href=\"http://json-ld.org/spec/latest/json-ld-api/\">JSON-LD API</a></cite> Latest. W3C Editor's Draft. URL: <a href=\"http://json-ld.org/spec/latest/json-ld-api/\">http://json-ld.org/spec/latest/json-ld-api/</a>";
berjon.biblio["RFC5988"] = "M. Nottingham. <a href=\"http://tools.ietf.org/rfc/rfc5988\"><cite>Web Linking</cite></a> October 2010. IETF Standard. URL: <a href=\"http://tools.ietf.org/rfc/rfc5988.txt\">http://tools.ietf.org/rfc/rfc5988.txt</a>";
// process the document before anything else is done
@@ -187,6 +187,8 @@
company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
{ name: "Gregg Kellogg", url: "http://greggkellogg.net/",
company: "Kellogg Associates", companyURL: "http://kellogg-assoc.com/" },
+ { name: "Markus Lanthaler", url: "http://www.markus-lanthaler.com/",
+ company: "Graz University of Technology", companyURL: "http://www.tugraz.at/" }
],
// authors, add as many as you like.
@@ -275,8 +277,8 @@
<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 <tref>Linked Data</tref>
+JSON has proven to be a highly useful object serialization and messaging format.
+In an attempt to harmonize the representation of <tref>Linked Data</tref>
in JSON, this specification outlines a common JSON representation format for
expressing directed graphs; mixing both Linked Data and non-Linked Data in
a single document.
@@ -361,7 +363,7 @@
<p>
JSON [[RFC4627]] defines several terms which are used throughout this document:
<dl>
- <dt><tdef>JSON Object</tdef></dt><dd>
+ <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
@@ -385,7 +387,7 @@
</dd>
<dt><tdef>null</tdef></dt><dd>
Unless otherwise specified, a JSON-LD processor MUST act as if a key-value pair in the body of a JSON-LD document was never declared when the value equals <em>null</em>.
- If <code>@value</code> or <code>@list</code> is set to <em>null</em> in expanded form, then the entire JSON object is ignored.
+ If <code>@value</code>, <code>@list</code>, or <code>@set</code> is set to <em>null</em> in expanded form, then the entire JSON object is ignored.
If <code>@context</code> is set to <em>null</em>, the <tref>active context</tref> is reset and when used
within a <tref>context</tref>, it removes any definition associated with the key, unless otherwise specified.
</dd>
@@ -404,7 +406,7 @@
<dt><code>@context</code></dt>
<dd>Used to define the short-hand names that are used throughout a JSON-LD
document. These short-hand names are called <tref>term</tref>s and help
- developers express specific identifiers in a compact manner. The
+ developers to express specific identifiers in a compact manner. The
<code>@context</code> keyword is described in detail in the section titled
<a href="#the-context">The Context</a>.</dd>
<dt><code>@graph</code></dt><dd>Used to explicitly express a <tref>linked data graph</tref>.</dd>
@@ -440,7 +442,7 @@
<tref title="compact_iri">compact IRIs</tref>.</dd>
</dl>
- <p>For the avoidance of doubt, all keys, keywords and values in JSON-LD are
+ <p>For the avoidance of doubt, all keys, keywords, and values in JSON-LD are
case-sensitive.</p>
</section>
@@ -491,7 +493,7 @@
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>
+ to be able to express almost every real world data model.</dd>
<dt>Terseness</dt>
<dd>The JSON-LD syntax must be very terse and human readable, requiring as
little effort as possible from the developer.</dd>
@@ -533,7 +535,7 @@
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
+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>
@@ -580,8 +582,8 @@
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. The value of a term mapping
- MUST be either; 1) a simple string with the lexical form of an <tref>absolute IRI</tref>,
- a <tref>compact IRI</tref>, or 3) an <tref>JSON object</tref> containing an
+ MUST be either; 1) a simple string with the lexical form of an <tref>absolute IRI</tref> or
+ 2) <tref>compact IRI</tref>, or 3) an <tref>JSON object</tref> containing an
<code>@id</code>, <code>@type</code>, <code>@language</code>, or <code>@container</code> keyword
(all other keywords are ignored by a JSON-LD processor).
</p>
@@ -666,7 +668,7 @@
<p>Contexts MAY be used at any time a <tref>JSON object</tref> is defined.
A <tref>JSON object</tref> MAY specify multiple contexts, using an
- <tref>array</tref>, which is processed in array-order. This is useful
+ <tref>array</tref>, which is processed in order. This is useful
when an author would like to use an existing context and add
application-specific terms to the existing context. Duplicate context
<tref>term</tref>s MUST be overridden using a last-defined-overrides
@@ -674,10 +676,10 @@
<p class="note">If a <tref>term</tref> is re-defined within a context, all previous
rules associated with the previous definition are removed. A <tref>term</tref> defined
- in a previous context MUST be removed, if it is defined to <code>null</code>.</p>
+ in a previous context MUST be removed, if it is re-defined to <code>null</code>.</p>
<p>
- The set of contexts defined within a specific <tref>JSON Object</tref> are
+ The set of contexts defined within a specific <tref>JSON object</tref> are
referred to as <tdef>local context</tdef>s. Setting the context to <code>null</code>
effectively sets the <tref>local context</tref> to it's initial state. The
<tdef>active context</tdef> refers to the accumulation of
@@ -722,7 +724,7 @@
{
"****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"
+ "****http://xmlns.com/foaf/0.1/depiction****": "http://twitter.com/account/profile_image/manusporny"
}
-->
</pre>
@@ -763,7 +765,7 @@
<p>IRIs may be represented as an <tref>absolute IRI</tref>, a <tref>relative IRI</tref>, a <tref>term</tref>, or a <tref>compact IRI</tref>.</p>
<p>An <tdef>absolute IRI</tdef> is defined in [[!RFC3987]] containing a <em>scheme</em> along with
- <em>path</em> and optional <em>query</em> and fragment segments. A <tdef>relative IRI</tdef> is an IRI
+ <em>path</em> and optional <em>query</em> and <em>fragment</em> segments. A <tdef>relative IRI</tdef> is an IRI
that is relative some other <tref>absolute IRI</tref>; in the case of JSON-LD this is the base location
of the document.</p>
@@ -821,8 +823,6 @@
<p><tref>Term</tref>s are case sensitive, and MUST be matched using a case-sensitive comparison.</p>
<p>Keys that do not expand to an absolute IRI are ignored.</p>
-<p class="issue">It is not determined if processing proceeds into values of undefined keys. If so,
- this would result in a graph which is not <tref title="embedding">embedded</tref>.</p>
<p><code>foaf:name</code> above will automatically expand out to the IRI
<code>http://xmlns.com/foaf/0.1/name</code>. See <a href="#compact-iris">Compact IRIs</a> for more details.</p>
@@ -840,7 +840,7 @@
-->
</pre>
-<p class="note">Specifying a <tref>JSON Object</tref> with an
+<p class="note">Specifying a <tref>JSON object</tref> with an
<code>@id</code> key is used to identify that object using an
<tref>IRI</tref>. This facility MAY also be used to link a
<tref>subject</tref> with an <tref>object</tref> using a mechanism called
@@ -1164,7 +1164,7 @@
represents just syntactic sugar that MUST be optimized away when processing
the document, it is very helpful for <a href="compaction">Compaction</a>
and <a href="framing">Framing</a>. The value of terms associated with a
- <code>@set</code> or <code>@list</code> <code>@container</code> are always
+ <code>@set</code>- or <code>@list</code>-<code>@container</code> are always
represented in the form of an <tref>array</tref> - even if there is just a
single value. This makes post-processing of the data easier as the data is
in a deterministic form. If no such <code>@container</code> is specified,
@@ -1294,7 +1294,7 @@
At times, declaring every single term that a document uses can require the
developer to declare tens, if not hundreds of potential
<tref>vocabulary</tref> <tref>term</tref>s that are used across an
- application. This is a concern for at least three reasons; the
+ application. This is a concern for at least three reasons: the
first is the cognitive load on the developer of remembering all of the
<tref>term</tref>s, the second is the serialized size of the
<tref>context</tref> if it is specified inline, the third is
@@ -1326,8 +1326,8 @@
occurrence of a colon (<code>:</code>). If the <tref>active context</tref>
contains a term mapping for <em>prefix</em>, an IRI is generated by
prepending the mapped <em>prefix</em> to the (possibly empty) <em>suffix</em>
- using textual concatenation. If no prefix mapping is defined, the value is used
- directly as an <tref>absolute IRI</tref>. If the prefix is an underscore
+ using textual concatenation. If no prefix mapping is defined, the value is interpreted
+ as an <tref>absolute IRI</tref>. If the prefix is an underscore
(<code>_</code>), the IRI remains unchanged. This effectively means that every term
containing a colon will be interpreted by a JSON-LD processor as an IRI.
</p>
@@ -1423,7 +1423,7 @@
<p>
In order to use an external context, an author MUST specify an <tref>IRI</tref>
to a valid JSON-LD document. The referenced document MUST have a
-top-level <tref>JSON Object</tref>. The value of any <code>@context</code> key
+top-level <tref>JSON object</tref>. The value of any <code>@context</code> key
within that object is substituted for the IRI within the referencing document
to have the same effect as if the value were specified inline within the
referencing document.</p>
@@ -1471,7 +1471,7 @@
<p>Each context in a list will be evaluated in-order. Duplicate mappings among
the <tref>context</tref>s MUST be overwritten on a last-defined-overrides
basis. The context list MUST contain either de-referenceable <tref>IRI</tref>s
-or <tref>JSON Object</tref>s that conform to the <tref>context</tref> syntax
+or <tref>JSON object</tref>s that conform to the <tref>context</tref> syntax
as described in this document.</p>
<p>An author may nest contexts within <tref>JSON object</tref>s, with the
@@ -1517,7 +1517,7 @@
<section>
<h2>Referencing Contexts from JSON Documents</h2>
-<p>Ordinary JSON documents can be transformed in JSON-LD documents by referencing
+<p>Ordinary JSON documents can be transformed into JSON-LD documents by referencing
to an external JSON-LD <tref>context</tref> in an HTTP Link Header. Doing this
allows JSON to be unambiguously machine-readable without requiring developers to
drastically change their workflow and provides an upgrade path for existing
@@ -1530,7 +1530,7 @@
MUST specify an <tref>IRI</tref> to a valid JSON-LD document in an HTTP Link
Header [[!RFC5988]] using the <code>describedby</code> link relation.
-The referenced document MUST have a top-level <tref>JSON Object</tref>. The
+The referenced document MUST have a top-level <tref>JSON object</tref>. The
<code>@context</code> subtree within that object is added to the top-level
object of the referencing document. If an array is at the top-level of the
referencing document and its items are objects, the <code>@context</code>
@@ -1564,8 +1564,9 @@
-->
</pre>
-<p class="note">JSON-LD documents MUST have all context information, including
-references to external contexts, within the body of the document.</p>
+<p class="note">JSON-LD documents served with the <code>application/ld+json</code> media type
+ MUST have all context information, including references to external contexts, within the
+ body of the document.</p>
</section>
<section>
@@ -1579,8 +1580,8 @@
<p>Instead of using a string representation of an IRI, the IRI MAY be
specified using an object having an <code>@id</code> key.
-The value of the <code>@id</code> key MUST be either a
-<tref>prefix</tref>:suffix value, an <tref>IRI</tref>. Type information
+The value of the <code>@id</code> key MUST be either a <tref>term</tref>, a
+<tref>prefix</tref>:suffix value, or an <tref>absolute IRI</tref>. Type information
may be specified</p>
<pre class="example" data-transform="updateExample">
@@ -1612,7 +1613,7 @@
...
"ex": "http://example.com/",
"@language": "ja",
- "name": { "@id": "ex:name", ****"@language": "null"**** },
+ "name": { "@id": "ex:name", ****"@language": null**** },
"occupation": { "@id": "ex:occupation" },
"occupation_en": { "@id": "ex:occupation", ****"@language": "en"**** },
"occupation_de": { "@id": "ex:occupation", ****"@language": "cs"**** }
@@ -1637,8 +1638,8 @@
<tref title="IRI">IRIs</tref> as keys. If the definition does not include an <code>@id</code> key,
the expanded IRI is determined by performing expansion of the key within the current active context.</p>
-<p class="note">Although it is possible to define a CURIE or IRI to expand to some other IRI, such
- usage is strongly discouraged.</p>
+<p class="note">Although it is possible to define a <tref>compact IRI</tref> or IRI to expand to some
+ other IRI, such usage is strongly discouraged.</p>
</section>
<section>
@@ -1802,9 +1803,8 @@
-->
</pre>
-<p>
-<tref>Term</tref>s, <tref title="compact iri">Compact IRIs</tref> and <tref title="iri">IRIs</tref> MAY also be used on the left-hand side of a definition.
-</p>
+<p><tref>Not only term</tref>s, but also <tref title="compact iri">Compact IRIs</tref>
+ and <tref title="iri">IRIs</tref> MAY be used on the left-hand side of a definition.</p>
<pre class="example" data-transform="updateExample">
<!--
@@ -1963,7 +1963,7 @@
<p>In this case, embedding doesn't work as each JSON-LD object references the other.
Using the <code>@graph</code>
keyword allows multiple resources to be defined within an <tref>array</tref>, and allows the use
- of a shared <tref>context</tref>. This is equivalent to using multiple <tref>JSON Object</tref>
+ of a shared <tref>context</tref>. This is equivalent to using multiple <tref>JSON object</tref>
definitions in array and defining the <code>@context</code> within each object:</p>
<pre class="example" data-transform="updateExample">
@@ -2051,7 +2051,7 @@
then be used later on in the JSON-LD markup to refer back to the
<tref>unlabeled node</tref>. This practice, however, is usually frowned upon when
generating <tref>Linked Data</tref>. If a developer finds that they refer to the unlabeled
-node more than once, they should consider naming the node using a resolve-able
+node more than once, they should consider naming the node using a de-referenceable
<tref>IRI</tref>.
</p>
@@ -2092,7 +2092,7 @@
<h3>Expansion</h3>
<p>The JSON-LD API [[JSON-LD-API]] defines an method for <em>expanding</em> a JSON-LD document.
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
+ context such that all IRIs, 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="#framing">Framing</a>.</p>
@@ -2136,7 +2136,7 @@
<section>
<h3>Compaction</h3>
-<p>The JSON-LD API [[JSON-LD-API]] defines an method for <em>compacting</em> a JSON-LD document.
+<p>The JSON-LD API [[JSON-LD-API]] defines a method for <em>compacting</em> a JSON-LD document.
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
@@ -2759,7 +2759,7 @@
<dd>Determines the serialization form for the JSON-LD document. The only
valid value at the moment is <code>expanded</code>. If no form is
specified in an HTTP request header to an HTTP server, the server MAY
- choose any form. If no form is specified for an HTTP client, the form
+ choose any form. If no form is specified in an HTTP response, the form
MUST NOT be assumed to take any particular form.</dd>
</dl>
</dd>
--- a/spec/latest/rdf-graph-normalization/index.html Mon Apr 16 16:33:24 2012 -0400
+++ b/spec/latest/rdf-graph-normalization/index.html Mon Apr 16 23:41:50 2012 +0200
@@ -19,7 +19,7 @@
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["JSON-LD"] = "Manu Sporny, Gregg Kellogg, et al. <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\"><cite>The JSON-LD Syntax</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\">http://json-ld.org/spec/latest/json-ld-syntax/</a>";
+ berjon.biblio["JSON-LD"] = "Manu Sporny, Gregg Kellogg, Markus Lanthaler. <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\"><cite>The JSON-LD Syntax</cite></a> Latest. W3C Editor's Draft. URL: <a href=\"http://json-ld.org/spec/latest/json-ld-syntax/\">http://json-ld.org/spec/latest/json-ld-syntax/</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>";
@@ -286,25 +286,25 @@
<h1>Introduction</h1>
<p>When data scientists discuss graph normalization, they
-do so in the context of achieving a particular set of goals. Since a directed
-graph can express the same information in a variety of different ways, it
+do so in the context of achieving a particular set of goals. Since a directed
+graph can express the same information in a variety of different ways, it
becomes necessary to be able to transform a graph of information into a
standard form for the purposes of calculating differences between two graphs,
-generating a cryptographically-strong hash identifier for a graph, or digitally
+generating a cryptographically-strong hash identifier for a graph, or digitally
signing a graph.</p>
-<p>Many RDF graphs, containing nodes with unique identifiers, can be normalized
+<p>Many RDF graphs, containing nodes with unique identifiers, can be normalized
quite easily. However, when a node does not have a unique identifier,
graph normalization becomes exponentially more difficult. This problem is
called the <tdef>graph isomorphism</tdef> problem, and it is believed to be a
-NP-hard problem in the worst cases. This means that the problem is very
+NP-hard problem in the worst cases. This means that the problem is very
difficult to solve in a reasonable timeframe for certain inputs. Luckily, these
types of inputs are extremely rare in the real world. Graph isomorphisms are
most commonly used as a denial of service attack and thus any software system
attempting to solve the graph normalization problem should be able to detect
graph isomorphisms correctly.</p>
-<p>This document outlines an algorithm for generating a normalized RDF
+<p>This document outlines an algorithm for generating a normalized RDF
graph given an input RDF graph. The algorithm is called the
<strong>Universal RDF Graph Normalization Algorithm 2011</strong> or
<strong>URGNA2011</strong>.</p>
@@ -325,9 +325,9 @@
<p>
To understand the basics in this specification you must be familiar with basic
-RDF concepts [[!RDF-CONCEPTS]]. A working knowledge of
-<a href="http://en.wikipedia.org/wiki/Graph_theory">graph theory</a> and
-<a href="http://en.wikipedia.org/wiki/Graph_isomorphism">graph isomorphisms</a>
+RDF concepts [[!RDF-CONCEPTS]]. A working knowledge of
+<a href="http://en.wikipedia.org/wiki/Graph_theory">graph theory</a> and
+<a href="http://en.wikipedia.org/wiki/Graph_isomorphism">graph isomorphisms</a>
is also recommended.</p>
</section>
@@ -370,8 +370,8 @@
<p>Normalization is the process of taking <tref>input graph</tref> and
performing a transformation on that input that results in all
aspects of the graph being arranged in a deterministic way in the
-<tref>output graph</tref>. That is, for two <tref>input graph</tref>s
-containing the same
+<tref>output graph</tref>. That is, for two <tref>input graph</tref>s
+containing the same
information, regardless of their arrangement, the <tref>output graph</tref>s
will be identical. The problem is a fairly difficult technical
problem to solve because it requires a directed graph to be ordered into a
@@ -1352,9 +1352,9 @@
graph normalization problem. Gavin Carothers for providing valuable feedback
and testing input for the algorithm defined in this specification. Sir
Tim Berners Lee for his thoughts on graph normalization over the years.
-Jesús Arias Fisteus for his work on a similar algorithm. Finally, a huge thank
-you goes out to Dave Longley who designed and implemented the algorithms
-used in this specification, which turned out to be a monumentally difficult
+Jesús Arias Fisteus for his work on a similar algorithm. Finally, a huge thank
+you goes out to Dave Longley who designed and implemented the algorithms
+used in this specification, which turned out to be a monumentally difficult
design challenge.
</p>