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 | [email protected] | http://dydra.com
Yes - it is intended to a remote request to a different dataset as
provided by the remote endpoint.
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. 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.
