On 24/12/14 12:29, james anderson wrote:
good afternoon,
On 2014-12-24, at 11:43, Andy Seaborne <[email protected]> wrote:
That would better. VALUES (?x) causes there to be a solution set
to be joined in the algebra expression. VALUES is syntax,
substitute() works on algebra expressions.
substitute() is also affected by scoping which the definition
ignores and shouldn't. Inner SELECTs and a WHERE with
non-projected ?x is really a different variable.
this brings up the point which would benefit from more careful
wording: how does the semantics of a service clause compare to that
of a subselect. in particular, given the discussion in the federated
query recommendation regarding the evaluation as a select and the
suggested means to propagate bindings, the binding environment for
the bgp within the service clause is somewhat less than
self-evident.
best regards from berlin,
Hi there,
The evaluation is defined, like everything else in SPARQL (or any
algebra) to be bottom up, that is, strict functional evaluation.
SERVICE looks like a remote SELECT *, specifically no projection Section
3 in the federated query spec:
Join(G, Service(IRI, Transform(P), SilentOp))
It may be better to evaluate using unscoped index joins and in the
SERVICE do this by sending over bindings. ARQ prefers index joins but
does not collect multiple bindings in VALUES for SERVICE.
(contributions welcome - maybe even an MSc project - I'm not aware of a
huge amount of coverage looking at the issues of operation on the web
but I haven't necessary been tracking it closely in recent years. There
is prior work - not web-related - for example, the work of the IBM
Research Garlic project on bind joins.)
You have to be careful about scoping and you can't always evaluate a
query solely in the style of binding propagating but the outer VALUES
clause should be correctly handled by any engine in this regard. There
isn't anything fundamentally special about SERVICE here. SPARQL 1.0 has
the case of nested optionals; there are others in 1.1 such as
projection+inner SELECT.
The benefits of rewriting and executing something more efficient for
SERVICE can be magnified by the network. So can doing the wrong
optimization! This is an implementation issue, not the semantics of the
query.
James - what would be most helpful is to post to SPARQL comments
explaining where the text can be improved. It will then at least make
sure it gets recorded for any future group.
Andy
--- james anderson | [email protected] | http://dydra.com
