Hi Andy, thanks for the reply!
> TDB1 and TDB2 do different things. TDB2 preserves integer subtypes > datatypes whereas TDB1 does not. > > It's the lexical form that is canonicalized - not the datatype. > > The distinction of "070", "70", "+70" etc is lost and become "70". Just to confirm that I understand what you mean by "preserves integer subtypes": when I insert the following two triples into either a TDB2 instance, or the default memory model... (triple _e <http://xmlns.com/foaf/0.1/age> "70"^^< http://www.w3.org/2001/XMLSchema#int>) (triple _e <http://xmlns.com/foaf/0.1/age> "70"^^< http://www.w3.org/2001/XMLSchema#integer>) ...there are actually two distinct triples in the model. If I insert the same two triples into a TDB1 instance, there is only a single triple in the model. Do I have this correct? My follow-up question is then around the purpose of `sameValueAs`, which is described in the typed literal howto ( https://jena.apache.org/documentation/notes/typed-literals.html): "There is a well defined notion of when two typed literals should be equal, based on the equality defined for the datatype in question. Jena2 implements this equality function by using the method sameValueAs. Thus two literals (“13”, xsd:int) and (“13”, xsd:decimal) will test as sameValueAs each other but neither will test sameValueAs (“13”, xsd:string)." Where are these `sameValueAs` semantics relevant? I don't immediately see that they play a role in triple insertion, deletion or unification in queries. Given the two triples above, if I query either the TDB2 model or the in memory model: (bgp (triple ?e <http://xmlns.com/foaf/0.1/age> "70"^^< http://www.w3.org/2001/XMLSchema#integer>)) I only get back a single binding, for the xsd:integer. Is `sameValueAs` also specific to TDB1? > When that spec says "the same type" in the context of the that spec at > that point, does it mean same xs:numeric basic types: xs:integer, > xs:decimal, xs:float and xs:double, or exact datatype? (The later 3.1 > adds "primitive datatype" but that post-dates SPARQL.) > > Generally, the interpretation seems to be the former - so long+long is > xs:integer+xs:integer (and can't overflow except for the implementation > limit on xs:integer) which is what Jena does. > > I can't find any examples on the web that show long + long -> long. > All examples are "integer + integer" suggesting arguments are raised to > one of the four xs:numeric types. > > > The safest approach if you want xs:long is to cast: > > xsd:long(?age + "1"^^xsd:long) > > The text in the latest spec 3.1 is: > https://www.w3.org/TR/xpath-functions/#op.numeric > > I'd be interested in knowing what other systems do here. > Thanks for the link Andy, that was very helpful.
