--- a/rdf-mt/index.html Wed Feb 27 09:52:09 2013 -0800
+++ b/rdf-mt/index.html Fri Mar 01 10:43:33 2013 -0600
@@ -5,12 +5,13 @@
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
- <title>RDF 1.1 Semantics Editors Draft</title>
+ <title>RDF 1.1 Semantics Editor's Draft</title>
<style type="text/css">
-font-family: sans-serif
.figure { text-align: center; }
.figure a[href]:hover { background: transparent; }
table td, table th { border: 1px solid #ddd; padding: 0.2em 0.5em; }
+
+/*<![CDATA[*/
code {font-family: monospace }
a.termref:visited, a.termref:link {font-family: sans-serif;
font-style: normal;
@@ -27,7 +28,8 @@
.ruletable {background-color: #FAFAFF}
.othertable {background-color: #FDFDFD}
.greyout {background-color: #CCCCCC}
-
+ /*]]>*/
+
/*****************************************************************
* ReSpec CSS
* Robin Berjon (robin at berjon dot com)
@@ -537,7 +539,7 @@
<body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"></a></p>
<h1 property="dcterms:title" class="title" id="title">RDF 1.1 Semantics</h1>
-<h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-02-11T00:00:00+0000" id="w3c-working-draft-15-january-2013"> Editors Working Draft 12 February 2013</h2><dl><dt>This version:</dt><dd><a href="https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html">https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html</a></dd><dt>Latest published version:</dt><dd><a href=""></a></dd><dt>Latest editor's draft:</dt><dd><a href=""></a></dd>
+<h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-02-28T00:00:00+0000" id="w3c-working-draft-28-february-2013"> Editors Working Draft 28 February 2013</h2><dl><dt>This version:</dt><dd><a href="https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html">https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html</a></dd><dt>Latest published version:</dt><dd><a href=""></a></dd><dt>Latest editor's draft:</dt><dd><a href=""></a></dd>
<dt>Previous version:</dt><dd><a rel="dcterms:replaces" href=""></a></dd><dt>Latest recommendation:</dt><dd><a href="http://www.w3.org/TR/rdf-mt/">http://www.w3.org/TR/rdf-mt/</a></dd><dt>Editors:</dt><dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Patrick Hayes" href="http://www.ihmc.us/groups/phayes/">Patrick Hayes</a>, <a rel="foaf:workplaceHomepage" href="http://www.ihmc.us/index.php">Florida IHMC</a></span>
</dd>
<dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Peter F. Patel-Schneider" href="////">Peter F. Patel-Schneider</a>, <a rel="foaf:workplaceHomepage" href="////">////</a></span>
@@ -556,7 +558,7 @@
<p class=changenote>Significant differences between this specification and the 2004 RDF 1.0 specification are noted in this format.</p>
<p class=technote>Technical or pedantic notes which explain arcane or side issues, of interest only to some readers, are noted in this format. </p>
<p></p>
-<p class="issue"> The 2004 semantics document contains a lot of material which is devoted to explaining material, such as most of the RDF vocabulary, which is <em>not</em> covered by the formal model theory, and also various warnings and cautions about the limits of truth-based semantics. Much of this has been retained in the present text. It would be a lot shorter and less verbose if all this were omitted, or possibly put into a separate Appendix or a separate section. Any comments on this idea? </p>
+
<h2 id="abstract">Abstract</h2>
<p>This is a specification of a precise semantics for the Resource Description
@@ -564,15 +566,15 @@
<h2><a name="prelim" id="prelim">Introduction</a> </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. Readers unfamiliar with model theory may find the informative sections /// useful, which re-state the semantic conditions in terms of axioms and inference rules. Readers who are unfamiliar with model theory can also find a brief introduction to the basic ideas and terminology in Appendix ////.</p>
+<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. Readers who are unfamiliar with model theory can find a brief introduction to the basic ideas and terminology in Appendix ////, and may find the informative section //// useful. </p>
<p>This specification is normative for RDF <a href="#glossFormal"
class="termref">formal</a> semantics. However, there are many aspects of RDF meaning which are not covered 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 <strong class="RFC2119">MUST NOT</strong> violate the conditions described here. </p>
<h2>Semantic extensions and entailment regimes </h2>
-<p><a id="DefSemanticExtension" name="DefSemanticExtension"></a>RDF is intended for use as a base notation for a variety of extended notations such as OWL and RIF, whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially described meaning. In addition, 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 IRI meanings, the larger the set of valid entailments. </p>
+<p><a id="DefSemanticExtension" name="DefSemanticExtension"></a>RDF is intended for use as a base notation for a variety of extended notations such as OWL //ref// and RIF //ref//, whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. In addition, 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 an <em>RDF semantic extension</em>. Each semantic extension defines an <em>entailment regime</em> 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 phrases such as rdfs-entailment, owl-entailment. All entailment regimes <strong class="RFC2119">MUST</strong> be <em>monotonic</em> extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A must also entail B under any extended notion of entailment. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime.</p>
+<p>A particular such set of semantic assumptions is called an <em>RDF semantic extension</em>. Each semantic extension defines an <em>entailment regime</em> 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 rdfs-entailment, owl-entailment. All entailment regimes <strong class="RFC2119">MUST</strong> be <em>monotonic</em> extensions of the simple entailment regime described in the next section, in the sense that if A simply entails B then A must also entail B under any extended notion of entailment. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime.</p>
<h1>Notation and terminology</h1>
@@ -585,7 +587,7 @@
to a formal summary of the entire semantics.
</p>
<p>Throughout this document, the equality sign = indicates
- identity. The statement "A = B" means that the expressions "A" and "B" name the same entity. Angle brackets <x,y> are used to indicate an ordered pair
+ identity. The statement "A = B" means that the expressions "A" and "B" name the same entity. 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 <a
href="http://www.w3.org/TR/rdf-testcases/#ntriples">N-Triples</a> syntax described
@@ -593,11 +595,16 @@
literal strings are enclosed within double quote marks, language tags indicated
by the use of the <code>@</code> sign, and triples terminate with a 'code dot'
<code>.</code> . </p>
+<p>In stating general rules or conditions we will use the following conventions:<br />
+sss or ttt indicates a Unicode character string; <br />
+aaa or bbb indicates an IRI<br />
+lll or mmm indicates a literal<br />
+_:xxx or _:yyy indicates a blank node. <br /></p>
-<p class=issue> Need more on the aaa and sss conventions. and the abbreviated Ntriples notation. </p>
+<p class=issue> Need more on the abbreviated Ntriples notation. </p>
<p>A <em>name</em> is any IRI or literal. A <em>vocabulary</em> is a set of names.
-<p class=issue>The definition in Concepts seems to be narrower than this. </p>
+</p>
@@ -605,7 +612,7 @@
-<p>A simple interpretation I of a vocabulary V is a structure consisting of:</p>
+<p>A simple interpretation I is a structure consisting of:</p>
<div class="title">Definition of a simple interpretation.</div>
<table border="1" summary="definition of a simple interpretation">
@@ -614,24 +621,29 @@
of I.</p>
<p>2. <span >A set IP, called the set of properties of I.</span></p>
<p>3. A mapping IEXT from IP into the powerset of IR x IR i.e. the
- set of sets of pairs < x,y > with x and y in IR .</p>
- <p>4. A mapping IS from IRIs in V into (IR union IP)</p>
- <p>5. A partial mapping IL from literals in V into IR.</p>
+ set of sets of pairs < x, y > with x and y in IR .</p>
+ <p>4. A mapping IS from IRIs into (IR union IP)</p>
+ <p>5. A partial mapping IL from literals in V into IR </p>
</td>
</tr>
</table>
-<p class=changenote>In the 2004 RDF 1.0 semantics, LV was not a partial mapping.</p>
+<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 decideable algorithms. Details are given in Appendix///. </p>
+
<p>IEXT(x), called
the <a href="#defexten" class="termref"><i>extension</i></a> of x, is a
set of pairs which identify the arguments for which the property is true,
that is, a binary relational extension.
</p>
+<p>The distinction between IR and IL will become significant below when the semantics of datatypes are defined. IL is allowed to be partial because some literals may fail to have a referent. However, IL is total on language-tagged strings and literals of type <code>xsd:string</code>. </p>
<p class="technote">
It is conventional to map a relation name to a relational extension directly. This however presumes that the vocabulary is segregated into relation names and individual names, and RDF makes no such assumption. Moreover, RDF allows an IRI to be used as a relation name applied to itself as an argument. Such self-application structures are used in RDFS, for example. The use of the IEXT mapping to distinguish the relation as an object from its relational extension accommodates both of these requirements. It also provides for a more intuitive notion of RDFS 'class' which can be distinguished from its set-theoretic extension.
</p>
+
+
<p>The denotation of a ground RDF graph in I is then given by the following
rules</p>
@@ -639,25 +651,20 @@
<div class="title">Semantic conditions for ground graphs.</div>
<table cellpadding="5" border="2" summary="semantic conditions for RDF graphs">
<tbody>
-<tr>
-<td class="semantictable">if E is a <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string" class="termref">language-tagged string</a> with type <code>rdf:langString</code>, a lexical form sss and a tag ttt, then IL(E) = < sss , ttt ></td>
- </tr>
-<tr>
-<td class="semantictable">if E is a literal with type <code>xsd:string</code> and a lexical form sss, then IL(E) = sss </td>
- </tr>
+
<tr>
- <td class="semantictable">if E is a literal in V then I(E) = IL(E)</td>
+ <td class="semantictable">if E is a literal then I(E) = IL(E)</td>
</tr>
<tr>
- <td class="semantictable">if E is an IRI in V then I(E) = IS(E)</td>
+ <td class="semantictable">if E is an IRI then I(E) = IS(E)</td>
</tr>
<tr>
<td class="semantictable"><p>if E is a ground triple s p o<code>.</code>
then I(E) = true if </p>
- <p>s, p and o are in V, <span >I(p) is in IP and the pair </span> < I(s) , I(o) >
+ <p>s, p and o are in V, <span >I(p) is in IP and the pair </span> <I(s),I(o)>
is in IEXT(I(p))</p>
<p>otherwise I(E)= false.</p></td>
</tr>
@@ -669,32 +676,19 @@
</tbody>
</table>
-<p>The first two conditions fix the denotations of simple string literals with and without language tags.</p>
-<p class="changenote"> <em>Change note.</em> 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. We include both of these cases in the basic graph semantics to maintain conformity to the 2004 RDF 1.0 specifications. None of these literals can be ill-typed **/BUT SEE BELOW/**, so their presence does not affect any entailments. </p>
-
-<p class="issue"> What do we say about a language-tagged string whose tag is not a legal language tag? Is that (a) a syntax error (b) an ill-typed literal, so having no value and producing a contradiction, or (c) a valid literal which happens to denote a pair containing an illegal language tag? We need to decide this as the semantics will treat these cases differently.
-</p>
+<p> If IL(E) is undefined for some literal E, then E has no semantic value, so any triple containing it must be false, so any graph containing that triple must also be false.</p>
+<p> The final condition implies that the empty graph (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 must be in IR; so any IRI which occurs in a graph both as a predicate and as a subject or object must denote something in the intersection of IP and IR.</p>
-<p>If an interpretation does not give a semantic value
- to a <a href="#defname" class="termref">name</a> in the graph then these truth-conditions will always yield the value false for some triple
- in the graph, and hence for the graph itself. Turned around, this means that in order for a graph to be true, all the IRI and literal nodes in it must refer to something in the world being described. </p>
-<p> The final condition implies that an empty graph (an empty set of triples) is trivially 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 must be in IR; so any IRI which occurs in a graph both as a predicate and as a subject or object must denote something in the intersection of IP and IR.</p>
-<p>The distinction between IS and IL will become significant below when the semantics of datatypes are defined. IL is allowed to be partial because some literals may fail to have a referent.</p>
-
-<p class="issue">Since 'plain' literals now have the type xsd:string, it seems we we must incorporate this datatype into the basic definition of RDF graph. Any objections to this? </p>
-<p class="issue"> rdf:langString is a "type", but is it a datatype? This will matter in RDFS where we are faced with the potential axiom (rdf:langString rdf:type rdfs:Datatype). </p>
-
- <h3><a name="unlabel" id="unlabel">1.5. Blank Nodes</a></h3>
+ <h3><a name="unlabel" id="unlabel">1.5. Blank Nodes</a></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.
+<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to identify any particular thing. They play a similar role to existentially quantified variables in a conventional logical notation. This is not the same as assuming that the blank node indicates an 'unknown' IRI.
</p>
-<p class="technote">Blank nodes play a similar role to existentially quantified variables in a conventional logical notation. </p>
-<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node <em>scope</em>. All blank nodes in an RDF graph must be in a single scope, but a scope might extend beyond a single graph. For example, a TriG document ///ref/// defines a blank node scope which extends over all graphs in the dataset described by the document. The <em>scope of a graph</em> means the smallest scope containing all the blank nodes which occur in the graph. </p>
+<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node <em>scope</em>. Note that all blank nodes in an RDF graph must be in a single scope, but that a scope might extend beyond a single graph. For example, a TriG document ///ref/// defines a blank node scope which extends over all graphs in the dataset described by the document.</p>
<p class="issue">The Concepts document does not yet define blank node scopes.</p>
@@ -703,15 +697,11 @@
<div class="title">Semantic condition for blank nodes.</div>
<table cellpadding="5" border="2" summary="Semantic conditions for blank nodes">
<tbody>
- <tr>
-
- <td class="semantictable">If E is a blank node and A(E) is defined then
- [I+A](E) = A(E)</td>
- </tr>
+
<tr>
- <td class="semantictable">If E is an RDF graph then I(E) = true if [I+A'](E) =
- true for some mapping A' from the set of blank nodes in the scope of E to IR, otherwise
+ <td class="semantictable">If E is an RDF graph then I(E) = true if [I+A](E) =
+ true for some mapping A from the set of blank nodes in the scope of E to IR, otherwise
I(E)= false.</td>
</tr>
</tbody>
@@ -730,10 +720,11 @@
<p> <a id="defmerge" name="defmerge"></a>Any set of graphs can be treated as a single graph simply by taking the union of the sets of triples. If two or more graphs are in the same scope, then the same blank node might occur in more than one of them, and will retain its identity when the union graph is formed. If the graphs in a set are from different scopes they cannot share blank nodes, so if they are represented by a notation which uses blank node identifiers then care must be taken to change the identifiers to avoid name clashes between blank node identifiers used in graphs from different scopes. Once this is done − that is, when graphs from different scopes do not use the same blank node identifier − then the union graph can be formed by taking the union of the triples in the various graphs in S. We will refer to this process of forming the union of graphs as <em>merging</em>, and to the union graph as the <em>merge</em> of the original graphs. </p>
-<p class="changenote"> The 2004 RDF 1.0 specification did not define a notion of blank node scope, so allowed the (irrational) possibility of two graphs 'accidentally' sharing a blank node. It was therefore obliged to define a process of 'standardizing apart' blank nodes, and to distinguish graph unions from graph merges. Requiring each RDF graph to be in a single blank node scope simplifies the basic syntax and renders this distinction unnecessary. Standardizing apart may still be needed at a concrete syntax level, but is not part of the underlying conceptual model of RDF. The earlier terminology is retained to avoid confusion, but now 'merging' simply means 'taking the union' at the graph syntax level.</p>
+<p class="changenote"> The 2004 RDF 1.0 specification did not define a notion of blank node scope, so allowed the possibility of two graphs 'accidentally' sharing a blank node. It was therefore obliged to define a process of 'standardizing apart' blank nodes, and to distinguish graph unions from graph merges. Requiring each RDF graph to be in a single blank node scope simplifies the basic syntax and renders this distinction unnecessary. Standardizing apart may still be needed at a concrete syntax level, but is not part of the underlying conceptual model of RDF. The earlier terminology is retained to avoid confusion, but now 'merging' simply means 'taking the union' at the graph syntax level.</p>
<h3>Simple Entailment</h3>
+<p class="issue">Should the 'explanatory' material in here be moved to the tutorial appendix? </p>
<p>Following standard terminology, we say that I <a
id="defsatis" name="defsatis"></a><i>satisfies</i> E when I(E)=true, and a set
S of RDF graphs <a id="defentail"
@@ -744,12 +735,10 @@
<p><a id="defvalid" name="defvalid">Any process which constructs a graph E from some other graph(s) S is said to be <em>(simply) valid</em> if S simply entails E </a><span >in every case</span>, otherwise <em>invalid.</em> </p>
-<p class="issue"> The following material could be made part of the idiots guide. </p>
-<div class="greyout">
-<p>Being an invalid process does not mean that the conclusion is false, and being <a href="#glossValid" class="termref">valid</a> does not guarantee truth. However, validity represents the best guarantee that any assertional language can offer: if given true inputs, it will never draw a false conclusion from them. The fact that an inference is valid should not be understood as meaning that the inference must be made, or that any process is obliged or required to make the inference. Nothing in this specification mandates any particular operations to be applied to RDF graphs. Entailment and validity are concerned solely with establishing the conditions on operations which guarantee the preservation of truth. Invalid processes are not prohibited, but 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 the inference must be made, or that any process 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 to be applied to RDF graphs. Entailment and validity are concerned solely with establishing the conditions on 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 //ref// which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, this validly entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF semantic extension. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
-</div>
+<p>Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest //ref// which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest validly entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF semantic extension. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
+
<h3>Some basic properties of simple entailment. </h3>
<p>The properties described here apply only to simple entailment, not to extended notions
of entailment introduced in later sections. Proofs
@@ -835,50 +824,53 @@
<h3>Literals and datatypes</h3>
-<p class="changenote"> In the 2004 RDF 1.0 specification, datatypes were as an extension to RDFS and 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 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>RDF literals are either language-tagged literals, whose semantics is already specified, or datatyped literals which
-combine a string and an IRI which is intended to identify a datatype. A datatype is understood to define a partial mapping from character strings to values, and the literal then refers to the value obtained by applying the datatype mapping to the character string. If this mapping gives no value for the literal string, then the literal also has no value.</p>
+<p>RDF literals are either language-tagged literals or datatyped literals which
+combine a string and an IRI identifying a datatype. A datatype is understood to define a partial mapping from character strings to values, and the literal then refers to the value obtained by applying the datatype mapping to the character string. If this mapping gives no value for the literal string, then the literal also has no value. </p>
-<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a known datatype. Interpretations will vary according to how many IRIs they recognize as denoting datatypes, so we will refer to a set D of <em>recognized datatype IRIs</em> and treat this as a parameter on interpretations, and hence upon entailments. Literals with an "unknown" datatype, that is, with a datatype IRI which is not in the set of recognized datatypes, are treated like IRI names and assumed to denote some thing in the universe IR. </p>
+<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it does not identify a datatype. Interpretations will vary according to how many IRIs they recognize as denoting datatypes, so we will refer to a set D of <em>recognized datatype IRIs</em> and treat this as a parameter on interpretations, and hence upon entailments. Literals with an "unknown" datatype, that is, with a datatype IRI which is not in the set of recognized datatypes, are treated like IRI names and assumed to denote some thing in the universe IR. </p>
<p class="changenote"> In the 2004 RDF 1.0 specification, D was defined as a datatype mapping from IRIs to datatypes, rather than simply as a set of IRIs. </p>
<p> A literal whose datatype IRI is recognized, but whose character string is not in the domain of the datatype mapping, is called <em>ill-typed</em>.</p>
-<p>The semantics of datatypes assumes that datatype IRIs denote things called datatypes in the universe, and that every recognized datatype d has a corresponding lexical-to-value mapping L2V(d) from character strings to semantic values. For example,</p><p> L2V(<code>http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal</code>)('24') </p><p> is the number twenty-four. The lexical-to-value mapping is defined by the specification of the datatype, externally to RDF.</p>
+<p>The semantics of datatypes assumes that datatype IRIs denote things called datatypes in the universe, and that every recognized datatype d has a corresponding lexical-to-value mapping L2V(d) from character strings to semantic values. For example,</p><p> L2V(<code>http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal</code>)('24') </p><p> is the number twenty-four. Lexical-to-value mappings are defined by the specification of the datatype, externally to RDF.</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, even though no L2V mapping is defined for it. The semantics of literals with this as their type are given below. (If datatype L2V mappings were defined on pairs of lexical values rather than strings, then the L2V mapping for <code>rdf:langString</code> would be the identity function on pairs of the form < unicode string, language tag >. But as they are not, we simply list this as a special case.)</p>
+
+
+<p>D-interpretations <strong class="RFC2119">MUST</strong> interpret any IRI which is normatively defined to identify a datatype, as referring to that datatype. In particular, the XML Schema built-in datatype IRIs listed in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#xsd-datatypes">///Concepts 5.1///</a> <strong class="RFC2119">MUST</strong> refer to the datatypes defined in ///XML Schema///, the IRI <code>rdf:HTML</code> <strong class="RFC2119">MUST</strong> refer to the datatype described in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#section-html">///Concepts 5.2///</a>, the IRI <code>rdf:XMLLiteral</code> <strong class="RFC2119">MUST</strong> refer to the datatype described in <a href="http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/#section-XMLLitera">///Concepts 5.3///</a>, and the IRI <code>rdf:plainLiteral</code> <strong class="RFC2119">MUST</strong> refer to the datatype defined in <a href="www.w3.org/TR/rdf-plain-literal/">///PlainLiteral///</a>. </p>
+
<h3>D-interpretations</h3>
-<p>Let D be a set of IRIs identifying recognized datatypes. A <em>(simple) D-interpretation</em> of V is a simple interpretation (V union D) which satisfies the following conditions:</p>
+<p>Let D be a set of IRIs identifying datatypes. A <em>(simple) D-interpretation</em> is a simple interpretation which satisfies the following conditions:</p>
<div class="title">Semantic conditions for datatyped literals.</div>
<table border="1" class="semantictable" summary="datatype semantic condition">
<tbody>
-<tr>
-<tr><td>For every IRI aaa in D, I(aaa) is the datatype conventionally identified by aaa.</td></tr><tr>
- <td>For every IRI aaa in D, and every datatyped literal "sss"^^aaa in V, IL("sss"^^aaa) = L2V(I(aaa))(sss)</td></tr></tbody></table></p>
+<tr><td>If <code>rdf:langString</code> is in D, then for every language-tagged string E with lexical form sss and language tag ttt, IL(E)= < sss, ttt > </td></tr>
+<tr><td>For every other IRI aaa in D, and every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(I(aaa))(sss)</td></tr>
+</tbody></table></p>
-<p>If the literal is ill-typed then the L2V 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-inconsistent, i.e. will be 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>If the literal is ill-typed then the L2V 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-inconsistent, 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>
+<br/>
-<p>The set of all values of datatype mappings − that is, the intersection of IR with the union of the ranges of L2V(I(aaa)) for aaa in D − is called the set LV of <em>literal values</em>. LV is a subset of IR but its extent depends upon the set D. Note that an IRI may also denote a value in LV, and blank nodes may range over values in LV.
-
-
-<p class="changenote"> In the 2004 RDF 1.0 specification, ill-typed literals were required to denote a value in IR, but excluded from LV. </p>
+<p class="changenote"> In the 2004 RDF 1.0 specification, ill-typed literals were required to denote a value in IR, and D-inconsistency could only be recognized by using the RDFS semantics. </p>
<p></p>
-<p class="technote"> These conditions do not require the universe of every interpretation to contain all possible literal values. D-interpretations can be finite.</p>
<h3>Datatype entailment</h3>
-<p>Datatype entailment is a form of vocabulary entailment. </p><p>Satisfaction and entailment are defined exactly as before, but restricted to D-interpretations. A graph is <em>(simply) D-satisfiable </em>when it has the value true in some D-interpretation, and a set S of graphs <em>(simply) D-entails </em>a graph G when every D-interpretation which makes S true also D-satisfies G.</p>
+<p>A graph is <em>(simply) D-satisfiable </em>when it has the value true in some D-interpretation, and a set S of graphs <em>(simply) D-entails </em>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 <em>D-unsatisfiable</em>. A D-unsatisfiable graph D-entails any graph. </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 D-entailment when D is the empty set. If S D-entails G then S simply entails G, but not the reverse. </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. If S D-entails G then S simply entails G, but not the reverse. </p>
<p>Several of the basic properties of simple entailment are also true for D-entailment, but the <a href="#interplemma" class="termref">interpolation lemma</a> is not true for D-entailment, since D-entailments
-can hold because of particular properties of the lexical-to-value mappings of the recognized datatypes. For example, if D contains <code>xsd:number</code>, then </p>
+can hold because of particular properties of the lexical-to-value mappings of the recognized datatypes. For example, if D contains <code>xsd:number</code> then </p>
<p><code>aaa ppp "00025"^^xsd:number .</code></p>
@@ -892,42 +884,25 @@
<h3><a name="RDFINTERP" id="RDFINTERP">3.1 RDF Interpretations</a></h3>
- <p ><a name="defRDFV" id="defRDFV"></a>The <em>RDF vocabulary, </em>rdfV, is an infinite
- set of IRIs in the <code>rdf:</code> namespace:</p>
-
-
-
- <table border="1" summary="rdf vocabulary">
- <tbody>
- <tr>
- <td class="othertable"><strong>RDF vocabulary</strong></td>
- </tr>
+ <p ><a name="defRDFV" id="defRDFV"></a>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.
- <tr>
-
- <td class="othertable"> <code>rdf:type</code> <code>rdf:Property
- rdf:XMLLiteral rdf:HTML rdf:nil rdf:List rdf:Statement rdf:subject rdf:predicate
- rdf:object rdf:first rdf:rest rdf:Seq rdf:Bag rdf:Alt rdf:value rdf:_1 rdf:_2
- ... </code></td>
- </tr>
- </tbody>
- </table>
- <p>The RDF built-in datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in ///RDF Concepts///. RDF interpretations are required to recognize these datatypes. The truth conditions on RDF graphs mean that the datatypes <code>rdf:langString</code> and <code>xsd:string</code> are effectively recognized also. </p>
-
-<p> <a id="rdfinterpdef" name="rdfinterpdef"></a>An <i>RDF-interpretation</i>
- of a vocabulary V is a {<code>rdf:XMLLiteral</code> , <code>rdf:HTML</code> , <code>rdf:langString</code>, <code>xsd:string</code>}-interpretation I <span >of (V union rdfV)
- which satisfies:</p>
-<div class="title">RDF semantic condition.</div>
+<p> <a id="rdfinterpdef" name="rdfinterpdef"></a>An <i>rdf-D-interpretation</i>
+ I is a D-interpretation where D includes <code>rdf:langString</code> and <code>xsd:string</code>, and which satisfies:</p>
+<div class="title">RDF semantic conditions.</div>
<table border="1" summary="RDF semantic condition">
<tbody>
<tr>
<td class="semantictable"><a name="rdfsemcond1" id="rdfsemcond1"></a>x is
in IP if and only if <x, I(<code>rdf:Property</code>)> is in IEXT(I(<code>rdf:type</code>))</td>
</tr>
+<tr><td class="semantictable"><a name="rdfsemcond2" id="rdfsemcond2"> For every language-tagged string E, < I(E), I(<code>rdf:langString</code>) > is in IEXT(I(<code>rdf:type</code>))
+<tr><td class="semantictable"><a name="rdfsemcond3" id="rdfsemcond3">For every other IRI aaa in D, and every well-typed literal "sss"^^aaa, < IL("sss"^^aaa), I(aaa) > is in IEXT(I(<code>rdf:type</code>))</td></tr>
+
</tbody>
</table>
- <p>and satisfies all the following triples:</p>
+ <p>and satisfies every triple in the following infinite set:</p>
<div class="title">RDF axioms.</div>
<table border="1" summary="RDF axiomatic triples">
@@ -949,29 +924,363 @@
</tr>
</table>
-<p> </p>
+<p>No other semantic constraints are imposed upon rdf-D-interpretations, so RDF imposes no particular normative meanings on the rest of the RDF vocabulary. Some consequences of this are discussed in Appendix ///</p>
+
+<p>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 datatypes <code>rdf:langString</code> and <code>xsd:string</code> must be recognized by all RDF interpretations. </p><p>The RDF built-in datatypes <code>rdf:XMLLiteral</code> and <code>rdf:HTML</code> are defined in ///RDF Concepts///. RDF interpretations are not required to recognize these datatypes. </p>
<h3><a name="rdf_entail" id="rdf_entail"></a>RDF entailment</h3>
-<p>S <i>rdf-entails</i> E when every rdf-interpretation which satisfies every
+<p>S <i>rdf-D-entails</i> E when every rdf-D-interpretation which satisfies every
member of S also satisfies E. </p>
-<p>It is easy to see that the lemmas in <a href="#entail" > Section 2</a> do not all apply to rdf-entailment:
- for example, all the rdf axioms are true in every <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, so are rdf-entailed by the empty graph,
- contradicting the <a href="#interplemma" class="termref">interpolation lemma</a> for rdf-entailment. </p>
+<p>The lemmas in <a href="#entail" > Section 2</a> do not all apply to rdf-D-entailment:
+ for example, all the rdf axioms are true in every <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, so are rdf-D-entailed by the empty graph,
+ contradicting the <a href="#interplemma" class="termref">interpolation lemma</a> for rdf-D-entailment. Section //// gives rules that can be used to detect RDF entailment between RDF graphs. </p>
-<p class="technote"> Since rdfV is infinite, there are no finite RDF interpretations. In practice, it is sufficient to restrict the RDF axioms to a finite subset which only contains the membership properties which actually occur in the graph vocabulary, but this is complicated to describe exactly. ///This is weak. </p>
-<p class="issue"> Ideally we should define rdf-satisfaction so that it allows finite models. Every way of doing this investigated so far has been either too complicated or unclear in its formal properties. Work continues on finding a more elegant solution, but the account given here is a fall-back.</p>
+
+
+
+<h2><a name="rdfs_interp" id="rdfs_interp">4. Interpreting the RDFS Vocabulary</a></h2>
+
+
+<h3><a name="RDFSINTERP" id="RDFSINTERP">4.1 RDFS Interpretations</a></h3>
+
+<p>RDF Schema [<cite><a href="#ref-rdf-vocabulary">RDF-VOCABULARY</a></cite>]
+ extends RDF to a larger <a id="defRDFSV" name="defRDFSV"></a>vocabulary
+ with more complex semantic constraints:</p>
+
+ <div class="c1">
+ <table border="1" summary="RDFS vocabulary">
+ <tbody>
+ <tr>
+ <td class="othertable"><strong>RDFS vocabulary</strong></td>
+ </tr>
+
+ <tr>
+ <td class="othertable"><code>rdfs:domain rdfs:range rdfs:Resource rdfs:Literal
+ rdfs:Datatype rdfs:Class rdfs:subClassOf rdfs:subPropertyOf
+ rdfs:member rdfs:Container rdfs:ContainerMembershipProperty
+ rdfs:comment rdfs:seeAlso rdfs:isDefinedBy
+ rdfs:label</code></td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+<p>(<code>rdfs:comment</code>,<code> rdfs:seeAlso</code>, <code>rdfs:isDefinedBy</code>
+ and <code>rdfs:label</code> are included here because some constraints which
+ 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
+ in terms of a new semantic construct, a <a
+ href="#glossClass" class="termref"><em>class</em></a>, i.e. a resource which represents
+ a set of things in the universe which all have that class as the 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>.
+ 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.
+ The class extension of <code>rdfs:Class</code> contains the class <code>rdfs:Class</code>.
+</p>
+
+
+<p><a id="rdfsinterpdef" name="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>
+
+<div class="title">RDFS semantic conditions.</div>
+ <table border="1">
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond1" id="rdfssemcond1"></a>ICEXT(y) is defined to be { x : < x,y > is in IEXT(I(<code>rdf:type</code>)) }</p>
+ <p>IC is defined to be ICEXT(I(<code>rdfs:Class</code>))</p>
+ <p>LV is defined to be ICEXT(I(<code>rdfs:Literal</code>))</p>
+ <p>IL(E) is in LV, for every well-typed literal E</p>
+ <p>ICEXT(I(<code>rdfs:Resource</code>)) = IR</p>
+<p>ICEXT(I(<code>rdf:langString</code>)) is the set {I(E) : E a language-tagged string }</p>
+<p>for every other IRI aaa in D, ICEXT(I(aaa)) is the value space of I(aaa)</p>
+<p>for every IRI aaa in D, I(aaa) is in ICEXT(I(<code>rdfs:Datatype</code>)) </p>
+</td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond2" id="rdfssemcond2"></a>If
+ < x,y > is in IEXT(I(<code>rdfs:domain</code>)) and < u,v > is
+ in IEXT(x) then u is in ICEXT(y)</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond3" id="rdfssemcond3"></a>If
+ < x,y > is in IEXT(I(<code>rdfs:range</code>)) and < u,v > is
+ in IEXT(x) then v is in ICEXT(y)</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond4" id="rdfssemcond4"></a>IEXT(I(<code>rdfs:subPropertyOf</code>))
+ is transitive and reflexive on IP</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond5" id="rdfssemcond5"></a>If
+ <x,y> is in IEXT(I(<code>rdfs:subPropertyOf</code>)) then x and
+ y are in IP and IEXT(x) is a subset of IEXT(y)</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond6" id="rdfssemcond6"></a>If
+ x is in IC then < x, I(<code>rdfs:Resource</code>) > is in IEXT(I(<code>rdfs:subClassOf</code>))</p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond8" id="rdfssemcond8"></a>IEXT(I(<code>rdfs:subClassOf</code>))
+ is transitive and reflexive on IC</p></td>
+ </tr>
+
+ <td class="semantictable"> <p><a name="rdfssemcond7" id="rdfssemcond7"></a>If
+ < x,y > is in IEXT(I(<code>rdfs:subClassOf</code>)) then x and y are
+ in IC and ICEXT(x) is a subset of ICEXT(y)</p></td>
+ </tr>
+ <tr>
+
+
+ <tr>
+ <td class="semantictable"><p><a name="rdfssemcond9" id="rdfssemcond9"></a>If
+ x is in ICEXT(I(<code>rdfs:ContainerMembershipProperty</code>)) then:<br />
+ < x, I(<code>rdfs:member</code>) > is in IEXT(I(<code>rdfs:subPropertyOf</code>))<br />
+ </p></td>
+ </tr>
+ <tr>
+
+ <td class="semantictable"><p><a name="rdfssemcond10" id="rdfssemcond10"></a>If
+ x is in ICEXT(I(<code>rdfs:Datatype</code>)) then <span >< x,
+ I(<code>rdfs:Literal</code>) > is in IEXT(I(<code>rdfs:subClassOf</code>))</span></p></td>
+ </tr>
+ </table>
+<p></p>
+
+
+
+
+ <p><a id="RDFS_axiomatic_triples" name="RDFS_axiomatic_triples"> </a>
+ </p>
+ <div class="title">RDFS axiomatic triples.</div>
+ <table border="1" summary="RDFS axioms">
+
+ <tr>
+
+
+ <td class="ruletable"> <code>rdf:type rdfs:domain rdfs:Resource .<br />
+ rdfs:domain rdfs:domain rdf:Property .<br />
+ rdfs:range rdfs:domain rdf:Property .<br />
+ rdfs:subPropertyOf rdfs:domain rdf:Property .<br />
+ <a name="axtripleforproof1" id="axtripleforproof1"></a>rdfs:subClassOf rdfs:domain
+ rdfs:Class .<br />
+ rdf:subject rdfs:domain rdf:Statement .<br />
+ rdf:predicate rdfs:domain rdf:Statement .<br />
+ rdf:object rdfs:domain rdf:Statement .<br />
+ rdfs:member rdfs:domain rdfs:Resource . <br />
+ rdf:first rdfs:domain rdf:List .<br />
+ rdf:rest rdfs:domain rdf:List .<br />
+ rdfs:seeAlso rdfs:domain rdfs:Resource .<br />
+ rdfs:isDefinedBy rdfs:domain rdfs:Resource .<br />
+ rdfs:comment rdfs:domain rdfs:Resource .<br />
+ rdfs:label rdfs:domain rdfs:Resource .<br />
+ rdf:value rdfs:domain rdfs:Resource .<br />
+ <br />
+ rdf:type rdfs:range rdfs:Class .<br />
+ rdfs:domain rdfs:range rdfs:Class .<br />
+ rdfs:range rdfs:range rdfs:Class .<br />
+ rdfs:subPropertyOf rdfs:range rdf:Property .<br />
+ <a name="axtripleforproof2" id="axtripleforproof2"></a>rdfs:subClassOf rdfs:range
+ rdfs:Class .<br />
+ rdf:subject rdfs:range rdfs:Resource .<br />
+ rdf:predicate rdfs:range rdfs:Resource .<br />
+ rdf:object rdfs:range rdfs:Resource .<br />
+ rdfs:member rdfs:range rdfs:Resource .<br />
+ rdf:first rdfs:range rdfs:Resource .<br />
+ rdf:rest rdfs:range rdf:List .<br />
+ rdfs:seeAlso rdfs:range rdfs:Resource .<br />
+ rdfs:isDefinedBy rdfs:range rdfs:Resource .<br />
+ rdfs:comment rdfs:range rdfs:Literal .<br />
+ rdfs:label rdfs:range rdfs:Literal .<br />
+ rdf:value rdfs:range rdfs:Resource .<br />
+ <br />
+ rdf:Alt rdfs:subClassOf rdfs:Container .<br />
+ rdf:Bag rdfs:subClassOf rdfs:Container .<br />
+ rdf:Seq rdfs:subClassOf rdfs:Container .<br />
+ rdfs:ContainerMembershipProperty rdfs:subClassOf rdf:Property .<br />
+ <br />
+ rdfs:isDefinedBy rdfs:subPropertyOf rdfs:seeAlso .<br />
+ <br />
+
+ rdfs:Datatype rdfs:subClassOf rdfs:Class .<br />
+ <br />
+ rdf:_1 rdf:type rdfs:ContainerMembershipProperty .<br />
+ <span >rdf:_1 rdfs:domain rdfs:Resource .<br />
+ rdf:_1 rdfs:range rdfs:Resource .</span> <br />
+ rdf:_2 rdf:type rdfs:ContainerMembershipProperty .<br />
+ rdf:_2 rdfs:domain rdfs:Resource .<br />
+ rdf:_2 rdfs:range rdfs:Resource . <br />
+ </code>... <br /> </td>
+ </tr>
+
+ </table>
+
+<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 <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, the first condition implies that IP
+ = ICEXT(I(<code>rdf:Property</code>)).</p>
+ <p>The semantic conditions on rdf-D-interpretations, together with the RDFS conditions on ICEXT, mean that every recognized datatype can be treated as an RDFS class, whose extension contains all the datatype values which are in the range of the datatype L2V mapping: ICEXT(I(aaa)) = { x : x = L2V(I(aaa))(sss) } for some string sss, when aaa is a datatype IRI in D. This produces a number of intuitive entailments, for example </p>
+
+<p><code>aaa ppp "nnn"^^xsd:number .</code></p>
+
+<p>rdfs-{<code>xsd:number</code>}-entails</p>
+
+<code>aaa ppp _:x . <br/> _:x rdf:type xsd:number .</code>
+
+</p>
+<p class="issue"> Why wouldn't this be an RDF-D-entailment? After all, it only uses terms in the RDF namespace. In general, the RDF/RDFS distinction seems to be somewhat muddled. </p>
+
+<p>These axioms and conditions have some redundancy. For example, all but one
+ of the RDF axiomatic triples can be derived from the RDFS axiomatic triples
+ and the semantic conditions on ICEXT,<code> rdfs:domain</code> and <code>rdfs:range</code>.
+ Other triples which must be true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s
+ include the following:</p>
+ <div class="title">Some rdfs-valid triples.</div>
+<table border="1">
+ <tr>
+ <td class="ruletable"><code>rdfs:Resource rdf:type rdfs:Class .<br />
+ rdfs:Class rdf:type rdfs:Class .<br />
+ rdfs:Literal rdf:type rdfs:Class .<br />
+ rdf:XMLLiteral rdf:type rdfs:Class .<br />
+rdf:HTML rdf:type rdfs:Class .<br />
+ rdfs:Datatype rdf:type rdfs:Class .<br />
+ rdf:Seq rdf:type rdfs:Class .<br />
+ rdf:Bag rdf:type rdfs:Class .<br />
+ rdf:Alt rdf:type rdfs:Class .<br />
+ rdfs:Container rdf:type rdfs:Class .<br />
+ rdf:List rdf:type rdfs:Class .<br />
+ rdfs:ContainerMembershipProperty rdf:type rdfs:Class .<br />
+ rdf:Property rdf:type rdfs:Class .<br />
+ rdf:Statement rdf:type rdfs:Class .<br />
+ <br />
+ rdfs:domain rdf:type rdf:Property .<br />
+ rdfs:range rdf:type rdf:Property .<br />
+ rdfs:subPropertyOf rdf:type rdf:Property .<br />
+ rdfs:subClassOf rdf:type rdf:Property .<br />
+ rdfs:member rdf:type rdf:Property .<br />
+ rdfs:seeAlso rdf:type rdf:Property .<br />
+ rdfs:isDefinedBy rdf:type rdf:Property .<br />
+ rdfs:comment rdf:type rdf:Property .<br />
+ rdfs:label rdf:type rdf:Property .<br />
+ </code><code></code></td>
+ </tr>
+</table>
+
+<p class="technote">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>
+<br />
+
+
+<h3><a name="ExtensionalDomRang" id="ExtensionalDomRang"></a>4.2 Extensional Semantic
+ Conditions (Informative)</h3>
+<p class="issue">Is this section useful, or is it more likely to be confusing? Editor is inclined to delete it. </p>
+<p>The semantics given above is deliberately chosen to be the weakest 'reasonable'
+ interpretation of the RDFS vocabulary. Semantic extensions <strong title="MAY in RFC 2119 context" class="RFC2119">MAY</strong>
+ strengthen the range, domain, subclass and subproperty semantic conditions to
+ the following '<a class="termref" href="#glossExtensional">extensional</a>'
+ versions:</p>
+ <div class="title">Extensional alternatives for some RDFS semantic conditions.</div>
+<table summary="range and domain extension conditions" border="1">
+ <tr>
+ <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:subClassOf</code>))
+ if and only if x and y are in IC and ICEXT(x) is a subset of ICEXT(y)</p></td>
+ </tr>
+ <tr>
+ <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:subPropertyOf</code>))
+ if and only if x and y are in IP and IEXT(x) is a subset of IEXT(y)</p></td>
+ </tr>
+ <tr>
+ <td class="semantictable"> <p><x,y> is in IEXT(I(<code>rdfs:range</code>))
+ if and only if (if < u,v > is in IEXT(x) then v is in ICEXT(y))</p></td>
+ </tr>
+ <tr>
+ <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:domain</code>))
+ if and only if (if <u,v> is in IEXT(x) then u is in ICEXT(y))</p></td>
+ </tr>
+</table>
+<p>which would guarantee that the subproperty and subclass properties were transitive
+ and reflexive, and would also have further consequences. </p>
+<p class="technote">These stronger conditions would be trivially satisfied when properties are
+ identified with property extensions, classes with class extensions, and <code>rdfs:SubClassOf</code>
+ understood to mean subset, and hence would be satisfied by an <a href="#glossExtensional" class="termref">extensional</a> semantics
+ for RDFS. In some ways the extensional versions provide a simpler semantics,
+ but they require more complex inference rules. The <a href="#glossIntensional" class="termref">intensional</a> semantics described
+ in the main text provides for most common uses of subclass and subproperty assertions,
+ and allows for simpler implementations of a <a href="#glossComplete" class="termref">
+ complete</a> set of RDFS entailment rules, described in <a href="#RDFSRules" class="termref"> ////</a>.</p>
+<h3><a name="literalnote" id="literalnote">4.3 A Note on rdfs:Literal</a> </h3>
+
+ <p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal <em>values</em>. For example, LV does not contain the literal <code>"24"^^xsd:number</code> (although it may contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#number</code>' ) but it does contain the number twenty-four.</p>
+
+ <p>A triple of the form</p>
+
+ <p><code><ex:a> rdf:type rdfs:Literal .</code></p>
+
+ <p>is consistent even though its subject is an IRI rather
+ than a literal. It says that the IRI '<code>ex:a</code>'
+ refers to a literal value, which is quite possible since literal values are things in the universe. It does not, of course, specify exactly which
+ literal value it refers to. Similarly, blank nodes may range over literal values. </p>
+
+
+<h3><a name="rdfs_entailment" id="rdfs_entailment"></a>4.4 RDFS Entailment</h3>
+<p>S <i>rdfs-D-entails</i> E when every <a href="#rdfsinterpdef" class="termref">rdfs-D-interpretation</a>
+ which satisfies every member of S also satisfies E. RDFS entailment is RDFS-{ } entailment, i.e. RDFS-D entailment with an empty D. </p>
+<p> Since every <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a> is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, if S rdfs-D-entails
+ E then S also rdf-D-entails 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> <code>xxx rdf:type rdfs:Resource .</code></p>
+<p>are true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s.</p>
+
+
+<h2><a name="MonSemExt" id="MonSemExt"></a>6. Monotonicity of semantic extensions
+</h2>
+<p>Given a set of RDF graphs, there are various ways in which one can 'add' information
+ to it. Any of the graphs may have some triples added to it; the set of graphs
+ may be extended by extra graphs; or the vocabulary of the graph may be interpreted
+ relative to a stronger notion of <a href="#vocabulary_entail" class="termref">vocabulary entailment</a>, i.e. with a larger set
+ of semantic conditions understood to be imposed on the interpretations. All
+ of these can be thought of as an addition of information, and may make more
+ entailments hold than held before the change. All of these additions are <a href="#glossMonotonic" class="termref"><em>monotonic</em></a>,
+ in the sense that entailments which hold before the addition of information,
+ also hold after it. We can sum up this in a single lemma:</p>
+<p ><strong><a name="GeneralMonotonicityLemma" id="GeneralMonotonicityLemma"></a>General monotonicity lemma</strong>. Suppose
+ that S, S' are sets of RDF graphs with every member of S a subset
+ of some member of S'. Suppose that Y indicates a semantic extension
+ of X, S X-entails E, and S and
+ E satisfy any syntactic restrictions of Y. Then S' Y-entails E.</p>
+
+<p >In particular, if D' is a <a href="#defDatatypeMap" class="termref">datatype map</a>, D a subset of D' and if S <a href="#D_entailment" class="termref"> D-entail</a>s
+ E then S also D'-entails E. </p>
+
+<h2><span ><a name="rules" id="rules"></a></span> Entailment
+ rules (Informative)</h2>
+
+<p class="issue"> The inference rules need to be rewritten using the convention that they apply to a syntactic generalization of RDF that allows literals in subject position. This will take some editorial work to complete but should be easier to understand once it is done. <br/> <br /><strong>Should this be a separate document? Should it be an appendix to this document?</strong> <br/><br/>I do not plan to reproduce the completeness proofs which were in the RDF 2004 document. They were unreadable, intimidating, buggy and unnecessary. </p>
+
+<h2><a name="tutorial" id="tutorial"/>Appendix: Introduction to model theory (Informative)</h2>
+
+<h2><a name="prf" id="prf"/>Appendix: Proofs of Lemmas (Informative)</h2>
+
+<h2><a name="notdo" id="notdo" />Appendix: What the semantics does not do (Informative) </h2>
+
<h3><a name="ReifAndCont" id="ReifAndCont"> Reification, Containers, Collections and rdf:value</a></h3>
-<p class="issue">Should this section, which is informative at best, simply be omitted? It is not really part of the definition of the model theory, more a kind of essay about stuff that is not in the model theory.</p>
-
<dt>
<dd class="greyout">
<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,
- or the reification vocabulary intended to enable an RDF graph to describe RDF triples. In this section we briefly review the intended meanings of this vocabulary. </p>
+ or the reification vocabulary intended to enable an RDF graph to describe RDF triples. In this appendix we briefly review the intended meanings of this vocabulary. </p>
<p>The omission of these conditions from the formal semantics is a design decision
@@ -1234,7 +1543,7 @@
values of the items, in the order got by tracing the <code>rdf:rest</code> properties
from the subject to <code>rdf:nil</code>. This permits sequences which contain
other sequences.</p>
-<p The RDFS semantic conditions, described below, require that any
+<p The RDFS semantic conditions require that any
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>
@@ -1256,360 +1565,8 @@
</dd>
</dt>
-
-<h2><a name="rdfs_interp" id="rdfs_interp">4. Interpreting the RDFS Vocabulary</a></h2>
-
-
-<h3><a name="RDFSINTERP" id="RDFSINTERP">4.1 RDFS Interpretations</a></h3>
-
-<p>RDF Schema [<cite><a href="#ref-rdf-vocabulary">RDF-VOCABULARY</a></cite>]
- extends RDF to include a larger <a id="defRDFSV" name="defRDFSV"></a>vocabulary
- rdfsV with more complex semantic constraints:</p>
-
- <div class="c1">
- <table border="1" summary="RDFS vocabulary">
- <tbody>
- <tr>
- <td class="othertable"><strong>RDFS vocabulary</strong></td>
- </tr>
-
- <tr>
- <td class="othertable"><code>rdfs:domain rdfs:range rdfs:Resource rdfs:Literal
- rdfs:Datatype rdfs:Class rdfs:subClassOf rdfs:subPropertyOf
- rdfs:member rdfs:Container rdfs:ContainerMembershipProperty
- rdfs:comment rdfs:seeAlso rdfs:isDefinedBy
- rdfs:label</code></td>
- </tr>
- </tbody>
- </table>
- </div>
-<p>(<code>rdfs:comment</code>,<code> rdfs:seeAlso</code>, <code>rdfs:isDefinedBy</code>
- and <code>rdfs:label</code> are included here because some constraints which
- 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
- in terms of a new semantic construct, a <a
- href="#glossClass" class="termref"><em>class</em></a>, i.e. a resource which represents
- a set of things in the universe which all have that class as the 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>.
- 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. The meanings of
- ICEXT and IC in a <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>
- of the RDFS vocabulary are completely defined by the first two conditions in
- the table of RDFS semantic conditions, below. A class may have an
- empty class extension. Two different class entities could have the same class extension.
- The class extension of <code>rdfs:Class</code> contains the class <code>rdfs:Class</code>.
-</p>
-
-<p class="technote">The term "class" used here should be distinguished from the usage of "class" in object-oriented programming and modelling. There is no notion of a class "owning" anything (such as a method) in RDFS. An RDF class is simply a way to classify things into a named category. </p>
-
-<p><a id="rdfsinterpdef" name="rdfsinterpdef"></a> An <i>rdfs-interpretation</i> of V is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a> I
- <span >of (V union rdfV union rdfsV) which satisfies the semantic conditions in the following table, and satisfies all the triples in the subsequent table of <em>RDFS axiomatic triples</em>.</p>
-<div class="title">RDFS semantic conditions.</div>
- <table border="1">
- <tr>
-
- <td class="semantictable"> <p><a name="rdfssemcond1" id="rdfssemcond1"></a>ICEXT(y) is defined to be { x : < x,y > is in IEXT(I(<code>rdf:type</code>)) }</p>
- <p>IC is defined to be ICEXT(I(<code>rdfs:Class</code>))</p>
- <p>ICEXT(I(<code>rdfs:Resource</code>)) = IR</p>
- <p >ICEXT(I(<code>rdfs:Literal</code>)) = LV</p></td>
- </tr>
- <tr>
-
- <td class="semantictable"> <p><a name="rdfssemcond2" id="rdfssemcond2"></a>If
- < x,y > is in IEXT(I(<code>rdfs:domain</code>)) and < u,v > is
- in IEXT(x) then u is in ICEXT(y)</p></td>
- </tr>
- <tr>
-
- <td class="semantictable"> <p><a name="rdfssemcond3" id="rdfssemcond3"></a>If
- < x,y > is in IEXT(I(<code>rdfs:range</code>)) and < u,v > is
- in IEXT(x) then v is in ICEXT(y)</p></td>
- </tr>
- <tr>
-
- <td class="semantictable"><p><a name="rdfssemcond4" id="rdfssemcond4"></a>IEXT(I(<code>rdfs:subPropertyOf</code>))
- is transitive and reflexive on IP</p></td>
- </tr>
- <tr>
-
- <td class="semantictable"> <p><a name="rdfssemcond5" id="rdfssemcond5"></a>If
- <x,y> is in IEXT(I(<code>rdfs:subPropertyOf</code>)) then x and
- y are in IP and IEXT(x) is a subset of IEXT(y)</p></td>
- </tr>
- <tr>
-
- <td class="semantictable"><p><a name="rdfssemcond6" id="rdfssemcond6"></a>If
- x is in IC then < x, I(<code>rdfs:Resource</code>) > is in IEXT(I(<code>rdfs:subClassOf</code>))</p></td>
- </tr>
- <tr>
-
- <td class="semantictable"><p><a name="rdfssemcond8" id="rdfssemcond8"></a>IEXT(I(<code>rdfs:subClassOf</code>))
- is transitive and reflexive on IC</p></td>
- </tr>
-
- <td class="semantictable"> <p><a name="rdfssemcond7" id="rdfssemcond7"></a>If
- < x,y > is in IEXT(I(<code>rdfs:subClassOf</code>)) then x and y are
- in IC and ICEXT(x) is a subset of ICEXT(y)</p></td>
- </tr>
- <tr>
-
-
- <tr>
- <td class="semantictable"><p><a name="rdfssemcond9" id="rdfssemcond9"></a>If
- x is in ICEXT(I(<code>rdfs:ContainerMembershipProperty</code>)) then:<br />
- < x, I(<code>rdfs:member</code>) > is in IEXT(I(<code>rdfs:subPropertyOf</code>))<br />
- </p></td>
- </tr>
- <tr>
-
- <td class="semantictable"><p><a name="rdfssemcond10" id="rdfssemcond10"></a>If
- x is in ICEXT(I(<code>rdfs:Datatype</code>)) then <span >< x,
- I(<code>rdfs:Literal</code>) > is in IEXT(I(<code>rdfs:subClassOf</code>))</span></p></td>
- </tr>
- </table>
-<p></p>
-<p></p>
-<p class="technote"> Several of the conditions in the above table can be understood as inference rules on RDF triples. For example,
- the fifth condition could be stated as the rule: <em>if <code>xxx rdfs:domain yyy .</code> and <code>uuu xxx vvv .</code> then <code>uuu rdf:type yyy .</code></em>. However, this would not guarantee that un-named elements of the universe would satisfy these basic semantic conditions, which is necessary to ensure that these inference patterns are correct even when blank nodes are present. That is why the conditions are stated here in semantic terms directly, rather than as inference-rule patterns. Complete systems of such rules are given in ////.</p>
-
-
-
- <p><a id="RDFS_axiomatic_triples" name="RDFS_axiomatic_triples"> </a>
- </p>
- <div class="title">RDFS axiomatic triples.</div>
- <table border="1" summary="RDFS axioms">
-
- <tr>
-
-
- <td class="ruletable"> <code>rdf:type rdfs:domain rdfs:Resource .<br />
- rdfs:domain rdfs:domain rdf:Property .<br />
- rdfs:range rdfs:domain rdf:Property .<br />
- rdfs:subPropertyOf rdfs:domain rdf:Property .<br />
- <a name="axtripleforproof1" id="axtripleforproof1"></a>rdfs:subClassOf rdfs:domain
- rdfs:Class .<br />
- rdf:subject rdfs:domain rdf:Statement .<br />
- rdf:predicate rdfs:domain rdf:Statement .<br />
- rdf:object rdfs:domain rdf:Statement .<br />
- rdfs:member rdfs:domain rdfs:Resource . <br />
- rdf:first rdfs:domain rdf:List .<br />
- rdf:rest rdfs:domain rdf:List .<br />
- rdfs:seeAlso rdfs:domain rdfs:Resource .<br />
- rdfs:isDefinedBy rdfs:domain rdfs:Resource .<br />
- rdfs:comment rdfs:domain rdfs:Resource .<br />
- rdfs:label rdfs:domain rdfs:Resource .<br />
- rdf:value rdfs:domain rdfs:Resource .<br />
- <br />
- rdf:type rdfs:range rdfs:Class .<br />
- rdfs:domain rdfs:range rdfs:Class .<br />
- rdfs:range rdfs:range rdfs:Class .<br />
- rdfs:subPropertyOf rdfs:range rdf:Property .<br />
- <a name="axtripleforproof2" id="axtripleforproof2"></a>rdfs:subClassOf rdfs:range
- rdfs:Class .<br />
- rdf:subject rdfs:range rdfs:Resource .<br />
- rdf:predicate rdfs:range rdfs:Resource .<br />
- rdf:object rdfs:range rdfs:Resource .<br />
- rdfs:member rdfs:range rdfs:Resource .<br />
- rdf:first rdfs:range rdfs:Resource .<br />
- rdf:rest rdfs:range rdf:List .<br />
- rdfs:seeAlso rdfs:range rdfs:Resource .<br />
- rdfs:isDefinedBy rdfs:range rdfs:Resource .<br />
- rdfs:comment rdfs:range rdfs:Literal .<br />
- rdfs:label rdfs:range rdfs:Literal .<br />
- rdf:value rdfs:range rdfs:Resource .<br />
- <br />
- rdf:Alt rdfs:subClassOf rdfs:Container .<br />
- rdf:Bag rdfs:subClassOf rdfs:Container .<br />
- rdf:Seq rdfs:subClassOf rdfs:Container .<br />
- rdfs:ContainerMembershipProperty rdfs:subClassOf rdf:Property .<br />
- <br />
- rdfs:isDefinedBy rdfs:subPropertyOf rdfs:seeAlso .<br />
- <br />
- rdf:XMLLiteral rdf:type rdfs:Datatype .<br />
- rdf:XMLLiteral rdfs:subClassOf rdfs:Literal . <br />
- rdf:HTML rdf:type rdfs:Datatype .<br />
- rdf:HTML rdfs:subClassOf rdfs:Literal . <br />
- xsd:string rdf:type rdfs:Datatype .<br />
- xsd:string rdfs:subClassOf rdfs:Literal . <br />
- rdf:langString rdf:type rdfs:Datatype .<br />
- rdf:langString rdfs:subClassOf rdfs:Literal . <br />
-
-
-<br />
- rdfs:Datatype rdfs:subClassOf rdfs:Class .<br />
- <br />
- rdf:_1 rdf:type rdfs:ContainerMembershipProperty .<br />
- <span >rdf:_1 rdfs:domain rdfs:Resource .<br />
- rdf:_1 rdfs:range rdfs:Resource .</span> <br />
- rdf:_2 rdf:type rdfs:ContainerMembershipProperty .<br />
- rdf:_2 rdfs:domain rdfs:Resource .<br />
- rdf:_2 rdfs:range rdfs:Resource . <br />
- ...</code> </td>
- </tr>
-
- </table>
-<p><span >Since I is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, the first condition implies that IP
- = ICEXT(I(<code>rdf:Property</code>)).</span></p>
-
-<p class="issue">Is rdf:langString an rdfs:Datatype? </p>
-
-<p>These axioms and conditions have some redundancy. For example, all but one
- of the RDF axiomatic triples can be derived from the RDFS axiomatic triples
- and the semantic conditions on ICEXT,<code> rdfs:domain</code> and <code>rdfs:range</code>.
- Other triples which must be true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s
- include the following:</p>
- <div class="title">Some rdfs-valid triples.</div>
-<table border="1">
- <tr>
- <td class="ruletable"><code>rdfs:Resource rdf:type rdfs:Class .<br />
- rdfs:Class rdf:type rdfs:Class .<br />
- rdfs:Literal rdf:type rdfs:Class .<br />
- rdf:XMLLiteral rdf:type rdfs:Class .<br />
-rdf:HTML rdf:type rdfs:Class .<br />
- rdfs:Datatype rdf:type rdfs:Class .<br />
- rdf:Seq rdf:type rdfs:Class .<br />
- rdf:Bag rdf:type rdfs:Class .<br />
- rdf:Alt rdf:type rdfs:Class .<br />
- rdfs:Container rdf:type rdfs:Class .<br />
- rdf:List rdf:type rdfs:Class .<br />
- rdfs:ContainerMembershipProperty rdf:type rdfs:Class .<br />
- rdf:Property rdf:type rdfs:Class .<br />
- rdf:Statement rdf:type rdfs:Class .<br />
- <br />
- rdfs:domain rdf:type rdf:Property .<br />
- rdfs:range rdf:type rdf:Property .<br />
- rdfs:subPropertyOf rdf:type rdf:Property .<br />
- rdfs:subClassOf rdf:type rdf:Property .<br />
- rdfs:member rdf:type rdf:Property .<br />
- rdfs:seeAlso rdf:type rdf:Property .<br />
- rdfs:isDefinedBy rdf:type rdf:Property .<br />
- rdfs:comment rdf:type rdf:Property .<br />
- rdfs:label rdf:type rdf:Property .<br />
- </code><code></code></td>
- </tr>
-</table>
-
-<p class="technote">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>
-<p><br />
- RDFS allows <a href="#defDatatype" class="termref">datatype</a>s to
- have class extensions, so they are considered to be classes. The members of a datatype class are the datatype values which are in the range of the datatype L2V mapping: ICEXT(I(ddd)) = { x : x = L2V(I(ddd))(sss) } for some string sss, when ddd is a recognized datatype IRI.
-
-</p>
-<h3><a name="ExtensionalDomRang" id="ExtensionalDomRang"></a>4.2 Extensional Semantic
- Conditions (Informative)</h3>
-<p>The semantics given above is deliberately chosen to be the weakest 'reasonable'
- interpretation of the RDFS vocabulary. Semantic extensions <strong title="MAY in RFC 2119 context" class="RFC2119">MAY</strong>
- strengthen the range, domain, subclass and subproperty semantic conditions to
- the following '<a class="termref" href="#glossExtensional">extensional</a>'
- versions:</p>
- <div class="title">Extensional alternatives for some RDFS semantic conditions.</div>
-<table summary="range and domain extension conditions" border="1">
- <tr>
- <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:subClassOf</code>))
- if and only if x and y are in IC and ICEXT(x) is a subset of ICEXT(y)</p></td>
- </tr>
- <tr>
- <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:subPropertyOf</code>))
- if and only if x and y are in IP and IEXT(x) is a subset of IEXT(y)</p></td>
- </tr>
- <tr>
- <td class="semantictable"> <p><x,y> is in IEXT(I(<code>rdfs:range</code>))
- if and only if (if < u,v > is in IEXT(x) then v is in ICEXT(y))</p></td>
- </tr>
- <tr>
- <td class="semantictable"> <p>< x,y > is in IEXT(I(<code>rdfs:domain</code>))
- if and only if (if <u,v> is in IEXT(x) then u is in ICEXT(y))</p></td>
- </tr>
-</table>
-<p>which would guarantee that the subproperty and subclass properties were transitive
- and reflexive, and would also have further consequences. </p>
-<p class="technote">These stronger conditions would be trivially satisfied when properties are
- identified with property extensions, classes with class extensions, and <code>rdfs:SubClassOf</code>
- understood to mean subset, and hence would be satisfied by an <a href="#glossExtensional" class="termref">extensional</a> semantics
- for RDFS. In some ways the extensional versions provide a simpler semantics,
- but they require more complex inference rules. The <a href="#glossIntensional" class="termref">intensional</a> semantics described
- in the main text provides for most common uses of subclass and subproperty assertions,
- and allows for simpler implementations of a <a href="#glossComplete" class="termref">
- complete</a> set of RDFS entailment rules, described in <a href="#RDFSRules" class="termref"> ////</a>.</p>
-<h3><a name="literalnote" id="literalnote">4.3 A Note on rdfs:Literal</a> </h3>
-
- <p>The class <code>rdfs:Literal</code> is not the class of literals, but rather that of literal <em>values</em>. For example, if the vocabulary contains the literal <code>"24"^^xsd:number</code>, then LV does not contain this literal (although it may contain the string '<code>"24"^^http://www.w3.org/2001/XMLSchema#number</code>' ) but it does contain the number twenty-four.</p>
-
- <p>A triple of the form</p>
-
- <p><code><ex:a> rdf:type rdfs:Literal .</code></p>
-
- <p>is consistent even though its subject is an IRI rather
- than a literal. It says that the IRI '<code>ex:a</code>'
- refers to a literal value, which is quite possible since literal values are things in the universe. It does not, of course, specify exactly which
- literal value it refers to. Similarly, blank nodes may range over literal values. </p>
-
-
-<h3><a name="rdfs_entailment" id="rdfs_entailment"></a>4.4 RDFS Entailment</h3>
-<p>S <i>rdfs-entails</i> E when every <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>
- which satisfies every member of S also satisfies E. This follows the wording
- of the definition of <a href="#defentail" class="termref">simple entailment</a>
- in <a href="#entail" class="termref"> Section 2</a>, but refers only to <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s
- instead of all simple interpretations. <span >Rdfs-entailment is an example
- of <a href="#vocabulary_entail" class="termref">vocabulary entailment</a>.</span>
-</p>
-<p> Since every <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a> is an <a href="#rdfinterpdef" class="termref">rdf-interpretation</a>, if S rdfs-entails
- E then it rdf-entails 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> <code>xxx rdf:type rdfs:Resource .</code></p>
-<p>are true in all <a href="#rdfsinterpdef" class="termref">rdfs-interpretation</a>s
- of any vocabulary containing the IRI <code>xxx</code>.</p>
-
-
-<h3><a name="RDFSdtype_interp" id="RDFSdtype_interp">RDFS with datatypes</a></h3>
-
- <p >As noted above, it is
- possible that a graph which is consistent in one vocabulary becomes inconsistent
- in a semantic extension defined on a larger vocabulary, and <a href="#defDinterp" class="termref">D-interpretation</a>s
- allow for inconsistencies in an RDF graph. The definition of <a href="#vocabulary_entail" class="termref">vocabulary entailment</a>
- means that an inconsistent graph will entail <em>any</em> graph in the stronger
- vocabulary entailment. For example, a D-inconsistent graph <a href="#D_entailment" class="termref"> D-entail</a>s any RDF
- graph. However, it will usually not be appropriate to consider such 'trivial'
- entailments as useful consequences, since they may not be <a href="#glossValid"
- class="termref">valid</a> entailments in a smaller vocabulary. </p>
-<h2><a name="MonSemExt" id="MonSemExt"></a>6. Monotonicity of semantic extensions
-</h2>
-<p>Given a set of RDF graphs, there are various ways in which one can 'add' information
- to it. Any of the graphs may have some triples added to it; the set of graphs
- may be extended by extra graphs; or the vocabulary of the graph may be interpreted
- relative to a stronger notion of <a href="#vocabulary_entail" class="termref">vocabulary entailment</a>, i.e. with a larger set
- of semantic conditions understood to be imposed on the interpretations. All
- of these can be thought of as an addition of information, and may make more
- entailments hold than held before the change. All of these additions are <a href="#glossMonotonic" class="termref"><em>monotonic</em></a>,
- in the sense that entailments which hold before the addition of information,
- also hold after it. We can sum up this in a single lemma:</p>
-<p ><strong><a name="GeneralMonotonicityLemma" id="GeneralMonotonicityLemma"></a>General monotonicity lemma</strong>. Suppose
- that S, S' are sets of RDF graphs with every member of S a subset
- of some member of S'. Suppose that Y indicates a semantic extension
- of X, S X-entails E, and S and
- E satisfy any syntactic restrictions of Y. Then S' Y-entails E.</p>
-
-<p >In particular, if D' is a <a href="#defDatatypeMap" class="termref">datatype map</a>, D a subset of D' and if S <a href="#D_entailment" class="termref"> D-entail</a>s
- E then S also D'-entails E. </p>
-
-<h2><span ><a name="rules" id="rules"></a></span> Entailment
- rules (Informative)</h2>
-
-<p class="issue"> The inference rules need to be rewritten using the convention that they apply to a syntactic generalization of RDF that allows literals in subject position. This will take some editorial work to complete but should be easier to understand once it is done. <br/> <br /><strong>Should this be a separate document? Should it be an appendix to this document?</strong> <br/><br/>I do not plan to reproduce the completeness proofs which were in the RDF 2004 document. They were unreadable, intimidating, buggy and unnecessary. </p>
-
-<h2><a name="prf" id="prf">Appendix: Proofs of Lemmas (Informative)</a></h2>
-
-<h2><a name="tutorial" id="tutorial">Appendix: Idiot's Guide to model theory (Informative)</h2>
-
-
-<h2><a name="gloss" id="gloss"></a>Appendix: Glossary of Terms (Informative)</h2>
-
-<p class="issue">This whole glossary should probably be made part of the Idiot's Guide. </p>
+<h2><a name="gloss" id="gloss"/>Appendix: Glossary of Terms (Informative)</h2>
<p><strong><a name="glossAntecedent"
id="glossAntecedent"></a>Antecedent</strong> (n.) In an <a
@@ -1938,6 +1895,8 @@
<h2><a name="ack" id="ack"></a>Appendix C: Acknowledgements</h2>
+
+<p class="issue">From here on is left over from the 2004 document and needs rewriting.</p>
<p>This document reflects the joint effort of the members of the <a
href="http://www.w3.org/2001/sw/RDFCore/">RDF Core Working Group</a>. Particular
contributions were made by Jeremy Carroll, Dan Connolly, Jan Grant, R. V. Guha,