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.

Received on Monday, 24 September 2007 07:55:26 UTC