W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2011

Re: Comparison with non-standard datatypes

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 14 Jun 2011 16:12:52 +0100
Message-ID: <4DF77A74.6000003@epimorphics.com>
To: public-rdf-dawg-comments@w3.org

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
> *
> *FILTER* ("42"^^xsd:float > "8"^^xsd:float)
> }
> returns true. However, the following query with user-defined datatypes
> (here: unit:Meter) does not work
> *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
> *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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:29 UTC