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

Re: Review of the n-ary extension

From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
Date: Sun, 26 Apr 2009 12:48:02 +0100
Cc: <public-owl-wg@w3.org>
Message-Id: <4FB816CB-F579-439D-9FA3-8545656C2AAF@cs.manchester.ac.uk>
To: Boris Motik <boris.motik@comlab.ox.ac.uk>

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.

Yes.

> This might be
> avoided if we provided unique names for arguments in all  
> restrictions. For
> example, $1, $2, $3, etc. comes to mind.

Uli and I discussed this design extensively and, at one point, even  
adopted it.

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

The main issues that led us to reject it are:
	1) Readability. Proper names are more legible in the equation. Please  
note that it's a good thing that the formal parameter names can vary  
from the actual parameter names (i.e., the data properties in  
question) since equations can be reused in different contexts. $1 is a  
bit TeXish :)
	2) Issues with arity. The formal parameter list establishes the arity  
of the lambda expression. With numeric arguments, the arity is  
underdetermined (e.g., what if the equation was a union of leq($1 $2)  
and leq($1 $3) and you feed it two arguments? You can't tell whether  
this is a syntax error or not).
	3) Conformance with MathML and more general practice. I tried to pick  
something that "looked standard" in MathML and lambda functions seemed  
the best (that is they are a fully defined, coherent MathML object).  
Thus, I want the FS to mirror the MathML as closely as possible.

	Please note that other syntaxes, such as Manchester syntax, can use a  
more user friendly syntax (though, really, it's not that bad, I  
found). I expect lots of people to name expressions which also lowers  
the load.

	Also note that Racer uses a different syntax, wherein there are *no*  
arguments of any kind and property names are just used directly. To  
adopt *that* style would require a change to the "hook" which I think  
is undesirable.

Thus, I think we should keep the more verbose syntax.

Cheers,
Bijan.
Received on Sunday, 26 April 2009 11:48:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 26 April 2009 11:48:43 GMT