W3C home > Mailing lists > Public > public-owl-dev@w3.org > October to December 2007

RE: [OWLWG-COMMENT] Punning and the "properties for classes" use case

From: Michael Schneider <schneid@fzi.de>
Date: Tue, 6 Nov 2007 10:36:39 +0100
Message-ID: <0EF30CAA69519C4CB91D01481AEA06A04A8FC7@judith.fzi.de>
To: "Pat Hayes" <phayes@ihmc.us>, "Bijan Parsia" <bparsia@cs.man.ac.uk>
Cc: "Owl Dev" <public-owl-dev@w3.org>

Hi, Bijan and Pat!

Pat Hayes wrote:

>Bijan Parsia wrote:

[snip]

>>Ad esse, ad posse est. Frankly, I've grown ever more strongly 
>>against hilog semantics (= entailing iff) because it's really hard 
>>to understand (what happens with a disjunctive equality?), and the 
>>actual worthwhile examples are non-existent.
>
>Well... not quite. They may be little known in the DL world, but 
>several projects have used and relied upon having genuine equality 
>(in OWL 1.1 terms, equal-individual implies equal-class) critically 
>in Common Logic and IKL.
>
>>Most people don't even know about the possibility. I explained it to 
>>one owl full advocate and he said, "Oh, that's really a bug, isn't 
>>it?"
>
>Yes, you have repeated that anecdote several times. Apparently some 
>people don't understand OWL-Full. Sigh. In fact, however, in a full 
>logic the hilog, aka CL, semantics are extremely simple to 
>understand, and the resulting logic extremely simple to use and to 
>follow. An equation between two names (of any 'sort') means that 
>anything - ANYTHING - said with one of them is logically equivalent 
>to the same thing said with the other. That really is all that it 
>amounts to. Duh. If you worry why equivalent-class (eg) doesn't imply 
>equal-class, note that the hilog semantics distinguishes classes from 
>class extensions, which is a real win, both semantically and 
>computationally (and one that is lost with punning.)
>
>One way to say this in punning terms is that the genuine equality in 
>OWL-1.1 is the intersection of sameAs, equivalentClass and 
>equivalentProperty; and that *this* should be a primitive, because 
>this is the relationship with the most coherent logic. In a weak 
>punning language like OWL 1.1, sameAs no longer means 'same as'. It 
>amounts to equality on only part of the universe, or perhaps better 
>only one facet of a multifaceted universe. In fact, OWL 1.1 simply 
>doesn't have a genuine equality, which IMO makes it a very faulty 
>language.
>
>>I regard relying on that entailment (esp. for alignment) as a total 
>>anti-pattern.
>
>(= a b)  & (P a) entails (P b) is an anti-pattern?? This way 
>madness lies.
>
>>Much better would be, after a merge, do query for all equalities 
>>involving individuals which pun classes, then review them manually 
>>to see which you actually think should push equivalences.
>
>What are the criteria for this decision? What does it mean for an 
>equality to not 'push an equivalence'? Got any examples? Equality is 
>supposed to mean that the two names denote one single thing, right? 

This has always been my viewing of the situation, too. But now, after
reading your (Bijan's and Pat's) two mails, I think there is also another
possible (and adequate(?)) view:

  * _View 1:_ If I read ":a owl:sameAs :b", then I look how the URI refs
":a" and ":b" are interpreted. If and only if they point to the same
resource in the universe, then the statement ":a owl:sameAs :b" is true. I
would call this view the "interpretation equality".

  * _View 2:_ If I read ":a owl:sameAs :b", then I compare the full
descriptions of :a and :b, i.e. I check if every property assigned to :a is
also assigned to :b, and vice versa. If and only if this is the case, then
the statement ":a owl:sameAs :b" is true. I would call this view the
"description equality".

If I accept View 1, i.e. if I regard the URI refs ":a" and ":b" just as
different names for the same entity, than it is trivially true that :a and
:b share both the same set of properties and - if a class resource is
denoted - also the same extension. And whatever else can be shared by :a and
:b will be shared, because it's the same resource in the universe.

If I accept View 2, i.e. if I only compare the descriptions of :a and :b,
then I see two problems:

  1) I can imagine (I don't know if this is possible) that there are two
/different/ entities in the universe which happen to have the same set of
properties assigned (same description). At least (this might be a naive
argument): If I have an RDF graph, where two different URIs ":a" and ":b"
have the same properties, I cannot simply say that :a and :b are the same,
and then remove all triples having ":b" as a subject from the graph without
changing the graph's meaning.

  2) I am not sure if the whole set of properties of some class resource
already uniquely determines the extension of this class. I would rather
believe that this is not the case.

So by accepting View 2, I can at least imagine that it is possible that
there are two different class resources in the universe, which happen to
have the same description (set of assigned properties), but have different
extensions. Thus, under View 2 I wouldn't have any problem with a missing
"sameIndividual->equivalentClass" entailment, or stronger, I would rather
regard it as a bug to have it. And by accepting View 2, punning does not
seem to be a problem to me anymore (I have to think a little further about
this, but at least I cannot see any immediate problem in this case).

I think that Pat is a "View 1 guy", and so am I, or at least have been until
yet. Bijan might be a "View 2 guy", but I am not certain. Other people, who
do not see a problem with punning, might also be "View 2 guys". I am not
quite certain in the moment which view I will prefer in the future. My
feeling is that View 1 is easier to keep in mind (it is very consequent),
but, at least from a technical point of view, I do not see why View 2 should
not also be legitime. So I am suddenly, in the moment, somewhat neutral on
this.

But I believe that RDF semantics, as described in the RDF semantics spec,
are strictly intended to be View 1. Pat, is this right? And if this is the
case, then I think that it is necessary to further investigate whether
punning conflicts with the possibility to define an RDF compatible OWL-1.1
semantics. 

Cheers,
Michael

>Interpreted as names of classes, why does this not mean being the 
>same class?
>
>>Punning allows you to do this easily.
>
>It leads to confusion and puzzles about identity, seems to me. The 
>fact that you have to invoke mysterious manual interventions to draw 
>conclusions seems to be a symptom of that.
>
>>Mashups require some human intervention. I see no reason why 
>>ontology mashups wouldn't.
>
>Having equality in the language is not a "mash-up".
>
>>Though it is good to be able to merge them and do *something* 
>>without getting a syntax error. That's what punning gives you.
>
>But so do many other treatments. Of course one should be able to do 
>this, but this isn't a vote for punning, its a vote against having 
>anal DL-style syntax restrictions in place.
>
>Pat
>
>>>Nevertheless, the most
>>>relevant point is to first have such a use case document. 
>And also I want to
>>>have a technical specification of punning, because I have 
>the feeling that
>>>there is still no common agreement on what punning provides 
>and what not.
>>
>>See the semantics document from OWL 1.1. See Boris's paper:
>> 
>>	
><http://web.comlab.ox.ac.uk/oucl/work/boris.motik/publications/
>motik07metamodeling-journal.pdf>
>>
>>wherein it's called "contextual semantics" or pi-semantics.
>>
>>There are multiple implementations. I don't know where you get your 
>>feeling from, but it seems rather off to me.
>>
>>Cheers,
>>Bijan.
>
>
>-- 
>---------------------------------------------------------------------
>IHMC		(850)434 8903 or (650)494 3973   home
>40 South Alcaniz St.	(850)202 4416   office
>Pensacola			(850)202 4440   fax
>FL 32502			(850)291 0667    cell
>phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
Received on Tuesday, 6 November 2007 09:36:53 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:55 GMT