Problems re EPCIS TraceabilityEvents

[VladimirAlexiev]

• Is https://uncefact.github.io/spec-untp/docs/specification/DigitalProductPassport#traceabilityevent conformant to https://uncefact.github.io/spec-untp/docs/specification/TraceabilityEvents ?
• https://uncefact.github.io/spec-untp/docs/specification/TraceabilityEvents links to the EPCIS home page where one can download a 200p PDF.
  • Also link to https://ref.gs1.org/epcis/ where one can browse and search classes, props and code lists
• https://uncefact.github.io/spec-untp/docs/specification/DigitalProductPassport#eventtypecode (can be edited in https://jargon.sh/user/unece/DigitalProductPassport/v/working/editor#) has brief event descriptions, eg aggregation: "event describing the grouping of products such as placing bales of cotton on a pallet" Shouldn't you use official descriptions as per eg https://ref.gs1.org/epcis/AggregationEvent? As a minimum, the same eventType describes aggregation and disaggregation

@nissimsan Should the rest be here in UNTP, or in the Traceability project?

• https://jargon.sh/user/unece/traceabilityEvents is an attempt to remodel https://ref.gs1.org/epcis. EPCIS indeed it can take plenty of refactoring since it carries a heavy backward-compatibility baggage. (I was deeply involved in the semantic efforts of EPCIS 2.0, so can provide some feedback)

Eg comparing https://jargon.sh/user/unece/traceabilityEvents/v/working/artefacts/readme/render#transactionevent to https://ref.gs1.org/epcis/TransactionEvent

• sourceParty, destinationParty are imprecise:
  • should be multiple
  • can be Party or Location (i.e. Organization or Place), see https://ref.gs1.org/epcis/SourceOrDestination
  • has a role from https://ref.gs1.org/cbv/SDT
  • applies to all events
• eventTime, readPoint are missing but these are the fundamental dimensions WHEN and WHERE
• etc etc etc

[onthebreeze]

Hi @VladimirAlexiev - thanks for your comments. Yes, traceability events needs some work. just as you posted this ticket I also raised a PR #70 . it probably doesn't answer everything but should get us closer. The intent here is to define a much smaller / tighter profile of EPCIS that is just sufficient for our needs. It's a pretty bog spec and if we dont constrain it then we've no chance of interoperable implementations. We also have to make some minor adjustments for the fact the EPCIS was written with API exchange in mind and not publish / discover events as VCs. Anyhow, I'd suggest that we re-baseline via PR #70 and then see what's wrong or missing.

[VladimirAlexiev]

@onthebreeze @nissimsan I understand and support the desire to simplify. But there should be no gratuitous differences because when you get a bunch of EPCIS events, how would you convert them to dpp:Traceability events? Here are some gratuitous differences:

• [ ] eventID (event URLs) are a specific ni: URI with hash in EPCIS, but "UUID" in DPP.
• [ ] bizLocation is present, but readPoint is missing
• [ ] parentID in EPCIS can be gs1:IndividualObject or gs1:Place but is parentEPC and only object in DPP

In the PR I suggested to use real examples from https://github.com/gs/EPCIS rather than fake values like 0, "string" etc. If you use these "real-world" examples and cut them to size, that will reduce the number of gratuitous differences

[GerhardHNL]

Within the UNCEFACT Library, the so-called "TT" components based on EPCIS are adopted. These components were used for Animal and Textile products Traceability. These event components have been published on github, see here https://vocabulary.uncefact.org/search?q=event (events for transformation, object, transaction, aggregation). As far as I know the mentioned missing elements are in. I suppose the Traceability Event information is just a place holder of the other event types. I would be great if the events will be aligned.

[VladimirAlexiev]

@GerhardHNL I've looked at these events, and they are indeed closer to EPCIS events.

[onthebreeze]

Traceability Events have been updated to align very closely with EPCIS, avoiding gratuitous differences. It is a deliberately simplified version of the full EPCIS specification. I hope that it is good enough for upcoming pilots. We cant use EPCIS exactly as it is because of the collision with VCDM terms and, more generally the implementation as VCs rather than REST APIs.

However I think it would be friendly to implementers if UNTP DTE is a fully conformant semantic subset of EPCIS rather than a "very similar looking" copy. One way to achieve that would be to create a DTE @context file where every element maps to the corresponding GS1 vocab https://ref.gs1.org/epcis/. Perhaps we could close this ticket and make a new one to create such a context file prior to UNTP v 1.0.0 production release?