Re: Domains and Ranges, based on Why the encapsulation?

Bijan,

Thanks for your detailed response.  This seems to fit my "reality" better.

Jim 




Bijan Parsia <bparsia@cs.man.ac.uk> 
Sent by: public-owl-dev-request@w3.org
09/24/2007 02:54 AM

To
James A Miller <James_A_Miller@Raytheon.com>
cc
"public-owl-dev-request@w3.org" <public-owl-dev@w3.org>
Subject
Re: Domains and Ranges, based on Why the encapsulation?







On Sep 23, 2007, at 9:02 PM, James A Miller wrote:

> Hello Danny, Michael, Emanuele, and the rest of you subcribers,
>
> I have a recurrent question, inspired again by the "Why the 
> encapsulation?" discussion:
>
> I have been told, by more than one source, that domains and ranges 
> should *not* be used in (up to) 99% of the cases.  The preference 
> is to use restrictions, due to issues with reuse and  inheritance 
> (among others?).

I suspect that the point would be that Domain and Range are fairly 
blunt tools being global.

>  I'm curious whether subscribers to this list agree.

I used to feel more strongly about it than I do now. It depends on 
your style.

> I have tried to follow this approach, but it seems that I am often 
> defining properties that *really* apply only to one domain class 
> and one range class, so I use domain and range, violating this "99% 
> rule".

Maybe all your cases are in the 1% :)

A lot depends on the kind of property tree you are developing. 
Consider having a property "has" vs. "hasColor" or "hasPart" vs. 
"hasSmallPart". The more specific your property, the more likely a 
"globalizing" domain or range makes sense. Conversely, if you made 
the range of "has" to be the class "Color" you're precluded using it 
for Tastes, etc. If you have a lot of "typed properties" i.e., 
properties that have their range built into the name, the the domain 
and range work, but now you have a proliferation of properties (and 
their attendant domain and ranges). Conversely, if you have fewer 
more generic properties, they will carry less information and so may 
be harder to use or harder to determine the intent of a use. Lots of 
repeated restrictions instead of a single global declaration doesn't 
seem to great either unless there's some *reason* for the repetition.

If you have a property that clearly belongs to one branch in your 
class hierarchy, then you can domain/range it high in that branch and 
use local restrictions to say more specific things about it.

So, if you have "spatialThing" and "mentalThing" branches, and you 
may want to restrict "hasPart" or "hasSpatialPart" to range over 
spatialThing (and domain over it). But there may be some spatial 
things that have 5 parts, or have no parts! Local restrictions can 
handle that.

The other issue is that multiple domains and ranges are interpreted 
as intersections. If you want union semantics, you need to use 
restrictions.

I supect that part of this style thing comes from the fact that 
description logics didn't have domain and range, so there wasn't a 
lot of exploration on how they might be effectively used and they 
*can* limit you. A similar case would be forbidding inverse axioms 
since you can always use an operator. (No one recommends this, 
afaik.) So, OWL (IIRC) *only* allowed inverse axioms, so every time 
you wanted to say something about an inverse, you had to coin a new 
name. In OWL 1.1 (again, IIRC) there is an operator that lets you 
build an "inverse expression" which you can use instead of the named 
inverse. I don't know I could make a decent general rule for when to 
use either. It depend son you, your audience, your application, and 
the things you are trying to say.

Cheers,
Bijan.