W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

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

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 17 Nov 2009 10:32:41 +0000
Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-Id: <C8F91392-D2D9-4F6F-97B5-A85695333E18@garlik.com>
To: Andy Seaborne <andy.seaborne@talis.com>
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  
>> 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 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  
Received on Tuesday, 17 November 2009 10:34:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC