Thanks for your advice. The QCR approach we currently use for the hasPart 
relationship which is indeed very flexible without constraining hasPart itself 
as such.

The only issue I have with restriction: is it really the same?

Whe I say the domain for property y is X, I say also that it is not a property 
for any other class. Via restrictions I would have to add a maxcard=0 for any 
other class wouldn't I? (since the default is uncostrained..)

Ch/Michel 


 
 
 

   TNO.NL

 

Michel Böhms

Consultant Building Innovation
 

TNO Built Environment and Geosciences

Van Mourik Broekmanweg 6 | PO Box 49 

2600 AA | Delft | The Netherlands

 

 

Tel +31 15 2763107

E-mail  [email protected]

Web http://www.linkedin.com/in/michelbohms

Skype name michelbohms

 

 

Disclaimer 

 

 
 
 
 
 
 

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Irene Polikoff
Sent: donderdag 7 januari 2010 18:02
To: [email protected]
Cc: Bonsma, P. (Peter)
Subject: RE: [tbc-users] multiple domains?

I second the restriction recommendation. Restrictions are local to a class as 
opposed to being global - as domains and ranges are.

They are also open ended. You can keep on adding new restrictions without 
impacting what was stated before. With unions, you can't simply add new 
statements, you have to retract the existing one. This means they impact 
modularity and you are likely to have problems merging two models which are 
using the same property.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Holger Knublauch
Sent: Thursday, January 07, 2010 3:44 AM
To: [email protected]
Cc: Bonsma, P. (Peter)
Subject: Re: [tbc-users] multiple domains?

On Jan 6, 2010, at 11:53 PM, Bohms, H.M. (Michel) wrote:

> Ok, what we will do in our owl-generation:
> - if range is different: change propertyname (make it globally unique)
> - if range is the same: merge domains via union
> 
> Guess this is the way to handle it?
> (we are coming from languages that define properties as secondary 
> concept
not as prime concepts  on the same level as classes so we have to adapt a
bit...)

Yes this should work. We had the same problems several times when attempting to 
convert UML or XML models to RDF/OWL.

An alternative to using rdfs:domains, is to define owl:allValuesFrom 
restrictions (or cardinality restrictions + range). This may make your data 
structures easier to manage, and is another way of "attaching" a property to a 
class.

Holger


This e-mail and its contents are subject to the DISCLAIMER at 
http://www.tno.nl/disclaimer/email.html

-- 
You received this message because you are subscribed to the Google Groups 
"TopBraid Composer Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/topbraid-composer-users?hl=en.


Reply via email to