Planning cross-border transportation o ers requires gathering data from multiple transport operators within and outside a country. The European legislation demands each member state to set up a National Access Point (NAP) for multimodal transport information, nevertheless, interoperability in accessing data from di erent NAPs is far to be accomplished. In this paper, we describe and validate our approach to consolidate metadata coming from di erent sources using Semantic Web technologies. The presented solution implements an automated ingestion pipeline harmonising metadata from three di erent European NAPs in a single metadata catalog.
In the transportation domain, several data and metadata catalogs coexist,
each one being maintained by a di erent initiative or mandated by a speci c EU
directive or country law. According to the EU Delegated Regulations 2017/1926,
885/2013, 886/2013 and 2015/962, each EU member state has to implement a
National Access Points (NAP) to make national transport data discoverable. A
NAP is an intermediary digital platform allowing access to tra c and
mobility data, and playing a crucial role in data exchange in the eld of mobility in
Europe. From the point of view of the transport operator looking for
mobilityrelated information, NAPs represent trusted sources of data and metadata, and
their content can be reliably used inside their own information systems. A NAP
is a web-based portal handling data concerning Safe and Secure Truck Parking's
(SSTP), Real-Time Tra c Information (road) (RTTI), Safety Related
Transport Information (road) (SRTI) and Multimodal Travel Information (MMTIS)
(all modes like train, busses, metro, cycling etc.). EU regulations mandate the
usage of Transmodel-based speci cations for the data exchange between transport
Copyright © 2021 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
operators and their own reference NAP, therefore aiming for data
interoperability. Nevertheless, the regulations don't specify which metadata should be used
to describe datasets, and how a NAP should be implemented. As a result, each
member State is implementing its own National Access Point using di erent
metadata schemas and exposing its functionalities via custom APIs [
This paper describes how we extended a metadata catalog, named Asset Manager, to seamlessly support accessing both local digital assets, directly added by users of the Asset Manager, and remote digital assets from multiple National Access Points. Our scenario is based upon the real requirements coming from Trenitalia1, which wants to create mobility packages to be sold to tour operators bringing tourists to the Milano-Cortina Winter Olympics in 20262. Creating such mobility packages means locating and accessing timetables of multiple transport operators. Performing this task, even in the case National Access Points are available, is time-consuming and requires checking multiple sources. Consolidating in a single catalog the metadata coming from multiple NAPs, together with metadata provided by Trenitalia, means being able to perform more e ciently the task and better ful l the mobility needs of tourists heading to the Winter Olympics. Such a scenario requires mapping di erent NAP metadata schemas onto a single schema and creating multiple metadata ingestion pipelines.
The steps which we implemented were the following:
i) Metadata schema mapping : the di erent NAP metadata schemas were
conceptually mapped onto a single schema, which is also used to describe the
local assets.
ii) RML transformation rules : the conceptual mappings from the speci c NAP
schemas to the Asset Manager metadata schema were implemented in RML [
To show the implemented approach for NAP metadata harmonisation, we selected three di erent NAPs from France, Belgium and the Netherlands. Since the approach is completely generic, this implementation opens the possibility to use the Asset Manager as an aggregator of multiple trusted metadata sources,
2 A video describing the scenario and the implemented solution is available at https: //www.youtube.com/watch?v=SoOLheMv1wQ
like open data portals, multimodal National Access Points, or other instances of the Asset Manager. In the following sections, we provide details on each step of the approach and meaningful insights about the implemented solution. 2
The main focus of the NAP regulations is to promote the usage of a speci c set of standards, based on Transmodel, across all Europe to improve transport data interoperability. Even though the role of the NAP as a dataset catalog is well-de ned by the regulation, each member state is then free to de ne its own implementation. Such principle led to the appearance of di erent metadata vocabularies, and the need for interoperability between the metadata schemas adopted by di erent NAPs. In our scenario, we analysed in detail the National Access Points provided by France, Belgium and the Netherlands.
Belgian NAP is built upon CKAN, therefore its API4 allows for searching for datasets according to speci c types or features. The metadata schema is quite rich and contains multi-lingual documentation, geographical coverage, and both contact person and responsible transport operator.
French NAP features a rich API5 and metadata schema, containing many
details about datasets. This National Access Point supports NeTEx representation
of static transport data (leveraging on Chouette [
Netherlands NAP has no clear API to obtain metadata, and the actual endpoint6 has been found by analyzing the JavaScript sources of the NAP website. The metadata schema mandates both a responsible person for the dataset publication and an owner transport operator company. The referenced dataset is listed with the attribute publicationURL, and no geographical coverage is present (as opposed to France metadata schema).
Summarising the analysis of the selected NAPs, they all feature di erent metadata schemas, and even basic information describing who is responsible for the asset is not represented in the same way.
A working group composed of representatives from the Netherlands, Germany, Austria and Sweden started to work on common metadata de nitions to be applied to the various NAPs in Europe to increase interoperability and ease the creation of multi-country solutions. The outcome of such group is called Coordinated Metadata Catalogue7 and de nes a minimum set of metadata which, according to its authors, should be supported in all the NAP implementations.
Using the Coordinated Metadata Catalogue schema allows harmonising those NAP schemas onto a uni ed schema, as all the basic information contained in the assets coming from the three di erent NAPs can be represented. 3
The Asset Manager is an RDF-based metadata catalog developed in the context
of the Shift2Rail Innovation Programme 48. We show the possibility to use it as
an aggregator of metadata coming from multiple trusted sources. The objective
is to let companies accessing domain-speci c knowledge in a coherent way using
a single tool. We de ned and validated an approach based on Semantic Web
technologies to perform metadata ingestion, to de ne and execute mappings
to a single metadata schema. Following the European guidelines to represent
metadata in data catalogs, the DCAT Application Pro le v2.0.1 [
Our solution leverages on the Asset Manager and the Chimera tool to: (i) connect to each NAP, (ii) fetch the metadata of its assets, (iii) convert such metadata into a coherent RDF representation to be easily queried via SPARQL, (iv) store the resulting triples inside the RDF repositories, (v) show that the Asset Manager can visualise both local and remote assets. 3.1
The rst and most important part to con gure the NAP metadata ingestion process is understanding the metadata schemas and identify which attributes and data structures can be found in all the di erent NAPs. We decided to use the Coordinated Metadata Catalogue as an intermediate model to ease the de nition of mappings between the metadata schemas. Indeed, the Coordinated Metadata Catalogue speci cation acknowledges the existence of other vocabularies and already provide an alignment to DCAT-AP adopted by the Asset Manager. We
Fig. 1: Conceptual mappings de ned for the harmonisation of the di erent National Access Point metadata schema. exploited such alignment, de ning a two-step conceptual mapping, as depicted in Figure 1: rst from the speci c NAP metadata schema onto Coordinated Metadata Catalogue, and then from that schema onto DCAT-AP.
The de ned conceptual mappings guided the coding of the actual mapping rules using RML9. Therefore, we assembled a metadata ingestion service exposed through a Chimera pipeline10. As shown in Figure 2, calling such service triggers the execution of the following actions for each of the countries: (i) the NAP API endpoint is called to obtain JSON metadata; (ii) lifting is performed on the resulting JSON metadata using the appropriate RML mapping rules and obtaining an RDF representation compliant with the DCAT-AP pro le; (iii) the resulting RDF triples are written in the RDF repository used by the Asset Manager as a separate RDF graph. 3.2
The Asset Manager arranges assets in categories according to so-called asset types. In the considered scenario, we mapped the items coming from the NAPs metadata ingestion pipelines to the journey planning asset type, which can be used to describe either datasets containing timetables or services providing timetables. Whenever a user asks for viewing the list of journey planning assets, the Asset Manager performs a single SPARQL query11 to retrieve the basic information about each published asset.
As can be noticed in Figure 3, when the NAPs metadata ingestion pipeline is activated, the Asset Manager starts showing both local assets and assets coming from National Access Points. This enables users to browse through the consolidated list of assets and to search for the most interesting ones. Moreover, the information retrieval can be automatised by exploiting the exposed Exploration 9 The developed RML mappings are available at https://github.com/cefriel/ nap-harmonisation/tree/main/rml 10 The con guration of the ingestion service is available at https://github.com/ cefriel/nap-harmonisation/blob/main/chimera-route/camel-context.xml 11 The query is available at https://github.com/cefriel/nap-harmonisation/blob/ main/asset-manager/query-visualise-assets.sparql API. As a result, this solution can encourage and facilitate the creation of multimodal mobility packages providing standardised access to information coming from several metadata sources. 4
The general availability of the National Access Points throughout Europe will improve interoperability in the transportation domain, as it will force all actors to provide data according to the Transmodel-based speci cations dictated by the regulators. We demonstrated that converging to a common set of metadata (such as the one proposed in the Coordinated Metadata Catalogue initiative) enables the possibility to treat the entire network of NAPs as a source of trusted data and metadata which can facilitate the planning of cross-border travel o ers.
The integration of remote metadata providers (such as the NAPs) in the IT systems of a transport operator is an operation which must carefully follow the data quality assurance and the information lifecycle processes de ned inside the company. As future work, we will investigate how to integrate the detection of changes in the metadata acquired from NAPs inside the lifecycle processes of other assets managed by the Asset Manager. Since NAPs will become the authoritative source of information in the transportation domain, it is important to promptly detect the availability of new versions of a remote asset used internally by the company (through the Asset Manager) notifying the owners of the dependant applications to check their functionalities and prevent errors.
Although based on a declarative approach, our solution exploits an external
integration engine to perform the actual calling of the API provided by the NAPs.
We will investigate the recent support introduced in RML for Web APIs [
The presented research was partially supported by the SPRINT project (Grant Agreement 826172) and the RIDE2RAIL project (Grant Agreement 881825), co-funded by the European Commission under the Horizon 2020 Framework Programme.