References now in bibliography, many internal and external links added. No changes to content.
authorPat Hayes <phayes@ihmc.us>
Thu, 30 May 2013 02:35:51 -0500
changeset 826 dac06fc88a5f
parent 825 b06424d5d526
child 827 c6c55256030d
References now in bibliography, many internal and external links added. No changes to content.
rdf-mt/index.html
--- a/rdf-mt/index.html	Wed May 29 12:47:42 2013 -0500
+++ b/rdf-mt/index.html	Thu May 30 02:35:51 2013 -0500
@@ -14,7 +14,16 @@
 
 localBiblio:{
 "HORST04":"Herman J. ter Horst. <cite>Extending the RDFS Entailment Lemma</cite>, in S.A. McIlraith et al. (Eds.), The Semantic Web - ISWC2004, Proceedings of the Third International Semantic Web Conference, Hiroshima, Japan, November 2004, Springer, LNCS 3298, pp. 77-91.",
-"HORST05":"Herman J. ter Horst. <cite>Completeness, Decidability and Complexity of Entailment for RDF Schema and a Semantic Extension Involving the OWL Vocabulary</cite>, Journal of Web Semantics 3 (2005) 79-115." },
+
+"HORST05":"Herman J. ter Horst. <cite>Completeness, Decidability and Complexity of Entailment for RDF Schema and a Semantic Extension Involving the OWL Vocabulary</cite>, Journal of Web Semantics 3 (2005) 79-115.",
+
+"RDF11-CONCEPTS": "Richard Cyganiak, David Wood, Editors. <cite><a href=\"http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/\">RDF 1.1 Concepts and Abstract Syntax.</a></cite> 15 January 2013. W3C Working Draft (work in progress). URL: <a href=\"http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/\">http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/</a>. The latest edition is available at <a href=\"http://www.w3.org/TR/rdf11-concepts/\">http://www.w3.org/TR/rdf11-concepts/</a>",
+
+"RDF-PLAINLITERAL":"Jie Bao, Sandro Hawke, Boris Motik, Peter F. Patel-Schneider, Alex Polleres, Editors. <cite><a href=\"http://www.w3.org/TR/rdf-plain-literal/\">rdf:PlainLiteral: A Datatype for RDF Plain Literals (Second Edition)</a></cite> 11 December 2012. W3C Recommendation. URL: <a href=\"http://www.w3.org/TR/rdf-plain-literal/\">http://www.w3.org/TR/rdf-plain-literal/</a>",
+
+"TURTLE-TR":"David Beckett, Tim Berners-Lee, Eric Prud'hommeaux, Gavin Carothers, Authors. <cite><a href=\"http://www.w3.org/TR/turtle/\">Turtle; Terse RDF Triple Language</a></cite> 19 February 2013. W3C Candidate Recommendation. URL: <a href=\"http://www.w3.org/TR/turtle/\">http://www.w3.org/TR/turtle/</a>" ,
+
+"ISO24707":"<cite>Information technology — Common Logic (CL): a framework for a family of logic-based languages</cite> 1 October 2007. International Standard ISO/IEC 24707:2007(E). URL: <a href=\"http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007%28E%29.zip\"> http://standards.iso.org/ittf/PubliclyAvailableStandards/c039175_ISO_IEC_24707_2007%28E%29.zip</a>" },
           
           // the specification's short name, as in http://www.w3.org/TR/short-name/
           shortName:            "rdf11-mt",
@@ -177,14 +186,14 @@
       <h2 id="notation">Notation and terminology</h2>
 
 
-      <p>This document uses the following terminology for describing RDF graph syntax, all as defined in the companion RDF Concepts specification [[!RDF11-CONCEPTS]]: <em>IRI</em>, <em><a class="externalDFN">RDF triple</a>, <a class="externalDFN">RDF graph</a>, <a class="externalDFN">subject</a>, <a class="externalDFN">predicate</a>, <a class="externalDFN">object</a>, <a class="externalDFN">RDF source</a>, <a class="externalDFN">node</a>, <a class="externalDFN">blank node</a>, <a class="externalDFN">literal</a>, <a class="externalDFN">isomorphic</a>.</em></p>
+      <p>This document uses the following terminology for describing RDF graph syntax, all as defined in the companion RDF Concepts specification [[!RDF11-CONCEPTS]]: <em><a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-iri">IRI</a></em>, <em><a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">RDF triple</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-rdf-graph">RDF graph</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">subject</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">predicate</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#section-triples">object</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF source</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-node">node</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-blank-node">blank node</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-literal">literal</a>, <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#graph-isomorphism">isomorphic</a>.</em></p>
 
-<p>We use the words <dfn>denotes</dfn> and <dfn>refers to</dfn> interchangeably as synonyms for the relationship between an IRI or literal and what it refers to in a given interpretation, itself called the <dfn>referent</dfn> or <dfn>denotation</dfn>. IRI meanings may also be determined by other constraints external to the RDF semantics; when we wish to refer to such an externally defined naming relationship, we will use the word <dfn>identify</dfn> and its cognates. For example, the fact that the IRI <code>http://www.w3.org/2001/XMLSchema#decimal</code> is widely used as the name of a datatype described in the XML Schema document [[XMLSCHEMA11-2]] might be described by saying that the IRI <em>identifies</em> that datatype. If an IRI identifies something it may or may not refer to it in a given interpretation, depending on how the semantics is specified. For example, an IRI used as a graph name <a>identify</a>ing a named graph in an <a class="external">RDF dataset</a> may refer to something different from the graph it identifies. </p>
+<p>The words <dfn>denotes</dfn> and <dfn>refers to</dfn> are used interchangeably as synonyms for the relationship between an IRI or literal and what it refers to in a given interpretation, itself called the <dfn>referent</dfn> or <dfn>denotation</dfn>. IRI meanings may also be determined by other constraints external to the RDF semantics; when we wish to refer to such an externally defined naming relationship, we will use the word <dfn>identify</dfn> and its cognates. For example, the fact that the IRI <code>http://www.w3.org/2001/XMLSchema#decimal</code> is widely used as the name of a datatype described in the XML Schema document [[XMLSCHEMA11-2]] might be described by saying that the IRI <em>identifies</em> that datatype. If an IRI identifies something it may or may not refer to it in a given interpretation, depending on how the semantics is specified. For example, an IRI used as a graph name <a>identify</a>ing a named graph in an <a class="external">RDF dataset</a> may refer to something different from the graph it identifies. </p>
 
 <p>Throughout this document, the equality sign = indicates strict identity. The statement "A = B" means that there is one entity to which both expressions "A" and "B" refer.  Angle brackets &lt; x, y &gt; are used to indicate an ordered pair 
   of x and y.</p>
 
-<p>Throughout this document, RDF graphs and other fragments of RDF abstract syntax are written using the notational conventions of the Turtle syntax [[!TURTLE-TR]]. The namespace prefixes <code>rdf:</code> <code>rdfs:</code> and <code>xsd:</code> are used as in [[!RDF11-CONCEPTS]], section 1.4. When the exact IRI does not matter, prefix <code>ex:</code> is used. When stating general rules or conditions we use three-character variables such as aaa, xxx, sss  to indicate arbitrary IRIs, literals, or other components of RDF syntax. </p>
+<p>Throughout this document, RDF graphs and other fragments of RDF abstract syntax are written using the notational conventions of the Turtle syntax [[!TURTLE-TR]]. The namespace prefixes <code>rdf:</code> <code>rdfs:</code> and <code>xsd:</code> are used as in [[!RDF11-CONCEPTS]], <a href="http://www.w3.org/TR/rdf11-concepts/#vocabularies">section 1.4</a>. When the exact IRI does not matter, the prefix <code>ex:</code> is used. When stating general rules or conditions we use three-character variables such as aaa, xxx, sss  to indicate arbitrary IRIs, literals, or other components of RDF syntax. </p>
 
 <p>A <dfn>name</dfn> is any IRI or literal. A typed literal contains
   two <a>name</a>s: itself and its internal type 
@@ -216,8 +225,8 @@
 <p>A <dfn>proper instance</dfn> of a graph 
   is an <a>instance</a> in which a blank node has been replaced by a <a>name</a>, or two blank 
   nodes in the graph have been mapped into the same node in the instance. </p>
-<p>Two graphs are <a class="external">isomorphic</a> when each maps into the other by a 1:1 mapping on blank nodes. Isomorphic graphs are mutual instances with an invertible instance 
-  mapping. As blank nodes have no particular identity beyond their location in a graph, we will often treat such isomorphic graphs as identical.</p>
+<p>Two graphs are <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#graph-isomorphism">isomorphic</a> when each maps into the other by a 1:1 mapping on blank nodes. Isomorphic graphs are mutual instances with an invertible instance 
+  mapping. As blank nodes have no particular identity beyond their location in a graph, we will often treat isomorphic graphs as identical.</p>
 
 <p>
 Graphs share blank nodes only if they are derived from graphs
@@ -226,7 +235,7 @@
 of blank nodes between different RDF graphs.  Simply downloading a
 web document does not mean that the blank nodes in a resulting RDF
 graph are the same as the blank nodes coming from other downloads of
-the same document or from the same source. RDF applications which manipulate concrete syntaxes for RDF which use blank node identifiers should take care to keep track of the identity of the blank nodes they identify. Blank node identifiers often have a local scope, so when RDF from different sources is combined, identifiers may have to be changed in order to avoid accidental conflation of distinct blank nodes.</p>
+the same document or from the same <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF source</a>. RDF applications which manipulate concrete syntaxes for RDF which use blank node identifiers should take care to keep track of the identity of the blank nodes they identify. Blank node identifiers often have a local scope, so when RDF from different sources is combined, identifiers may have to be changed in order to avoid accidental conflation of distinct blank nodes.</p>
 
 <p>Forming the union of a set of graphs preserves the identity of blank nodes shared between the graphs. This document will often treat a set of graphs as being identical to a single graph comprising their union, without further comment. </p>
 
@@ -266,7 +275,7 @@
   </tr>
   </table>
 
-<p class="changenote">The 2004 RDF 1.0 semantics defined interpretations relative to a vocabulary.<br/><br/>In the 2004 RDF 1.0 semantics, IL was a total, rather than partial, mapping.<br/><br/> The 2004 RDF 1.0 specification divided literals into 'plain' literals with no type and optional language tags, and typed literals. Usage has shown that it is important that every literal have a type. RDF 1.1 replaces plain literals without language tags by literals typed with the XML Schema <code>string</code> datatype, and introduces the special type <code>rdf:langString</code> for language-tagged strings. The full semantics for typed literals is given in the next section. </p>
+<p class="changenote">The 2004 RDF 1.0 semantics defined interpretations relative to a vocabulary.<br/><br/>In the 2004 RDF 1.0 semantics, IL was a total, rather than partial, mapping.<br/><br/> The 2004 RDF 1.0 specification divided literals into 'plain' literals with no type and optional language tags, and typed literals. Usage has shown that it is important that every literal have a type. RDF 1.1 replaces plain literals without language tags by literals typed with the XML Schema <code>string</code> datatype, and introduces the special type <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> for language-tagged strings. The full semantics for typed literals is given in the next section. </p>
 
 <p class="technote"> Interpretations are required to interpret all <a>name</a>s, and are therefore infinite. This simplifies the exposition. However, RDF can be interpreted using finite structures, supporting decidable algorithms. Details are given in Appendix B. </p>
 
@@ -279,7 +288,7 @@
 <p>The distinction between IR and IL will become significant below when the semantics of datatypes are defined. IL is allowed to be partial because some literals may fail to have a referent. </p>
 
 <p class="technote"> 
