Add SPARQL evaluation tests for triple terms and reified triples

[rubensworks]

These tests are derived from the rdf-star SPARQL evaluation tests.
https://github.com/w3c/rdf-star/tree/main/tests/sparql/eval

All tests pass on my end, but to make sure I did not make any mistakes, it would be good if we have at least one other reference implementations that pass all these tests in the same way.

Closes #140

[afs]

These look great!

I have a problem with one test (op4) which I'm 95%+ certain is an issue with the Jena result set comparison code.

[afs]

I am getting different answers for :irireifier and _:bnodereifier (non-literals)

The test is <= and => - and there is no fall back to RDFterm-equals/sameValue but they are equal terms.

The question is whether being = should imply that <= and => are true.

Got: 8 --------------------------------
------------------------------------------------------------------------------
| x    | left                            | right                             |
==============================================================================
| :x10 | _:b0                            | _:b0                              |
| :x9  | :irireifier                     | :irireifier                       |
| :x7  | <<( :a :b 9 )>>                 | <<( :a :b 123 )>>                 |
| :x6  | <<( _:b1 :b 123e0 )>>           | <<( _:b1 :b 123 )>>               |
| :x5  | <<( _:b2 :b 123 )>>             | <<( _:b2 :b 123 )>>               |
| :x3  | <<( :a :q <<( :a :b 123 )>> )>> | <<( :a :q <<( :a :b 123.0 )>> )>> |
| :x2  | <<( :a :b 123 )>>               | <<( :a :b 123 )>>                 |
| :x1  | <<( :a :b 123 )>>               | <<( :a :b 123.0 )>>               |
------------------------------------------------------------------------------
Expected: 6 -----------------------------
-----------------------------------------------------------------------------
| left                            | right                             | x   |
=============================================================================
| <<( :a :b 123 )>>               | <<( :a :b 123.0 )>>               | :x1 |
| <<( :a :b 123 )>>               | <<( :a :b 123 )>>                 | :x2 |
| <<( :a :b 9 )>>                 | <<( :a :b 123 )>>                 | :x7 |
| <<( :a :q <<( :a :b 123 )>> )>> | <<( :a :q <<( :a :b 123.0 )>> )>> | :x3 |
| <<( _:b0 :b 123 )>>             | <<( _:b0 :b 123 )>>               | :x5 |
| <<( _:b1 :b 123e0 )>>           | <<( _:b1 :b 123 )>>               | :x6 |
-----------------------------------------------------------------------------

(The "b0" is scoped to the table only - the first "Got" table use of "b0" is not the same blank node as in the "Expected" table.)

[rubensworks]

Thanks for checking the tests @afs!

I am getting different answers for :irireifier and _:bnodereifier (non-literals)
The question is whether being = should imply that <= and => are true.

I think your results are correct, and this is an issue in my implementation.
I will look into modifying the expected output after I fixed my implementation.

[rubensworks]

I think your results are correct, and this is an issue in my implementation.

@afs After some deeper analysis, I'm actually not sure about this anymore.

For instance, what happens with _:b0 is the following:

• _:b0 <= _:b0 && _:b0 >= _:b0 is decomposed into 2 branches.
• _:b0 <= _:b0 is translated into _:b0 < _:b0 || _:b0 = _:b0
• _:b0 < _:b0 could be executed first. But the SPARQL spec does not define the behaviour of < for blank nodes (also for IRIs). Therefore, implementations could throw a type error.
• This type error is propagated upwards following EBV propagation logic, and the result for _:b0 is omitted.

So based on my understanding of the spec, I believe both of our test outputs are actually correct, as Jena probably has a defined behaviour for comparing bnodes, whereas Comunica doesn't. (unless my reasoning is flawed somewhere)
Therefore, it might be better to modify the test to ensure equal outputs, by for example also including FILTER (isTRIPLE(?left) && isTRIPLE(?right)).

[afs]

@rubensworks Interesting!

I'll investigate further.

the SPARQL spec does not define the behaviour of < for blank nodes (also for IRIs).

Agreed.

logical-or is special. If one branch is true, the overall result is true. error || true and true || error are true (it makes || order independent).

[rubensworks]

@afs Thanks for your comment.

logical-or is special. If one branch is true, the overall result is true. error || true and true || error are true (it makes || order independent).

This was the problem in my implementation. Our <= implementation was not properly delegating to the logical-or operator, and was therefore missing the correct handling of errors.
After fixing this, I get exactly the same results as you (which I just pushed).

[rubensworks]

@afs I was just informed by my colleague @jitsedesmet (who implemented much of the expressions logic in comunica), that my comment above is not entirely accurate, and that our old implementation should in fact still be spec-compliant.

Because in https://www.w3.org/TR/sparql11-query/#OperatorMapping, <= is only defined in terms of logical-or for numerics. And since bnodes and IRIs are not numerics, <= is therefore also not defined for bnodes and IRIs.

So we might need to add FILTER (isTRIPLE(?left) && isTRIPLE(?right)) to the query of this op-4 test after all, for implementations that strictly follow the spec without operator extensions.
Do you agree with this analysis?