RE: Containers

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.

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'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.

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.

I was wondering what other implementations do?

Brian

ps:  My interpretation of the rdf:_xxx properties must
start at _1 and be contiguous constraint is that it applies to the
abstract resource; it does not apply to any particular collection
of statements.  So you represent part of bag in a model or 
RDF XML serialization.

B

> -----Original Message-----
> From: Graham Klyne [mailto:GK@ninebynine.org]
> Sent: 01 February 2001 08:52
> To: Dave Beckett; Brian McBride
> Cc: RDF interest group
> Subject: Fwd: Containers
> 
> 
> Another point I meant to offer, but forgot when I drafted the 
> earlier note...
> 
> I'd also like to suggest that container membership properties 
> other than 
> rdf:_n MAY be used to indicate membership of an rdf:Bag.  I 
> think this is 
> kind-of implied by the relaxations your approach introduces, 
> but it's not 
> explicit.  This way, the basic rdf:Bag framework could be 
> used to collect 
> set members defined over a number of different documents, 
> accommodating the 
> "anyone can say anything about anything" principle.
> 
> #g
> --
> 
> >Date: Wed, 31 Jan 2001 18:02:37 +0000
> >To: Dave Beckett <dave.beckett@bristol.ac.uk>, Brian McBride 
> ><bwm@hplb.hpl.hp.com>
> >From: Graham Klyne <GK@ninebynine.org>
> >Subject: Containers
> >Cc: RDF interest group <www-rdf-interest@w3.org>
> >
> >I finally took a look at:
> >
> >>[3] A Proposed Interpretation of RDF Containers -
> >>     http://www-uk.hpl.hp.com/people/bwm/rdf/issues/containersyntax/
> >
> >and think it does a pretty good job of cleaning up the 
> messier container 
> >issues.  I have come to view the RDFM&S constructs as 
> useful, convenient 
> >ways to present containers whose contents are presented 
> complely within a 
> >single document.
> >
> >
> >A comment, for your consideration, concerning rdf:li as an attribute:
> >
> >Since you allow (example 3):
> >
> >       [http://foo, rdf:_1, "1"]
> >       [http://foo, rdf:_1, "1 again"]
> >
> >why not just map rdf:li as an attribute to rdf:_1?  Then 
> example 4 would be:
> >
> >        <rdf:Description rdf:about="http://badExample" 
> rdf:li="a" rdf:_3="b"/>
> >
> >will generate:
> >
> >         [http://badExample, rdf:_1, "a"]
> >         [http://badExample, rdf:_3, "b"]
> >
> >and doesn't have to be viewed as a "bad example".
> >
> >#g
>

Received on Friday, 2 February 2001 10:47:00 UTC