overcome the fragmentation of multiple data formats and communication protocols;

Transcription

1 Semantic Transformations for Rail Transportation Newsletter October 2018 INTRODUCTION AND SCOPE The primary objective of the ST4RT (Semantic Transformations for Rail Transportation) project is to develop a demonstrator tool that will provide ontology-based transformations between different specifications and protocols, resulting in enhanced semantic interoperability between disparate, heterogeneous legacy systems. Such transformation technology is a powerful tool that aims to allow the project to meet the challenge to overcome the complex misalignment of eco-system services due to differences in business models and legacy systems. The Semantic Transformation addresses fundamental obstacles to interoperability and, if widely deployed, will be able to: overcome the fragmentation of multiple data formats and communication protocols; connect multi-modal providers and the services sectors; lower the cost of accessing data that is openly discoverable but of low quality or availability; maximise growth potential for the development of new products and services by removing ICT systems incompatibility, e.g. enabling market players and new entrants capabilities, thereby reducing the cost and time-to-market for the ICT integration This project has received funding from the European Union s Horizon 2020 research and innovation under grant agreement No:

2 ST4RT INTERACTION WITH SHIFT2RAIL The scope of ST4RT project is to fill in a specific role within the fourth Shift2Rail Innovation Programme related to Passenger Services (IP4) by providing the transformation technology which is necessary to assure that technical interoperability can be deployed effectively and cost-efficiently by market actors in order to create service offerings that substantially improve mobility. ST4RT is one of the 1st Open Call projects of Shift2Rail and as shown in the figure below, it built on the work that was carried out in the IT2Rail lighthouse project and will also feed future Shift2Rail projects. Most of the ST4RT project partners were also involved in IT2Rail, which has eased the knowledge transfer needed for such collaborative projects TRL1 TRL2 TRL3 TRL4 TRL5 TRL6 TRL7 TRL8 TRL9 SHIFT2RAIL - IP4 IT2Rail GoF4R ST4RT White Paper Target Market ATTRACkTIVE CONNECTIVE COHESIVE My-Trac FUTURE PROJECT Figure 1: ST4RT interaction with Shift2Rail The transformation technology proposed by ST4RT is essential to achieving the goals for the Interoperability Framework (IF) that will provide the right tools in order to introduce seamless mobility services, foster the development of multimodal travel services and help to overcome the obstacles currently impeding the development of market innovation and limiting a large acceptance of the semantic web for transportation. 2

3 DESIGN OF IF CONVERTERS Interoperability refers to the ability of devices or systems to participate in the coordinated execution of tasks and functions in some business process, in which data/information exchange happens in a transparent way, according to common protocols and formats. Interoperability is achieved when the partners involved in the data/information exchange agree on the common information model and on the interfaces between their systems. Interoperability can be and typically is achieved at the syntactic level. However, a full interoperability should be sought at semantic level i.e., 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. The ST4RT project addresses the issue of interoperability through the creation of an explicit, formal, shareable, machinereadable and computable description of the semantic reference model associated with data descriptions and exchanges. The ultimate goal is to allow for a higher degree of automation of distributed processes across multiple data formats and spanning unspecified actors. These formal, explicit, machine-readable descriptions, in the form of domain ontologies, are maintained, stored and made accessible by the ontology repository provided by the Interoperability Framework and used to annotate web services in the Interoperability Framework s semantic web service repository. Figure 2 summarises the general approach for semantic interoperability that is adopted in the ST4RT project. Two different specifications A and B are semantically annotated in order to create mappings from their data models to the global reference ontology currently represented by IT2Rail ontology, but possibly extended to a network of interrelated domain ontologies. The resulting mappings are the basis for the semantic transformations of ST4RT, so that data expressed in the two specifications can be converted into their respective ontological version. (reference ontology) (Standard A) (Standard B) Figure 2: ST4RT approach to semantic interoperability Whenever two systems that adopt the different specifications A and B such as, for example, those that are used as case studies in the ST4RT project, that is the Full Service Model 1 (FSM) specification and the XML version of the TAP-TSI 918 specification 2 need to exchange information, the semantic transformation takes place. As in the depicted example, a message originally expressed with regards to specification A because it is generated by a system adopting specification A is lifted to its ontological version, by means of the mapping between specification A and the reference ontology; once in its ontological counterpart, the message can then be lowered to a message expressed with regards to specification B, by

