SPARQL 1.1 entailment regimes and query with FROM clause

Question

I'm currently documenting/testing about SPARQL 1.1 entailment regimes and the recommendation repeatedly states that

The scoping graph is graph-equivalent to the active graph

but it does not specifies what is the active graph referring to : is it the data-set used in the query ? a union of all graphs in the store ?

As a test to determine this , I got this graph URIed <http://www.example.org/> in a Sesame Memory store with RDF Schema and direct type inferencing store (v2.7.14)

@prefix ex:<http://www.example.org/> .
ex:book1 rdf:type ex:Publication .
ex:book2 rdf:type ex:Article .
ex:Article rdfs:subClassOf ex:Publication .
ex:publishes rdfs:range ex:Publication .
ex:MITPress ex:publishes ex:book3 .

I've been trying the following query (which means using the default graph thus the inference engine)

SELECT ?s WHERE { ?s a ex:Publication . }

As expected, it returns me all three instances

<http://www.example.org/book1>
<http://www.example.org/book2>
<http://www.example.org/book3>

while the query :

SELECT ?s FROM ex: WHERE { ?s a ex:Publication . } 

returns only

<http://www.example.org/book1>

Under the said circumstances, shouldn't both results be the same?

What should happen (according to the recommendation) if data and schema are split between two graphs in the store (like <urn:rdfs-schema> and <urn:data>, or even scattered across more graphs) and the query uses both graphs (or a subset of schema-related graphs) in the FROM clause instead of the default graph ?

Meaning should the inferencing be global throughout the store or does it depend on the query dataset ?

Or maybe is the recommendation loose enough to make this an implementation dependent issue ?

Thanks for your lights,

Max.

EDIT this question is being redirected to SPARQL 1.1 entailment regimes and query with FROM clause (follow-up)

Answer 1

Your second query only returns only book1 because in Sesame's RDFS inferencer, entailed statements are inserted in the default graph, not in the named graph(s) from which the premises for the entailment come. So the entailed results are simply not present in the graph you are querying.

The reason for this design choice is at least partly historic, as the Sesame RDFS inference engine predates the W3C notion of entailment regimes. The rationale at the time was that in the case of inferencing over several named graphs (where e.g. one premise comes from graph A and another from B), insertion in the default graph (rather than in either A, or B, or both) was simplest with the least amount for confusion.

Sesame currently does not explicitly support the W3C entailment regimes specification. However, if you feel that a simple improvement would be possible to make it more compatible, by all means log a feature request.

(disclosure: Sesame developer)

Answer 2

What exactly is in the default graph isn't specified by the SPARQL 1.1 standard. In particular, see 13.1 Examples of RDF Datasets which mentions that:

The definition of RDF Dataset does not restrict the relationships of named and default graphs. Information can be repeated in different graphs; relationships between graphs can be exposed. Two useful arrangements are:

• to have information in the default graph that includes provenance information about the named graphs
• to include the information in the named graphs in the default graph as well.

However, by using FROM clauses to specify which graph should be the default graph, or by using multiple FROM clauses to specify which graphs should be merged to be the default graph.

That's all concerning the default graph. The active graph is another term you'll see in the SPARQL 1.1 spec:

The graph that is used for matching a basic graph pattern is the active graph. In the previous sections, all queries have been shown executed against a single graph, the default graph of an RDF dataset as the active graph. The GRAPH keyword is used to make the active graph one of all of the named graphs in the dataset for part of the query.

So, you can use from (possible multiple times) to control the default graph, and thereby the initial active graph, and then graph { … } within a query to change the active graph.