- From: Richard Newman <r.newman@reading.ac.uk>
- Date: Wed, 21 Feb 2007 14:21:04 -0800
- To: "Stephane Fellah" <stephanef@imagemattersllc.com>
- Cc: <public-rdf-dawg-comments@w3.org>
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