Comments on the new RDF Model Theory spec [Bag/Alt issue]

**** BAG/ALT ISSUE
**** After
**** http://lists.w3.org/Archives/Public/www-rdf-comments/2002AprJun/0093.html

> >**** 3.2.2 Containers ****
> >
> ><quote>
> >RDF does not support any entailments which could arise from 
> >re-ordering the elements of an rdf:Bag.
> ><snip/>
> >Notice that if this conclusion were valid, then the result of 
> >conjoining it to the original graph would also be a valid 
> >entailment, which would assert that both elements were in both 
> >positions. (This is an consequence of the fact that RDF is a purely 
> >assertional language.)
> ></quote>
> >
> >ISSUE:
> >This amounts to drop an important functionality that is part of the 
> >normative RDFM&S spec.
> 
> Take this issue up with the WG, not with me.
> 
> In my view, this functionality never was in RDF: it is a fantasy 
> based on a misunderstanding about the nature of assertional languages
> 
> >This is not documented anywhere in the RDF Issue List, cf 
> >http://www.w3.org/2000/03/rdf-tracking/ .

This has never been confuted so far, so the output of 
this thread can be well seen at a first attempt to build
a public account on this issue. That, eventually, should go in the 
official issue list (hopefully already closed ;)

> >So, why rule out entailments like the one cited in the spec, cf
> ><quote>
> >_:xxx [rdf:type] [rdf:Bag] .
> >_:xxx [rdf:_1] <ex:a> .
> >_:xxx [rdf:_2] <ex:b> .
> >
> >does not entail
> >
> >_:xxx [rdf:_1] <ex:b> .
> >_:xxx [rdf:_2] <ex:a> .
> ></quote>
> >...??
> 
> The wording you cite tries to explain why. If
> 
> _:xxx [rdf:type] [rdf:Bag] .
> _:xxx [rdf:_1] <ex:a> .
> _:xxx [rdf:_2] <ex:b> .
> 
> entails
> 
> _:xxx [rdf:_1] <ex:b> .
> _:xxx [rdf:_2] <ex:a> .
> 
> then it also must entail
> 
> _:xxx [rdf:type] [rdf:Bag] .
> _:xxx [rdf:_1] <ex:a> .
> _:xxx [rdf:_2] <ex:b> .
> _:xxx [rdf:_1] <ex:b> .
> _:xxx [rdf:_2] <ex:a> .
> 
> and by suitable reordering, it will entail that ALL members of the 
> bag are in ALL positions.
> 
> All RDF containers have an inherent ordering on their members that is 
> fixed by the very syntax of the membership properties. If you want 
> RDF bags to be really bags, then you must re-design the container 
> membership function suite. You can't have unordered containers 
> accessed with ordered membership functions in an assertional 
> language; the very act of saying they are in the container assigns 
> them a place in the ordering, and there is no way to 'un-say' it.

Pat, I think there are two points that can be separated in the discussion.
1) Use of ordered elements (rdf:_n) in bags (and alts)
2) Whether or not this results in containers being broken

Before going on, one clarification: I then assume that the Seq construct
is viewed as fine, so here we're just discussing about the Bag (and Alt).
If it's not seen as fine, then we'd probably open another issue for that.

Now, back on Bag.

On 1): 
I cannot but wholeheartedly agree with your feeling that imposing
sequencing ordering even on Bag has been a bad-and-ugly design choice.
I agree so much that, in the old 1998's ;), I raised a formal issue on this
(and incidentally, was not the only one), which is C.30 in the 
original RDF issue list, cf
http://www.w3.org/RDF/Group/Syntax/issuesd.html#c30
-->
http://lists.w3.org/Archives/Public/www-rdf-comments/1998OctDec/0011.html
-->
<quote>
4) The Bag container: as it is now, its model representation is 
   probably too specific; now, a bag with {Joe, Ann, Mary} has a 
   different model representation than {Ann, Joe, Mary}. This forces
   you to put much more effort in the model equivalence, or in other 
   words, makes the model representation unnecessarily fine-grained.
   The point is the use of RDF:_1 RDF:_2 etc. I agree this way is 
   consistent with Alt and Seq, but, here we're talking about a 
   different data structure, where the order doesn't matter. So,
   it would be probably better to encode this in the model 
   using just a unique rdf:_bag (for example) predicate. This is 
   a simple edit to do, and gives you the important property that 
   a Bag has one model representation and not many different ones,
   something not true now (and therefore, rather tricky imho...).
</quote>
and you can see how this issue ended and where we are now.
Said this, now that things have gone as they have, this feature
is the present standard, and we've to pass beyond the fact we
like it or not (we both don't), and see what we can do with it.

So, on to point 2).
The motivating example says that if the first entailment holds, then it 
*must* entail ... bla.
Saying *must* implies it mathematically follows from something in the MT.
Which, I couldn't find. There's no rule that tells you that the second
entailment must hold (is there?). And in fact, the only thing that should 
reasonably hold is just the entailment of 

 _:xxx [rdf:type] [rdf:Bag] .
 _:xxx [rdf:_1] <ex:a> .
 _:xxx [rdf:_2] <ex:b> .
 _:yyy [rdf:_1] <ex:b> .
 _:yyy [rdf:_2] <ex:a> .

which is perfectly fine.

So, this can't be the reason to ban the Bag container. 

Now, there might be the reason we don't like it (I do have other reasons
too), but then such reasons have to be explicitly written down as official 
motivation, because the status quo has its huge shield in the fact that it's the 
normative standard (!), and to change it we do need good motivations.
There are other approaches than the status quo, like taking bags out altogether, or 
for example, modifying them using an rdf:_bag , or maybe even others. But still
there's the need for some good motivation before dropping a part of the 
"old normative RDF" and going another way. Showing it is broken is in fact a 
very good motivation, but that's not been the case yet.

Thoughts?
-M

ps Note:
Since I don't like Bags myself, I will do add my main motivation to drop them.
I had it in 1998, and I still have it now: it makes implementation quite hard,
and imho the cost/benefit is consequently not worth at all.
That's my major reason, and in fact, the only very-good-reason I had/have, apart
from taste and other minor things (which would be solved by an rdf:_bag fix,
but are in any case minor).
But as said, the fact it's not at all a strong argument like "this is broken", 
implies that if we decide to drop a normative part, we have to be well aware of 
what the real reasons are, and write them down officially for the public record.

pps Similar reasoning (although, with different entailments ;) apply for Alt.
Including the hard-to-implement motivation.

Received on Thursday, 23 May 2002 11:53:49 UTC