tweaks to the Introduction based on comments from Pat Hayes
authorRichard Cyganiak <richard@cyganiak.de>
Fri, 18 Nov 2011 22:14:48 +0000
changeset 177 cdc85a383cb3
parent 176 789b390724ef
child 178 fae093033aba
tweaks to the Introduction based on comments from Pat Hayes
rdf-concepts/index.html
--- a/rdf-concepts/index.html	Fri Nov 18 19:30:47 2011 +0000
+++ b/rdf-concepts/index.html	Fri Nov 18 22:14:48 2011 +0000
@@ -195,8 +195,11 @@
     some thing in the universe of discourse. These things are called
     <dfn title="resource">resources</dfn>. Anything can be a resource,
     including physical things, documents, and abstract concepts.
-    Literals denote <a title="datatype">datatyped</a> resources such as
-    strings, numbers, and dates. A special kind of literals,
+    The resource denoted by an IRI is called its <a>referent</a>, and the
+    resource denoted by a literal is called its
+    <a title="literal value">value</a>. Literals have
+    <a title="datatype">datatypes</a> that define the range of possible
+    values, such as strings, numbers, and dates. A special kind of literals,
     <a>language-tagged strings</a>, denote plain-text strings in a
     natural language.</p>
 
@@ -205,17 +208,20 @@
     <a title="resource">resources</a> <a title="denote">denoted</a> by
     the <a>subject</a> and <a>object</a></em>. This statement corresponding
     to an RDF triple is known as an <dfn>RDF statement</dfn>.
-    The predicate itself is an <a>IRI</a> and denotes a relationship type,
-    also known as a <dfn>property</dfn>.</p>
+    The predicate itself is an <a>IRI</a> and denotes a binary relation,
+    also known as a <dfn>property</dfn>. (Relations that involve more than
+    two entities can only be
+    <a href="http://www.w3.org/TR/swbp-n-aryRelations/">indirectly
+    expressed in RDF</a> [[SWBP-N-ARYRELATIONS]].)</p>
 
     <p>The assertion of an <a>RDF graph</a> amounts to asserting all the
     triples in it, so the meaning of an RDF graph is the conjunction
     (logical AND) of the <a title="RDF statement">statements</a>
     corresponding to all the triples it contains.</p>
 
-    <p>The <a title="RDF statement">statement</a> corresponding to a
-    triple with a <a>blank node</a> says that something with the given
-    relationship exists, without explicitly naming it.</p>
+    <p><a title="RDF statement">Statements</a> involving
+    <a title="blank node">blank nodes</a> say that something with the given
+    relationships exists, without explicitly naming it.</p>
 </section>
 
 
@@ -293,12 +299,28 @@
 </section>
 
 
-<section id="conformance"></section>
+<section id="conformance">
+    Implementations are free to represent <a title="RDF graph">RDF graphs</a> in
+    any other equivalent form. As an example: in an RDF graph,
+    literals with datatype <tt><a>rdf:XMLLiteral</a></tt> can be represented
+    in a non-canonical
+    format, and canonicalization performed during the comparison between two
+    such literals. In this example the comparisons may be
+    being performed either between syntactic structures or
+    between their denotations in the domain of discourse.
+    Implementations that do not require any such comparisons can
+    hence be optimized.</p>
+</section>
 
 
 <section id="section-URIspaces">
     <h2>RDF Vocabulary IRI and Namespace</h2>
 
+    <p class="issue">This section should be removed from
+    <em>RDF Concepts</em> and folded into [[RDF-SCHEMA]] which
+    actually defines the terms in question. This is
+    <a href="http://www.w3.org/2011/rdf-wg/track/actions/121">ACTION-121</a>.</p>
+
     <p>RDF uses <a title="IRI">IRIs</a> to identify resources
     and properties. Certain
     IRIs with the following leading substring are defined by the
@@ -323,16 +345,307 @@
 </section>
 
 
-<section id="section-Datatypes">
-   <h2>Datatypes</h2>
+<section id="section-rdf-graph">
+    <h2>RDF Graphs</h2>
 
