RE: RDF Semantics: Interpretations and Modelling

>  > [Ive taken this off the rdf-core list as its no longer a WG issue,
>>  seems to me.] - Pat
>Well, no problem, backing it up to www-rdf-interest.
>
>To the point:
>>  In order for me to respond to this, I need to know what it is exactly
>>  that you think is being 'dropped'. What entailments do you want, that
>>  are not valid at the present? I have no idea what you mean by 'BAGAX'.
>
>The extra inferences ("BAGAX" ~ BAG AXioms ;) are the usual permutation ones:
>   BAG(t_1,...,t_k)  ->  BAG(t_pi(1),...,t_pi(k))
>   (where pi is any permutation in [1,k])

These are not "usual" inferences. They are indeed usual *operations 
on* bags, in the sense in which a bag is a data structure being 
manipulated by a programming language, but that is not the same as an 
*inference about* a bag.  The intuition you are referring to here is 
that a bag is the same bag when its elements are permuted, right? 
Mathematically speaking, a bag can be regarded as an equivalence 
class of sequences under permutations: the ordering inherent on a 
sequence is 'factored out' in a bag. True, but you need to take some 
care when you propose to represent this *by means of inference*. You 
need to actually refer to the permutation somehow, either explicitly 
or implicitly. Doing it explicitly is obviously beyond the expressive 
capacity of RDF; but so is doing it implicitly. To do this means that 
you need a rule something like the following: that if A and B are 
rdf:bags, and if the elements of A are some permutation of the 
elements of B, then A=B. But how do we say that elements of A are a 
permutation of the elements of B? There is no way to say this in RDF, 
since there is no way to even know that we have listed all the 
elements of a container. It is not enough to simply 'permute' the 
elements that happen to be mentioned in a particular graph, since one 
might later discover that A but not B has another member which isn't 
listed in the graph one happens to have at the present time. And in 
any case, even if there were a way to 'close' a container - ie to 
assert that all its elements were listed - the required condition 
would have to be a semantic condition expressed as an inference rule 
with a conclusion about identity; but RDF(S) has no way to express 
identity. (The required conclusion could be stated in OWL.)

There is an additional complication, by the way. The RDF description 
uses urirefs to name the members of the bag. BUt two different 
urirefs might denote the same thing; so the number of things in the 
actual bag might be different from the number of names used to 
describe it. Again, most programming languages finesse or avoid this 
issue (by a unique names assumption or by treating names as a kind of 
pointer or reference or address under the hood) but it remains 
central in any descriptive language.

>
>In triples,
>
>_:xxx [rdf:type] [rdf:Bag]
>_:xxx [rdf:_1] <foo:a_1>
>...
>_:xxx [rdf:_k] <foo:a_k>
>
>entails
>
>_:xxx [rdf:type] [rdf:Bag]
>_:xxx [rdf:_pi(1)] <foo:a_pi(1)>
>...
>_:xxx [rdf:_pi(k)] <foo:a_pi(k)>
>
>
>for every permutation pi of [1,k]

This does not work. As explained earlier, this says that *every* item 
is in *every* position in the container, which I would guess is not 
what you intend it to mean. What you want to say is, if one were to 
permute the elements, then nothing would change. But that isnt what 
this inference says.  Permuting a description is not the same thing 
as describing a permutation. Permuting is an operation, which 
requires a state to get changed. Once permuted, the elements are no 
longer in their previous order, right? But assertions don't work like 
that: once you say something is in position 1, you have asserted this 
to be true, and just adding (concluding, inferring) an statement that 
it is in position 5 doesn't undo the previous assertion that is in 
position 1. So now you have concluded that it is in two positions at 
the same time. To 'do' the permutation, you need to do more than just 
infer that the items are all in some other position: you need to also 
"de-assert" your earlier claims that they were in the original 
positions. But there is no way to de-assert an asserted statement.

BTW, one might suggest that bags should be represented by a 
non-indexed container membership property, eg rdf:_in, say. But the 
trouble with this idea is that it provides for no way to put two 
copies of something into a bag, since

_:xxx rdf:_in a .
and
_:xxx rdf:_in a .
_:xxx rdf:_in a .

are obviously equivalent to one another. So this would make it 
impossible to even specify a bag.

>
>So now http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Feb/0035.html
>should become clearer (pls tell me if it's not yet), and can be 
>appropriately replied :)

You have confirmed what I thought you meant there, and I stand by my 
earlier reply.

>Thanks,
>-M
>
>ps
>Secondary points in the email (not needed for the above, just 
>clarification tidbits).
>Disclaimer: to avoid ratholes or mile-long emails, I'd suggest not 
>even replying to what below, and just replying again to the 0035
>email with the BAGAX clarification :) Or, well, extract relevant 
>parts if really needed... ;)

Just one comment (below):
.....

>  > >
>>  >Now, to solve the apparent contraposition:
>>  >what happens if we add BAGAX? That, conjoin becomes an invalid operator.
>>  >So, what? Who cares?
>>
>>  Anyone who ever wants to draw a conclusion in RDF or any extension of
>>  it. See below.
>>
>>  >There's no inconsistency. Just, don't use the "conjoin" straight on graphs.
>>  >(and, suggestion: you'd better use "merge" anyway... ;)
>>
>>  No, you really are missing the point. The validity of conjunction
>>  isn't declared by fiat, or as an option: it FOLLOWS from the
>>  truth-conditions. If you want A and B to not entail (A and B), you
>>  tell me how to state the truth-conditions so as to make it not be
>>  entailed.
>Please don't talk about conjunction here, we are talking about 
>"conjoin" or whatever you like to name it, and this renaming is just
>confusing. Conjoin is not the conjunction in the RDF-logic.

No, really, it is. Unioning two sets of RDF triples is *exactly* 
forming their logical conjunction. Check the truth-conditions; they 
are transcribed from a standard logical style for stating 
truth-conditions for Gentzen tableau (which also allow arbitrarily 
long conjunctions.)

.....

Pat
-- 
---------------------------------------------------------------------
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
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Wednesday, 5 February 2003 13:21:20 UTC