Minor changes after PFPS comments.
authorPat Hayes <phayes@ihmc.us>
Thu, 07 Mar 2013 10:47:10 -0600
changeset 627 9940e18240c6
parent 625 03152b4860af
child 628 ca9988c5da4d
Minor changes after PFPS comments.
rdf-mt/index.html
--- a/rdf-mt/index.html	Wed Mar 06 00:09:11 2013 -0600
+++ b/rdf-mt/index.html	Thu Mar 07 10:47:10 2013 -0600
@@ -539,10 +539,10 @@
 
   <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"></a></p>
 <h1 property="dcterms:title" class="title" id="title">RDF 1.1 Semantics</h1>
-<h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-03-05T00:00:00+0000" id="w3c-working-draft-5-March-2013"> Editor's Working Draft 5 March 2013</h2><dl><dt>This version:</dt><dd><a href="https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html">https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html</a></dd><dt>Latest published version:</dt><dd><a href=""></a></dd><dt>Latest editor's draft:</dt><dd><a href=""></a></dd>
+<h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-03-07T00:00:00+0000" id="w3c-working-draft-7-March-2013"> Editor's Working Draft 7 March 2013</h2><dl><dt>This version:</dt><dd><a href="https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html">https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html</a></dd><dt>Latest published version:</dt><dd><a href=""></a></dd><dt>Latest editor's draft:</dt><dd><a href=""></a></dd>
 <dt>Previous version:</dt><dd><a rel="dcterms:replaces" href=""></a></dd><dt>Latest recommendation:</dt><dd><a href="http://www.w3.org/TR/rdf-mt/">http://www.w3.org/TR/rdf-mt/</a></dd><dt>Editors:</dt><dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Patrick Hayes" href="http://www.ihmc.us/groups/phayes/">Patrick Hayes</a>, <a rel="foaf:workplaceHomepage" href="http://www.ihmc.us/index.php">Florida IHMC</a></span>
 </dd>
-<dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Peter F. Patel-Schneider" href="////">Peter F. Patel-Schneider</a>, <a rel="foaf:workplaceHomepage" href="////">////</a></span>
+<dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Peter F. Patel-Schneider" href="////">Peter F. Patel-Schneider</a>, <a rel="foaf:workplaceHomepage" href="http://www.nuance.com/">Nuance Communications</a></span>
 </dd>
 
 <dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><span property="foaf:name">David Wood</span>, <a rel="foaf:workplaceHomepage" href="http://3roundstones.com/">3 Round Stones </a>(Series Editor)</span>
@@ -623,7 +623,7 @@
           <p>3. A mapping IEXT from IP into the powerset of IR x IR i.e. the
             set of sets of pairs &lt; x, y &gt; with x and y in IR .</p>
       <p>4. A mapping IS from IRIs into (IR union IP)</p>
-      <p>5. A partial mapping IL from literals in V into IR </p>
+      <p>5. A partial mapping IL from literals into IR </p>
      </td>
   </tr>
   </table>
@@ -688,7 +688,7 @@
 <p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to identify any particular thing. They play a similar role to existentially quantified variables in a conventional logical notation. This is not the same as assuming that the blank node indicates an 'unknown' IRI. 
 </p>
 
-<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node <em>scope</em>. Note that all blank nodes in an RDF graph must be in a single scope, but that a scope might extend beyond a single graph. For example, a TriG document ///ref/// defines a blank node scope which extends over all graphs in the dataset described by the document.</p>
+<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node <em>scope</em>. Note that all blank nodes in an RDF graph must be in a single scope, but that a scope might extend beyond a single graph. For example, a TriG document ///ref/// defines a blank node scope which extends over all graphs in the dataset described by the document. Two graphs not in the same blank node scope do not share any blank nodes.</p>
 
 <p class="issue">The Concepts document does not yet define blank node scopes.</p>
 
