Re: SPARQL Query 1.1 review comments

Yes, I certainly agree.

- Steve

Sent on the move.

On 6 Jan 2010, at 00:48, Souripriya Das <SOURIPRIYA.DAS@oracle.com>  
wrote:

> Steve,
>
> So as I understand both Ivan and you seemed to agree with my  
> thoughts (see below) regarding requiring an alias name to go with an  
> expression.
>
>> My opinion would be to require an alias name, mainly because of the
>> following:
>>
>>   * Specifying a binding for an alias variable works uniformly for
>>     everything: 1) in Results XML format 2) as an "output" variable  
>> of
>>     a subquery that can be referenced in outer query, and 3) in a
>>     top-level query.
>>   * Although it does put a burden on the user to come up with the  
>> name
>>     of a variable that is not potentially bound, it makes the query
>>     appear much clearer.
>>
>
> Regarding changing the query example in Sec 9 to SELECT ?org (SUM(? 
> lprice) AS ?totalPrice) ..., we can do it afterward if it is okay  
> with others.
>
> Thanks,
> - Souri.
>
> ----- Original Message -----
> From: steve.harris@garlik.com
> To: andy.seaborne@talis.com
> Cc: SOURIPRIYA.DAS@oracle.com, public-rdf-dawg@w3.org
> Sent: Tuesday, January 5, 2010 7:11:28 PM GMT -05:00 US/Canada Eastern
> Subject: 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 06:08:15 UTC