W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > February 2010

Re: Further comments on SPARQL 1.1

From: Steve Harris <steve.harris@garlik.com>
Date: Fri, 26 Feb 2010 16:36:19 +0000
Cc: <public-rdf-dawg-comments@w3.org>
Message-Id: <E1ED75DB-6CDB-450C-9CB5-39D0A4F55819@garlik.com>
To: Rob Vesse <rav08r@ecs.soton.ac.uk>
Responding as an individual, not representing the group...

On 25 Feb 2010, at 15:24, Rob Vesse wrote:

> With regards to my previous comments and the Working Group’s  
> response [1] I would like to make some further comments.
>
> Aggregates – I do not like the proposed SEPARATOR syntax for  
> GROUP_CONCAT at all, if you are going to include GROUP_CONCAT simply  
> leave it as a single argument with a standard separator and then  
> specify that fn:string-join() must be supported by SPARQL 1.1 as a  
> function since I believe the WG intends to specify a subset of XPath  
> and other common functions that implementations should support?

Referring to XPath functions directly is not helpful, as they're  
orthogonal to the semantics of aggregates. Functions take a list of  
values, perform some internal operation on them, and return a value.  
Aggregations take a list (actually a multi-set I believe) of  
expressions, evaluate them with respect to a binding set, apply some  
set function, and then return a value. These are not compatible  
concepts.

If you have something like:

data:
<x> <p> "1" .
<x> <p> "2" .

SELECT (GROUP_CONCAT(?x, "|") AS ?c)
WHERE {
    <x> <p> ?x .
}

you will get back something like:

?c = "1 | 2 |"

But that's because it evaluates to

Aggregation((), {?x, "|"}, GROUP_CONCAT, [BS]) as per §9.2 of SPARQL  
1.1 draft.

Which evaluates to GROUP_CONCAT({"1", "|", "2", "|"})

The SEPARATOR syntax comes from MySQL, which is where GROUP_CONCAT  
originates from, it's necessary in SQL for the same reason it is in  
SPARQL.
http://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html#function_group-concat

I'm not planning to add order ORDER BY aggregate syntax in SPARQL 1.1,  
but I'm leaving it open for future WGs.

Hope this helps,
    Steve

-- 
Steve Harris, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44 20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD
Received on Friday, 26 February 2010 16:36:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 26 February 2010 16:36:54 GMT