W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

Re: Review of the n-ary extension

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Tue, 7 Apr 2009 17:26:57 +0100
Message-Id: <D06FEE94-84D9-4059-8D27-4A97E02518DA@cs.man.ac.uk>
To: W3C OWL Working Group <public-owl-wg@w3.org>
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:
	 <lambda xmlns="http://www.w3.org/1998/Math/MathML"
                     <bvar> <ci>x</ci></bvar>

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.


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


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


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


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


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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:11 UTC