RE: Extending daml+oil with concrete datatypes

On January 29, McBride, Brian writes:
> Can one think of the restriction "has at most 3 children
> who are doctors" as a cardinality restriction on the
> property "children who are doctors" rather than a
> cardinality and range restriction on the property "children"?
> 
> One could then have something like:
> 
>   <daml:Restriction>
>     <daml:onProperty>
>       <rdf:Property>
>         <rdfs:subPropertyOf rdf:resource="#children"/>
>         <rdfs:range rdf:resource="#doctor"/>
>       </rdf:Property>
>     <daml:maxCardinality>3</daml:maxCardinality>
>   </daml:Restriction>
> 
> Brian McBride

Brian,

No, it doesn't work. What you would need is the ability to define a
property that is EXACTLY equal the children property with the range
restricted to doctor, so that (x,y) would be an instance of the
property IFF (x,y) is an instance of children and y is an instance of
doctor.  What you have in the above restriction is a sub property of
such a property, so x may have a child y who is a doctor without (x,y)
being an instance of the subProperty. 

Moreover, even if you use the same construction elsewhere in the
ontology, it does not necessarily refer to the same property, as each
usage could be taken to specify a different subProperty. This means
that I can't infer that:

   <daml:Restriction>
     <daml:onProperty>
       <rdf:Property>
         <rdfs:subPropertyOf rdf:resource="#children"/>
         <rdfs:range rdf:resource="#doctor"/>
       </rdf:Property>
     <daml:maxCardinality>2</daml:maxCardinality>
   </daml:Restriction>

is a subClass of your restriction, because there could be hundreds of
instances of your property that are not instances of my property.

Regards, Ian


> 
> > -----Original Message-----
> > From: Ian Horrocks [mailto:horrocks@cs.man.ac.uk]
> > Sent: 23 January 2001 23:14
> > To: Jeff Heflin
> > Cc: www-rdf-logic@w3.org
> > Subject: Re: Extending daml+oil with concrete datatypes
> > 
> > 
> > I will try to clarify why we need hasClassQ:
> > 
> > On January 23, Jeff Heflin writes:
> > >
> > > [snip]
> > >
> > > I don't think this is right. We would have a similar 
> > problem if someone
> > > tried to define two "normal" restrictions within the same
> > > daml:Restriction element. Consider the example:
> > > 
> > > <daml:Restriction>
> > >    <daml:onProperty rdf:resource="#eyeColor" />
> > >    <daml:hasValue rdf:resource="#green"> 
> > >    <daml:onProperty rdf:resource="#hairColor" />
> > >    <daml:hasValue rdf:resource="#brown">
> > > </daml:Restriction>
> > > 
> > > Does this restriction define the set of things with hair that is
> > > green/brown and eyes that are green/brown? That would be an odd
> > > interpretation.
> > 
> > This is exactly the interpretation - it may be odd but if you choose
> > to write it this way then that is what you get. As you show below, you
> > can make things clear by separating the two statements about hairColor
> > and eyeColor:
> > 
> > > (Note: that the use of specially named properties can't
> > > solve this problem). The usefulness of the restriction 
> > element is that
> > > is allows you to describe each restriction independently, such as:
> > > 
> > > <rdfs:subClassOf>
> > >    <daml:Restriction>
> > >       <daml:onProperty rdf:resource="#eyeColor" />
> > >       <daml:hasValue rdf:resource="#green"> 
> > >    </daml:Restriction>
> > > </rdfs:subClassOf>
> > > <rdfs:subClassOf>
> > >    <daml:Restriction>
> > >       <daml:onProperty rdf:resource="#hairColor" />
> > >       <daml:hasValue rdf:resource="#brown">
> > >    </daml:Restriction>
> > > </rdfs:subClassOf>
> > > 
> > > ... which clearly means the set of things that have both 
> > green eyes and
> > > brown hair. Thus, I believe a restriction should define a 
> > restriction on
> > > a single property, and anything else is undefined. 
> > Therefore, I don't
> > > think your example makes a convincing argument for keeping 
> > the special
> > > data type properties.
> > 
> > But if I don't have hasClasQ, when I try to write a qualified
> > cardinality constraint describing the class of things that have at
> > most three Doctors amongst their children, I get:
> > 
> >  <daml:Restriction>
> >    <daml:onProperty rdf:resource="#hasChild"/>
> >    <daml:hasClass rdf:resource="#Doctor"/>
> >    <daml:maxCardinalityQ>3</daml:maxCardinalityQ>
> >   </daml:Restriction>
> > 
> > (aside - note that there can be any number of children, in fact there
> > may not be any children at all, but if there are children, then at
> > most three of them can be Doctors)
> > 
> > Note that the combination of onProperty and hasClass make a perfectly
> > valid restriction, so I have also "inadvertently" stated that I have
> > at least one child who is a Doctor, something that I may not have
> > wanted or intended. The problem is that there is now NO WAY to state a
> > qualified cardinality restriction without also stating a hasClass
> > restriction.
> > 
> > Similarly, if we try to dispense with the Q versions of the various
> > cardinality restrictions there is no way to state a qualified
> > restriction without also stating an unqualified one.
> > 
> > The way to resolve the problem in general would be to define the
> > possible combinations of properties on restrictions and the meaning in
> > each case, but I don't see how this can be done in RDF.
> > 
> > 
> > As for the dedicated concrete datatype syntax, we probably could get
> > rid of a lot of it if we also relaxed some range restrictions. This
> > has pros and cons - it makes the language more compact but it could
> > also be argued that it makes it less clear (and maybe harder to
> > parse). But I am certainly open to argument on this point.
> > 
> > Ian
> > 
>

Received on Tuesday, 30 January 2001 06:01:01 UTC