Unclear error when having unbound variables.

[rubensworks]

Executing a query like the following:

PREFIX tmp: <http://example.org/temporal#>
PREFIX sp: <http://example.org/singletonproperties#>
PREFIX m: <http://example.org/music#>
PREFIX radio: <http://example.org/radios#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?track ?tracktitle ?initial ?final
WHERE {
    ?track m:title ?tracktitle.
    ?sp2 sp:singletonPropertyOf m:plays.
    radio:q-music ?sp2 ?track.
    ?sp2 tmp:interval ?interval.
}

Will throw TypeError: Cannot call method 'replace' of undefined at the error event of the SparqlIterator. Most likely because the variables ?initial ?final are defined at the SELECT clause, but not inside the WHERE clause.

Link to the hdt dataset + ldf-server config to replicate this error: http://cl.ly/082N451L2o0u

---

Possible solutions could be:

• Not throwing an error, and always binding undefined with these unbound variables.
• Throwing a clear error when the query is being parsed.
• Clarify the current error.
• Not changing anything, since it's the user who entered an invalid query.

[RubenVerborgh]

Thanks for reporting; we should do a query sanity check to see whether all demanded variables occur in the query body.

[mielvds]

Note that the SPARQL specification says the following: If the evaluation of the expression produces an error, the variable remains unbound for that solution but the query evaluation continues. http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#assignment

So wether it is unbound or not, it should be there, so option 1 seems the only valid option according to the spec.

[RubenVerborgh]

Interesting find, @mielvds, although this only seems to hold in the case of expressions (BIND, SELECT, GROUP BY), not triple patterns?

And even in those cases, would expect a difference though between an expression that can never be evaluated (because the variable does not occur anywhere else in the query) or an expression which has a variable that has no value (e.g., it comes from an OPTIONAL clause). A quick search in the spec didn't reveal anything though.

[RubenVerborgh]

This was fixed by fa7b517a7aebfcf6311a2b0dd14f4d005f13aeeb.