- From: Matthew Perry <matthew.perry@oracle.com>
- Date: Tue, 29 Mar 2011 08:50:44 -0400
- To: Steve Harris <steve.harris@garlik.com>
- CC: W3C SPARQL Working Group <public-rdf-dawg@w3.org>
On 3/29/2011 8:15 AM, Steve Harris wrote:
> On 2011-03-15, at 13:05, Matthew Perry wrote:
>
>> Hi,
>>
>> My review the query document is below.
> [snip]
>
>> --- 11.7 ---
>> It seems that unbound and error will be treated differently now (e.g. encountering a blank node during a sum() gives an error but encountering an unbound value has no effect). I recall that errors used to have the same effect as unbound.
>>
>> If I understand correctly, these queries would have different results now whereas before they gave the same result.
>>
>> SELECT (SUM(?X) + SUM(?Y) AS ?XY)
>> WHERE { ?X :P ?Y }
> So, SUM(?X) will be an error, meaning ?XY will be an error.
>
>> SELECT SUM(?XY)
>> WHERE { SELECT (?X + ?Y) AS ?XY
>> WHERE { ?X :P ?Y }
>> }
> I think that it will be the same, eval(?XY) will be an error, so SUM(?XY) will also be an error.
>
> “ListEval((unbound), μ) = (error), as the evaluation of an unbound expression is an error.”
> From §18.4, but it's stated informally in a number of places too.
>
> Though, there was a typo in the definition of Sum() I've just fixed. Sum(3) was op:numeric-add(3, 1), which is clearly not right.
>
> ...
Ok. That works for me.
- Matt
>> Minor comments / typos:
>> --- 1.1 ---
>> [Sections => Section] 11 introduces the mechanism to group and aggregate results, which can [be] incorporated as subqueries as described in Section 12.
> Thanks, fixed.
>
> ...
>
>> --- 11.2 ---
>> In order to calculate aggregate values for a solution, the solution is first divided into one or more groups, and [the the => the] aggregate value is calculated for each group.
> Thanks again.
>
> - Steve
>
Received on Tuesday, 29 March 2011 12:51:28 UTC