4 means of its respective mapping to the reference ontology, and can be consumed by the target system. Of course, the same procedure can be followed when the message exchange is initiated by the system adopting specification B. As mentioned above, the overarching idea is to annotate legacy data representations to be able to match the legacy concepts to those of the reference ontology, and vice-versa. In the ST4RT approach, the assumption is that legacy data representations and the corresponding data instances are given in terms of specification technologies, such as XSD 3 and XML 4. Figure 3 shows the lifting/lowering process in the case where for both the source and target specifications the data representation is defined through XSD files. Notice that the reference ontology will usually be an integration of several ontologies, each defining a separate set of concepts. XML (Source) JAXB Unmarshal Java Object (Source) SPARQL XSDs JAXB Auto Generate Java Classes Intermediate Ontology Named Graph XML (Target) JAXB Marshal Java Object (Target) SPARQL Lifting Transformation: Lowering Transformation: One Time Transformation: Figure 3: Approach workflow in the case where source and target specifications are defined through XSD files The starting point of the approach is that data schema definitions given in terms of XSD files are first translated into declarations in the Java programming language, which can be done automatically through existing frameworks such as JAXB 5. Then, the declarations of Java classes, methods and attributes are annotated to match them with concepts in the reference ontology. For example, Java classes, which capture data types defined in XSD files, are usually matched with classes of elements in the ontology, as it occurs in the following annotation, which maps the ContactInformation concept from the FSM specification to the Passenger class of the customer:passenger ) public class ContactInformation extends FSMID The annotated Java code is used to produce, during the lifting phase at runtime, sets of RDF (subject, predicate, object) triples (that is, a named graph) conforming to the reference ontology, starting from XML files conforming to the XSD definitions of the source specification. The Java-based annotations are also used to produce, during the lowering phase, XML files obeying the XSD definition of the target specification from the named graph created during the lifting phase. In addition to annotation shown above, the ST4RT approach defines other annotations to match concepts from legacy specifications to reference ontology (and vice versa), and in particular@rdfproperty to transform attributes into predicates, which allows for the definition of powerful SPAQRL 6 queries that are useful to perform more complicated mappings

5 REFERENCE IMPLEMENTATION OF IF CONVERTERS The design of the Interoperability Framework is based on the provision of a set of semantic interoperability services that can be deployed in multiple configurations, and that do not mandate a specific set of communication protocols or frameworks, leaving the choice of deployment strategies to partners. A ST4RT converter can play a central role in the Interoperability Framework, since it can be embedded as a library to implement message conversion inside an enterprise service bus or in a dedicated Web Service. Figure 4 gives an overview of the main layers of a ST4RT converter, which are briefly described in the following. ST4RT Converter Process-to-process conversion Message-to-message conversion RDF Lifting / Lowering Framework Figure 4: Overview of the layers of a ST4RT converter The RDF Lifting and Lowering framework provides Java Persistence API Architecture (JPA)-like capabilities extending it with the ability to operate on triple stores i.e., on database systems designed for storage and retrieval of RDF statements ( triples ) through semantic queries. Much as JPA annotations on Java classes provide automatic object-relational mappings from these classes to relational database schemas and vice-versa, the RDF framework provides automatic mappings to/from RDF statements. This enables the developer to delegate the mechanics of connection, input/output and storage/retrieval of the data across the network to the framework, while concentrating on the manipulation in pure Java of objects and relationships which, unlike the JPA entities, represent logical statements connected to the domain s axiomatic description of the domain s ontology. For example, triples generated by a SPARQL query as a result of logical inference i.e., new logical statements inferred based on the axioms and the existing data are automatically instantiated as Java objects and relationships and are therefore available for ordinary programming. The message-to-message conversion layer is built on top of the lifting and lowering capabilities and is able to manage a simple request/response business process. Such feature is implemented by introducing a communication context and by letting developers store intermediate triples inside a temporary RDF repository. The repository also hosts domain ontologies and lookup data (RDF datasets representing nearly static assets such as Stop Places and Locations). It becomes therefore possible to create the response message not just according to data provided by the destination service, but also according to the corresponding request. This is mandatory for converting messages whenever a session is defined. 5

