Re: SPARQL 1.1 Query Review Part 1

On 2011-12-08, at 09:54, Birte Glimm wrote:

> Sorry for being a bit late with my response. Apart from the points
> currently under discussion, all my comments have been addressed.
> Regarding my comment on 11.2, where Steve couldn't find the text, I
> think I somehow looked at the LC doc instead of the current editors'
> draft for this section. The current section seems fine.
> 
> I comment inline on the remaining issue.
> 
> Birte
> 
> On 8 December 2011 10:10, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
>> 
>> 
>> On 07/12/11 14:10, Steve Harris wrote:
>>> 
>>> On 2011-12-07, at 13:11, Andy Seaborne wrote:
>>>> 
>>>> 
>>>> On 06/12/11 22:53, Steve Harris wrote:
>>>>>>> 
>>>>>>> "[...] In aggregate queries and sub-queries variables that
>>>>>>> appear
>>>>>>>>> 
>>>>>>>>> in the query pattern, but are not in the GROUP BY clause
>>>>>>>>> cannot be projected nor used in project expressions." I
>>>>>>>>> would add a comma after "GROUP BY clause"
>>>>>>> 
>>>>>>> 
>>>>>>> Done
>>>>>>> 
>>>>>>>>> I don't think this is correct. I can select expressions
>>>>>>>>> with aggrated variables that are not grouped: SELECT
>>>>>>>>> (SAMPLE(?x) AS ?y) { ?x :p ?z } GROUP BY ?z
>>>>>>> 
>>>>>>> 
>>>>>>> @@Steve
>>>>> 
>>>>> I believe that's as the group intended.
>>>> 
>>>> 
>>>> I think Birte's point is that SAMPLE(?x) uses a variable in a
>>>> select expression, but it's not GROUP BY'ed.
>>>> 
>>>> As currently worded, that's not allowed.
> 
> Yes, that's my point.
> 
>>> We have:
>>> 
>>> “In aggregate queries and sub-queries variables that appear in the
>>> query pattern, but are not in the GROUP BY clause cannot be projected
>>> nor used in select expressions. In order to project arbitrary
>>> expressions the SAMPLE aggregate may be used. For details see the
>>> section on Projection Restrictions.”
>> 
>> But SAMPLE(?x) is part of a SELECT expression.
>> 
>> SAMPLE(?x) is using variable that is forbidden by this text as ?x is not
>> GROUP BY'ed.
>> 
>> The text forbids just as it correctly forbids (?x + 1).
>> 
>> It needs to allow use of ungrouped variables in an aggregate function.
> 
> How about rephrasing as follows:
> “In aggregate queries and sub-queries, variables that appear in the
> query pattern, but are not in the GROUP BY clause, can only be
> projected or used in select expressions if they are aggregated. The
> SAMPLE aggregate may be used for this purpose. For details see the
> section on Projection Restrictions.”

OK, that seems clear to me.

- Steve

>> Editorial:
>> 
>> A comma or two would be good:
>> "In aggregate queries and sub-queries, "
>>                                   ^^^^^^
>> ", but are not in the GROUP BY clause,"
>>                                   ^^^^^^
>> 
>> 
>>> I could change to “nor used directly in select expressions”, does
>>> that make it clearer? I think the bit about SAMPLE makes it
>>> reasonably clear, but it could be better.
> 
> Makes it slightly clearer.
> 
>>>>>>>>> "It is an error for aggregates to project variables with
>>>>>>>>> a name already used in other aggregate projections."
>>>>>>>>> Isn't it even forbidden to use any variable that is used
>>>>>>>>> elsewhere? SELECT (SAMPLE(?x) AS ?y) { ?x :p ?y } GROUP
>>>>>>>>> BY ?y would not be valid, right?
>>>>>>> 
>>>>>>> 
>>>>>>> @@Steve
>>>>> 
>>>>> I'm not really sure, that seems like more of a general select
>>>>> expressions restriction - I thought that was allowed at one time
>>>>> though?
>>>>> 
>>>>> I guess it wouldn't hurt to reiterate if that is the case, Andy?
>>>> 
>>>> 
>>>> Agreed - restate the condition.
>>> 
>>> 
>>> OK, changed to:
>>> 
>>> “It should be noted that as per functions, aggregate expressions are
>>> required to be aliased (again, similar to the BIND clause, using the
>>> keyword AS) in order to project them from queries or subqueries. In
>>> the example above this is done using the variable ?totalPrice. It is
>>> an error for aggregates to project variables with a name already used
>>> in other aggregate projections, or in the WHERE clause.”
>>> 
>>> Is that OK? The previous para already includes a link to the
>>> projection restrictions.
> 
> Seems ok to me now.
> 
>> 
>> Fine
>> 
>>> 
>>> - Steve
>>> 
>> 
>>        Andy
>> 
> 
> 
> 
> -- 
> Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
> Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
> University of Ulm                         Fax:   +49 731 50 24188
> D-89069 Ulm                               birte.glimm@uni-ulm.de
> Germany
> 

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Friday, 9 December 2011 09:55:07 UTC