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>

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 UTC

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