-It is conventional to map a relation name to a relational extension directly.  This however presumes that the vocabulary is segregated into relation names and individual names, and RDF makes no such assumption. Moreover, RDF allows an IRI to be used as a relation name applied to itself as an argument. Such self-application structures are used in RDFS, for example. The use of the IEXT mapping to distinguish the relation as an object from its relational extension accommodates both of these requirements. It also provides for a notion of RDFS 'class' which can be distinguished from its set-theoretic extension.  
+It is conventional to map a relation name to a relational extension directly.  This however presumes that the vocabulary is segregated into relation names and individual names, and RDF makes no such assumption. Moreover, RDF allows an IRI to be used as a relation name applied to itself as an argument. Such self-application structures are used in RDFS, for example. The use of the IEXT mapping to distinguish the relation as an object from its relational extension accommodates both of these requirements. It also provides for a notion of RDFS 'class' which can be distinguished from its set-theoretic extension. A similar technique is used in the ISO/IEC Common Logic standard [[ISO24707]].
 </p>
 
 
@@ -354,7 +363,7 @@
 <h3 id="intuitions">Intuitive summary</h3>
 
 <p>An RDF graph is true exactly when:</p>
-<p>1. the IRIs and literals in subject or object position in the graph all refer to things,</p><p>2. there is some way to interpret all the blank nodes in the graph as referring to things,</p><p>3. the IRIs in property position identify binary relationships,</p><p>4. and under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship referred to by P. </p>
+<p>1. the IRIs and literals in subject or object position in the graph all refer to things,</p><p>2. there is some way to interpret all the blank nodes in the graph as referring to things,</p><p>3. the IRIs in property position refer to binary relationships,</p><p>4. and under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship referred to by P. </p>
     </section>
 </section>
 
@@ -457,8 +466,8 @@
 </section>
 
 <section><h2 id="skolemization">Skolemization</h2>
-<p><a class="externaldefinition">Skolemization</a> is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See [[!RDF11-CONCEPTS]] for a fuller discussion. </p> 
-<p> Suppose G is a graph containing blank nodes and sk is a skolemization mapping on the blank nodes in G, so that sk(G) is a skolemization of G.  Then the semantic relationship between them can be summarized as follows. </p>
+<p><a class="externaldefinition">Skolemization</a> is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See <a href="http://www.w3.org/TR/rdf11-concepts/#section-skolemization">Section 3.5</a> of [[!RDF11-CONCEPTS]] for a fuller discussion. </p> 
+<p> Suppose G is a graph containing blank nodes and sk is a skolemization mapping from the blank nodes in G to the skolem IRIs which are substituted for them, so that sk(G) is a skolemization of G.  Then the semantic relationship between them can be summarized as follows. </p>
 
 <p class="fact">   sk(G) simply entails G (since sk(G) is an instance of G.)</p>
 <p class="fact">   G does not entail sk(G) (since sk(G) contains IRIs not in G.) </p>
@@ -477,14 +486,14 @@
 
 <p class="changenote">In the 2004 RDF 1.0 specification, the semantics of datatypes referred to datatype maps. The current treatment using the notion of recognized datatype IRI is simpler and more direct.</p>
 
