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

Re: Bags (was: closing semantic issues)

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 7 Nov 2001 16:14:14 -0600
Message-Id: <p05101063b80f5b61500a@[]>
To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Cc: w3c-rdfcore-wg@w3.org
>At 05:35 PM 11/6/01 -0600, Pat Hayes wrote:
>>>If RDF is going to have something called rdf:Bag, then its *RDF* semantics
>>>should conform to the generally-accepted meaning of bags, and not to some
>>>other meaning.
>>I disagree. rdf:Bag is a class, is all. RDF is no more obliged to 
>>say precisely what it means than it is for any other class.
>In view of your recent comments about bags and entailments I was 
>wondering if *any* of the current container frameworks adequately 
>capture the "generally-accepted" meaning of bags; e.g. (using {* ... 
>*} to enclose members of a bag):
>     {* a, a, b *}  being the same bag as  {* a, b, a *}

Well, I've always understood the idea to be that RDF *describes* 
containers, rather than implementing them or exemplifying them. So it 
is OK for RDF to keep a 'private' ordering and basically treat all 
containers as sequences, but if it describes a container as being an 
rdf:Bag then it is saying that this ordering isn't supposed to be 
taken to be 'significant' in some sense. (I think this is close to 
what the M&S says.) But the ordering is still *there* in the RDF. 
After all, this is exactly how LISP would handle bags: you would 
encode them as lists and provide bag-access functions that pretended 
that the list ordering didn't matter, by doing things like checking 
for permutations under the hood. RDF doesn't implement this kind of 
thing, of course, but then that's not its role; it just has to carry 
information around without damaging it. If it delivers all the 
members of a container and the container type, that's all it needs to 
be able to do, right? Something else can figure out what to do with 
it from there on out.

This would matter, by the way, if RDF had any way to say that one bag 
equaled another, because then it would gets its knickers in a twist; 
but it never tries to say that, so everything is OK.

>The problem you mentioned with ordinal member properties is that RDF 
>inference doesn't provide for the retraction of statements.

Right, that's another way of saying it doesn't have states.

>  In 
>you said, in response to DanC:
>>         _:b rdf:type rdf:Bag.
>>         _:b rdf:_1 "abc".
>>         _:b rdf:_2 "def".
>>         _:b rdf:type rdf:Bag.
>>         _:b rdf:_2 "abc".
>>         _:b rdf:_1 "def".
>>and generally: the _n arcs of a bag can be permuted.
>That doesn't work. If it entails that, then it must also entail:
>         _:b rdf:type rdf:Bag.
>         _:b rdf:_1 "abc".
>         _:b rdf:_2 "def".
>         _:b rdf:_2 "abc".
>         _:b rdf:_1 "def".
>so just saying 'can be permuted' isn't enough. The fact is that we 
>really shouldn't have indexed selectors on things that are supposed 
>to be bags, since once you use those selectors once, the bag is 
>ordered, whether you like it or not. You can only 'permute' it if 
>you have state, and RDF has no states to permute over. Monotonic 
>inference only adds conclusions, it can't do things like permutation.
>I was thinking that a bag represented using a list-type expression 
>might have the same problem:

If you want it actually BE a bag, right, it will break. It cant be 
both a list and a bag. (It could be a list pretending to be a bag, 
though. Two different lists can pretend to be same bag, of course.:-)

>One thought I has was a bag representation sort-of like a set but 
>also having a repeat count for each member:
>     _:a bag:contains _:a1 .
>     _:a bag:contains _:a2 .
>     _:a1 bag:value "abc" .
>     _:a1 bag:count "1" .
>     _:a1 bag:value "def" .
>     _:a1 bag:count "1" .
>No entailment is needed to represet the equivalkent of permutation. 
>I think other entailments here work fine;  consider {* _:b1, _:b2 *}:

Yes, that works, but it requires that we have numbers as a primitive 
datatype, which will produce howls from the DAML description 

>     _:a bag:contains _:a1 .
>     _:a bag:contains _:a2 .
>     _:a1 bag:value _:b1 .
>     _:a1 bag:count "1" .
>     _:a2 bag:value _:b2 .
>     _:a2 bag:count "1" .
>if we then learn that _:b1 and _:b2 are equivalent,

....but wait. Do we want to consider reasoning with equivalences at 
all? That gets us into a whole lot of tar-pits which we might want to 
just try to avoid, maybe (please?)

>Another thought I had was to back of from direct entailment. 
>Returning to Dan's original formulation:
>>         _:b rdf:type rdf:Bag.
>>         _:b rdf:_1 "abc".
>>         _:b rdf:_2 "def".
>>         _:b rdf:type rdf:Bag.
>>         _:b rdf:_2 "abc".
>>         _:b rdf:_1 "def".
>to say instead that:
>        ex:subj ex:prop _:b1.
>         _:b1 rdf:type rdf:Bag.
>         _:b1 rdf:_1 "abc".
>         _:b1 rdf:_2 "def".
>        ex:subj ex:prop _:b2.
>         _:b2 rdf:type rdf:Bag.
>         _:b2 rdf:_1 "def".
>         _:b2 rdf:_2 "abc".

Yes, I think that will work, if we want to take bags slightly more 
seriously. So each permutation of a bag is a distinct thing, but they 
are all property-equivalent in that anything true of one must be 
transferrable to the others. In fact, without state, this is about 
the best we could do, I think. It basically allows all the states of 
the bag to be present at once. However it only works when we use a 
different bNode, right?

So heres the rule. If we have a triple

foo rdf:type rdf:Bag

in a graph, then say that the nodes which are in the object position 
of a triple of the form

foo rdf:_n <object>

in that graph are the 'foo member nodes'. Then any graph gotten by 
permuting the arcs to the foo member nodes, and replacing  the node 
foo by a new bnode, should be entailed by the first graph.

Tell you want, lets agree not to talk about rdf:Bag-closures, OK?


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 7 November 2001 17:14:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC