Re: On UML as a presentation syntax for OWL

Pat,

I recently retracted the "defined/primitive" comment.  It was based on an 
older syntactic distinction in DLs.

My third point still stands.  Here's an example:

If we have two classes, P and Q.  All Ps are Qs.
I have one relation, R.  All Ps have at least one R.

In FOL I would have:

(all (x) (-> (p x) (q x)))
(all (x) (-> (p x) (exists y (R x y))

In OWL I would have something like
P: (and Q (at-least 1 R))

In an OO (C++ here), I would say something like:
class P : public Q {
  Object* R;
}

There are already subtle differences in the way I wrote these three 
things, but my point was that, if I create an instance, and at the time I 
create it all I assert is that it is a Q, in FOL and OWL there is nothing 
preventing me from later stating that instance has a value for R, and 
nothing preventing me from later saying that instance is a P.  In most 
OO's that I know about, when you "instantiate" a class, you get the 
slots/relations of that class, and you are syntactically prevented from 
referencing any other slots/relations, even if those slots/relations are 
allowed for subclasses.  So if I create an instance of Q, I can not give 
it a value for R.

SO this isn't really about the semantics of subclass, but of 
instantiation, and what kind of monotonic additions one is allowed to 
make. 

-Chris

Dr. Christopher A. Welty, Knowledge Structures Group
IBM Watson Research Center, 19 Skyline Dr.
Hawthorne, NY  10532     USA 
Voice: +1 914.784.7055,  IBM T/L: 863.7055
Fax: +1 914.784.6078, Email: welty@us.ibm.com




patrick hayes <phayes@ai.uwf.edu>
Sent by: www-webont-wg-request@w3.org
05/18/2002 11:00 PM

 
        To:     Christopher Welty/Watson/IBM@IBMUS
        cc:     www-webont-wg@w3.org
        Subject:        Re: On UML as a presentation syntax for OWL

 

>In my PhD. thesis which used Classic to represent a simply ontology of
>object-oriented program constructs, I pointed out three subtle but
>important differences in the way description logics and object-oriented
>languages structure and represent information.  While the semantics of 
UML
>is still not completely clear, the link to OO languages has set a 
de-facto
>semantics on the subclass relation (unfortunately called "inheritance" in
>that community).   Most of this de-facto semantics comes from the way UML
>tools generate code in OO languages such as Java and especially C++.
>Unfortunately, this semantics is not logical.
>
>The more obvious of the three differences is that there is no notion of
>"primitive" vs. "defined" classes as there is in DLs.  Generally,
>primitive classes state only-necessary conditions and defined classes
>state necessary and sufficient conditions for class membership.  In this
>sense, all OO classes are DL primitive-classes.  There is no notation in
>UML to make such a differentiation.

I find this distinction logically meaningless. That is, the 
distinction between the two kinds of conditions is meaningful, of 
course; but that is a distinction between two kinds of assertion 
about classes, not about two kinds of *class*. Classes are just sets, 
and there is only one kind of set. If I give you necessary conditions 
for membership a set, then later give you some more information about 
it so that you now have necessary and sufficient conditions on 
membership in the set, the set itself has not changed, only what you 
know about it.

>The second difference is that "associations" in UML are not global.  They
>explicitly link two classes, thus defining both domain and range
>restrictions.  A more subtle point, however, is that in the negative case
>- that is the case in which an association is not present in a class - 
the
>association CAN NOT be present on instances of the class.  This may seem
>like an obvious extension of the previous point about domain/range
>restrictions, except in the presence of the final difference.
>
>The final difference is in the way the introduction of associations is
>treated in subclasses.  This is the most confusing point, and does not 
fit
>into any intuitive logical understanding of the subclass relation.
>Normally, we think of subclass to be, quite simply, if P is a subclass of
>Q, then, logically (using the KIF FOL serialization): (FORALL x (=> (P x)
>(Q x))).  So if we defined class Q such that all instances have an
>association R1, we implicitly define that all instances of P have the
>association R1.  HOWEVER: if we define class P (the subclass) such that
>all instances of P have an association R2, instances of Q that are not
>instances of P CAN NOT have the association R2.  So, "direct instances" 
of
>Q (the superclass) can not have the association R2.

Well, Chris, you certainly have me confused. The above paragraph 
seems to fit with my understanding of the subclass relation. As you 
describe it, there are three classes Q, P and (Q-P), the last two 
being disjoint subclasses of Q; everything in Q has an association 
R1, and everything in P, but nothing in (Q-P), has an association R2. 
That all seems quite sensible and conformant to the normal meaning of 
subclass. We could even define P as the subclass of Q which has the 
association R2. (Actually I have no idea what 'having an association' 
means, but that doesn't seem to matter.) So where is the "lack of 
fit" that you are talking about?

Pat

Received on Tuesday, 21 May 2002 09:31:32 UTC