Verifying the Integrity of Information along a Supply Chain using Linked Data and Smart Contracts (Supplementary Material)

Accompanying a submission to Posters & Demos at Semantics 2019.

tl;dr

Here, you find our submission to Semantics 2019 Posters and Demos, a walk-through for our demo with screencasts, and the ontology.

Abstract

The paper

Please find the demo submission here. The paper is accompanying an accepted paper at Semantics 2019. For a preprint, see here.

Application Showcase

We extend the motivating example from our paper. We present a walk-through of this three step example of a simple supply chain:

Item Creation:

A fisherman creates an item, i.e. some fish.

Item Handover:

The fish is handed over between supply chain partners, e.g. from the fisherman to a trucker to a local supermarket to the consumer.

Item Verification:

At the store, the consumer verifies information about the fish as a decision-making support for the purchase. Verification could also be performed during each handover.

We first introduce the concept of a Linked Pedigree as a modelling basis. Next we describe the architectural setup of our demonstration. Subsequently, we present a walk-through of our example.

Linked Pedigree

A Linked Pedigree is a trail of ownership of a specific supply chain item. It is build in form of RDF graphs made available via HTTP and described using terms from the ontology OntoPedigree. The top part of Figure 1 illustrates the structure of a Linked Pedigree: Each Linked Pedigree consists of different parts, i.e. RDF graphs, created by the involved supply chain participants. In our case, there are three Linked Pedigree parts, namely the fisher's, the trucker's and the supermarket's. Each Linked Pedigree part references the preceeding part by its HTTP URI up to the initial part. Thus, a Linked Pedigree can be retrieved by traversing backwards on and dereferencing the previous part URIs.

Architecture for the Demo

In our application showcase, we use the architecture depicted in Figure 2. Each of the three businesses, i.e. the fisher, the trucker and the supermarket, has the same setup in terms of software: A Linked Data server, e.g. a LDP implementation, an Ethereum blockchain node, and the LD-chain client developed by us. The Ethereum blockchain node acts as a participant in the distributed ledger to perform data storage and computation. The LD-chain client provides a command-line interface. The end-consumer only requires an instance of the LD-chain client connected to any Ethereum node in the private network and with access to the network's Linked Data.

Walk-through for the Demo

The showcase depicts how transparent and verifiable information is generated and exchanged during the life cycle of a supply chain item. During the first two steps, i.e. item creation and item handover, the item's physical history is described and published as Linked Data. In the third step, i.e. item verification, we only cover the verification of the such published data.
The overall protocol is depicted in Figure 3. The top left group starting with create item in bold relates to the item creation. The next group starting with transport item relates to the handover. With store item, the step for verifying the data starts, ending in the actual purchase.

Item Creation: The Fisher initialises the Linked Pedigree.

A visitor, taking the role of the fisherman, creates a supply chain item by catching a fish. Information on the item and the catching process, e.g. fishing ground and time, is recorded in form of an RDF graph and published via HTTP. Thus, the initial part of the Linked Pedigree on the fish is formed. An simple example can be found here.

Item Handover: The Fisher stores an RDF graph hash.

The fisher meets up with the trucker to hand over the item. Information on the imminent item handover is included in the initial Linked Pedigree part.
Still in the role of the fisher, the visitor uses the LD-chain client to store the hash of the updated Linked Pedigree part via the Smart Contract. For that, he/she enters the URI whose content to hash. In addition, the visitor needs to specify the next owner's Ethereum wallet address. As a result, a transaction for storing the hash and transferring the digital ownership to the trucker is issued to the Ethereum node. The transaction is pending until a miner successfully mines a block that includes this transaction.
During the process, console logs are displayed about what is happening. The RDF content of the dereferenced URI can be viewed, hashing logs indicate the generated hash value, and query logs show if the submitted Linked Pedigree part is to be appended to an existing one or registered as a new initial one. When the transaction is mined, the gas used for the transaction as well as the action performed, i.e. registering or appending, is displayed to the visitor.

Item Handover: The Trucker approves the RDF graph hash.

