--- a/rdf-mt/index.html Fri Jun 14 17:49:53 2013 +0100
+++ b/rdf-mt/index.html Mon Jun 17 02:27:26 2013 -0500
@@ -177,8 +177,8 @@
<p>A particular such set of semantic assumptions is called a <dfn>semantic extension</dfn>. Each <a>semantic extension</a> defines an <dfn>entailment regime</dfn> of entailments which are valid under that extension. RDFS, described later in this document, is one such <a>semantic extension</a>. We will refer to an entailment regime by names such as <em> RDFS entailment</em>, <em>D-entailment</em>, etc. </p>
<p><a>Semantic extension</a>s MAY impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and MAY consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br/><br/>
-<code>ex:a rdfs:subClassOf owl:Thing .</code><br/><br/>
-are prohibited in the OWL-DL [[OWL2-SYNTAX]] <a>semantic extension</a>. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions. None of the <a>semantic extension</a>s normatively defined in this document impose such syntactic restrictions on RDF graphs.</p>
+<code>ex:a rdfs:subClassOf "Thing"^^xsd:string .</code><br/><br/>
+are prohibited in the OWL-DL [[[OWL2-PROFILES]] <a>semantic extension</a>. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions. None of the <a>semantic extension</a>s normatively defined in this document impose such syntactic restrictions on RDF graphs.</p>
<p>All entailment regimes MUST be <a>monotonic</a> extensions of the simple entailment regime described in the document, in the sense that if A <a>simply entails</a> B then A also entails B under any extended notion of entailment, provided that any syntactic conditions of the extension are also satisfied. Put another way, a <a>semantic extension</a> cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
</section>
@@ -229,17 +229,6 @@
<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
-described by documents or other structures (such as the data
-structures in an RDF store) that explicitly provide for the sharing
-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 <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>
-
<p >An RDF graph is <dfn>lean</dfn> if it has no instance which is
a proper subgraph of itself. Non-lean graphs have internal redundancy
and express the same content as their lean subgraphs. For example, the graph</p>
@@ -250,7 +239,53 @@
_:x ex:p _:x .</code></p>
<p >is lean. <a>Ground</a> graphs are lean. </p>
- </section>
+
+<section> <h3>Shared blank nodes, unions and merges</h3>
+<p>
+Graphs share blank nodes only if they are derived from graphs
+described by documents or other structures (such as an RDF dataset) that explicitly provide for the sharing 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 <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><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/>
+<img src="RDF11SemanticsDiagrams/example2.jpg"></p>
+
+<p>contain four nodes. Their union would therefore also contain four nodes:</p>
+
+<p><img src="RDF11SemanticsDiagrams/example4.jpg"></p>
+
+<p> However, the document formed by simply concatenating these textual surface representations: </p>
+
+<p><code>ex:a ex:p _:x .<br/>
+ex:b ex:q _:x .</code><br/></p>
+
+<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><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>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>
+
+<p><img src="RDF11SemanticsDiagrams/example3.jpg"></p>
+
+<p>is the four-node graph</p>
+
+<p><img src="RDF11SemanticsDiagrams/example4.jpg"></p>
+
+<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>
+
+</section>
+
+</section>
<section>
<h2 id="simple"> Simple Interpretations</h2>
@@ -295,7 +330,7 @@
<p>The denotation of a ground RDF graph in an interpretation I is then given by the following
- rules, where the interpretation is also treated as a function from expressions (names, triples and graphs) to semantic values:</p>
+ rules, where the interpretation is also treated as a function from expressions (names, triples and graphs) to elements of the universe and truth values:</p>
<div class="tabletitle">Semantic conditions for ground graphs.</div>
@@ -359,13 +394,24 @@
Blank nodes themselves differ from other nodes in not being assigned
a denotation by an interpretation, reflecting the intuition that
they have no 'global' meaning. </p>
+
+<section><h3>Shared blank nodes</h3>
+
+<p> The semantics for blank nodes are stated in terms of the truth of a graph. However, when two (or more) graphs share a blank node, their meaning is not fully captured by treating them in isolation. For example, consider the overlapping graphs</p>
+<p><img src="RDF11SemanticsDiagrams/example5.jpg"></p>
+<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>))={<Alice,Monica>,<Bob,Ruth> }<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>
+
+
+</section>
</section>
<section class="informative">
-<h3 id="intuitions">Intuitive summary</h3>
+<h3 id="intuitions" class="informative">Intuitive summary (Informative)</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 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>
<section id="simpleentailment"><h2>Simple Entailment</h2>
@@ -383,7 +429,7 @@
<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 [[RDF-TESTCASES]] 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 simply 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 <a>semantic extension</a>. 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>
-
+</section>
<section>
@@ -394,7 +440,7 @@
<p>This does not hold for extended notions of interpretation. For example, a graph containing an <a>ill-typed</a> literal is <a>D-unsatisfiable</a>.</p>
-<p><a>Simple entailment</a> can be detected by relatively simple syntactic comparisons. The two basic forms of simply valid inference in RDF are, in logical terms, the inference from <code>(P and Q)</code> to <code>P</code>, and the inference from <code>foo(baz)</code> to <code>(exists (x) foo(x) ) </code>. The first corresponds to taking a subgraph of a graph, the second to replacing an IRI or literal with a blank node. More precisely, the following <dfn>interpolation</dfn> <strong>lemma</strong> </p>
+<p>The following <dfn>interpolation</dfn> <strong>lemma</strong> </p>
<p class="fact">
G simply entails a graph E if and only if a subgraph of G is an instance of E.
@@ -405,7 +451,7 @@
there is some instance of the entailed graph which is a subset of the union
of the original set of graphs. </p>
-<p class="technote">This is clearly decidable, but it is also difficult in general, since one can encode the NP-hard subgraph problem (detecting whether one mathematical graph is a subgraph of another) as detecting simple entailment between RDF graphs. This construction (due to Jeremy Carroll) uses graphs containing many blank nodes, which are unlikely to occur in practice. The complexity of checking simple entailment is reduced by having fewer blank nodes in the conclusion E. When E is a <a>ground</a> graph, it is simply a matter of checking the subset relationship on sets of triples.</p>
+<p class="technote">This is clearly decidable, but it is also difficult to determine in general, since one can encode the NP-hard subgraph problem (detecting whether one mathematical graph is a subgraph of another) as detecting simple entailment between RDF graphs. This construction (due to Jeremy Carroll) uses graphs containing many blank nodes, which are unlikely to occur in practice. The complexity of checking simple entailment is reduced by having fewer blank nodes in the conclusion E. When E is a <a>ground</a> graph, it is simply a matter of checking the subset relationship on sets of triples.</p>
<p><a>Interpolation</a> has a number of direct consequences, for example:</p>
@@ -436,32 +482,9 @@
<p class="fact"> If E contains an IRI which does not occur anywhere in S, then S does not entail E.</p>
-<p>When forming the union of graphs, care must be taken over the identity of blank nodes. For example, the following graph contains three nodes:</p>
-
-<p><code>ex:a ex:p _:x .<br/>
-ex:b ex:q _:x .</code></p>
-
-<p>If the two triples in this graph were separated, perhaps into two distinct RDF documents, and treated as two separate graphs</p>
-
-<p><code>ex:a ex:p _:x . </code></p>
-
-<p>and</p>
-
-<p><code>ex:b ex:q _:x . </code></p>
-
-<p>and these two documents then combined, the two occurrences of the blank node identifier would be understood to identify distinct blank nodes, which remain distinct when the union of these graphs is created. The resulting union</p>
-
-<p><code>ex:a ex:p _:x1 .<br/>
-ex:b ex:q _:x2 .</code></p>
-
-
-<p>contains four nodes rather than three, and is entailed by the original graph but does not entail it. </p>
-
-<p>The process of combining graphs while forcing a separation of their blank nodes is called <dfn>merging</dfn>, and the result of merging a set of graphs is called its <dfn>merge</dfn>. Merging is typically achieved by replacing blank node identifiers in the surface syntax to avoid accidentally conflating blank nodes identified by the same blank node identifier in different documents. </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>As the above example illustrates, the fact that G entails every member of S does not imply that G entails the union of S. </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>
@@ -483,22 +506,20 @@
<section><h2 id="datatypes">Literals and datatypes</h2>
<p class="changenote"> In the 2004 RDF 1.0 specification, datatype D-entailment was defined as a <a>semantic extension</a> of RDFS-entailment. Here it is defined as a direct extension to basic RDF. This is more in conformity with actual usage, where RDF with datatypes is widely used without the RDFS vocabulary. If there is a need to distinguish this from the 2004 RDF 1.0 terminology, the longer phrasing "simple D-entailment" or "simple datatype entailment" should be used rather than "D-entailment". </p>
-<p> Datatypes are identified by IRIs. Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is the set of <dfn>recognize</dfn><strong>d</strong> datatype IRIs. </p>
+<p> Datatypes are <a title="identify">identified</a> by IRIs. Interpretations will vary according to which IRIs they recognize as denoting datatypes. We describe this using a parameter D on interpretations. where D is the set of <dfn>recognize</dfn><strong>d</strong> datatype IRIs. We assume that a recognized IRI <a title+"identify">identifies</a> a unique datatype wherever it occurs, and the semantics requires that it refers to this identified datatype. The exact mechanism by which an IRI <a title="identify">identifies</a> a datatype IRI is considered to be external to the semantics. RDF processors which are not able to determine which datatype is identifier by an IRI cannot <a>recognize</a> that IRI, and should treat any literals type with that IRI as unknown names. </p>
-<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 class="changenote">In the 2004 RDF 1.0 specification, the semantics of datatypes referred to datatype maps. The current treatment subsumes datatype maps into the interpretation mapping on recognized IRIs.</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>
+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 denotes the value obtained by applying this mapping to the character string sss: L2V(d)(sss). 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 <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-PLAIN-LITERAL]]. 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-PLAIN-LITERAL]]. 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 <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, 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>
-
<section id="D_interpretations"><h2>D-interpretations</h2>
<p>Let D be a set of IRIs <a>identify</a>ing datatypes. A <dfn>(simple) D-interpretation</dfn> is a <a>simple interpretation</a> which satisfies the following conditions:</p>
@@ -506,11 +527,11 @@
<table border="1">
<tbody>
<tr><td class="semantictable">If <code>rdf:langString</code> is in D, then for every language-tagged string E with lexical form sss and language tag ttt, IL(E)= < sss, ttt' >, where ttt' is ttt converted to lower case using US-ASCII rules </td></tr>
-<tr><td class="semantictable">For every other IRI aaa in D, and every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(I(aaa))(sss)</td></tr>
+
+<tr><td class="semantictable">For every other IRI aaa in D, I(aaa) is the datatype identified by aaa, and for every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(I(aaa))(sss)</td></tr>
</tbody></table>
-
<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 <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.
@@ -562,6 +583,7 @@
</section>
</section>
+</section>
<section><h2 id="rdf_d_interpretations">RDF Interpretations</h2>
<p >RDF interpretations impose extra semantic conditions on <code>xsd:string</code> and part of the infinite
set of IRIs with the namespace prefix <code>rdf:</code> .
@@ -607,7 +629,8 @@
<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 <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>
<h3><a id="rdf_entail"></a>RDF entailment</h3>
@@ -659,7 +682,7 @@
</tr>
<tr>
- <td class="othertable">rdfD2</td>
+ <td class="othertable"><dfn>rdfD2</dfn></td>
<td class="othertable">xxx aaa yyy <code>.</code></td>
<td class="othertable">aaa <code>rdf:type rdf:Property .</code> </td>
</tr>
@@ -691,7 +714,7 @@
</section>
</section>
-
+</section>
<section><h2>RDFS Interpretations</h2>
<p>RDF Schema [[RDF-SCHEMA]]
extends RDF to a larger vocabulary
@@ -925,7 +948,6 @@
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. Blank nodes may range over literal values, for the same reason. </p>
</section>
-</section>
<section>
<h3 id="rdfs_entailment">RDFS Entailment</h3>
@@ -962,7 +984,7 @@
<td class="othertable">yyy <code>rdf:type</code> xxx <code>.</code></td>
</tr>
<tr >
- <td class="othertable"></a><dfn>rdfs3</dfn></td>
+ <td class="othertable"><dfn>rdfs3</dfn></td>
<td class="othertable">aaa <code>rdfs:range</code> xxx <code>.</code><br />
yyy aaa zzz <code>.</code></td>
<td class="othertable">zzz <code>rdf:type</code> xxx <code>.</code></td>
@@ -1038,9 +1060,9 @@
</section>
</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 an optional default graph, 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 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>
@@ -1050,7 +1072,7 @@
<h2>Appendices</h2>
-<section class="appendix"><h3 id="entailment_rules">Entailment rules (Informative)</h3>
+<section class="appendix" class="informative"><h3 id="entailment_rules">Entailment rules (Informative)</h3>
<p>This section is based on work described more fully in [[HORST04]], [[HORST05]], which should be consulted for technical details and proofs. </p>
<p> The RDF and RDFS entailment patterns listed in the above tables can be viewed as left-to-right rules which add the entailed conclusion to a graph. These rule sets can be used to check RDF (or RDFS) entailment between graphs S and E, by the following sequence of operations:</p>
@@ -1094,7 +1116,7 @@
</tbody>
</table>
<p> Both of these can be handled by allowing the rules to apply to a generalization of the RDF syntax in which literals may occur in subject position and blank nodes may occur in predicate position. </p>
-<p>Define a <dfn>generalized RDF triple</dfn> to be a triple <x, y, z> where x and z can be an IRI, a blank node or a literal, and y can be an IRI or a blank node; and extend this to the rest of RDF, so that a generalized RDF graph is a set of generalized RDF triples. (This extends the generalization used in [[HORST04]] and follows exactly the terms used in [[OWL2-SYNTAX]].) The semantics described in this document applies to the generalized syntax without change, so that the notions of interpretation, satisfiability and entailment can be used freely. Then we can replace the first RDF entailment pattern with the simpler and more direct</p>
+<p>Define a <dfn>generalized RDF triple</dfn> to be a triple <x, y, z> where x and z can be an IRI, a blank node or a literal, and y can be an IRI or a blank node; and extend this to the rest of RDF, so that a generalized RDF graph is a set of generalized RDF triples. (This extends the generalization used in [[HORST04]] and follows exactly the terms used in [[OWL2-PROFILES]].) The semantics described in this document applies to the generalized syntax without change, so that the notions of interpretation, satisfiability and entailment can be used freely. Then we can replace the first RDF entailment pattern with the simpler and more direct</p>
<div class="tabletitle">G-RDF-D entailment pattern.</div>
<table border="1" >
@@ -1105,7 +1127,7 @@
<th ><strong>then S RDF entails, recognizing D</strong></th>
</tr>
<tr >
- <td class="othertable">GrdfD1</td>
+ <td class="othertable"><dfn>GrdfD1</dfn></td>
<td class="othertable"> xxx aaa <code>"</code>sss<code>"^^</code>ddd <code>.</code> <br/>
for ddd in D</td>
<td class="othertable"><code>"</code>sss<code>"^^</code>ddd <code>rdf:type</code> ddd <code>.</code></td>
@@ -1117,15 +1139,15 @@
<p> which gives the entailments;</p>
<P><code>ex:a ex:p "string"^^xsd:string .<br/>
ex:b ex:q "string"^^xsd:string .<br/>
-"string"^^xsd:string rdf:type xsd:string .</code> by GrdfD1</p>
+"string"^^xsd:string rdf:type xsd:string .</code> by <a>GrdfD1</a></p>
which is an instance (in generalized RDF) of the desired conclusion, above.</p>
<p> The second example can be derived using the RDFS rules:</p>
<p><code>ex:a rdfs:subPropertyOf _:b .<br/>
_:b rdfs:domain ex:c .<br/>
ex:d ex:a ex:e .<br/>
-ex:d _:b ex:c .</code> by rdfs7<br/>
-<code>ex:d rdf:type ex:c .</code> by rdfs2</p>
+ex:d _:b ex:c .</code> by <a>rdfs7</a><br/>
+<code>ex:d rdf:type ex:c .</code> by <a>rdfs2</a></p>
<p>Where the entailment patterns have been applied to generalized RDF syntax but yield a final conclusion which is legal RDF. </p>
@@ -1134,22 +1156,22 @@
<p>1. Add to S all the RDF (and RDFS) axiomatic triples which do not contain any container membership property IRI.<br/>
2. For each container membership property IRI which occurs in E, add the RDF (and RDFS) axiomatic triples which contain that IRI.<br/>
3. If no triples were added in step 2., add the RDF (and RDFS) axiomatic triples which contain <code>rdf:_1</code>. <br/>
-4. Apply the rules GrdfD1 and rdfD2 (and the rules rdfs1 through rdfs13), with D={<code>rdf:langString</code>, <code>xsd:string</code>), to the set in all possible ways, to exhaustion. </p>
+4. Apply the rules <a>GrdfD1</a> and <a>rdfD2</a> (and the rules <a>rdfs1</a> through <a>rdfs13</a>), with D={<code>rdf:langString</code>, <code>xsd:string</code>), to the set in all possible ways, to exhaustion. </p>
<p>Then we have the completeness result:</p>
<p class="fact">If S is RDF (RDFS) consistent, then S RDF entails (RDFS entails) E just when the <a>generalized RDF (RDFS) closure</a> of S towards E simply entails E.</em> </p>
<p>The closures are finite. The generation process is decidable and of polynomial complexity. Detecting simple entailment is NP-complete in general, but of low polynomial order when E contains no blank nodes. </p>
-<p>Every RDF(S) closure, even starting with the empty graph, will contain all RDF(S) tautologies. In practice there is little utility in re-deriving these, and a subset of the rules can be used to establish most entailments of practical interest. </p>
+<p>Every RDF(S) closure, even starting with the empty graph, will contain all RDF(S) tautologies which can be expressed using the vocabulary of the original graph plus the RDF and RDFS vocabularies. In practice there is little utility in re-deriving these, and a subset of the rules can be used to establish most entailments of practical interest. </p>
-<p>If it is important to stay within legal RDF syntax, rule rdfD1 may be used instead of GrdfD1, and the introduced blank node can be used as a substitute for the literal in subsequent derivations. The resulting set of rules will not however be complete.</p>
+<p>If it is important to stay within legal RDF syntax, rule <a>rdfD1</a> may be used instead of <a>GrdfD1</a>, and the introduced blank node can be used as a substitute for the literal in subsequent derivations. The resulting set of rules will not however be complete.</p>
<p>As noted earlier, detecting datatype entailment for larger sets of datatype IRIs requires attention to idiosyncratic properties of the particular datatypes.</p>
</section>
-<section class="appendix"><h2 id="finite_interpretations">Finite interpretations (Informative)</h2>
+<section class="appendix" class="informative"><h2 id="finite_interpretations">Finite interpretations (Informative)</h2>
<p>To keep the exposition simple, the RDF semantics has been phrased in a way which requires interpretations to be larger than absolutely necessary. For example, all interpretations are required to interpret the whole IRI vocabulary, and the universes of all D-interpretations must contain all possible strings and therefore be infinite. This appendix sketches, without proof, how to re-state the semantics using smaller semantic structures, without changing any entailments. </p>
<p>Basically, it is only necessary for an interpretation structure to interpret the <a>name</a>s actually used in the graphs whose entailment is being considered, and to consider interpretations whose universes are at most as big as the number of names and blank nodes in the graphs. More formally, we can define a <dfn>pre-interpretation</dfn> over a <a>vocabulary</a> V to be a structure I similar to a <a>simple interpretation</a> but with a mapping only from V to its universe IR. Then when determining whether G entails E, consider only pre-interpretations over the finite vocabulary of <a>name</a>s actually used in G union E. The universe of such a pre-interpretation can be restricted to the cardinality N+B, where N is the size of the vocabulary and B is the number of blank nodes in the graphs. Any such pre-interpretation may be extended to <a>simple interpretation</a>s, all of which which will give the same truth values for any triples in G or E. Satisfiability, entailment and so on can then be defined with respect to these finite pre-interpretations, and shown to be identical to the ideas defined in the body of the specification.</p>
@@ -1182,12 +1204,13 @@
<p>Suppose H is an instance of G with the instantiation mapping M, and that I satisfies H. For blank nodes n in G which are not in H define A(n)=I(M(n)); then I+A satisfies G, so I satisfies G. QED.</p>
<p class="fact">Every graph is satisfiable.</p>
-<p>To show this, we construct a interpretation I from the symbols in the graph itself, called a <dfn>Herbrand interpretation</dfn>. IR contains the <a>name</a>s and blank nodes which occur in the graph, with I(n)=n for each <a>name</a> n; n is in IP and <a, b> in IEXT(n) just when the triple <a n b> is in the graph. For IRIs which do not occur in the graph, assign them values in IR at random. Then I+A, where A is the identity map on blank nodes, satisfies the graph, by construction. QED.</p>
+<p>Consider the simple interpretation with universe {x}, IEXT(x)= <x,x > and I(aaa)=x for any IRI aaa. This interpretation satisfies every RDF graph. QED.</p>
<p class="fact">
G simply entails a graph E if and only if a subgraph of G is an instance of E.
</p>
-<p>If a subgraph E' of G is an instance of E then G entails E' which entails E, so G entails E. If G entails E, then the <a>Herbrand interpretation</a> I of G satisfies every triple <s p o> in E; that is, for some mapping A from the blank nodes of E to the vocabulary of G, the triple <[I+A](s) I(p) [I+A](o)> occurs in G. But this is an instance of <s p o> under the instance mapping A; so an instance of E is a subgraph of G. QED.</p>
+
+<p>If a subgraph E' of G is an instance of E then G entails E' which entails E, so G entails E. NOw suppose G entails E, and consider the <a>Herbrand interpretation</a> I of G defined as follows. IR contains the <a>name</a>s and blank nodes which occur in the graph, with I(n)=n for each <a>name</a> n; n is in IP and <a, b> in IEXT(n) just when the triple <a n b> is in the graph. (For IRIs which do not occur in the graph, assign them values in IR at random.) I satisfies every triple <s p o> in E; that is, for some mapping A from the blank nodes of E to the vocabulary of G, the triple <[I+A](s) I(p) [I+A](o)> occurs in G. But this is an instance of <s p o> under the instance mapping A; so an instance of E is a subgraph of G. QED.</p>
<p class="fact">if E is lean and E' is a proper instance of E, then E does not entail E'.</p>
<p>Suppose E entails E', then a subgraph of E is an instance of E', which is a proper instance of E; so a subgraph of E is a proper instance of E, so E is not lean. QED.</p>
@@ -1260,7 +1283,7 @@
<p><a>Reification</a>s can be written with a blank node as subject, or with an IRI subject which does not <a>identify</a> any concrete realization of a triple, in both of which cases they simply assert the existence of the described triple. </p>
- <p>The subject of a <a>reification,/a> is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
+ <p>The subject of a <a>reification</a> is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
composition or provenance information are applied to the
reified triple, which are meaningful only when thought of as
referring to a particular instance or token of a triple. </p>
@@ -1480,11 +1503,11 @@
</section>
- <section class='appendix'>
+ <section class='appendix' class="informative">
<h2 id="acknowledgements">Acknowledgements</h2>
<p>The basic idea of using an explicit extension mapping to allow self-application without violating the axiom of foundation was
-suggested by Christopher Menzel. The generalized RDF syntax used in Appendix A, and the example showing the need for it, were suggested by Herman ter Horst, who also proved completeness and complexity results for the rule sets. Jeremy Carroll first showed that simple entailment is NP-complete in general. </p>
+suggested by Christopher Menzel. The generalized RDF syntax used in Appendix A, and the example showing the need for it, were suggested by Herman ter Horst, who also proved completeness and complexity results for the rule sets. Jeremy Carroll first showed that simple entailment is NP-complete in general. Antoine Zimmerman suggested several simplifications and improvements to the proofs and presentation.</p>
<p>The RDF 1.1 editors acknowledge valuable contributions from Thomas Baker, Dan Brickley, Gavin Carothers, Jeremy Carroll, Pierre-Antoine Champin, Richard Cyganiak, Martin J. Dürst, Alex Hall, Steve Harris, Ivan Herman, Eric Prud'hommeaux, Andy Seaborne, David Wood and Antoine Zimmermann. </p>
<p>This specification is a product of extended deliberations by <a href="http://www.w3.org/2000/09/dbwg/details?group=46168&public=1">members of the RDF Working Group</a>. It draws upon the earlier specification [[RDF-MT]], whose editor acknowledged valuable inputs from Jeremy Carroll, Dan Connolly, Jan Grant, R. V. Guha, Herman ter Horst, Graham Klyne, Ora Lassilla, Brian McBride, Sergey Melnick, Peter Patel-Schneider, Jos deRoo and Patrick Stickler.