Hi Scot,

I agree, but I agree especially in an open world situation.
Suppose I model a closed world of some (flipper-mngt-software-application-input,
"
:hasChild rdfs:domain :Person
:Flipper a :Dolphin
:Flipper :hasChild :Joey
"

Would just be a wrong model since the domain clause was just too restrictive 
for the closed world knowledge at hand.

But ok, assuming open world, I guess any domain spec would be too ambitious 
since nobody can make such decision for the whole open world...

What makes me think: assuming open world, why do we have domain specs at all?

Michel


 
 
 
<Whe I say the domain for property y is X, I say also that it is not a property 
for any other class. >

Conceptually, this is true.  But also keep in mind that this is enforced in 
RDFS by inferring that any subject using the property y is inferred to be a 
member of X.  This leads to a consistent model, but may lead to unexpected 
inferences.  For example if you have the
triples:
:hasChild rdfs:domain :Person
:Flipper a :Dolphin
:Flipper :hasChild :Joey

Then you will infer:
:Filpper a :Person

...probably not a correct inference.  The point being that this type of error 
is extremely easy to do with global domain/range definitions.  And one of the 
reasons to prefer local restrictions.

If you instead want to enforce this by raising a warning when the domain/range 
do not match the definitions, you can use SPIN constraint violations.  
spinrdfs.owl (in TopBraid/TBC) provides an example of this for range 
definitions.

-- Scott

On Jan 11, 3:01 am, "Bohms, H.M. (Michel)" <[email protected]>
wrote:
> 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
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