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.

Received on Wednesday, 21 February 2007 20:30:34 UTC