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 . }" );
}
}





Reply via email to