[ 
https://issues.apache.org/jira/browse/JENA-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241743#comment-17241743
 ] 

Andy Seaborne commented on JENA-2005:
-------------------------------------

The xsd:decimal change between 1.0 and 1.1 is a nusiense - it is the only such 
change though.

To be robust to all cases and consider values, you can use FILTER
{noformat}
  :s :p ?o . 
  FILTER (?o = 4)
{noformat}
or to be specific to decimals:
{noformat}
  :s :p ?o .
  FILTER (?o = 4 && datatype(?o) = xsd:decimal)
{noformat}

> SPARQL does not correctly handle xsd:decimal datatypes
> ------------------------------------------------------
>
>                 Key: JENA-2005
>                 URL: https://issues.apache.org/jira/browse/JENA-2005
>             Project: Apache Jena
>          Issue Type: Question
>          Components: Fuseki
>    Affects Versions: Jena 3.16.0
>            Reporter: Steve Baskauf
>            Priority: Minor
>
> In performing a federated query at the Wikidata Query Service 
> ([https://query.wikidata.org/sparql),] I bound the object of the triple:
>  
> <http://www.wikidata.org/entity/Q97446840>  
> <http://www.wikidata.org/prop/direct/P2896>  "4"^^xsd:decimal.
>  
> as it was provided by the SERVICE endpoint. I also bound the value of the 
> triple:
>  
> <http://www.wikidata.org/entity/Q97446840>  
> <http://www.wikidata.org/prop/direct/P2896>  "4.0"^^xsd:decimal.
>  
> which was present in the local dataset. (The value was originally loaded from 
> Turtle as the number 4.0 (not a datatyped literal).
> When I performed a MINUS operation between the bound values from the SERVICE 
> endpoint and the bound values from the local triplestore, this value should 
> have been removed from the result set because according to the XML schema 
> Recommendation [https://www.w3.org/TR/xmlschema-2/#decimal] both "4" and 
> "4.0" are valid lexical representations ("If the fractional part is zero, the 
> period and following zero(es) can be omitted.") of the same decimal number. 
> However, Fuseki did not recognize the two values as identical, which is an 
> error.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to