Re: SPARQL Query 1.1 review comments

On 5 Jan 2010, at 16:53, Andy Seaborne wrote:
> On 05/01/2010 2:33 PM, Souripriya Das wrote:

...

>> Regarding my comments about "value of expression in presence of  
>> operands
>> of incorrect data types" ("semantics unclear" in Sec 2.5, Sec 13.1.2,
>> and Sec 9): The idea of skipping the binding (effectively  
>> binding=null?)
>> sounds good.
>>
>> For the query example in Sec 9, I still think it will nicely show the
>> grouping aspect if we extend the SELECT list slightly to SELECT ?org
>> (SUM(?lprice) AS ?totalPrice).
>
> [Steve]

I'm not really inclined to change it at this point. Several people  
have reviewed the document, so I'd rather not change things right now.

>> One more question: Are we always requiring an alias for an  
>> expression?
>> That is, would SELECT SUM(?lprice) ... (i.e., without the alias
>> ?totalPrice) be allowed?
>
> Not formally decided (I couldn't find a resolution anyway) but there  
> is a body of support for requiring the alias name.  If sent over HTP  
> with the results format, a name is required.  Just for query, a  
> processor can easily generate one at parse time so there is no  
> requirement for it.
>
> Your opinion?
>
> Personally, I think the work to generate a safe one (it's similar to  
> calculating SELECT *) is negligible and so a design to the benefit  
> of the user is to be preferred.

I disagree. I think it makes queries potentially harder to read and  
understand, and I can't think of a sensible usecase for it. You can't  
refer to it elsewhere in the query, as you don't know what it will be  
called, so why project out something you can't use?

You can't return them to a client either, as SELECT * only projects  
variables that appear in the query.

It makes sense in SQL because you can have columns called things like  
“x * 3”, so engines can reliably map from expressions to column names,  
but SPARQL syntax doesn't allow that.

- Steve

Received on Wednesday, 6 January 2010 00:11:17 UTC