--- a/rdf-mt/index.html Tue May 21 10:37:51 2013 -0700
+++ b/rdf-mt/index.html Sun May 26 16:38:45 2013 -0500
@@ -13,8 +13,8 @@
specStatus: "ED",
localBiblio:{
-"EXTRDFS":"Herman J. ter Horst, Extending the RDFS Entailment Lemma, in S.A. McIlraith et al. (Eds.), The Semantic Web - ISWC2004, Proceedings of the Third International Semantic Web Conference, Hiroshima, Japan, November 2004, Springer, LNCS 3298, pp. 77-91.",
-"CDCENTAILMENT":"Herman J. ter Horst, Completeness, Decidability and Complexity of Entailment for RDF Schema and a Semantic Extension Involving the OWL Vocabulary, Journal of Web Semantics 3 (2005) 79-115." },
+"HORST04":"Herman J. ter Horst. <cite>Extending the RDFS Entailment Lemma</cite>, in S.A. McIlraith et al. (Eds.), The Semantic Web - ISWC2004, Proceedings of the Third International Semantic Web Conference, Hiroshima, Japan, November 2004, Springer, LNCS 3298, pp. 77-91.",
+"HORST05":"Herman J. ter Horst. <cite>Completeness, Decidability and Complexity of Entailment for RDF Schema and a Semantic Extension Involving the OWL Vocabulary</cite>, Journal of Web Semantics 3 (2005) 79-115." },
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "rdf11-mt",
@@ -87,14 +87,54 @@
.ruletable {background-color: #DDDDFF; padding:0.5em;}
.othertable {background-color: #FDFDFD; padding:0.5em;}
.tabletitle {font-size: small; font-weight: bolder;}
-.technote {font-size:small; background: #ccccff; padding: 0.5em; margin: 2em 1em;}
-.changenote {padding: 0.5em; margin: 2em 1em;font-size: small; background: #ffccff;}
+
+.technote {
+ font-size:small;
+ margin: 2em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.technote::before {
+ content: "Technical Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #eff;
+ padding: 3px 1em;
+}
+
+
+.changenote {
+ font-size:small;
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #ffddfe;
+}
+
+.changenote::before {
+ content: "Change Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #ffddef;
+ padding: 3px 1em;
+}
+
+
.fact {
padding: 0.5em;
margin: 1em 0;
position: relative;
clear: both;
- background-color: #ffccaa;
+ background-color: #ffeecc;
+ border: 1px solid black
}
</style>
</head>
@@ -110,46 +150,43 @@
</section>
<section class='introductory'><h2 id="notes">Notes</h2>
-<p class='changenote'>Notes in this style indicate changes from the 2004 RDF semantics.</p>
+<p class='changenote'>Notes in this style indicate changes from the 2004 RDF 1.0 semantics.</p>
<p class='technote'>Notes in this style are technical asides on obscure or recondite matters.</p></section>
<section>
<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>
+
</section>
+<section id="conformance"><p>This specification, <em>RDF 1.1 Semantics</em>, is normative for RDF semantics and the validity of RDF inference processes. It is not normative for 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. </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>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 be given meanings. 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 entailments follow from those assumptions. </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>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/>
<code>ex:a rdfs:subClassOf owl:Thing .</code><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 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 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 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>
+<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>
<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 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 <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>
+ <p>This document uses the following terminology for describing RDF graph syntax, all as defined in the companion RDF Concepts specification [[!RDF11-CONCEPTS]]: <em>IRI</em>, <em><a class="externalDFN">RDF triple</a>, <a class="externalDFN">RDF graph</a>, <a class="externalDFN">subject</a>, <a class="externalDFN">predicate</a>, <a class="externalDFN">object</a>, <a class="externalDFN">RDF source</a>, <a class="externalDFN">node</a>, <a class="externalDFN">RDF term</a>, <a class="externalDFN">blank node</a>, <a class="externalDFN">literal</a>, <a class="externalDFN">isomorphic</a>.</em></p>
-<p>Angle brackets < x, y > are used to indicate an ordered pair
- of x and y. RDF graph syntax is indicated using the notational conventions of
- the Turtle syntax described
- in the Turtle Working Draft [[TURTLE-TR]]. Prefix definitions are omitted. When stating general rules or conditions we use three-character variables such as aaa, xxx, sss to indicate arbitrary IRIs, literals, or other components of RDF syntax. </p>
+<p>We use the words <dfn>denotes</dfn> and <dfn>refers to</dfn> interchangeably as synonyms for the relationship between an IRI or literal and what it refers to in a given interpretation, itself called the <dfn>referent</dfn> or <dfn>denotation</dfn>. IRI meanings may also be determined by other constraints external to the RDF semantics; when we wish to refer to such an externally defined naming relationship, we will use the word <dfn>identify</dfn> and its cognates. For example, the fact that the IRI <code>http://www.w3.org/2001/XMLSchema#decimal</code> is widely used as the name of a datatype described in the XML Schema document [[XMLSCHEMA11-2]] might be described by saying that the IRI <em>identifies</em> that datatype. If an IRI identifies something it may or may not refer to it in a given interpretation, depending on how the semantics is specified. For example, an IRI used as a graph name <a>identify</a>ing a named graph in an <a class="external">RDF dataset</a> may refer to something different from the graph it identifies. </p>
-<p class="issue">Should the following definitions be in Concepts rather than here?</p>
+<p>Throughout this document, the equality sign = indicates strict identity. The statement "A = B" means that there is one entity to which both expressions "A" and "B" refer. Angle brackets < x, y > are used to indicate an ordered pair
+ of x and y.</p>
-<p>A <dfn>name</dfn> is any IRI or literal. Note that a typed literal contains
+<p>Throughout this document, RDF graphs and other fragments of RDF abstract syntax are written using the notational conventions of the Turtle syntax [[!TURTLE-TR]]. The namespace prefixes <code>rdf:</code> <code>rdfs:</code> and <code>xsd:</code> are used as in [[!RDF11-CONCEPTS]], section 1.4. When the exact IRI does not matter. the prefix <code>ex:</code> is used. When stating general rules or conditions we use three-character variables such as aaa, xxx, sss to indicate arbitrary IRIs, literals, or other components of RDF syntax. </p>
+
+<p>A <dfn>name</dfn> is any IRI or literal. A typed literal contains
two <a>name</a>s: itself and its internal type
IRI. A <dfn>vocabulary</dfn> is a set of <a>name</a>s.
</p>
@@ -179,8 +216,8 @@
<p>A <dfn>proper instance</dfn> of a graph
is an <a>instance</a> in which a blank node has been replaced by a <a>name</a>, or two blank
nodes in the graph have been mapped into the same node in the instance. </p>
-<p><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>
+<p>Two graphs are <a class="external">isomorphic</a> when each maps into the other by a 1:1 mapping on blank nodes. Isomorphic graphs are mutual instances with an invertible instance
+ mapping. As blank nodes have no particular identity beyond their location in a graph, we will often treat such isomorphic graphs as identical.</p>
<p>
Graphs share blank nodes only if they are derived from graphs
@@ -189,7 +226,7 @@
of blank nodes between different RDF graphs. Simply downloading a
web document does not mean that the blank nodes in a resulting RDF
graph are the same as the blank nodes coming from other downloads of
-the same document or from the same source. RDF applications which manipulate concrete syntaxes for RDF which use blank node identifiers must 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 re-named in order to avoid accidental conflation of distinct blank nodes.</p>
+the same document or from the same source. RDF applications which manipulate concrete syntaxes for RDF which use blank node identifiers should take care to keep track of the identity of the blank nodes they identify. Blank node identifiers often have a local scope, so when RDF from different sources is combined, identifiers may have to be changed in order to avoid accidental conflation of distinct blank nodes.</p>
<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>
@@ -207,7 +244,10 @@
<section>
<h2 id="simple"> Simple Interpretations</h2>
-
+
+<p>This section defines the basic notions of interpretation and truth for RDF graphs. 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> cannot interpret different occurrences of a single IRI differently.</p>
+
+
<p>A <dfn>simple interpretation</dfn> I is a structure consisting of:</p>
<div class="tabletitle">Definition of a simple interpretation.</div>
@@ -308,14 +348,11 @@
a denotation by an interpretation, reflecting the intuition that
they have no 'global' meaning. </p>
</section>
-<section>
+<section class="informative">
<h3 id="intuitions">Intuitive summary</h3>
<p>An RDF graph is true exactly when:</p>
<p>1. the IRIs and literals in subject or object position in the graph all refer to things,</p><p>2. there is some way to interpret all the blank nodes in the graph as referring to things,</p><p>3. the IRIs in property position identify binary relationships,</p><p>4. and under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship referred to by P. </p>
-
-<p>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>
@@ -332,7 +369,7 @@
<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 <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>
+<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 !-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>
@@ -388,12 +425,12 @@
<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>
+<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 are treated as two separate graphs</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>
@@ -401,7 +438,7 @@
<p><code>ex:b ex:q _:x . </code></p>
-<p>then the two occurrences of the blank node identifier must be understood to identify distinct blank nodes, which remain distinct when the union of these graphs is created. The resulting union</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>
@@ -409,7 +446,7 @@
<p>contains four nodes rather than three, and is entailed by the original graph but does not entail it. </p>
-<p>This 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, as here, by replacing blank node identifiers in the surface syntax to avoid accidentally identifying distinct blank nodes identified by the same blank node identifier in different identifier scopes. </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>
@@ -419,7 +456,7 @@
</section>
<section><h2 id="skolemization">Skolemization</h2>
-<p><a class="externaldefinition">Skolemization</a> is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See [[RDF11-CONCEPTS]] for a fuller discussion. </p>
+<p><a class="externaldefinition">Skolemization</a> is a transformation on RDF graphs which eliminates blank nodes by replacing them with "new" IRIs, which means IRIs which are coined for this purpose and are therefore guaranteed to not occur in any other RDF graph (at the time of creation). See [[!RDF11-CONCEPTS]] for a fuller discussion. </p>
<p> Suppose G is a graph containing blank nodes and sk is a skolemization mapping on the blank nodes in G, so that sk(G) is a skolemization of G. Then the semantic relationship between them can be summarized as follows. </p>
<p class="fact"> sk(G) simply entails G (since sk(G) is an instance of G.)</p>
@@ -430,8 +467,6 @@
<p>The second property means that a graph is not logically <a>equivalent</a> to its skolemization. Nevertheless, they are in a strong sense almost interchangeable, as shown the next two properties. The third property means that even when conclusions are drawn from the skolemized graph which do contain the new vocabulary, these will exactly mirror what could have been derived from the original graph with the original blank nodes in place. The replacement of blank nodes by IRIs does not effectively alter what can be validly derived from the graph, other than by giving new names to what were formerly anonymous entities. The fourth property, which is a consequence of the third, clearly shows that in some sense a skolemization of G can "stand in for" G as far as entailments are concerned. Using sk(G) instead of G will not affect any entailments which do not involve the new skolem vocabulary. </p>
-<p>Skolemization means that it is possible to use RDF without blank nodes without losing any real expressivity. Opinions differ on the merits of this strategy.</p>
-
</section>
<section><h2 id="datatypes">Literals and datatypes</h2>
@@ -446,9 +481,9 @@
<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>Literals with <code>rdf:langString</code> as their datatype are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. </p>
-<p>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>
+<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it is not <a>recognize</a>d as referring to a datatype. Literals with such an "unknown" datatype IRI, which is not in the set of <a>recognize</a>d datatypes, MUST NOT be treated as errors, although RDF applications MAY issue a warning. Such literals SHOULD be treated like IRIs and assumed to denote some thing in the universe IR. RDF processors which fail to <a>recognize</a> a datatype IRI will not be able to detect some entailments which are visible to one which does. For example, the fact that </p><p><code>ex:a ex:p "20.0000"^^xsd:decimal .</code></p><p>entails </p><p><code>ex:a ex:p "20.0"^^xsd:decimal .</code></p><p>will not be visible to a processor which does not <a>recognize</a> the datatype URI <code>xsd:decimal</code>.</p>
</section>
@@ -467,7 +502,7 @@
<p>If the literal is <a>ill-typed</a> then the L2V(I(aaa)) mapping has no value, and so the literal cannot denote anything. In this case, any triple containing the literal must be false. Thus, any triple, and hence any graph, containing an <a>ill-typed</a> literal will be <a>D-unsatisfiable</a>, i.e. false in every D-interpretation. This applies only to literals typed with recognized datatype IRIs in D; literals with an unrecognized type IRI are not <a>ill-typed</a> and cannot give rise to a <a>D-unsatisfiable</a> graph. </p>
-<p>The built-in RDF datatype <code>rdf:langString</code> has no <a>ill-typed</a> literals. Any syntactically legal literal with this type will denote a value in every RDF interpretation. The only ill-typed literals of type <code>xsd:string</code> are those containing a Unicode code point which does not match the <em>Char</em> production in [[!XML10]]. Such strings cannot be written in an XML-compatible surface syntax.
+<p>The built-in RDF datatype <code>rdf:langString</code> has no <a>ill-typed</a> literals. Any syntactically legal literal with this type will denote a value in every RDF interpretation. The only ill-typed literals of type <code>xsd:string</code> are those containing a Unicode code point which does not match the <em>Char</em> production in [[XML10]]. Such strings cannot be written in an XML-compatible surface syntax.
</p>
@@ -491,7 +526,7 @@
<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>
+<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>
@@ -506,7 +541,7 @@
<p><code>ex:a ex:p"25"^^xsd:decimal .</code>
</p>
-<p>In general, any triple containing a literal with a <a>recognize</a>d datatype IRI D-entails 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 another literal when the lexical strings of the literals map to the same value under the lexical-to-value map of the datatype. If two different datatypes in D map lexical strings to a common value, then a triple containing a literal typed with one datatype may D-entail another triple containing a literal typed with a different datatype. For example, <code>"25"^^xsd:integer</code> and <code>"25.0"^^xsd:decimal</code> have the same value, so the above also D-entails</p>
<p><code>ex:a ex:p "25"^^xsd:integer .</code></p>
@@ -518,7 +553,7 @@
</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 in the <code>rdf:</code> namespace.
+ set of IRIs with the namespace prefix <code>rdf:</code> .
<p>An <dfn>RDF interpretation</dfn> <strong>recognizing D</strong> is a <a>D-interpretation</a> I where D includes <code>rdf:langString</code> and <code>xsd:string</code>, and which satisfies:</p>
<div class="tabletitle">RDF semantic conditions.</div>
@@ -555,12 +590,12 @@
</tr>
</table>
-<p>RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are described in Appendix D.</p>
+<p>RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Appendix D describes the intended uses of some of this vocabulary.</p>
<p>The datatype IRIs <code>rdf:langString</code> and <code>xsd:string</code> MUST be <a>recognize</a>d by all RDF interpretations. </p>
-<p>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>
+<p>Two other datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in [[!RDF11-CONCEPTS]]. RDF-D interpretations MAY fail to <a>recognize</a> these datatypes. </p>
</section>
<section>
@@ -568,7 +603,7 @@
<p>S <dfn>RDF entail</dfn><strong>s</strong> E <strong>recognizing D</strong> when every <a>RDF interpretation recognizing D</a> which satisfies S also satisfies E. When D is {<code>rdf:langString</code>, <code>xsd:string</code>} then we simply say S <strong>RDF entails</strong> E. </p>
-<p>The properties of <a>simple entailment</a> described earlier do not all apply to <a>RDF entail</a>ment. For example, all the RDF axioms are true in every <a>RDF interpretation</a>, so are <a>RDF entail</a>ed by the empty graph, contradicting <a>interpolation</a> for RDF entailment. </p>
+<p>The properties of <a>simple entailment</a> described earlier do not all apply to <a>RDF entail</a>ment. For example, all the RDF axioms are true in every <a>RDF interpretation</a>, and so are <a>RDF entail</a>ed by the empty graph, contradicting <a>interpolation</a> for RDF entailment. </p>
<section><h4>Patterns of RDF entailment</h4>
@@ -828,7 +863,7 @@
<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 <a>RDF 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 <a>class</a> <code>rdfs:Datatype</code> can be considered to contain exactly the referents of <a>recognize</a>d datatype IRIs. </p>
+<p>When using RDFS semantics, the referents of all <a>recognize</a>d datatype IRIs can be considered to be in the <a>class</a> <code>rdfs:Datatype</code>. </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>. </p>
@@ -867,9 +902,9 @@
</table>
<p>RDFS does not partition the universe into disjoint categories of classes, properties and individuals. Anything in the universe can be used as a class or as a property, or both, while retaining its status as an individual which may be in classes and have properties. Thus, RDFS permits classes which contain other classes, classes of properties, properties of classes, etc. As the axiomatic triples above illustrate, it also permits classes which contain themselves and properties which apply to themselves. A property of a class is not necessarily a property of its members, nor vice versa. </p>
-<section>
+<section class="informative">
<h4>A note on rdfs:Literal</h3>
-<p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal values, which may also be referred to by IRIs. For example, LV does not contain the literal <code>"24"^^xsd:integer</code> but it does contain the number twenty-four.</p>
+<p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal values, which may also be referred to by IRIs. For example, LV does not contain the literal <code>"foodle"^^xsd:string</code> but it does contain the string "foodle".</p>
<p>A triple of the form</p>
@@ -994,13 +1029,11 @@
</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. 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 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>Although the IRIs are called "graph names", they may refer to something other than the graph they are paired with. This allows IRI referring to other kinds of entities, such as persons, to be used in a dataset to <a>identify</a> graphs of information relevant to the entity <a>denote</a>d by the graph name IRI.</p>
-<p>When a graph name IRI is used inside RDF triples in a dataset it may or may not refer to the graph it names. The semantics does not require, nor should RDF engines presume without some external reason to do so, that graph name IRIs used in RDF triples refer to the graph they name.</p>
-
-<p>Graphs in a single dataset may share blank nodes. This is the only case where distinct RDF graphs may share a blank node. Graphs in distinct datasets cannot share blank nodes. </p>
+<p>When a graph name IRI is used inside RDF triples in a dataset it may or may not refer to the graph it names. The semantics does not require, nor should RDF engines presume, without some external reason to do so, that graph name IRIs used in RDF triples refer to the graph they name.</p>
</section>
@@ -1008,7 +1041,7 @@
<section class="appendix"><h3>Entailment rules (Informative)</h3>
-<p>This section is based on work described more fully in [[EXTRDFS]], [[CDCENTAILMENT]], which should be consulted for technical details and proofs. </p>
+<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>
<p>1. Add to S all the RDF (or RDF and RDFS) axiomatic triples except those containing the container membership property IRIs <code>rdf:_1, rdf:_2, ...</code>.<br/>
2. For every container membership property IRI which occurs in E, add the RDF (or RDF and RDFS) axiomatic triples which contain that IRI.<br/>
@@ -1050,7 +1083,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 [[EXTRDFS]] 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-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>
<div class="tabletitle">G-RDF-D entailment pattern.</div>
<table border="1" >
@@ -1093,7 +1126,7 @@
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 <a>generalized RDF (RDFS) closure</a> of S towards E 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>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>
@@ -1107,7 +1140,7 @@
<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 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>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 and blank nodes, 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. The universe of such a pre-interpretation can be restricted to the cardinality N+B+C, where N is the size of the vocabulary, B is the number of blank nodes in the graphs, and C is the number of classes (including datatype classes) that are implicitly mentioned 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>
<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 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.
@@ -1158,7 +1191,7 @@
</section>
-<section class="appendix" id="whatnot"><h2 id="non_semantics">RDF reification, containers and collections. (Informative)</h2>
+<section class="appendix" class="informative" 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,
@@ -1202,8 +1235,7 @@
ex:graph1 rdf:predicate ex:b .<br/>
ex:graph1 rdf:object ex:c .</code></p>
- <p>The second graph is called a <i><a href="#glossReify"
- class="termref"><em>reification</em></a></i> of the triple in the first
+ <p>The second graph is called a <dfn>reification</dfn> of the triple in the first
graph.</p>
<p> Reification is not a form of quotation. Rather, the reification describes the
relationship between a token of a triple and the resources that the triple refers
@@ -1300,7 +1332,7 @@
type <code>rdf:Seq</code> are considered to be ordered, and things
of type <code>rdf:Alt</code> are considered to represent a
collection of alternatives, possibly with a preference ordering.
- The ordering of items in an ordered container is intended to be
+ If the container is of an ordered type, then the ordering of items in the container is intended to be
indicated by the numerical ordering of the container membership
properties, which are assumed to be single-valued.
However, these informal interpretations are not reflected in any formal RDF
@@ -1308,7 +1340,7 @@
<p>RDF does not support any entailments which could arise from enumerating
- the elements of an <code>rdf:Bag</code> in a different order. For example,</p>
+ the elements of an unordered <code>rdf:Bag</code> in a different order. For example,</p>
<p><code>_:xxx rdf:type rdf:Bag .<br/>
_:xxx rdf:_1 ex:a .<br/>
@@ -1319,10 +1351,10 @@
<p><code>_:xxx rdf:_1 ex:b .<br/>
_:xxx rdf:_2 ex:a .</code></p>
- <p>Notice that if this conclusion were <a>valid</a>, then the result of
+ <p>(If this conclusion were <a>valid</a>, then the result of
adding it to the original graph would be <a>entailed</a> by the graph, and this would assert that both elements were in both
positions. This is a consequence of the fact that RDF is a purely
- assertional language.</p>
+ assertional language.)</p>
<p>There is no assumption that a property of a container applies to
any of the elements of the container, or vice versa. </p>
@@ -1338,8 +1370,8 @@
<p><code>_:xxx rdf:_2 _:yyy .</code></p>
- <p>There is no way in RDF to 'close' a container, i.e. to assert
- that it contains only a fixed number of members. This is a
+ <p>There is no way in RDF to assert
+ that a container contains only a fixed number of members. This is a
reflection of the fact that it is always consistent to add a triple
to a graph asserting a membership property of any container. And
finally, there is no built-in assumption that an RDF container has
@@ -1430,22 +1462,6 @@
subject of the <code>rdf:first</code> property, and any subject or object of
the <code>rdf:rest</code> property, be of <code>rdf:type rdf:List</code>. </p>
</section>
-<section>
-
-<h3><a id="rdfValue"></a>rdf:value</h3>
-<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
- of its own.</p>
-<p>Since the range of possible uses for <code>rdf:value</code> is so wide, it
- is difficult to give a precise statement which covers all the intended meanings
- or use cases. Users are cautioned, therefore, that the
- meaning of <code>rdf:value</code> may vary from application to application.
- Even when the intended meaning is clear from the context in the original graph document, it may be
- lost when graphs are merged or when conclusions are inferred.</p>
-</section>
</section>