Use xsd:decimal instead of xsd:float

[jmkeil]

Hi. In units.ttl, constants.ttl, prefixes.ttl there are some numbers with the datatype xsd:float. The accuracy of the values intended to represent is impaired by the use of xsd:float, as by definition the semantically represented value is a value, that can be represented with a IEEE 754 32 bit binary floating point number. Literals with lexical representations that do not exactly match a 32 bit binary floating point number are rounded. Following, the lexical representation suggests an accuracy that is not given. For example,

• "1e-06"^^xsd:float represents 0.0000009999999974752427078783512115478515625,
• "1e+30"^^xsd:float represents 1.000000015047466219876689E+30, or
• "0.0174532925199433"^^xsd:float represents 0.01745329238474369049072265625.

For xsd:float, only the first 7 digits are guaranteed (16 digits in case of xsd:double). Instead, xsd:decimal should be used, as it preserves arbitrary precision. xsd:decimal has the disadvantage to not permit exponential notation. But I think, preserving the accuracy of the numbers is of highest importance for the SI Reference Point, so this disadvantage is acceptable. Using xsd:decimal would also permit to use Turtle shorthand syntax for decimal numbers. Further, as xsd:integer is a subtype of xsd:decimal properties with Integer and Decimal Number values, could get the rdfs:range xsd:decimal, in contrast to xsd:float and xsd:integer that are not in a subtype relation to each other.

Related issue: #24 (@stuchalk), #59
Detailed discussion of the problem: https://doi.org/10.1007/978-3-031-06981-9_10

[Crparedes]

Thank you very much.
Using the functions you present in Figure 2 of your manuscript makes the issue evident on our side. For example, querying the prefixes in our SPARQL assistant:

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>
PREFIX si:   <https://si-digital-framework.org/SI#>

SELECT ?EnLabel ?Exponent ?dataType ?ScalingFactor
  (xsd:decimal( STRDT( STR(?ScalingFactor), ?dataType ) ) AS ?ActualScalingFactor)
WHERE {?SIPrefix
  skos:prefLabel ?EnLabel ; si:hasExponent ?Exponent ; si:hasDatatype ?dataType ; si:hasScalingFactor ?ScalingFactor .
  FILTER(lang(?EnLabel) = "en")
}
ORDER BY ?Exponent

Shows the reality:

If we change to xsd:decimal and replace scientific notation, the values remain unaltered (test done in our internal dev server):

[Crparedes]

The same goes for constants, running:

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>
PREFIX si:  <https://si-digital-framework.org/SI#> 
SELECT ?label ?value ?dataType
  (xsd:decimal(  STRDT( STR(?value), ?dataType ) ) AS ?ActualValue)

WHERE {?Constant 
  skos:prefLabel ?label ;  si:hasValue ?value ; si:hasDatatype ?dataType;
FILTER langMatches( lang(?label), 'en' ). 
}

Produces distorted values:

