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