@@ -716,11 +716,6 @@
 
 <p>All semantic extensions of any vocabulary or higher-level notation encoded in RDF <a class="RFC2119">MUST</a> conform to these minimal truth conditions. Other semantic extensions may extend and add to these, but they <a class="RFC2119">MUST NOT</a> over-ride or negate them. </p>
 
-<h3>Merging Graphs</h3>
-
-<p> <a id="defmerge" name="defmerge"></a>Any set of graphs can be treated as a single graph simply by taking the union of the sets of triples. If two or more graphs are in the same scope, then the same blank node might occur in more than one of them, and will retain its identity when the union graph is formed. If the graphs in a set are from different scopes they cannot share blank nodes, so if they are represented by a notation which uses blank node identifiers then care must be taken to change the identifiers to avoid name clashes between blank node identifiers used in graphs from different scopes. Once this is done &minus; that is, when graphs from different scopes do not use the same blank node identifier &minus; then the union graph can be formed by taking the union of the triples in the various graphs in S. We will refer to this process of forming the union of graphs as <em>merging</em>, and to the union graph as the <em>merge</em> of the original graphs. </p>
-
-<p class="changenote"> The 2004 RDF 1.0 specification did not define a notion of blank node scope, so allowed the possibility of two graphs 'accidentally' sharing a blank node. It was therefore obliged to define a process of 'standardizing apart' blank nodes, and to distinguish graph unions from graph merges. Requiring each RDF graph to be in a single blank node scope simplifies the basic syntax and renders this distinction unnecessary. Standardizing apart may still be needed at a concrete syntax level, but is not part of the underlying conceptual model of RDF. The earlier terminology is retained to avoid confusion, but now 'merging' simply means 'taking the union' at the graph syntax level.</p>
 
 <h3>Simple Entailment</h3>
 
@@ -739,6 +734,70 @@
 
 <p>Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest //ref// which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest validly entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF semantic extension. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
 
+<h3><a name="graphdefs" id="graphdefs">Graph Definitions </h3>
+
+<p class="issue">This section is lifted almost verbatim from the 2004 document. Some of these definitions may not be needed. This will be cleaned up in a final edit.<br/><br/>
+The notions of instance and equivalence may (?) need to be stated more carefully taking bnode scopes into account. Instance mappings should be defined on a whole scope rather than a graph?.
+
+    
+<p><a name="defgraph" id="defgraph">An <span > <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-rdf-graph"><em>RDF 
+  graph</em></a></span>, or simply a <em>graph</em>, is a set of RDF triples.</a></p>
+<p><a name="defsubg" id="defsubg">A <i>subgraph</i> of an RDF graph is a subset 
+  of the triples in the graph.</a> A triple is identified with the singleton set 
+  containing it, so that each triple in a graph is considered to be a subgraph. 
+  A <em>proper</em> subgraph is a proper subset of the triples in the graph. </p>
+
+    
+<p><a name="defgd" id="defgd">A <em>ground</em> RDF graph is one with no blank 
+  nodes.</a></p>
+
+    
+<p><a name="defname" id="defname">A <em>name</em> is an IRI or a literal.</a> 
+  Note that a typed literal comprises
+  two <a href="#defname"  class="termref">name</a>s: itself and its internal type 
+  IRI. </p>
+<p><a name="defvocab" id="defvocab"></a> A set of <a href="#defname"  class="termref">name</a>s 
+  is referred to as a <i>vocabulary</i>. The vocabulary <em>of</em> a graph is 
+  the set of names which occur as the subject, predicate or object of any triple 
+  in the graph. IRIs which occur only inside typed literals 
+  are not required to be in the vocabulary of the graph.</p>
+<p><a name="definst" id="definst"> Suppose that M is a functional mapping from a set of blank 
+  nodes to some set of literals, blank nodes and IRIs. Any graph obtained 
+  from a graph G by replacing some or all of the blank nodes N in G by M(N) is 
+  an <em>instance</em> of G.</a> Any graph is an instance of itself, 
+  an instance of an instance of G is an instance of G,
+  and if H is an instance of G then every triple in H is an instance of some triple 
+  in G.</p>
+<p><a name="definstvoc" id="definstvoc">An instance <i>with respect to a vocabulary</i> 
+  V </a>is an <a href="#definst" class="termref">instance</a> in which all the 
+  <a href="#defname" class="termref">name</a>s in the instance that were substituted 
+  for blank nodes in the original are <a href="#defname" class="termref">name</a>s 
+  from V.</p>
+<p><a name="defpropinst" id="defpropinst">A <i>proper</i> instance</a> of a graph 
+  is an instance in which a blank node has been replaced by a name, or two blank 
+  nodes in the graph have been mapped into the same node in the instance. </p>
+<p >Any instance of a graph in which a blank node is mapped to a new blank node 
+  not in the original graph is an instance of the original and also has it as 
+  an instance, and this process can be iterated so that any 1:1 mapping between 
+  blank nodes defines an instance of a graph which has the original graph as an 
+  instance. Two such graphs, each an instance of the other but neither a proper 
+  instance, which differ only in the identity of their blank nodes, are considered 
+  to be <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-graph-equality">equivalent</a>. 
+  We will often treat such equivalent graphs as identical. Equivalent graphs are mutual instances with an invertible instance 
+  mapping.</p>
+<p ><span ><a id="deflean"
+    name="deflean">An RDF graph is <em>lean</em> if it has no instance which is 
+  a proper subgraph of the graph.</a> Non-lean graphs have internal redundancy 
+  and express the same content as their lean subgraphs. For example, the graph</span></p>
+<p ><code>&lt;ex:a&gt; &lt;ex:p&gt; _:x .<br />
+  _:y &lt;ex:p&gt; _:x .</code></p>
+<p >is not <a
+      href="#deflean" class="termref">lean</a>, but</p>
+<p ><code>&lt;ex:a&gt; &lt;ex:p&gt; _:x .<br />
+  _:x &lt;ex:p&gt; _:x .</code></p>
+<p >is <a
+      href="#deflean" class="termref">lean</a>. </p>
+
 <h3>Some basic properties of simple entailment. </h3>    
 <p>The properties described here apply only to simple entailment, not to extended notions 
   of entailment introduced in later sections. Proofs
