Review of the n-ary data range specification

Hello,

As required by my ACTION-235, here is a review of the n-ary data range specification
(http://www.w3.org/2007/OWL/wiki/Data_Range_Extension:_Linear_Equations).

My main comment is that I still don't understand exactly how to reason with the proposed extension. Note that the conjunctions of
data predicates that we obtain during reasoning can contain a mix of various datatypes and a mix of comparison predicates.
Therefore, although the document contains several pointers to related literature, adapting these existing results to our setting
seems to be nontrivial.

Other than tat, I have below juts the following noncritical comments.

- I didn't understand why 'Rational' was defined in the functional-style spec. I thought that we'd instead define a new datatype
owl:rational. Then, the 'Term' production should use the 'Constant' nonterminal, possibly with a constraint (in English) restricting
the type of the constant appropriately.

- I did not understand what is the meaning of '[URI]' in the productions for 'Comparison', 'ScaledComparison', and
'LinearComparison'.


- The syntax for comparisons consists of two parts: (i) a declaration of the arguments, and (ii) an expression that uses these
arguments. This might be a bit unwieldy, and could be shortened if we provided built-in names for the arguments, such as $1, $2,
etc. Thus, instead of

(1) Comparison( y1 y2 lt (y1 y2))

we could have something like

(2) Comparison(lt ($1 $2))

In fact, we could further simplify the syntax and simply write

(3) lt( $1 $2 )

or even

(4) $1 lt $2

(For the latter, we'd need to check whether the syntax is parsable.)


- 'Comparison', 'ScaledComparison', and 'LinearComparison' seem to have been introduced in order to define different classes of
comparpisons. I'm not sure, though, whether this needs to be done at the syntax level. Note that simple comparisons are linear
comparisons; the latter are not a semantically different construct. Therefore, it might be more convenient to define just one type
of syntax for all types of comparisons, and then to simply place a global restriction on the comparisons if you want to have, say,
simple comparisons only. This would have the benefit that you'd need to define the semantics only once: I was a bit confused with
why there are several variants of the semantics.



- I'm slightly confused by the definition of the semantics for Comparison: the syntax contains y1 and y2, whereas the semantics
refers to y1 and y2. It seems to me that we need t1[y1->v1][y2->v2] and the same for t2 in this case as well. Note that the syntax
does not require the arguments to be in the same order as in the comparison; therefore, we could have a piece of syntax of the form

(5) Comparison( y1 y2 lt (y2 y1) )

Regards,

	Boris

Received on Thursday, 30 October 2008 08:46:46 UTC