--- a/rdf-mt/index.html Sun May 26 16:38:45 2013 -0500
+++ b/rdf-mt/index.html Wed May 29 12:47:42 2013 -0500
@@ -141,7 +141,7 @@
<body>
<section id='abstract'>
<p> This document describes a precise semantics for the Resource Description
- Framework 1.1 [[RDF-PRIMER]] and RDF Schema [[RDF-SCHEMA]]. It defines a number of distinct entailment regimes and corresponding systems of inference rules. It is part of a suite of documents which comprise the full specification of RDF 1.1.</p>
+ Framework 1.1 [[RDF11-CONCEPTS]] and RDF Schema [[RDF-SCHEMA]]. It defines a number of distinct entailment regimes and corresponding patterns of entailment. It is part of a suite of documents which comprise the full specification of RDF 1.1.</p>
</section>
<section id='sotd'>
@@ -162,12 +162,12 @@
<section>
<h2 id="extensions">Semantic extensions and entailment regimes</h2>
- <p>RDF is intended for use as a base notation for a variety of extended notations such as OWL [[OWL2-OVERVIEW]] and RIF [[RIF-OVERVIEW]], whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. Also, particular IRI vocabularies may be given meanings. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more entailments follow from those assumptions. </p>
+ <p>RDF is intended for use as a base notation for a variety of extended notations such as OWL [[OWL2-OVERVIEW]] and RIF [[RIF-OVERVIEW]], whose expressions can be encoded as RDF graphs which use a particular vocabulary with a specially defined meaning. Also, particular IRI vocabularies may be given meanings by other specifications or conventions. When such extra meanings are assumed, a given RDF graph may support more extensive entailments than are sanctioned by the basic RDF semantics. In general, the more assumptions that are made about the meanings of IRIs in an RDF graph, the more entailments follow from those assumptions. </p>
<p>A particular such set of semantic assumptions is called a <dfn>semantic extension</dfn>. Each <a>semantic extension</a> defines an <dfn>entailment regime</dfn> of entailments which are valid under that extension. RDFS, described later in this document, is one such <a>semantic extension</a>. We will refer to an entailment regime by names such as <em> RDFS entailment</em>, <em>D-entailment</em>, etc. </p>
-<p><a>semantic extension</a>s MAY impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and MAY consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br/>
-<code>ex:a rdfs:subClassOf owl:Thing .</code><br/>
+<p><a>Semantic extension</a>s MAY impose special syntactic conditions or restrictions upon RDF graphs, such as requiring certain triples to be present, or prohibiting particular combinations of IRIs in triples, and MAY consider RDF graphs which do not conform to these conditions to be errors. For example, RDF statements of the form <br/><br/>
+<code>ex:a rdfs:subClassOf owl:Thing .</code><br/><br/>
are prohibited in the OWL-DL [[OWL2-SYNTAX]] <a>semantic extension</a>. In such cases, basic RDF operations such as taking a subset of triples, or merging RDF graphs, may cause syntax errors in parsers which recognize the extension conditions. None of the <a>semantic extension</a>s normatively defined in this document impose such syntactic restrictions on RDF graphs.</p>
<p>All entailment regimes MUST be <a>monotonic</a> extensions of the simple entailment regime described in the document, in the sense that if A <a>simply entails</a> B then A also entails B under any extended notion of entailment, provided that any syntactic conditions of the extension are also satisfied. Put another way, a <a>semantic extension</a> cannot "cancel" an entailment made by a weaker entailment regime, although it can treat the result as a syntax error.</p>
@@ -177,14 +177,14 @@
<h2 id="notation">Notation and terminology</h2>
- <p>This document uses the following terminology for describing RDF graph syntax, all as defined in the companion RDF Concepts specification [[!RDF11-CONCEPTS]]: <em>IRI</em>, <em><a class="externalDFN">RDF triple</a>, <a class="externalDFN">RDF graph</a>, <a class="externalDFN">subject</a>, <a class="externalDFN">predicate</a>, <a class="externalDFN">object</a>, <a class="externalDFN">RDF source</a>, <a class="externalDFN">node</a>, <a class="externalDFN">RDF term</a>, <a class="externalDFN">blank node</a>, <a class="externalDFN">literal</a>, <a class="externalDFN">isomorphic</a>.</em></p>
+ <p>This document uses the following terminology for describing RDF graph syntax, all as defined in the companion RDF Concepts specification [[!RDF11-CONCEPTS]]: <em>IRI</em>, <em><a class="externalDFN">RDF triple</a>, <a class="externalDFN">RDF graph</a>, <a class="externalDFN">subject</a>, <a class="externalDFN">predicate</a>, <a class="externalDFN">object</a>, <a class="externalDFN">RDF source</a>, <a class="externalDFN">node</a>, <a class="externalDFN">blank node</a>, <a class="externalDFN">literal</a>, <a class="externalDFN">isomorphic</a>.</em></p>
<p>We use the words <dfn>denotes</dfn> and <dfn>refers to</dfn> interchangeably as synonyms for the relationship between an IRI or literal and what it refers to in a given interpretation, itself called the <dfn>referent</dfn> or <dfn>denotation</dfn>. IRI meanings may also be determined by other constraints external to the RDF semantics; when we wish to refer to such an externally defined naming relationship, we will use the word <dfn>identify</dfn> and its cognates. For example, the fact that the IRI <code>http://www.w3.org/2001/XMLSchema#decimal</code> is widely used as the name of a datatype described in the XML Schema document [[XMLSCHEMA11-2]] might be described by saying that the IRI <em>identifies</em> that datatype. If an IRI identifies something it may or may not refer to it in a given interpretation, depending on how the semantics is specified. For example, an IRI used as a graph name <a>identify</a>ing a named graph in an <a class="external">RDF dataset</a> may refer to something different from the graph it identifies. </p>
<p>Throughout this document, the equality sign = indicates strict identity. The statement "A = B" means that there is one entity to which both expressions "A" and "B" refer. Angle brackets < x, y > are used to indicate an ordered pair
of x and y.</p>
-<p>Throughout this document, RDF graphs and other fragments of RDF abstract syntax are written using the notational conventions of the Turtle syntax [[!TURTLE-TR]]. The namespace prefixes <code>rdf:</code> <code>rdfs:</code> and <code>xsd:</code> are used as in [[!RDF11-CONCEPTS]], section 1.4. When the exact IRI does not matter. the prefix <code>ex:</code> is used. When stating general rules or conditions we use three-character variables such as aaa, xxx, sss to indicate arbitrary IRIs, literals, or other components of RDF syntax. </p>
+<p>Throughout this document, RDF graphs and other fragments of RDF abstract syntax are written using the notational conventions of the Turtle syntax [[!TURTLE-TR]]. The namespace prefixes <code>rdf:</code> <code>rdfs:</code> and <code>xsd:</code> are used as in [[!RDF11-CONCEPTS]], section 1.4. When the exact IRI does not matter, prefix <code>ex:</code> is used. When stating general rules or conditions we use three-character variables such as aaa, xxx, sss to indicate arbitrary IRIs, literals, or other components of RDF syntax. </p>
<p>A <dfn>name</dfn> is any IRI or literal. A typed literal contains
two <a>name</a>s: itself and its internal type
@@ -238,7 +238,7 @@
<p >is not lean, but</p>
<p ><code>ex:a ex:p _:x .<br/>
_:x ex:p _:x .</code></p>
-<p >is lean. Ground graphs are lean. </p>
+<p >is lean. <a>Ground</a> graphs are lean. </p>
</section>
@@ -247,6 +247,8 @@
<p>This section defines the basic notions of interpretation and truth for RDF graphs. All <a>semantic extension</a>s of any vocabulary or higher-level notation encoded in RDF MUST conform to these minimal truth conditions. Other <a>semantic extension</a>s may extend and add to these, but they MUST NOT modify or negate them. For example, because interpretations are mappings which apply to IRIs, a <a>semantic extension</a> cannot interpret different occurrences of a single IRI differently.</p>
+<p>The entire semantics applies to <a>RDF graph</a>s, not to <a>RDF source</a>s. An <a>RDF source</a> has a semantic meaning only through the graph that is its value at a given time, or in a given state. Graphs cannot change their semantics with time.</p>
+
<p>A <dfn>simple interpretation</dfn> I is a structure consisting of:</p>
@@ -283,7 +285,7 @@
<p>The denotation of a ground RDF graph in I is then given by the following
- rules</p>
+ rules, where an interpretation is treated as a function from expressions (names, triples and graphs) to semantic values:</p>
<div class="tabletitle">Semantic conditions for ground graphs.</div>
@@ -304,7 +306,7 @@
then I(E) = true if </p>
<p>I(p) is in IP and the pair <I(s),I(o)>
is in IEXT(I(p))</p>
- <p>otherwise I(E)= false.</p></td>
+ <p>otherwise I(E) = false.</p></td>
</tr>
<tr>
@@ -325,7 +327,7 @@
<h3 id="blank_nodes">Blank Nodes</h3>
-<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to <a>identify</a> any particular thing. This is not the same as assuming that the blank node indicates an 'unknown' IRI. Blank node identifiers play a similar role to existentially quantified variables in a conventional logical notation; they are local to the document in which they occur.
+<p>Blank nodes are treated as simply indicating the existence of a thing, without using an IRI to <a>identify</a> any particular thing. This is not the same as assuming that the blank node indicates an 'unknown' IRI.
</p>
<p> Suppose I is an interpretation and A is a mapping from a set of blank nodes to the universe IR of I. Define the mapping [I+A] to be I on <a>name</a>s, and A on blank nodes on the set: [I+A](x)=I(x) when x is a <a>name</a> and [I+A](x)=A(x) when x is a blank node; and extend this mapping to triples and RDF graphs using the rules given above for ground graphs. Then the semantic conditions for an RDF graph are:</p>
@@ -367,9 +369,9 @@
some other graph(s) S is (simply) <dfn>valid</dfn> if S
simply entails E in every case, otherwise <dfn>invalid.</dfn></a></p>
-<p>The fact that an inference is valid should not be understood as meaning that any RDF application is obliged or required to make the inference. Similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations on RDF graphs or sources. Entailment and validity are concerned solely with establishing the conditions on such operations which guarantee the preservation of truth. While logically invalid processes, which do not follow valid entailments, are not prohibited, users should be aware that they may be at risk of introducing falsehoods and errors into otherwise correct RDF data. Nevertheless, particular uses of logically invalid processes may be justified and appropriate for data processing under circumstances where truth can be ensured by other means. </p>
+<p>The fact that an inference is valid should not be understood as meaning that any RDF application is obliged or required to make the inference. Similarly, the logical invalidity of some RDF transformation or process does not mean that the process is incorrect or prohibited. Nothing in this specification requires or prohibits any particular operations on RDF graphs or sources. Entailment and validity are concerned solely with establishing the conditions on such operations which guarantee the preservation of truth. While logically invalid processes, which do not follow valid entailments, are not prohibited, users should be aware that they may be at risk of introducing falsehoods into true 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 !-TESTCASES]] which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest simply entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF <a>semantic extension</a>. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
+<p>Entailment refers only to the truth of RDF graphs, not to their suitability for any other purpose. It is possible for an RDF graph to be fitted for a given purpose and yet validly entail another graph which is not appropriate for the same purpose. An example is the RDF test cases manifest [[RDF-TESTCASES]] which is provided as an RDF document for user convenience. This document lists examples of correct entailments by describing their antecedents and conclusions. Considered as an RDF graph, the manifest simply entails a subgraph which omits the antecedents, and would therefore be incorrect if used as a test case manifest. This is not a violation of the RDF semantic rules, but it shows that the property of <em> "being a correct RDF test case manifest"</em> is not preserved under RDF entailment, and therefore cannot be described as an RDF <a>semantic extension</a>. Such entailment-risky uses of RDF should be restricted to cases, as here, where it is obvious to all parties what the intended special restrictions on entailment are, in contrast with the more normal case of using RDF for the open publication of data on the Web.</p>
@@ -420,8 +422,7 @@
If S entails a finite graph E, then some finite subset S' of S entails E.
<!-- <a href="#compactlemmaprf" class="termref"> [Proof]</a> -->
</p>
-<p>
-This property is often called <em>compactness</em>. RDF is compact. As RDF graphs can be infinite, this is sometimes important.</p>
+<p>The property described here is called <em>compactness</em>. RDF is compact. As RDF graphs can be infinite, this is sometimes important.</p>
<p class="fact"> If E contains an IRI which does not occur anywhere in S, then S does not entail E.</p>
@@ -483,7 +484,7 @@
<p>Literals with <code>rdf:langString</code> as their datatype are an exceptional case which are given a special treatment. The IRI <code>rdf:langString</code> is classified as a datatype IRI, and interpreted to refer to a datatype, even though no L2V mapping is defined for it. The value space of <code>rdf:langString</code> is the set of all pairs of a string with a language tag. The semantics of literals with this as their type are given below. </p>
-<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it is not <a>recognize</a>d as referring to a datatype. Literals with such an "unknown" datatype IRI, which is not in the set of <a>recognize</a>d datatypes, MUST NOT be treated as errors, although RDF applications MAY issue a warning. Such literals SHOULD be treated like IRIs and assumed to denote some thing in the universe IR. RDF processors which fail to <a>recognize</a> a datatype IRI will not be able to detect some entailments which are visible to one which does. For example, the fact that </p><p><code>ex:a ex:p "20.0000"^^xsd:decimal .</code></p><p>entails </p><p><code>ex:a ex:p "20.0"^^xsd:decimal .</code></p><p>will not be visible to a processor which does not <a>recognize</a> the datatype URI <code>xsd:decimal</code>.</p>
+<p>RDF literal syntax allows any IRI to be used in a typed literal, even when it is not <a>recognize</a>d as referring to a datatype. Literals with such an "unknown" datatype IRI, which is not in the set of <a>recognize</a>d datatypes, MUST NOT be treated as errors, although RDF applications MAY issue a warning. Such literals SHOULD be treated like IRIs and assumed to denote some thing in the universe IR. RDF processors which fail to <a>recognize</a> a datatype IRI will not be able to detect some entailments which are visible to one which does. For example, the fact that </p><p><code>ex:a ex:p "20.0000"^^xsd:decimal .</code></p><p>entails </p><p><code>ex:a ex:p "20.0"^^xsd:decimal .</code></p><p>will not be visible to a processor which does not <a>recognize</a> the datatype IRI <code>xsd:decimal</code>.</p>
</section>
@@ -538,7 +539,7 @@
<p>D-entails</p>
-<p><code>ex:a ex:p"25"^^xsd:decimal .</code>
+<p><code>ex:a ex:p "25"^^xsd:decimal .</code>
</p>
<p>In general, any triple containing a literal with a <a>recognize</a>d datatype IRI D-entails another literal when the lexical strings of the literals map to the same value under the lexical-to-value map of the datatype. If two different datatypes in D map lexical strings to a common value, then a triple containing a literal typed with one datatype may D-entail another triple containing a literal typed with a different datatype. For example, <code>"25"^^xsd:integer</code> and <code>"25.0"^^xsd:decimal</code> have the same value, so the above also D-entails</p>
@@ -690,7 +691,7 @@
<table border="1">
<tbody>
<tr>
- <td ><strong>RDFS vocabulary</strong></td>
+ <td ><dfn>RDFS vocabulary</dfn></td>
</tr>
<tr>
@@ -1140,8 +1141,8 @@
<section class="appendix"><h2 id="proofs">Finite interpretations (Informative)</h2>
<p>To keep the exposition simple, the RDF semantics has been phrased in a way which requires interpretations to be larger than absolutely necessary. For example, all interpretations are required to interpret the whole IRI vocabulary, and the universes of all D-interpretations must contain all possible strings and therefore be infinite. This appendix sketches, without proof, how to re-state the semantics using smaller semantic structures, without changing any entailments. </p>
-<p>Basically, it is only necessary for an interpretation structure to interpret the <a>name</a>s actually used in the graphs whose entailment is being considered, and to have a universe which contains referents for all the <a>name</a>s and blank nodes, plus a random member of each nonempty class or type, in order to provide for the truth of existential assertions made using blank nodes. Formally, we can define a <dfn>pre-interpretation</dfn> over a <a>vocabulary</a> V to be a structure I similar to a <a>simple interpretation</a> but with a mapping only from V to its universe IR, and when considering whether G entails E, consider only pre-interpretations over the finite vocabulary of <a>name</a>s actually used in G union E. The universe of such a pre-interpretation can be restricted to the cardinality N+B+C, where N is the size of the vocabulary, B is the number of blank nodes in the graphs, and C is the number of classes (including datatype classes) that are implicitly mentioned in the graphs. Any such pre-interpretation may be extended to <a>simple interpretation</a>s all of which which will give the same truth values for any triples in G or E. Satisfiability, entailment and so on can then be defined with respect to these finite pre-interpretations, and shown to be identical to the ideas defined in the body of the specification.</p>
-<p>When considering D-entailment, pre-interpretations may be kept finite by weakening the semantic conditions for datatyped literals so that IR need contain literal values only for literals which actually occur in G or E, or a single value in the value space if there are no such literals in the vocabulary. For RDF entailment, only the finite part of the RDF vocabulary which include those container membership properties which actually occur in the graphs need to be interpreted, and the second RDF semantic condition is weakened to apply only to values which are values of literals which actually occur in the vocabulary. For RDFS interpretations, again only that finite part of the infinite container membership property vocabulary which actually occurs in the graphs under consideration needs to be interpreted. In all these cases, a pre-interpretation of the vocabulary of a set of graphs may be extended to a full interpretation of the appropriate type without changing the truthvalues of any triples in the graphs.</p>
+<p>Basically, it is only necessary for an interpretation structure to interpret the <a>name</a>s actually used in the graphs whose entailment is being considered, and to have a universe which contains referents for all the <a>name</a>s and blank nodes, plus a random member of each nonempty class or type, in order to provide for the truth of existential assertions made using blank nodes. Formally, we can define a <dfn>pre-interpretation</dfn> over a <a>vocabulary</a> V to be a structure I similar to a <a>simple interpretation</a> but with a mapping only from V to its universe IR, and when considering whether G entails E, consider only pre-interpretations over the finite vocabulary of <a>name</a>s actually used in G union E. The universe of such a pre-interpretation can be restricted to the cardinality N+B, where N is the size of the vocabulary and B is the number of blank nodes in the graphs. Any such pre-interpretation may be extended to <a>simple interpretation</a>s all of which which will give the same truth values for any triples in G or E. Satisfiability, entailment and so on can then be defined with respect to these finite pre-interpretations, and shown to be identical to the ideas defined in the body of the specification.</p>
+<p>When considering D-entailment, pre-interpretations may be kept finite by weakening the semantic conditions for datatyped literals so that IR need contain literal values only for literals which actually occur in G or E, and the size of the universe restricted to (N+B).(D+1), where D is the number of recognized datatypes. (A tighter bound is possible.) For RDF entailment, only the finite part of the RDF vocabulary which include those container membership properties which actually occur in the graphs need to be interpreted, and the second RDF semantic condition is weakened to apply only to values which are values of literals which actually occur in the vocabulary. For RDFS interpretations, again only that finite part of the infinite container membership property vocabulary which actually occurs in the graphs under consideration needs to be interpreted. In all these cases, a pre-interpretation of the vocabulary of a set of graphs may be extended to a full interpretation of the appropriate type without changing the truth-values of any triples in the graphs.</p>
<p>The whole semantics could be stated in terms of pre-interpretations, yielding the same entailments, and allowing finite RDF graphs to be interpreted in finite structures, if this <em>finite model property</em> is considered important.
</section>
@@ -1228,7 +1229,7 @@
<p><code>ex:a ex:b ex:c .</code></p>
- <p>and suppose that this graph is identified by the IRI <code>ex:graph1</code>. Exactly how this identification is achieved is external to the RDF model, but it might be by the IRI resolving to a concrete syntax document describing the graph, or by the IRI being the associated name of a named graph in a dataset. Assuming that the IRI can be used to refer to the triple, then the reification vocabulary allows us to describe the first graph in another graph:</p>
+ <p>and suppose that IRI <code>ex:graph1</code> is used to <a>identify</a> this graph. Exactly how this identification is achieved is external to the RDF model, but it might be by the IRI resolving to a concrete syntax document describing the graph, or by the IRI being the associated name of a named graph in a dataset. Assuming that the IRI can be used to refer to the triple, then the reification vocabulary allows us to describe the first graph in another graph:</p>
<p><code>ex:graph1 rdf:type rdf:Statement .<br/>
ex:graph1 rdf:subject ex:a .<br/>
@@ -1244,26 +1245,26 @@
</p>
-<p>Reifications can be written with a blank node as subject, or with an IRI subject which does not <a>identify</a> any concrete realization of a triple, in which case they assert the existence of the described triple. </p>
+<p><a>Reification</a>s can be written with a blank node as subject, or with an IRI subject which does not <a>identify</a> any concrete realization of a triple, in both of which cases they simply assert the existence of the described triple. </p>
- <p>The subject of a reification is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
+ <p>The subject of a <a>reification,/a> is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of
composition or provenance information are applied to the
reified triple, which are meaningful only when thought of as
referring to a particular instance or token of a triple. </p>
- <p>A reification of a triple does not entail the triple, and is not
+ <p>A <a>reification</a> of a triple does not entail the triple, and is not
entailed by it. The
- reification only says that the triple token exists and what it is about,
+ <a>reification</a> only says that the triple token exists and what it is about,
not that it is true, so it does not entail the triple. On the other hand, asserting a triple does not automatically imply that any
triple tokens exist in the universe being described by the triple.
For example, the triple might be part of an ontology describing
animals, which could be satisfied by an interpretation in which the
- universe contained only animals, and in which a reification of it was therefore
+ universe contained only animals, and in which a <a>reification</a> of it was therefore
false.</p>
- <p>Since the relation between triples and reifications of triples
+ <p>Since the relation between triples and <a>reification</a>s of triples
in any RDF graph or graphs need not be one-to-one, asserting a
- property about some entity described by a reification need not
+ property about some entity described by a <a>reification</a> need not
entail that the same property holds of another such entity, even if
it has the same components. For example,</p>
@@ -1305,19 +1306,19 @@
indices should not necessarily be thought of as defining an
ordering of the container itself; some containers are considered to be unordered.</p>
- <p>The RDFS vocabulary, described below, adds a generic membership
+ <p>The <a>RDFS vocabulary</a> adds a generic membership
property which holds regardless of position, and classes containing
all the containers and all the membership properties.</p>
- <p>One should understand this RDF vocabulary as <em>describing</em>
- containers, rather than as a vocabulary for constructing them, as
+ <p>One should understand this vocabulary as <em>describing</em>
+ containers, rather than as a tool for constructing them, as
would typically be supplied by a programming language. The actual containers are entities in the semantic universe,
and RDF graphs which use the vocabulary simply provide very basic
information about these entities, enabling an RDF graph to
characterize the container type and give partial information about
the members of a container. Since the RDF container vocabulary is
so limited, many 'natural' assumptions concerning RDF containers
- are not formally sanctioned by the RDF formal semantics. This should not be taken as
+ cannot be formally sanctioned by the RDF formal semantics. This should not be taken as
meaning that these assumptions are false, but only that RDF does
not formally entail that they must be true.</p>
@@ -1339,7 +1340,7 @@
entailments.</p>
-<p>RDF does not support any entailments which could arise from enumerating
+<p>The RDF semantics does not support any entailments which could arise from enumerating
the elements of an unordered <code>rdf:Bag</code> in a different order. For example,</p>
<p><code>_:xxx rdf:type rdf:Bag .<br/>
@@ -1448,7 +1449,7 @@
by failing to specify its <code>rdf:rest</code> property value.</p>
-<p><a>semantic extension</a>s may
+<p><a>Semantic extension</a>s may
place extra syntactic well-formedness restrictions on the use of this vocabulary
in order to rule out such graphs. They may
exclude interpretations of the collection vocabulary which violate the convention