RE: Questions concerning 11.7 (Aggregate Example (with errors))

Steve,

Yes, this statement is clear and answers my question:

> The result of an Aggregate which returns an error, is an error, but the SELECT expression result of projecting an error is unbound.  

Will any such clarification be present in the final version of the document?

Thanks,
Bryan

> -----Original Message-----
> From: Steve Harris [mailto:steve.harris@garlik.com] 
> Sent: Monday, October 10, 2011 5:43 AM
> To: Bryan Thompson
> Cc: public-rdf-dawg-comments@w3.org
> Subject: Re: Questions concerning 11.7 (Aggregate Example 
> (with errors))
> 
> This is in response to 
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2
> 011Aug/0000.html
> 
> > Hello,
> >
> > I am trying to put together some unit tests for error handling for 
> > aggregates.  Based on the example below it seems that an 
> error within 
> > an aggregate function (such as SUM or AVG) is NOT trapped by the 
> > function (which would cause the specific solution to be dropped by 
> > that function), but rather causes the evaluation of that 
> function for 
> > the group to fail such that  no value is bound for that 
> function for 
> > that group.  Is this the correct reading?  Also, per the 
> example, the failure of one aggregate for a group does not 
> cause the group to be dropped, just that aggregate, correct?
> 
> Not exactly.
> 
> The result of an Aggregate which returns an error, is an 
> error, but the SELECT expression result of projecting an 
> error is unbound. 
> 
> > Also, if the test were modified to such that ?c could be computed 
> > while ?avg still produced an error, I presume that ?c would become 
> > bound for the group.  For example, consider if the source 
> of the error 
> > was a Literal having numeric data but not explicitly typed 
> as some xsd 
> > numeric datatype rather than a blank node.  In this case, 
> one of the 
> > aggregates might be written to parse the literal, returning 
> its numeric value.  Under those circumstances, I presume that 
> ?c would become bound but that ?avg would not.
> 
> ?c can be bound if AVG is an error because the AVG error is 
> handled in SELECT expressions.
> 
> > One more twist to consider.  What if there is a HAVING 
> clause and it 
> > encounters the same error?  I assume that it should fail 
> the group in 
> > which the error was encountered, but not the entire query.  E.g., 
> > HAVING SUM(?p) > 0 in the example below.  That would trip 
> on the same error which is tripping up AVG(?p).
> 
> That is correct, the evaluation rules are as per FILTER.
> 
> Please indicate whether this response has answered your query.
> 
> Steve, on behalf of the SPARQL WG.

Received on Tuesday, 18 October 2011 22:55:39 UTC