Re: Review of the n-ary extension

Thanks Boris. It doesn't seem that these block FPWD.

On 7 Apr 2009, at 14:27, Boris Motik wrote:

> Hello,
>
> Please find bellow my review of the n-ary extension. I've split my  
> comments into
> general and editorial ones.
>
> Regards,
>
> 	Boris
>
> ---------------------------------------------------------------
> General comments:
>
> - I find the syntax such as leq(Arguments(x y) ( x y )) rather  
> clunky: it first
> defines the aliases x and y and then uses them in a restriction.  
> This might be
> avoided if we provided unique names for arguments in all  
> restrictions. For
> example, $1, $2, $3, etc. comes to mind. Under such an approach,  
> one would
> simply write leq( $1 $2 ). Such a syntax seems to be much more  
> compact and
> therefore easier to decipher (no extraneous parentheses).

Uli and I worked out a version of this, and it has some issues.

Primary is that it doesn't match what, afaict, correct MathML. Since  
I would like the functional syntax to mirror the exchange syntaxes  
and I would like to use MathML for exchanging (in)equations, it seems  
that we're a bit stuck there.

I renormalized it to:
	DataComparison(Arguments(x y) leq( x y )))

Which corresponds to:
<owl:DataComparison>
	 <lambda xmlns="http://www.w3.org/1998/Math/MathML"
                     xsi:schemaLocation="http://www.w3.org/1998/Math/ 
MathML
                     http://www.w3.org/Math/XMLSchema/mathml2/ 
mathml2.xsd">
                     <bvar> <ci>x</ci></bvar>
                     <bvar><ci>y</ci></bvar>
                     <apply>
                         <leq/>
                         <ci>x</ci>
                         <ci>y</ci>
                     </apply>
                 </lambda>
</owl:DataComparison>

Another difficulty is that positional variables make it difficult to  
determine the arity of the predicate. After all, it's possible for a  
binary predicate to *use* only one of its arguments in the body of  
the expression.

So, I agree that there are some advantages, but authoring convenience  
is not, and should not be, a goal for the FS. And I think authoring  
convenience in the RDF and XML serializations *is* to use MathML.

Manchester syntax will adopt something easier, I believe.

> - The domain of the operations such as * and + is unclear: is it  
> owl:real only,
> or does it include xsd:double and xsd:float as well? I believe it  
> should be the
> former and not the latter.

Yes. Fixed.

> But if this is the case, then NaN, +INF, and -INF
> should not be mentioned any more as they were evicted from the  
> value spaces of
> the numeric datatypes recently.

Fixed.

> - owl:realPlus should be replaced with owl:real.

Indeed. Fixed.

> ---------------------------------------------------------------
> Editorial comments:
>
> - Throughout: After the last change to the way abbreviated IRIs are  
> handled in
> the FS, all such IRIs need to contain a colon. Thus, "water" should  
> be changed
> to ":water", and similarly for other IRIs.

They are meant as relative IRIs. So I need to enclose them in <>?

> - Section 1, 1st sentence: "types" -> "datatypes" or "data ranges".  
> (At this
> point, it is unclear what "types" might be.)

Fixed.

> - Throughout: "data predicates" -> "data ranges".
>
>
> - Section 1: "These predicates can be in OWL axioms" -> "These  
> predicates can be
> used in OWL axioms"
>

Fixed.

> - Section 1: "Predicates can only related values data properties" - 
> > "can only
> relate"

Fixed.

> - Section 1: "in future documents" -> "in future versions of this  
> specification"

Fixed.

> - Throughout: The usage of the royal "we" seems inappropriate to me  
> in a
> specification such as OWL. Sentences such as "With this definition,  
> we can
> infer:" should be rephrased as "With this definition, one can infer:"

Fixed, except, perhaps in the semantics. Will fix.

> - Throughout: It seems to me that the style of presentation should  
> be more
> matter-of-fact. Hence, sentences such as "All we need to specify  
> here is what
> the meaning of a Comparison, ScaledComparison, and LinearComparison  
> is." should
> be rephrased as "This document just defines the semantics of  
> Comparison,
> ScaledComparison, and LinearComparison."

Fixed except in the semantics. Will fix.

Cheers,
Bijan.

Received on Tuesday, 7 April 2009 16:23:10 UTC