Nowadays, innovative digital services are massively spreading both in the public and private sectors. In this work we focus on the digital data regarding the mobility of persons and goods, which are experiencing exponential growth thanks to the significant difusion of telecommunication infrastructures and inexpensive GPS-equipped devices. The volume, velocity, and heterogeneity of mobility data call for advanced and eficient services to collect and integrate various data sources from diferent data producers. The MobiDataLab H2020 project aims to deal with these challenges by introducing an eficient and highly interoperable digital framework for mobility data sharing. In particular, the project aims to propose to the mobility stakeholders (i.e., transport organising authorities, operators, industry, governments, and innovators) reproducible methodologies and sustainable tools that can foster the development of a data-sharing culture in Europe and beyond. This paper introduces the key concepts driving the design and definition of a cloud-based data-sharing federation we call the Transport Cloud platform, which represents one of the main pillars of the MobiDataLab project. Such platform aims to ensure transnational access to mobility data in a secure, eficient, and seamless way, and to ensure that FAIR principles (i.e., mobility data should be findable , accessible, interoperable, and reusable) are enforced.
Over the recent years the European Union devoted many resources and eforts to promoting
data-sharing initiatives, platforms, and policies across its member states. Indeed, in the A
European Strategy for Data vision1 the European commission recognizes how exploiting data
allows the private sector to continuously innovate and create new types of thriving businesses.
At the same time, public entities and institutions can leverage public data to better understand
societal dynamics and make informed decisions. The data sharing vision driving the policies
of the European Union is that of a “[...] single European data space as a market for data, open
to data from across the world, where personal as well as non-personal data, including sensitive
business data, are secure and businesses also have easy access to an almost infinite amount of
high-quality industrial data, boosting growth and creating value, while minimising the human
carbon and environmental footprint”2. Accordingly, several European projects and initiatives
have been heavily financed in the recent past – just to name a few, GAIA-X 3 [
Let us now focus our attention on mobility data sharing, which is a particular instantiation
of the vision described above and the main topic of our work. In general terms, mobility data
can be defined as data that provides information on mobility patterns. For instance, in the
urban domain it can be encountered in the form of network description, timetable information,
car trafic, public transportation or other mobility modes, parking data, and accessibility data
[
Mobility data sharing – and enabling it appropriately – plays also a critical role in the
decarbonization of the European Union. For instance, the European Green Deal9 and the
European Data Space strategy10 strictly depend on the capacity of organizations to digitalize
and share mobility data, since data-sharing and smart mobility solutions constitute an essential
pillar toward the decarbonization of the European transportation sector. Indeed, over the recent
years many systems enabling connected and automated multi-modal mobility took advantage of
smart mobility solutions leveraging shared data and artificial intelligence. For instance, mobility
data sharing can support several novel applications that improve intermodal connections in
transport hubs – e.g., solutions that search for optimal levels of vehicle availability in car and
bicycle sharing systems. All these considerations align with the goals pursued by the Global
Roadmap of Action toward Sustainable Mobility [
Tackling the heterogeneity and peculiarities of mobility data, as well as the various constraints
related to their safe and trusted sharing, is a core objective of the European H2020 MobiDataLab
project11. MobiDataLab envisions the usage of an open and federated cloud-based architecture
to easily and practically enforce complex and often contrasting requirements coming from
FAIR (Findability, Accessibility, Interoperability, and Reusability) and privacy principles. Indeed,
a federated cloud can in principle support the sharing of arbitrary resources from arbitrary
application domains, with arbitrary consumer groups across multiple administrative domains
2https://eur-lex.europa.eu/legal-content/EN/TXT/
3https://www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html
4https://plusplus.sobigdata.eu/
5https://fenix-network.eu/
6http://www.sunfishproject.eu/
7https://cordis.europa.eu/project/id/318485
8https://www.dataforroadsafety.eu/
9https://ec.europa.eu/info/strategy/priorities-2019-2024/european-green-deal_en
10https://digital-strategy.ec.europa.eu/en/policies/strategy-data
11https://mobidatalab.eu/
[
In the following we discuss the Transport Cloud platform, the cloud-based data-sharing federation the MobiDataLab project intends to propose.
The MobiDataLab Transport Cloud platform aims to facilitate access to mobility data in an
open, interoperable, transnational, and privacy-preserving way. The platform also aims to adopt
the FAIR principles [
The vision behind these goals stems from the needs and interests of the stakeholders behind the MobiDataLab project. Indeed, these are public and private institutions that have an interest to either act as mobility data providers (for instance, provide real-time public transportation data, road-network data, vehicle data), or are interested in consuming mobility data through the access and services provided by the transport cloud platform. Therefore, the platform has been designed according to federated cloud principles to ofer solutions that strive to reduce (and, whenever possible, eliminate) current technical limitations that act as barriers to mobility data sharing and reuse.
In the following, we provide more details on the transport cloud platform that is being developed by the MobiDataLab project. First, we focus on the actors interacting with the transport cloud platform. Subsequently, we focus on the inner components of the architecture to detail how the platform enables, facilitates, and promotes mobility data sharing between data consumers and data producers.
∙ Administrators are individuals in charge of managing user accounts and the platform access, deploying applications within the platform, and configuring the components operating within the platform. ∙ Developers are individuals who deal with the deployment and integration of transport cloud components. ∙ Data consumers are entities that use the data and services available within the transport cloud. Relevant examples can be data scientists, researchers, domain experts, transport Administrator t n e m e g a n a M d n a n o itr a u g if n o C
MobiDataLab Transport Cloud Platform
Developer n o ii s v o r P e c i v r e S dn Data and Service taa Providers a D customers, or external services that use the data and services ofered by the transport cloud platform. ∙ Data providers are entities that provide, either passively or actively, data or services to the Transport Cloud. Some examples that were deemed relevant to the MobiDataLab project are Trip planners (e.g., Navitia12, HERE13), MobiDataLab stakeholders (e.g., transport operators or public institutions that actively share their data and services for the good of the MobiDataLab project), and open data/services providers (e.g., OpenStreetMap14).
The architecture of the transport cloud platform has been primarily designed to promote mobility data sharing between data consumers and data providers. Indeed, the components operating within the platform have the role of powering, sustaining, and adding value to the information lfowing between these two types of actors. In the following, we focus on how the data consumers 12https://navitia.io/ 13https://www.here.com/ 14https://www.openstreetmap.org/ MobiDataLab Architecture
Actors
Transport Cloud and producers interface and interact with the transport cloud platform, and elaborate on the functionalities that key components provide to sustain the underlying information flow. To this end, we introduce in Figure 2 a more detailed overview of the platform architecture.
On the one side of the transport cloud we have the Data consumers (box 1 in Figure 2), which can interact with the platform through the several transport cloud channels (box 2 in Figure 2, Data and Service Access box in Figure 1). Said channels are (1) API endpoints (mainly dedicated to REST API services), (2) web interface endpoints, i.e., endpoints dedicated to services which need interaction with the end user (for example scenarios involving data analysis and visualisation tasks), and (3) generic endpoints – for instance, a SPARQL endpoint may enable a data consumer to access some knowledge base via Resource Description Framework (RDF) queries.
Whichever the channel of choice, data consumers first interact with the transport cloud by authenticating themselves via the identity manager (box 3 Figure 2, Data and Service Access box in Figure 1). Once authenticated, data consumers proceed to submit their requests to the transport cloud platform via the API Components (box 4 in Figure 2), which in turn process the requests by querying the metadata and service catalogues (box 3 Figure 2, Data and Service Access box in Figure 1) to find out the appropriate data sources and services (either internal or external to the transport cloud) the platform must use to satisfy the requests. It is worth noting that the technologies currently under examination for the implementation of said catalogues are being conducted according to the FAIR principles.
On the other end of the transport cloud we have the third-party providers, i.e., the data providers previously mentioned (box 8 in Figure 2). The third-party providers always represent the information entry point of the platform as they are responsible for the provision of information in the form of datasets and services. The access mechanisms to these information sources are identified and implemented according to the operations to be performed and the types of data and services that need to be accessed. More precisely, information retrieved from third-party providers can either be imported within the Transport Cloud, thus requiring appropriate storage solutions (box 7 in Figure 2)15, or accessed on the fly through the use of specific data and service endpoints exposed by the providers. We report that the transport cloud will handle the latter type of access using the data and service APIs components (box 4 Figure 2), which may employ appropriate caching mechanisms to improve access eficiency.
Now that it is clear how data consumers and third-party providers (i.e., data producers) interact with the transport cloud, we focus on a key component that enables to process information lfowing within the platform, i.e., the processor (box 5 in Figure 2, which encompasses the Data Privacy & Anonymization, Data/Service Harmonization & Standardization, Data Processing, and Data Fusion and Enrichment boxes in Figure 1). In generic terms, we define a processor as a component that models some function that inputs some data and produces an output according to a well-defined logic. This definition then allows to instantiate the notion of processor in many diferent ways, thus allowing the transport cloud to provide via multiple processors a potentially unlimited number of operations and services. For instance, in the context of mobility data sharing a processor may be used to perform semantic enrichment based on common vocabularies, geographical enrichment based on common geometries, data format translation when some data format must be reconducted to another one, data fusion when multiple datasets must be combined, data anonymisation to increase trust in the platform via privacy-preserving techniques, injection of license specification, and in general any data processing task that is relevant to the goals of the project. In general, it is clear how processors add further value to the transport cloud platform, as they give the ability to create novel data and services. Finally, we report that processors will lean on computational resources internal to the transport cloud platform (box 6 Figure 2).
This paper introduces the concepts at the basis of the Transport Cloud platform, which is the cloud and data-sharing federation proposed by the MobiDataLab Project. The project kickedof in February 2021 and aims to promote the transport data sharing culture in Europe. The MobiDataLab Transport Cloud platform is therefore intended to be an open and inter-operable platform that eases the access and integration of distributed and heterogeneous mobility data owned by distinct organizations. The platform will be available to public and private institutions 15Storage solutions that the platform will include are relational databases, spatial databases, and knowledge graph databases. that have an interest to either act as mobility data providers or consume mobility data through the access and services provided by the transport cloud platform. The platform has been designed to be compliant with the FAIR principles. In the near future we plan to further advance the definition and the design of the Transport Cloud architecture, which will be then evaluated according to the needs of the MobiDataLab stakeholders.
This work has been partially supported by the European Union’s Horizon 2020 Research and Innovation program under the projects ACCORDION (Grant agreement ID: 871793) and MOBIDATALAB (Grant agreement ID: 101006879).