Subsequent to agreement between PFPS and AZ and Pat, definition of entailment by a set of graphs has been removed. Technical note added to point out how to deal with this. Paragraph added to section 10 stating that dataset semantics is that of its default graph.
authorPat Hayes <phayes@ihmc.us>
Thu, 20 Jun 2013 01:43:04 -0500
changeset 860 9cb14ea07161
parent 859 9b7903f00547
child 861 99f024c81d42
Subsequent to agreement between PFPS and AZ and Pat, definition of entailment by a set of graphs has been removed. Technical note added to point out how to deal with this. Paragraph added to section 10 stating that dataset semantics is that of its default graph.
rdf-mt/index.html
--- a/rdf-mt/index.html	Wed Jun 19 12:29:10 2013 -0500
+++ b/rdf-mt/index.html	Thu Jun 20 01:43:04 2013 -0500
@@ -192,7 +192,7 @@
 <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]], <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>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. Some cases are illustrated by node-arc diagrams showing the graph structure directly.</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 
@@ -247,7 +247,7 @@
 the same document or from the same <a class="externalDFN" href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF source</a>.</p>
 
 <p> 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> For example, two documents may both use the blank node identifier "<code>_:x</code>" to identify a blank node, but unless these documents are in a shared identifier scope or are derived from a common source, the occurrences of "<code>_:x</code>" in one document will identify a different blank node than the one in the graph described by the other document. When graphs are formed by combining RDF from multiple sources, it may be necessary to <dfn>standardize apart</dfn> the blank node identifiers by replacing them by others which do not occur in the other document(s). For example, the two graphs represented  by the following texts: </p> 
+<p> For example, two documents may both use the blank node identifier "<code>_:x</code>" to identify a blank node, but unless these documents are in a shared identifier scope or are derived from a common source, the occurrences of "<code>_:x</code>" in one document will identify a different blank node than the one in the graph described by the other document. When graphs are formed by combining RDF from multiple sources, it may be necessary to <dfn>standardize</dfn> apart the blank node identifiers by replacing them by others which do not occur in the other document(s). For example, the two graphs represented  by the following texts: </p> 
 <p><code>ex:a ex:p _:x . </code><br/><br/>
 <img src="RDF11SemanticsDiagrams/example1.jpg" /></p>
 <p><code>ex:b ex:q _:x . </code><br/><br/>
@@ -264,11 +264,11 @@
 
 <p>describes a graph containing three nodes:</p>
 <p><img src="RDF11SemanticsDiagrams/example3.jpg"></p>
-<p> since the two occurrences of the blank node identifier "<code>_:x</code>" occurring in a common identifier scope identify the same blank node. The union of these two graphs is more properly described by a surface form such as:</p>
+<p> since the two occurrences of the blank node identifier "<code>_:x</code>" occurring in a common identifier scope identify the same blank node. The four-node union of these two graphs is more properly described by a surface form such as:</p>
 <p><code>ex:a ex:p _:x1 .<br/>
 ex:b ex:q _:x2 .</code></p>
 
-<p>in which the blank node identifiers have been standardized apart to avoid conflating the distinct blank nodes. (The particular blank node identifiers used have no significance, only that they are distinct.) </p>
+<p>in which the blank node identifiers have been <a>standardize</a>d apart to avoid conflating the distinct blank nodes. (The particular blank node identifiers used have no significance, only that they are distinct.) </p>
 
 <p>It is possible for two or more graphs to share a blank node, for example if they are subgraphs of a single larger graph or derived from a common source. In this case, the union of a set of graphs preserves the identity of blank nodes shared between the graphs. In general, the union of a set of RDF graphs accurately represents the same semantic content as the graphs themselves, whether or not they share blank nodes. </p>
 <p>A related operation, called <dfn>merging</dfn>, takes the union after forcing any shared blank nodes, which occur in more than one graph, to be distinct in each graph. The resulting graph is called the <dfn>merge</dfn>. The merge of subgraphs of a graph may be larger than the original graph. For example, the result of merging the two singleton subgraphs of the three-node graph</p> 
@@ -281,7 +281,6 @@
 
 <p>The union is always an instance of the merge. If graphs have no blank nodes in common, then their merge and union are identical. </p>
 
-<p>If S is a set of graphs, then the set obtained by replacing any subsets of S which share a blank node by their union, is the <dfn>unionizing</dfn> of S. If no graphs in S share any blank nodes, then the unionizing of S is the same as S. The unionizing of S accurately represents the combined meaning of the graphs in S. </p>
 
 </section>
 
