Digital Trade Document Relationships
ICC DSI’s recently published Key Trade Documents and Data Elements kicks off with this beautiful diagram:
The diagram displays the data elements, many of which are duplicated, that belong to seven major global trade documents. The red and green circles at the bottom denote the trade parties responsible for exchanging the documents.
From a modern technology perspective, the top row screams Linked Data. The bottom part maps equally well to Verifiable Credentials’ digital signatures issuance and downstream verification.
We will explore this further based on this sample implementation:
Actors
On the ICC DSI diagram, Packing Lists are exchanged from Seller/Exporter to Buyer/Importer. While true, this is not the full story; for example, Customs also require Packing List documentation.
The Verifiable Credentials data model maps perfectly to how trade documents are actually passed through multiple parties along the supply chain. Throughout the entirety of the supply chain, data can be verified, cryptographically tying back to the original issuer.
Relationships
The top row of ICC DSI’s diagram lists numerous relationships, which can be broadly categorized as Collections, Repetition, and Relationships.
Document Pouches
Documents are often presented to the same actor at once, in a “pouch.” A pouch of documents is expected to be related in customs and trade finance use cases.
Above, two credentials are joined by the same Workflow Instance, explicitly indicating relation across multiple Verifiable Presentations.
Inter-Document References
Documents typically carry identifiers and reference each other. For example, a Commercial Invoice typically references a Purchase Order, usually with a Purchase Order number, which is unique to the two organizations’ business relationship.
As you can see on figure 5, both the Packing List and the Bill of Lading references the same Unique Resource Identifier (the yellow node).
Note that the trade parties are also represented by the same green nodes, referenced from both documents. “Seller Inc.” is the Issuer, Seller and Ship From party on the Packing List, and the consignor on the Bill of Lading. This is because the documents reference URIs, in this case Decentralized Identifiers.
Repeating Elements
Non-identified values are usually just repeated on the documents where they are required. For example, a weight measurement is typically not identified (although it could be), so the values are repeated whenever required. For example, a shipment’s product Gross Weight is listed both the Packing List and the Commercial Invoice.
Also shown on figure 5, the goods weights and measurements are repeated on the Packing List and the Bill of Lading. Automating a consistency check to confirm that the documents represent the same shipment is trivial when the data comes with strong semantics in this way.
Conclusion
I wrote this article based on a quick implementation of ICC DSI’s model using prevalent, modern web technologies. This was quickly done using the open source for example these PL and BL schemas, and our Verifiable Data Platform for credentials management and constructing the corresponding data graphs.
The intention of this article has been to present a direction, from the ICC DSI model towards a scalable, interoperable implementation model.
Similarly, talking about Linked Data, Verifiable Credentials and Decentralized Identifiers in the abstract can be rather alienating. But as we have seen, they address some very tangible elements of global trade, beautifully introduced by the ICC DSI.
Nis Jespersen, Transmute’s Solutions Architect, is editor of the United Nations CEFACT JSON-LD Web Vocabulary project and author of the W3C Traceability Vocabulary specification.
Connect with Nis on LinkedIn, Twitter, & GitHub
Sign up for free on Transmute’s Verifiable Data Platform on https://platform.transmute.industries.
