Current customs applications are declaration based to support the various customs procedures based on (inter)national laws and regulations. To be able to perform a proper supply chain risk analysis, customs requires to have all data in supply chains. The current declaration procedures are not sufficient since they do not supported retrieval of containers stuffing information resulting in the fact that authorities do not have a complete data set. It has been shown that enterprises already have a lot of data available to meet their customer requirements that can be made directly accessible to authorities, instead of 'pushing' data to the authorities based on procedures. By not only making this data available to customs but also to other authorities, they also comply with Single Window implementations. There are various solutions to data retrieval, e.g. a Service Oriented Architecture (SOA) offers a potential solution. The proposed approach in this paper is based on Linked Open Data (LOD) and implies innovative IT to be implemented by both authorities and enterprises in supply chains. The paper discusses LOD and its application to supply chain risk analysis. The proposed solution allows authorities to govern global supply chains in supply networks.
In a networked economy characterized by dynamic business relationships and of a
global nature [
Linked Open Data (LOD) for data and content capture from its original resources
is an innovative approach [
First of all, the objective of supply chain visibility for supply chain risk analysis and missing data is briefly presented and secondly the principles of Linked Open Data are presented. These principles are applied to supply chain visibility and finally conclusions and next steps are given. 2
This section briefly presents the need of supply chain visibility for supply chain risk analysis. Furthermore, it defines the challenges for authorities for completing supply chain data with current missing data. Different solutions are presented in this section, whereas the next sections present a solution based on LOD in more detail. 2.1
Various authorities like customs monitor value exchange crossing national or EU
borders from a fiscal, security and safety perspective [
By monitoring discrete events, not all required data may be present, e.g. the export,
exit, entry and import declarations do not contain packaging details of containers
implying that the complete content of the container is not always to customs. To
complete the information, the seamless integrated data pipeline is introduced
consisting of all traders with their data and business documents participating in a
supply chain (Fig. 1, [
authority authority post export assurance by customs invoice, order, etc. entry in records consignor or exporter
Freight forwarder or 3PL
GPS and satelite positioning country A carrier manifest port 1
port 2 GPS and satelite positioning handling fees insurance fees packing list contracts of car iage Let er of Credit shipping note carrier’s receipt House Way Bil vessel booking freight account
Freight forwarder or 3PL GPS and satelite positioning country B post clearance assurance by customs entry in records consignee or importer (Frank Heijman, David Hesketh, 2011)
The conceptual pipeline can be viewed from two perspectives, namely a process and a data perspective. The process perspective specifies relations between traders in supply chains, e.g. a stevedore with contractual obligations to a shipping line and a forwarder that arranges pre- or on-carriage to a port. These processes of cooperating traders can be described by transaction trees reflecting the business transactions between traders. The data perspective not only reflects the business transactions, but also the physical objects and their status. Fig. 2 shows the data perspective representing the physical objects. Each of the relations between two high level data concepts can be created physically by another supply chain actor, e.g. stuffing containers can be done by a groupage centre and a stevedore performs loading and discharging. The physical objects can be more detailed and more physical objects can be added. ‘Customs goods’ is a particular view on physical objects. They represent physical objects in terms of a customs classification used for instance for VAT purposes, the so-called harmonised goods code. The status of physical objects is represented by their availability in a place, e.g. at a stevedores location. This availability can be provided by RF tags and business transactions amongst traders. These business transactions refer to a business activity that specifies conditions under which transactions can be performed.
business activity place business transaction availability customs goods iemxppoorrtt/ product packaging cargo stuffing, stripping container load, discharge transport means entry/exit/transit/etc.
entry/exit/transit/etc.
load, discharge
In international container transport, authorities are not always aware of the ‘packaging’ and ‘stuffing/stripping’ relations. These are added by traders that are not obliged to perform a declaration. To retrieve this information, customs has several options that will be presented hereafter. 2.2
To complete the data perspective, customs basically has two options, namely
monitoring more discrete events with accompanying declarations or a continuous
monitoring of involved traders based on capturing their supply chain data (piggy
backing, see [
This section explains Linked Open Data (LOD) in the context of the semantic web. An architecture for the semantic web defines data resources and data capture mechanisms according to a known semantics. These two aspects of the semantic web are described in this section. 3.1
Data semantics is the basis of the semantic web. Open standards for the semantic web
are currently applied in many open data projects [
It is possible to distinguish various data resources. Sensors, enterprises, IT systems,
social media are some examples of data resources. Data resources provide data of
different natures, e.g. a sensor like an RF tag is a data resource with possibly
streaming data and data fusion of this sensor data results in a new data resource. In all
occasions, metadata has to be related to the data, specifying quality aspects of that
data. Open Archives Initiative – Protocol for Metadata Harvesting (OAI-PMH, [
(OWL)
resource
metadata
(OAI-PMH, DC)
resource
There are basically three ways to capture data from different resources [
resource data analysis, data querying
data data crawling (pipelines with different crawling functions and settings per (group of) resources) published data of resource based on open link data resource resource …..
Although crawling is able to capture data with different semantics, agreement on these semantics is required for analysis. Ontology can specify the structure of the data store. Possibly, data pipelines require transformation functionality for storing data in the data store according this ontology. For analysis purposes, additional metadata is required, e.g. the data resource, the way the data is captured by that resource, the time of data capture, and a reference to algorithms like SPSS (Statistical Package for the Social Sciences) used for data analysis and fusion performed by the resource. The metadata of the crawled resources also needs to be stored with the data. Data fusion can for instance be performed on (real time streaming) data of one or more sensors. The fused data has its particular metadata that has to be linked to the original resource data. Data fusion is not only applicable for real time data streams, but can be applied to all types of data. In such a way, aggregated and processed data is created. Crawling can thus be applied for analysis of large amounts of data and requires replication of that data.
The second way of data capture is the so-called on the fly dereferencing pattern implying that all data is captured by following links between resources. This pattern captures data from a resource chain based on links between those resources. Only that data is captured that is relevant for the resource chain. The data resources from which data is captured are not known in advance, but become apparent by following links. Supply chains can be seen as an example of resource chains.
The third pattern is called the query federation pattern. This latter pattern is based on sending complex queries directly to a predefined set of data sources. This pattern can be used for one time queries for which the data resources to be queried are known. 4
As we have indicated, Linked Open Data is the most commonly known application of the semantic web. This section constructs views a trader as a data resource and proposes a means for data capture to create supply chain visibility to customs. Firstly, a proposal for data capture is presented; secondly this section gives the conditions for implementing this proposal, and finally, advantages of the proposed solution are discussed. 4.1
The options crawling and on the fly dereferencing seem to be the most applicable implementation options for supply chain visibility. Whereas on the fly dereferencing dynamically constructs individual supply chains in a logistics value web, crawling captures data from all actors in a value web. On the fly dereferencing is based on links between traders. Business transactions (see before) can serve as links, but only business transaction related to particular physical objects like containers need to be evaluated to construct a supply chain. Constructing supply chains in this way may be time consuming and only that part of the supply chain is constructed for which the links can be followed at a given time. As many traders will act in more than one supply chain, on the fly dereferencing may not be the best option.
Thus, crawling seems to be a better option for data capture by customs. Crawling decouples data fusion and analysis functionality from data capture, allowing performing data analysis independent of data resource availability. It means that supply chain data of traders and links between those traders based on business transactions are captured independent of supply chain risk analysis. Each trader acts as a data resource in a value web by publishing available supply chain data (piggy backing). A link must have meta-data like a validity period to be able to distinguish between operational and historic transactions. The business transaction links can be used to reconstruct supply chains in the value web. Authorities can decide themselves how frequent they capture data this way; it can be every 5 minutes but also on a daily basis. Data capture also depends on the availability of data resources. Agreements have to be made in this respect between authorities and companies. Supply chain data can be enhanced for analysis purposes by retrieving additional data from external source, e.g. not only databases with know traders of authorities that can be trusted, but also data from social media defining relations between persons and thus companies. Social media data is not always trustworthy and needs to be handled as such.
risk analysis (reasoning engine, different per authority based on supply chain visibility) socimalendeiatw,ootrhkesrand structured data
data store external resource
crawling ((un)structured data,
pipelines) other resources supply chain data data fusion (supply chain view) actor based data store data capture (pipelines with different crawling functions and settings per (group of) traders) logistic value web supply chain visibility published data of enterprises, chain link data
Supply chain and business transaction data (Fig. 2) published by traders need to be refreshed based on agreed events, meaning that authorities still need to monitor progress of supply chains in accordance with laws and regulations. These events can be the ones that are already defined by current customs procedures, e.g. exit, entry, import, and (re-)export (see before). A trader acting as a data resource has to build in these controls for refreshing the data, but basically they will be available since traders do business with each other.
An authority has two options for risk analysis after data capture. The first option is
to store all data as received and analyse this data. It means that data is duplicated
based on crawling frequencies. It may lead to potential large data stores, depending on
the number of logistics movements that has to be captured. The second option is to
fuse the received data to actually reflect the structure of a supply chain, i.e. container
data is only stored once for one supply chain thus creating supply chain visibility
(Fig. 5). The latter situation can be constructed by following links between actors
based on transactions. The proposed solution shown in Fig. 5 can be optimized, e.g. to
capture only data that is refreshed by a trader or to capture only transaction data of
traders, construct supply chains in a network, and analyze vulnerability of these
chains based on additional data of traders. In case one of these sources is considered
to be a threat, additional data can be captured for further analysis. The latter approach
closely relates to what is called System Based Auditing [
semantics maintenance customs trader data analysis, data querying
data data capture
customs transaction links supply chain data resource identifier (URI/URL) data, content trader data pipeline
The supply chain data store offering supply chain visibility is a new data resource that can be accessed by other resources. Supply chain data is the basis for various other applications, e.g. economic figures, statistics, different risk analysis functions for each authority, etc. By further enhancing supply chain data with results of risk analysis, supply chain data of one (customs) authority can be used by another authority thus constituting a global network of interconnected authorities. Chain data crawling thus does not only mean capturing data of supply chain traders, but also data of authorities in other countries, possibly with the inclusion of the risk analysis results of that other authority. The latter requires a level of trust amongst authorities in different countries. Fig. 6 shows that a supply chain pipeline (Fig. 1) can thus be monitored by several authorities, each from its own perspective and with its particular responsibility. Global supply networks can thus be monitored by more that one authority. 4.2
As we have stated, semantics of open data is one of the main conditions for the
semantic web and thus for global supply risk analysis based on supply chain visibility
(Fig. 6). Semantics can be represented in different ways. In the semantic web, a data
resource can also contain semantics of other data resources. Such a reference is
feasible if one of the semantic web standards is used, for instance Web Ontology
Language (OWL). Currently, the World Customs Organization (WCO) has specified
semantics for declarations supported by messaging with a UML class diagram
covering all types of laws and regulations for global logistics [
The second aspect is the functionality supported by the WCO class diagram. It has been specified to support all data relevant for governing supply chains by authorities and constitutes not only customs specific data like harmonized goods code, but also container and vessel data. One of the basic questions is whether this data is sufficient to support all processes of actors in supply chains. It is most likely that a networked ontology for open data in supply chains needs to be constructed based on a representation of the WCO class diagram by an ontology. Furthermore, localizations are most probably required, e.g. a national authority may have additional data requirements. By constructing networked ontologies, localizations can easily be supported. 4.3
Implementing the proposed solution has many advantages for both traders and
authorities. Whilst the proposed way of data capturing is a complete decoupling
between traders and authorities with a minimal set of agreements, it will decrease the
administrative burden. Traders, being shippers and logistic service providers, publish
their supply chain data according to an agreed ontology including the transaction
links. By making their data available to authorities, they can adhere to requirements of
all laws and regulations, independent of the way they are implemented. There are lots
of authority initiatives to change the implementation for lessening the administrative
burden for traders [
Authorities on the other hand can optimize the physical inspection of supply chains, because all supply chains in a logistic value web are completely visible. Authorities do not have to introduce additional events that have to be monitored by new procedures supported with messaging, but have full visibility if all traders make their data available to those authorities. Each chain but also each individual trader can be analysed on its behaviour. In case traders have data available, packaging and stuffing data will also be available to authorities (Fig. 2). Supply chain visibility thus improves the detection of anomalies by also including external data resources in the analysis. Furthermore, each authority can have its specific risk analysis method; for the purpose of a seamless goods flow they need to align their inspection planning. The latter prevents that the same goods are inspected more than once by different authorities. The proposed supply chain risk analysis pattern requires a new approach to IT of those authorities. They need to capture data from all types of resources and use this data for analysis instead of keeping validating the completeness of a data administration. Information management will change. 5
This paper takes a semantic web view for supply chain visibility and proposes a solution for data capture in logistic value webs. Supply chain visibility will improve supply chain risk analysis and the proposed data capturing mechanism will decrease the administrative burden since it is based on already available supply chain data (piggy backing), whereas other solutions require the implementation of new procedures by traders and authorities that will increase the administrative burden. Semantics of supply chain data can be specified by an ontology that can be based on the WCO class diagram.
It is not required for authorities and traders to implement the proposed solution instead of current, existing declaration based solutions. These can still be used and are also a data resource for data capture to construct supply chain visibility. However, as indicated in section 2, the current declaration based systems do not offer complete supply chain visibility. Thus, additional software is provided offering visibility of those events that are currently not declared. Commercial supply chain visibility tools based on sensor (RF) data like EPCIS (Electronic Product Code Information Services) or SICIS (Shared Intermodal Container Information System, www.integritysupplychain.eu) could be used for these purposes. Not only adoption, technical and organizational aspects are of further study, but the solution also has to fit in current laws and regulations. Furthermore, the business case for both traders and authorities has to be made as part of the adoption. Security and privacy also have to be solved based on policies of traders and authorities.
This paper is the result of the Dutch Extended Single Window project funded by Dinalog and the cooperation between TNO and Capgemini for developing innovative approaches for supply chain visibility. These concepts are further developed and tested in EU FP7 Cassandra (www.cassandra-project.eu).