Re: "Unbound" in SPARQL (was Re: [TF-LIB] COALESCE is an unhelpful choice of name)

On 17 Nov 2009, at 08:59, Andy Seaborne wrote:
> On 16/11/2009 20:35, Steve Harris wrote:
>> On 16 Nov 2009, at 20:14, Andy Seaborne wrote:
>> ...
>>>> ?x = :alice, ?bestDay = 12
>>>> ?x = :bob, ?bestDay = 8
>>>> [no row for :carol because we can't return "unbound"/null from
>>>> MAX(?sales)]
>>>>
>>>
>>> Would this work?
>>>
>>> SELECT ?x ( TRY(MAX(?sales), -1) AS ?bestDay)
>>>
>>> or other choice of marker for no value.
>>
>> Yes, in this case, but it's a pretty poor substitute.
>>
>> I wonder if there's some wording where unbound expressions can be
>> projected, it seems a little odd that SELECT ?sales produces rows,
>> whereas SELECT COALESCE(?sales) doesn't.
>>
>> Probably if you chase this deep enough though you end up changing  
>> SPARQL
>> 1.0 results :( I guess we should have bitten the bullet and gone  
>> with a
>> tri-value logic to start with.
>>
>> - Steve
>>
>> PS I really don't like TRY() as a name, though I can see the logic  
>> in it.
>>
>
> The core of the issue is touching ?sales at all in an expression  
> context. COALESCE is merely invoking a value context.
>
> SELECT ?x
> SELECT (?x AS ?y)
> SELECT (?x+1 AS ?y)
>
> If we have "SELECT (expr AS ?y)" then (?x AS ?y) has ?x in an  
> expression context requiring a value.  In the second and third  
> cases, ?x is evaluated and if there is an error, we need to decide  
> what to do.
>
> At F2F2, the consensus was that type errors in project are  
> eliminated - I've been reading that as
>  SELECT xsd:integer("squirrel") {}
> has no rows.

Yes, that's my understanding too.

> (this part of the chat seems to have started with errors in  
> aggregates and I may be reading the point out of context.)

Perhaps if that only applied to the T -> TX transformation (in SQL  
speak), and not to projections it would be possible to address the  
usecase? Though, projecting unbound on errors doesn't really sit well  
with me.

> SPARQL only has we only have one kind of error and anyway choosing  
> different actions based on different error types will get tricky  
> because one error may lead to another.

Yep, that's not really very tempting.

> This is where the fact relational algebra rename is just a rename  
> (no expressions, it changes the name of a column) makes a difference  
> here. We could special case the translation to the SPARQL algebra:
>
> SELECT ?x 		=> project((?x),  ....)
> SELECT (?x AS ?y)       => project((?y), rename(?x as ?y) ....))
> SELECT (?x+1 AS ?y)     => project((?y), extend(?x+1 as ?y) ....))

But the example above was MAX(?x), so it would fall under the "extend"  
semantics anyway, I think.

- Steve

-- 
Steve Harris, CTO, 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 Tuesday, 17 November 2009 10:34:14 UTC