Re: Statements/Reified statements

Damien Morton wrote:

> I hope you will forgive me if I ask a question or two.

Well let me take a stab at your questions ... if i give wrong answers hopefully
somebody will correct me.  I put my motivational payload at the end.

> If an rdf database contains a set (s,p,o) statements, how is ordering meant
> to be implemented?

There is no ordering specified for a RDF database by M&S.  There is no ordering
of the (s, p, o) triples in a model because a model is considered a set and a
set has no order.

> I see that the predicate rdf_n is used in rdf sequences, but surely when an
> object is inserted into a collection at some position, all of the rdf_n
> predicates will have to be renumbered to reflect the new ordering. Is my
> understanding correct?

I don't know of any way in RDF to insert a new triple in a sequenced bag.  I
think you would have to reassert the entire bag again and then it would
automatically be resequenced.

> Isnt this something of an implementation nightmare,
> causing a single insertion or deletion to require re-stating of all of the
> membership statements about the collection.

I think the sequencing of RDF triples in a database would be the internal affair
of the running implementation.  But I don't think there is any particular
information that should be contained in that sequencing.  Where sequencing is
important, I think M&S says it should be specified by an rdf:seq assertion.  I
agree that is would be an implementation nightmare to try to incrementally
update such a sequence.  Do you have a real example of a application that would
require such a nightmare?

> If one were to restate all of the membership statements, how would you query
> for "x: (container, rdf_n, ?x)", given that you dont know what n is, and
> that you probably dont want to be doing regular expression searches on
> predicates.

The agent that restated would know what n is (would know the sequence), to any
other agent it would be new information.

> Surely a better way would be to implement this as a linked list of
> statements.

I think  you could keep whatever sequence information internally by using the
statement ID that is present in most APIs. If you wanted to communicate that
information to the outside world in RDF you could use the idAttr of production
[RDFgrammar#6.12] like the following:

[yourSequence] --yourns:seq-->[idAttr1]
[yourSequence] --yourns:seq-->[idAttr2]

See:
[RDFgrammar#6.12] --rdf:about-->"http://www.w3.org/TR/REC-rdf-syntax/#grammar"
[RDFgrammar#6.12] --rdf:label-->" '<' propName idAttr? '>' value '</' propName
'>' "

<a html:name="payload" />
<rdf:description
rdf:about=http://lists.w3.org/Archives/Public/www-rdf-interest/2000Nov/0378.html#payload">

<rdf:label="payload"/>
<rai:text>
But i think most APIs will build extra reification quads for each of your
assertions, it may not be very efficient.  Of course if [StatementsCanBeObjects]
is accepted, your problems will be solved.
</rai:text>
</rdf:description>

[StatementsCanBeObjects]
    --rdf:about-->

"http://lists.w3.org/Archives/Public/www-rdf-interest/2000Nov/0360.html"

We must be painfully clear to what we refer when we write RDF.
Seth Russell

Received on Friday, 24 November 2000 16:53:02 UTC