6 ConvertSD JAXB Converter Resources loadsxml() unmarshal(xmlfile) ref ref lowersd marshal(javaobject) loadtxml() savexml() Figure 5: General conversion mechanism As the UML Sequence Diagram depicted in Figure 5 shows, first the XML file conforming to the source data representation (e.g., FSM) is loaded, and it is used by the JAXB framework to instantiate a corresponding Java object. Then, the ST4RT converter uses the annotations defined for the source specification, and additional resources such as repositories of RDF triples on which to run SPARQL queries, to lift the Java object to the integrated ontology. After the lifting process has been completed, a new Java object, capturing the concepts of the target specification (e.g., TAP-TSI 918 XML) is instantiated, and it is filled out with the relevant information during the lowering phase (again, by exploiting resources such as SPARQL endpoints). Finally, the Java object is used by the JAXB framework to create an XML file that conforms to the target specification. 6

7 DEMONSTRATORS HEROS platform The first of the two demonstrators makes use of the HEROS platform provided by Hit Rail. HEROS is a tool presenting a web services interface capable of converting booking messages expressed in the format defined by the Technical Document B.5 of TAP TSI into the 918 XML UIC 7 specification and vice versa. The chosen use case is a reservation for a berth in a night train, with different parameters. The initial request in FSM 8 syntax is converted by the ST4RT converter into 918 syntax. The resulting 918 request is automatically answered by Boomerang, a tool provided by Hit Rail; this answer is passed back to the converter that converts it into an FSM response (attribution of the berth to the customer). The necessary technical preparatory work consisted in adapting the Hardware/Software environment where to run the demo, defining the expected functional results, defining the Key Performance Indicators and the metrics to evaluate the results, storing the sample bookings to be used in the demo in the IF repository, creating the logical connection between the HEROS platform and the reference transformation mappings produced in the previous project phases. The actual tests have then been started, using a reporting system where to store all the results of tests, in order to support the evaluation to be performed in the final phase of the project. The final report will collect the results of the testing activity and compare the results vs KPI and metrics previously defined. IT2Rail environment The second demonstrator has been developed as a merging of the ST4RT converter with the Interoperability Framework created by the IT2Rail Lighthouse project. Its essential purpose is to prove one of the basic design principles of the Shift2Rail IP4 innovation program, namely the ability to insulate any application from the underlying mechanics of interoperability allowing a wide choice of architectural and deployment options to networked participants in the provision of seamless multi-modal mobility services. The fundamental point of the second demonstrator is to re-use, unchanged, the ST4RT converter operating on the first pilot, but allowing it to work across distributed semantic graph spanning the world wide web. This principle is illustrated in the following figure 6: Process-to-process conversion Message-to-message conversion RDF Lifting / Lowering Framework Message A Lifting inferred graph Message B Lowering message A graph The «web of data» domain ontology message B graph «External» graphs Stop places Product code list Reservation systems Countries... etc Figure 6: Distributed semantic graph layer

8 The top three layers of Fig. 4 Overview of the layers of a ST4RT converter, i.e. the ST4RT Converter itself, remain unchanged, and through a graph federation mechanism developed for the demonstrator, operate on a set of distributed graphs linked across the world wide web (the web of data ). The use of local or remote federated graphs is controlled by configuration parameters of the RDF Lifting / Lowering framework, so that both options are available. This adds an important feature to the converter, in that it eliminates the need to obtain and pre-load external data before operation: this is essential from a business process standpoint, in that the network of participants can be open to members joining or leaving the network at their own pace without centralized control. In addition, the ability to operate on a distributed semantic graph allows the Lifting and Lowering phases of the conversion to be potentially executed by different networked systems physically remote to one-another: it would be possible, therefore, to execute Lifting within the client process and Lowering at the server, or to select deployment scenarios. With this new capability available the ST4RT converter is now able to work as an additional component of the Interoperability Framework. To demonstrate this the second pilot uses the ST4RT converter in two complementary scenarios: in the first, an FSM client initiates a PreBooking request answered by a TAP-TSI server acting the booking provider role, in the second the roles are reversed, with the TAP-TSI client initating a Reservation Request answered by an FSM booking provider. FSM Client scenario FSM «PreBooking» message TAP-TSI Reservation Message FSM client ST4RT Converter TAP-TSI Processor FSM «offering» message IT2Rail Travel Expert Broker IT2Rail Triple Store PICO message Trenitalia Travel Expert IT2Rail Ontology Repository Figure 7: Second demonstration FSM Client / TAP-TSI server scenario 8

