Problems related to initialBindings

[bergos]

Issue type:

• 🐛 Bug

---

Description:

I plan to use Comunica for SPARQL support in shacl-engine. While running tests from the official test suite, I came across a few issues related to initialBindings. I created a repository with examples to reproduce the problem. There is a comment on top of each file with more details.

Repository with examples

[github-actions]

Thanks for reporting!

[rubensworks]

Thanks for reporting these findings @bergos!

@joachimvh I suspect this is similar to recent issues you fixed in the algebra (#1223 and #1294). Could you check if this is something that needs changes in the algebra? If not, I can have a closer look to see if changes are needed on the Comunica-side.

[joachimvh]

@joachimvh I suspect this is similar to recent issues you fixed in the algebra (#1223 and #1294). Could you check if this is something that needs changes in the algebra?

Note that for both those issues I didn't take the initial bindings into account. There already was an issue with the original query without adding bindings when converting to algebra and back to SPARQL. So I had a look here to see if there also was a similar issue.

In this case the generated SPARQL query was the same as the original query (again without applying bindings), except for the one in pre-binding-002. There the output query is

SELECT ?this WHERE {
  FILTER("false"^^<http://www.w3.org/2001/XMLSchema#boolean> 
         && (?this = <http://datashapes.org/sh/tests/sparql/pre-binding/pre-binding-002.test#InvalidResource>))
}

So probably for that one there is a bug in the algebra where the filter scope gets pulled out of their group graph patterns and applied to a higher level. Tbh, reading the spec on this again, this is probably a misinterpretation I made when originally implementing this. I opened joachimvh/SPARQLAlgebra.js#105 for this.

But so for all the other ones I wouldn't know what the cause is. I didn't look into the effect of applying the bindings as I'm not sure how this works in Comunica. Is the query itself changed or is this applied afterwards?

[rubensworks]

So probably for that one there is a bug in the algebra where the filter scope gets pulled out of their group graph patterns and applied to a higher level. Tbh, reading the spec on this again, this is probably a misinterpretation I made when originally implementing this. I opened joachimvh/SPARQLAlgebra.js#105 for this.

Thanks! :-)

But so for all the other ones I wouldn't know what the cause is. I didn't look into the effect of applying the bindings as I'm not sure how this works in Comunica. Is the query itself changed or is this applied afterwards?

The handling of the initial bindings is done here, so mostly non-sparqlalgebrajs code indeed.

[simonvbrae]

As discussed with @rubensworks, I will work on this issue.

[simonvbrae]

What is the expected behaviour of the second filter expression in this query (taken from example pre-binding-002.js) when the InitialBinding for this has the value 'ex:InvalidResource'? @bergos

PREFIX ex: <http://datashapes.org/sh/tests/sparql/pre-binding/pre-binding-002.test#>
    SELECT $this WHERE {
      {
        FILTER (false) .
      } UNION {
        FILTER ($this = ex:InvalidResource) .
      }
    }

[bergos]

@simonvbrae The first part of the union is empty, and the second one returns one row with $this bound to ex:InvalidResource, which would also be the final result set.

[simonvbrae]

@simonvbrae The first part of the union is empty, and the second one returns one row with $this bound to ex:InvalidResource, which would also be the final result set.

Thank you for your reply! I have solved a couple of your examples including the query I mentioned above.

As for the query1 and query2 examples, what exactly is expected there?
I'm not sure if the filter clause should be applied to the values, meaning after, which would result in the values being ignored.
For reference, query1 and query2:

  PREFIX ex: <http://datashapes.org/sh/tests/sparql/pre-binding/pre-binding-002.test#>
  SELECT $this $that WHERE {
    {
      VALUES $that { "test1" }
      FILTER (false) .
    } UNION {
      VALUES $that { "test2" }
      FILTER ($this = ex:InvalidResource) .
    }
  }

SELECT $this $that WHERE {
  {
    VALUES ($that) { ("test1") }
    FILTER (false) .
  } UNION {
    VALUES ($that) { ("test2") }
    FILTER ($this = ex:InvalidResource) .
  }
}

[bergos]

@simonvbrae In both cases, I would expect a single row with $that = "test2" and $this = ex:InvalidResource.

However, while the other examples are from the official SHACL test suite, I built these two by myself, and I'm not 100% sure how VALUES and initial bindings should interact. These examples were mainly included to help trace the issue. I noticed that the engine behaved differently for initial bindings than patterns matching triples in the data graph or values injected with the VALUES keyword.