@@ -785,6 +844,11 @@
   If S entails E and E is a finite graph, then some finite subset S' of S entails 
   E. <a href="#compactlemmaprf" class="termref"> [Proof]</a></p>
 
+<h3>Merging Graphs</h3>
+
+<p> <a id="defmerge" name="defmerge"></a>Any set of graphs can be treated as a single graph simply by taking the union of the sets of triples. If two or more graphs are in the same scope, then the same blank node might occur in more than one of them, and will retain its identity when the union graph is formed. If the graphs in a set are from different scopes they cannot share blank nodes, so if they are represented by a notation which uses blank node identifiers then care must be taken to change the identifiers to avoid name clashes between blank node identifiers used in graphs from different scopes. Once this is done &minus; that is, when graphs from different scopes do not use the same blank node identifier &minus; then the union graph can be formed by taking the union of the triples in the various graphs in S. We will refer to this process of forming the union of graphs as <em>merging</em>, and to the union graph as the <em>merge</em> of the original graphs. </p>
+
+<p class="changenote"> The 2004 RDF 1.0 specification did not define a notion of blank node scope, so allowed the possibility of two graphs 'accidentally' sharing a blank node. It was therefore obliged to define a process of 'standardizing apart' blank nodes, and to distinguish graph unions from graph merges. Requiring each RDF graph to be in a single blank node scope simplifies the basic syntax and renders this distinction unnecessary. Standardizing apart may still be needed at a concrete syntax level, but is not part of the underlying conceptual model of RDF. The earlier terminology is retained to avoid confusion, but now 'merging' simply means 'taking the union' at the graph syntax level.</p>
 
 
 <h3>Skolemization</h3>
@@ -828,19 +892,19 @@
 
 
 <p>RDF literals and datatypes are fully described in ///Concepts///. In summary: RDF literals are either language-tagged strings, or datatyped literals which 
