# Re: SUM aggregate operator and non-numeric literals

From: Steve Harris <steve.harris@garlik.com>
Date: Sun, 26 Jun 2011 09:00:19 +0100
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <B6AFE40A-6942-4252-B771-67F762F23DFE@garlik.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
```I think it was mostly just that at the time I wrote the def'n there was no (obvious, explicit) function for +, makes sense to change it to me.

- Steve

On 2011-06-25, at 16:18, Lee Feigenbaum wrote:

> On the surface, Jeen's reasoning makes sense to me.
>
>
> Lee
>
> -------- Original Message --------
> Subject: SUM aggregate operator and non-numeric literals
> Resent-Date: Thu, 23 Jun 2011 01:05:51 +0000
> Date: Thu, 23 Jun 2011 13:05:10 +1200
> From: Jeen Broekstra <jeen.broekstra@gmail.com>
>
>
> Hi DAWG,
>
> The current definition of SUM (section 18.4) is as follows :
>
> ==begin quote==
> Definition: Sum
> numeric Sum(multiset M)
>
> The Sum set function is used by the SUM aggregate in the syntax.
>
> Sum(M) = Sum(ToList(Flatten(M))).
>
> Sum(S) = op:numeric-add(S1, Sum(S2..n)) when card[S] > 1
> Sum(S) = op:numeric-add(S1, 0) when card[S] = 1
> Sum(S) = 0 when card[S] = 0
>
> ==end quote==
>
> Given that the definition of SUM is directly in terms of the
> op:numeric-add XPath function, it follows that it can only be applied on
> numeric literals. Therefore, any SUM that aggregates over a set of
> values that contains a non-numeric type will result in a type error. Not
> even an extension of the SPARQL operator table in section 17.3 will
> help, as SUM is not defined in terms of those operators.
>
> In other words, if we have the following data:
>
> :a rdf:value "1" .
> :a rdf:value "2"^^xsd:integer .
> :b rdf:value "3"^^xsd:integer .
>
> And the following query:
>
> SELECT (SUM(?val) as ?value)
> WHERE {
>   ?a rdf:value ?val .
> } GROUP BY ?a
>
> The result will be always a type error.
>
> I would argue that having the same extensibility mechanisms available
> for SUM as we have for, for example, the + operator would be preferable.
> That way, implementations wanting to offer a more forgiving version of
> the SUM operator (one which silently ignores the non-numerics, for
> example), could do so while staying spec-compliant.
>
>
> Regards,
>
> Jeen
>
>
>
>

--
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11