@@ -402,7 +401,7 @@
 <p> and an interpretation I over the universe {Alice, Bob, Monica, Ruth} with:<br/>
 I(<code>ex:Alice</code>)=Alice, I(<code>ex:Bob</code>)=Bob, IEXT(I(<code>ex:hasChild</code>))={&lt;Alice,Monica&gt;,&lt;Bob,Ruth&gt; }<br/></p>
 <p>Each of the inner graphs is true under this interpretation, but the two of them together is not, because the three-node graph says that Alice and Bob have a child together. In order to capture the full meaning of graphs sharing a blank node, it is necessary to consider the union graph containing all the triples which contain the blank node.</p>
-<p class="technote"> RDF graphs can be viewed as conjunctions of simple atomic sentences in first-order logic, where blank nodes are free variables which are understood to be existential. Taking the union of two graphs is then analogous to syntactic conjunction in this syntax. RDF syntax has no explicit variable-binding quantifiers, so the truth conditions for any RDF graph treat the free variables in that graph as existentially quantified in that graph. Taking the union of graphs which share a blank node changes the implied quantifier scopes. The unionizing of a set of graphs accurately reflects the smallest quantifier scopes which capture the full meaning of the graphs in the set.
+<p class="technote"> RDF graphs can be viewed as conjunctions of simple atomic sentences in first-order logic, where blank nodes are free variables which are understood to be existential. Taking the union of two graphs is then analogous to syntactic conjunction in this syntax. RDF syntax has no explicit variable-binding quantifiers, so the truth conditions for any RDF graph treat the free variables in that graph as existentially quantified in that graph. Taking the union of graphs which share a blank node changes the implied quantifier scopes. 
 </p>
 
 
@@ -418,14 +417,14 @@
 
 <section id="simpleentailment"><h2>Simple Entailment</h2>
 
-<p>Following standard terminology, we say that I <dfn>satisfies</dfn> E when I(E)=true, that E is <dfn>satisfiable</dfn> when an interpretation exists which satisfies it, (otherwise <dfn>unsatisfiable</dfn>), that a graph G <dfn>simply entails</dfn> a graph E when every interpretation which satisfies G also satisfies E. If S is a set of graphs then S simply entails E when any every interpretation which satisfies every member of the <a>unionizing</a> of S also satisfies E. </p>
+<p>Following standard terminology, we say that I <dfn>satisfies</dfn> E when I(E)=true, that E is <dfn>satisfiable</dfn> when an interpretation exists which satisfies it, (otherwise <dfn>unsatisfiable</dfn>), and that a graph G <dfn>simply entails</dfn> a graph E when every interpretation which satisfies G also satisfies E. </p>
 <p>In later sections these notions will be adapted to other classes of interpretations, but throughout this section 'entailment' should be interpreted as meaning simple entailment.
 </p>
 
-<p class="changenote">This definition treats a set of graphs which share blank nodes identically to its union, unlike the definition used in the 2004 RDF 1.0 Semantics. This is more appropriate for the case where graphs may share blank nodes, as can occur with the graphs in an RDF dataset. If this case does not arise, this definition is identical to the previous definition.</p>
+<p class="technote">We do not define a notion of entailment between sets of graphs. To determine whether a set of graphs entails a graph, the graphs in the set must first be combined into one graph, either by taking the union or the merge of the graphs. Unions preserve the common meaning of shared blank nodes, while merging effectively ignores any sharing of blank nodes. </p>
 
     <p><a id="defvalid">Any process which constructs a graph E from
-    some other graph(s) S is (simply) <dfn>valid</dfn> if S
+    some other graph S is (simply) <dfn>valid</dfn> if S
     simply entails E in every case, otherwise <dfn>invalid.</dfn></a></p> 
 
 <p>The fact that an inference is valid should not be understood as meaning that any RDF application is obliged or required to make the inference. Similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations on RDF graphs or sources. Entailment and validity are concerned solely with establishing the conditions on such operations which guarantee the preservation of truth. While logically invalid processes, which do not follow valid entailments, are not prohibited, users should be aware that they may be at risk of introducing falsehoods into true RDF data. Nevertheless, particular uses of logically invalid processes may be justified and appropriate for data processing under circumstances where truth can be ensured by other means. </p>
@@ -471,7 +470,7 @@
 </p>
 <p class="fact"> If 
   E is a <a>lean</a> graph and E' is a <a>proper instance</a> of E, then E does 
-  not simply entail E'. 
+  not entail E'. 
 </p>
     
 <p class="fact"> If S is a subgraph of S' and S entails E, then S' entails E.
@@ -485,9 +484,6 @@
 
 <p class="fact"> If E contains an IRI which does not occur anywhere in S, then S does not entail E.</p>
 
