3

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)

Stanislav Kralin
  • 11,070
  • 4
  • 35
  • 58
Max
  • 685
  • 4
  • 14

2 Answers2

4

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)

Jeen Broekstra
  • 21,642
  • 4
  • 51
  • 73
  • thanks for the precision, I had forgotten this fact. I don't know if the changes would be simple but it would be nice to be compliant :) – Max Feb 10 '15 at 05:40
  • Just to be sure then, about the inference scoping graph in the recommendation, that would mean the inference is computed using only the query active graph? Ie an engine instance per request? – Max Feb 10 '15 at 05:53
1

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.

Joshua Taylor
  • 84,998
  • 9
  • 154
  • 353
  • Hi @Joshua, thanks for answering but I don't get your point. Here I really want to know how the entailment regime implemented on a store defines its scoping graph (and to what extent the recommendation is helpful before going into implementation-dependancy). Meaning should the inference be evaluated globally (depending on the regime and graphs in the store) or if the reasoner uses the queries active graph. – Max Feb 09 '15 at 18:29
  • @Max I was primarily referring to the part of the question where you said: " '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 ?" I was just responding to the part about what active graph means, and that since the contents of the default graph are implementation, when the active graph is the default graph, its contents are implementation dependent. Jeen's answer (which I've upvoted) is much more specific and probably more useful. – Joshua Taylor Feb 10 '15 at 15:43
  • ok, I understand your answer better now ;) but, since Jeen confirmed that my test was moot regarding the recommendation, that still leaves me with the the entailment scoping graph perspective (see the second comment on Jeen's answer). Anyway I may post a distinct follow up question to clear thins up. Feel free to participate ;) Thanks anyway – Max Feb 10 '15 at 16:17
  • see http://stackoverflow.com/questions/28436622/sparql-1-1-entailment-regimes-and-query-with-from-clause-follow-up – Max Feb 10 '15 at 16:26