Re: ORDER BY allows expression, SELECT does not

Dan Connolly wrote:
> On Sun, 2006-03-26 at 19:54 -0500, souripriya.das@oracle.com wrote:
>> This has been raised by people and acknowledged in 
>> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jan/0075.html.
>> I was wondering what the reasoning was behind this.
> 
> I don't think the asymmetry is a conscious design choice.
> 
> As I recall, SELECT was designed early on, and ORDER BY
> came later. We don't have any requirements for expressions
> in select, and aside from the occasional thinking-out-loud
> here or there, none of the WG discussions have argued
> for a change, so it hasn't been changed.
> 
> 
>> Thanks,
>> - Souri.

There are two factors:

1/ In the SPARQL design we have at present, the RDF terms that are returned by 
a SELECT query are terms from the scoping set.  The results do not include RDF 
terms calculated by the query.  The query, in ORDER BY and FILTER, can make 
new RDF terms but these can't be assigned to a variable and can't be returned 
in SELECT.

2/ The result set format uses named variables.  To return the result of an 
expression, we'd need a named variable for the resulting RDF term or change 
the results format.  SPARQL is neutral as to API style of name-access or 
positional-access currently.

So it's not an asymmetry as such - it'd need a new concept of assignment in 
solutions.

- - - - - - - -

Like other SQL-inspired features, there is nothing to stop this being added if 
we committed strongly to the algebra style we have.  The extensibility debate 
for OWL (certainly, RDF maybe) has held this back in the current timescale.


Outline:

If unnamed expressions were in the clause SELECT, then we'd need to refine 
things and prefer positional APIs; if we wished to retain named variables 
everywhere, we'd need to add assignment (within a solution) with associated 
syntax.  My preference is ":=" for assignment because it is an expression 
thing and then the only oddity is that expressions in SELECT would need to 
look like:

SELECT ?x ?y (?c := ?a*2) ?d
WHERE ...

"AS" could be made to work as well, a keyword would be needed, but note 
clarity issues if there are no brackets to be required:

SELECT ?x ?y ?a*2 AS ?c ?d  # I don't that clear.

SELECT ?x ?y (?a*2 AS ?c) ?d  # I find that better.


More material for SPARQL-2.  IMO, we have enough for a useful language now.
Does everything? No - but I don't see that as a problem if the subset we have 
is useful to enough people.  "Useful, now" vs "complete, late(r)".

 Andy

Received on Monday, 27 March 2006 10:26:22 UTC