Re: Missing LET (Assignment) in SPARQL 1.1

Perhaps (on a sunny day) I might have something to add to the
discussion, but please forgive me, I missed the point in which
order-dependence arrived. I've not been keeping up and frankly I can't
see how you can sensibly do it to OPTIONALs.

But as Holger points out, LET could likely be order-dependent, but -
it doesn't have to be a drain. CONSTANT, no? The first assignation is
the only assignation to care about.

Scoping of such things shouldn't be a big issue - we have brackets...

2009/10/27 Holger Knublauch <yahoo@knublauch.com>:

> Same with FILTERs - often the query designer knows very well where he wants
> the FILTERing to take place. Why should an engine be required to do the
> re-ordering automatically and possibly mess up any performance expectations?
> But that's a separate topic :)

Absolutely. A FILTER is a filter, how it's implemented is irrelevant.

> You can project multiple expressions from a single subquery, so I'm not sure
> that's a concern?
>
> The problem is readability. Imagine a couple of expressions in the same
> SELECT row...

I suspect (apologies again for not following relevant discussions)
that's flogging a dead horse - if you need projection, use CONSTRUCT,

> Again, why not put both calculations in a single subquery? I don't know what
> "*?this*" is, but I'd expect this query to be much easier to read as:
>
> CONSTRUCT {
>    ?diamond spinbox:replaceWith spinbox:Space .
>    ?world boulders:diamondsCollected ?newDiamondsCount .
> }
> WHERE {
>  SELECT ?world (?oldDiamondCount + 1 AS ?newDiamongCount)
> (spinbox:getNeighbor(?this, ?direction) AS ?diamond) {
>    ?world spinbox:field ?this .
>    ?world spinbox:keyDirection ?direction .
>    ?diamond a boulders:Diamond .
>    ?world spinbox:field ?this .
>    ?world boulders:diamondsCollected ?oldDiamondsCount .
>  }
> }
>
> Because I am using the variable ?diamond in the WHERE clause, and not just
> in the CONSTRUCT. ?diamond will have to be bound in the ?diamond a
> boulders:Diamond match, otherwise the whole query does not make sense.

Surely ?diamond would be there catching something even in version 1.001?

> Compare the original version below
> # Rule1: Collect and replace diamond if possible
> CONSTRUCT {
>     ?diamond spinbox:replaceWith spinbox:Space .
>     ?world boulders:diamondsCollected ?newDiamondsCount .
> }
> WHERE {
>     ?world spinbox:field ?this .
>     ?world spinbox:keyDirection ?direction .
>     LET (?diamond := spinbox:getNeighbor(?this, ?direction)) .
>     ?diamond a boulders:Diamond .
>     ?world spinbox:field ?this .
>     ?world boulders:diamondsCollected ?oldDiamondsCount .
>     LET (?newDiamondsCount := (?oldDiamondsCount + 1)) .
> }


The order of things appears to make things very messy, perhaps an
argument for avoiding it.
Maybe LETs should only appear at the start of a clause.

belated Cheers,
Danny.


-- 
http://danny.ayers.name

Received on Tuesday, 27 October 2009 04:18:35 UTC