Re: Inverse property on classes

>
>  Would you use allValuesFrom <
>> http://www.w3.org/TR/owl-guide/#owl_allValuesFrom> to create this weird
>> pizza class that has all mozzarella as topping? :Pizza_mozzarella_class
>> :hasTopping all :Mozzarella_class
>>
> No. That's why I said that it wouldn't be that trivial. Here you're saying
> that "all toppings of Pizza_mozzarella_class's instances are instances of
> Mozzarella_class". But you need something else: "any instance of
>  Pizza_mozzarella_class has *all* instances of  Mozzarella_class as
> toppings". Do you see the difference? The second does imply that *any*
> instance of Mozzarella_class is a topping of an instance of the
> Pizza_mozzarella_class (provided the latter is non-empty) while the first
> does not.


So I need to define both sides of the relation?
:Pizza_mozzarella_class :hasTopping all :Mozzarella_class
:Mozzarella_class :isToppingOf all :Pizza_mozzarella_class

In this case, I don't use anymore the inverse property?

I have the feeling that property characteristics like inverse and
transitivity are useful on instances, not on classes.

If we add an ingredient class to our ontology and a transitive property
hasPart that is parent of hasTopping.
:Ingredient rdf:type owl:Class
:hasPart rdf:type owl:TransitiveProperty
:hasTopping rdf:type :hasPart
:Cheese_class rdf:type :Ingredient

:Pizza_mozzarella_class :hasTopping all :Mozzarella_class
:Mozzarella_class :hasPart some :Cheese_class

Would it be possible to know if my pizza has some cheese as ingredient?


>  Actually, I want to use classes and not individuals because I need to
>> reason on them and it seems that reasoners can only work on classes...
>>
> I'm not sure what you mean by "it seems that reasoners can only work on
> classes...". It is often a highly non-trivial modeling decision (to use
> classes or individuals to model certain things).
>

When I tried to find inferred classes from my instances it did not work...
But when I used classes instead of instances, the reasoner created the
inferred model.
In fact, if I was able to 'navigate' threw my ontology using the inverse and
transitive properties on classes, it would be great. But for the moment, I
can't.
But I can do it easily with instances... that's why I'm stuck with
individuals :-(

Thanks again Pavel!

Cedric




>>
>>
>> On Wed, May 13, 2009 at 4:40 PM, Pavel Klinov <klinovp@cs.man.ac.uk<mailto:
>> klinovp@cs.man.ac.uk>> wrote:
>>
>>    Hello,
>>
>>    Cédric Thiébault wrote:
>>
>>        Hi,
>>
>>
>>    [snip]
>>
>>
>>
>>
>>        When I create an individual :Pizza_mozzarella and add a
>>        property :hasTopping on :Mozzarella individual, I can work
>>        with the inverse property on the topping and I see that
>>        :Mozzarella :isToppingOf :Pizza_mozzarella. It works great
>>        with individual.
>>
>>        But when I try to do the same test with classes:
>>        :Pizza_mozzarella_class :hasTopping some :Mozzarella_class
>>
>>        But I cannot use the inverse property: :Mozzarella_class does
>>        not know anything about :Pizza_mozzarella_class.
>>
>>        Is this normal ?
>>
>>
>>    Yes. Notice that you are not making any claim here about
>>    Mozzarella_class in general. You're only saying that all instances
>>    of Pizza_mozzarella_class are related to *some* instance of
>>    Mozzarella_class. Imagine a model in which there are 10,000
>>    mozarrellas and only one of them is used as a topping on all
>>    pizzas (it would be a satisfying model). Would you want to be able
>>    to conclude something general about 9,999 mozarellas basing on
>>    only one instance?
>>
>>
>>        Are inverse properties usable only on individuals ?
>>
>>
>>    Well, it depends on what you mean by "using". For example, you can
>>    define a class (and an instance) of pizzas which has *all*
>>    instances of Mozzarella as toppings (although it's not that
>>    trivial). Then, of course, you'll be able to infer that
>>    :Mozzarella_class :isToppingOf some :that_weird_pizza_class.
>>
>>
>>    Cheers,
>>    Pavel
>>
>>
>>
>>        Thanks for your help :-)
>>
>>        Cedric
>>
>>
>