Open GerhardHNL opened 6 months ago
onthebreeze
commented
6 months ago 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
commented
6 months ago 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 https://github.com/uncefact/spec-untp/issues/84#issuecomment-2089836644 , 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
commented
6 months ago Hoping that @mgh128 can offer some guidance on how easy/hard it is to use EPCIS within a VC.
mgh128
commented
6 months ago 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
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago That's correct - and you might also notice that we have made use of scoped contexts where appropriate.
onthebreeze
commented
2 months ago Right - so I think there's a bit of consensus building to do here in terms of mapping UNTP Digital Traceability Events to EPCIS.
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
Does that make sense?
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