Alignment Traceability Events needed

[GerhardHNL]

Find here the TT event types as adopted in the Buy-Ship-Pay model. This model contains the missing readLocation in the model on Github. Here the structure used for textiles.: https://service.unece.org/trade/uncefact/publication/Agriculture/TTTL-TraceabilityEventMessage/HTML/031.htm

But BSP is missing the sensor data support, although it has support for certification details. The reference of a transaction document can be found within trade transaction, but in the github model it is a referenced document. We should update the models and start with what UNECE/UNCEAFCT already published. Updating/alginment with latest BSP TT Events en GS1 TT Event is relvant. See here GS1 Traceability page (https://www.gs1.org/standards/epcis). The TT Events within BPS are used for Animal TT and Textiles TT, but exported in XML syntax, using UNCEFACT XML NDR. It could be exported to JSON syntax.

EPCIS / CBV 2.0 adds support for:

Sensor data for monitoring the condition of assets (e.g., in cold chains) and industrial IoT processes
Certification details pertaining to products, organisations and locations
Linked, browsable online definitions for all event data fields and classes, code lists and values
JSON / JSON-LD syntax which is developer-friendly
REST API for capture and query of event data, easing integration of EPCIS into evolving applications
GS1 Digital Link URI syntax to express GS1 identifiers within EPCIS event data

[onthebreeze]

The question here is whether to align with GS1 EPCIS or to align with the UN/CEFACT TT "version" of GS1 EPCIS. My view would be that there are many many implementations of GS1 EPCS and probably very few implementations of UN/CEFACT TT so we are being more friendly to the implementation community by aligning with GS1 EPCIS

[GerhardHNL]

Hi Steve, The alignment was about BSP model of UN/CEFACT with EPCIS latest version, in which association event, sensor element etc has been added. Whether or not GS1 EPCIS is being used as the foundation for UNTP Traceability Information is a decision within this project. BSP should still align. Best regards Gerhard From: Steven Capell ***@***.***> Sent: donderdag 2 mei 2024 09:55 To: uncefact/spec-untp ***@***.***> Cc: GerhardHNL ***@***.***>; Author ***@***.***> Subject: Re: [uncefact/spec-untp] Alignment Traceability Events needed (Issue #84) The question here is whether to align with GS1 EPCIS or to align with the UN/CEFACT TT "version" of GS1 EPCIS. My view would be that there are many many implementations of GS1 EPCS and probably very few implementations of UN/CEFACT TT so we are being more friendly to the implementation community by aligning with GS1 EPCIS — Reply to this email directly, view it on GitHub <#84 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK4JD4KNRGDZTXSGLGZIVGDZAHWMLAVCNFSM6AAAAABHCC55FSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZHAZTMNRUGQ> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AK4JD4M7JVVLXEHPKIT7WVDZAHWMLA5CNFSM6AAAAABHCC55FSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT4SBQGI.gif> Message ID: ***@***.*** ***@***.***> >

[philarcher]

Hoping that @mgh128 can offer some guidance on how easy/hard it is to use EPCIS within a VC.

[mgh128]

As correctly noted by @GerhardHNL ,
EPCIS / CBV 2.0 adds support for:

Sensor data for monitoring the condition of assets (e.g., in cold chains) and industrial IoT processes

Certification details pertaining to products, organisations and locations
(ideally by reference to online Linked Data making use of https://www.gs1.org/voc/CertificationDetails )

Linked, browsable online definitions for all event data fields and classes, code lists and values
( see https://ref.gs1.org/epcis and https://ref.gs1.org/cbv and within the GS1 Web Vocabulary at https://gs1.org/voc the following https://gs1.org/voc/MeasurementType , https://www.gs1.org/voc/SensorAlertType and https://www.gs1.org/voc/CertificationDetails . Machine-interpretable ontology files provided at https://ref.gs1.org/standards/epcis/epcis-ontology.jsonld and https://ref.gs1.org/standards/epcis/cbv-ontology.jsonld)

JSON / JSON-LD syntax which is developer-friendly
(examples at https://ref.gs1.org/docs/epcis/examples , normative artefacts at https://ref.gs1.org/standards/epcis/artefacts )

REST API for capture and query of event data, easing integration of EPCIS into evolving applications
(see https://ref.gs1.org/standards/epcis/openapi.json )

GS1 Digital Link URI syntax to express GS1 identifiers within EPCIS event data
(see https://ref.gs1.org/standards/#digital-link . Note that GS1 Digital Link URIs can more seamlessly link or redirect to various kinds of online information resources, services and even master data - a full set of 'link types' for use with GS1 Digital Link can be found at https://www.gs1.org/voc/?show=linktypes )

EPCIS provides an open standard for sharing visibility event data, conceptually thought of as having dimensions 'What?', 'Where?', 'When?', 'Why?' and now also 'How? / in what condition?' .

If you view a Verifiable Credential as digitally signed structured data (ideally Linked Data in JSON-LD), then of course an EPCIS event (or collection of somehow related EPCIS events) can certainly be valid data payload of a JSON Web Signature - and potentially included within the data payload of a Verifiable Credential.

What is less clear to me is which of the various dimensions of an EPCIS event are considered to be mapped to the 'Credential Subject' or even the 'Issuer'. EPCIS events may simply record an observation but more usually are used to express what happened at the completion of a specific business process step - and which things were involved, where and when it happened, what state or condition those things were in. Capture applications interface with sensors and automated identification and capture systems as well as business logic elsewhere to generate streams EPCIS event data, often automatically, so in that sense it's a very different scenario from when a Issuer deliberately issues a credential that asserts a number of claims about a Credential Subject. EPCIS uses a constraint-based query language, which you can think of as being somewhat analogous to SQL or SPARQL but deliberately more constrained, to prevent unmanageable queries. Further details about the EPCIS query language and its constraint parameters can be found in section 8.2.7.1 of https://ref.gs1.org/standards/epcis/ . This means that it's equally valid to query an EPCIS repository asking for details about which objects were present at a particular read point or business location within a particular time range - or to ask for event data about a specific object, possibly having no prior knowledge about the locations and times at which they might be reported in event data. There isn't a single well-defined "query direction" when querying EPCIS event data - there's considerable flexibility to ask various different kinds of query simply by choosing the query parameters appropriately to effectively filter the collection of event data on various parameters/dimensions of interest.

EPCIS event data isn't really designed from the perspective of "Issuer asserts Claims X, Y, Z about CredentialSubject".
It's simply an open standard for interoperable sharing and query of multi-dimensional (What, Where, When, Why, How) visibility event data, either for supply chain traceability (supporting query and exchange across organisations) or even for internal track and trace within an organisation.

EPCIS and its companion standard CBV are also recognised as ISO/IEC 19987:2024 and ISO/IEC 19988:2024 respectively.
GS1 provides a number of tools to support EPCIS, including https://freepcis.gs1.org/ui/home and https://ref.gs1.org/tools/epcis-sandbox/

It's also very important to understand that EPCIS is not simply an EDI message or document. Yes, there is an EPCISDocument data structure defined (for use in sending a set of EPCIS event data to a repository) and EPCISQueryDocument for returning the results of a query but these are merely transient ephemeral 'envelopes' or wrappers that can be discarded, while what is expected to be stored in EPCIS repositories are event data. EPCIS repositories are not repositories of EDI documents or messages.

However, we have given some thought to how data derived from EPCIS events could work with Verifiable Credentials and Decentralised Identifiers to support checking of end-to-end traceability, without revealing commercially sensitive business intelligence. This draft white paper may be of some interest:
https://gs1.github.io/EndToEndTraceability/GS1-WhitePaper-VerifiableCredentials-EPCIS-end-to-end-traceability.pdf

I'd strongly encourage alignment with the current (v2.0) version of EPCIS and CBV to obtain the maximum benefits and interoperability with an open standard that is already in use by industry.

Also tagging my colleague @CraigRe (Craig Alan Repec) in case he has further details to add, as the coordinating editor of EPCIS and CBV. If you have specific questions about the JSON/JSON-LD syntax for EPCIS, GS1 Digital Link URIs or the white paper above, I can probably help.

[onthebreeze]

I wasnt aware that GS1 had such a lot of good content at ref.gs1.org including the full epcis ontology. This is good news.

What we want at UNTP is a simple and easily implementable subset of EPCIS (mostly transformation events that can bridge from finished products to constituent materials. We tried that with https://uncefact.github.io/spec-untp/docs/specification/DigitalTraceabilityEvents which is "recognisable" as a simple subset of EPCIS. But the trouble is it's not actually strictly that - it's a copy & tweak.

What I suggest as a way forward here is that we can make a model that suits our needs but make sure that the JSON-LD context file references the vocabulary at https://ref.gs1.org/standards/epcis/epcis-ontology.jsonld.

This way we give issuers of UNTP credentials a simple schema that works for them but we make sure that consumers / verifiers can ingest JSON-LD data that expands using a @context file to exactly match the semantics of any EPCIS event source.

Although I wonder how we'd reconcile the W3C VCDM "id" with the EPCIS "eventId" - but thats a minor hurdle.

Thoughts?

[Fak3]

Although I wonder how we'd reconcile the W3C VCDM "id" with the EPCIS "eventId" - but thats a minor hurdle.

In epcis context, eventID is an alias to @id so we can use either id or @id or eventID - the resulting graph will be the same.

[mgh128]

That's correct - and you might also notice that we have made use of scoped contexts where appropriate.

[onthebreeze]

Right - so I think there's a bit of consensus building to do here in terms of mapping UNTP Digital Traceability Events to EPCIS.

• @GerhardHNL suggest to map to the UN/CEFACT version of the traceability structures - which will shortly be updated at https://vocabulary.uncefact.org/about (needs to be updated for library D23B). In that case there will be no direct mapping to GS1 EPCIS standard. It will look very similar to humans but will be totally different for machines.
• @mgh128 and @Fak3 point out that there are existing EPCIS artefacts that we can just use - including both JSON-LD ontology (https://ref.gs1.org/standards/epcis/epcis-ontology.jsonld) and JSON-LD context file (https://ref.gs1.org/standards/epcis/epcis-context.jsonld). The only issue is that these were not designed for VC usage and so may have terms that collide with VCDM and may need to reflect things like VCDM "issuer" might need to substitute for epcis:sender. Whilst the @context file question may be manageable, there are likely to be more problems with EPCIS schema files - which will be designed for API messaging and not for VC embedding.
• other options would be to create our own schema but to embed the existing EPCIS JSON-LD @context reference. This would permit us to define a VC compatible and simplified credential structure but just re-use the existing context file (assuming there arent any breaking VCDM conflicts).
• A final option would be to develop our own Schema and context file - but still reference the same EPCIS published ontology. Which would presumably still yield an EPCIS compatible graph.

My personal view (which will need discussion at UN/CEFACT bureau) is that UNTP (or UN/CEFACT more generally) should not re-invent stuff that already exists, particularly if it already has some significant industry traction - which I believe is the case for EPCIS. If that is the consensus of this group and is supported by UN/CEFACT bureau then this discussion boils down to the following

1. the reference vocabulary for traceability events will be GS1 EPCIS ontology.
2. the context files would be vcdm and gs1 published epcis context - so long as these two don't clash.
3. the schema would be a UNTP DTE schema that is optimised for our VC implementation model but which references the epcis context

Does that make sense?