SPARQL parser not robust to spurious semicolon

[pchampin]

The following code:

import rdflib; res = rdflib.Graph().query("""
PREFIX rdfs:    <http://www.w3.org/2000/01/rdf-schema#>
CONSTRUCT {
  [ a rdfs:Class; ] .
} WHERE {}
""")

fails with:

Exception: these aint triples

while that SPARQL query is accepted by the validator at http://sparql.org/query-validator.html . If you remove the ";" after rdfs:Class, it works.

Granted, that semicolon is not required, but it should be tolerated (the Turtle parser tolerates it).

[pchampin]

Bump ?

Investigating a little more on this, I found that:

python -m rdflib.plugins.sparql.parser 'SELECT * { [ ?p ?o ] }

produces

[[], SelectQuery_{'where': GroupGraphPatternSub_{'part': [TriplesBlock_{'triples':
   [([rdflib.term.BNode('N09359afea7ad47cb83c49cd7a888730c'), ?p, ?o], {})]}]}}]

where 'triples' contains a list of 3 elements, which is ok.

while

python -m rdflib.plugins.sparql.parser 'SELECT * { [ ?p ?o; ] }' # notice the spurious ';' after ?o

produces

[[], SelectQuery_{'where': GroupGraphPatternSub_{'part': [TriplesBlock_{'triples':
   [([rdflib.term.BNode('Nbbd0449894a14243a4900a17c72f6c75'), ?p, ?o, rdflib.term.BNode('Nbbd0449894a14243a4900a17c72f6c75')], {})]}]}}]

where 'triples' contains a list of 4 elements, which is why the "these aint triples" exception is raised in algebra.py:triples, if I am not mistaken.

So the problem seems to come from parser.py:expandTriples, which does not handle that "spurious" semicolon correctly...

[gromgull]

I am very sorry to confirm that the spurious semicolon is really allowed :)

http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#rPropertyListNotEmpty

and it's right here:

https://github.com/RDFLib/rdflib/blob/master/rdflib/plugins/sparql/parser.py#L491

I would guess you need to check the remaining length here somehow:

https://github.com/RDFLib/rdflib/blob/master/rdflib/plugins/sparql/parser.py#L56

but I don't have time to play with it now.

[pchampin]

@gromgull They are allowed by the parser, indeed, but then incorrectly handled, causing the failure in algebra.py ("these aint triples" exception).
Worse, in some cases, it does not fail, but parses to the wrong graph. See for example:

      PREFIX : <http://example.org/>
      CONSTRUCT {
        :a :b :c ; ;
           :d :e ; ;
           :f :g ;
      } WHERE {}

produces

@prefix : <http://example.org/> .
:a :b :c, :d .
:e :b :d .
:f :g :d .

Thanks for the precise pointers though, I'm about to submit a pull request with a patch fixing this.