RE: Extending daml+oil with concrete datatypes

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




> -----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 Monday, 29 January 2001 15:45:49 UTC