Re: Comparison with non-standard datatypes

Ok, thanks Andy. I must have missed this extension mechanism which seems to be doing what we would need.

With this I am pleased with the response and we can close this topic.

Thanks,
Holger


On Jun 15, 2011, at 1:12 AM, Andy Seaborne wrote:

> 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 23:36:20 UTC