Focuses on standardizing data and processes for containerized maritime transport, including Track & Trace and documentation flows.
Over time, different sectors have developed their own operational “languages” to describe and manage their activities. This fragmentation is evidenced by the multitude of global and local data standards across logistics, trade, and transport. The BDI explicitly recognizes this landscape and emphasizes that participants should:
Align with sector-relevant standards where possible, rather than duplicating efforts or creating isolated models. Examples of well known and governed standards are (non exhaustive):
Organize for supply chain-wide semantic interoperability. In many logistics environments, not all actors operate under the same modality or domain-specific framework. Therefore, the Semantic KIT recommends adding the as a minimal, cross-modal structure. This enables end-to-end visibility of goods movement from the perspective of the Beneficial Cargo Owner (BCO), serving as a neutral format for semantic consistency across the supply chain.
It is strongly recommended to conduct research into existing standards, as the tools or practices you currently employ are likely derived from one.
There are a couple of relevant considerations to take into account for the selection of a data standard. For the evaluation of suitable existing data models, please consider the following.
Market participants might ask themselves the question:
"If I invest in particular standard semantics, how many partners can I work with using this standard?"
To avoid using an unknown or rarely-used standard, it is recommended to determine if there is an actively maintained data model governed by a Standards Development Organization (SDO). In addition, one should assess how well the model aligns with the use case(s), and understand the model’s governance structure and licensing terms.
Indicates the extend to which the standard can be deployed in an automated way, as well as its ability to support anticipated future developments.
Given that the BDI is a logistics, event-driven architecture, consider selecting a standard that supports events as well.
Identify which part of the standard is relevant for the use case. Often, only a subset is required, making adoption more lightweight. If the standard offers well-defined extensibility mechanisms, use them to incorporate case-specific data while maintaining compliance. If critical elements are missing, engage with the SDO to evolve the model, thereby improving the standard for the broader community.
Consider how the data model supports or integrates with BDI’s Identity, Authentication, and Authorization (IAA) protocol. Most standards are silent on identity and trust, which allows BDI’s Trust KIT to be applied alongside.
When no suitable standard exists, it is recommended to use LEO: a generic cross-modal structure that can be extended for specific use cases serving as a neutral format for semantic consistency across the supply chain.
Focuses on standardizing data and processes for containerized maritime transport, including Track & Trace and documentation flows.
Develops standards for the global air cargo industry, covering electronic messaging, air waybills, and cargo operations.
Provides a modular data model for planning, execution, and tracking of multimodal transport and logistics movements, mainly in the European inland context.
Defines technical specifications for interoperability in rail transport, including infrastructure, rolling stock, and data exchange for railway operations.
When interacting parties do not share an existing semantics standard, the use of LEO is required. Note, however, that it is possible for BDI parties to use any other framework.
For example, consider a multi-model trip from a manufacturer to the BCO that partly travels over sea. The parties involved in the sea trip may, in interactions with one another, make use of the DCSA standard. This is a well-known standard that has been in use for a long time. For the communication with other stakeholders, however, DCSA may not be the best standard, as these parties are not familiar with it or are not currently using it. Therefore, LEO may be required for the interactions with these stakeholders.
The DCSA () maintains a set of standards for data exchange between stakeholders in the maritime world. These standards are widely adopted and can be considered for support in data exchange within BDI implementations. However, when using these standards, one must consider whether the BDI principles — e.g. security, zero trust, data sovereignty and data at the source — can still be maintained, as very few of these are required by the DCSA standards.
Other frameworks
The DCSA described above is only one example of an an alternative semantic framework that can be used in the context of the BDI. Other frameworks, such as the IATA standard used for air freight, will be added later when necessary.
There is a growing demand from Beneficial Cargo Owners (BCO) to create more visibility in the supply chain: visibility of the operational planning and execution of all the steps between ordering goods and receiving the consignments in the distribution center or warehouse of the BCO.
Each transport leg in the consignment journey results in one or more events which are to be communicated between parties directly involved in the transport leg. The event communication leads to data exchanges, typically using specific systems, platforms and data formats. The diversity of parties, systems and data formats are a barrier to automated exchanges.
In summary, there exists a wide variety of data formats and semantic definitions in supply chains. This leads to the issue depicted in the following figure:
It is unfeasible for BCOs wanting to track & trace their goods to adopt all the data standards in the field. Meanwhile, logistics partners do not wish to switch to different data standards if they already have a standard in use. A global unification of data standards is not a practical option for the near future.
The Logistics Event Ontology (LEO) was developed to resolve this issue. LEO functions as an envelope around the existing standards, thereby allowing for domain-specific standards next to a shared format.
The purpose of this building block is to describe the creation and usage of a light-weight common BDI format, called LEO (Logistics Event Ontology). The purpose of this format is to bridge the existing standards in the realm of logistics data sharing, like , , , , , , and many others. It is not the intention to fully map all details of all standards onto a single model. Instead, the LEO-format distils the minimal data needed to follow goods through the supply chain based on the perspective of the BCO.
The BDI framework separates the envelope from the payload, thereby separating event data from other operational data. The BDI envelope is a notification of an event with additional data and metadata, combined with a link to the endpoint of the data owner where more (sensitive) data about the event may be requested. The data owner evaluates the request and provides data to the requesting party on a 'need-to-know' basis.
The Logistics Event Ontology (LEO) is derived from existing standards, especially the standard. This standard, however, does not allow for the modelling of events in the future. — an open-sourced fully compliant implementation of the EPCIS standard — resolves this issue by allowing for extensions on the existing model. LEO uses this standard and combines it with the modelling of future events.
LEO supports the use of standard operational trip data by operators (such as carriers) to generate notifications of events to cargo owners or authorities, leading to efficiency and productivity increases.
This building block is closely linked with the . The LEO format is mostly geared towards:
The description of events
The minimal data needed to communicate between modalities and existing standards.
IT defines templates for frequently-used common logistic events and their linkage to domain standards.
The main, if not the only, purpose of the BDI is to facilitate the exchange of data between parties in a logistic chain. However, this is only possible if all involved parties share the same interpretation of the data. This requires a common format and structure (syntax) of the data as well as a common semantics.
Over time, many transport modalities have developed their own ‘language’ to communicate about their activities. This is illustrated by the number of semantics standards. It is expected that data spaces should align with sectors and their standards, creating the need for tools for organizations that participate in multiple data spaces to switch between standards.
The semantics KIT provides a common semantics framework called LEO as well as means to include a variety of existing standards, such as DCSA (for container transport), IATA (air transport) and ERA (rail transport).
Many of the known semantic standards currently in use in logistics are based on monomodal transport. However, modern supply chains are inherently multimodal, requiring the involved parties to exchange data with other parties that are not necessarily in their own modality. This limits the use of modality specific semantic models.
This KIT requires the Trust and Event KITs. This building block is closely linked with the Event Publish-Subscribe Service. The LEO format is mostly geared towards the description of events and the minimal data needed to communicate between modalities and existing standards. It defines templates for often used common logistic events and their linkage to domain standards.
3. Shipment: The business transactions along the supply chain. Like bill of lading, airway bill, customs documents, clearances, certificates, etc.
The LEO format is primarily focused on the first two physical perspectives and builds on the semantic work done in de FEDeRATED projects.