--- a/rdf-mt/index.html Tue Feb 12 11:48:00 2013 -0600
+++ b/rdf-mt/index.html Thu Feb 14 14:40:33 2013 -0600
@@ -28,9 +28,6 @@
.othertable {background-color: #FDFDFD}
.greyout {background-color: #CCCCCC}
-</style>
-<style type="text/css">
-
/*****************************************************************
* ReSpec CSS
* Robin Berjon (robin at berjon dot com)
@@ -660,7 +657,7 @@
<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>
@@ -674,13 +671,18 @@
<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, so their presence does not affect any entailments. </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 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 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.</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>
@@ -688,10 +690,11 @@
<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. 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>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>
+<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>. 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>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 class="issue">The Concepts document does not yet define blank node scopes.</p>
@@ -741,10 +744,12 @@
<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>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>
<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