Re: Further comments on SPARQL 1.1

On 26 Feb 2010, at 17:01, Rob Vesse wrote:

> Hi Steve
>
> Ok that makes more sense now, not entirely keen on the syntax mainly  
> because it adds an extra way to terminate an expression inside an  
> aggregate which inevitably adds to the ever increasing code bloat of  
> my SPARQL parser

I'm not particularly fond of the syntax myself, but I don't have a  
better suggestion, and reusing the syntax in SQL makes more sense than  
inventing something new, and differently bad.

> > Referring to XPath functions directly is not helpful, as they're  
> orthogonal to the semantics of aggregates
>
> But some XPath functions aren’t strictly speaking functions and are  
> in fact aggregates since they operate on sequences rather than  
> single values – fn:string-join() being a prime example of this since  
> there is a separate fn:concat() function for just joining an  
> arbitrary number of single values.

It's not just operating on a sequence that makes it an aggregate. Some  
of the SPARQL aggregates may well be defined in terms of XPath  
functions internally, but it's not enough to say aggregate X is  
equivalent to fn:x.

Do What I Mean doesn't really cut it in standards, sadly.

> > I'm not planning to add order ORDER BY aggregate syntax in SPARQL  
> 1.1, but I'm leaving it open for future WGs
>
> When you say this do you mean you’re not permitting queries such as  
> this:
>
> SELECT ?s WHERE {?s ?p ?o} GROUP BY ?s ORDER BY COUNT(?s)

No, I mean something like:

SELECT (GROUP_CONCAT(?x ORDER BY ?x) as ?c)

Which is legal in MySQL.

> Which currently is not valid syntax but can be rewritten as:
>
> SELECT ?s COUNT(?s) AS ?count WHERE {?s ?p ?o} GROUP BY ?s ORDER BY ? 
> count
>
> And will probably work depending on exactly when the implementation  
> applies the ORDER BY clause.

ORDER BY is applied after the aggregates have been evaluated.

> By the way do you happen to know what the IN/NOT IN syntax Andy was  
> tweeting about yesterday is - I assume it’s just SPARQLs equivalent  
> of the field IN (“value1”, “value2”) style syntax of SQL – is that  
> likely to be in the next working draft?

Yes, and yes.

Regards,
    Steve

> From: public-rdf-dawg-comments-request@w3.org [mailto:public-rdf-dawg-comments-request@w3.org 
> ] On Behalf Of Steve Harris
> Sent: 26 February 2010 16:36
> To: Rob Vesse
> Cc: public-rdf-dawg-comments@w3.org
> Subject: Re: Further comments on SPARQL 1.1
>
> 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
>

-- 
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