Consider adding a context to bindings?

[surilindur]

Issue type:

• ➕ Feature request

---

Description:

There may be use cases where metadata should be maintained per bindings instance, and carried with the bindings all the way to the query engine output (I do not know how to express this properly, sorry). One such example use case could be when multiple sources may contribute to a single result binding, and information about the exact sources contributing to a specific result from the query engine are needed, to help trace back any potentially weird results or filter them as needed.

To help address this use case and potential other ones, perhaps a context could be added to bindings, with functionality similar to the context being passed to the query engine itself and then passed around internally to actors. For example, a Bindings instance could have a context property where members could be accessed using a IBindingsContextKey:

function exampleSourceAddition(bindings: Bindings): void {
  const sourcesKey: IBindingsContextKey = new BindingsContextKey('urn:comunica:something:sources')
  const sourcesValue: Set<string> = bindings.context.getSafe<Set<string>>(sourcesKey)
  sourcesValue.add('https://example.com/sparql')
  bindings.context = bindings.context.set(sourcesKey, sourcesValue)
}

Maybe the existing context-related work could be generalised, to have an IContextKey, IContext, etc.? That way, any future aspects of the engine also needing context could be taken into consideration, and it would help reduce the amount of types because there are already a lot of them.

I am just creating this issue to open the discussion around the topic. 🙂

[github-actions]

Thanks for the suggestion!

[rubensworks]

We could probably indeed directly use the IContext interface, and add it as a context field to bindings.

I guess we'll want the context to be only assignable during creation of the bindings? This will require us to go beyond the bindings factory interface of RDF/JS.

Another question is how to handle joins, where 2 bindings are merged (see the merge functions). We may want to require the caller of the merge function to explicitly say how the contexts of 2 bindings should be merged, as there may not be a generic way that is good for all cases.

[maartyman]

In the current version of incremunica (an incremental version of comunica that can process both additions and deletions) I added a diff boolean to the Bindings class to define if a Binding has been deleted or added. A context field for the bindings as described here could perfectly allow for this functionality without the need to change this core comunica package.

Indeed, when merging two bindings, these contexts need to be combined. In my case, if either one of the bindings has a negative diff (meaning it has been deleted) the resulting merge binding has to have a negative diff too (logical and). (At this moment, this has not been correctly implemented in the master branch of incremunica)

[rubensworks]

It sounds like we may want to introduce some kind of merge-handlers for bindings context keys, which define what to do when specific context keys are merged. Perhaps we could even introduce a new bus for this.

[maartyman]

An important consideration is to also alter the @comunica/jest to take into account the context when comparing two bindings.