Issue of support of Bag/Alt in RDF

re. your comment in

and the previous mail threads on this general issue, this is an 
attempt to summarize the discussion and reach a resolution.

First, let us agree on record, as we have already agreed off record, 
that neither of us particularly likes the RDF bag construct, but that 
the issue here, in your words 
) is that "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."

The formal semantics of the rdf container vocabulary in the case of 
rdf:Bag - that is, the formally specified semantics - is, I claim, 
clear and unambiguous. That is, the container membership properties 
are properties which relate containers to their members; and that is 
all. No claims are made, in the case of bags, that the ordering of 
the properties is significant; and no claim is made that the items 
enumerated in a particular graph are all the members of a container.

The questions then are, is this position even coherent, or is the 
above claim broken? , and, could we do better? I will claim that the 
answers are yes and no, respectively.

First, is it broken? That is, is it coherent to claim that one can 
give an ordered description of an unordered thing?  Seems to me that 
the answer is clearly yes, one can, as illustrated by the example of 
a list of items found in a pocket or in a drawer.  This seems to be 
uncontroversial as long as you bear in mind that these really are 
descriptions rather than constructions.

However, it might be said that we should be able to do better, in 
that there should be some formally sanctioned entailments that hold 
for bags, eg the description could have been given in a different 
order, and the bag would be unchanged.  However, I do not think that 
there are any formal entailments which can be stated which reflect or 
capture this intuition, since all RDF container descriptions are 
partial, so it is *never* possible to validly conclude that two 
containers (bags or seqs or alts) are identical, if given only an 
enumeration of their members; since one, but not the other, may have 
additional members. This point is independent of the order in which 
the elements of the container are enumerated. Consider:

ex:bagOne rdf:type rdf:Bag .
ex:bagOne rdf:_:1 aaa .
ex:bagOne rdf:_:2 bbb .
ex:bagTwo rdf:type rdf:Bag .
ex:bagTwo rdf:_:1 aaa .
ex:bagTwo rdf:_:2 bbb .
ex:bagThree rdf:type rdf:Bag .
ex:bagThree rdf:_:1 bbb .
ex:bagThree rdf:_:2 aaa .

It is not valid to conclude from his that bagOne is the same as 
bagThree, because it is not valid to conclude that bagOne is the same 
as bagTwo. They may not even have the same members.

We have already discussed the issue of whether it makes sense to 
infer a 're-ordering' of the bag description; the inappropriateness 
of this follows from the very notion of logical entailment (the fact 
that entailmen is state-free, in effect.)

There is one possible entailment condition that could rationally be 
added, which could be illustrated thus:

ex:bagOne rdf:type rdf:Bag .
ex:bagOne rdf:_:1 aaa .
ex:bagOne rdf:_:2 bbb .


_:x rdf:type rdf:Bag .
_:x rdf:_:1 bbb .
_:x rdf:_:2 aaa .

Ie that a bag EXISTS which can be described in the other order.

We did consider this, but rejected it as (a) providing no effectively 
utility in practice, since implementations will probably use 
extra-logical machiinery to check re-orderings in practice; (b) being 
extremely complicated to state in general (it requires one to be 
explicit about all permutations of the container vocabulary in use) 
and (c) imposing a heavy and pointless burden on complete conforming 
reasoners, which would then be required to generate bnodes for all 
possible permutations of every rdf:bag description, all to no likely 
useful purpose.

On balance, therefore, the WG decided to not provide any further 
formal semantics for rdf:bag, but to include a discussion, with 
suitable warnings, of the intended meaning, as in the current draft 
of the document.

In the light of all this, we have decided not to change the current 
draft of the relevant section or to modify the model theory.

Please reply to this email, copying indicating
whether this decision is acceptable.

Pat Hayes

IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola               			(850)202 4440   fax
FL 32501            				(850)291 0667    cell	   for spam

Received on Monday, 21 April 2003 19:22:21 UTC