<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
-- 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.
