Bovlb patch 1

[bovlb]

Summary of changes

The following SPARQL where clause:

?s :hasIngredient [:name "chicken"], [:name "butter"] .

should be parsed as:

_:1 :name "butter" .
_:2 :name "chicken" .
?s :hasIngredient _:1 .
?s :hasIngredient _:2

but was instead being parsed as:

_:1 :name "chicken" .
_:1 :name _:2 .
_:2 :name "butter" .
?s :hasIngredient _:1

I fixed the bug and added a new test.

Checklist

• Checked that there aren't other open pull requests for
  the same change.
• Checked that all tests and type checking passes.
• If the change has a potential impact on users of this project:
  • Added or updated tests that fail without the change.
  • Updated relevant documentation to avoid inaccuracies.
  • Considered adding additional documentation.
• Considered granting push permissions to the PR branch,
  so maintainers can fix minor issues and keep your PR up to date.

[bovlb]

pre-commit.ci autofix

[bovlb]

pre-commit.ci autofix

[coveralls]

coverage: 90.293% (-0.006%) from 90.299%
when pulling e287709 on bovlb:bovlb-patch-1
into 9c469b5 on RDFLib:main.

[ashleysommer]

Wow. Thanks. I can't believe a bug like that in the SPARQL parser has existed undetected for so long.
Was the bug only when the two bnodes are on the same line? Did it have the same problem when thee bnodes were separated over two lines like this?

?s :hasIngredient [:name "chicken"],
                  [:name "butter"] .

[bovlb]

Wow. Thanks. I can't believe a bug like that in the SPARQL parser has existed undetected for so long.

I didn't believe it at first myself.

Was the bug only when the two bnodes are on the same line? Did it have the same problem when thee bnodes were separated over two lines like this?

That doesn't change the token sequence, so it's the same problem.

The bug was that we were assuming a comma implied we should repeat the third-last and second-last results as the subject and object of the new triple. This assumption didn't hold when we had inserted a triple from a blank node.