CommentResponse:DBeckett-1

In response to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Dec/0001.html

Dave,

Thanks for your comments on the SPARQL Query 1.1 working draft.

The responses of the Working Group are below:

I.

The current editors draft hopefully addresses the issue of the exact behaviour of aggregates in the absence of a GROUP BY expression.

The next working draft has a greatly expanded algorithmic description section, which we hope will address your concerns around translating the formalisms to code.

The Federated Query part will be a separate document, apart from the BINDINGS keyword, which will be part of the core Query document. The Federated Query part will be considered as optional.

The intention is to leave the grammar in the Query document, even though it covers both Query and Update.

Property Paths have been added to the list of new features in the editors draft.

The group agreed that the name for the HTTP Update protocol was too long, and has descided to change the name of that document to "SPARQL 1.1 Graph Store HTTP Protocol".

With regard to the "version" number of the SPARQL documents, the group felt that as backwards compatibility is maintained with version 1.0, 1.1 was the most appropriate name.

II.

The execution of aggregates is indeed complex, there is now something which explicitly sets out the order in the current editors draft. http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#convertGroupAggSelectExpressions

III.

The group is also aware that sufficient test coverage in this area has not yet been achieved.

The group has decided that BINDINGS will be usable outside of a federated queries.

IV.

At the start of the working group, the group discussed the various features that were desired by the community, and voted on where people's priorities lay. At this stage things like the number of existing implementations were taken into account. There were seven known implementations at that time, the ones listed at http://esw.w3.org/SPARQL/Extensions/Paths plus cwm.

The explanation of ListEval and ListEvalE has been expanded somewhat to make it clearer.

The "scalar" (now consistently named "scalarvals") argument to the Aggregation function is there for the GROUP_CONCAT aggregate, and also for extension aggregates, which may also require scalar arguments.

In the current editors draft HAVING is defined in terms of Filter(), and the scoping is more clearly set out, which will hopefully make that operation clearer.

There is now a algorithmic sketch to show how Aggregate Values should be applied to Solution Sequences in the current editors draft, if can be found in the section on Evaluation Semantics.

Yes, EXISTS and NOT EXISTS can only be used in FILTER expressions.

The pseudo code in the Aggregates section has been greatly expanded in the current editors draft.

Regarding conformance levels. Currently the group feels that it would be best to have a single recommendation without different conformance levels.

Please respond to this mail saying whether you feel it has addressed your questions sufficiently.