the "fossilGhgEmissions" is defined as "Decimal" which is further described in JSON representation it MUST be encoded as a JSON String.
In 4.01/Pcf.ttl, fossilGhgEmissions has characteristic of "PositiveEmissionsTrait;" which has the base characteristic "PositiveEmission" which is bamm:dataType xsd:decimal.
But the json-schema translation which is gen/json-schema.json, says it is number in json.
Where
Your "fossilGhgEmissions" as json number is not aligned with the WBCSD's definition as JSON String
I guess, the WBCSD's specification of Decimal is precision wise numeric data type, so it is represented as JSON String for avoiding errors like 0.1+0.2!=0.3
FYI: this is what happened in python, this kind of error is not preferable for precision wise numeric type:
Additional context
Other property which has "Decimal" or variants may have the same issue.
FYI: In the OData v4(which is database community standard), the precision-wise data type is Edm.Decimal which is converted to JSON String or number, depending on the option IEEE754Compatible=true or false.
Describe the bug According to WBCSD's specification of PCF data , Technical Specifications for PCF Data Exchange (Version 2.0.1-20230927)
the "fossilGhgEmissions" is defined as "Decimal" which is further described in JSON representation it MUST be encoded as a JSON String.
In 4.01/Pcf.ttl, fossilGhgEmissions has characteristic of "PositiveEmissionsTrait;" which has the base characteristic "PositiveEmission" which is bamm:dataType xsd:decimal.
But the json-schema translation which is gen/json-schema.json, says it is number in json.
Where Your "fossilGhgEmissions" as json number is not aligned with the WBCSD's definition as JSON String
I guess, the WBCSD's specification of Decimal is precision wise numeric data type, so it is represented as JSON String for avoiding errors like 0.1+0.2!=0.3
FYI: this is what happened in python, this kind of error is not preferable for precision wise numeric type:![image](https://github.com/eclipse-esmf/esmf-semantic-aspect-meta-model/assets/730771/7de43ac6-9487-4707-969f-0ce1285a874b)
Additional context Other property which has "Decimal" or variants may have the same issue.
FYI: In the OData v4(which is database community standard), the precision-wise data type is Edm.Decimal which is converted to JSON String or number, depending on the option IEEE754Compatible=true or false.