--- a/rdf-mt/index.html Mon May 13 03:33:36 2013 -0500
+++ b/rdf-mt/index.html Wed May 15 02:01:12 2013 -0500
@@ -112,29 +112,29 @@
<h2 id="introduction">Introduction</h2>
<p>
This document defines a model-theoretic semantics for RDF graphs and the RDF and RDFS vocabularies, providing an exact formal specification of when truth is preserved by transformations of RDF or operations which derive RDF content from other RDF. </p>
-<p>This specification is normative for RDF semantics and the validity of inference processes. There are many aspects of RDF meaning which are not described or specified by this semantics, including social issues of how IRIs are assigned meanings in use, and how the referents of IRIs are related to Web content expressed in other media such as natural language texts. Accounts of such extended notions of meaning will go beyond this specification, but MUST NOT violate the conditions described here. </p>
+<p>This specification is normative for RDF semantics and the validity of inference processes. There are many aspects of RDF meaning which are not described or specified by this semantics, including social issues of how IRIs are assigned meanings in use and how the referents of IRIs are related to Web content expressed in other media such as natural language texts. Accounts of such extended notions of meaning will go beyond this specification, but MUST NOT violate the conditions described here. </p>
</section>
<section>
<h2 id="extensions">Semantic extensions and entailment regimes</h2>
<p>RDF is intended for use as a base notation for a variety of extended notations such as OWL [[OWL2-OVERVIEW]] and RIF [[RIF-OVERVIEW]], whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. Also, particular IRI vocabularies may impose user-defined meanings upon the basic RDF meaning rules. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more valid entailments it has. </p>
-<p>A particular such set of semantic assumptions is called a <dfn>semantic extension</dfn>. Each semantic extension defines an <dfn>entailment regime</dfn> of entailments which are valid under that extension. RDFS, described later in this document, is one such semantic extension. We will refer to an entailment regime by names such as <em>rdfs-entailment</em>, <em>D-entailment</em>, etc. </p>
+<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>Semantic extensions 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/>
+<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/>
<code>ex:a rdfs:subClassOf owl:Thing .</code><br/>
-are prohibited in the OWL-DL [[OWL2-SYNTAX]] semantic extension. 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 semantic extensions normatively defined in this document impose syntactic restrictions on RDF graphs.</p>
+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 syntactic restrictions on RDF graphs.</p>
-<p>All entailment regimes MUST be <a>monotonic</a> extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A also entails B under any extended notion of entailment, provided of course that any syntactic conditions of the extension are also satisfied. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
+<p>All entailment regimes MUST be <a>monotonic</a> extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A also entails B under any extended notion of entailment, provided of course 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>
<section>
<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 Concepts specification [[!RDF11-CONCEPTS]]: <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">RDF term</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">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">RDF term</a>, <a class="externalDFN">blank node</a>, <a class="externalDFN">literal</a>, <a class="externalDFN">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 expression (usually an IRI) 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 identifying a named graph in an <a class="external">RDF dataset</a> may refer to something different from the graph it identifies. </p>
+<p>We use the words <dfn>denotes</dfn> and <dfn>refers to</dfn> interchangeably as synonyms for the relationship between an expression (usually an IRI) 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. </p>
@@ -147,7 +147,7 @@
<p>A <dfn>name</dfn> is any IRI or literal. Note that a typed literal contains
two <a>name</a>s: itself and its internal type
- IRI. A <dfn>vocabulary</dfn> is a set of names.
+ IRI. A <dfn>vocabulary</dfn> is a set of <a>name</a>s.
</p>
<p>The <dfn>empty graph</dfn> is the empty set of triples. </p>
@@ -173,7 +173,7 @@
for blank nodes in the original are <a>name</a>s
from V.</p>
<p>A <dfn>proper instance</dfn> of a graph
- is an <a>instance</a> in which a blank node has been replaced by a name, or two blank
+ 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><a class="external">Isomorphic</a> graphs are mutual instances with an invertible instance
mapping. As blank nodes have no particular identity beyond their location in a graph, we will treat such isomorphic graphs as identical.</p>
@@ -222,7 +222,7 @@
<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="technote"> Interpretations are required to interpret all names, and are therefore infinite. This simplifies the exposition. However, RDF can be interpreted using finite structures, supporting decidable algorithms. Details are given in Appendix ///. </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>
<p>IEXT(x), called
@@ -275,16 +275,16 @@
<p> The final condition implies that the empty graph (the empty set of triples) is always true.</p>
<p>The sets IP and IR may overlap, indeed IP can be a subset of IR. Because of the domain conditions on IEXT, the denotation of the subject and object of any true triple will be in IR; so any IRI which occurs in a graph both as a predicate and as a subject or object will denote something in the intersection of IP and IR.</p>
-<p>Semantic extensions may impose further constraints upon interpretation mappings by requiring some IRIs to refer in particular ways. For example, D-interpretations, described below, require some IRIs, understood as identifying and referring to datatypes, to have a fixed interpretation. </p>
+<p><a>semantic extension</a>s may impose further constraints upon interpretation mappings by requiring some IRIs to refer in particular ways. For example, D-interpretations, described below, require some IRIs, understood as <a>identify</a>ing and referring to datatypes, to have a fixed interpretation. </p>
<section>
<h3 id="blank_nodes">Blank Nodes</h3>
-<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to identify any particular thing. This is not the same as assuming that the blank node indicates an 'unknown' IRI. Blank node identifiers play a similar role to existentially quantified variables in a conventional logical notation; they are local to the document in which they occur.
+<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to <a>identify</a> any particular thing. This is not the same as assuming that the blank node indicates an 'unknown' IRI. Blank node identifiers play a similar role to existentially quantified variables in a conventional logical notation; they are local to the document in which they occur.
</p>
-<p> Suppose I is an interpretation and A is a mapping from a set of blank nodes to the universe IR of I. Define the mapping [I+A] to be I on names, and A on blank nodes on the set: [I+A](x)=I(x) when x is a name and [I+A](x)=A(x) when x is a blank node; and extend this mapping to triples and RDF graphs using the rules given above for ground graphs. Then the semantic conditions for an RDF graph are:</p>
+<p> Suppose I is an interpretation and A is a mapping from a set of blank nodes to the universe IR of I. Define the mapping [I+A] to be I on <a>name</a>s, and A on blank nodes on the set: [I+A](x)=I(x) when x is a <a>name</a> and [I+A](x)=A(x) when x is a blank node; and extend this mapping to triples and RDF graphs using the rules given above for ground graphs. Then the semantic conditions for an RDF graph are:</p>
<div class="tabletitle">Semantic condition for blank nodes.</div>
<table border="1">
@@ -310,7 +310,7 @@
<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>All semantic extensions of any vocabulary or higher-level notation encoded in RDF MUST conform to these minimal truth conditions. Other semantic extensions may extend and add to these, but they MUST NOT modify or negate them. For example, because interpretations are mappings which apply to IRIs, a semantic extension MUST NOT interpret different occurrences of a single IRI differently.</p>
+<p>All <a>semantic extension</a>s of any vocabulary or higher-level notation encoded in RDF MUST conform to these minimal truth conditions. Other <a>semantic extension</a>s may extend and add to these, but they MUST NOT modify or negate them. For example, because interpretations are mappings which apply to IRIs, a <a>semantic extension</a> MUST NOT interpret different occurrences of a single IRI differently.</p>
</section>
</section>
@@ -320,35 +320,40 @@
<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, and that a set S of graphs simply entails E when the union of S simply entails E. 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 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. If this case does not arise, this definition is exactly equivalent to the previous definition.</p>
+<p class="changenote">This definition treats a set of graphs 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 exactly equivalent to the previous definition.</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
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; and 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 and errors into otherwise correct 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>
+<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 and errors into otherwise correct 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>
-<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 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>
+<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>
<h3>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. </p>
+<p>The properties described here apply only to simple entailment, not to extended notions of entailment introduced in later sections. Proofs are given in Appendix C. </p>
<p class="fact">Every graph is satisfiable.</p>
-<p>This does not hold for extended notions of interpretation. A graph containing an <a>ill-typed</a> literal is D-unsatisfiable.</p>
-<p>Simple entailment can be recognized 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>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 class="fact">
G simply entails a graph E if and only if a subgraph of G is an instance of E.
</p>
+
<p> completely characterizes simple entailment in syntactic
- terms. To tell whether a set of RDF graphs simply entails another, check that
+ terms. To detect whether a set of RDF graphs simply entails another, check that
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 complex 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. ([[Refer to Jeremy Carroll.]]) This 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 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>
<p class="fact"> The <a>empty graph</a> is entailed by
@@ -363,7 +368,7 @@
<!-- <a href="#instlemprf" class="termref"> [Proof]</a> -->
</p>
<p class="fact"> If
- E is a consistent <a>lean</a> graph and E' is a <a>proper instance</a> of E, then E does
+ E is a <a>lean</a> graph and E' is a <a>proper instance</a> of E, then E does
not simply entail E'.
</p>
@@ -376,6 +381,7 @@
</p>
<p>
This property is often called <em>compactness</em>. RDF is compact. As RDF graphs can be infinite, this is sometimes important.</p>
+
<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. The process of taking two subgraphs of an RDF graph, treating each subgraph as a separate graph, and then re-combining them by creating the union of these separated graphs, does not yield the original graph when the subgraphs share a common blank node. For example, the following graph contains three nodes:</p>
@@ -425,25 +431,26 @@
</section>
<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 semantic extension 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 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 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 identifying 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 L2V 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 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 recognized, but whose character string is assigned no value by the lexical-to-value mapping 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 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> 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 recognized datatype IRIs. </p>
-
-<p> RDF processors are not required to recognize 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 recognized, they MUST be interpreted as described there, and when the IRI <code>rdf:plainLiteral</code> is recognized, 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 recognized, the mapping between a recognized 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 <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>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. </p>
-<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it is not recognized as referring to a datatype. Literals with such an "unknown" datatype IRI, which is not in the set of recognized datatypes, MUST NOT be classified as errors, although RDF applications MAY issue a warning. They SHOULD be treated like IRI names and assumed to denote some thing in the universe IR. RDF processors which fail to recognize 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 recognize the datatype URI <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, MUST NOT be treated as errors, although RDF applications MAY issue a warning. They 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 URI <code>xsd:decimal</code>.</p>
</section>
<section id="D_interpretations"><h2>D-interpretations</h2>
-<p>Let D be a set of IRIs identifying datatypes. A <dfn>(simple) D-interpretation</dfn> is a simple interpretation which satisfies the following conditions:</p>
+<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>
<div class="tabletitle">Semantic conditions for datatyped literals.</div>
<table border="1">
@@ -454,9 +461,11 @@
-<p>If the literal is ill-typed 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 ill-typed literal will be D-unsatisfiable, i.e. false in every D-interpretation. This applies only to datatype IRIs in D; literals with "unknown" datatypes are not ill-typed and do not produce a D-inconsistency. </p>
-<p>The built-in RDF datatypes <code>rdf:langString</code> and <code>xsd:string</code> have no ill-typed literals. Any literal with these types which is syntactically legal in RDF will denote a value in every RDF interpretation. </p>
-<p class="issue">Is this true? Is "\u0000"^^xsd:string ill-formed or syntactically illegal? What about "foodle"@700 ?</p>
+<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 datatype IRIs in D; literals with "unknown" datatypes are not <a>ill-typed</a> and cannot be <a>D-unsatisfiable</a>. </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 required datatype <code>xsd:string</code> can have an ill-formed string, for example one containing the Unicode null character \u0000. However, such ill-formed strings cannot be written in most surface syntactic notations for RDF. </p>
+
+<p class="issue">Blech. This is very weak. Can't we do better than just saying this?</p>
@@ -472,15 +481,19 @@
<p>A graph is (simply) <dfn>D-satisfiable</dfn> when it has the value true in some D-interpretation, and a set S of graphs (simply) <dfn>D-entails</dfn> a graph G when every D-interpretation which makes S true also D-satisfies G.</p>
-<p> Unlike the case with simple interpretations, it is possible for a graph to have no satisfying D-interpretations, i.e. to be <dfn>D-unsatisfiable</dfn>. A D-unsatisfiable graph D-entails any graph. </p>
+<p> Unlike the case with <a>simple interpretation</a>s, it is possible for a graph to have no satisfying D-interpretations, i.e. to be <dfn>D-unsatisfiable</dfn>. RDF processors MAY treat an unsatisfiable graph as signaling an error condition, but this is not required.</p>
-<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 ⊂ 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, so if S D-entails G then S simply entails G. </p>
+<p> A <a>D-unsatisfiable</a> graph D-entails any graph.</p>
+
+<p class="technote">The fact that an unsatisfiable statement entails any other statement has been known since antiquity. It is called the principle of <em>ex falso quodlibet</em>. It should not be interpreted to mean that it is necessary, or even permissible, to actually draw any conclusion from an inconsistency.</p>
+
+<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 <a>recognize</a>d, the stronger is the entailment, so that if D ⊂ 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, so if S D-entails G then S simply entails G. </p>
<section> <h4>Patterns of datatype entailment</h4>
-<p>Unlike simple entailment, it is not possible to give a single syntactic criterion to recognize all D-entailments, which
-can hold because of particular properties of the lexical-to-value mappings of the recognized datatypes. For example, if D contains <code>xsd:decimal</code> then </p>
+<p>Unlike <a title="simply entails">simple entailment</a>, it is not possible to give a single syntactic criterion to detect all D-entailments, which
+can hold because of particular properties of the lexical-to-value mappings of the <a>recognize</a>d datatypes. For example, if D contains <code>xsd:decimal</code> then </p>
<p><code>ex:a ex:p "25.0"^^xsd:decimal .</code></p>
@@ -489,13 +502,13 @@
<p><code>ex:a ex:p"25"^^xsd:decimal .</code>
</p>
-<p>In general, any triple containing a literal with a recognized datatype IRI D-entails a similar 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 a similar 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>In general, any triple containing a literal with a <a>recognize</a>d datatype IRI D-entails a similar 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 a similar 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>Ill-typed literals are the only form of simple D-contradiction, but datatypes can give rise to a variety of other contradictions when combined with the RDFS vocabulary, defined later.</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>
</section>
@@ -538,26 +551,26 @@
</tr>
</table>
-<p>No other semantic constraints are imposed upon <a>rdf-D-interpretation</a>s, so RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are discussed in <a>Appendix C</a></p>
+<p>No other semantic constraints are imposed upon <a>rdf-D-interpretation</a>s, so RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are described in Appendix D.</p>
-<p id="rdfinterpdef">An <em>rdf-interpretation</em>, or <em>RDF interpretation</em>, is an rdf-{<code>rdf:langString</code>, <code>xsd:string</code> }-interpretation, i.e. an rdf-D-Interpretation with a minimal set D. The datatype IRIs <code>rdf:langString</code> and <code>xsd:string</code> MUST be recognized by all RDF-D interpretations. </p>
+<p id="rdfinterpdef">An <dfn>rdf-interpretation</dfn>, or <dfn>RDF interpretation</dfn>, is an rdf-{<code>rdf:langString</code>, <code>xsd:string</code> } interpretation, i.e. an rdf-D-Interpretation with a minimal set D. The datatype IRIs <code>rdf:langString</code> and <code>xsd:string</code> MUST be <a>recognize</a>d by all RDF-D interpretations. </p>
-<p>Two datatypes in the rdf: namespace <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in [[!RDF11-CONCEPTS]]. RDF-D interpretations MAY fail to recognize these datatypes. </p>
+<p>Two datatypes in the rdf: namespace <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>
</section>
<section>
-<h3><a id="rdf_entail"></a>RDF entailment</h3>
+<h3><a id="rdf_entail"></a>RDF-D entailment</h3>
-<p>S <i>rdf-D-entails</i> E when every rdf-D-interpretation which satisfies every
- member of S also satisfies E. </p>
+<p>S <dfn>rdf-D-entail</dfn><strong>s</strong> E when every <a>rdf-D-interpretation</a> which satisfies every
+ member of S also satisfies E, and <dfn>rdf-entail</dfn><strong>s</strong> E when every <a>rdf-interpretation</a> of S also satisfies E. </p>
-<p>The properties of <a>simple entailment</a> described earlier do not all apply to rdf-D-entailment. For example, all the rdf axioms are true in every <a">rdf-interpretation</a>, so are rdf-D-entailed by the empty graph,
- contradicting <a>interpolation</a> for rdf-D-entailment. </p>
+<p>The properties of <a>simple entailment</a> described earlier do not all apply to <a>rdf-D-entail</a>ment. For example, all the RDF axioms are true in every <a>rdf-interpretation</a>, so are <a>rdf-D-entail</a>ed by the empty graph,
+ contradicting <a>interpolation</a> for rdf-D entailment. </p>
<section><h4>Patterns of RDF-D entailment</h4>
-<p> The last semantic condition in the above table gives the following entailment pattern for recognized datatype IRIs: </p>
+<p> The last semantic condition in the above table gives the following entailment pattern for <a>recognize</a>d datatype IRIs: </p>
<div class="tabletitle">RDF-D entailment pattern.</div>
<table border="1" >
@@ -565,7 +578,7 @@
<tr>
<th > </th>
<th ><strong>if S contains</strong></th>
- <th ><strong>then S RDF-D-entails</strong></th>
+ <th ><strong>then S rdf-D-entails</strong></th>
</tr>
<tr >
<td class="othertable">rdfD1</td>
@@ -577,7 +590,7 @@
</tbody>
</table>
-<p>Note, this is valid even when the literal is ill-typed, since an inconsistent graph entails any triple.</p>
+<p>Note, this is valid even when the literal is <a>ill-typed</a>, since an unsatisfiable graph entails any triple.</p>
<p>For example,</p>
<p> <code>ex:a ex:p "123"^^xsd:integer .</code></p>
@@ -594,7 +607,7 @@
<tr>
<th > </th>
<th ><strong>if S contains</strong></th>
- <th ><strong>then S RDF-D-entails</strong></th>
+ <th ><strong>then S rdf-D-entails</strong></th>
</tr>
<tr>
@@ -621,6 +634,11 @@
<p><code>ex:a ex:p ex:v .</code></p>
+<p>In addition, the semantic conditions on value spaces may produce other unsatisfiable graphs. For example, when D contains <code>xsd:integer</code> and <code>xsd:boolean</code>, then the following is <a>rdf-D-unsatisfiable</a>:</p>
+
+<p><code>_:x rdf:type xsd:boolean .<br/>
+_:x rdf:type xsd:integer . </code></p>
+
</section>
</section>
@@ -651,11 +669,11 @@
apply to their use can be stated using <code>rdfs:domain</code>,<code> rdfs:range</code>
and <code>rdfs:subPropertyOf</code>. Other than this, the formal semantics does
not constrain their meanings.)</p>
-<p>Although not strictly necessary, it is convenient to state the RDFS semantics
+<p>It is convenient to state the RDFS semantics
in terms of a new semantic construct, a <dfn>class</dfn>, i.e. a resource which represents
a set of things in the universe which all have that class as a value of their
- <code>rdf:type</code> property. Classes are defined to be things of type <code>rdfs:Class</code>,
- and <span >the set of all classes in an interpretation will be called IC</span>.
+ <code>rdf:type</code> property. <a>Class</a>es are defined to be things of type <code>rdfs:Class</code>,
+ and the set of all classes in an interpretation will be called IC.
The semantic conditions are stated in terms of a mapping ICEXT (for the <em>C</em>lass
<em>Ext</em>ension in I) from IC to the set of subsets of IR.</p><p> A class may have an
empty class extension. Two different classes can have the same class extension.
@@ -663,8 +681,8 @@
</p>
-<p><a id="rdfsinterpdef"></a> An <i>rdfs-D-interpretation</i> is an <a href="#rdfinterpdef" class="termref">rdf-D-interpretation</a> I
- which satisfies the semantic conditions in the following table, and satisfies all the triples in the subsequent table of <em>RDFS axiomatic triples</em>. As before, an <em>rdfs-interpretation</em>, or <em>RDFS interpretation</em>, is an rdfs-D-interpretation with D= {<code>xsd:string</code>, <code>rdf:langString</code> }.</p>
+<p> An <dfn>rdfs-D-interpretation</dfn> is an <a>rdf-D-interpretation</a> I
+ which satisfies the semantic conditions in the following table, and all the triples in the subsequent table of RDFS axiomatic triples. As before, an <dfn>rdfs-interpretation</dfn>, or <dfn>RDFS interpretation</dfn>, is an <a>rdfs-D-interpretation</a> with D= {<code>xsd:string</code>, <code>rdf:langString</code> }.</p>
<div class="tabletitle">RDFS semantic conditions.</div>
<table border="1">
@@ -803,10 +821,10 @@
<p class="changenote">In the 2004 RDF 1.0 semantics, LV was defined as part of a simple interpretation structure, and the definition given here was a constraint. </p>
-<p>Since I is an rdf-interpretation, the first condition implies that IP
+<p>Since I is an <a>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 a class whose extension is the value space of the datatype, and every literal with that datatype either fails to refer, or refers to a value in that class.</p>
-<p>When using RDFS semantics, the class <code>rdfs:Datatype</code> can be considered to contain exactly the referents of recognized datatype IRIs. </p>
+ <p>The semantic conditions on <a>rdf-D-interpretation</a>s, together with the RDFS conditions on ICEXT, mean that every <a>recognize</a>d datatype can be treated as a class whose extension is the value space of the datatype, and every literal with that datatype either fails to refer, or refers to a value in that class.</p>
+<p>When using RDFS semantics, the class <code>rdfs:Datatype</code> can be considered to contain exactly the referents of <a>recognize</a>d datatype IRIs. </p>
<p>The axioms and conditions listed above 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>.
@@ -860,10 +878,10 @@
<section>
<h3 id="rdfs_entailment">RDFS Entailment</h3>
-<p>S <i>rdfs-D-entails</i> E when every rdfs-D-interpretation
- which satisfies every member of S also satisfies E. RDFS entailment is rdfs-{<code>rdf:langString</code>, <code>xsd:string</code> }-entailment, i.e. rdfs-D-entailment with a minimal D. </p>
-<p> Since every rdfs-D-interpretation is an rdf-D-interpretation, if S rdfs-D-entails
- E then S also rdf-D-entails E; but rdfs-entailment is stronger than rdf-entailment.
+<p>S <dfn>rdfs-D-entails</dfn> E when every <a>rdfs-D-interpretation</a>
+ which satisfies every member of S also satisfies E. <dfn>RDFS entailment</dfn> is rdfs-{<code>rdf:langString</code>, <code>xsd:string</code> } entailment, i.e. <a title="rdfs-D-entails">rdfs-D-entailment</a> with a minimal D. </p>
+<p> Since every <a>rdfs-D-interpretation</a> is an <a>rdf-D-interpretation</a>, if S <a>rdfs-D-entails</a>
+ E then S also <a>rdf-D-entail</a>s E; but rdfs-entailment is stronger than rdf-entailment.
Even the empty graph has a large number of rdfs-entailments which are not rdf-entailments,
for example all triples of the form </p>
<p> aaa <code>rdf:type rdfs:Resource .</code></p>
@@ -961,11 +979,25 @@
</table>
+<p>RDFS provides for several new ways to be RDFS-D unsatisfiable. For example, the following graph is RDFS-{<code>xsd:integer</code>, <code>xsd:boolean</code>} unsatisfiable:</p>
+<p><code>ex:p rdfs:domain xsd:boolean .<br/>
+ex:a rdf:type xsd:integer .<br/>
+ex:a ex:p ex:c .</code></p>
</section>
</section>
+<section><h2>RDF Datastores</h2>
+<p>An RDF <a class="externalDFN">datastore</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. 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 datastore to <a>identify</a> graphs of information relevant to the entity <a>denote</a>d by the graph name IRI.</p>
+
+<p>This has the consequence that when a graph name IRI is used inside RDF triples in a datastore 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>Graphs in a single datastore may share blank nodes. This is the only case where distinct RDF graphs may share a blank node. Graphs in distinct datastores cannot share blank nodes. </p>
+
+</section>
<section class="appendix"><h3>Entailment rules (Informative)</h3>
@@ -1047,14 +1079,14 @@
<p>Where the entailment patterns have been applied to generalized RDF syntax but yield a final conclusion which is legal RDF. </p>
<p>With the generalized syntax, these rules are complete for both RDF and RDFS entailment. Stated exactly:</p>
-<p>Let S and E be RDF graphs. Define the <dfn>generalized RDF (RDFS) closure</dfn> of S to be the set obtained by the following procedure.</p>
+<p>Let S and E be RDF graphs. Define the <dfn>generalized RDF (RDFS) closure</dfn> <strong>of S towards E</strong> to be the set obtained by the following procedure.</p>
<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>
<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 generalized RDF (RDFS) closure of S simply entails E.</em> </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>Since the closures are finite, the generation process is decideable, and of polynomial complexity. Detecting simple entailment is NP-complete in general, but of low polynomial order when E contains no blank nodes. </p>
@@ -1067,15 +1099,15 @@
</section>
<section class="appendix"><h2 id="proofs">Finite interpretations (Informative)</h2>
-<p>To keep the exposition simple, the RDF semantics has been phrased in a way which requires interpretations structures 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 RDF entailemnts. </p>
-<p>Basically, it is only necessary for an interpretation structure to interpret the names actually used in the graphs whose entailment is being considered, and to have a universe which contains referents for all the names, plus a random member of each nonempty class or type, in order to provide for the truth of existential assertions made using blank nodes. 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, and when considering whether G entails E, consider only pre-interpretations over the finite vocabulary of names actually used in G union E. Clearly, any such pre-interpretation may be extended to simple interpretations all of which which will give the same truthvalues for any triples in G or E. Satisfiability, entailment and so on can then be defined with respect to these finite structures, and shown to be identical to the ideas defined in the earlier sections.</p>
-<p>When considering D-entailment, pre-interpretations may be kept finite by weakening the semantic conditions for datatyped literals so that IR need contain literal values only for literals which actually occur in G or E, or a single value in the value space if there are no such literals in the vocabulary. (This preserves the truth of the triple <code> _:x rdf:type </code>ddd <code>.</code> when ddd is recognized.) For RDF-D entailment, only the finite part of the RDF vocabulary which include those container membership properties which actually occur in the graphs need to be interpreted, and the second RDF semantic condition is weakened to apply only to values which are values of literals which actually occur in the vocabulary. For RDFS interpretations, again only that finite part of the infinite container membership property vocabulary which actually occurs in the graphs under consideration needs to be interpreted. In all these cases, a pre-interpretation of the vocabulary of a set of graphs may be extended to a full interpretation of the appropriate type without changing the truthvalues of any triples in the graphs.</p>
+<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 have a universe which contains referents for all the <a>name</a>s, plus a random member of each nonempty class or type, in order to provide for the truth of existential assertions made using blank nodes. 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, and when considering whether G entails E, consider only pre-interpretations over the finite vocabulary of <a>name</a>s actually used in G union E. Clearly, any such pre-interpretation may be extended to <a>simple interpretation</a>s all of which which will give the same truthvalues 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>
+<p>When considering D-entailment, pre-interpretations may be kept finite by weakening the semantic conditions for datatyped literals so that IR need contain literal values only for literals which actually occur in G or E, or a single value in the value space if there are no such literals in the vocabulary. For RDF-D entailment, only the finite part of the RDF vocabulary which include those container membership properties which actually occur in the graphs need to be interpreted, and the second RDF semantic condition is weakened to apply only to values which are values of literals which actually occur in the vocabulary. For RDFS interpretations, again only that finite part of the infinite container membership property vocabulary which actually occurs in the graphs under consideration needs to be interpreted. In all these cases, a pre-interpretation of the vocabulary of a set of graphs may be extended to a full interpretation of the appropriate type without changing the truthvalues of any triples in the graphs.</p>
<p>The whole semantics could be stated in terms of pre-interpretations, yielding the same entailments, and allowing finite RDF graphs to be interpreted in finite structures, if this <em>finite model property</em> is considered important.
</section>
-<section class="appendix"><h2>Proofs of some results (Informative)</h2>
+<section class="appendix" class="informative"><h2>Proofs of some results (Informative)</h2>
<p class="fact"> The <a>empty graph</a> is entailed by
any graph, and does not entail any graph except itself.
@@ -1096,7 +1128,7 @@
<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 names and blank nodes which occur in the graph, with I(n)=n for each name 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>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 class="fact">
G simply entails a graph E if and only if a subgraph of G is an instance of E.
@@ -1107,7 +1139,6 @@
<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>
<p class="fact">If E contains an IRI which does not occur in S, then S does not entail E.</p>
<p>IF S entails E then a subgraph of S is an instance of E, so every IRI in E must occur in that subgraph, so must occur in S. QED.</p>
-<br/>
<p class="fact">For any graph H, if sk(G) entails H there there is a graph H' such that G entails H' and H=sk(H').</p>
<p>The skolemization mapping sk substitutes a unique new IRI for each blank node, so it is 1:1, so has an inverse. Define ks to be the inverse mapping which replaces each skolem IRI by a unique blank node, different from all other blank nodes. Since sk(G) entails H, a subgraph of sk(G) is an instance of H, say A(H) for some instance mapping A on the blank nodes in H. Then ks(A(H)) is a subgraph of G; and ks(A(H))=A(ks(H)) since the domains of A and ks are disjoint. So ks(H) has an instance which is a subgraph of G, so is entailed by G; and H=sk(ks(H)). QED.</p>
@@ -1120,9 +1151,7 @@
</section>
-<section class="appendix" id="whatnot"><h2 id="non_semantics">What the semantics does not do (Informative)</h2>
-
-<p class="issue">Something in here about datasets having no specified semantics, and why. Why using a graph name need not refer to the graph.</p>
+<section class="appendix" id="whatnot"><h2 id="non_semantics">RDF reification, containers and collections. (Informative)</h2>
<p>The RDF semantic conditions do not place formal constraints on the meaning
of much of the RDF vocabulary which is intended for use in describing containers and bounded collections,
@@ -1176,7 +1205,7 @@
</p>
-<p>Reifications can be written with a blank node as subject, or with an IRI subject which does not identify any concrete realization of a triple, in which case they assert the existence of the described triple. </p>
+<p>Reifications 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 which case they assert the existence of the described triple. </p>
<p>The subject of a reification 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
@@ -1292,7 +1321,7 @@
any of the elements of the container, or vice versa. </p>
<p>There is no formal requirement that
the three container classes are disjoint, so that for example
- it is not <a>inconsistent</a> to assert that something is both an <code>rdf:Bag</code> and an <code>rdf:Seq</code>.
+ it is consistent to assert that something is both an <code>rdf:Bag</code> and an <code>rdf:Seq</code>.
There is no assumption that containers are gap-free, so that for example</p>
<p><code>_:xxx rdf:type rdf:Seq.<br/>
_:xxx rdf:_1 ex:a .<br/>
@@ -1380,7 +1409,7 @@
by failing to specify its <code>rdf:rest</code> property value.</p>
-<p>Semantic extensions may
+<p><a>semantic extension</a>s may
place extra syntactic well-formedness restrictions on the use of this vocabulary
in order to rule out such graphs. They may
exclude interpretations of the collection vocabulary which violate the convention
@@ -1397,8 +1426,8 @@
<section>
<h3><a id="rdfValue"></a>rdf:value</h3>
-<p>The intended use for <code>rdf:value</code> is <a href="http://www.w3.org/TR/rdf-primer/#rdfvalue">explained
- intuitively</a> in the RDF Primer
+<p>The intended use for <code>rdf:value</code> is explained
+ intuitively in the RDF Primer
document [[RDF-PRIMER]]. It is typically
used to identify a 'primary' or 'main' value of a property which has several
values, or has as its value a complex entity with several facets or properties
@@ -1415,14 +1444,19 @@
<section class='appendix'>
- <h2 id="acknolwedgements">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.</p>
-<p>// Herman ter Horst for rule style, Li Ding for complete graphs, Antoine for no-vocabulary and general input. Others?///</p>
- <p>
- Many thanks to Robin Berjon for making our lives so much easier with his cool tool. You betcha.
- </p>
+ <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>
+
+<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.
+
+</p>
+
+
+ <p>This document was prepared using the ReSpec.js writing tool developed by Robin Berjon. </p>
+
</section>
</body>
</html>