[BUG] xsd:decimal in SAMM is converted to type=number in json-scheme?

[miwamasa]

Describe the bug data type with "xsd:decimal" is converted to type=number in json-scheme, where in the carbonfootprint in WBCSD context, it should be string with some constraint in json.

SAMM file=Pcf.ttl

A carbonfootprint example of eclipse-tractusx https://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.pcf/4.0.1/Pcf.ttl

the Pcf.ttl supposed to be aligned with the WBCSD's specification:

Technical Specifications for PCF Data Exchange (Version 2.0.1-20230927)

in the specification, the "fossilGhgEmissions" is defined as "Decimal" with type=String.

in the Pcf.ttl, "fossilGhgEmissions" type is defined as "xsd:decimal" via (fossilGhgEmissions-> PositiveEmissionsTrait;->PositiveEmission)

Where

the json-schema converted by samm-cli indicates "fossilGhgEmissions"'s type is "number" which means float in json via (fossilGhgEmissions->PositiveEmissionsTrait)

Additional context As far as I know, xsd:decimal permits both string format "2.24" and numeric format 2.24.

But in json context, it should be string with some format constraints.

for example official json-schema from WBCSD (although v1) says:

https://github.com/wbcsd/pathfinder-use-case-001/blob/main/spec/rest-api/openapi-1.0.0-beta2.json

fossileGhgEmission is positivedecimal which is defined as string with regrex constraint.

[miwamasa]

Additional Information: current SAMM cli converts xs:decimal to AAS as INTEGER_MEASURE

[miwamasa]

The issue is summerized as follows:

Background:

• In some cases, especially enterprise application, precision wise numeric data type is necessary
• Decimal(in WBCSD's PACT case) is such precision wise numeric data type
• The Decimal is represented as JSON String to keep precision-wiseness

  Question:

• How to express such precision wise numeric data type(in conceptual manner) in SAMM?
• what kind of conversion to JSON/AAS is adequate for such datatype
• In PACT/WBCSD's case , it is JSON String for its representation

FYI: OData v4 case

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.

[chris-volk]

Dear @miwamasa , apologies for the late reaction. Thanks for reporting this topic and giving all the context. Myself I knew PCF, but not the WBCSD specification.

I understand that you're working in the context of catena-x with product carbon footprint. First of all, the discussion of datatypes in json, particularly strings, is coming up repeatedly and we try to maintain the right balance between diversity in modeling capabilities and implementation friendliness. We shall capture it even better in a forum article or in a documentation section.

The current state of SAMM and serialization in SDK is according to https://eclipse-esmf.github.io/samm-specification/snapshot/payloads.html#data-type-mappings : hence, current status is that within ESMF XSD:decimal is always represented as a JSON number. This is consistent and allows a serialization, therefore what you are reporting is not a bug within ESMF. However, this does not help you yet.

Let me outline different paths that catena-x and ESMF can tackle your issue, which have to be discussed:

• One can argue that the expressivity in SAMM is not sufficient and it is not possible to exactly follow a given datatype description as required by Technical Specifications for PCF Data Exchange (Version 2.0.1-20230927) and additional mapping possibilities shall be added. In essence, treat this issue as an improvement request to ESMF SAMM&SDK . We would have to be careful with this, since more possibilities, and particularly using strings in JSON comes with additional cost for developers.
• One can argue that there is a bug/inconsistency in the catena-x PCF model https://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.pcf/4.0.1/Pcf.ttl since it does not follow the WBCSD specification exactly. That would have to be raised within catena-x, and what could be done? Perhaps model it as a regular string instead of xsd:decimal, and describe it as a string for a decimal value with a regular expression constraint, hence have it serialized to JSON string. One would have to be very careful with that since all implementations have to be changed, and would afterwards be more complex.
• One could argue - and that's perhaps the best solution - that the WBCSD specification and the PCF model by catena-x are two slightly different specifications, and that the catena-x model is perhaps the more implementation friendly one that is the more common practice for web apis. In order to find out, one would have to gain knowledge about how and why WBCSD is used, who is using the PCF for which purpose. However, this discussion should be had within catena-x .