RE: RDF Semantics: Interpretations and Modelling

From: pat hayes <phayes@ai.uwf.edu>
Date: Wed, 5 Feb 2003 12:23:04 -0600
Message-Id: <p05111b08ba66fd07cd6a@[10.0.100.86]>
To: "Massimo Marchiori" <massimo@w3.org>
Cc: Ossi Nykänen <onykane@butler.cc.tut.fi>, <bwm@hplb.hpl.hp.com>, "RDF-Interest" <www-rdf-interest@w3.org>
```
>  > [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

>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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:58 GMT