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: Andy Seaborne <andy.seaborne@talis.com>
Date: Tue, 17 Nov 2009 12:03:21 +0000
Message-ID: <4B029109.60800@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>

On 17/11/2009 11:44, Steve Harris wrote:
> On 17 Nov 2009, at 11:35, Andy Seaborne wrote:
>>>> 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.
>> Yes, it would fall under extend - it returns a value - I was bring up
>> a simpler and yet nasty case :-)
>> We do have the opportunity to define MAX itself. MAX/empty-set can be
>> a defined to return term sparql:noValue. Not a null per se but it
>> might work out. sparql:noValue + 0 is an error.
> Right, that may have some slightly strange consequences, and will land
> us more obviously in tri-value logic space, but overall it may be less
> confusing to users. The slightly odd corner cases are things like:
> A) SELECT ?x (MAX(?y) AS ?max) ... you get ?x and unbound value for ?max
> - probably expected
> B) SELECT ?x (MAX(?y) + 1 AS ?max1) ... you get no row.
> But probably users will figure this out. It's reasonably logical. I
> think SQL would always give you the row, as per A), because NULL+1 is
> NULL, not an error.
> - Steve, hoping sparql:noValue wasn't supposed to be a URI :)

It can be a URI :)  The other alternative is a literal that is in a 
value space disjoint from all others.

Received on Tuesday, 17 November 2009 12:03:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:58 UTC