RE: Further comments on SPARQL 1.1

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

 

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

 

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

 

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.

 

Or do you mean some kind of super evil SQL inspired syntax you’re planning
to force on us all one day ;-)

 

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?

 

Cheers,

Rob

 

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