What is the biggest advantage of EPCIS 2.0? It's not what you think

The GS1 EPCIS traceability standard has been around for a while. First formalised in 2007, it focused on RFID interoperability and used the most popular integration architecture of the time: web services based on the SOAP/XML protocol.

In 2022, after 6 years of work, GS1 released a major update to the EPCIS standard in version 2.0. Billed as a modernisation designed to help businesses and developers adopt EPCIS more easily, the GS1 EPCIS homepage lists the following reasons to get excited about EPCIS 2.0:

  • 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

Much of the commentary about EPCIS 2.0 points to the move from XML web services to JSON APIs (the same technical method used by most data exchanges on the internet today) as the most important change. And this is certainly a good thing!

But it's the very last advantage listed - the ability to use Digital Links as identifiers - that I believe is the most powerful feature of the new version, and one that has gone somewhat unnoticed by the majority of commentators (except my friend and former colleague Dominique Guinard, who co-invented the Digital Link standard!).

When I first heard of the ability to express identifiers in EPCIS messages as either Digital Links or the traditional EPC Pure Identity URI, my first thought was a knee-jerk reaction about how difficult it is going to be to support participants submitting data using one or the other. As a developer of EPCIS systems, I wished they had just settled on one identifier standard.

But it was only on further reflection that I realized how wrong I was. The ability to use Digital Links in EPCIS 2.0 is arguably its most powerful feature. Let me explain why.

One of EPCIS’s biggest weaknesses is that its messages are full of identifiers which are hard to understand by humans without a join to further master data. Consider the following snippet from an EPCIS message:

What do the identifiers really mean? Where exactly is this location? Who owns it? What classes of product do these batches belong to?

While EPCIS has limited support for master data in header and ILMD elements, having to send master data with every set of messages “just in case” the recipient doesn’t have it adds bloat. GS1 themselves recommend other methods of master data exchange; such as the GDSN for product master data. But this adds friction and complexity and hinders adoption.

But imagine the same message with Digital Links:

A lesser known power of Digital Links is that you can query them with additional parameters, and, if supported by the owner of the Digital Link, get back specific information, in human or machine-readable formats. These additional parameters are called “linkTypes”, and there are many already defined by GS1.

Thanks to linkTypes, a receiving system that saw GTINs and GLNs for the first time could use that same Digital Link to dynamically request further machine readable master data, directly from the manufacturer, by using the linkType “gs1:masterData” as defined on the GS1 Link Type list

In the example above, the Digital Link query would look like this:

 https://brand.com/01/01100001100019/?linkType=gs1:masterData

A good choice for a modern interoperable format for the returned master data would be JSON-LD using the schema defined at the GS1 Web Vocabulary for Products.

You could do the same thing for Location Master data:

 https://brand.com/414/1100001100019/?linkType=gs1:masterData

Grab the returned geo-coordinates and now you can plot your shipments on a map, or calculate journey distances for carbon emission estimation.

And why stop there? If no certificationInfo elements were included in the EPCIS messages you’ve received from business partners, you could still check for product and location certifications by dynamically performing queries to those digital links using the gs1:certificationInfo linkType. The GS1 Web Vocabulary gives us a good candidate for describing key attributes of a certification in a machine readable way.

The two standards complement each other the other way around as well. Imagine you received a batch of product with a Digital Link, and you wanted to fetch machine readable traceability data for storage in your own traceability system, but you didn’t have any system integration with this supplier. Your system could perform a Digital Link query with linkType “gs1:traceability” to get this information back dynamically from the manufacturer. And the obvious format for the response is EPCIS 2.0, which is the best traceability data standard available today.

And what about recall? Imagine you had a system that needs to check all the Digital Link equipped product batches you receive for recall notices. You can query Digital Links using the linkType “gs1:recallStatus”, but you really need a machine readable response format for this to be automated. Again, the best choice for this response format is a list of EPCIS 2.0 recall events.

Here at TrackVision AI, we have developed a comprehensive approach for how EPCIS 2.0 and GS1 Digital Link can combine to deliver never before seen capabilities for certification monitoring, carbon emission estimation, multi-tier provenance verification, and recall monitoring, for tiny fractions of the IT costs traditionally required. We have a fully operational reference implementation ready for use today.

We will be creating a series of blog posts and videos describing how this works in more detail, but why wait? For more information, contact us at https://trackvision.ai/contact today.

Recommended for you
About the author
Jonathan Ling
With over 15 years experience in supply chain system integration, consulting and IT architecture, Jonathan is passionate about improving supply chain traceability and transparency through the application of open industry standards.