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

Author: pfps

spec/index.html

@@ -1879,289 +1879,6 @@ <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>