On 2014-12-24, at 17:38, Andy Seaborne <[email protected]> wrote: > 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.
which, with respect to the comment earlier in the thread - with reference to the substitution rule, leads to confusion. > 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. which can mean only, that it could limit the cardinality of the returned solution field (as suggested in the federation recommendation), but not that there should be any substitution of the form which the comment earlier in the thread implies. > 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. indeed. the federation recommendation describes the semantics in terms of select - which it must given the permitted syntax, rather than leaving room for the suggestion that the exists clause contains just a bgp, to which one might have argued, substitution would apply. > > 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. i had not seen the text itself as requiring improvement until i read you comments about substitution, which suggested that they would apply to the service clause. did i mis-read? our current implementation does perform the sidewards-information-passing (aka substitution) which is described in the sparql recommendation, subject to contour constraints of the kind which you describe, above, but my experience is that the practical performance consequences for "(not) exists” are unfortunate and a concrete goal is to re-implement those based on joins. at that point, it might be appropriate to offer suggestions and i will. best regards, from berlin, --- james anderson | [email protected] | http://dydra.com
