- From: Steve Harris <steve.harris@garlik.com>
- Date: Mon, 10 Oct 2011 10:43:13 +0100
- To: Bryan Thompson <bryan@systap.com>
- Cc: "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
This is in response to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Aug/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 Monday, 10 October 2011 09:43:48 UTC