...
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 on them to the null context.