I must say I am not a big fan of requiring a specific argument at query time to get the expected results. I like that SPARQL can be queried in a standard way to get expected results without needing to add a wrapper. And people who query should not think of which arguments they need to set in order to get the results they expect with a triplestore

But if you are ok with adding it to the server and oxrdflib graph arguments, then that's perfect! That leaves the previous behavior unchanged by default, and that gives admins like me the possibility to set their own preferences. I'll look into adding it when I will have some time.

I have already played a bit with rust recently :) https://github.com/vemonet/nanopub-rs and https://github.com/biopragmatics/curies.rs , oxigraph was the main source of inspiration (and code), thanks a lot!

@Tpt I had a quick look, and it seems we have 3 choices:

• Add a default_graph_as_union field to the Store struct, and create separate constructors Store::open_union() and Store::open_secondary_union(). This has the advantage to not change the arguments of existing constructors like Store::open() or Store::open_secondary(). But it adds more functions to the API, and requires to add a if/else to call the right constructor instead of just passing the variable.
• Otherwise we could add a default_graph_as_union boolean argument to the different constructors. It feels cleaner in term of API imo, but this would require to change all existing call to the open constructors, and introduce a breaking change for people who are using the rust library
• Last option does not require to change the Store struct at all. It could be directly picking up the default default_graph_as_union from environment variables in configure_and_evaluate_sparql_query(). Probably the worst in term of elegant API design, but this get the job done for most use-cases in 2 lines of code, without the need to touch to the Store.

Where goes your preference?

Probably the worst in term of elegant API design, but this get the job done for most use-cases in 2 lines of code, without the need to touch to the Store.

Just a bystander but I would strongly suggest to avoid environment variables as a primary configuration mechanism, they are ghosts.

I like that SPARQL can be queried in a standard way to get expected results without needing to add a wrapper. And people who query should not think of which arguments they need to set in order to get the results they expect with a triple store.

I would argue here the "standard way" according to the actual standard is to only query the default graph by default (see my reference above) and it's why I would call the "expected" results. If I remind correctly (but I might be wrong) it's what rdflib Dataset, Jena and RDF4J are also doing and I guess also a good number of other implementations.

I must say I am not a big fan of requiring a specific argument at query time to get the expected results.

To play the devil's advocate, this is what the SPARQL 1.1 HTTP protocol allows with it's default-graph-uri argument that allows to change the default graph. It's why I have added the union-default-graph argument.

I'll look into adding it when I will have some time.

Great! Thanks! RDFlib is already providing the __UNION__ option to the Store.query method when targeting the union of all graph so I would tend to think the change should be done in rdflib itself and not in oxrdflib. But I have not investigated it properly.

I have already played a bit with rust recently :) https://github.com/vemonet/nanopub-rs and https://github.com/biopragmatics/curies.rs , oxigraph was the main source of inspiration (and code), thanks a lot!

Amazing! I will have a look at them.

Where goes your preference?

None are good imho sadly. The env variable is a non starter imho per @adamreichold argument and because it prevents to have both a Store with "default graph is union" and a Store with "default graph is default graph" in the same process. I am also not at ease with the boolean arguments because I am ready to bet there might an other dozen of boolean arguments one might want to add there two so we might end up with unreadable open("path", true, false, true, true). Similarly, custom constructors is not a good idea imho because of combinatorial explosion.

Yes I agree none of these 3 solutions seemed clean, especially the env variable one

The best solution I know for this problem would be to use the builder pattern:

Instantiating a default store:

Store::open()
    .build()

With a custom union-default-graph:

Store::open()
    .set_default_graph_as_union()
    .build()

It will still require to update all calls to the Store constructor, but it is much more extensible, and it will allow you to add more configurable fields to the Store later easily without the need for more changes

Regarding the SPARQL specs, you are completely right, and it indeed behave this way with RDFLib, I just never noticed! To be fair, I am fine if you prefer to keep the union-default-graph just on the query, as long as we make it a bit clearer in the docs (maybe we could add a section about available params for HTTP query in https://github.com/oxigraph/oxigraph/blob/main/cli/README.md). But I still think it could be nice to set it at the server level, if you want to introduce the builder pattern :)