-combine a string and an IRI identifying a datatype. A datatype is understood to define a partial mapping, the <em>lexical-to-value mapping</em>, from character strings to values, and the literal refers to the value obtained by applying this mapping to the character string. If the mapping gives no value for the literal string, then the literal has no referent.  A literal whose datatype IRI is recognized, but whose character string is not in the domain of the datatype lexical-to-value mapping, is called <em>ill-typed</em>. A literal which is not ill-typed is <em>well-typed</em>. The <em> value space</em> of a datatype is the range of the lexical-to-value mapping, i.e. the set of all values of well-typed literals of that datatype.
-Datatypes are indicated by IRIs, formally in terms of a <em>datatype map</em> from a set of <em>recognized</em> IRIs to datatypes.
+combine a string and an IRI identifying a datatype. A datatype is understood to define a partial mapping, the <em>lexical-to-value mapping</em>, from character strings to values, and the literal refers to the value obtained by applying this mapping to the character string. If the mapping gives no value for the literal string, then the literal has no referent. The <em> value space</em> of a datatype is the range of the lexical-to-value mapping. Every literal with that type either refers to a value in the value space, or fails to refer at all. A literal whose datatype IRI is recognized, but whose character string is not in the domain of the datatype lexical-to-value mapping, is called <em>ill-typed</em>.
+Datatypes are indicated by IRIs.
 </p>
 
-<p> Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is a datatype map. We will indicate a datatype map by the set of recognized datatype IRIs. </p>
-
-<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a datatype. Literals with an "unknown" datatype IRI which is not in the set of recognized datatypes, are treated like IRI names and assumed to denote some thing in the universe IR. </p>
+<p> Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is a set of IRIs that constitute the recognized datatype IRIs. IRIs listed in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#xsd-datatypes">///Concepts Section 5///</a> <strong class="RFC2119">MUST</strong> be interpreted as described there, and the IRI <code>rdf:plainLiteral</code> <strong class="RFC2119">MUST</strong> be interpreted to refer to the datatype defined in <a href="www.w3.org/TR/rdf-plain-literal/">///PlainLiteral///</a>. When other datatypes are used, the mapping between a recognized IRI and the datatype it refers to <strong class="RFC2119">MUST</strong> be specified unambiguously, and be fixed during all RDF transformations or manipulations.</p> </p>
 
 <p>Language-tagged strings 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. (If datatype L2V mappings were defined on pairs of lexical values rather than strings, then the L2V mapping for <code>rdf:langString</code> would be the identity function on pairs of the form < unicode string, language tag >. But as they are not, we simply list this as a special case.)</p>
 
 <p class="issue">This will require alignment with Concepts.  rdf:langString may have an L2V mapping which is ignored by the semantics. Concepts currently states that it is not a datatype even though the IRI is a datatype IRI. </p>
 
-<p>Datatype maps <strong class="RFC2119">MUST</strong> interpret any IRI listed in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#xsd-datatypes">///Concepts Section 5///</a> as described there, and the IRI <code>rdf:plainLiteral</code> <strong class="RFC2119">MUST</strong> be interpreted to refer to the datatype defined in <a href="www.w3.org/TR/rdf-plain-literal/">///PlainLiteral///</a>. When other datatypes are used, the mapping between a recognized IRI and the datatype it refers to <strong class="RFC2119">MUST</strong> be specified unambiguously, and be fixed during all RDF transformations or manipulations.</p>
+<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a datatype. Literals with an "unknown" datatype IRI which is not in the set of recognized datatypes, are treated like IRI names and assumed to denote some thing in the universe IR. </p>
+
+
 
 
 <h3>D-interpretations</h3>
@@ -870,7 +934,7 @@
 <p>In all of this language, 'D' is being used as a parameter to represent some set of datatype IRIs, and different D sets will yield different notions of satisfiability and entailment. The more datatypes are recognized, the stronger is the entailment, so that if D &subset; E and S E-entails G then S must D-entail G. Simple entailment is { }-entailment, i.e. D-entailment when D is the empty set. If S D-entails G then S simply entails G, but not the reverse. </p>
 
 <p>Several of the basic properties of simple entailment are also true for D-entailment, but the <a href="#interplemma" class="termref">interpolation lemma</a> is not true for D-entailment, since D-entailments 
