Re: Ambiguity for Literal order in SPARQL

The text I was paraphrasing refers to extending the semantics of  
FILTER operations, and is quite clear. The difficulty here is that  
ORDER BY uses <, which is also a filter operation, and is subject to  
the operator mappings table: it's *not* clear whether extensions to  
this table apply to ORDER BY at all, or whether they are allowed to  
modify the ordering defined in an unextended implementation.

Given this sentence in 9.1:

"If the ordering criteria do not specify the order of values, then  
the ordering in the solution sequence is undefined."

from your example one could argue that, according to the standard,  
the ordering for an unextended implementation is only partially  
defined. In an extended implementation the ordering is defined, but  
the expectations of a user according to the standard are met, which  
is fine... for this simple case.

However, ORDER BY clauses rely on the undefined result to do cascading:

ORDER BY ?date ?someotherparameter

... a client can thus rely on the values of ?date being uncomparable  
to introduce sorting by some other parameter. Adding an  
implementation of < that compares these new datatypes to dateTimes  
alters that ordering clause so that the undefined sections are no  
longer ordered by ?someotherparameter. You upgrade your  
implementation and your queries start yielding different results.  
That's bad.

To clarify:

- you can extend < to apply to java:javaDateDTs if this extension  
only changes the behavior of the implementation where otherwise a  
type error would occur.
- however, it presumably should not affect the ordering of the  
required output of a query when compared to an unextended  
implementation. Thus, ORDER BY must not use the operator mappings table.
- to extend ordering, users should explicitly use conversion  
operators; it's very clear when these are implementation-dependent,  
so expectations are not confounded.

It is my personal opinion that ORDER BY clauses must be unambiguous,  
comparing only booleans, numerics, dateTimes, and strings. However, I  
don't think that the standard is clear on whether an implementation  
must yield an order that is comparable to the defined order of an  
unextended implementation. Would the WG care to comment?


> Thanks Richard for additional clarifications,
>
> You wrote:
>
> "Implementations may *extend* comparisons, but only where a type error
> would otherwise occur. No implementation should ever produce
> different results to those mandated by the specification, only
> additional results. I don't think that custom mappings between value
> spaces allows for that"
>
> I think my custom mappings between value space allows for that.
>
> Here an example:
>
> urn:S1 dc:created "Wed Feb 21 16:00:00 EST 2007"^^java:javaDateDT
> urn:S2 dc:created "2007-02-21T16:05:55.265-05:00"^^xsd:dateTime
> urn:S3 dc:created "Wed Feb 21 15:00:00 EST 2007"^^java:javaDateDT
> urn:S4 dc:created "2007-02-21T16:10:55.265-05:00"^^xsd:dateTime
>
>
> If the query looks like:
>
> SELECT ?s ?date
> WHERE {?s dc:created ?date}
> ORDERBY desc(?date)
>
> Assuming my implementation supports java:javaDataDT and map it  
> internally to
> Date (or Calendar) then I should get the following results:
>
> S3,S2,S1,S4
>
> If my implementation does not support the custom datatype, then I  
> will have
>
> S3,S1,S2,S4
>
> (S3 and S1 used lexical comparison, S2,S4 used value space comparison)
>
> You can notice that S1 precedes S2 in both cases, which is correct
> semantically, but the support of the custom datatype by the SPARQL  
> engine
> produces additional (enhanced) results.
>
> "No implementation should ever produce different results to those  
> mandated
> by the specification, only additional results". This sentence remains
> ambiguous to me.  I think the result I get is consistent with the
> specification.
>
> What do you think?
>
> Best regards
>
> Stephane Fellah

Received on Wednesday, 21 February 2007 22:21:15 UTC