The Issue

There seems no way to indicate the "Graph Store"'s default graph in SPARQL QUERY:

The SPARQL specifications are rather weird in this:

SPARQL QUERY defines a Dataset's "default graph" as a defineable graph which is either:
1. the "RDF Merge" of all named graphs, if no FROM/FROM NAMED clause is given
2. the dynamic "RDF Merge" of the sole graphs specified in one or more FROM clause
SPARQL UPDATE defines a "Graph Store" 's "default graph" as the unique "UNNAMED GRAPH" in the store. If no graph is specified in an update, the information is stored in the unnamed graph. A Graph Store's default graph seems to be in a 1-1 relationship with the Sesame's null context

So, issue is: how to indicate the "Graph Store"'s default graph in a SPARQL QUERY?

The issue seems to be at specifications' level, and obviously it has reflected in issues with the various technologies.

Here follow a few links related to management of Sesame's null context inside SPARQL

https://openrdf.atlassian.net/browse/SES-850
http://www.openrdf.org/issues/browse/SES-849
http://www.openrdf.org/issues/browse/SES-848
http://www.thefigtrees.net/lee/blog/2010/11/sparql_rdf_datasets_from_from.html
http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518

Possible solutions

In the following example, we show how to retrieve all triples from the sole null context of sesame2, by using a negation-as-failure pattern and removing all triples which are present in a named graph

PREFIX : <http://starred.it#>
prefix sesame: <http://www.openrdf.org/schema/sesame#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX st_example: <http://art.uniroma2.it/ontologies/st_example#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ann: <http://art.uniroma2.it/ontologies/annotation#>
PREFIX daml: <http://www.daml.org/2001/03/daml+oil#>

select ?s ?p ?o ?g
where
{ 
?s ?p ?o .

OPTIONAL { 
GRAPH ?g

{ ?s ?p ?o . }

}
FILTER ( !bound(?g) )
}

Equivalent solutions, can be obtained through these:

where
{ 
?s ?p ?o
MINUS { GRAPH ?g {?s ?p ?o} }
}

or

where
{ 
?s ?p ?o
FILTER NOT EXISTS { GRAPH ?g {?s ?p ?o} }
}

The problem is that if a triple is really (explicit) present in the default graph and in a name graph, this MINUS would find the triple in the named graph and thus remove it from the default graph

Following the issue

We have sent an email to the sesame general mailing list:

http://sourceforge.net/mailarchive/message.php?msg_id=31585163

and reported the issue in JIRA: OWLART-1

Note that we have also addressed the following issue about the ALL word in SPARQL:

Vedere se inserire un grafo fittizio corrispondente a tutti i grafi; in FROM avrebbe senso per mettere tutto nel default graph (che è di fatto il behavior di default, se non fosse che viene resettato a insieme vuoto quando viene specificato anche un solo FROM/FROM NAMED). Im FROM NAMED il discorso è più complesso, perché in teoria questo ANY (ALL?) dovrebbe matchare esattamente con il suo stesso nome, in quanto sono i nomi dichiarati nel FROM NAMED a poter essere usati poi nella query

on the RDF4J mailing list on 19/01/2017 : https://groups.google.com/d/msg/rdf4j-users/4ce117dR9J0/XXXVhkiwEAAJ

another one on RDF4J about behavior of the null context: on 25/01/2017 https://groups.google.com/forum/#!topic/rdf4j-users/dNDZ_nV93mA referring a previous one on OWLIM: http://answers.ontotext.com/questions/1166/null-context-inference-and-explicit-triples-from-other-graphs-inconsistency-with-sesame2-semantics

Nella mail non ho scritto che penso il behavior di RDF4J sia nato da un accostamento (in realtà sbagliato) al def graph di SPARQL (che per default contiene tutti i grafi) xchè nelle API l'equiv del def gtaph, che è un container dinamico, non è il null context, bensì la capacita di poter configurare i grafi. Il null context dovrebbe più essere messo in accostamento al default graph delle Graph Store API. Jeen replied telling that it is not necessarily a desired behavior in RDF4J, and it is most probably a bug in the RDFS reasoner (despite in an old email to a guy asking about the difference in behavior wrt Jena, he said it was simply a different interpretation of the default graph).

I checked without any reasoner and at least, with no reasoning (but asking for inferred triples) no triple from the other graphs is copied to the null contexts, (same thing with the directTypeInference), so it is really specifically the RDFS reasoner copying them to the null context.

Issues with the notion of default graph and SPARQL

The Issue

Possible solutions

Following the issue