--- a/spec/latest/json-ld-syntax/index.html Sun Jan 27 23:54:13 2013 -0500
+++ b/spec/latest/json-ld-syntax/index.html Mon Jan 28 12:19:55 2013 +0100
@@ -481,10 +481,10 @@
or a <tref>JSON object</tref>.</p>
<p>When a <tref>JSON object</tref> is
- associated with a term, it is called an <tref>expanded term definition</tref>.
+ associated with a term, it is called an <tref>expanded term definition</tref>.
<tdef title="expanded term definition">Expanded term definitions</tdef> may
be used to associate <a href="#type-coercion">type</a> or
- <a href="#string-internationalization">language information</a> with a
+ <a href="#string-internationalization">language information</a> with a
term.
The example above specifies that the values of <code>image</code> and
<code>homepage</code> terms are <tref title="IRI">IRIs</tref>.
@@ -518,7 +518,7 @@
<p>The referenced context not only specifies how the terms map to
<tref title="IRI">IRIs</tref> in the Schema.org vocabulary but also specifies that
the values of the <code>homepage</code> and <code>image</code> property
- can be interpreted as an <tref>IRI</tref> (e.g. <code>"@type": "@id"</code>,
+ can be interpreted as an <tref>IRI</tref> (<code>"@type": "@id"</code>,
see section <a href="#iris"></a> for more details). This information gives the
data global context and allows developers to re-use each other's data
without having to agree to how their data will interoperate on a
@@ -706,17 +706,17 @@
<section>
<h2>Node Identifiers</h2>
- <p>To be able to externally reference <tref title="node">nodes</tref>
- in a <tref title="json-ld_graph">graph</tref>, it is important that each <tref>node</tref> have
+ <p>To be able to externally reference <tref title="node">nodes</tref>
+ in a <tref title="json-ld_graph">graph</tref>, it is important that each <tref>node</tref> has
an unambiguous identifier. <tref title="IRI">IRIs</tref> are a fundamental concept of
<tref>Linked Data</tref>, and <tref title="node">nodes</tref> should have a de-referenceable
identifier used to name and locate them. For <tref title="node">nodes</tref> to be truly linked,
de-referencing the identifier should result in a representation of that <tref>node</tref>.
Associating an <tref>IRI</tref> with a <tref>node</tref> tells an application that it
- can fetch the resource associated with the IRI and get back a description of the
+ can fetch the resource associated with the IRI and get back a description of the
<tref>node</tref>.</p>
- <p><tref title="json-ld_document">JSON-LD documents</tref> may also contain descriptions
+ <p><tref title="json-ld_document">JSON-LD documents</tref> may also contain descriptions
of other <tref title="node">nodes</tref>, so it is necessary to be able to
uniquely identify each <tref>node</tref> so that the data is associated
with the correct <tref>node</tref> in an unambiguous way.</p>
@@ -814,7 +814,7 @@
<section>
<h2>Compact IRIs</h2>
<p>A document on the Web that defines one or more IRIs for use as
- <tref title="property">properties</tref> in Linked Data is called a
+ <tref title="property">properties</tref> in Linked Data is called a
<tdef>vocabulary</tdef>.
<tref title="term">Terms</tref> in <tref>Linked Data</tref> documents may draw from
a number of different <tref title="vocabulary">vocabularies</tref>s. At times, declaring every single <tref>term</tref>
@@ -841,7 +841,7 @@
<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><tref title="prefix">Prefixes</tref> are expanded when the form of the value
is a <tref>compact IRI</tref> represented as a <code>prefix:suffix</code>
combination, and the prefix matches a <tref>term</tref> defined within the
@@ -1030,11 +1030,11 @@
<p>The <code>@type</code> <tref>keyword</tref> is also used to associate a type
with a <tref>node</tref>. The concept of a <tref>node type</tref> and
a <tref>value type</tref> are different.</p>
-
-<p>Generally speaking, a
- <tdef>node type</tdef> specifies the type of thing that is being described,
- like a person, place, event, or web page. A <tdef>value type</tdef> specifies
- the unit of measurement for a particular value, such as a date, meter,
+
+<p>Generally speaking, a
+ <tdef>node type</tdef> specifies the type of thing that is being described,
+ like a person, place, event, or web page. A <tdef>value type</tdef> specifies
+ the unit of measurement for a particular value, such as a date, meter,
or light year.</p>
<pre class="example" data-transform="updateExample"
@@ -1234,13 +1234,13 @@
<section>
<h2>Advanced Context Usage</h2>
-
+
<p>Section <a href="#the-context"></a> introduced the basics of what makes
- JSON-LD work. This section expands on the basic principles of the
+ JSON-LD work. This section expands on the basic principles of the
<tref>context</tref> and demonstrates how more advanced use cases can
be achieved using JSON-LD. </p>
-
- <p>In general, contexts may be used at any time a
+
+ <p>In general, contexts may be used at any time a
<tref>JSON object</tref> is defined. The only time that one cannot
express a context is inside a context definition itself. For example, a
<tref>JSON-LD document</tref> may use more than one context at different
@@ -1334,12 +1334,6 @@
<p class="note">It is a best practice to put the <tref>context</tref> definition
at the top of the JSON-LD document.</p>
- <p class="note">While it is possible to define a <tref>compact IRI</tref>, or
- an <tref>absolute IRI</tref> to expand to some other unrelated <tref>IRI</tref>
- (for example, <code>foaf:name</code> expanding to
- <code>http://example.org/unrelated#species</code>), such usage is strongly
- discouraged.</p>
-
<p class="note">To avoid forward-compatibility issues,
<tref title="term">terms</tref> starting with an <code>@</code> character are
to be avoided as they might be used as <tref title="keyword">keywords</tref>
@@ -1486,7 +1480,7 @@
<tref>null</tref> in the <tref>expanded term definition</tref>.</p>
<p class="note">Language associations can only be applied to plain
- literal <tref title="string">strings</tref>.
+ literal <tref title="string">strings</tref>.
<tref title="typed value">Typed values</tref> or values that are subject
to <a href="#type-coercion"></a> cannot be language tagged.</p>
@@ -1805,14 +1799,18 @@
-->
</pre>
-<p>
-In order for the <tref>absolute IRI</tref> to match above, the <tref>absolute IRI</tref> needs to be used in the <tref>JSON-LD document</tref>. Also note that <code>foaf:homepage</code>
-will not use the <code>{ "@type": "@id" }</code> declaration because
-<code>foaf:homepage</code> is not the same as
-<code>http://xmlns.com/foaf/0.1/homepage</code>. That is, <tref title="term">terms</tref>
-are looked up in a <tref>context</tref> using direct string comparison before the
-<tref>prefix</tref> lookup mechanism is applied.
-</p>
+<p>In order for the <tref>absolute IRI</tref> to match above, the <tref>absolute IRI</tref>
+ needs to be used in the <tref>JSON-LD document</tref>. Also note that <code>foaf:homepage</code>
+ will not use the <code>{ "@type": "@id" }</code> declaration because
+ <code>foaf:homepage</code> is not the same as <code>http://xmlns.com/foaf/0.1/homepage</code>.
+ That is, <tref title="term">terms</tref> are looked up in a <tref>context</tref> using
+ direct string comparison before the <tref>prefix</tref> lookup mechanism is applied.</p>
+
+<p class="note">While it is possible to define a <tref>compact IRI</tref>, or
+ an <tref>absolute IRI</tref> to expand to some other unrelated <tref>IRI</tref>
+ (for example, <code>foaf:name</code> expanding to
+ <code>http://example.org/unrelated#species</code>), such usage is strongly
+ discouraged.</p>
<p>The only exception for using terms in the <tref>context</tref> is that
circular definitions are not allowed. That is,
@@ -1979,22 +1977,22 @@
This decision was made due to the extreme amount of added complexity when
processing lists of lists.</p>
-<p>While <code>@list</code> is used to describe <em>ordered sets</em>,
- the <code>@set</code> keyword is used to describe <em>unordered sets</em>.
+<p>While <code>@list</code> is used to describe <em>ordered lists</em>,
+ the <code>@set</code> keyword is used to describe <em>unordered sets</em>.
The use of <code>@set</code> in the body of a JSON-LD document
is optimized away when processing the document, as it is just syntactic
- sugar. However, <code>@set</code> is helpful when used within the context
+ sugar. However, <code>@set</code> is helpful when used within the context
of a document.
Values of terms associated with a <code>@set</code> or <code>@list</code> container
are always represented in the form of an <tref>array</tref>,
- even if there is just a single value that would otherwise be optimized to
- a non-array form in compact form (see
+ even if there is just a single value that would otherwise be optimized to
+ a non-array form in compact form (see
<a href="#compact-document-form"></a>). This makes post-processing of
JSON-LD documents easier as the data is always in array form, even if the
array only contains a single value.</p>
<p class="note">The use of <code>@container</code> in the body of a JSON-LD
- document has no meaning and is not allowed by the JSON-LD grammar
+ document has no meaning and is not allowed by the JSON-LD grammar
(see <a href="#json-ld-grammar"></a>).</p>
</section>
@@ -2209,7 +2207,7 @@
<h2>Identifying Blank Nodes</h2>
<p>At times, it becomes necessary to be able to express information without
- being able to uniquely identify the <tref>node</tref>.
+ being able to uniquely identify the <tref>node</tref>.
This type of node is called a <tref>blank node</tref>
(see <cite><a href="http://www.w3.org/TR/rdf11-concepts/#section-blank-nodes">Section 3.4: Blank Nodes</a></cite>
of [[!RDF-CONCEPTS]]). In JSON-LD, <tref title="blank node identifier">blank node identifiers</tref> are
@@ -2281,7 +2279,7 @@
<p>Sometimes it is desirable to include comments or annotations in the data
that is not meant to express Linked Data but should nevertheless survive
- JSON-LD processing and transformation. In JSON-LD such data can be included
+ JSON-LD processing and transformation. In JSON-LD such data can be included
by using the <code>@annotation</code> <tref>keyword</tref> as shown in the
following example:</p>
@@ -2305,10 +2303,10 @@
<p>Annotations can also be used to structure data into a form that is
more efficient to access, but fundamentally does not convey any additional
- semantic meaning. The annotation feature allows an author to
+ semantic meaning. The annotation feature allows an author to
structure data using a simpley key-value map where the keys do not map
- to <tref title="IRI">IRIs</tref>. This enables direct access to data
- instead of having to scan an array in search of a specific item. The
+ to <tref title="IRI">IRIs</tref>. This enables direct access to data
+ instead of having to scan an array in search of a specific item. The
following example illustrates this use case:</p>
<pre class="example" data-transform="updateExample"
@@ -2348,15 +2346,15 @@
<p>In the example above, the <strong>blogPost</strong> <tref>term</tref> has
been marked as an <tref>annotation map</tref>. The <strong>en</strong>,
<strong>de</strong>, and <strong>ja</strong> keys will be ignored
- semantically, but preserved syntactically, by the JSON-LD Processor.
+ semantically, but preserved syntactically, by the JSON-LD Processor.
This allows a developer to access the German version
of the <strong>blogPost</strong> using the following code snippet:
<code>obj.blogPost.de</code>.</p>
<p>The interpretation of the data above is expressed in
the table below. Note how the annotations do not appear in the Linked Data
- below, but would continue to exist if the document were compacted or
- expanded (see <a href="#compact-document-form"></a> and
+ below, but would continue to exist if the document were compacted or
+ expanded (see <a href="#compact-document-form"></a> and
<a href="#expanded-document-form"></a>) using a JSON-LD processor:</p>
<table class="example">
@@ -2412,7 +2410,7 @@
<section>
<h3>Expanded Document Form</h3>
-<p>The JSON-LD Algorithms and API specification [[JSON-LD-API]]
+<p>The JSON-LD Algorithms and API specification [[JSON-LD-API]]
defines a method for <em>expanding</em> a JSON-LD document.
Expansion is the process of taking a JSON-LD document and applying a
<code>@context</code> such that all IRIs, types, and values
@@ -2467,12 +2465,12 @@
<section>
<h3>Compact Document Form</h3>
-<p>The JSON-LD Algorithms and API specification [[JSON-LD-API]]
+<p>The JSON-LD Algorithms and API specification [[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 a very compact form of the document is generated.
- At times, a JSON-LD document may be received that is not in its most
- compact form. The JSON-LD Algorithms, via an API, provides a way to compact a
+ At times, a JSON-LD document may be received that is not in its most
+ compact form. The JSON-LD Algorithms, via an API, provides a way to compact a
JSON-LD document.</p>
<p>For example, assume the following JSON-LD input document:</p>
@@ -2536,9 +2534,9 @@
expanding the document (see <a href="#expanded-document-form"></a>) and then
using a developer-supplied context to compact the expanded document.
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
- <tref>term</tref> provided by the developer. This powerful mechanism allows
- the developer to re-shape the incoming JSON data into a format that is
+ to <strong>name</strong>, it could have also mapped it to any arbitrary
+ <tref>term</tref> provided by the developer. This powerful mechanism allows
+ the developer to re-shape the incoming JSON data into a format that is
optimized for their application.</p>
</section>
@@ -2557,20 +2555,20 @@
<tref title="JSON-LD graph">JSON-LD graphs</tref> and comprises exactly one
<tdef>default graph</tdef> and zero or more <tdef title="named graph">named graphs</tdef>.</li>
<li>The <tref>default graph</tref> does not have a name and MAY be empty.</li>
- <li>Each <tref>named graph</tref> is a pair consisting of a <tdef>graph name</tdef>
+ <li>Each <tref>named graph</tref> is a pair consisting of a <tdef>graph name</tdef>
and a <tref>JSON-LD graph</tref>. The
<tref>graph name</tref> SHOULD be an <tref>IRI</tref> or
<tref>blank node identifier</tref>.</li>
<li>A <tdef>JSON-LD graph</tdef> is a labeled directed graph containing
- a set of zero or more <tref title="node">nodes</tref> connected by
+ a set of zero or more <tref title="node">nodes</tref> connected by
<tref title="edge">edges</tref>.</li>
<li>Every <tdef>edge</tdef> has a direction associated with it and is labeled with
an <tref>IRI</tref> or a <tref>blank node identifier</tref>. Within the JSON-LD syntax
these edge labels are called <tdef title="property">properties</tdef>.</li>
- <li>Every <tdef>node</tdef> represents a <tdef>resource</tdef> or a
+ <li>Every <tdef>node</tdef> represents a <tdef>resource</tdef> or a
<tdef>value</tdef>. <tref title="resource">Resources</tref> are labeled
using either an <tref>IRI</tref> or a <tref>blank node identifier</tref>.
- <tref title="value">Values</tref> are a
+ <tref title="value">Values</tref> are a
<tref>JSON-LD value</tref> or a <tref>list</tref>.</li>
<li>A <tref>node</tref> having an outgoing edge MUST be an <tref>IRI</tref> or a
<tref>blank node</tref>.</li>
@@ -2595,7 +2593,7 @@
tag as defined by [[BCP47]]. The language tag MUST be well-formed according to section
<a href="http://tools.ietf.org/html/bcp47#section-2.2.9">2.2.9</a> of [[BCP47]], and MUST
be lowercase.</li>
- <li>A <tdef>list</tdef> is an ordered sequence of zero or more
+ <li>A <tdef>list</tdef> is an ordered sequence of zero or more
<tref title="IRI">IRIs</tref>,
<tref title="blank node">blank nodes</tref>, and
<tref title="JSON-LD value">JSON-LD values</tref>.</li>
@@ -2964,7 +2962,7 @@
<p>Summarized these differences mean that JSON-LD is capable of serializing any RDF
graph or dataset and most, but not all, JSON-LD documents can be transformed to RDF.
A complete description of the algorithms to convert from RDF to JSON-LD and from
- JSON-LD to RDF is included in the JSON-LD Algorithms and API specification
+ JSON-LD to RDF is included in the JSON-LD Algorithms and API specification
[[JSON-LD-API]].</p>
<p>Even though JSON-LD serializes RDF datasets, it can also be used as a RDF graph source.
@@ -3024,7 +3022,7 @@
-->
</pre>
-<p class="note">JSON-LD has no equivalent for the Turtle <code>@base</code>
+<p class="note">JSON-LD has no equivalent for the Turtle <code>@base</code>
declaration, but can use a prefix such as <code>base</code> to encode the
information in the document.</p>
@@ -3328,9 +3326,9 @@
directly evaluate the JSON-LD serialization and instead purely parse the
input into a language-native data structure. <br/>
JSON-LD contexts that are loaded from the Web over non-secure connections,
- such as HTTP, run the risk of modifying the JSON-LD
+ such as HTTP, run the risk of modifying the JSON-LD
<tref>active context</tref> in a way that could compromise security. It
- is advised that any application that depends on a remote context for mission
+ is advised that any application that depends on a remote context for mission
critical purposes vet and cache the remote context before allowing the
system to use it.</dd>
<dt>Interoperability considerations:</dt>
@@ -3377,19 +3375,19 @@
<h1>Acknowledgements</h1>
<p>The authors would like to extend a deep appreciation and the most sincere
- thanks to Mark Birbeck, who contributed foundational concepts
- to JSON-LD via his work on RDFj. JSON-LD uses a number of core concepts
+ thanks to Mark Birbeck, who contributed foundational concepts
+ to JSON-LD via his work on RDFj. JSON-LD uses a number of core concepts
introduced in RDFj, such as the context as a mechanism to provide an
environment for interpreting JSON data. Mark had also been very involved in
the work on RDFa as well. RDFj built upon that work. JSON-LD exists
because of the work and ideas he started nearly a decade ago in 2004.</p>
- <p>A large amount of thanks goes out to the JSON-LD Community Group
- participants who worked through many of the technical issues on the mailing
- list and the weekly telecons - of special mention are François Daoust,
+ <p>A large amount of thanks goes out to the JSON-LD Community Group
+ participants who worked through many of the technical issues on the mailing
+ list and the weekly telecons - of special mention are François Daoust,
Stéphane Corlosquet, Lin Clark, and Zdenko 'Denny' Vrandečić.</p>
- <p>The work of David I. Lehn and Mike Johnson are appreciated for
+ <p>The work of David I. Lehn and Mike Johnson are appreciated for
reviewing, and performing several implementations
of the specification. Thanks to Ian Davis for this work on RDF/JSON. Thanks also
to Nathan Rixham, Bradley P. Allen, Kingsley Idehen, Glenn McDonald, Alexandre Passant,