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                                                                                                                                           (

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