--- a/rdf-mt/index.html Thu Mar 07 12:07:25 2013 -0600
+++ b/rdf-mt/index.html Fri Mar 08 20:15:50 2013 -0600
@@ -1,35 +1,17 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
-
-<html dir="ltr" about="" property="dcterms:language" content="en" xmlns="http://www.w3.org/1999/xhtml" prefix="bibo: http://purl.org/ontology/bibo/" typeof="bibo:Document">
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<!-- saved from url=(0053)http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/ -->
+<html dir="ltr" about="" property="dcterms:language" content="en" xmlns="http://www.w3.org/1999/xhtml" prefix="bibo: http://purl.org/ontology/bibo/" typeof="bibo:Document"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>RDF 1.1 Semantics Editors Draft</title>
<style type="text/css">
.figure { text-align: center; }
.figure a[href]:hover { background: transparent; }
table td, table th { border: 1px solid #ddd; padding: 0.2em 0.5em; }
-font-family: sans-serif
-/*<![CDATA[*/
-code {font-family: monospace }
- a.termref:visited, a.termref:link {font-family: sans-serif;
- font-style: normal;
- color: black;
- text-decoration: none }
-a.termref:link:hover {background-color: #ffffaa }
-.RFC2119 { font-size: small; font-weight: bolder; }
-.oldstuff {color: red; background-color: #DDFFDD }
-.newstuff { }
-.newerstuff { }
-.changetable {background-color: #FFCCFF}
-.semantictable {background-color: #FFFFAA}
-.notetable {background-color: #BBBBFF}
-.ruletable {background-color: #FAFAFF}
-.othertable {background-color: #FDFDFD}
-.greyout {background-color: #CCCCCC}
- /*]]>*/
-
+ </style>
+
+
+ <style type="text/css">
/*****************************************************************
* ReSpec CSS
* Robin Berjon (robin at berjon dot com)
@@ -393,7 +375,7 @@
padding: 3px 1em;
}
.technote {
- margin: 1em 0em 0em;
+ margin: 1em 3em 0em;
padding: 1em;
border: 1px solid #F00;
background: #ccccff;
@@ -539,7 +521,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-03-07T00:00:00+0000" id="w3c-working-draft-7-March-2013"> Editor's Working Draft 7 March 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-03-08T00:00:00+0000" id="w3c-working-draft-7-March-2013"> Editor's Working Draft 8 March 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="http://www.nuance.com/">Nuance Communications</a></span>
@@ -576,7 +558,9 @@
<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 <em>rdfs-entailment</em>, <em>owl-entailment</em>, etc.. </p>
-<p>Semantic extensions <strong class="RFC2119">MAY</strong> 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 <strong class="RFC2119">MAY</strong> consider RDF graphs which do not conform to these conditions to be syntax errors. ///Give OWL-DLexample///. 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.</p><p> None of the semantic extensions normatively defined in this document impose syntactic restrictions on RDF graphs.</p>
+<p>Semantic extensions <strong class="RFC2119">MAY</strong> 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 <strong class="RFC2119">MAY</strong> consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br />
+<code>:a rdfs:subClassOf owl:Thing .</code><br />
+are prohibited in the OWL-DL semantic extension. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions.</p><p> None of the semantic extensions normatively defined in this document impose syntactic restrictions on RDF graphs.</p>
<p>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, provided of course that any syntactic conditions of the extension are also satisfied. Put another way, a semantic extension cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
@@ -671,8 +655,17 @@
<p >is <a
href="#deflean" class="termref">lean</a>. </p>
+<p>Blank nodes in RDF graphs are restricted to a single <em>scope</em> of blank node identifiers. Each blank node can occur in only one scope. The same blank node identifier used in a several scopes identifies a different blank node in each scope in which it occurs. Scopes are defined by the surface syntax used to encode RDF. For example, in RDF/XML and NTriples, the scope is defined by the document. In TriG, a syntax for RDF datastores, the scope is the entire datastore. Two graphs not in the same scope do not share any blank nodes.</p>
+<p>The set of all triples in a given scope is an RDF graph, called a <em>scoped graph</em>. (The scoped graph may be an abstraction, e.g. for a dataset it is the set of all triples which occur in any graph in the dataset, which may not be represented explicitly in the dataset itself.) Every RDF graph must be a subgraph of a scoped graph. </p>
+<p>An RDF graph is <em>complete</em> when, for every blank node in the graph, the graph contains all triples in the scoped graph which contain that blank node. That is, for every blank node in the scope, the graph either does not contain the blank node, or else it contains all triples in the scoped graph which contain that blank node. Scoped graphs and ground graphs are always complete. Incomplete graphs may fail to give enough information to reconstruct the information contained in their union.</p>
+
+<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 of the 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, and treating this as the scoped graph of a single blank node scope. 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. (We may describe this as "making a copy" of the triples in the original graphs, when the new scope is distinct from the scopes containing 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 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 blank node identifiers 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. Since 2004, in subsequent practice, the term "RDF graph" is widely used to mean what is here defined as a scoped graph. </p>
+
+<p class="issue">The Concepts document does not yet define blank node scopes.</p>
<h2><a id="sinterp" name="sinterp"> Simple Interpretations</a> </h2>
@@ -755,7 +748,7 @@
<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>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. Two graphs not in the same blank node scope do not share any blank nodes.</p>
+<p>The semantics of blank nodes is defined as a condition on all RDF triples in a single blank node scope. 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. Two graphs not in the same blank node scope do not share any blank nodes.</p>
<p class="issue">The Concepts document does not yet define blank node scopes.</p>
@@ -816,16 +809,22 @@
<p><a name="instlem" id="instlem"><strong>Instance Lemma.</strong></a> A graph
is entailed by any of its <a
href="#definst" class="termref">instances</a>.<a href="#instlemprf" class="termref"> [Proof]</a></p>
-<p >The relationship between merging and entailment is simple,
- and obvious from the definitions:</p>
+
<p><a name="mergelem" id="mergelem"><strong>Merging lemma.</strong></a> The merge
- of a set S of RDF graphs is entailed by S, and entails every member of S. <a href="#mergelemprf" class="termref">[Proof]</a></p>
+ of a set S of complete RDF graphs is entailed by S, and entails every member of S. <a href="#mergelemprf" class="termref">[Proof]</a></p>
- <p>This means that a set of graphs can be treated as <a
+<p>The merging lemma does not hold for incomplete graphs. For example, consider the graph</p>
+<p>
+<code>:a :p _:x . <br/>
+:b :p _:x .</code></p>
+<p>and let S be the set of its singleton subgraphs. Treated in isolation, these can be satisfied by an interpretation which does not satisfy their union, e.g. one with <br />IEXT(I(<code>:p</code>)) = {< I(<code>:a</code>),I(<code>:a</code>) >, < I(<code>:b</code>),I(<code>:b</code>) > }. This is because the mapping <code>_:x</code>/I(<code>:a</code>) works for the first triple considered in isolation, and the mapping <code>_:x</code>/I(<code>:b</code>) for the second triple considered in isolation, but there is no mapping which works for the combination. The incompleteness of the subgraphs means that neither is obliged to consider the full set of constraints on the blank node that are represented by their union. </p>
+
+
+ <p>This means that a set of complete graphs can be treated as <a
href="#glossEquivalent" class="termref">equivalent</a> to its
merge, a single graph, as far as the <a
href="#glossModeltheory" class="termref">model theory</a> is
- concerned. In general, we will not usually bother to distinguish between a set of graphs and the single graph formed by merging them. </p>
+ concerned. In general, we will not usually bother to distinguish between a set of complete graphs and the single graph formed by merging them. </p>
<p>The main result for simple entailment is:</p>
<p><a name="interplemma" id="interplemma"><strong>Interpolation Lemma.</strong>
S entails a graph E if and only if a subgraph of S is an instance of E. </a><a href="#interplemmaprf" class="termref">[Proof]</a></p>
@@ -847,12 +846,6 @@
If S entails E and E is a finite graph, then some finite subset S' of S entails
E. <a href="#compactlemmaprf" class="termref"> [Proof]</a></p>
-<h3>Merging Graphs</h3>
-
-<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 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>Skolemization</h3>