W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2001

ACTION 2001-08-24#9 : issues with containers

From: pat hayes <phayes@ai.uwf.edu>
Date: Wed, 29 Aug 2001 17:54:08 -0700
Message-Id: <v04210114b7b334f8a7a9@[130.107.66.237]>
To: w3c-rdfcore-wg@w3.org
Re: ACTION 2001-08-24#9 Pat: Write up a summary of the issues with containers

OK, here are the ones that seem to be significant from trying to 
incorporate containers in the MT. Note, these arise independently of 
the matter of what rdf:li means; I'm assuming that has been somehow 
dealt with and considering only the use of properties of the form 
rdf:_n where n is an explicit integer, ie things of type 
rdfs:containerMembershipProperty.

1. There is no way to say that some set of container contents is 
*all* that is in a container. So it does not follow that all the 
things that are mentioned as being in a container are all the things 
there are in the container. Making that assumption might indeed be a 
Bad Thing as it would be non-monotonic, but allowing an *explicit* 
way of saying that some things are precisely the things in a 
container would make the language much more useful and wouldn't 
create any obvious problems (and is what the XML examples in the M&S 
strongly seem to suggest, BTW.).  One way would be to provide a way 
of saying that a container has a certain number of members, but that 
would require the use of numbers. Or we could introduce a special 
'last thing in container' thingie so that if

xxx rdf:_n rdf:lastThing

then it would follow that

xxx rdf:_m yyy

would be false for any m>n.

It seems to me that in order to be really useful, containers need 
some such device. Without it they are really only orderings.

2. It isn't clear whether containers (particularly sequences) can 
have 'gaps' or not. For example, does this graph

xxx rdf:type rdf:seq
xxx rdf:_1 aaa
xxx rdf:_3 ccc

entail this?

xxx rdf:type rdf:seq
xxx rdf:_1 aaa
xxx rdf:_3 ccc
xxx rdf:_2 _:yyy

I suggest we at least say whether or not it does, one way or the other.

3.  There really doesn't seem to be any actual difference between 
bags and sequences in RDF; the MT doesn't make any real distinction. 
The M&S *says* there is, and everyone knows what it means, but the 
distinction only arises when one is deciding whether or not two 
containers are the 'same' container, and RDF doesnt have any way of 
saying that two containers aren't the same, so what does the 
distinction amount to? Particularly as RDF uses exactly the same 
primitives to relate bags to their contents as it does to relate 
sequences to theirs, ie bags are described as being unordered, but 
are treated as having an order by the language itself.

It might be better to simply have one kind of container which are 
honest-to-God sequences, but allow them to have properties which mark 
them as intended-to-be-thought-of-as-baggish, or 
intended-to-thought-of-as-settish, or whatever, rather than kind of 
pretend they are 'really' different when they are in fact exactly the 
same to RDF. We could do this just by saying

rdf:bag rdfs:subClassOf rdf:seq

in fact, and leave everything else just as it is, then other 
container classes can be introduced in the same way as the need 
arises.

4.  rdf:alt as described in the M&S is a crock; in particular, 
because of 1., asserting a property of an Alt hardly says anything; 
it could be true even if all the members of the alt which are 
mentioned in the graph do not have the property, since there might be 
some others that do. (See the latest version of the MT document for a 
longer discussion of this.)

Fixing 1 seems to be a prerequisite for making rdf:alt coherent in 
the way stated in the M&S.  I would  suggest that we simply trash 
rdf:alt and suggest that our successors re-do it better.

---------

That's all, folks.

Pat
---------------------------------------------------------------------
(650)859 6569 w
(650)494 3973 h (until September)
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Wednesday, 29 August 2001 20:53:01 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:38:49 EDT