RE: Containers

At 02:51 PM 2/2/01 +0000, you wrote:
>Hi Graham,
>
>Another good point.
>
>The note Dave and I wrote was about syntax and I think
>of the issue you raise here as being about model/schema.
>Hence the separate reply thread.
>
>You inspired me to go re-read the schema spec (well part
>of it).  My reading of it is that the class
>rdfs:ContainerMembershipProperty embodies the idea of
>membership of a container.  rdf:_1, rdf:_2 ... are all
>instances of that class.
>
>There is nothing to stop anyone from defining other
>instances of that class, e.g.
>
>   <rdfs:ContainerMembershipProperty rdf:ID="#klyne:memberOf"/>
>
>klyne:memberOf implies container membership.
>So the machinery is in rdfs already.

Yes, that's roughly what I had in mind (but I was too lazy to go find the 
exact reference).  I guess I was suggesting it might be helpful to mention 
this in a "clarification" document;  c.f. allowing multiple rdf:_1 is also 
a model issue rather than syntax.

>This does raise a few interesting questions.  Dan Brickley
>has suggested that it would be good to define rdfx:member
>as an instance of rdfs:ContainerMembershipProperty and define
>rdf:_1, rdf:_2, ... as subproperties of it.  If all container
>membership properties are defined as subProperties of rdfx:member
>it makes it possible to write more efficient queries.

I like that.  I had got half way there with some of my context-related 
thoughts, but missed the trick of making _n sub-properties.  What I really 
like about all this is that it requires no change to the RDF core ... it's 
surprising how much can be built on that simple base.

>I'm not sure what it would mean for a seq or an alt to have
>an explicit rdfx:member property e.g.:
>
>   <rdf:Seq>
>     <rdfx:member>foo</rdfx:member>
>   </rdf:Seq>
>
>Where in the sequence does this foo come?  One is tempted
>to say this construct is not allowed, but schema domain
>constraints don't provide the machinery to do that.
>An alternative approach might be that the above means that
>'foo' is the n'th member of the sequence, but we don't know
>the value of n.

I was tempted as you.  But I think that this may raise a more fundamental 
question about how one can define an ordering on properties, which is 
implicit in the idea of seq, but which is also outside any RDF machinery I 
am aware of.  In fact, I now think this may be another submerged reason I 
have been uneasy about the RDF approach to collections.

Come to think of it, I don't think the schema machinery can really deal 
with bags and seqs as they stand (or not in a finite schema description).

If we can answer the question about ordering (and comparison) of properties 
in a general way, then I think it is possible to answer the point you 
raise.  It might even be possible to make a schema mechanism.  It may be 
that some issues have to be pushed up from the schema level to a different 
(logical?) level:  if, say, _3 can be repeated in a Bag, what does it mean 
to have such a repetition in a Seq?  Partial ordering?

I'm rambling, so I'll stop.  But I think this may be an important point to 
think about.

>And of course this all this will only in practise if the
>implementations will do the 'inference'.  Jena doesn't
>at the moment, but I wasn't doing anything in particular
>this weekend anyway.

Oooh... I really don't think a parser should be expected to do inference.

#g

Received on Friday, 2 February 2001 13:08:00 UTC