RE: Ambiguity for Literal order in SPARQL

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 



-----Original Message-----
From: public-rdf-dawg-comments-request@w3.org
[mailto:public-rdf-dawg-comments-request@w3.org] On Behalf Of Richard Newman
Sent: Wednesday, February 21, 2007 3:30 PM
To: Stephane Fellah
Cc: public-rdf-dawg-comments@w3.org
Subject: Re: Ambiguity for Literal order in SPARQL


> 1) 2 literals with the same value space.
>
> If both literals have the same datatype uri, thus they share the  
> same value
> space. It is also possible that both literals with different  
> datatypes share
> the same value space (For example: xsd:int,xsd:float,xsd:double  
> datatypes
> maps to value space of Numbers).

Presently, the SPARQL spec describes specific sorted orders for  
numerics, booleans, and dateTimes (see Section 11.1). Numerics of any  
kind are compared with op:numeric-less-than. The specific datatype  
URI doesn't matter beyond its specifying that the argument is a  
number. Note that this is true for all numerics (11.3):

"SPARQL follows XPath's scheme for numeric type promotions and  
subtype substitution for arguments to numeric operators. The XPath  
Operator Mapping rules for numeric operands {xs:integer, xs:decimal,  
xs:float, xs:double, and types derived from a numeric type} apply to  
SPARQL operators as well (see XML Path Language (XPath) 2.0 [XPATH20]  
for defintions of numeric type promotions and subtype substitution)"

> If the implementation provides a comparator for the value space,  
> then it
> should return the result of this comparison, otherwise delegate the
> comparison to the lexical form if not supported or equals value  
> returned.

See Section 11.3.1:

---
11.3.1 Operator Extensibility

Extended SPARQL implementations may support additional associations  
between operators and operator functions; this amounts to adding rows  
to the table above. No additional operator support may yield a result  
that replaces any result other than a type error in an unextended  
implementation. The consequence of this rule is that extended SPARQL  
implementations will produce at least the same solutions as an  
unextended implementation, and may, for some queries, produce more  
solutions.

---

in other words, a SPARQL implementation must support value-space <  
for numerics, booleans, and dateTimes. An implementation can  
optionally provide additional mappings for <, but only under the  
constraints given.

> 2) 2 literals with different value spaces (and by inference different
> datatypes).
>
> An example would be for custom temporal datatypes to be compared with
> xsd:dateTime or datatypes for unit of measure.
>
> If the implementation provides an "adapter" from one value space to  
> another
> and a comparator for these "compatible" values, then it should  
> return the
> result of this comparison, otherwise delegate the comparison to the  
> lexical
> form if not adapter or comparator supported or equals value returned.
>
> That means the comparison in value space would be implementation  
> specific.

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.

The best way to do what you're describing is through extension  
functions:

ORDER BY myfunctions:getDateTimeFromMyCustomDatatype(?somevar)

where myfunctions:getDateTimeFromMyCustomDatatype names a function  
that returns a dateTime literal from a literal with a "custom  
temporal datatype".

Use SPARQL's built-in sorting, but provide the sorting functions with  
the output of custom extension functions.

> Does the WG agree with this approach? Let me know if I was not clear.

Please note that I do not speak on behalf of the WG -- I'm just an  
implementer who's been working with SPARQL for a long time.


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.412 / Virus Database: 268.18.3/694 - Release Date: 2/20/2007
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.412 / Virus Database: 268.18.3/694 - Release Date: 2/20/2007

Received on Wednesday, 21 February 2007 21:57:18 UTC