You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason this is an issue is that it results in unexpectedly empty result sets when e.g. having a join with basic federation between a conforming system and qlever - i.e. term equality then no longer holds:
Example
SELECT * { #
BIND(1 AS ?x) # conforming system that uses xsd:integer
SERVICE <http://qlever.service/sparql> {
BIND(1 AS ?x) # qlever that uses xsd:int
}
}
Examples of literal syntax in SPARQL include:
...
1, which is the same as "1"^^xsd:integer
1.3, which is the same as "1.3"^^xsd:decimal
1.300, which is the same as "1.300"^^xsd:decimal
1.0e6, which is the same as "1.0e6"^^xsd:double
The text was updated successfully, but these errors were encountered:
Aklakan
changed the title
Integer literals in SPARQL returned with incorrect type.
Literals in SPARQL returned with incorrect type.
Feb 18, 2025
Qlever incorrectly returns numeric literals as
xsd:int
instead ofxsd:integer
. Not sure if this is an issue of the parser or the query processor.Actual result:
Expected result:
The reason this is an issue is that it results in unexpectedly empty result sets when e.g. having a join with basic federation between a conforming system and qlever - i.e. term equality then no longer holds:
Example
Further issue:
1.3
becomesxsd:double
, should be xsd:decimalFrom the SPARQL Spec:
The text was updated successfully, but these errors were encountered: