This question really boils down to what one is trying to do. There are
various tradeoffs and nuances.
If you want to stay within RDFS semantics, then saying that
ex:price a rdf:Property.
ex:PricedObject a rdfs:Class .
ex:price rdfs:domain ex:PricedObject .
ex:Clothing rdfs:subClassOf ex:PricedObject .
ex:Car rdfs:subClassOf ex:PricedObject .
Does not entail
ex:price rdfs:domain ex:Clothing.
ex:price rdfs:domain ex:Car.
All it means is that if :x ex:price :someprice, then :x a ex:PricedObject .
Meaning that any resource which is a subject of a triple where ex:price is a
predicate, must ultimately be a member of ex:PricedObject class. However, it
does not mean that every member of this class has this property, thus there
can be subclasses of ex:PricedObject whose members do not have prices.
Because of this, there is no way in RDFS to "inherit" a property association
down the class hierarchy. But if you are writing custom code to interpret
the ontology, you can make any conclusion you want including conclusions
that are not part of RDFS rules.
Restrictions work in a different way, they do propagate a property
association down the class hierarchy, so if you say:
ex:pricedObject minCardinaly = 1 onProperty :price (or use someValuesFrom
restriction), you are indeed saying that any member of any subclasses of
ex:PricedObject must have this property.
But you are not saying that some resource that is not a member of
ex:PricedObject cannot have this property.
There is a way to say this with restrictions. It would involve an inverse of
ex:price. So, if you had an inverse property ex:priceOf, you could then say
ex:Price allValuesFrom ex:PricedObject onProperty ex:priceOf
Obviously, this would only work with object properties.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Holger
Knublauch
Sent: Monday, January 11, 2010 4:10 AM
To: [email protected]
Cc: Bonsma, P. (Peter)
Subject: Re: [tbc-users] multiple domains?
Yes, as long as you only define local restrictions, the property could also
be used at other classes. So it does not mean the same as a global
rdfs:domain.
BTW, in addition to owl:unionOf, another style of attaching a property to
multiple classes via rdfs:domain is to define an artificial superclass and
then use multiple inheritance. This is comparable to the notion of
"interfaces" in Java and other OO languages. For example, if you have a
property
ex:price a rdf:Property
which you want to make available to all classes that can have a price (e.g.
ex:Clothing and ex:Car), then you can introduce a class
ex:PricedObject a rdfs:Class .
and then add
ex:price rdfs:domain ex:PricedObject .
and make ex:PricedObject a superclass of any priced class:
ex:Clothing rdfs:subClassOf ex:PricedObject .
ex:Car rdfs:subClassOf ex:PricedObject .
This still does not "close" the usage of ex:price to only those classes, but
it's a pure RDFS alternative to using owl:Restrictions.
Holger
On Jan 11, 2010, at 1:01 AM, Bohms, H.M. (Michel) 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
>
>
>
>
>
>
> 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.
>
>
--
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.
