Re: Ambiguity for Literal order in SPARQL

> Hmm, good point. I can propose to add a short paragraph to 11.3.1:
> [[
> Additional mappings of the '<' operator are expected to control the
> relative ordering of the operands, specifically, when used in an
> <a href=3D"#modOrderBy"><code>ORDER BY</code></a> clause.
> ]]

I'd agree with that, with an addition (see below).

> The problem is that I'm not convinced that they should or should
> not affect ordering, or even how much time it's worth delaying the
> specification for this. The current spec does not specify total
> ordering in part because the use cases didn't motivate us to. Not
> every implementor decision that affects the query results need be
> specified, only those where interop is useful.

I don't really mind either way. If implementations can extend  
ordering, a note must be added that, in general*, queries featuring  
LIMIT/OFFSET and ORDER BY are not interoperable.

>> You upgrade your =20
>> implementation and your queries start yielding different results. =20
>> That's bad.
>
> But how bad? We worked hard to avoid this in terms of the collection
> of results. I guess changing the order and then slicing means you have
> a different answer in your reported collection.

The results returned by a query featuring ORDER BY will have an  
implementation-defined ordering whenever values with datatypes other  
than string, boolean, datetime, or numeric are compared. Furthermore,  
the results returned by queries featuring both ORDER BY and LIMIT or  
OFFSET are entirely implementation-dependent whenever such datatypes  
are used.

This means that the WG's efforts to provide for only extension, not  
modification, of behavior apply only to the evaluation of a subset of  
all queries -- those without these characteristics.

(Sliced results are already somewhat damaged because there is no  
total ordering: when a slice point falls in an undefined segment of  
the results, unexpected behavior can occur. This makes things a  
little worse, though.)

I'd suggest adding some text to the effect of my text above, with the  
additional advice that ordering expressions can use STR() or another  
operator to guarantee the type of values to be compared, thus  
controlling the ordering.


Thanks for your reply, Eric.

-R


* queries without specific efforts made cannot be guaranteed to be  
interoperable:

   ORDER BY ?x
   -- not interoperable, because ?x could be any value, and trigger  
any implementation of less-than.
   ORDER BY str(x)
   -- interoperable, because string< is well-defined.

Received on Monday, 26 February 2007 17:55:19 UTC