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

On 17/11/2009 12:28, Steve Harris wrote:
> On 17 Nov 2009, at 12:03, Andy Seaborne wrote:
>> On 17/11/2009 11:44, Steve Harris wrote:
>>>
>>> - 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.
>
> What about
 >
> SELECT ?x
> WHERE {
> ?x :p :o .
> OPTIONAL {
> ?x :doesnotexist ?y .
> }
> FILTER(?y = sparql:noValue)
> }
>
> v's
>
> SELECT * WHERE {
> { SELECT (MAX(?y) AS ?max)
> WHERE {
> ?x :p :o .
> OPTIONAL {
> ?x :doesnotexist ?y .
> }
> } GROUP BY ?x }
> FILTER(?max = sparql:noValue) }


They are different. (And independent of URI vs literal)

I'm also not against MAX(empty) being an error.  This seems the simpler 
design and most easily communicatable.

You can use TRY/COALESCE to turn errors into some other value (also 
needed if you have an unwritable value).

Short forms coudl be provided, if we think it's convenient, for 
application specific defaults : MAX(?x, emptyValue)

(This use of TRY/COALESCE is what you were proposing for handling xsd casts)

I don't have a problem with the fact these two are different. In SQL 
NULL does not join with NULL unless you provide an explicit join 
condition.  Once NULL appear in SQL, the SQL to cope with natural usages 
of two OPTIONAL, one after the other, is not natural and it's right we 
did not impose the same burden on application writers.


> It potentially has the opposite confusion problem to SQLs infamous WHERE
> x = NULL.

The constraints here are:
1/ XSD expression evaluation
2/ The simpler use cases of two OPTIONALs that drove the design of 
SPARQL 1.0.

We could do a superset of XSD, mod the restriction of SPARQL 1.0 
compatibility, but I think we'd get in trouble from the different 
sources of NULL (the old there are X types of SQL NULL anbd they are 
different).

Having complexity in the expressions, for a pattern matching language, 
is the right balance to consider.

> It might be easier to make it same value that can't be written down,
> then users can't distinguish it from the "unbound" value.
>
> - Steve

How is it serialized into XML results?

(Keeping it internal breaks federated query)

If you want an ideal solution, it probably means that every instance is 
distinct and unique.  Then undef != undef.

	Andy

Received on Tuesday, 17 November 2009 13:47:31 UTC