- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Wed, 7 Nov 2001 16:14:14 -0600
- 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
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0150.html
>you said, in response to DanC:
>
>[[[
>DanC:
>> _:b rdf:type rdf:Bag.
>> _:b rdf:_1 "abc".
>> _:b rdf:_2 "def".
>>
>>entails
>>
>> _:b rdf:type rdf:Bag.
>> _:b rdf:_2 "abc".
>> _:b rdf:_1 "def".
>>
>>and generally: the _n arcs of a bag can be permuted.
>
>PatH:
>
>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
logicians.
> _: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".
>>
>>entails
>>
>> _: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".
>
>entails:
>
> 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?
Pat
--
---------------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola, FL 32501 (850)202 4440 fax
phayes@ai.uwf.edu
http://www.coginst.uwf.edu/~phayes
Received on Wednesday, 7 November 2001 17:14:20 UTC