Re: Dealing with qualified expressions in DAML

From: John Pacheco <pacheco@AI.SRI.COM>
Subject: Re: Dealing with qualified expressions in DAML
Date: Thu, 26 Sep 2002 12:28:06 -0700 (PDT)

> I'm afraid that I have one more question that I would like to pose regarding 
> this discussion.  Does this "shared extension" side effect take place when other 
> restriction elements are used instead of just "hasClassQ"
> 
> For example 
> 
> <daml:Class rdf:ID="Rabbit">
>   <rdfs:subClassOf>
>     <daml:Restriction>
>       <daml:onProperty rdf:resource="#Eats"/>
>       <daml:toClass rdf:resource="#Vegitables"/>
>       <daml:hasValue rdf:resource="#Carrots"/>
>     </daml:Restriction>
>   </rdfs:subClassOf>
> </daml:Class>
> 
> Now before you said:
> >     It is a logical consequence of the information specified that each of
> >     the restrictions thus formed has the same extension.
> So does that mean that 
>    {things that eat Vegitables}
>    has exactly the same elements as 
>    {things that eat Carrots}

Yes, except that that is not what the syntax above says.  To get this you
need two toClass pieces.n

> This would imply that anything that eats vegitables eats carrots, which would 
> not be intended.

Correct.

> Or is the "side effect" that the restrictions will have the same extention due 
> to the use of the same tags in the restriction repeatedly?  If that were the 
> case then this example:
> 
> <daml:Class rdf:ID="AnimalLover">
>   <rdfs:subClassOf>
>     <daml:Restriction>
>       <daml:onProperty rdf:resource="#owns"/>
>       <daml:hasValue rdf:resource="#Dog"/>
>       <daml:hasValue rdf:resource="#Cat"/>
>     </daml:Restriction>
>   </rdfs:subClassOf>
> </daml:Class>
> 
> Would logically imply that 
>    {things that own Dogs}
>    has exactly the same elements as 
>    {things that own Cats}
> Is that correct?

Well, this one is that things that own a dog also own a cat, and vice
versa.

> If you could just clarify this, then I think I would understand how exactly one 
> is to standardly use restrictions.  
> 
> Thank you,
> John
> 

Again, it is generally a bad idea to construct restrictions with ``too
many'' pieces.

[...]

peter

Received on Thursday, 26 September 2002 15:53:39 UTC