Allow blank nodes to be reused across expressions

[RubenVerborgh]

Currently, a blank node resulting from one expression, cannot be reused in another. Following the example of https://github.com/solid/query-ldflex/issues/33, the following snippets return different results:

const alice = "https://drive.verborgh.org/public/2019/blanks.ttl#Alice";
for await (const name of solid.data[alice].friends.name)
  console.log(`${name}`)

const alice = "https://drive.verborgh.org/public/2019/blanks.ttl#Alice";
for await (const friend of solid.data[alice].friends)
  console.log(`${await friend.name}`)

This happens because Alice's friends are identified by blank nodes, and they lose context across multiple expressions. If we retry both snippets with Alice2, which has IRI friends, we get the same results.

---

We could strive to reuse blank nodes across expressions, by internally skolemizing them. Here is a sketch of how that could work:

• When outputting blank nodes, Comunica assigns an internal identifier to them. For instance, _:b1 is still output as a BlankNode, but has a special internal field .skolemized that contains urn:skolem:1234.
• When a SPARQL query is generated from such a skolemized blank node, the skolemized IRI is used instead of a blank node.
• When returning results, any skolemized NamedNode is turned into a skolemized `BlankNode.

The key is inserting skolemization and deskolemization processing in the right place, for which I need to ask @rubensworks for help.

We could simply skolemize upon parsing, and then deskolemize right before results are returned. This works in all cases, except when Comunica directly operates on a store (the contents of which it did not parse, so it can contain actual blank nodes).

And alternative approach is a skolemizing store wrapper. It takes a store as an argument, and translates on the fly in its match etc. methods.

Perhaps both approaches can be used in conjunction: skolemization in parsers for all cases, except when a store is passed, then we wrap it.

[rubensworks]

Skolemization does indeed sound the right way to go here.

This issue in Comunica would be a requirement for this: comunica/comunica#355
And (AFAICS) that's probably everything that needs to be done, as all request go via the federated actor.

[justinwb]

Checking to see if this issue has been slated for work in the near term? We're running into some use cases that are blocked by this.

[RubenVerborgh]

@justinwb Will schedule it in @rubensworks' agenda.

[RubenVerborgh]

Or maybe also @joachimvh, they can decide who is most appropriate.

[rubensworks]

I've started working on the solution described in comunica/comunica#355.

This will mean that Comunica will not output any blank nodes anymore originating from sources (unless enforced by SPARQL via BNODE()). (The solution you describe would solve the problem here, but not the problem described in comunica/comunica#355)

As far as I know, this shouldn't be a problem for users downstream, and SPARQL spec-compliant.
@RubenVerborgh Do you agree?

[RubenVerborgh]

This will mean that Comunica will not output any blank nodes anymore originating from sources

That by itself seems too strong? Should at least be a switch (off by default to have correct query semantics)?

SPARQL spec-compliant

Do we have evidence? Perhaps something @Dexagod might want to dive into?

[rubensworks]

Hmm, I just realized there is a isBlank function. If we'd skolemize everything, this would definitely change the semantics of the query, which is not what we want.
So skolemizing everything may indeed be too radical. The internal .skolemized field may be a better solution.