Re: Extending daml+oil with concrete datatypes

Ian Horrocks wrote:
> 
> 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:

But wouldn't it be better if we disallowed such constructs? We could do
this by simply stating that onProperty is a daml:UniqueProperty.

> [snip]
>
> 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.

I never meant to argue that we should dispense with the Q properties. I
agree with your argument for their importance.

> 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.

The dedicated concrete datatype syntax is the subject of my objection. I
think that as far as most user's are concerned there's no significant
difference between an abstract property and a concrete property, so why
should they have to use different syntax for each? Systems that depend
on the separation of the abstract and concrete domains should still be
able to tell which properties use which domains.

Jeff

Received on Wednesday, 24 January 2001 12:02:11 UTC