Introduction

This document provides the technical documentation to apply the FEDeRATED ontology for the logistics domain. We first cover the design choices, initial framework, and the resulting modularisation of the model into various modules. In detail we describe the Event module which is the main concept of the ontology. We also describe some tested mapping procedures with RML-variants and data validation schemes with SHACL.

 

 

Figure 1 Flower model

 

 

Figure 2 Initial version of the semantic model

 

Scope and Application Area

The ontology is intended as an upper ontology for the logistics domain. This means that it should provide an interface to all relevant concepts, but it is not intended to cover details of the domain. The ontology is explicitly intended to be extended by domain ontology from the various logistics modalities such as the railways, airways, waterways, and roads. In other words, the main function of upper-level ontology is to support broad inter-operability among many domain-specific ontologies by providing a common starting point for the formulation of definitions.

 

Modularisation

In line with the requirements given by Flower Model (figure 1) and the initial graphical model (figure 2) we categorized the relevant information in modules. The result of this partitioning is an ontology network that consists of seven interconnected ontologies (figure 3).

 

We maintain the centrality of the Event concept: each event contains associations to the digital twins, locations, and/or business services involved. These three concepts therefore are collected in dedicated modules containing the concepts regarding the physical object, infrastructural and geographical locations, and business concepts, respectively. The main modularisation also includes a Classifications module which collects all references to existing codelists and standards.

 

 

Figure 3 Architecture of the main modules

 

Main modules

The proposed ontology architecture consists of domain ontologies, enumerations, and annotation/system ontologies. We describe each module in more detail.

Domain Ontologies

1. Business Service

The Business service ontology describes anything that is related to services that are provided to a customer by a logistics or transport service provider. It contains information on various types of services such as transport or storage services. But it also describes business transactions such as bookings and orders. Other information such as information on routes, shipments and logistics actors that are involved in the business services can also be found in this ontology.

2. Digital Twin

The Digital Twin module contains concepts for all of the physical objects of the logistics domain. As such it contains taxonomies for transport means, equipment, goods, and products. It additionally contains datatype and object properties to describe attributes of each physical object.

 

3. Event

 

The Event module has a central functionality in the ontology. Each concept contains several mandatory attributes:

- An atomic event has two relations to the concepts involved in the event. This is a combination of Digital Twins, Physical Infrastructure and Business Services. For example, an arrival event contains associations to a transport means and to a infrastructural location; an load or discharge event contains an association to a transport means and to an equipment.

- An Event has two timestamps indicating when the event was generated and when the event takes or took place.

- A milestone, which can be either Start or End.

- A datetime type, which can be actual, planned, required, or estimated.

4. Physical Infrastructure

The physical infrastructure ontology contains information on infrastructural and logistical functions that are used in logistics events. Logistical functions depict locations at which logistical activities can be performed. These locations are connected by trajectory, also described in the ontology.

5. Classification

The ontology contains functionalities to include external standards, taxonomies, controlled vocabularies, and code lists. These provide additional information of digital twins, business services, physical infrastructures, and other concepts in the ontology.  An example is the UNECE code list for Hazardous Material (Hazmat). The collection of codelists triplified in the Classifications module will extend over time.

 

Additional modules

6. Logistics Roles

 

The logistics role ontology describes the different types of roles logistics actors and locations can have as part of an event. The physical actors and locations are fixed objects and described in separate ontologies. The roles of these actors and locations can differ depending on the event they are involved in. Logistic actors can have commercial, financial or logistic roles. Locations can act as for example a place of loading or a place of arrival depending on the context.

 

7. Reusable Tags

 

In the Reusable Tags module we modelled concepts that can be reused for annotation purposes. Reusable tag is an annotation ontology that enables us to create and assign customer tags for giving more context on entities in domain ontologies. For example, we can distinguish derived features by using an is_derived annotation property.

 

External Modules

The FEDeRATED ontology network is specifically designed with the intention of reusing ontologies describing relevant domains. The ontologies reused can be relevant to the Logistics domain or can be domain independent. We are considering to extend or align the FEDeRATED ontology with the following established ontologies.

 

Logistics domain

1. ERA Ontology: railway ontology designed by the European Railway Association containing more detailed concepts of the rail modality. We have developed an alignment that relates general FEDeRATED concepts to the railway specific concepts of the ERA ontology.

2. OneRecord:

Domain-independent

1. Geonames: the Geonames ontology contains a model and data about almost any geographical location including infrastructure like ports, bridges, train stations. We are considering reuse based on the license & costs of reusing Geonames and based on the required level of detail of the Physical Infrastructure module.

2. Geographical Information: the Geographical Information ontology is light weight in comparison to the Geonames ontology as it only contains properties for latitude and longitude.

3. Ontology of Measurement: the Ontology of Measurement (OM) provides functionality to describe a measurement in much larger detail (e.g., square meters, volume, etc) than possible when just using literals or strings, while retaining interoperability.

4. Time Ontology[BC(1] : we consider reuse of the time ontology when it is required to reason about datetime intervals and such. This ontology contains concepts for time durations, intervals, etcetera.

 

Event structure

An Event contains exactly two associations with instances of Digital Twin, Physical Infrastructure, and Business Service via the event:involvesDigitalTwin, event:involvesPhysicalInfrastructure, or event:involvesBusinessService object properties, respectively. An Event additionally has a attributes for the milestone (Start or End) and the datetime type (actual, etc). The combination of associations and attributes characterizes the event.

 

We give some examples that have already been implemented for the core Events commonly used. The exhaustive list can be found in the ontology file. Additional custom Events can be defined by specifying two associations, the datetime type, and the milestone.

 

Example ATA Event

 

Figure 6 Example ATA event

 

Example merge/split Event

 

Atomic event types

Next to the events described above, the ontology defines the following atomic events. Constraints are defined for these in SHACL shapes, which can be reused and amended by partners. The following table lists the predefined events  based on the two associations it has. The upper-right half is blacked out, because there is no ordering among the two associations. Blank cells can be filled in based on user events.

 

		Transport Means	Equipment	Goods/Products	Package	Location	Legal Person
Transport Means
Equipment		Equipment{Load|Discharge}
Goods/Products		Goods{Discharge|Load}	Strip|Stuff	Merge|split
Package
Location	Ms=Start	ArrivalEvent
	MS=End	DepartureEvent
Legal Person

 

Complex event types

Next to the atomic events, we also define complex events that contain associations to other events. For example, in the following figure a Call event is described. This consists of four other events: Arrival, an optional set of Load and Discharge events, and a Departure Event. The complex Event functionality allows users to structure their own complex events following the SHACL/SPARQL tool. The SPARQL query can extract the complex events from a set of atomic events. The SHACL constraint can validate whether the events follow the structure prescribed by the flow diagram.

 

 

 [BC(1]Subject to change, just an example.