-<p>RDF literals and datatypes are fully described in [[!RDF11-CONCEPTS]]. In summary: RDF literals are either language-tagged strings, or datatyped literals which 
-combine a string and an IRI <a>identify</a>ing a datatype. A datatype is understood to define a partial mapping, called the <dfn>lexical-to-value mapping</dfn>, from character strings to values. The function <dfn>L2V</dfn> maps datatypes to their lexical-to-value mapping. A literal with datatype d refers to (denotes) the value obtained by applying this mapping to the character string: L2V(d)(string). If the lexical-to-value mapping gives no value for the literal string, then the literal has no referent. The <dfn>value space</dfn> of a datatype is the range of the <a>lexical-to-value mapping</a>. Every literal with that type either refers to a value in the value space of the type, or fails to refer at all. An  <dfn>ill-typed</dfn> literal is one whose datatype IRI is <a>recognize</a>d, but whose character string is assigned no value by the <a>lexical-to-value mapping</a> for that datatype. </p>
+<p>RDF literals and datatypes are fully described in <a href="http://www.w3.org/TR/rdf11-concepts/#section-Datatypes"> Section 5</a> of [[!RDF11-CONCEPTS]]. In summary: RDF literals are either language-tagged strings, or datatyped literals which 
+combine a string and an IRI <a>identify</a>ing a datatype. A datatype is understood to define a partial mapping, called the <dfn>lexical-to-value mapping</dfn>, from character strings to values. The function <dfn>L2V</dfn> maps datatypes to their lexical-to-value mapping. A literal with datatype d refers to (denotes) the value obtained by applying this mapping to the character string: L2V(d)(<em>string</em>). If the lexical-to-value mapping gives no value for the literal string, then the literal has no referent. The <dfn>value space</dfn> of a datatype is the range of the <a>lexical-to-value mapping</a>. Every literal with that type either refers to a value in the value space of the type, or fails to refer at all. An  <dfn>ill-typed</dfn> literal is one whose datatype IRI is <a>recognize</a>d, but whose character string is assigned no value by the <a>lexical-to-value mapping</a> for that datatype. </p>
 
-<p> RDF processors are not REQUIRED to <a>recognize</a> any datatype IRIs other than <code>rdf:langString</code> and <code>xsd:string</code>, but when IRIs listed in Section 5 of [[!RDF11-CONCEPTS]] are <a>recognize</a>d, they MUST be interpreted as described there, and when the IRI <code>rdf:plainLiteral</code> is <a>recognize</a>d, it MUST be interpreted to refer to the datatype defined in [[!RDF-PLAINLITERAL]]. RDF processors MAY recognize other datatype IRIs, but when other datatype IRIs are <a>recognize</a>d, the mapping between a <a>recognize</a>d IRI and the datatype it refers to MUST be specified unambiguously, and MUST be fixed during all RDF transformations or manipulations.</p> 
+<p> RDF processors are not REQUIRED to <a>recognize</a> any datatype IRIs other than <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> and <a href="http://www.w3.org/TR/xmlschema11-2/#string"><code>xsd:string</code></a>, but when IRIs listed in <a href="http://www.w3.org/TR/rdf11-concepts/#section-Datatypes">Section 5</a> of [[!RDF11-CONCEPTS]] are <a>recognize</a>d, they MUST be interpreted as described there, and when the IRI <code>rdf:plainLiteral</code> is <a>recognize</a>d, it MUST be interpreted to refer to the datatype defined in [[!RDF-PLAINLITERAL]]. RDF processors MAY recognize other datatype IRIs, but when other datatype IRIs are <a>recognize</a>d, the mapping between a <a>recognize</a>d IRI and the datatype it refers to MUST be specified unambiguously, and MUST be fixed during all RDF transformations or manipulations.</p> 
 
-<p>Literals with <code>rdf:langString</code> as their datatype are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. </p>
+<p>Literals with <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> as their datatype are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. </p>
 
