SPARQL*: How should bind act?

[JervenBolleman]

Specifically in relation to non present triples and construct queries.

On an empty store

PREFIX ex:<http://example.org/>
SELECT ?x {
  BIND(<<ex:1 ex2: ex:3>> AS ?x)
}

expect one result.

PREFIX ex:<http://example.org/>
SELECT ?x {
  BIND(<<ex:1 ex:2 ?lala>> AS ?x)
}

expect no results.

Store with a single named graph
containing

ex:1 ex2: ex:3

PREFIX ex:<http://example.org/>
SELECT ?x {
  <<?s ?p ?o>>
  BIND(<<ex:1 ex2: ex:3>> AS ?x)
  FILTER(sameTerm(<<?s ?p ?o>> , ?x))
}

One result.

Store with two named graphs

graph:1 {ex:1 ex2: ex:3}
graph:2 {ex:1 ex2: ex:3}

Union graph semantics

PREFIX ex:<http://example.org/>
SELECT ?x {
  <<?s ?p ?o>>
  BIND(<<ex:1 ex2: ex:3>> AS ?x)
  FILTER(sameTerm(<<?s ?p ?o>> , ?x))
}

expect two results

PREFIX ex:<http://example.org/>
SELECT DISTINCT ?x {
  <<?s ?p ?o>>
  BIND(<<ex:1 ex2: ex:3>> AS ?x)
  FILTER(sameTerm(<<?s ?p ?o>> , ?x))
}

expect one result

Basically the issue comes down to a bind of a non variable currently (sparql 1.1) gives one value. In SPARQL* it might give more than one value.

[aarushiag]

Hi @JervenBolleman . We were going through this issue and found that parser.py binds the variable in the BIND expression (?x in ''BIND (<<?s ?p ?o?? AS ?x)"") to an Embedded Triple object and not to the variable which was assigned to the embedded triple after reification.

To correct the same we tried to make changes in parser.py by converting the Embedded Triple Object to a Variable(using toPython() function). However, we came to know that in the case when our SPARQL* query contains URIREF objects, the parser returns a Comp Value object and toPython can't work on CompValue objects. Hence, we suppose that only way to correct this would be to change the Embedded Triple Object into the equivalent variable before evaluating the bindings. (Or a better way could be to use a SID so that we can set the proper binding of the variable with the SID of the Embedded Triple in parser.py.)

[JervenBolleman]

@aarushiag I also think we need to convert the Embedded Triple Object into the variable before evaluating the bindings. Even when using SID. Because most stores won't have a Statement concept that is unique per triple but unique per quad.

Also for (BIND <<?s ?p example:1>> AS ?p) gives problems too as these are never one thing but a stream of things.

So I think we have a lot of complexity to work around in the BIND phase. The OntoText RDF4J solution is one, where it is effectively a FILTER. I don't know what the other projects have done.

[aarushiag]

@JervenBolleman , Yes you are correct in the sense that we need to perform the conversion of the Embedded Triple Object into the variable before evaluating the bindings. To do so, we suppose that the reification of the triples and the conversion of object into variable can be performed in the algebra.py file while making the query.
In one of your previous commits , I noticed that you had previously written the functionality for reification in algebra.py which you moved to evaluate.py in the later commits. Can you explain the reason behind the change?

[JervenBolleman]

@aarushiag yes I thought that having an fuction for reification in algebra was the natural place. Now I think it actually needs to move to the graph. It seems that only a graph can know how it is can efficiently reify an embedded triple. i.e. if it can give a sid or not.

[aarushiag]

@JervenBolleman I suppose the graph gives the query to the preprocessor.py which performs parsing through parser.py and further evaluation through algebra.py and evaluate.py. Since the reification must be performed before evaluation and after parsing, I cannot get how a graph can reify a triple.
Do you mean that the preprocessor should pass on the parsed query to the graph for reification before giving it to algebra and evaluate. Can you explain this in more detail ?

[aarushiag]

@JervenBolleman Going through multiple possibilities, I found that the whole reification code must be moved out of evaluate.py and should be performed after parsing the query. I wasn't very sure regarding the placement of the code (Whether it should be in algebra.py or graph.py). Also moving the whole code shall involve a series of testing as it might affect other cases. Hence I propose the above solution for BIND queries as a special case. I understand that this might not be an ideal solution but it might help to give an insight as to how BIND should work for Sparql star queries. Any suggestions are welcomed.

[JervenBolleman]

@aarushiag I think it is fine to special case it for now, and afterwards standardize.

In the end the "refication" code needs to be on the graph. I don't think the algebra is the part that can resolve this. Evaluate could but I think a new method on the graph layer will allow more optimization and better separation of concerns.