search

sine-fdn / ileap-extension

SFC / GLEC Data Model Extension
https://sine-fdn.github.io/ileap-extension/
MIT License
0 stars 1 forks source link

How does host system recognize product or logistics carbon footprint with same path? #11

Closed nishiguchiH closed 2 weeks ago

nishiguchiH commented 7 months ago

Hi

As far as I read PCF Data Exchange / iLEAP Technical Specifications I understand that host system call PFN API with same path (GET https://{FQDN}/2/footprints) even when getting product carbon footprint or logistics carbon footprint from ohter system.

In that case, host system should recognize type of responsed carbon footprint value by extension property? or do you have any recommendation?

zeitgeist commented 6 months ago

Dear @nishiguchiH , my apologies for not following up earlier.

You are right. At this point, you can identify iLEAP service footprints by the existence of iLEAP-specific data model extension(s) only.

We are happy to improve on the tech specs if you could share more details (for instance, which specific use case you have in mind, or similar information), or even a concrete proposal if you have time for this.

nishiguchiH commented 3 months ago

Hi @zeitgeist

Thank you for your reply. Understood. I'm just concerned that other solution which doesn't implement iLEAP also have to consider carbon footprint value itself of our system responses because of Pathfinder Integration specification. For example, in spite of the property name of "CarbonFootprint" is same, one message means product level emissions literally, but other one means logistics level emissions.

On the other hand, according to OAS, not only shipment footprint but also TOC data are included on response body when calling "/2/footprints". is there any reasons why not separating path between shipment footprint and TOC? (like /2/ileap/toc for TOC data)

zeitgeist commented 3 months ago

Dear @nishiguchiH ,

Thank you for your comment.

For example, in spite of the property name of "CarbonFootprint" is same, one message means product level emissions literally, but other one means logistics level emissions.

We are working under the hypothesis that it will work in practice as dedicated identification schemes are used for TOCs, Shipment footprints, etc. The pilot testing later this year exists to also validate this hypothesis.

From your experience or perspective, do you expect our hypothesis to hold or to not hold?

is there any reasons why not separating path between shipment footprint and TOC? (like /2/ileap/toc for TOC data)

One reason for this approach is interoperability with (existing) PACT solutions and that there is convergence to a single protocol as much as possible. For my taste, at the level of semantics TOCs and ShipmentFootprints match quite well the fundamental ideas of the PACT Data Model and Protocol.

Would you prefer a dedicated endpoint (per HOC, TOC, etc.)?

zeitgeist commented 2 weeks ago

Closing this issue due to inactivity.