You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in JSONLD it must be 1.23 and not "1.23" for a float.
I wrote in 3lbits/CIM4NoUtility#278 about the dangers of JSON numbers.
JSON doesn't define its numbers:
It doesn't define int, float, double: there's just "number".
And it doesn't specify whether a number should be represented as float, double or even infinite precision big decimal.
That is implementation specific.
We get what we want: "1.234567890123457E-1"^^xsd:float and "1"^^xsd:float.
But 1.234567890123457E-1 has too many decimals for a float. What happened is that internally it was processed as double, and only spit out with float datatype.
More importantly, you cannot control whether to enclose numbers in quotes on output.
I made tests with some tools (I'll commit the details to git):
tool
reactance
normallyInService
GraphDB
"0.123" xsd:float
"true" xsd:boolean
Jena riot
"0.123" xsd:float
"true" xsd:boolean
ttl2json
"0.123" xsd:float
true
Virtuoso context
0.1230000033974648
true
Virtuoso plain
0.1230000033974648
true
GraphDB and Jena output @value in quotes and always attach a datatype
Virtuoso outputs only @value without quotes (and adds some fake decimal digits due to internal conversions)
ttl2json outputs the number as @value in quotes with datatype, but the boolean without quotes
Note: in all cases we didn't specify a context to use (because it's not ready).
If we do, then more tools may output values in quotes.
What is the harm if JSON numbers are enclosed in quotes?
The text was updated successfully, but these errors were encountered:
Does this example not show that we "must" allow for both?
My understanding is:
The JSON-LD standard specifies that datatype declarations can be used to define the type of literal values, such as integers, dates, or custom data types, by adding a "@type" key within the context or within each value. This is optional in JSON-LD, as JSON-LD tries to be flexible with datatypes to accommodate varied data structures and maximize compatibility with JSON.
From this we have the following option:
Requiring Datatype Declarations
Not Allowing Datatype Declarations
Allowing Both With and Without Datatypes
As we have the context as part of the profile I do not see that we have to require it (1). However, interoperability is fundamental so that is pointing to requiring it. For me I would recommend (3) - Allowing both.
Virtuoso behaviours is generally not accepted. However, I think we have in CIM standard defined some tolerance that this would be inside.
(split off from #49)
I wrote in 3lbits/CIM4NoUtility#278 about the dangers of JSON numbers.
JSON doesn't define its numbers:
That is implementation specific.
https://json-ld.org/playground/
The result is
"0.123"^^xsd:double
and"1"^^xsd:integer
.So depending on the specific value, it's treated as different datatype!
We get what we want:
"1.234567890123457E-1"^^xsd:float
and"1"^^xsd:float
.But 1.234567890123457E-1 has too many decimals for a float. What happened is that internally it was processed as double, and only spit out with
float
datatype.I made tests with some tools (I'll commit the details to git):
@value
in quotes and always attach a datatype@value
without quotes (and adds some fake decimal digits due to internal conversions)@value
in quotes with datatype, but the boolean without quotesNote: in all cases we didn't specify a context to use (because it's not ready).
If we do, then more tools may output values in quotes.
What is the harm if JSON numbers are enclosed in quotes?
The text was updated successfully, but these errors were encountered: