CONSTRCT..FROM does not work

[tpluscode]

Describe the bug

It should be possible to select graphs to query using the FROM keyword

To Reproduce Steps to reproduce the behavior:

1. JS oxigraph v0.4.0-alpha.7

2. Run this

   import * as  oxigraph from 'oxigraph'
   import rdf from '@zazuko/env'
   
   const q1 = rdf.quad(
     rdf.blankNode(), rdf.ns.rdf.type, rdf.ns.schema.Person, rdf.namedNode('urn:graph:a')
   )
   const q2 = rdf.quad(
     rdf.blankNode(), rdf.ns.rdf.type, rdf.ns.schema.Person, rdf.namedNode('urn:graph:b')
   )
   
   const store = new oxigraph.Store([q1, q2])
   
   store.query(`
     CONSTRUCT { ?s ?p ?o }
     FROM <urn:graph:a>
     WHERE { ?s ?p ?o }
   `, {
      use_default_graph_as_union: true,
   })
   

3. Expect one result, from graph:a but get both triples

Only happens with use_default_graph_as_union = true. Nor does it happen in docker version

[Tpt]

Sorry, it seems I forgot to reply to this issue. It's because the JS API follows the SPARQL protocol that states that the dataset specified in the protocol, (here {use_default_graph_as_union: true}) must override the one in the query (here FROM <urn:graph:a>). Having the opposite behavior would prevent implementing SPARQL protocol on top of Oxigraph

[tpluscode]

Firstly, can you explain why the JS version should behave different from the docker one?

I don't think I read the spec (you linked to v1.2 draft on purpose?) the same way. In the protocol, two dataset parameters are defined: default-graph-uri and named-graph-uri, which correspond to, and trump, FROM and FROM NAMED clauses respectively.

What neither the protocol, nor the query syntax supports is specifying the union graph as the default graph. Thus, other engines I am familiar with allow what oxigraph also has: to use the union of all graphs as the default.

I do not, however, see that it should conflict the spec. use_default_graph_as_union is not a parameter defined by the spec and thus its interpretation should be fairly open. Granted, shall it be combined with default-graph-uri, I expect that it would be ignored. Otherwise, I do not see any issues.

[Tpt]

Firstly, can you explain why the JS version should behave different from the docker one?

I am confused. I think the behavior of the docker version is the same as the JS one. In the HTTP server, the URL query argument union-default-graph overrides the FROM part of the SPARQL query text.

you linked to v1.2 draft on purpose?

I find it slightly more readable. There is no substantive change between v1.1 REC and v1.2 draft.

What neither the protocol, nor the query syntax supports is specifying the union graph as the default graph. Thus, other engines I am familiar with allow what oxigraph also has: to use the union of all graphs as the default.

Yes!

I do not, however, see that it should conflict the spec.

Inded, you are correct. It would not conflict the spec because as you said the spec does not talk about this parameter at all.

If I understand the problem properly, there are two options:

1. Consider use_default_graph_as_union as a variant of default-graph_uri that instead of limiting the default graph to a given named graph set the default graph as the union of all graph. Then for consistency the two parameters should behave the same way and use_default_graph_as_union should override the FROM part of the query.
2. Consider that use_default_graph_as_union is applied before dataset selection to just tweak the definition of the default graph. Hence, if present, the FROM part of the query overrides the use_default_graph_as_union argument and use_default_graph_as_union is not incompatible anymore with default-graph_uri (default-graph_uri has the priority).

Currently Oxigraph implements option 1 if I am not mistaken. If I understand correctly you would prefer option 2. Am I correct?

[tpluscode]

If I understand correctly you would prefer option 2

I suppose it's also a matter of familiarity. Of course I do not know all engines but it's what I learned to expect.

On the other hand, using the protocol parameters could be something I should start doing, making this issue somewhat irrelevant.

[Tpt]

Thnk you! I think it would make sense to revisit Oxigraph behavior in the next major release. #1011 adds support to set a named graph in the JS Store.query method

[tpluscode]

Nor does it happen in docker version

Actually, I think I was wrong. Adding ?union-default-graph argument to the endpoint also causes FROM to be ignored. I still do not think this is right and the bahaviour surprising.

[Tpt]

Adding ?union-default-graph argument to the endpoint also causes FROM to be ignored.

This priority is to reflect that the default-graph-uri query parameter overrides the FROM definition accoding to the SPARQL protocol spec. But I agree it's confusing and should maybe be revisited.