Re: On UML as a presentation syntax for OWL

Pat,

My point was that the semantics of UML are currently associated with OO 
languages, and that the semantics of OWL are different in several ways, 
some of which are a bit subtle, as in this example.  If we are to use UML 
as a presentation syntax for OWL we must:

- be aware of the differences in the semantics
- decide whether a UML diagram for OWL should have a slightly different 
semantics (in terms of how it maps to OWL) than a UML diagram for an OO 
language, or try to mimic the OO semantics of UML.

Don't be fooled by the fact that this seems obvious. 

-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




pat hayes <phayes@mail.coginst.uwf.edu>
05/21/2002 04:21 PM

 
        To:     Christopher Welty/Watson/IBM@IBMUS
        cc:     www-webont-wg@w3.org
        Subject:        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.

OK.

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

Of course. However, if you had SAID that it was a Q and not a P and 
had no R, then things would have been different.

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

Ah. OK, then indeed we should be careful to say that OWL is not an OO 
language. This should give no cause for concern since OWL isn't a 
programming language in any case, so the question if its being OO or 
not shouldn't really even arise.

>  So if I create an instance of Q, I can not give
>it a value for R.

I'm not sure what you are saying here. It seems that the OO fragment 
given above means something different from the the FOL/OWL fragments. 
I guess that my reaction would be, so why then did you put them 
together? It seemed like you were saying that they were equivalent, 
but they aren't. OK, so what? Is your point that there is no way in 
the OO language of saying the FOL/OWL content (so what?) or that 
there is no way in FOL/OWL to say the content expressed by the OO 
fragment (clearly false for FOL, but maybe an issue for OWL (?))

Pat

>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 16:46:15 UTC