-can hold because of particular properties of the lexical-to-value mappings of the  recognized datatypes. For example, if D contains <code>xsd:number</code> then </p>
+can hold because of particular properties of the lexical-to-value mappings of the  recognized datatypes. For example, if D contains <code>xsd:integer</code> then </p>
 
 <p><code>aaa ppp "00025"^^xsd:integer .</code></p>
 
@@ -1004,7 +1068,6 @@
     <td class="semantictable"> <p><a name="rdfssemcond1" id="rdfssemcond1"></a>ICEXT(y) is defined to be { x : &lt; x,y &gt; is in IEXT(I(<code>rdf:type</code>)) }</p>
         <p>IC is defined to be ICEXT(I(<code>rdfs:Class</code>))</p>
         <p>LV is defined to be ICEXT(I(<code>rdfs:Literal</code>))</p>
-        <p>IL(E) is in LV, for every well-typed literal E</p>
         <p>ICEXT(I(<code>rdfs:Resource</code>)) = IR</p>
 <p>ICEXT(I(<code>rdf:langString</code>)) is the set {I(E) : E a language-tagged string }</p>
 <p>for every other IRI aaa in D, ICEXT(I(aaa)) is the value space of I(aaa)</p>
@@ -1139,7 +1202,7 @@
 
 <p>Since I is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, the first condition implies that IP 
   = ICEXT(I(<code>rdf:Property</code>)).</p>
- <p>The semantic conditions on rdf-D-interpretations, together with the RDFS conditions on ICEXT, mean that every recognized datatype can be treated as an RDFS class, whose extension is the value space of the datatype: ICEXT(I(aaa)) = {&nbsp;x&nbsp;:&nbsp;x=L2V(I(aaa))(sss) for some string sss&nbsp;} , when aaa is a datatype IRI in D. </p>
+ <p>The semantic conditions on rdf-D-interpretations, together with the RDFS conditions on ICEXT, mean that every recognized datatype can be treated as an RDFS class whose extension is the value space of the datatype, and every literal with that datatype either fails to refer (if the literal is ill-typed) or else refers to a value in that class.</p>
 <p>These axioms and conditions have some redundancy. For example, all but one 
   of the RDF axiomatic triples can be derived from the RDFS axiomatic triples 
   and the semantic conditions on ICEXT,<code> rdfs:domain</code> and <code>rdfs:range</code>. 
@@ -1219,7 +1282,7 @@
   complete</a> set of RDFS entailment rules, described in <a href="#RDFSRules" class="termref"> ////</a>.</p>
 <h3><a name="literalnote" id="literalnote">4.3 A Note on rdfs:Literal</a> </h3>
 
-    <p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal <em>values</em>. For example, LV does not contain the literal <code>"24"^^xsd:number</code> (although it may contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#number</code>' ) but it does contain the number twenty-four.</p>
+    <p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal <em>values</em>. For example, LV does not contain the literal <code>"24"^^xsd:integer</code> (although it may contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#integer</code>' ) but it does contain the number twenty-four.</p>
 
   <p>A triple of the form</p>
 
@@ -1227,8 +1290,7 @@
 
     <p>is consistent even though its subject is an IRI rather
     than a literal. It says that the IRI '<code>ex:a</code>'
-    refers to a literal value, which is quite possible since literal values are things in the universe. It does not, of course, specify exactly which
-    literal value it refers to. Similarly, blank nodes may range over literal values. </p>
+    refers to a literal value, which is quite possible since literal values are things in the universe. Similarly, blank nodes may range over literal values. </p>
 
     
 <h3><a name="rdfs_entailment" id="rdfs_entailment"></a>4.4 RDFS Entailment</h3>