W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2003

RE: RDF Semantics: Interpretations and Modelling

From: Massimo Marchiori <massimo@w3.org>
Date: Wed, 5 Feb 2003 01:39:52 +0100
To: "pat hayes" <phayes@ai.uwf.edu>
Cc: Ossi Nykänen <onykane@butler.cc.tut.fi>, <bwm@hplb.hpl.hp.com>, "RDF-Interest" <www-rdf-interest@w3.org>, "Massimo Marchiori" <massimo@w3.org>
Message-ID: <NGBBJNKIMLOPPCFHEJEMKEKMDBAA.massimo@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])

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]

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 :)

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... ;)

> >You are saying:
> >a) conjoin is a valid operator
>
> Yes. To be very exact ( which I think I will add to the semantics
> doc, BTW, for clarification of this issue) the following lemma holds:
>
> Lemma. Suppose an RDF graph G entails a triple T. Then G entails G union {T}.
The whole lemma I stated as "conjoin is a valid operator" could just be stated, verbatim, that way, no? ;)
Literally translated in slightly less human-readable prose, it would be
Lemma: Given a set of RDF graphs S, S entails union(S)
but of course that's a matter of personal taste, your rewording is similar.

>
> Notice that this refers to adding a triple, not merge of a graph.
Well, in fact that's why it's defined as a new "conjoin" operator, and I didn't mention merge, no? (??)

> >b) adding BAGAX makes conjoin invalid
>
> No. Conjoin isn't invalid, and in any case the inference I sketched
> isn't *invalid*, it just kind of makes nonsense of any assertion
> about bags.

Having said what BAGAX is, you can now understand the sentence (right? :)

>
> >and using the above two, the claim in the Model Theory at the time,
> >and Semantics doc now, is:
> >
> >Because of a) and b), we can't add BAGAX
> >(which means, we can't support rdf:bag in the model theory)
>
> No, the RDF model theory DOES support bags. It always has done. There
> is no NEED to add any further inferences. That is what I am claiming.
Ditto.

> And, by the way. I have no idea what BAGAX is supposed to be.
>
> >
> >***
> >
> >What I am saying is:
> >
> >Mmm, I see that there's a claim that we can't support rdf:bag
> >That means we can't add BAGAX....
> >... but, wait, we can add BAGAX, so that can't be the reason to ban
> >the rdf:bag
>
> I have no idea what you are talking about. Nobody has ever suggested
> 'banning' rdf:bag.
I meant its properties. Of course the syntax term is still there, voided (no BAGAX).

> Its right there in the list of vocabulary items,
> it has a model theory, what more do you want?
Ditto, BAGAX.

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

>
> As for not using conjoin 'straight', by which I assume you mean,
> always re-name any nodeIDs in any conclusion,
Never said this (?). Just said, conjoin is not a valid operator any more.

> this will make
> virtually all RDF inference useless, eg it will not be possible to
> infer someone's name from knowing their phone number, since as soon
> as you make the smallest inference, the bnode identifying the thing
> you are talking about needs to be swapped, so its no longer the same
> thing any more. No logic can survive that kind of restriction:
> ordinary natural deduction rules for propositional logic would break
> under that restriction.
Skipped, for what said above.

>
> >------
> >
> >SUMMARY:
> >
> >We can then turn the discussion into
> >"for some reasons (@@space to fill in here@@), I do want conjoin of
> >graphs to be valid
>
> Its not an ad hominem issue. Conjunction IS valid, in almost every
> logic under the sun. How can it not be valid? If you know that A is
> true and B is true, how can you not agree that (A and B) is true?
Ditto as before. This is not conjunction in the RDF-logic, it is "conjoin"-or-whatever name you like.

>
> >, so much that I'm willing to give up the
> >rdf:bag facility",
> >
> >but that's a *totally different argument* from the straight
> >"we can't support the rdf:bag facility"
> >
> >I hope this clarifies the viewpoints and the core of the issue.
>
> Not for me, Im afraid. And Ive never said we can't support the
> rdf:bag facility. On the contrary, I think we do support rdf:bag.
Clarified above (support of rdf:bag == BAGAX inferences)

>
> >As rdf:bag was the normative standard (with its implicit BAGAX),
> >this is not a trivial issue at all.
>
> rdf:bag still is the normative standard. What has changed?
>
> >
> >Moral: we still need to document the proper reasons on why the
> >rdf:bag support is dropped (if it is dropped)
>
> 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'.
>
> You can use any formalism you like to state them.
>

--> Beginning of email ;)
Received on Tuesday, 4 February 2003 19:41:40 GMT

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