- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Sat, 08 Oct 2011 20:52:56 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: public-rdf-dawg@w3.org
Looks good to me too.
On 10/8/2011 8:26 AM, Andy Seaborne wrote:
> Steve,
>
> The new draft looks good.
>
> Andy
>
> On 07/10/11 16:20, Steve Harris wrote:
>> Ah, thanks, I see what he is getting at now, draft updated at
>> http://www.w3.org/2009/sparql/wiki/CommentResponse:BT-1
>>
>> - Steve
>>
>> On 2011-10-07, at 15:26, Andy Seaborne wrote:
>>
>>>
>>>
>>> On 07/10/11 13:15, Steve Harris wrote:
>>>> Comment:
>>>> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Aug/0000.html
>>>>
>>>>
>>>> Draft response:
>>>> http://www.w3.org/2009/sparql/wiki/CommentResponse:BT-1
>>>>
>>>> - Steve
>>>>
>>>
>>> The example is a bit more complicated because it involved aggregation
>>> and select expressions.
>>>
>>> An error in an aggregate is not trapped specifically by the aggregate
>>> - it's an error. In the example it's because the select expression
>>> that you get an unbound.
>>>
>>> SELECT ( 1/0 AS ?x ) {}
>>>
>>> is:
>>>
>>> -----
>>> | x |
>>> =====
>>> | |
>>> -----
>>>
>>> this then explains the second point: ?c can be bound if AVG is an
>>> error because the AVG error is handled in SELECT expressions.
>>>
>>> SELECT
>>> ( COALESCE(SUM(?a),"error") AS ?x )
>>> (SUM(?a) AS ?y )
>>> { BIND ("abc" AS ?a) }
>>>
>>> ==>
>>>
>>> ---------------
>>> | x | y |
>>> ===============
>>> | "error" | |
>>> ---------------
>>>
>>> and then HAVING( aggregate error ) is just like a FILTER and error.
>>>
>>> Andy
>>>
>>
>
>
Received on Sunday, 9 October 2011 00:53:50 UTC