Re: json-ld-api type fidelity in RDF roundtripping

On 03/04/13 15:57, Sandro Hawke wrote:
> A few issues came up during my review, related to handling of typed values.
>
> My understanding is RDF allows typed values to be expressed in canonical
> form, like "1.1"^^xs:double or non-canonical form like
> "1.10"^^xs:double.   I suspect all existing RDF parsers & generators
> preserve the form, keeping things like trailing zeros. On the other
> hand, deeper systems like SPARQL engines often convert to canonical
> form.     Basically, it would be silly to require triplestores to
> remember not just the actually number being stored by also arbitrary
> additional data about how it was formatted, so we don't do that.
>
> I think it's clear all RDF consumers should accept input in either
> canonical or non-canonical form.   They may preserve things like
> trailing zeros, but they should not depend on them.
>
> With JSON, technically the syntax allows trailing zeros, etc, but JSON
> parsers are going to lose that information, because they return an
> actually IEEE Double instead of a string for that value.   So, in RDF
> terms, it makes sense to treat JSON-LD like a triplestore; it's going to
> lose any non-canonical form of the lexical representation of datatyped
> values.
>
> JSON-LD has two ways to express datatyped values in JSON.   It can
> either use native types (like 1.1) or expanded types (like { "@value":
> "1.1", "@type": "http://www.w3.org/2001/XMLSchema#double" }).
>
> Issue 1:  How should RDF->JSON converters handle typed values for which
> there is a JSON native type and which are not in canonical form.  Should
> they be converted to a JSON native value, in which case formatting
> (trailing zeros, etc) is lost, or should they remain in expanded form,
> so the full details remain.       I prefer just using native values,
> since I think it makes the system easier to use.   Basically, I think
> it's fine for components to convert things to canonical form when they
> can.  I'd also be okay with leaving it open to implementors.
>
> Issue 2: What about values which are going to be slightly changed by
> being converted to native form, like "1.99999999999999999999"^^xs:double
> ?   If that gets output in JSON as 1.99999999999999999999 I believe
> it'll get read back in as "2"^^xs:int.

Minor:

"1.99999999999999999999"^^xs:double isn't a double or at least not the 
double you may think it is . It is outside the precision range for 
doubles which is 53 bits.  As JSON uses doubles, effectively, they do 
roughy align on xs:double.

http://www.w3.org/TR/xmlschema11-2/#double

A decimal is arbitrary precision in XSD:

"1.99999999999999999999"^^xs:decimal

Decimals minimum precision is 18 digits.

and also
http://www.w3.org/TR/xsd-precisionDecimal/

> Should these be forced to
> remain in expanded form, to avoid this changing of value and even type?
> On this, I suggest expanded form be required if practical -- but I'm not
> sure it's always clear when it's required.
>
> These basically boil down to what kind of fidelity is to be guaranteed
> by round-tripping RDF->JSONLD->RDF.

which is a very good question

	Andy

>
>        -- Sandro
>
>
>
>

Received on Thursday, 4 April 2013 12:58:13 UTC