9 An FSM client used the IT2Rail Travel Expert Broker to obtain offers from the Trenitalia PICO Commercial platforms (depicted in orange) and sends them for pre-booking to a TAP-TSI processor (depicted in light blue), which plays the role of the Boomerang in the first demonstration. All three participating applications, the FSM client, the Trenitalia Travel Expert and the TAP-TSI processor, generate and consume messages in different formats, but interoperability is ensured through semantic conversion at the Travel Expert Broker, for FSM/PICO conversion, and at the ST4RT Converter, for FSM/TAP-TSI conversion. Both conversion mechanisms use the same ontology, served by the IT2Rail ontology repository, and the Stop Place, Reservation systems, Product code lists and Country graphs stored on the IT2Rail triple store and other linked data sources, which all appear to all applications as a single distributed graph hosted on the world wide web. No static data needs to be moved/copied to any application for them to operate, and all applications are in fact seamlessly interconnected using a shared data base which is, in fact, the semantic web itself. The deployment of the scenario consists solely in the configuration of the ST4RT converter to use the federated graphs and in its installation, as a web archive (WAR) on any web server container. TAP-TSI Client scenario TAP-TSI Reservation request / response FSM «PreBooking» request / response TAP-TSI client ST4RT Converter FSM Simulator IT2Rail Triple Store IT2Rail Ontology Repository Figure 8: Second demonstration TAP-TSI Client / FSM server scenario As depicted in Fig. 8, in this second scenario the roles are reversed in that a TAP-TSI client initiates a reservation process with a remote FSM capable booking processor while the interoperability mechanism is unchanged. Due to the unavailability of a live FSM-capable booking engine for the project, the FSM role is played by an FSM simulator component that exposes an FSM specification compliant PreBookig operation web service on a remote system hosted by Oltis Group. The FSM Simulator operates as the Boomerang service in the first pilot but handles FSM rather than TAP-TSI messages. 9

10 POTENTIAL BARRIERS As mentioned earlier, the ST4RT approach relies on the idea that legacy data representations need to be suitably annotated to match the concepts therein with those of the reference ontology - both for lifting and lowering purposes. The annotation process requires a certain level of expertise in various areas. In particular, expertise in the logical formalization of the transport domain s machine-readable ontology, and specifically in the concepts being handled by the specifications, is a must. In addition, a good knowledge of semantic technologies, such as for example the SPARQL language, is also necessary, at least for non-trivial mappings, which typically require the writing of suitable SPARQL queries. In addition, the ST4RT approach currently requires annotations to be placed in Java classes representing the concepts comprised in the specification; whereas this does not entail that knowledge of the programming language itself is necessary, it does at least make the process of actually associating annotations with concepts a bit cumbersome, and this could deter some potential users from adopting the ST4RT approach to interoperability. Several different solutions can be adopted to overcome these barriers, for example to ease the actual process of writing annotations and adding them in the right places in files, but they are outside of the scope of the ST4RT project, and are left for future work. PROJECT STRUCTURE The diagram below shows how the project is structured into the five different Work Packages. WP1 Project Management WP2 WP5 of Interoperability Framework Converters WP3 Design of Interoperability Framework Converters WP4 Reference of Interoperability Framework Converters Figure 9: Project structure of ST4RT WP3 has produced the conceptual design of the converter-generation procedure, whilst WP4 has studied the best approach to implementation of the design, including a selection of tools and frameworks, and provided a specific implementation of the design with the support of established software developer partners active in the provision of solutions and services to the Rail Industry. During the second half of the project, WP5 has analysed the selected target use case, developed the test cases and performance measures, and implemented the actual demonstration scenarios providing quantitative analysis of the results. 10

11 NOTES 11

12 PARTNERS PROJECT COORDINATOR TECHNICAL LEADER THE EUROPEAN RAIL INDUSTRY TM PROJECT PARTNERS FACTS AND FIGURES Total Budget 1 million (100% EU funded) Duration 24 months Project Start Date 1st November 2016 Project End Date 31st October 2018 Number of Partners 8 Grant Agreement No CONTACT US Project Coordinator Stefanos Gogos (UNIFE) Stefanos.gogos@unife.org This project has received funding from the European Union s Horizon 2020 research and innovation under grant agreement No: