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

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.

	Andy

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