Enrico,
Yes - two things are happening - derived types get rolled up to
xsd:integer and also formats are canonicalized (well, the value is
stored and the lexical form is remade if needed).
{ ?a ?b 28 } matches { ?a ?b 0028 } and { ?a ?b +28 }
The original datatype could have been kept (needs 4 bits of encoding -
there are 13 derived types of xsd:decimal, from xsd:integer on down) but
"28"^^xsd:int would not match "28"^^xsd:integer without some cost.
Inlining the value really speeds up numerical filters like
FILTER ( ?x < 56 )
FILTER ( ?x > 4 && ?x < 56 )
Andy
On 09/07/13 09:24, Enrico Daga wrote:
Yes, I am using TDB, your pointers clarified all, thank you!
At the end, any SPARQL expression asking for xsd:int would match values
with xsd:integer and this applies to any canonicalized datatype.
Returning to my example, the following queries actually work:
select * from <http://example/int/integer> where { ?a ?b 28 }
or
select * from <http://example/int/integer> where { ?a ?b "28"^^<
http://www.w3.org/2001/XMLSchema#int> }
Thank you very much!
Enrico
On 8 July 2013 17:45, Rob Vesse <[email protected]> wrote:
Is this using TDB as a backend?
This is by design in TDB - see Value Canonicalization and TDB Design
(http://jena.apache.org/documentation/tdb/value_canonicalization.html and
http://jena.apache.org/documentation/tdb/architecture.html) - and not a
Fuseki issue but rather a feature of TDB.
Since TDB inlines certain datatypes into the Node IDs in order to speed up
common datatype computations it needs to normalize derived datatypes to
the appropriate base type. So as in your example anything derived from
xsd:integer will be canonicalized to the xsd:integer form.
Rob
On 7/8/13 8:50 AM, "Enrico Daga" <[email protected]> wrote:
Hi,
I loaded some data in Fuseki and found some differences in an xsd
datatype.
Follows a test case:
insert data {
graph <http://example/int/integer> {
_:ex <http://example.org/property/size> "28"^^<
http://www.w3.org/2001/XMLSchema#int>
}}
Selecting data from the graph <http://example/int/integer> will show the
value as <http://www.w3.org/2001/XMLSchema#integer> instead.
While this is not a big issue and I could live with that in principle, in
my specific situation (back-end migration to Fuseki), clients relying on
the xsd:int datatype will break (and I want the data to be consistent with
the legacy back-end).
Any advise? Should I open a bug towards 0.2.8? ;)
Thank you all,
Enrico
--
Enrico Daga
--
http://www.enridaga.net
skype: enri-pan
