SPARQL Grammar updated

http://www.w3.org/2009/sparql/docs/sparql-grammar-11.html
(the final layout will be tweaked when it's stable).

This is, I hope, complete for SPARQL 1.1 Query.
Update is waiting for confirmation of the design.

The grammar is sufficiently large that it's likely not to necessarily be 
expressed the best way and also it's quite possible it has bugs in it.

So, I'd like to build the syntax test suite.

** request

To do this, could you email examples of complete queries that you think 
are legal for SPARQL 1.1 (and not for SPARQL 1.0). I'd also like 
examples of bad syntax, for designs that are not legal.

The queries don't have to make sense.

Examples:

Good:
SELECT (COUNT(*) AS ?C) {}

Bad:
SELECT COUNT(*) {}

** Notes:

* Aggregates, with DISTINCT always possible.  Custom aggregates included.

* GROUP_CONCAT(?x,?y ; SEPARATOR=";")

At F2F3, we converged on this named parameters form of GROUP_CONCAT.  I 
suggested a uniform treatment with params available in custom 
aggregates. However, having tried this, I found it leads to complexity 
without obvious benefit.

Question:
Is this legal:
   GROUP_CONCAT(?x,?y ; SEPARATOR=?sep)
where ?sep is some in-scope variable?  For now, I've made the separator 
a fixed string depending clarification.

* The form { ?s ?p ?o UNION { ?s ?p ?o } }
The second {} is necessary or else it get confusing about FILTERs

* Select expressions require named variables:
SELECT (COUNT(*) AS ?C) {}
   not
SELECT COUNT(*) {}

* SERVICE and BINDINGS
BINDINGS is the last thing in a query.

The "not set" keywork is UNDEF because we have a function call "BOUND" 
so "UNBOUND" seemed a touch confusing, and because it may become defined 
in the query.

 Andy

Received on Sunday, 25 April 2010 17:12:34 UTC