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

In UML design (and in ER conceptual design) all the (binary)  
properties (aka associations or relations in that realm) have a fixed  
unique domain and range, since an association happens to be between  
two classes (or a relation between two entities) that by definition  
are its domain and its range. This leads to an explicit  
multiplication of associations, each for each local context. Of  
course, you could relate all those associations via specialisation/ 
generalisation or equivalence.
 From a conceptual design point of view, this makes more sense to me,  
even in an onotlogy/DL/OWL context.
I am a multiplier...
cheers
--e.

On 24 Sep 2007, at 09:54, Bijan Parsia wrote:

>
> 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 15:20:30 UTC