Re: Proposed simplification of datatype expressions

this is being discussed on the telecon but for the record, this is what i
brought up
Ian Horrocks wrote:

> I know this is rather last-minute, but I would like to propose a
> couple of small simplifications to the language that would
> significantly improve ease of implementation of datatype reasoning in
> both DL and Lite.
>
> 1. Change the specification of cardinality constraints so that they
> can only be applied to individual valued properties and not to data
> valued properties. This seems to be a relatively small loss as most
> data valued properties turn out to be functional, and it is hard to
> think of realistic examples where local/arbitrary-valued cardinality
> constraints are required.
>
> 2. Eliminate the dataRange construction from OWL DL, i.e., do not
> support oneOf(5 10 15 20). If used in someValuesFrom restrictions,
> this construction doesn't add any expressive power as it is equivalent
> to a disjunction of value restrictions, but if used in allValuesFrom
> restrictions it acts like a datatype definition outside XMLS.

this suggestion would exclude the option of using
 oneof("red"   "white"  "rose")   as the allvaluesfrom restriction on
hasWineColor on wine.
then we need to make red, white, and rose individuals instead of using
strings.  That is doable but not how ian has argued this should be modeled.




>
>
> These changes would significantly simplify the task of implementing
> datatype reasoners:
>
> - There would no longer be any need to worry about interactions between
>   cardinality constraints and the cardinality of a datatype, and a
>   datatype reasoner would not have to consider multiple sets of
>   constraints, each of which must have a different solution;
>
> - A datatype reasoner would only need to consider the satisfiability
>   of a finite conjunction of (possibly negated) type specifications
>   and values, and would not need to deal with disjunctions of such
>   conjunctions.
>
> - It would be much easier to extend the language to deal with nary
>   datatypes, e.g., to compare the values of multiple properties -
>   combining these with cardinality constraints gets quite hairy
>   because it is necessary to count all possible tuples that can be
>   formed from the relevant properties.
>
> Regards, Ian

Received on Thursday, 13 March 2003 12:38:54 UTC