Now, if we run it on a ttl file where data type was changed to xsd:decimal, but keep scientific notation, turtle shorthand notation (as mentioned by @jmkeil, also in issue #59) assumes the value as double, and the query does not return an ActualValue column (but, why?):

If we replace scientific notation, the column appears and values are same as presented, not distorted anymore:

[fmeynadier]

Above mentionned commit (in a separate branch) is just a proposal, I was curious how we could implement that starting from the yaml... The idea is that the scripts themselves are in charge of converting exponents to the correct number of zeros in the string inside the TTL (then it is the user's choice how he wants it to be displayed).

[fmeynadier]

(some PEP8 changes slipped in due to my editor's settings... If you want a cleaner view of the commit, the cog icon offers the way to ignore "whitespaces" diffs)

[jmkeil]

the value as double, and the query does not return an ActualValue column (but, why?)

STRDT returns null if the lexical value is illegal for the datatype and the triple store seems to skip columns without a value in the first binding. Adding ORDER BY DESC(STR(?value)) will bring it back.

[jmkeil]

Which triplestore do you use? This seems to be a bug of it, comparing the results of SELECT * WHERE { VALUES (?a ?b) {(1 1) (UNDEF 1)} } and SELECT * WHERE { VALUES (?a ?b) {(UNDEF 1) (1 1)} }.

[Crparedes]

@fmeynadier the branch https://github.com/TheBIPM/SI-Reference-Point-2023/tree/77-decimal-datatype associated with this issue generates the decimal datatypes in the serialized TTL files from the YAML and the cuq Python scripts.

In my proposal there is minimal intervention to the YAML files, values are read as strings, converted to decimal using the decimal library (which @mgrub mentioned in the last meeting allowed exponent notation) and then stored as xsd:decimal or xsd:integer (according to what is in the YAML) into the TTL files.

[fmeynadier]

Sorry @Crparedes I did not realize you already started (although the name of the branch is perfectly clear and should have warned me !)

The motivation behind my approach was:

• to remove as much as possible redundant data in the manually modified YAML (i.e. remove scaling factors, which can be deduced from exponent; and set all types to decimal for homogeneity)
• to avoid any possible conversion error at the YAML -> rdflib level, e.g. if you forget to enclose the value in double quotes for constants. Separating between mantissa and exponent makes it impossible to miss.

... also using the Decimal lib, but constructing the input within the script.

I guess that the result is equivalent (except integer vs decimal cases)

[Crparedes]

@jmkeil, we are importing Jena 3.17. This needs to be upgraded and is a pending task.

[larsbarring]

Coming new to this repo, I will nevertheless jump in with a bold proposal:

Proposal: an exact-decimal datatype for authoritative numeric values

Problem

SIRP and the experimental CODATA Constants SemWeb service publish numeric values that are exact at source — defining constants are exact by construction following the 2019 SI redefinition; recommended values of measured constants are stated decimals with stated uncertainties; unit conversion factors are exact rationals. Both the values themselves and their associated standard uncertainties need to be representable exactly: an uncertainty such as 1.5×10⁻⁵ carries the same exactness contract as the value it qualifies, and is itself a small-magnitude decimal. The XSD numeric datatypes currently available do not preserve this exactness [1]:

• xsd:float and xsd:double silently distort decimal values that have no exact binary representation.
• xsd:decimal preserves precision but does not permit exponent notation. Several Planck-scale quantities published by CODATA already exceed the SI prefix range — Planck length is of order 10⁻³⁵ m, Planck time of order 10⁻⁴⁴ s — and the SI prefix range itself, recently extended to 10⁻³⁰ (quecto) and 10³⁰ (quetta) [2], is likely to be pushed further with compound prefixes already envisaged as a future extension [3]. Values requiring 30+ leading zeros in plain decimal notation are not a hypothetical future concern but a present one. This is a sustainability problem, not a stylistic one.
• xsd:precisionDecimal would have solved both — it supports exponent notation, arbitrary precision, and special values — but was removed from XSD 1.1 at Candidate Recommendation stage. The W3C Working Group's reason was a laconic statement that "there does not seem to be sufficient consensus in the community for its retention" [4]. The definition survives only as a Working Group Note [5], RDF implementations are not required to support it [1, §2], and to our knowledge no mainstream RDF framework (Jena, RDF4J, rdflib, Oxigraph) recognizes it as a built-in numeric datatype. In practical terms, xsd:precisionDecimal is not available.

Why this matters for SIRP and CODATA Constants

These are authoritative upstream sources. Consumers fall into two groups: SemWeb tooling (SPARQL, SHACL, reasoners) and everything else (Python, R, Julia, Rust, C/C++, Java, SQL, ...). The "everything else" group is dominant in scientific computing. Every existing XSD numeric datatype carries an implicit consumption convention that loses exactness — xsd:float/xsd:double map to native IEEE 754 binary, and xsd:decimal falls back to binary in most consumer pipelines because non-Decimal math libraries demand it. Importantly, the datatype tag itself does not signal to the consumer that the value should be treated as exact.

What is needed is a datatype whose contract is a publisher-side statement of fidelity: this value is exact at our end; no rounding, truncation, or binary approximation has been applied during publication. The datatype clearly signals that the default numeric pipeline (typically IEEE 754 binary) risks degrading precision, and that consumers requiring exactness should reach for arbitrary-precision tooling.

Proposal

Define a datatype — si:exactScientific — whose lexical form is mantissa + e + exponent (e.g. 1.602176634e-19), with arbitrary mantissa precision and arbitrary integer exponent. The value space is the exact rational mantissa × 10^exponent. Lexical form preserves trailing zeros (as precisionDecimal did) so that 1.60e-19 and 1.6000000e-19 are distinguishable in precision even though they denote the same value.

Defining a new datatype, rather than waiting for a possible future W3C process to revisit xsd:precisionDecimal, is justified by the position SIRP and CODATA occupy: as authoritative metrology publishers with a clear need that current XSD types do not meet, and no current indication that the W3C process will re-engage. The lexical form is deliberately identical to what xsd:precisionDecimal would have used, so if and when a standardized type does become available, migration is mechanical.

This datatype does not address:

• Symbolic constants such as π or e, which require structural representation (named entity + ratio) as discussed separately. In practice, however, consumers outside symbolic-mathematics tools work with finite-precision approximations of these constants (50, 100, or more decimal places). Such an approximation is itself an exact rational of the form mantissa × 10^exponent and is faithfully representable as si:exactScientific. The publisher states the truncation explicitly; the consumer knows precisely what they have received.
• Genuinely binary-native data (instrument output, computational results from binary-float pipelines), for which a hexadecimal-lexical datatype as proposed in [1, §7] would be appropriate. CODATA Constants and SIRP do not produce binary-native data, so this is out of scope here.

Why now

SIRP is in active development, as is CODATA Constants SemWeb publication. Both data models are still mutable. Once consumer codebases harden around the current representations, changing the published format becomes substantially more expensive. The diagnosis is now documented [1]; the SI prefix trajectory shows the magnitude problem will worsen, not improve [2, 3]; and no other authoritative metrology source has yet committed to a representation. The SIRP and CODATA
Constants teams are well-placed to coordinate on a shared convention before independent decisions diverge.

We propose that the two teams join forces on a shared exact-decimal datatype, with the goal of aligning on lexical form and value-space semantics before either project's representation is locked in — by independent decisions, or by users establishing their own ad hoc interpretations of what is currently available from the beta SIRP and experimental CODATA Constants services. A natural deliverable would be a jointly-authored paper in Metrologia or the Data Science Journal, both to document the agreed specification and to seed adoption beyond the two source projects.

References

[1] Keil, J. M. and Gänßinger, M. (2022). The Problem with XSD Binary Floating Point Datatypes in RDF. ESWC 2022.
https://2022.eswc-conferences.org/wp-content/uploads/2022/05/paper_98_Keil_et_al.pdf

[2] Brown, R. J. C. (2023). A further short history of the SI prefixes. Metrologia 60, 013001. https://doi.org/10.1088/1681-7575/ac6afd

[3] Brown, R. J. C. (2019). Considerations on compound SI prefixes. Measurement 140, 237–239.

[4] W3C XML Schema Working Group (2011). W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes — Changes since version 1.0. W3C Candidate Recommendation, 21 July 2011. https://www.w3.org/TR/2011/CR-xmlschema11-2-20110721/datatypes.diff-1.0.html

[5] W3C XML Schema Working Group (2011). An XSD datatype for IEEE floating-point decimal. W3C Working Group Note, 9 June 2011. https://www.w3.org/TR/2011/NOTE-xsd-precisionDecimal-20110609/

[Crparedes]

Thank you @larsbarring,

A similar proposal was made on the last meeting of the SI Digital Framework task group (2026-03-09, by @mgrub). However, a general response was that it could have negative effects on the interoperability of the data, as it could probably get treated as a typed literal with no numeric meaning, difficulting comparing and filter, or the performing of operations that are well established for adopted XSD datatypes. We could, of course, reopen the discussion.

To me, the current approach by CODATA Constants is good, it uses codata:valueFloat to present numeric values in scientific notation (sxd:float); codata:value for values typed as xsd:string; and codata:valueDecimal to present the calues in the (not so human-friendly, I admit) xsd:decimal. We propose a similar approach in the SI Reference Point, where the si:hasValue will contain the xsd:decimal, and the si:hasValueAsString currently presents the HTML-friendly version of that value. We could consider adding a si:hasValueAsFloat to incorporate the scientific notation version into the knowledge graph. This, I think, was also one of the proposals in the last meeting.

[larsbarring]

Thanks for the response @Crparedes

Obviously I was not aware of the preceding discussion. And I realize that I forgot to mention one important part in my proposal: it is intended to complement (not replace!) the values represented as xsd:decimal to support established SemWeb applications and workflows. The new datatype is genuinely a non-standard addition (CODATA's existing pattern uses custom properties with standard XSD datatypes; this proposal is the further step of introducing a non-standard datatype), and the case for it rests on technical gaps that the standard XSD types do not cover:

• The first is future-proofing for extreme magnitudes. xsd:decimal preserves exactness but cannot express exponent notation. CODATA already publishes Planck-scale quantities that require 35 to 44 leading zeros in plain decimal form. Values published at the SI Reference Point have not yet reached that magnitude, but that may come in the not so distant future. What today is a reality for the CODATA Constants may soon also face SIRP. And, now, when both services still are in a formative phase, is a good time to look at current potential limitations and hedge for future needs.

• The second is a publisher-side fidelity contract. Mantissa-and-exponent notation is the natural form for these values, as the existing si:hasValueAsString channel demonstrates with its typographic styling. The machine-actionable channel currently has no exact equivalent: xsd:decimal cannot express exponent notation, and xsd:float introduces silent binary distortion. si:exactScientific provides an ASCII-mantissa-and-exponent form that mirrors the structure of the existing human-readable channel, exactly preserved.

On the interoperability concern: it is a real point. A custom datatype IRI is, today, opaque to mainstream RDF tooling. But consumers that don't recognise the IRI fall back to RDF's standard behaviour for unknown datatypes -- exposing the lexical form as a typed string. The lexical form is the faithful, lossless representation of the exact value, so no consumer silently receives a corrupted value; they either get datatype-aware operations or a parseable string. In any case, the property name itself signals to a consumer outside the SemWeb context that the value requires extended-precision tooling. The existing xsd:decimal channel continues to serve consumers needing SPARQL-queryable numerics today.

The suggested si:hasValueAsFloat and si:exactScientific would occupy different points in the design space. si:hasValueAsFloat (typed as xsd:float) gives scientific notation that is queryable by mainstream tooling but inherits the already identified problem of binary approximation. si:exactScientific gives scientific notation that is exact but, today, requires fallback handling in tooling that doesn't recognise the IRI. Whether one, the other, or both are appropriate is a design decision for SIRP and CODATA, but the exactness need is not addressed by xsd:float.

My proposal was/is intended to offer a forward-looking perspective and possible solution to a known problem (cf. Keil & Gänßinger) of numeric representation in SemWeb context, where I think that SI and CODATA together have the unique authoritative position and a real use case for making a decisive impact. But, of course, I do not know anything about the considerations and technical aspects behind the current design path. Whether this warrants to reopen the discussion is really up to you. My perspective is really that of a user of the SIRP API and the coming CODATA Constants API (and other), where I have seen this kind of binary distortion of values.

[Crparedes]

Sorry for the very late reply @larsbarring,

Your proposal of the si:exactScientific typed literals as a complement of the xsd:decimal values, with the possibility of mechanically migrating to xsd:precisionDecimal if it becomes available in the future, sounds more sensible to me now.

Currently, we have implemented the xsd:decimal datatype and are close to releasing the first stable version of the knowledge model. The addition of si:exactScientific is something we should discuss also with members of the task group and, depending on the outcome, implement for upcoming updates.