On 17/06/16 20:36, james anderson wrote:
On 2016-06-17, at 21:10, Jeremy J Carroll <j...@syapse.com
<mailto:j...@syapse.com>> wrote:
Given the interesting conversation about EXISTS, I have a slightly
related question
select *
{ graph <eg:graph> {
?s <eg:b> ?o
FILTER EXISTS {
?s <eg:c> ?o
}
}
}
is the <eg:c> matched against the default graph or <eg:graph>?
given the definitions in the recommendation, {?s <eg:c> ?o } should
apply to the given graph.
while the definition does not take the trouble to describe the meaning
specific to forms, i have understood only
- {graph <x> {graph <y> … } } to limit the scope
- {graph ?x … } to have scope limited by projection which did not include ?x
- {graph ?? { service … } } to limit scope
where, for the service case, i am ambivalent.
I sometimes get results for this sort of query that surprise me, and
so I tend to explicitly repeat the graph scope.
In the definition:
https://www.w3.org/TR/sparql11-query/#defn_evalGraph
if IRI is a graph name in D
eval(D(G), Graph(IRI,P)) = eval(D(D[IRI]), P)
if IRI is not a graph name in D
eval(D(G), Graph(IRI,P)) = the empty multiset
eval(D(G), Graph(var,P)) =
Let R be the empty multiset
foreach IRI i in D
R := Union(R, Join( eval(D(D[i]), P) , Ω(?var->i) )
the result is R
...
so it is setting the active graph from "GRAPH <eg:graph>" or "GRAPH ?g"
to the {contained} pattern all the way down. No, you can't get back to
the default graph - the both WGs were aware of this as I recall.
For SERVICE, all that matters is the endpoint - the active graph is not
passed across.
Andy
best regards, from berlin,
---
james anderson | ja...@dydra.com <mailto:ja...@dydra.com> | http://dydra.com
