W3C home > Mailing lists > Public > public-sparql-dev@w3.org > January to March 2015

Re: how should undefined elements figure in aggregate samples?

From: james anderson <james@dydra.com>
Date: Tue, 31 Mar 2015 09:31:25 +0000
Message-ID: <0000014c6f2bd3ba-cf60747b-1608-4102-89d4-1255ef6e596a-000000@eu-west-1.amazonses.com>
To: public-sparql-dev@w3.org
good morning;

On 2015-03-31, at 11:04, Andy Seaborne <andy@apache.org> wrote:

> The aggregate handle errors based on the nature of each aggregates:
> 
> e.g.
> http://www.w3.org/TR/sparql11-query/#defn_aggCount
> "remove error elements from N"
> 
> so count(?x) is the number of defined ?x in the group, count(*) the number of rows, count(if(?x = 99),1,0)) the number of times 99 occurs.
> 
> Sum(?x) does not remove error or indeed non-numbers:
> so sum(1+2+undef) is undef as is sum(1+"oops")
> 
> Sum(coalesce(?x,0)) on {1, 2, undef} is 3.
> Sum(coalesce(?x+0,0)) on {1, 2, "oops"} is 3.
> 
> There is no canonical result for sample().

ok, let us be less specific and return to the opening question: given the nature of sparql, which result is useful?

in addition to which, there is also a concern, how the passage in the text which leads the section on “aggregate algebra" affects sample argument expressions which are more complex than a single variable? where the text specifies

    Note that, although the result of a ListEval can be an error, and errors may be used to group, solutions containing error values are removed at projection time.
    ListEval((unbound), μ) = (error), as the evaluation of an unbound expression is an error.

one reading of that text is that such expressions would certainly be errors should they entail evaluation of an unbound marker, in which case, the “no canonical result” interpretation for the simple variable reference introduces a unwarranted asymmetry in the way sample expressions are to be interpreted.

best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com
Received on Tuesday, 31 March 2015 09:31:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 31 March 2015 09:31:56 UTC