Re: Asymmetry of Domain and Range in OWL

I think we are all in agreement on the major points and were merely 
nit-picking at the logical level and choice of descriptive terms.  So I 
suggest we all await the first draft and then continue nit-picking then 
;-)

-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/25/2004 02:49 AM

To
Christopher Welty/Watson/IBM@IBMUS
cc
Pat Hayes <phayes@ihmc.us>, best-practice <public-swbp-wg@w3.org>, 
public-swbp-wg-request@w3.org
Subject
Re: Asymmetry of Domain and Range in OWL






Chris, all 
Opening my mail after the weekend, I rest my case that the issue is 
confusing, regardless of how we describe it.   ...and that it leads on to 
other subtleties in the differences in how OO and DL people think about 
things. 
I agree entirely with Chris - and think I said - that this isn't an 
'asymmetry' from a logician's point of view, but I will assert from having 
watched learners struggle with it that it is surprising to them and seems 
"asymmetrical" when they first meet it. 
We need to be very careful about what words we use, but the fact remains, 
that the inferences made about violations of domain constraints are 
different from those made about violations of range constraints - in any 
DL - whereas in most other systems, either simply produces an error 
message. 
Alan 
 
Christopher Welty wrote: 
  
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 
 
 
-- 
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