Why xsd:double? Why not xsd:decimal?

[dr-shorthair]

I note that in the section on conversion of native data-types, numbers with fractions are interpreted as xsd:double rather than xsd:decimal.

That is counter-intuitive to me when dealing with interpretation of a serialization, since conversion of a literal to a double is not exact in general.

[iherman]

I would expect that JSON conversions to various languages convert to float/double by default. It may lead to serious complications if the JSON-LD interpretation would be radically different: the idea is to provide an easy path from vanilla JSON usage to JSON expressing Linked Data.

It is perfectly possible to set the conversion to xsd:decimal explicitly in the @context, though:

{
  "@context" : {
    "xsd" : "http://www.w3.org/2001/XMLSchema#",
    "example": {
      "@id": "http://www.example.org/example",
      "@type": "xsd:decimal"
    }
  },
  "example" : 1.2345
}

The section you refer to only define the default conversion to Turtle.

[dr-shorthair]

The standard Turtle interpretation of a bare number-with-fraction is xsd:decimal, so there may be a complication here. Perhaps little more explanation in the text of why the default here is different? (it surprised me)

[pchampin]

I agree with @iherman's interpretation, and made a PR where this rationale is explained. This has to checked by @gkellogg or other members of the JSON-LD 1.0 team, though...

[gkellogg]

Text updated in #319.

@dr-shorthair, please indicate if this update satisfactorily addresses your concern.

[dr-shorthair]

Thank you. This does provide an explanation and alerts users to the solution selected.

(I remain suspicious about the general principle of reflexively casting numbers transported as strings into something different. But probably a battle to be fought elsewhere, sometime, maybe ...).

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Close syntax#318 as solved

View the transcript

4.1. xsd:double vs xsd:decimal
Rob Sanderson: #318
Gregg Kellogg: The JSON data model uses IEEE floats, they can not reliably encode doubles.
Proposed resolution: Close syntax#318 as solved (Rob Sanderson)
Rob Sanderson: +1
Gregg Kellogg: The spec has been updated to add a note. This should be sufficient to close the issue.
Ivan Herman: +1
Ruben Taelman: +1
Gregg Kellogg: +1
Pierre-Antoine Champin: +1
Resolution #2: Close syntax#318 as solved
Jeff Mixter: +1
Tim Cole: +1

[dr-shorthair]

Interesting. The proposed solution is to leave the type for numbers with fractions as xsd:double, yet the comment from Gregg Kellogg in the meeting minutes suggests that even that may be incorrect since JSON uses IEEE float internally. So is this issue resolved correctly?

[gkellogg]

It dos use float internally, but integers, at least within a certain range, can be unambiguously identified. We covered this in depth in 1.0.

[dr-shorthair]

But is float the same as double these days? If JSON-LD number+fraction is cast to xsd:double, but JSON uses float internally, isn't there still an inconsistency?

[gkellogg]

@dr-shorthair See RFC8259 section 6 on numbers. interoperability is generally the same as IEEE double precision floating point values, which is the same as xsd:double.

Note that the JSON Canonicalization Scheme, which we use when transforming JSON literals to RDF, does show a decimal-like representation (333333333.3333333) it could potentially be used to carve out a subset of xsd:decimal that could be generated, but without hints in the context, there would be no way to distinguish between what should be a decimal, float or double, so we're pretty might back where we were.

Of course, by this logic, how to distinguish double 1e0, or 1.0 from integer 1; this is where we took license in how to consider when transforming, which seems to have good acceptance.