Re: ProjectExpression andAssignment equivalence

On 8 May 2009, at 18:26, Seaborne, Andy wrote:
>> -----Original Message-----
>> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
>> request@w3.org] On Behalf Of Steve Harris
>> Sent: 8 May 2009 18:05
>> To: SPARQL Working Group
>> Subject: ProjectExpression andAssignment equivalence
>>
>> re. http://www.w3.org/2009/sparql/track/actions/13
>>
>> With some help from Luke I've worked out a plausible definition for
>> the LET() syntax that was in the wiki page, and shown an equivalent
>> general form in SPARQL + SubQueries + ProjectExpressions.
>>
>> http://www.w3.org/2009/sparql/wiki/Feature:Assignment#Equivalence_with_S
>> ubSelects_and_ProjectExpressions
>
> Looks good.
>
> I think you have to require that A does not mention v i...n as well  
> in your approach, which is OK.

Right, if you do, it gets a bit peculiar. That really just goes back  
to the point I was making about assignment not really being a sensible  
operation in RA. I had a brief stab at a more complex mapping, with a  
double rename, but it quickly got hard to read, as did the SubSELECT  
equivalent.

> I came up with some evaluation rules for variables when I added  
> assignment:
>
> A1:  If the expression does not evaluate (e.g. unbound variable in  
> the expression), no assignment occurs and the query continues.
>
> A2: If the variable is unbound, and the expression evaluates, the  
> variable is bound to the value.
>
> A3: If the variable is bound to the same value as the expression  
> evaluates, nothing happens and the query continues.
>
> A4: If the variable is bound to a different value as the expression  
> evaluates, an error occurs and the current solution will be excluded  
> from the results.
>
> ----
>
> A1 is a manifestation of whatever we decide to do with expression  
> failures in SelectExpressions.
>
> A2 is the expected case!

Hmmm, perhaps. I don't want to mention the N word, but that would  
weird me out a little.

> A3 and A4 are there for the cases when the assigned to variable  
> occurs earlier (deeper) in the query.  It works better with  
> OPTIONALs in the first pattern than simply forbidding the mention of  
> a variable in a pattern.  It can used to provide for default  
> values.   Again, this is not assignment-specific and occur in  
> SelectExpressions.

Sure, you need to say something about that case anyway. My belief is  
that the LET()-style syntax could give users who don't understand the  
underlying logic, the impression that they're doing something they're  
not.

The again, those same users would not understand the operation behind  
SELECT either, so might be surprised either way. It wouldn't be our  
fault though :)

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Saturday, 9 May 2009 08:32:19 UTC