-<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it is not <a>recognize</a>d as referring to a datatype. Literals with such an "unknown" datatype IRI, which is not in the set of <a>recognize</a>d datatypes, MUST NOT be treated as errors, although RDF applications MAY issue a warning. Such literals SHOULD be treated like IRIs and assumed to denote some thing in the universe IR. RDF processors which fail to <a>recognize</a> a datatype IRI will not be able to detect some entailments which are visible to one which does.  For example, the fact that </p><p><code>ex:a ex:p "20.0000"^^xsd:decimal .</code></p><p>entails </p><p><code>ex:a ex:p "20.0"^^xsd:decimal .</code></p><p>will not be visible to a processor which does not <a>recognize</a> the datatype IRI <code>xsd:decimal</code>.</p>
+<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it is not <a>recognize</a>d as referring to a datatype. Literals with such an "unknown" datatype IRI, which is not in the set of <a>recognize</a>d datatypes, SHOULD NOT be treated as errors, although RDF applications MAY issue a warning. Such literals SHOULD be treated like IRIs and assumed to denote some thing in the universe IR. RDF processors which fail to <a>recognize</a> a datatype IRI will not be able to detect some entailments which are visible to one which does.  For example, the fact that </p><p><code>ex:a ex:p "20.0000"^^xsd:decimal .</code></p><p>entails </p><p><code>ex:a ex:p "20.0"^^xsd:decimal .</code></p><p>will not be visible to a processor which does not <a>recognize</a> the datatype IRI <code>xsd:decimal</code>.</p>
 
 
 </section>
@@ -503,7 +512,7 @@
 
 <p>If the literal is <a>ill-typed</a> then the L2V(I(aaa)) mapping has no value, and so the literal cannot denote anything. In this case, any triple containing the literal must be false. Thus, any triple, and hence any graph, containing an <a>ill-typed</a> literal will be  <a>D-unsatisfiable</a>, i.e. false in every D-interpretation. This applies only to literals typed with recognized datatype IRIs in D; literals with an unrecognized type IRI are not <a>ill-typed</a> and cannot give rise to a <a>D-unsatisfiable</a> graph. </p>
 
-<p>The built-in RDF datatype <code>rdf:langString</code> has no <a>ill-typed</a> literals. Any syntactically legal literal with this type will denote a value in every RDF interpretation. The only ill-typed literals of type <code>xsd:string</code> are those containing a Unicode code point which does not match the <em>Char</em> production in [[XML10]]. Such strings cannot be written in an XML-compatible surface syntax. 
+<p>The built-in RDF datatype <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> has no <a>ill-typed</a> literals. Any syntactically legal literal with this type will denote a value in every RDF interpretation. The only ill-typed literals of type <a href="http://www.w3.org/TR/xmlschema11-2/#string"><code>xsd:string</code></a> are those containing a Unicode code point which does not match the <a href="http://www.w3.org/TR/xml11/#NT-Char"><em>Char</em> production</a> in [[XML10]]. Such strings cannot be written in an XML-compatible surface syntax. 
 
 </p>
 
@@ -594,9 +603,9 @@
 <p>RDF imposes no particular normative meanings on the rest of the RDF vocabulary.  Appendix D describes the intended uses of some of this vocabulary.</p>
 
 
-<p>The datatype IRIs <code>rdf:langString</code> and <code>xsd:string</code> MUST be <a>recognize</a>d by all RDF interpretations. </p>
+<p>The datatype IRIs <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string"><code>rdf:langString</code></a> and <a href="http://www.w3.org/TR/xmlschema11-2/#string"><code>xsd:string</code></a> MUST be <a>recognize</a>d by all RDF interpretations. </p>
 
-<p>Two other datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in [[!RDF11-CONCEPTS]]. RDF-D interpretations MAY fail to <a>recognize</a> these datatypes. </p>
+<p>Two other datatypes <a href="http://www.w3.org/TR/rdf11-concepts/#section-XMLLiteral"><code>rdf:XMLLiteral</code></a> and <a href="http://www.w3.org/TR/rdf11-concepts/#section-html"><code>rdf:HTML</code></a> are defined in [[!RDF11-CONCEPTS]]. RDF-D interpretations MAY fail to <a>recognize</a> these datatypes. </p>
 </section>
 <section>
 
@@ -1479,7 +1488,7 @@
 </p>
 
 
-      <p>This document was prepared using the ReSpec.js writing tool developed by Robin Berjon. </p>
+      <p>This document was prepared using the <a href="http://dev.w3.org/2009/dap/ReSpec.js/documentation.html#dfn-respec">ReSpec.js specification writing tool</a> developed by Robin Berjon. </p>
        
     </section>
   </body>