Jesse Wright

@dependabot rebase

> The current solution limits flexibility here because we limit the results that are fetched via the Sparql filter. Although I do not really know how it works internally, do...

> The current solution is to prepend a '@'. This is workable but also not perfect because the JavaScript syntax does not that inside certain notations so you fallback to: ...

> Is it normal that the following does not work? > > ``` > await tomato.label.nl.sparql // undefined > ``` > > I would expect some value. If needed I...

In light of these comments around testing could you also add some integration tests like [this one](https://github.com/LDflex/LDflex/blob/master/test/integration/collections-query-test.js) which evaluates the query against an actual query engine.

The results seem to align with the sparql query issued in [this](https://github.com/LDflex/LDflex/blob/e7303dd8efb5346a5fb3356caea692f0ba2d0201/test/integration/sparql-test.js#L109-L115) test; @jblemee Is this the intended behavior? If it is, I think there would need to be a...

Aha fair enough, personally I think it would be best to introduce a new handler regardless so as to avoid introducing breaking changes.

Not only does this cause incorrect data, it can actually lead to an infinite loop of deductions when circular rule dependencies are involved

That's more or less what I am doing [here](https://github.com/comunica/comunica-feature-reasoning/blob/b939ae60ce5a1167e70a13c70523fa0b59ac2e66/packages/bus-rdf-reason/lib/ActorRdfReasonMediated.ts#L15-L23) in the reasoning bus at the moment - however, the difficulty lies in the fact that the `sourceId` is also required...

Sounds like it could work - though unless you are planning on changing the 'expected' context entries by users in `actor-init-sparql` then there will also need to be a pre-processing...