"SPARQL 1.1 Federated Query" : please clarify remote dataset [was Fwd: SERVICE within GRAPH

[james anderson <ja...@dydra.com>]

good afternoon;

a note in the recommendation to record the intent which mr seaborne relates, below, would help to clarify the service operator semantics with respect to the remote dataset.

Begin forwarded message:

> From: Andy Seaborne <an...@apache.org>
> Date: 30 September 2013 1:49:54 PM GMT+02:00
> To: users@jena.apache.org, james@dydra.com
> Subject: Re: SERVICE within GRAPH
> 
> On 29/09/13 16:32, james anderson wrote:
>> good evening, martynas;
>> 
>> 
>> On 29 Sep 2013, at 2:03 PM, Martynas Jusevičius wrote:
>> 
>>> Hey,
>>> 
>>> I want to do federation between to endpoints, both of which contain
>>> named graphs. I'm trying a query of this shape:
>>> 
>>> [...]
>> 
>> this is one of the several aspects of federation semantics which the
>> recommendations leave incomplete. the respective descriptions of algebra
>> translations and semantics, below, suggest that the initial dataset for
>> the remote query is the remote service's default dataset and that, in
>> particular, the dataset restriction effected by a graph operation, via
>> 
>>    eval(D(D[IRI]), P)
>> 
>> has no bearing on the interpretation of the service form,
>> 
>>    Invocation(IRI, P, SilentOp)
> >
>> in which, as the 'P' expression includes no provision to specify any
>> dataset, it is necessarily applied to whatever dataset the remote
>> service provides when a query does not describe the dataset. in the
>> context of your use case, this which would mean that the first statement
>> pattern would be executed against the default graph of that default
>> dataset and the inner graph clause would restrict that dataset with its
>> graph for its contained patterns.
>> 
>> best regards, from berlin,
>> ----
>> http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#sparqlTranslateGraphPatterns
>> http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#defn_evalGraph
>> http://www.w3.org/TR/2013/REC-sparql11-federated-query-20130321/#defn_service
>> ---
>> james anderson | james@dydra.com | http://dydra.com
> 
> Yes - it is intended to a remote request to a different dataset as provided by the remote endpoint.

at issue, is not the dataset statement content, but its graphs' names and its compositions in terms of named and default graphs.
in any case, the point is understood. in particular, given the clarification, below.

> 
> The federation case being addressed in SPARQL basic federated query is one where there is remote published data and the quesry wishes to incorporate access to that data during a query.  Each publisher (each service endpoint) is independent and the daatset at the remote endpoint need be nothing like the local one.  Passing the graph over is assuming a similar structure.  The app can do that by adding GRAPH inside SERVICE - that GRAPH refers to the remote dataset not the local one.  Consider the example of "GRAPH ?g".
> 
> There are other "federated query" cases, like one very large and compound dataset spread over multiple machines but essentially under one point of control.  This is not the intended target for SERVICE.
> 
> The datset for a query is local to the query processor and it knows nothing about the remote dataset other than it can access it via SERVICE.

at issue, is not what the local processor might know, but what the query author can specify.

>  The local GRAPH is not relevant - in fact, even if a graph using that IRI is available at the remote endpoint, it may not be the same graph.  Think of "current weather" which varies.
> 
> 	Andy
> 
> 
> PS Actually, you may be able to scope the SERVICE to a graph using ?default-graph-uri= in the service URL but it's not exactly convenient.

thank you for that insight.

best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com