Thanks for looking into this (or having recently looked into it)! It's just syntactic sugar, so it's no terrible inconvenience.
As an aside, I really like the property paths. They really make lots of queries much nicer. In particular, I've recently come of really like the "variable declaration"-like look of :Foo ^a ?foo1, ?foo2, ?foo3 . :Bar ^a ?bar1, ?bar2 . Thanks again! //JT On Sat, Feb 18, 2012 at 4:35 PM, Andy Seaborne <[email protected]> wrote: > Joshua, Rob, > > > Spooky. > > I found a similar (but different) bug in the SPARQL grammar only on Thursday > this week. > > ARQ is "correct" it's the published SPARQL grammar that's wrong. > > You found: > > [77] TriplesSameSubjectPath > ::= VarOrTerm PropertyListNotEmptyPath | > TriplesNode PropertyListPath > > so far so good: > > [79] PropertyListPath ::= PropertyListNotEmpty? > > should be > > [79] PropertyListPath ::= PropertyListPathNotEmpty? > ^^^^ > so currently no paths after non-empty [ .. ] (it's not just ^) > > I found that templates and query shared TriplesNode and it goes to > > BlankNodePropertyList ::= '[' PropertyListNotEmpty ']' > > so you can't have property paths inside []. > > i.e. { [ :p/:q 123 ] } > > The WG tests should have caught this (also my fault) so they need fixing as > well. > > Thanks for the report with complete details. > > BTW There is an online validator based on ARQ which I try to keep up to date > version-wise: > > http://www.sparql.org/query-validator.html > > Andy > > > > On 18/02/12 19:22, Rob Vesse wrote: >> >> ARQ 2.9.0 is out and available from incubator.apache.org/jena >> >> I'm afraid I don't know whether this is fixed in either that release or >> in trunk. Certainly the Fuseki 0.2.1 snapshot I have which uses ARQ >> 2.9.0 appears to hit the issue still so if you can confirm with core >> directly with the 2.9.0 code (and or the 2.9.1 snapshot) I'd go ahead >> and file a JIRA for this >> >> Rob >> >> On 2/18/12 10:33 AM, Joshua TAYLOR wrote: >>> >>> Hi all, I think this is a bug. The first three of the following triple >>> patterns are parsed successfully, but the fourth throws a runtime >>> exception.successfully. I'm using Jena-2.6.4 which includes with >>> ARQ-2.8.7. Can anyone confirm or deny this (or tell me that I'm using >>> an outdated version, or point me to the existing bug report that I >>> didn't find on JIRA,&c ;))? Thanks, //JT >>> >>> [] a :c; :p :o . >>> [] a :c; ^:p :o . >>> [ a :c ] :p :o . >>> [ a :c ] ^:p :o . >>> >>> Exception in thread "main" com.hp.hpl.jena.query.QueryParseException: >>> Encountered " "^" "^ "" at line 1, column 62. >>> Was expecting one of: >>> <IRIref> ... >>> <PNAME_NS> ... >>> <PNAME_LN> ... >>> <VAR1> ... >>> <VAR2> ... >>> "a" ... >>> "graph" ... >>> "optional" ... >>> "minus" ... >>> "bind" ... >>> "service" ... >>> "filter" ... >>> "{" ... >>> "}" ... >>> "." ... >>> >>> at >>> >>> com.hp.hpl.jena.sparql.lang.ParserSPARQL11.perform(ParserSPARQL11.java:87) >>> >>> at >>> com.hp.hpl.jena.sparql.lang.ParserSPARQL11.parse(ParserSPARQL11.java:40) >>> at com.hp.hpl.jena.query.QueryFactory.parse(QueryFactory.java:132) >>> at com.hp.hpl.jena.query.QueryFactory.create(QueryFactory.java:69) >>> at com.hp.hpl.jena.query.QueryFactory.create(QueryFactory.java:40) >>> at com.hp.hpl.jena.query.QueryFactory.create(QueryFactory.java:28) >>> >>> Code to reproduce: >>> >>> import com.hp.hpl.jena.query.QueryFactory; >>> >>> class QueryBug { >>> public static void main( String[] args ) { >>> String prologue = "PREFIX :<http://www.example.com/> SELECT * WHERE "; >>> // 1--3 are fine, but 4 throws an exception. >>> QueryFactory.create( prologue + "{ [] a :c; :p :o . }" ); >>> QueryFactory.create( prologue + "{ [] a :c; ^:p :o . }" ); >>> QueryFactory.create( prologue + "{ [ a :c ] :p :o . }" ); >>> QueryFactory.create( prologue + "{ [ a :c ] ^:p :o . }" ); >>> } >>> } >>> >>> >>> >> > -- Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
