Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove informative appendix on reification, etc. #100

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

remove informative appendix on reification, etc. #100

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
283 changes: 0 additions & 283 deletions spec/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1895,289 +1895,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>
Expand Down
Loading