-    <p class="issue">This section perhaps should discuss
-    <a href="http://www.w3.org/TR/rdf-mt/#dtype_interp">the XSD datatype
-    map</a>.  This is
-    <a href="http://www.w3.org/2011/rdf-wg/track/issues/70">ISSUE-70</a>.
-    <a href="http://www.w3.org/2011/rdf-wg/track/issues/66">ISSUE-66</a>
-    tracks the integration of new XSD 1.1 datatypes.</p>
-    </p>
+    <p>An <dfn>RDF graph</dfn> is a set of
+    <a title="RDF triple">RDF triples</a>.</p>
+
+    <p><a name="section-graph-equality"></a><dfn>Graph equivalence</dfn>:
+    Two <a title="RDF graph">RDF graphs</a>
+    <var>G</var> and <var>G'</var> are equivalent if there
+    is a bijection <var>M</var> between the sets of nodes of the two graphs,
+    such that:</p>
+
+    <ol>
+      <li><var>M</var> maps blank nodes to blank nodes.</li>
+      <li><var>M(lit)=lit</var> for all <a title="literal">RDF literals</a> <var>lit</var> which
+      are nodes of <var>G</var>.</li>
+
+      <li><var>M(uri)=uri</var> for all <a title="IRI">IRIs</a> <var>uri</var>
+      which are nodes of <var>G</var>.</li>
+
+      <li>The triple <var>( s, p, o )</var> is in <var>G</var> if and
+      only if the triple <var>( M(s), p, M(o) )</var> is in
+      <var>G'</var></li>
+    </ol>
+    <p>With this definition, <var>M</var> shows how each blank node 
+    in <var>G</var> can be replaced with
+    a new blank node to give <var>G'</var>. A definition of graph equivalence
+    is needed to support the RDF Test Cases [[RDF-TESTCASES]] specification.</p>
+
+
+<section id="section-triples">
+    <h3>Triples</h3>
+
+    <p>An <dfn>RDF triple</dfn> contains three components:</p>
+
+    <ul>
+      <li>the <dfn>subject</dfn>, which is an
+      <a>IRI</a> or a <a>blank node</a></li>
+
+      <li>the <dfn>predicate</dfn>, which is an <a>IRI</a></li>
+
+      <li>the <dfn>object</dfn>, which is an <a>IRI</a>,
+      a <a>literal</a> or a <a>blank node</a></li>
+    </ul>
+
+    <p>An RDF triple is conventionally written in the order subject,
+    predicate, object.</p>
+    
+    <p>The predicate is also known as the <dfn>property</dfn> of the triple.</p>
+
+    <p>The set of <dfn title="node">nodes</dfn> of an <a>RDF graph</a>
+    is the set of subjects and objects of triples in the graph.
+    Predicate IRIs MAY also appear as nodes in the graph.</p>
+
+    <p><a title="IRI">IRIs</a>, <a title="blank node">blank nodes</a> and
+    <a title="literal">literals</a> are collectively known as
+    <dfn title="RDF term">RDF terms</dfn>.</p>
+</section>
+
+
+<section id="section-IRIs">
+    <h3>IRIs</h3>
+
+    <p>An <dfn title="IRI"><acronym title="Internationalized Resource Identifier">IRI</acronym></dfn>
+    (Internationalized Resource Identifier) within an RDF graph
+    is a Unicode string [[!UNICODE]] that conforms to the syntax
+    defined in RFC 3987 [[!IRI]]. IRIs are a generalization of
+    <dfn title="URI"><acronym title="Uniform Resource Identifier">URI</acronym>s</dfn>
+    [[URI]]. Every absolute URI and URL is an IRI.</p>
+
+    <p>IRIs in the RDF abstract syntax MUST be absolute, and MAY
+    contain a fragment identifier.</p>
+
+    <p><dfn>IRI equality</dfn>:
+    Two IRIs are equal if and only if they are equivalent
+    under Simple String Comparison according to
+    <a href="http://tools.ietf.org/html/rfc3987#section-5.1">section 5.1</a>
+    of [[!IRI]]. Further normalization MUST NOT be performed when
+    comparing IRIs for equality.</p>
+
+    <p class="note">When IRIs are used in operations that are only
+    defined for URIs, they must first be converted according to
+    the mapping defined in
+    <a href="http://tools.ietf.org/html/rfc3987#section-3.1">section 3.1</a>
+    of [[!IRI]]. A notable example is retrieval over the HTTP
+    protocol. The mapping involves UTF-8 encoding of non-ASCII
+    characters, %-encoding of octets not allowed in URIs, and
+    Punycode-encoding of domain names.</p>
+
+    <p class="note">Some concrete syntaxes permit relative IRIs
+    as a shorthand for absolute IRIs, and define how to resolve
+    the relative IRIs against a base IRI.</p>
+
+    <p class="note">Previous versions of RDF used the term
+    “<dfn>RDF URI Reference</dfn>” instead of “IRI” and allowed
+    additional characters:
+    “<code>&lt;</code>”, “<code>&gt;</code>”,
+    “<code>{</code>”, “<code>}</code>”,
+    “<code>|</code>”, “<code>\</code>”,
+    “<code>^</code>”, “<code>`</code>”,
+    ‘<code>“</code>’ (double quote), and “<code> </code>” (space).
+    In IRIs, these characters must be percent-encoded as
+    described in <a href="http://tools.ietf.org/html/rfc3986#section-2.1">section 2.1</a>
+    of [[URI]].</p>
+
+    <div class="note">
+      <p>Interoperability problems can be avoided by minting
+      only IRIs that are normalized according to
+      <a href="http://tools.ietf.org/html/rfc3987#section-5">Section 5</a>
+      of [[!IRI]]. Non-normalized forms that should be avoided
+      include:</p>
+
+      <ul>
+        <li>Uppercase characters in scheme names and domain names</li>
+        <li>Percent-encoding of characters where it is not
+          required by IRI syntax</li>
+        <li>Explicitly stated HTTP default port
+          (<code>http://example.com:80/</code>);
+          <code>http://example.com/</code> is preferrable</li>
+        <li>Completely empty path in HTTP IRIs
+          (<code>http://example.com</code>);
+          <code>http://example.com/</code> is preferrable</li>
+        <li>“<code>/./</code>” or “<code>/../</code>” in the path
+          component of an IRI</li>
+        <li>Lowercase hexadecimal letters within percent-encoding
+          triplets (“<code>%3F</code>” is preferable over
+          “<code>%3f</code>”)</li>
+        <li>Punycode-encoding of Internationalized Domain Names
+          in IRIs</li>
+        <li>IRIs that are not in Unicode Normalization
+          Form C [[!NFC]]</li>
+      </ul>
+    </div>
+</section>
+
+
+<section id="section-Graph-Literal">
+    <h2>Literals</h2>
+
+    <p>Literals are used to denote values such as strings, numbers and dates
+    by means of a lexical representation.</p>
+
+    <p>A <dfn>literal</dfn> in an <a>RDF graph</a> consists of:</p>
+
+    <ul>
+    <li>a <dfn>lexical form</dfn> being a Unicode [[!UNICODE]] string,
+    which should be in Normal Form C [[!NFC]],</li>
+    <li>a <dfn>datatype IRI</dfn> being an <a>IRI</a> that establishes
+    the <a>literal value</a>.</li>
+    </ul>
+
+    <p>A <dfn>language-tagged string</dfn> is any <a>literal</a>
+    whose <a>datatype IRI</a> is equal to
+    <code>http://www.w3.org/1999/02/22-rdf-syntax-ns#langString</code>.
+    In addition to <a>lexical form</a> and datatype IRI,
+    a language-tagged string also has:</p>
+
+    <ul>
+    <li>a non-empty <dfn>language tag</dfn> as defined by [[!BCP47]].
+    The language tag MUST be well-formed according to
+    <a href="http://tools.ietf.org/html/bcp47#section-2.2.9">section 2.2.9</a>
+    of [[!BCP47]], and MUST be normalized to lowercase.</li>
+    </ul>
+
+    <p>Concrete syntaxes MAY support <dfn title="simple literal">simple
+    literals</dfn>, consisting of only a <a>lexical form</a>
+    without any datatype IRI or language tag. Simple literals only
+    exist in concrete syntaxes, and are treated as
+    syntactic sugar for abstract syntax
+    <a title="literal">literals</a> with the <a>datatype IRI</a>
+    <code>http://www.w3.org/2001/XMLSchema#string</code>.</p>
+
+    <p><dfn>Literal equality</dfn>:
+    Two literals are equal if and only if the two
+    <a title="lexical form">lexical forms</a>, the two
+    <a title="datatype IRI">datatype IRIs</a>, and the two
+    <a title="language tag">language tags</a> (if any)
+    compare equal, character by character.</p>
+
+    <p class="note">In earlier versions of RDF, literals with a
+    <a>language tag</a> did not have a <a>datatype IRI</a>, and
+    <a title="simple literal">simple literals</a> could appear
+    directly in the abstract syntax. Simple literals and literals with a
+    language tag were collectively known as
+    <dfn title="plain literal">plain literals</dfn>.</p>
+
+      <p class="note">Literals in which the lexical form begins with a
+      composing character (as defined by [[CHARMOD]]) are allowed however they may cause
+      interoperability problems, particularly with XML version 1.1 [[XML11]].</p>
+
+    <p class="note">Earlier versions of RDF permitted tags that
+    adhered to the generic tag/subtag syntax of language tags,
+    but were not well-formed according to [[!BCP47]]. Such
+    language tags do not conform to RDF 1.1.</p>
+
+    <p class="note">The <code>xsd:string</code> datatype does not
+    permit the <code>#x0</code> character, and implementations may not permit
+    control codes in the <code>#x1-#x1F</code> range. Earlier versions of
+    RDF allowed these characters in
+    <a title="simple literal">simple literals</a>, although they
+    could never be serialized in a W3C-recommended concrete syntax.</p>
+
+      <p class="note">When using the language tag, care must be
+      taken not to confuse language with locale. The language
+      tag relates only to human language text. Presentational
+      issues should
+      be addressed in end-user applications.</p>
+
+      <p class="note">The case normalization of 
+language tags is part of
+ the description of the abstract syntax, and consequently the abstract
+ behaviour of RDF applications. It does not constrain an
+ RDF implementation to actually normalize the case. Crucially, the result
+ of comparing two language tags should not be sensitive to the case of
+ the original input.</p>
+
+    <p class="note">RDF Literals are distinct and distinguishable
+    from <a title="IRI">IRIs</a>; e.g. <code>http://example.org/</code>
+    as a string <a>literal</a> is not equal to <code>http://example.org/</code>
+    as an IRI.</p>
+
+
+</section>
+
+
+<section id="section-blank-nodes">
+    <h2>Blank Nodes</h2>
+
+    <p>The <dfn title="blank node">blank nodes</dfn> in an RDF graph 
+    are drawn from an infinite set. This set is disjoint from the set
+    of all <a title="IRI">IRIs</a> and the set of all
+    <a title="literal">literals</a>.
+    Otherwise, this set of blank nodes is arbitrary.</p>
+
+    <p>RDF makes no reference to any internal structure of blank nodes.
+    Given two blank nodes, it is 
+    possible to determine whether or not they are the same.</p>
+
+    <div class="note">
+    <p>Some concrete syntaxes for RDF use 
+    <dfn title="blank node identifier">blank node identifiers</dfn>
+    to allow several statements to use the same
+    blank node. A blank node identifier is a local identifier that can be
+    distinguished from IRIs and literals. Such blank node identifiers are
+    <em>not</em> part of the RDF abstract syntax, but are entirely
+    dependent on the particular concrete syntax used.</p>
+
+    <p>When graphs are merged, their blank nodes must be kept distinct
+    if meaning is to be preserved; this may call for re-allocation of
+    blank node identifiers.</p>
+    </div>
+
+    <p class="issue">Should “Graph merge” be defined in this spec?
+    If not, then the previous paragraph could just as well go.</p>
+</section>
+
+
+<section id="section-skolemization">
+    <h3>Replacing Blank Nodes with IRIs</h3>
+
+    <p>Blank nodes do not have identifiers in the RDF abstract syntax. The
+    <a title="blank node identifier">blank node identifiers</a> introduced
+    by some concrete syntaxes have only
+    local scope and are purely an artifact of the serialization.</p>
+
+    <p>In situations where stronger identification is needed, systems MAY
+    systematically transform some or all of the blank nodes in an RDF graph
+    into IRIs [[!IRI]].  Systems wishing to do this SHOULD mint a new, globally
+    unique IRI (a <dfn>Skolem IRI</dfn>) for each blank node so transformed.</p>
+
+    <p>This transformation does not change the meaning of an RDF graph,
+    provided that the Skolem IRIs do not occur anywhere else.</p>
+
+    <p>Systems may wish to mint Skolem IRIs in such a way that they can
+    recognize the IRIs as having been introduced solely to replace a blank
+    node, and map back to the source blank node where possible.</p>
+
+    <p>Systems that want Skolem IRIs to be recognizable outside of the system
+    boundaries SHOULD use a well-known IRI [[WELL-KNOWN]] with the registered
+    name <code>genid</code>. This is an IRI that uses the HTTP or HTTPS scheme,
+    or another scheme that has been specified to use well-known IRIs; and whose
+    path component starts with <code>/.well-known/genid/</code>.
+
+    <p>For example, the authority responsible for the domain
+    <code>example.com</code> could mint the following recognizable Skolem IRI:</p>
+
+    <pre>http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6</pre>
+
+    <p class="issue">IETF registration of the <code>genid</code> name is
+    currently in progress.</p>
+
+    <p class="note">RFC 5785 [[WELL-KNOWN]] only specifies well-known URIs,
+    not IRIs. For the purpose of this document, a well-known IRI is any
+    IRI that results in a well-known URI after IRI-to-URI mapping [[!IRI]].</p>
+</section>
+
+</section>
+
+
+<section id="section-Datatypes">
+    <h2>Datatypes</h2>
 
     <p>Datatypes are used with RDF <a title="literal">literals</a>
     to represent values such as string, numbers and dates.
@@ -461,8 +774,23 @@
     </table>
 
 
+<section id="xsd-datatypes">
+    <h3>The XML Schema Built-in Datatypes</h3>
+
+    <p class="issue">This subsection should discuss
+    <a href="http://www.w3.org/TR/rdf-mt/#dtype_interp">the XSD datatype
+    map</a>.  This is
+    <a href="http://www.w3.org/2011/rdf-wg/track/issues/70">ISSUE-70</a>.
+    <a href="http://www.w3.org/2011/rdf-wg/track/issues/66">ISSUE-66</a>
+    tracks the integration of new XSD 1.1 datatypes.</p>
+    </p>
+
+
+</section>
+
+
 <section id="section-XMLLiteral">
-    <h3>XML Content within an RDF Graph</h3>
+    <h3>The <code>rdf:XMLLiteral</code> Datatype</h3>
 
     <p class="issue">The canonicalization rules required for XML literals
     are quite complicated. Increasingly, RDF is produced and consumed in
@@ -563,257 +891,20 @@
     <code>xml:lang</code> attribute.</p>
 </section>
 
-</section>
-
-
-<section id="section-Graph-syntax">
-    <h2>Abstract Syntax</h2>
-
-    <p>This section defines the RDF abstract syntax. The RDF abstract
-    syntax is a set of triples, called the RDF graph.</p>
-
-<p class="note">This <em>abstract</em> syntax is the
-syntax over which the formal semantics are defined.
-Implementations are free to represent RDF graphs in
-any other equivalent form.  As an example:
-in an RDF graph,
-literals with datatype <tt>rdf:XMLLiteral</tt> can be represented
-in a non-canonical
-format, and canonicalization performed during the comparison between two
-such literals. In this example the comparisons may be
-being performed either between syntactic structures or
-between their denotations in the domain of discourse.
-Implementations that do not require any such comparisons can
-hence be optimized.
-</p>
-
-
-<section id="section-rdf-graph">
-    <h3>RDF Graphs</h3>
-
-    <p>An <dfn>RDF graph</dfn> is a set of
-    <a title="RDF triple">RDF triples</a>.</p>
-
-    <p><a name="section-graph-equality"></a><dfn>Graph equivalence</dfn>:
-    Two <a title="RDF graph">RDF graphs</a>
-    <var>G</var> and <var>G'</var> are equivalent if there
-    is a bijection <var>M</var> between the sets of nodes of the two graphs,
-    such that:</p>
+<section id="datatype-maps">
+    <h3>Datatype Maps</h3>
 
-    <ol>
-      <li><var>M</var> maps blank nodes to blank nodes.</li>
-      <li><var>M(lit)=lit</var> for all <a title="literal">RDF literals</a> <var>lit</var> which
-      are nodes of <var>G</var>.</li>
-
-      <li><var>M(uri)=uri</var> for all <a title="IRI">IRIs</a> <var>uri</var>
-      which are nodes of <var>G</var>.</li>
-
-      <li>The triple <var>( s, p, o )</var> is in <var>G</var> if and
-      only if the triple <var>( M(s), p, M(o) )</var> is in
-      <var>G'</var></li>
-    </ol>
-    <p>With this definition, <var>M</var> shows how each blank node 
-    in <var>G</var> can be replaced with
-    a new blank node to give <var>G'</var>. A definition of graph equivalence
-    is needed to support the RDF Test Cases [[RDF-TESTCASES]] specification.</p>
-</section>
-
-
-<section id="section-triples">
-    <h3>RDF Triples</h3>
-
-    <p>An <dfn>RDF triple</dfn> contains three components:</p>
-
-    <ul>
-      <li>the <dfn>subject</dfn>, which is an
-      <a>IRI</a> or a <a>blank node</a></li>
-
-      <li>the <dfn>predicate</dfn>, which is an <a>IRI</a></li>
-
-      <li>the <dfn>object</dfn>, which is an <a>IRI</a>,
-      a <a>literal</a> or a <a>blank node</a></li>
-    </ul>
-
-    <p>An RDF triple is conventionally written in the order subject,
-    predicate, object.</p>
-    
-    <p>The predicate is also known as the <dfn>property</dfn> of the triple.</p>
-
-    <p>The set of <dfn title="node">nodes</dfn> of an <a>RDF graph</a>
-    is the set of subjects and objects of triples in the graph.
-    Predicate IRIs MAY also appear as nodes in the graph.</p>
-
-    <p><a title="IRI">IRIs</a>, <a title="blank node">blank nodes</a> and
-    <a title="literal">literals</a> are collectively known as
-    <dfn title="RDF term">RDF terms</dfn>.</p>
+    <p class="note">This subsection should define the term “datatype map”
+    and consolidate all information related to the mapping from IRIs to
+    datatypes.</p>
 </section>
 
 
-<section id="section-IRIs">
-    <h3>IRIs</h3>
-
-    <p>An <dfn title="IRI"><acronym title="Internationalized Resource Identifier">IRI</acronym></dfn>
-    (Internationalized Resource Identifier) within an RDF graph
-    is a Unicode string [[!UNICODE]] that conforms to the syntax
-    defined in RFC 3987 [[!IRI]]. IRIs are a generalization of
-    <dfn title="URI"><acronym title="Uniform Resource Identifier">URI</acronym>s</dfn>
-    [[URI]]. Every absolute URI and URL is an IRI.</p>
-
-    <p>IRIs in the RDF abstract syntax MUST be absolute, and MAY
-    contain a fragment identifier.</p>
-
-    <p><dfn>IRI equality</dfn>:
-    Two IRIs are equal if and only if they are equivalent
-    under Simple String Comparison according to
-    <a href="http://tools.ietf.org/html/rfc3987#section-5.1">section 5.1</a>
-    of [[!IRI]]. Further normalization MUST NOT be performed when
-    comparing IRIs for equality.</p>
-
-    <p class="note">When IRIs are used in operations that are only
-    defined for URIs, they must first be converted according to
-    the mapping defined in
-    <a href="http://tools.ietf.org/html/rfc3987#section-3.1">section 3.1</a>
-    of [[!IRI]]. A notable example is retrieval over the HTTP
-    protocol. The mapping involves UTF-8 encoding of non-ASCII
-    characters, %-encoding of octets not allowed in URIs, and
-    Punycode-encoding of domain names.</p>
-
-    <p class="note">Some concrete syntaxes permit relative IRIs
-    as a shorthand for absolute IRIs, and define how to resolve
-    the relative IRIs against a base IRI.</p>
-
-    <p class="note">Previous versions of RDF used the term
-    “<dfn>RDF URI Reference</dfn>” instead of “IRI” and allowed
-    additional characters:
-    “<code>&lt;</code>”, “<code>&gt;</code>”,
-    “<code>{</code>”, “<code>}</code>”,
-    “<code>|</code>”, “<code>\</code>”,
-    “<code>^</code>”, “<code>`</code>”,
-    ‘<code>“</code>’ (double quote), and “<code> </code>” (space).
-    In IRIs, these characters must be percent-encoded as
-    described in <a href="http://tools.ietf.org/html/rfc3986#section-2.1">section 2.1</a>
-    of [[URI]].</p>
-
-    <div class="note">
-      <p>Interoperability problems can be avoided by minting
-      only IRIs that are normalized according to
-      <a href="http://tools.ietf.org/html/rfc3987#section-5">Section 5</a>
-      of [[!IRI]]. Non-normalized forms that should be avoided
-      include:</p>
-
-      <ul>
-        <li>Uppercase characters in scheme names and domain names</li>
-        <li>Percent-encoding of characters where it is not
-          required by IRI syntax</li>
-        <li>Explicitly stated HTTP default port
-          (<code>http://example.com:80/</code>);
-          <code>http://example.com/</code> is preferrable</li>
-        <li>Completely empty path in HTTP IRIs
-          (<code>http://example.com</code>);
-          <code>http://example.com/</code> is preferrable</li>
-        <li>“<code>/./</code>” or “<code>/../</code>” in the path
-          component of an IRI</li>
-        <li>Lowercase hexadecimal letters within percent-encoding
-          triplets (“<code>%3F</code>” is preferable over
-          “<code>%3f</code>”)</li>
-        <li>Punycode-encoding of Internationalized Domain Names
-          in IRIs</li>
-        <li>IRIs that are not in Unicode Normalization
-          Form C [[!NFC]]</li>
-      </ul>
-    </div>
-</section>
-
-
-<section id="section-Graph-Literal">
-    <h3>RDF Literals</h3>
-
-    <p>Literals are used to denote values such as strings, numbers and dates
-    by means of a lexical representation.</p>
+<section id="section-Literal-Value">
+    <h3>The Value Corresponding to a Literal</h3>
 
-    <p>A <dfn>literal</dfn> in an <a>RDF graph</a> consists of:</p>
-
-    <ul>
-    <li>a <dfn>lexical form</dfn> being a Unicode [[!UNICODE]] string,
-    which should be in Normal Form C [[!NFC]],</li>
-    <li>a <dfn>datatype IRI</dfn> being an <a>IRI</a>.</li>
-    </ul>
-
-    <p>A <dfn>language-tagged string</dfn> is any <a>literal</a>
-    whose <a>datatype IRI</a> is equal to
-    <code>http://www.w3.org/1999/02/22-rdf-syntax-ns#langString</code>.
-    In addition to <a>lexical form</a> and datatype IRI,
-    a language-tagged string also has:</p>
-
-    <ul>
-    <li>a non-empty <dfn>language tag</dfn> as defined by [[!BCP47]].
-    The language tag MUST be well-formed according to
-    <a href="http://tools.ietf.org/html/bcp47#section-2.2.9">section 2.2.9</a>
-    of [[!BCP47]], and MUST be normalized to lowercase.</li>
-    </ul>
-
-    <p>Concrete syntaxes MAY support <dfn title="simple literal">simple
-    literals</dfn>, consisting of only a <a>lexical form</a>
-    without any datatype IRI or language tag. Simple literals only
-    exist in concrete syntaxes, and are treated as
-    syntactic sugar for abstract syntax
-    <a title="literal">literals</a> with the <a>datatype IRI</a>
-    <code>http://www.w3.org/2001/XMLSchema#string</code>.</p>
-
-    <p><dfn>Literal equality</dfn>:
-    Two literals are equal if and only if the two
-    <a title="lexical form">lexical forms</a>, the two
-    <a title="datatype IRI">datatype IRIs</a>, and the two
-    <a title="language tag">language tags</a> (if any)
-    compare equal, character by character.</p>
-
-    <p class="note">In earlier versions of RDF, literals with a
-    <a>language tag</a> did not have a <a>datatype IRI</a>, and
-    <a title="simple literal">simple literals</a> could appear
-    directly in the abstract syntax. Simple literals and literals with a
-    language tag were collectively known as
-    <dfn title="plain literal">plain literals</dfn>.</p>
-
-      <p class="note">Literals in which the lexical form begins with a
-      composing character (as defined by [[CHARMOD]]) are allowed however they may cause
-      interoperability problems, particularly with XML version 1.1 [[XML11]].</p>
-
-    <p class="note">Earlier versions of RDF permitted tags that
-    adhered to the generic tag/subtag syntax of language tags,
-    but were not well-formed according to [[!BCP47]]. Such
-    language tags do not conform to RDF 1.1.</p>
-
-    <p class="note">The <code>xsd:string</code> datatype does not
-    permit the <code>#x0</code> character, and implementations may not permit
-    control codes in the <code>#x1-#x1F</code> range. Earlier versions of
-    RDF allowed these characters in
-    <a title="simple literal">simple literals</a>, although they
-    could never be serialized in a W3C-recommended concrete syntax.</p>
-
-      <p class="note">When using the language tag, care must be
-      taken not to confuse language with locale. The language
-      tag relates only to human language text. Presentational
-      issues should
-      be addressed in end-user applications.</p>
-
-      <p class="note">The case normalization of 
-language tags is part of
- the description of the abstract syntax, and consequently the abstract
- behaviour of RDF applications. It does not constrain an
- RDF implementation to actually normalize the case. Crucially, the result
- of comparing two language tags should not be sensitive to the case of
- the original input.</p>
-
-    <p class="note">RDF Literals are distinct and distinguishable
-    from <a title="IRI">IRIs</a>; e.g. <code>http://example.org/</code>
-    as a string <a>literal</a> is not equal to <code>http://example.org/</code>
-    as an IRI.</p>
-
-
-<section id="section-Literal-Value">
-    <h4>The Value Corresponding to a Literal</h4>
-
-    <p>The <a>datatype IRI</a> refers to a <a>datatype</a>. For XML Schema
+    <p>The <a>datatype IRI</a> of a literal denotes a <a>datatype</a>.
+    For XML Schema
     <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes">built-in</a>
     datatypes, IRIs such as
     <code>http://www.w3.org/2001/XMLSchema#int</code> are used. The IRI
@@ -857,78 +948,6 @@
 
 </section>
 
-</section>
-
-
-<section id="section-blank-nodes">
-    <h3>Blank Nodes</h3>
-
-    <p>The <dfn title="blank node">blank nodes</dfn> in an RDF graph 
-    are drawn from an infinite set. This set is disjoint from the set
-    of all <a title="IRI">IRIs</a> and the set of all
-    <a title="literal">literals</a>.
-    Otherwise, this set of blank nodes is arbitrary.</p>
-
-    <p>RDF makes no reference to any internal structure of blank nodes.
-    Given two blank nodes, it is 
-    possible to determine whether or not they are the same.</p>
-
-    <div class="note">
-    <p>Some concrete syntaxes for RDF use 
-    <dfn title="blank node identifier">blank node identifiers</dfn>
-    to allow several statements to use the same
-    blank node. A blank node identifier is a local identifier that can be
-    distinguished from IRIs and literals. Such blank node identifiers are
-    <em>not</em> part of the RDF abstract syntax, but are entirely
-    dependent on the particular concrete syntax used.</p>
-
-    <p>When graphs are merged, their blank nodes must be kept distinct
-    if meaning is to be preserved; this may call for re-allocation of
-    blank node identifiers.</p>
-    </div>
-
-    <p class="issue">Should “Graph merge” be defined in this spec?
-    If not, then the previous paragraph could just as well go.</p>
-
-
-<section id="section-skolemization">
-    <h4>Replacing Blank Nodes with IRIs</h4>
-
-    <p>Blank nodes do not have identifiers in the RDF abstract syntax. The
-    <a title="blank node identifier">blank node identifiers</a> introduced
-    by some concrete syntaxes have only
-    local scope and are purely an artifact of the serialization.</p>
-
-    <p>In situations where stronger identification is needed, systems MAY
-    systematically transform some or all of the blank nodes in an RDF graph
-    into IRIs [[!IRI]].  Systems wishing to do this SHOULD mint a new, globally
-    unique IRI (a <dfn>Skolem IRI</dfn>) for each blank node so transformed.</p>
-
-    <p>This transformation does not change the meaning of an RDF graph,
-    provided that the Skolem IRIs do not occur anywhere else.</p>
-
-    <p>Systems may wish to mint Skolem IRIs in such a way that they can
-    recognize the IRIs as having been introduced solely to replace a blank
-    node, and map back to the source blank node where possible.</p>
-
-    <p>Systems that want Skolem IRIs to be recognizable outside of the system
-    boundaries SHOULD use a well-known IRI [[WELL-KNOWN]] with the registered
-    name <code>genid</code>. This is an IRI that uses the HTTP or HTTPS scheme,
-    or another scheme that has been specified to use well-known IRIs; and whose
-    path component starts with <code>/.well-known/genid/</code>.
-
-    <p>For example, the authority responsible for the domain
-    <code>example.com</code> could mint the following recognizable Skolem IRI:</p>
-
-    <pre>http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6</pre>
-
-    <p class="issue">IETF registration of the <code>genid</code> name is
-    currently in progress.</p>
-
-    <p class="note">RFC 5785 [[WELL-KNOWN]] only specifies well-known URIs,
-    not IRIs. For the purpose of this document, a well-known IRI is any
-    IRI that results in a well-known URI after IRI-to-URI mapping [[!IRI]].</p>
-</section>
 
 </section>
 
@@ -989,8 +1008,6 @@
 
 </section>
 
-</section>
-
 
 <section id="section-fragID" class="informative">
     <h2>Fragment Identifiers</h2>