Revert "remove informative appendix on reification, etc. (#100)" (#107)

This reverts commit 4174d9d.

Author: franconi

spec/index.html

@@ -1891,6 +1891,289 @@ <h2>Proofs of some results (Informative)</h2>
 
 </section>
 
+<section id="whatnot" class="informative appendix">
+  <h2 id="non_semantics">RDF reification, containers and collections (Informative)</h2>
+
+  <p>The RDF semantic conditions do not place formal constraints on the meaning
+    of much of the RDF vocabulary which is intended for use in describing containers and bounded collections,
+    or the reification vocabulary intended to enable an RDF graph to describe RDF triples.
+    This appendix briefly reviews the intended meanings of this vocabulary. </p>
+
+  <p>The omission of these conditions from the formal semantics is a design decision
+    to accommodate variations in existing RDF usage and to make it easier to implement
+    processes to check formal RDF entailment. For example, implementations may decide
+    to use special procedural techniques to implement the RDF collection vocabulary.</p>
+
+  <section id="Reif">
+    <h3>Reification</h3>
+
+    <div class="c1">
+      <table>
+        <tbody>
+          <tr>
+            <td class="othertable"><strong>RDF reification vocabulary</strong></td>
+          </tr>
+          <tr>
+            <td class="othertable"><code>rdf:Statement rdf:subject rdf:predicate
+                rdf:object</code></td>
+          </tr>
+        </tbody>
+      </table>
+    </div>
+
+    <p>The intended meaning of this vocabulary is to allow an RDF graph to act as metadata describing other RDF triples. </p>
+
+    <p>Consider an example graph containing a single triple:</p>
+
+    <p><code>ex:a ex:b ex:c .</code></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 <a>name</a> of a named graph in a dataset.
+      Assuming that the IRI can be used to denote 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/>
+      ex:graph1 rdf:predicate ex:b .<br/>
+      ex:graph1 rdf:object ex:c .</code></p>
+
+    <p>The second graph is called a <dfn>reification</dfn> of the triple in the first graph.</p>
+
+    <p>Reification is not a form of quotation. Rather, the reification describes the
+      relationship between a token of a triple and the resources that the triple denotes. 
+      The value of the <code>rdf:subject</code> property is not the
+      subject IRI itself but the thing it <a>denotes</a>, and similarly for <code>rdf:predicate</code> and <code>rdf:object</code>.
+      For example, if the referent of <code>ex:a</code> is Mount Everest,
+      then the subject of the reified triple is also the mountain, not the IRI which denotes it.</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 <a>reification</a> is intended to denote 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
+      denoting a particular instance or token of a triple. </p>
+
+    <p>A <a>reification</a> of a triple does not entail the triple, and is not entailed by it.
+      The <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 <a>reification</a> of it was therefore
+      false.</p>
+
+    <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 <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>
+
+    <p><code>_:xxx rdf:type rdf:Statement .<br/>
+      _:xxx rdf:subject ex:subject .<br/>
+      _:xxx rdf:predicate ex:predicate .<br/>
+      _:xxx rdf:object ex:object .<br/>
+      _:yyy rdf:type rdf:Statement .<br/>
+      _:yyy rdf:subject ex:subject .<br/>
+      _:yyy rdf:predicate ex:predicate .<br/>
+      _:yyy rdf:object ex:object .<br/>
+      _:xxx ex:property ex:foo .</code></p>
+
+    <p>does not entail</p>
+
+    <p><code>_:yyy ex:property ex:foo .</code></p>
+
+  </section>
+
+  <section id="containers">
+    <h4>RDF containers</h4>
+
+    <table>
+      <tbody>
+        <tr>
+          <td class="othertable"><strong>RDF(S) Container Vocabulary</strong></td>
+        </tr>
+        <tr>
+          <td class="othertable"><code>rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2
+              ... rdfs:member rdfs:Container rdfs:ContainerMembershipProperty</code></td>
+        </tr>
+      </tbody>
+    </table>
+
+    <p>RDF provides vocabularies for describing three classes of
+      containers. Containers have a type, and their members can
+      be enumerated by using a fixed set of <em>container membership
+      properties</em>. These properties are indexed by integers to
+      provide a way to distinguish the members from each other, but these
+      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 <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 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
+      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>
+
+    <p>There are no special semantic conditions on the container
+      vocabulary: the only structure which RDF presumes its containers
+      to have is what can be inferred from the use of this vocabulary and
+      the general RDF semantic conditions. This amounts to knowing the type of a container, and having a partial
+      enumeration
+      of the items in the container. The intended mode of use is that things
+      of type <code>rdf:Bag</code>
+      are considered to be unordered but to allow duplicates; things of
+      type <code>rdf:Seq</code> are considered to be ordered, and things
+      of type <code>rdf:Alt</code> are considered to represent a
+      collection of alternatives, possibly with a preference ordering.
+      If the container is of an ordered type, then the ordering of items in the container is intended to be
+      indicated by the numerical ordering of the container membership
+      properties, which are assumed to be single-valued.
+      However, these informal conditions are not reflected in any formal RDF
+      entailments.</p>
+
+
+    <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/>
+       _:xxx rdf:_1 ex:a .<br/>
+       _:xxx rdf:_2 ex:b .</code></p>
+
+    <p>does not entail</p>
+
+    <p><code>_:xxx rdf:_1 ex:b .<br/>
+       _:xxx rdf:_2 ex:a .</code></p>
+
+    <p>(If this conclusion were <a>valid</a>, then the result of
+      adding it to the original graph would be <a>entail</a>ed by the graph, and this would assert that both elements were in both
+      positions. This is a consequence of the fact that RDF is a purely
+      assertional language.)</p>
+
+    <p>There is no assumption that a property of a container applies to
+      any of the elements of the container, or vice versa. </p>
+
+    <p>There is no formal requirement that
+      the three container classes are disjoint, so that for example
+      it is consistent to assert that something is both an <code>rdf:Bag</code> and an <code>rdf:Seq</code>.
+      There is no assumption that containers are gap-free, so that for example</p>
+
+    <p><code>_:xxx rdf:type rdf:Seq.<br/>
+       _:xxx rdf:_1 ex:a .<br/>
+       _:xxx rdf:_3 ex:c .</code></p>
+
+    <p>does not entail</p>
+
+    <p><code>_:xxx rdf:_2 _:yyy .</code></p>
+
+    <p>There is no way in RDF to assert
+      that a container contains only a fixed number of members. This is a
+      reflection of the fact that it is always consistent to add a triple
+      to a graph asserting a membership property of any container. And
+      finally, there is no built-in assumption that an RDF container has
+      only finitely many members.</p>
+  </section>
+
+  <section id="collections">
+    <span id="rdf-collections"><!-- Alternative identifier --></span>
+    <h4>RDF collections</h4>
+
+    <table>
+      <tbody>
+        <tr>
+          <td class="othertable"><strong>RDF Collection Vocabulary</strong></td>
+        </tr>
+        <tr>
+          <td class="othertable"><code>rdf:List rdf:first rdf:rest rdf:nil</code></td>
+        </tr>
+      </tbody>
+    </table>
+
+    <p>RDF provides a vocabulary for describing collections, i.e.'list
+      structures', in terms of head-tail links. Collections differ from
+      containers in allowing branching structure and in having an
+      explicit terminator, allowing applications to determine the exact
+      set of items in the collection.</p>
+
+
+    <p>As with containers, no special semantic conditions are imposed on this vocabulary
+      other than the type of <code>rdf:nil</code> being <code>rdf:List</code>. It
+      is intended for use typically in a context where a container is described using
+      blank nodes to connect a 'well-formed' sequence of items, each described by
+      two triples of the form
+      <code><br/>
+      <br/>
+      _:c1 rdf:first aaa .<br/>
+      _:c1 rdf:rest _:c2 .</code></p>
+
+    <p>where the final item is indicated by the use of <code>rdf:nil</code> as the
+      value of the property <code>rdf:rest</code>. In a familiar convention, <code>rdf:nil</code>
+      can be thought of as the empty collection. Any such graph amounts to an assertion
+      that the collection exists, and since the members of the collection can be determined
+      by inspection, this is often sufficient to enable applications to determine
+      what is meant. The semantics does not require any collections
+      to exist other than those mentioned explicitly in a graph (and the empty collection).
+      For example, the existence of a collection containing two items does not automatically
+      guarantee that the similar collection with the items permuted also exists:
+      <code>
+      <br/><br/>
+      _:c1 rdf:first ex:aaa .<br/>
+      _:c1 rdf:rest _:c2 .<br/>
+      _:c2 rdf:first ex:bbb .<br/>
+      _:c2 rdf:rest rdf:nil . </code></p>
+
+    <p>does not entail</p>
+
+    <p><code>_:c3 rdf:first ex:bbb .<br/>
+      _:c3 rdf:rest _:c4 .<br/>
+      <span >_:c4 rdf:first</span> ex:aaa .<br/>
+     _:c4 rdf:rest rdf:nil .
+     </code></p>
+
+    <p>Also, RDF imposes no 'well-formedness' conditions on the use of this
+      vocabulary, so that it is possible to write RDF graphs which assert
+      the existence of highly peculiar objects such as lists with forked
+      or non-list tails, or multiple heads:</p>
+
+    <p><code>_:666 rdf:first ex:aaa .<br/>
+      _:666 rdf:first ex:bbb .<br/>
+      _:666 rdf:rest ex:ccc .<br/>
+      _:666 rdf:rest rdf:nil . </code></p>
+
+    <p>It is also possible to write a set of triples which under-specify a collection
+      by failing to specify its <code>rdf:rest</code> property value.</p>
+
+    <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
+      that the subject of a 'linked' collection of two-triple items of the form described
+      above, ending with an item ending with <code>rdf:nil</code>, <a>denotes</a> a totally
+      ordered sequence whose members are the referents of the <code>rdf:first</code>
+      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 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>
+  </section>
+
+</section>
+
 <section id="privacy" class="informative appendix">
   <h2>Privacy Considerations (Informative)</h2>
   <p>