Now, the visitor takes the role of the trucker. Before accepting the item, the visitor has to review the content of the proposed Linked Pedigree part, especially information on the imminent handover. If everything is fine, the visitor uses the LD-chain client to approve the hash of the Linked Pedigree part. For that, he/she enters the URI to approve, i.e. the URI of the fisherman's part. A transaction to approve the specified URI is issued. After successful mining, the gas used is displayed.
Again, console logs are displayed to the visitor during the process about content, hash and verification of the input URI. When the transaction is mined, the visitor in the role of the trucker accepts to receive the physical item from the fisher.
Now the visitor can create the next Linked Pedigree part that references the initial part, i.e. the fisher's, by its URI. An simple example can be found here.

Item Handover: The Trucker stores an RDF graph hash.

Continuing the iterative example, the visitor will store the new part's hash and propose the item to his/her next role, i.e. the supermarket. The trucker transports the item to the supermarket. Information on the transportation and on the imminent item handover is included in the trucker's Linked Pedigree part.
Still in the role of the trucker, the visitor uses the LD-chain client to store the hash of the Linked Pedigree part via the Smart Contract. For that, he/she enters the URI whose content to hash. In addition, the visitor again needs to specify the next owner's Ethereum wallet address, in this case, the supermarket's. As a result, a transaction for storing the hash and transferring the digital ownership to the supermarket is issued to the Ethereum node. The transaction is pending until a miner successfully mines a block that includes this transaction.
During the process, console logs are displayed about what is happening. The RDF content of the dereferenced URI can be viewed, hashing logs indicate the generated hash value, and query logs show if the submitted Linked Pedigree part is to be appended to an existing one or registered as a new initial one. When the transaction is mined, the gas used for the transaction as well as the action performed, i.e. registering or appending, is displayed to the visitor.

Item Handover: The Trucker approves the RDF graph hash.

Now, the visitor takes the role of the supermarket. Before accepting the item, the visitor has to review the content of the proposed Linked Pedigree part, especially information on the imminent handover. If everything is fine, the visitor uses the LD-chain client to approve the hash of the Linked Pedigree part. For that, he/she enters the URI to approve, i.e. the URI of the truckers's part. A transaction to approve the specified URI is issued. After successful mining, the gas used is displayed. Again, console logs are displayed to the visitor during the process about content, hash and verification of the input URI. When the transaction is mined, the visitor in the role of the supermarket accepts to receive the physical item from the trucker.
Now the visitor can create the next Linked Pedigree part that references the previous intermediate part, i.e. the truckers's, by its URI. An simple example can be found here.

Item Verification: The End-consumer checks the Linked Pedigree.

Taking the familiar role of the end-consumer, the visitor wants to ascertain if the fish's information has not (maliciously) been tampered with, e.g. a retrospective adjustment to the cooling information was made. To this end, the visitor uses the LD-chain client to verify the integrity of the fish's Linked Pedigree. For that, he/she enters the URI of the last known Linked Pedigree part that is provided by the supermarket. A table shows verification information of each URI dereferenced during the backwards traversal of the Linked Pedigree. This way, the customer can check the information trail on the fish until the beginning, i.e. the catchment.
Again, console logs about the verification of iteratively dereferenced URIs are displayed. Each single Linked Pedigree part contains a reference to its previous part. Traversing backwards this chain of links, the LD-chain client calculates the corresponding hashes on the fly and checks them against the hashes retrieved via the Smart Contract. This verification can be performed analogously at any point in the supply chain by any participant, starting at different points in the traversal.

The ontology

The terms we used in our modelling are depicted in Figure 4. We use an UML class diagram to illustrate modelling in RDFS using the following correspondence: UML’s class, association, and inheritance map to rdfs:Class, rdfs:domain and rdfs:range of an rdf:Property, and rdfs:subClassOf relationships respectively. For more details, see our paper.

Authors

• Christoph Braun, Institute AIFB, Karlsruhe Institute of Technology (KIT), Germany
• Tobias Käfer, Institute AIFB, Karlsruhe Institute of Technology (KIT), Germany