- From: Christopher Welty <welty@us.ibm.com>
- Date: Fri, 22 Oct 2004 09:33:26 -0400
- To: Alan Rector <rector@cs.man.ac.uk>
- Cc: Pat Hayes <phayes@ihmc.us>, best-practice <public-swbp-wg@w3.org>, public-swbp-wg-request@w3.org
- Message-ID: <OF8A1B2521.E7AF45DC-ON85256F35.0046BBAA-85256F35.004A78CA@us.ibm.com>
Alan,
That's what I thought you meant, but I don't consider it an asymmetry at
all, because you have a universal restriction on one "direction" and an
existential restriction in the other. While this is certainly something
to point out in a note somewhere, I don't think it is as much of a problem
since OO doesn't have a notion of "some values from" anyway, so there is
less chance, I think, of people with an OO background confusing it with
something they already do.
I think there are two problems that OO people have in understanding the
logical semantics of OWL:
1) Semantics of "slot attachement" in OO: If I define two classes C1 and
C2, and say C2 is a subclass of C1, and C2 has a "slot" called "name"
whose value is a string. What this means in an OO language is that if I
create an instance of C1 (the superclass), it (the instance) CANNOT have a
value for the slot "name". There is a notion of "introduction" down a
class hierarchy that we have a real problem capturing in logical
semantics. There is no way to say this in OWL. It's tempting to think
that something like:
class C2 extends C1 { String name; }
is the same as:
subclass(c2 c1)
Class(c2 partial restriction(name allValuesFrom String))
but they mean something different. In the former, an instance of C1 (and
only C1) does not and CANNOT have a value for name.
2) domain and range restrictions. In an OO language, to begin with you
don't have global restrictions on "slots" or "fields". This is less of a
problem to explain - since it doesn't exist in OO I have found people have
less trouble understanding it because they aren't assuming apriori that it
works the same as something they are familiar with. The danger arises in
local range restrictions. So, if we add a third class C3 to the example,
that has a property P all of whose values are instances of C2, we'd have
something like this in Java:
class C3 {P C2;}
This is not equivalent to:
Class(c3 partial restriction(P allValuesFrom C2))
Because there is no way in (first order) logic to say the OO meaning,
which is something like "only objects that are primitive instances of C2
can be the value of P". I'm introducing the notion of "primitive
instance" here, as a label for a concept that exists in OO and not in
first-order logic (and thus, not in OWL). In OO, there is the
understanding that instances/objects (I use the terms synonymously here)
are "created" at some point. This point in time is a critical one for the
object, and for understanding the semantics of OO models. At creation
time, objects are assigned a SINGLE "class". This class stays with them
for their entire existence, and is essential to their nature. At the time
of creation, any "relations" the object can have must have been defined on
the class (or inherited from superclasses) as slots or fields. This
cannot change for the object's existence. Thus when I create an instance
of class C1 above, it has no "slots" and thus the fact that I chose to
make this object an instance of C1 prevents me from ever giving it a
relation.
Furthermore, in OO I cannot put a value into slot P of an instance of C3,
unless that value is a primitive instance of C2 (or a subclass of C2). It
simply can't be done. The idea that if a put a value there it "becomes"
an instance of C2 is totally alien to the OO mindset.
Note that historically, this was not always true of OO languages.
-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.7455
Email: welty@watson.ibm.com, Web:
http://www.research.ibm.com/people/w/welty/
Alan Rector <rector@cs.man.ac.uk>
Sent by: public-swbp-wg-request@w3.org
10/22/2004 06:07 AM
To
best-practice <public-swbp-wg@w3.org>, Pat Hayes <phayes@ihmc.us>
cc
Subject
Asymmetry of Domain and Range in OWL
Pat, All
Sorry for not giving a clear explanation last night. There are slides (as
soon as our server comes back)
at www.cs.man.ac.uk/~rector/papers/common-errors-ekaw.html. The slides
(available in both pdf and .ppt) have the clearest explanation of the
point - towards the end.
I summarise in N3 notation below..
Supposed I have a property
:has_topping
a owl:ObjectProperty ;
rdfs:domain :Pizza ;
rdfs:range :Pizza_topping .
And classes
:Pizza
a owl:Class .
:Pizza_topping
a owl:Class .
:Ice_cream
a owl:Class .
:Ice_cream_cone
a owl:Class ;
And I add an existential restriction that 'violates' both the domain and
range restrictions, say
:Ice_cream_cone
rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :has_topping ;
owl:someValuesFrom :Ice_cream
] .
If there are no disjoint axioms, then what happens is that Ice_cream_cone
is classified as a kind of Pizza, and is satisfiable. The 'violation' of
the range restriction is ignored.
If there are disjoint axioms, then Ice_cream_cone is unsatisfiable if
either the domain or range constraint is violated, but there is no effect
on Ice_cream, because the statement is about 'some Ice_cream' rather than
'All Ice_cream'.
New users find confusing the fact that 'violation' of domain constraints
can cause things to be reclassified (programmers tend to call it
'coerced') but range constraints cannot. (except if the inverse property
is used, in which the domain and range swap roles)
I put 'violation' in scare quotes because, of course. without the
disjoint axioms, it isn't really a violation according to OWL semantics,
but it is almost certainly an error in the sense of not being what the
user intended.
Regards
Alan
--
Alan L Rector
Professor of Medical Informatics
Department of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL: +44-161-275-6188/6149/7183
FAX: +44-161-275-6236/6204
Room: 2.88a, Kilburn Building
email: rector@cs.man.ac.uk
web: www.cs.man.ac.uk/mig
www.opengalen.org
www.clinical-escience.org
www.co-ode.org
Received on Friday, 22 October 2004 13:35:30 UTC