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: Pat Hayes <phayes@ihmc.us>
Date: Tue, 6 Nov 2007 13:44:38 -0600
Message-Id: <p06230902c3566a17e57e@[10.100.0.38]>
To: "Michael Schneider" <schneid@fzi.de>
Cc: "Owl Dev" <public-owl-dev@w3.org>, "Bijan Parsia" <bparsia@cs.man.ac.uk>

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

Right, this makes perfect sense, *provided that* 
the 'resource in the universe' reflects the whole 
meaning of the name, as it does in RDF, RDFS, 
OWL-1, Common Logic and classical FOL. owl:sameAs 
then means equality, i.e. being the same thing 
as. Unfortunately, in the case of punning it does 
not, because the use of the name in 
non-individual positions makes it denote 
something which is *not* in the universe.

>   * _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".

One problem with this (IMO) is that even if this 
is the case it doesn't follow that the properties 
and classes (you have to also cover classes) are 
*identical*, at most that they have identical 
extensions. But even if one is a staunch 
extensionalist, it isn't practical, since it may 
not be possible to check all those properties. 
Moreover, it will be non-monotonic, since new 
properties might appear later which would 
distinguish the names even when used as property 
names. Similarly for classes.

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

It does if you construct the semantics so that 
'being the same thing' means what it says, which 
gives one the hilog/common-logic/rdf style rather 
than the punning style. In punning, "being the 
same thing" only covers part of the intended 
meaning since it excludes classes and properties. 
Two names can 'be the same thing' and still be 
different classes/properties (because classes and 
properties aren't counted as 'things'. Which, 
incidentally, is based on a common 
misunderstanding about Tarskian semantics.)

>  And whatever else can be shared by :a and
>:b will be shared, because it's the same resource in the universe.

Quite. That is the basic intuition behind the CL 
semantics, which also underlies RDF and RDFS and 
OWL 1.

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

Yes. That is possible in any logic with equality.

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

It might in some cases, but not in general.

But the real problem is that in order to be 
effective, this requires a nonmonotonic logical 
framework. (Or a closed world of 
properties/classes.)

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

Yes... also for view 1, by the way... BUT...

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

I think that is a misunderstanding. Even if we 
want to distinguish between a class (say) and its 
extension, it is still the case that each 
class-thing has a unique extension. So if two 
class names denote the same class - if they are 
asserted to be the same class-thing - then they 
must have the same class extension. That is 
exactly the argument that leads to the 
Hilog/CL/RDF semantics, where there are explicit 
extension functions from things to class (and 
property) extensions.

It is important not to think of "individual" as a 
kind of classification. Calling something an 
"individual" just means that it is in the 
universe of discourse (can be named, is counted 
when one quantifies, can be in a class, can have 
properties, etc..; and most saliently for this 
discussion, can be asserted to be equal). It is 
not a taxonomic classification into some 'type' 
of thing: ANYTHING can be an individual (even in 
classical FOL). So, in particular, a class or a 
property can be an individual. To say that a=b 
(aka, owl:sameAs a b .) is to say that there is 
one thing that the names "a" and "b" both denote. 
If this denoted thing is a class, or a property, 
this is STILL what equality (aka owl:sameAs) 
should mean. Punning screws up this basic logical 
device beyond the possibility of easy repair. And 
equality is really basic: in many texts it is 
considered to be part of the fundamental logic, 
like the connectives and quantifiers.

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

See above.

>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 suspect that people who like punning see it as 
purely a syntactic hack for allowing conventional 
GOFOL reasoning to be handled without causing too 
much syntactic grief. And if one ignores 
equality, it is just that: in fact, if one 
ignores equality, punning and the Hilog/CL/RDF 
approach are equivalent in almost all cases. So 
the choice between them should turn on the extent 
to which they make sense of equality: and punning 
is a major loser in that regard.

I gather from a brief conversation with Peter 
(though this was over a year ago) that the choice 
of punning over the Hilog/RDF semantics was 
motivated by wanting to actively block the 
sameAs==> sameClass inference, because the 
presence of this entailment made some of the DL 
search algorithms less efficient. (So it is not a 
case of developing punning and then discovering 
it to be, whoops, incompatible with RDF: it was 
deliberately *designed* to be incompatible with 
RDF.) I strongly believe that this is bad SWeb 
engineering. The semantic clarity of the 
Hilog/RDF approach, most notably in its coherent 
approach to equality, seems to be more important 
for interoperability than the requirements of the 
current computational state of the art, which is 
a moving target in any case. The only cost in 
practice of adopting the RDF (and ISO CL and RDFS 
and IKL and OWL')-compatible semantics over the 
punning semantics will be that some of the first 
generation of OWL1.1 reasoners will be slightly 
incomplete w.r.t. the published semantics. IMO 
incompleteness, especially for marginal cases, is 
a vanishingly small price to pay for semantic 
clarity.

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

Yes, but one has to remember that the semantics 
as stated there does *not* prohibit classes and 
properties from being treated as individuals, as 
the DL semantics does. In ISO Common Logic terms, 
it is not a segregated dialect.

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

Actually I think an RDF compatible OWL 1.1 
semantics could be constructed, but it would be 
highly artificial and, worse, incompatible with 
the OWL 1.0/RDF semantics. I wonder why we are 
even discussing such a baroque possibility at 
this stage of SWeb deployment.

Pat

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


-- 
---------------------------------------------------------------------
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
Received on Tuesday, 6 November 2007 19:45:14 GMT

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