Re: Comparison with non-standard datatypes

Holger,

The intended mechanism for datatype extension is described in SPARQL 
1.0, section 11.3.1 "Operator Extensibility" [1].

An implementation may extend function evaluation and comparison by 
adding new rows to the dispatch table.

In your example of:

"42"^^unit:Meter > "8"^^unit:Meter

which in base SPARQL is an error (no matching operator for ">" between 
unit:Meter and unit:Meter), the correct extension is to add ">" for 
(unit:Meter , unit:Meter).

The SPARQL test suite includes tests on xsd:date (see [2]) and are 
marked in the test suite with mf:requires

The group feels that implicit casting of unknown datatypes to numerical 
types would be a less useful mechanism.

We would be grateful if you would acknowledge that your comment has been 
answered by sending a reply to this mailing list.

Andy (on behalf of the SPARQL WG)

[1] http://www.w3.org/TR/rdf-sparql-query/#operatorExtensibility<br/>
[2] http://www.w3.org/2001/sw/DataAccess/tests/data-r2/open-world/date-3.rq

On 03/06/11 06:42, Holger Knublauch wrote:
> *
> Dear working group,
>
> I would like to suggest to add more openness and flexibility to SPARQL's
> handling of typed literals. Currently
>
> *
> *ASK**WHERE*{
> *FILTER* ("42"^^xsd:float > "8"^^xsd:float)
> }
>
> returns true. However, the following query with user-defined datatypes
> (here: unit:Meter) does not work
>
> *ASK**WHERE*{
> *FILTER* ("42"^^unit:Meter > "8"^^unit:Meter)
> }
>
> Could you please consider generalizing the Operator Mapping
>
> http://www.w3.org/TR/2011/WD-sparql11-query-20110512/#OperatorMapping
>
> so that all unknown datatypes default to 'numeric' treatment, so that
> their literal lexical form is mapped to decimal numbers? I guess the
> same algorithm would be needed in places like ORDER BY.
>
> We have real-world use cases where we would like to exchange product
> data with units, and all of them are essentially numeric. The current
> work-around
>
> *ASK**WHERE*{
> *FILTER* (xsd:float("42"^^unit:Meter) > xsd:float("8"^^unit:Meter))
> }
>
> (which works) looks overly complex and not generic. I believe opening
> this up will future-proof SPARQL before it gets frozen again for many years.
>
> Thanks for your consideration,
> Holger
>

Received on Tuesday, 14 June 2011 15:13:22 UTC