Challenges

COLLABORATIVE LIGHTWEIGHT ONTOLOGY ENGINEERING
Collaborative ontology engineering is experiencing a transformation, where the comprehensive methodologies that were originally proposed in the last decades, mostly inspired by traditional software and knowledge engineering methodologies, and comprising a large set of inter-related tasks with a strong tool support, have led the way to more agile methods and techniques, which are supported by ad-hoc collaborative ontology engineering tools or tools that make use of underlying software engineering infrastructure like GitHub.
In the approach fostered by the Shift2Rail IF, ontologies are the core of the conversion mechanisms that ease the integration of heterogeneous services. Existing services, even when they are not semantically annotated, are typically described through schemas that define the information they exchange, and that provide some semantic information about the information exchanged (e.g., types of elements, subtyping relationships). The ability to extract this semantic information and organise it into automatically-created ontologies, that can serve as a starting point for the agile collaborative ontology engineering tasks, can facilitate the integration process promoted by the Shift2Rail IF.

SEMANTIC AUTOMATION FOR SERVICE INTEGRATION
Semantic interoperability is achieved when interoperating systems are able to interpret the exchanged information automatically and meaningfully, so that exchanged messages are unambiguously defined and understood by the different parties. Semantic correspondences are often captured by message transformation rules that map names, values, and structures in the messages exchanged by different systems. This strategy can be seen as a pragmatic way to address semantic interoperability within organisational boundaries, where naming policies can be enforced and controlled, but not realistic in large and geographically distributed organisations. In these scenarios, reaching semantic agreements is problematic: accurate derivation of meaning cannot be implicit, and therefore the semantic correspondence in message exchanges requires specific tools and methods. In particular, there is the need to better support and, if possible, automate the definition of ontology-based annotations and mappings enabling the conversion/translation of heterogeneous messages exchanged by different systems.

DISTRIBUTED QUERYING PROCESSING AND DATA INTEGRATION
Distributed query processing can be seen as a key enabler to perform data integration in the context of the IF. It will allow bringing together heterogeneous data from a range of data providers, showing a unified view from the available information. One of the most challenging aspects in this context is the data integration at the semantic level and without the need for a centralised data store. Current approaches to semantic data integration are based on the idea of providing virtual or materialised distributed views on the data according to existing ontologies, and published as RDF.

ENHANCED INTEROPERABILITY FRAMEWORK ARCHITECTURE
Though the IF plays a central role in the Shift2Rail IP4 concept, it is not itself meant to be a centralised component that provides in a single point all intended functionalities or MSP invocation such as location resolving, or access to assets such as the reference ontology. Indeed, the success of the IF concept in practice will hinge in good part on it truly being a collection of services that are offered and managed in a decentralised way, and on demand. To achieve its goals, the Shift2Rail IF can benefit from recent advances in the architecting and management of cloud-based systems, such as the use of microservices, stateless components, container technology, and so on. To make this vision of the Shift2Rail IF a reality, the SPRINT project will both study the state-of-the-art in the architecting and management of distributed systems, with a particular focus on cloud-based ones, and it will carry out a careful analysis of the requirements – both external (i.e., as perceived by external stakeholders) and internal (e.g., in terms of performance, scalability, flexibility, security) – of the Shift2Rail IF. This preparatory work will be the basis to identify the architectural patterns and concepts that best suit the needs of the Shift2Rail IF; these patterns will then be instantiated according to the specific functionalities offered by the Shift2Rail IF and the components implementing them.

TESTING INFRASTRUCTURE AND REALISTIC KPIs
We envisage the Shift2Rail IF as a flexible infrastructure that will evolve over time as its adoption spreads to new players. As a consequence, a continuous validation of the adherence of the IF to its requirements will be necessary, to make sure that its functionalities and features are not disrupted. To this end, the SPRINT project will define a testing infrastructure that will allow the maintainers of the Shift2Rail IF to continuously assess the conformity of the latter to its goals. In particular, the project will define, based on the identified requirements of the Shift2Rail IF, a set of test cases and Key Performance Indicators (KPIs) that will be the basis for the aforementioned assessment.

NATIONAL ACCESS POINT FOR MULTIMODAL TRANSPORTATION
The Commission Delegated Regulation (EU), released on 31^st May 2017, focuses on the priority action “provision of EU-wide multimodal travel information services” mentioned in the Directive 2010/40/EU. It establishes the specifications necessary to ensure the accessibility, exchange and update of static and dynamic transportation data for the provision of multimodal information services in the European Union.
The Regulation stipulates the following concerning the notion of National Access Point (NAP):

• (Article 3.1) “Each Member State shall set up a NAP. The NAP shall constitute a single point of access for users to at least the static travel and traffic data and historic traffic data of different transport modes, including data updates provided by the transport authorities, transport operators, infrastructure managers or transport on demand service providers within the territory of a given Member State.”

• (Article 3.3) “National access points shall provide discovery services to users, for example services allowing for the search of the requested data using the contents of the corresponding metadata and displaying such contents.”

• (Article 3.4) “Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall provide the metadata in order to allow users to discover and use the datasets made accessible through the NAP.”

• (Article 4.4) “APIs that provide access to static travel and traffic data via the NAP shall be publicly accessible allowing users and end-users to register to obtain access.”