- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Tue, 27 Oct 2009 05:18:01 +0100
- To: Holger Knublauch <yahoo@knublauch.com>
- Cc: SPARQL Working Group Comments <public-rdf-dawg-comments@w3.org>
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