-<p class="fact"> The merge of a set of graphs is entailed by the set, and entails every graph in the set. </p>
-
-<p>However, it is possible for G to entail every member of a set S of graphs without entailing the union of S, when the graphs share one of more blank nodes. The four-node graph illustrated in section 4.1 entails both single-triple subgraphs of the three-node graph, but it does not entail the three-node graph itself.  </p>
 
 </section>
 </section>
@@ -576,12 +572,14 @@
 <p><code>ex:a ex:p "25"^^xsd:decimal .</code>
 </p>
 
-<p>In general, any triple containing a literal with a <a>recognize</a>d datatype IRI D-entails another literal when the lexical strings of the literals map to the same value under the lexical-to-value map of the datatype.  If two different datatypes in D map lexical strings to a common value, then a triple containing a literal typed with one datatype may D-entail another triple containing a literal typed with a different datatype. For example, <code>"25"^^xsd:integer</code> and <code>"25.0"^^xsd:decimal</code> have the same value, so the above also D-entails.  (There is a W3C Note [[SWBP-XSCH-DATATYPES]] containing a long <a href="http://www.w3.org/TR/swbp-xsch-datatypes/#sec-values">discussion</a> of literal values.)</p>
+<p>In general, any triple containing a literal with a <a>recognize</a>d datatype IRI D-entails another literal when the lexical strings of the literals map to the same value under the lexical-to-value map of the datatype.  If two different datatypes in D map lexical strings to a common value, then a triple containing a literal typed with one datatype may D-entail another triple containing a literal typed with a different datatype. For example, <code>"25"^^xsd:integer</code> and <code>"25.0"^^xsd:decimal</code> have the same value, so the above also D-entails  </p>
 
 <p><code>ex:a ex:p "25"^^xsd:integer .</code></p>
 
 <p>when D also contains <code>xsd:integer</code>.
 
+<p>(There is a W3C Note [[SWBP-XSCH-DATATYPES]] containing a long <a href="http://www.w3.org/TR/swbp-xsch-datatypes/#sec-values">discussion</a> of literal values.)</p>
+
 <p><a>ill-typed</a> literals are the only way in which a graph can be simply <a>D-unsatisfiable</a>, but datatypes can give rise to a variety of other unsatisfiable graphs when combined with the RDFS vocabulary, defined later.</p>
 </section>
 
@@ -1065,11 +1063,13 @@
 </section>
 </section>
 <section><h2>RDF Datasets</h2>
-<p>An RDF <a class="externalDFN">dataset</a> (see [[!RDF11-CONCEPTS]]) is a finite set of RDF graphs each paired with an IRI called the <strong>graph name</strong>, plus a <strong>default graph</strong>, without a name. Graphs in a single dataset may share blank nodes. The association of graph name IRIs with graphs is used by SPARQL [[RDF-SPARQL-QUERY]] to allow queries to be directed against particular graphs.</p>
+<p>An RDF <a class="externalDFN">dataset</a> (see [[!RDF11-CONCEPTS]]) is a finite set of RDF graphs each paired with an IRI or blank node called the <strong>graph name</strong>, plus a <strong>default graph</strong>, without a name. Graphs in a single dataset may share blank nodes. The association of graph name IRIs with graphs is used by SPARQL [[RDF-SPARQL-QUERY]] to allow queries to be directed against particular graphs.</p>
 
-<p>Although the IRIs are called "graph names", they may refer to something other than the graph they are paired with. This allows IRI referring to other kinds of entities, such as persons, to be used in a dataset to <a>identify</a> graphs of information relevant to the entity <a>denote</a>d by the graph name IRI.</p>
+<p>Graph names in a dataset may refer to something other than the graph they are paired with. This allows IRI referring to other kinds of entities, such as persons, to be used in a dataset to <a>identify</a> graphs of information relevant to the entity <a>denote</a>d by the graph name IRI.</p>
 
-<p>When a graph name IRI is used inside RDF triples in a dataset it may or may not refer to the graph it names. The semantics does not require, nor should RDF engines presume, without some external reason to do so, that graph name IRIs used in RDF triples refer to the graph they name.</p>
+<p>When a graph name is used inside RDF triples in a dataset it may or may not refer to the graph it names. The semantics does not require, nor should RDF engines presume, without some external reason to do so, that graph names used in RDF triples refer to the graph they name.</p>
+
+<p>If a dataset is published as an assertion then it MUST be interpreted to be an assertion of its default graph. Semantic extensions MAY impose extra conditions which require other named graphs in the dataset to be interpreted in particular ways. </p>
 
 </section>