Sesame SPARQL engine misinterprets half-unbounded path length expressions
Description
Environment
relates to
Activity
{min, max} path modifiers are to be removed from the parser altogether (see SES-1706), making this a moot issue. Marking resolved.
Sorry, I didn't notice your answer earlier.
The actual issue is not a huge problem for us internally, because there is a simple workaround. That is not why I created the issue as critical.
That said, in this case I don't agree with your assessment that "you should find that failing quickly is not always the best option". As I noted in the issue, I created the issue as critical because in this case the fault in the software causes the SPARQL engine to return an answer that is actually wrong and therefore misleading for further processing. This in contrast with the other, earlier error I reported, which just throws an exception – slightly annoying, but better for working projects that depend on Sesame because at least the query clearly does not work and no question about it.
More pointedly, the difference between the two situations is that in the exception case the problem is annoying but in this case the problem actually casts doubt on the reliability of Sesame (which is bad for the project as a whole). In this case my assessment (as a user of Sesame, but even more as a fan of the project) is that it would be better for Sesame to fail hard rather than send me down the wrong path. And that is why I made it a critical issue.
I would assume that other SPARQL engines would also be dropping support for this feature that didn't make it into the final specification, so we would be improving interoperability by now not providing it at all.
If you find cases where the SPARQL (or other) compliance tests fail to cover then please continue to report it to us, like this.
However, we are all volunteers on the project, and we have various, geographically distributed, day jobs that generally relate to Sesame, but are not our main job. You will quickly find that if you urgently need something fixed with any Open Source library that is staffed by a distributed network of volunteers that you need to provide a patch for it yourself, or at least try to delve into the internals to try to find the root cause yourself even if you can't fix it. Once you do that a few times you should find that failing quickly is not always the best option, particularly with SPARQL, as disabling a feature completely may affect well functioning queries.
Alternatively, you could get a support contract with one of the companies that provide third-party extensions to Sesame, or consultancy services, and then ask for them to fix it.
Well, from my point of view as the reporter, this issue contains a minor and a major problem:
The minor problem is that the property path length expression doesn't work (irksome, but not deadly in my case).
The major problem is that sesame can produce query results that are actually wrong.
If Sesame drops support for this expression I could certainly live with that as a solution to the (slightly less convenient, but okay) as long as the parser explicitly fails a path length expression. Sure, dropping functionality is the weak solution to the minor problem – but the important thing is that Sesame should fail early and explicitly in case of unsupported functionality rather than produce baloney answers.
The final SPARQL-1.1 Query specification doesn't seem to support this style of property paths anymore, although they were in an early draft.
Is this still an issue for Sesame?
0. Same tree as in SES-886: Application of transitive closure + in property path expression yields incorrect results when combined with other properties.Closed . 1. Try the following query: PREFIX test: <http://www.testerie.test.com/nodes#> select ?node ?name where { ?node test:hasParent{2} test:B . ?node test:name ?name . } RESULT: ============================================== node = http://www.testerie.test.com/nodes#K name = KKK ============================================== node = http://www.testerie.test.com/nodes#J name = JJJ That's okay. 2. Now try this one: PREFIX test: <http://www.testerie.test.com/nodes#> select ?node ?name where { ?node test:hasParent{0,2} test:B . ?node test:name ?name . } RESULT: ============================================== node = http://www.testerie.test.com/nodes#B name = BBB ============================================== node = http://www.testerie.test.com/nodes#F name = FFF ============================================== node = http://www.testerie.test.com/nodes#E name = EEE ============================================== node = http://www.testerie.test.com/nodes#K name = KKK ============================================== node = http://www.testerie.test.com/nodes#J name = JJJ Again, okay. 3. This one: PREFIX test: <http://www.testerie.test.com/nodes#> select ?node ?name where { ?node test:hasParent{,2} test:B . ?node test:name ?name . } EXPECTED RESULT: Same as under 2. ACTUAL RESULT: ============================================== node = http://www.testerie.test.com/nodes#K name = KKK ============================================== node = http://www.testerie.test.com/nodes#J name = JJJ 4. And this one: PREFIX test: <http://www.testerie.test.com/nodes#> select ?node ?name where { ?node test:hasParent{0,} test:B . ?node test:name ?name . } EXPECTED RESULT: Same as under 2. ACTUAL RESULT: ============================================== node = http://www.testerie.test.com/nodes#B name = BBB Seems like the parser is misinterpreting the one-way unbounded notation. Note: I'm creating this one as critical rather than minor because the answer is actually wrong.