D2.1: Technology Ecosystem Architecture Ecosystem... · Deliverable leader VLTN 29-02-2016, 10-03-2018 Quality manager JR 28-02-2016 Project manager IF 29-02-2016, 13-03-2018

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Grant Agreement No 636148.

D2.1: Technology Ecosystem Architecture

Project Title: Optimodal European Travel Ecosystem Acronym: EuTravel

Start date of project: 01/05/2015 Duration: 30M

Due date of deliverable: 29/02/2016

Original submission date: 29/02/2016

Submission of version v2.0: 04/04/2017

Resubmission date (v2.1): 15/03/2018

Organisation name of lead contractor for this deliverable: VLTN

Final [v2.1]

Dissemination Level

PU Public

CO Confidential, restricted under conditions set out in Grant Agreement to consortium members and the Commission Services.

Ref. Ares(2018)1484227 - 19/03/2018

EuTravel D2.1: Technology Ecosystem Architecture v2.1

2

Table of Contents 1 EXECUTIVE SUMMARY ............................................................................................................................. 8

2 OBJECTIVES AND POSITIONING OF TASK 2.1 ........................................................................................... 9

2.1 RELATION TO DOA TASKS ............................................................................................................................ 9 2.2 RELATION TO OTHER DELIVERABLES ............................................................................................................. 11

3 REPORT STRUCTURE .............................................................................................................................. 12

4 THE TRAVEL INDUSTRY AS AN ECOSYSTEM............................................................................................ 13

4.1 DIGITAL ECOSYSTEMS................................................................................................................................ 13 4.2 SERVICE ORIENTED ECOSYSTEMS ................................................................................................................. 13 4.3 TRAVEL INDUSTRY ACTORS, SYSTEMS AND PROCESSES ..................................................................................... 14

4.3.1 Types of Travel Ecosystem Participants .......................................................................................... 14 4.3.2 Travel Processes and their architectural scope in EuTravel. ........................................................... 15 4.3.3 Travel Services from the end-user/traveller perspective................................................................. 16

5 TRAVEL SERVICES INTEROPERABILITY IMPERATIVE ............................................................................... 16

5.1 INTRODUCTION AND RATIONALE .................................................................................................................. 16 5.2 ONLINE TRAVEL SERVICES .......................................................................................................................... 17 5.3 TOWARDS TRAVEL SERVICES INTEROPERABILITY ............................................................................................. 18

5.3.1 General Travel and Transport Data Standards ............................................................................... 18 5.3.2 The OpenTravel Standard ............................................................................................................... 19 5.3.3 Rail Services Interoperability Standards.......................................................................................... 19 5.3.4 Ferry Services Interoperability Standards ....................................................................................... 20

6 APIS AND THE TRAVEL INDUSTRY .......................................................................................................... 23

6.1 INTRODUCTION ........................................................................................................................................ 23 6.2 FROM TRAVEL SERVICES TO TRAVEL APIS ..................................................................................................... 23 6.3 TRAVEL API CLASSIFICATION ...................................................................................................................... 24 6.4 TRAVEL INDUSTRY API PERSPECTIVE ............................................................................................................ 25

6.4.1 GDS Perspective .............................................................................................................................. 25 6.4.2 Ferry industry Perspective ............................................................................................................... 25

6.5 REVIEW OF SPECIFIC TRAVEL APIS ............................................................................................................... 25 6.5.1 SilverRail Journey Planner API ......................................................................................................... 26 6.5.2 Travelport Universal API ................................................................................................................. 26 6.5.3 Pharos Seatravel API ....................................................................................................................... 27

6.6 CRITICISM OF CURRENT TRAVEL INDUSTRY APIS ............................................................................................. 27

7 SEMANTIC TECHNOLOGIES FOR TRAVEL SERVICES AND DATA ............................................................... 29

7.1 PURPOSE OF SEMANTIC WEB TECHNOLOGIES IN EUTRAVEL .............................................................................. 29 7.2 THE POTENTIAL OF SEMANTIC TECHNOLOGIES FOR ENHANCING TRAVEL SERVICES .................................................. 29 7.3 DATA INTEROPERABILITY USING SEMANTIC TECHNOLOGIES ............................................................................... 30

7.3.1 Semantic Web Services ................................................................................................................... 30 7.3.2 Travel Ontologies ............................................................................................................................ 30

8 API DESIGN APPROACHES ...................................................................................................................... 32

8.1 API GATEWAY PATTERN ............................................................................................................................ 32 8.2 API ORCHESTRATION ................................................................................................................................ 32 8.3 API RESULT CACHING ................................................................................................................................ 32

9 API-CENTRED TRAVEL ECOSYSTEM ARCHITECTURE ............................................................................... 33

9.1 OVERVIEW OF THE ARCHITECTURE ............................................................................................................... 33 9.2 FUNCTIONAL SUBSYSTEMS AND INTERFACES OF THE ECOSYSTEM ARCHITECTURE ................................................... 34 9.3 SUPER TRAVEL API OPERATIONS ................................................................................................................. 37 9.4 COMMON INFORMATION MODEL AND EUTRAVEL ONTOLOGY .......................................................................... 38


3

9.5 API SUBJECT AREAS .................................................................................................................................. 38 9.6 API OPERATIONS ..................................................................................................................................... 39

10 CONCLUSIONS, DISCUSSION, AND RECOMMENDATIONS ...................................................................... 40

10.1 MAIN FINDINGS OF TASK 2.1 ..................................................................................................................... 40 10.2 INHIBITORS FOR THE ACCEPTANCE OF THE ‘SUPER TRAVEL API’ APPROACH.......................................................... 42 10.3 POTENTIAL IMPACT OF THE PROPOSED UNIVERSAL API ON THE TRAVEL INDUSTRY ................................................ 42

11 BIBLIOGRAPHY ...................................................................................................................................... 44

12 APPENDIX 1: SUPER API SWAGGER JSON SPECIFICATION ...................................................................... 46

13 APPENDIX 2: SEMANTIC WEB SERVICES – LIGHTWEIGHT APPROACHES ................................................. 88

13.1 INTRODUCTION ........................................................................................................................................ 88 13.2 SAWSDL (SEMANTIC ANNOTATIONS FOR WSDL AND XML SCHEMA) .............................................................. 88 13.3 WSMO-LITE (WEB SERVICE MODELING ONTOLOGY LITE)............................................................................... 88 13.4 USDL/LINKED USDL ................................................................................................................................ 89 13.5 HYDRA ................................................................................................................................................. 90


4

Document Summary Information Abstract

This deliverable describes the high-level IT architecture for the EuTravel ‘Super Travel API’ (or API of APIs). It documents the research performed in Task 2.1 and its findings. The report begins with a review of state of the art and requirements for travel service interoperability and the emergence of travel APIs. It discovers the absence of truly multimodal APIs, in the marketplace, but a plethora of single mode travel and related APIs that are largely incompatible with each other. The report therefore proposes a semantics-based approach for API interoperability, for a universal ‘Super Travel API’. The high level technical architecture for the ‘Super Travel API’ and associated systems and services, is described, including its main components: API Registry, Common Information Model, API Broker, Route Planner. The report sets the ground for detailed specification and prototyping of the technical components of the ‘Super Travel API’ in subsequent Work Package 2 tasks.

Keywords

API, optimodal, multimodal, comodal, travel industry, ontology

Authors and contributors

Initials Name Organisation Role BK Bill Karakostas VLTN Deliverable Lead TK Takis Katsoulakos ILS Overall Review IF Ioanna Fergadioti ILS Input to sections 3 and 6,

overall editing TJ Tom Jones Amadeus Input to sections 5 and 7 JR Jenny Rainbird BMT Overall review SK Socrates Katsoulakos BMT Overall review AM Alexis Merle Brittany Ferries Input to section 5 LM Loredana Mancini Business-E Input to section 5 YZ Yannis Zorgios CLMS Input to section 8 JC J.C. Teres I. Casals FGC Input to section 7, overall

review EG Eftichia Georgiou NCSRD Input to section 6 NA Nikos Argyreas NCSRD Input to section 6 AW Alan Warburton Pharos Datacom Input to section 7 NB Nicholas Belle Pharos Datacom Input to section 5 TW Tony Williams Pharos Datacom Input to section 5 AS Andrew Steele SilverRail Input to section 5 IT Ioan Toma STI Input to section 7 IA Iacopo de Angelis Trenitalia Input to section 5, overall

review MT Marco Tognaccini Trenitalia Input to section 5, overall

review DC David Classey Travelport Input to sections 5 and 7


5

Revision history Revision Date Who Comment TOC 01-12-15 ΒΚ, IF TOC Draft v1.0 02-01-16 BK Sections 1-8 Draft v1.1 04-01-16 BK Input and comments from contributors Draft v1.3 18-02-16 BK Submitted for internal review Draft v1.4 23-02-16 IF Internal Review, Edits Draft v1.5 28 -02-16 JR, SK, JC Peer Review Final v1.0 29-02-16 BK Final Edits Final v2.0 14-02-17 BK First resubmission Final v2.1 15-03-18 BK Second resubmission, addressing final review

comments Quality control

Role Who Date Deliverable leader VLTN 29-02-2016,

10-03-2018 Quality manager JR 28-02-2016 Project manager IF 29-02-2016,

13-03-2018 Disclaimer The content of the publication herein is the sole responsibility of the publishers and it does not necessarily represent the views expressed by the European Commission or its services. While the information contained in the documents is believed to be accurate, the authors(s) or any other participant in the EuTravel consortium make no warranty of any kind with regard to this material including, but not limited to the implied warranties of merchantability and fitness for a particular purpose. Neither the EuTravel Consortium nor any of its members, their officers, employees or agents shall be responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or omission herein. Without derogating from the generality of the foregoing neither the EuTravel Consortium nor any of its members, their officers, employees or agents shall be liable for any direct or indirect or consequential loss or damage caused by or arising from any information advice or inaccuracy or omission herein.


6

Abbreviations API Application Programming Interface

B2B Business-to-Business

B2B Business-to-Consumer

CRS Computer Reservation System

DoA Description of Action (GA)

DRT Demand Responsive Transit/Transport

GCP Global Commerce Platform

GDS Global Distribution System

ITS Intelligent Transport Systems

MERITS Multiple European Railways Integrated Timetable Storage

MMITS Multimodal Information and Ticketing Systems

OTA Online Travel Agent

OPS Optimodal planner service

OTD Online Travel data resources

OTS Online Travel Service Orchestrator

PNR Passenger Name Record

POS Point of Sale

PT Public Transportation

QoS Quality of Service

SESA Enabled Service Oriented Architectures

SOA Service Oriented Architecture

SWS Semantic Web Services

TAP Telematics Applications for Passenger services

TAP-TSI Telematics Applications for Passenger Services Technical

Specifications for Interoperability

TMC Travel Management Company

TOP Traveller Online Profile and Record

TPS Third Party Services

TSP Travel Service Provider

UI User interface

VAS Value-adding Service

WSDL Web Services Description Language


7

List of Figures FIGURE 2-1: WORKPLAN RATIONAL ................................................................................................................................ 9 FIGURE 2-2: D2.2 KEY DEPENDENCIES WITH OTHER DELIVERABLES ...................................................................................... 11 FIGURE 3-1: VISUAL ROADMAP OF THIS REPORT .............................................................................................................. 12 FIGURE 4-1: ACTOR TYPES IN THE TRAVEL INDUSTRY ECOSYSTEM. ....................................................................................... 14 FIGURE 4-2: THE STEPS OF THE TRAVEL PROCESS ............................................................................................................. 15 FIGURE 4-3: A VIEW OF THE TRAVEL INDUSTRY’S VALUE CHAIN (BASED ON [7]) ..................................................................... 16 FIGURE 5-1: SERVICE AND API ORIENTED IT ARCHITECTURE FOR SILVERRAIL ......................................................................... 17 FIGURE 5-2: SERVICES ARCHITECTURE FOR FGC .............................................................................................................. 17 FIGURE 5-3: THE FERRYGATEWAY CONCEPT (FROM WWW.FERRYGATEWAY.ORG) .................................................................. 20 FIGURE 6-1: TRAVEL SERVICE AND API LAYERS ................................................................................................................ 24 FIGURE 9-1: ARCHITECTURAL LAYERS OF THE API ............................................................................................................ 33 FIGURE 9-2: ARCHITECTURAL BLOCKS AND INTERFACES OF THE ECOSYSTEM ARCHITECTURE ..................................................... 34 FIGURE 9-3: SUPER API SUBJECT AREAS ......................................................................................................................... 38 FIGURE 13-1: RELATIONSHIP BETWEEN WSDL, SAWSDL, AND WSMO-LITE ...................................................................... 89 FIGURE 13-2: USDL PACKAGES ................................................................................................................................... 89

List of Tables TABLE 2-1: DELIVERABLE’S ADHERENCE TO EUTRAVEL WORK PLAN .................................................................................... 10 TABLE 4-1: TRAVEL TASKS AND ASSOCIATED SERVICES ....................................................................................................... 15 TABLE 5-1: FERRY MESSAGING BASED STANDARDS .......................................................................................................... 20 TABLE 9-1: FUNCTIONAL MODULE DESCRIPTIONS ............................................................................................................ 35 TABLE 9-2: ARCHITECTURAL INTERFACE DESCRIPTIONS ...................................................................................................... 36 TABLE 9-3: USE CASES OF THE TRAVEL ECOSYSTEM .......................................................................................................... 37 TABLE 9-4: MAIN SUBJECTS AND ENTITIES OF EUTRAVEL’S COMMON INFORMATION MODEL (1) .............................................. 39 TABLE 9-5: MAIN SUBJECTS AND ENTITIES OF EUTRAVEL’S COMMON INFORMATION MODEL (2) .............................................. 39 TABLE 9-6: MAIN OPERATIONS OF THE SUPER API .......................................................................................................... 39


8

1 Executive Summary

Application Programming Interfaces (APIs) is a technology that promises to revolutionalise all industries, including the travel industry, where it can promote the concept of optimodality by facilitating the development of seamless intermodal travel services. APIs are the way in which the software applications and computing services initially connect with each other and therefore serve as the starting point or foundation for interoperability and fuller operational integration of organisations. At the moment, in the travel industry there are APIs for the major services underpinning systems such as GDSs. However, the main problem hampering interoperability in the industry is that access to such APIs is hardwired to the applications of travel agents and other system users. Also, many of these APIs are not public. This not only makes APIs more difficult to evolve, but also it makes it harder for intermodality/optimodality services to be developed. The report proposes an API centred IT architecture that realises the Optimodal Framework of EuTravel, that allows the combination of different APIs through a single common interface, thus allowing route planners to create multimodal itineraries that meet the end user preferences and promote optimodal travel.


9

2 Objectives and positioning of Task 2.1

2.1 Relation to DoA Tasks The overall objective of WP2 – Optimodality Ecosystem Enablers is to architect the EuTravel Ecosystem infrastructure and builds on the outcomes of WP1 - Optimodality Framework, while WP3 – EuTravel Living Lab tests and validates the infrastructural components and project concepts. The work packages relationship is shown in Figure 2-1 below.

Figure 2-1: Workplan Rational

Deliverable D2.1 describes work carried out in Work Package 2. Deliverable D2.1 is described in the DoA as “Architectural model of the Ecosystem and APIs architecture including a meta-API allowing the Ecosystem participants (content providers), to interact by publishing their service descriptions in industry standard or proprietary formats. Defines the framework interoperability semantics, semantic translation, mediation and conversion services that will facilitate intermodal travelling”. Specific objectives of Work Package 2 include: 1. Specifying the EuTravel Ecosystem Architecture for the implementation of the Optimodality Framework. 2. Producing the Ecosystem Specification and Prototype Implementation. 3. Developing a unified- cross-device - multilingual user interface design and implementation. 4. Producing Value Added Services from each travel service provider partner, utilising Ecosystem tools. Task 2.1 is informed by T1.1 (Stakeholder needs analysis), T1.3 (Technology assessment, EuTravel Knowledge Base and Observatory), and T1.4 (EU Optimodality Framework and Impact Assessment). Task 2.1 specifies the high level EuTravel Ecosystem Architecture to implement the EU Optimodality Framework (T1.4) by incorporating stakeholder needs, industry technical standards, and state of the art technologies baseline (T1.3).


10

Task 2.1 provides input importantly to T2.2 Ecosystem Specification and Prototype Implementation. The following section is extracted from the project’s Description of Action (DoA) and demonstrates how each sub task of T2.1 is addressed in this deliverable.

Table 2-1: Deliverable’s adherence to EuTravel Work Plan

Main sub-task activities as described in DoA Document Reference ST2.1.1 Specify the architecture using industry

standard methodologies for enterprise architectures.

Addressed in section 9 of this report. In this report the architecture of the Super Travel API has been described using functional diagrams. The full specification of the Super API operations is included in Appendix 1.

ST2.1.2 Review merits of different approaches to service descriptions including BPEL and OWL-S, and more recent approaches such as USDL and Linked-USDL, but also more lightweight approaches such as SAWSDL and WSMO-Lite and Web/RESTful approaches such Hydra.

Addressed in Section 7 and Appendix 2. Semantic technologies for travel services and data are reviewed in section 7. We have adopted Schema.org as the semantic technology to use to describe the Common Information Model.

ST2.1.3 Describe service specifications, and service mashups in languages selected in ST 2.1.2. The set of these interfaces will form a meta-API (‘API of APIs’) allowing Ecosystem participants to interface their systems and data with the Ecosystem.

Addressed in Section 9. The meta-API is specified in Section 9 of the report, using the Industry Standard Open API specification in Appendix 1.

ST2.1.4 Specify requirements for performance, security and data quality to make communications between nodes short timely and reliable.

Addressed in Section 9. Moreover, the outcome of this task, the Optimodal Framework Technical Architecture guides the specification and design work in T2.2-Ecosystem Specification and Prototype Implementation. The general approach to minimize overheads in component communications is outlined in this report, in Section 8. However, performance, security and data quality techniques used are detailed in Deliverable D2.2


11

2.2 Relation to other Deliverables This document serves as a high level concise roadmap towards realising the ‘Super Travel API’ (or API of APIs) and associated technical components and services, that are envisioned in the project’s DoA. Individual concepts, components and approaches are elaborated in other Workpackage 2 deliverables, and also in deliverable 1.4 (‘EuTravel optimodality framework’), which serves as a context model and knowledge base of models, methods and concepts utilised and produced in EuTravel. D2.1 is closely related to D1.4 and D2.2 (Figure 2-2). While D1.4 takes a wide, all encompassing view of the travel/optimodality domain, D2.2 is a reference implementation of a subset of the Optimodality Framework outlined in D1.4.

Figure 2-2: D2.2 key dependencies with other deliverables

D2.1 presents therefore the technology context, enablers and options for producing a universal API for the travel industry. As such it conforms to the overall mandate of D1.4. It also provides an architectural guide for the work described in D2.2. However, D2.1 can be potentially used for alternative implementations of universal travel APIs. This deliverable also collects and analyses the travel industry’s current practice regarding travel APIs and takes a critical view of existing travel APIs approaches. In this respect it is a more technology-focused stakeholder needs analysis, compared to Deliverable 1.1.


12

3 Report Structure

Figure 3-1 shows the relevant subject areas that were considered towards specifying the high-level architecture of the ‘Super Travel API’.

Figure 3-1: Visual roadmap of this report

More specifically: Section 4 considers the travel industry as an Ecosystem of services and identifies its key actors. It then explains how this view of the industry will be transformed by the concept of ‘API’. Section 5 discusses relevant state of the art and state of practice in travel B2B service data standards and protocols from the various sectors of the travel industry (air, rail, coach, and ferries), and discusses their interoperability shortcomings which also become obstacles for API interoperability. Section 6 discusses APIs and their role and importance in the travel industry presenting views from the Consortium’s experts, thus validating the Project’s objective to develop a ‘super Travel API’. Section 7 discusses semantic technologies such as web services and ontologies, their potential for the travel industry and how they informed the design of the ‘Super Travel API’ components such as the Common Information Model and travel ontology. Section 8 presents technologies, architectures and patterns for implementing APIs, used in the ‘Super Travel API’ architecture. Section 9 presents the main architectural components of the ‘Super Travel API’ system, their functionalities, as well as key data and operations supported by the ‘Super Travel API’. Finally, Section 10 discusses the findings of the research, technical and business obstacles to industry acceptance of the Super Travel API concept, and finally its potential impact on the travel industry.

Architecture of ‘super Travel API’

(Section 9)

Travel Industry APIs (Section 6)

Travel Industry APIs (Section 6)

Industry interoperability

Models and standards(Section 5)

The travel industry

Ecosystem (Section 4)

Obstacles, and industry potential

(Section 10)

Obstacles, and industry potential

(Section 10)

Semantic technologies(Section 7)

API technologies(Section 8)


13

4 The Travel Industry as an Ecosystem

4.1 Digital Ecosystems Digital Ecosystems are the digital counterparts of biological ecosystems, exploiting the self-organising properties of biological ecosystems, which are considered to be robust, self-organising and scalable architectures that can automatically solve complex, dynamic problems [3]. EuTravel’s ambition is the creation of: “An ecosystem of travellers, travel services providers, transport infrastructure and services providers, administrations, all in a collaborative environment where all systems communicate, processes seamlessly interoperate and organisations encompass collaborative strategies to create new products and services that enable travel users to organise composite pan-European intermodal trips according to their own set of criteria including best possible environmental performance.” Hence, in this section we define what is an Ecosystem, and more specifically a service -oriented Ecosystem. Then, in section 4.3 we describe the main participants in the travel industry Ecosystem, leading in the next section to an API based view of the Ecosystem.

4.2 Service Oriented Ecosystems An Ecosystem Service Oriented Architecture is one where the interactions between the Ecosystems participants are in terms of services. Service oriented ecosystems allow services to recombine and evolve overtime, constantly seeking to improve their effectiveness for the users. Individuals within the travel industry’s Digital Ecosystem will therefore provide applications (groups of services), created in response to user requests. Other individuals can emerge in a Digital Ecosystem and adapt to find niches where they are useful in fulfilling other user requests for applications. In Service Oriented Architectures (SOA), services inter-operate based on a formal definition (or contract, e.g. by using the WSDL service specification standard) that is independent of the underlying platform and programming language. Service descriptions are used to advertise the service capabilities, interface, behaviour, and quality. The publication of such information about available services provides the necessary means for discovery, selection, binding, and composition of services. The expected behaviour of a service during its execution is described by its behavioural description (for example, as a workflow process, described using a process definition standard such as BPEL). Also, a quality of service (QoS) description, can be used to publish important functional and non-functional service quality attributes, such as service metering and cost, performance metrics (response time, for instance), security attributes, integrity (transactional), reliability, scalability, and availability. Service clients (end-user organisations that use some service) and service aggregators (organisations that consolidate multiple services into a new, single service offering) utilise service descriptions to achieve their objectives. While, as said above, services are described via their interfaces, (e.g. in an XML based interface description language such as WSDL), more recently, the trend towards using Application Programming Interfaces (APIs) is increasing. An API is more detailed than a service interface as it offers also a set of routines, data structures, object classes, libraries and/or operating system services in addition to an interface of a web service. Thus, APIs provide more fine-grained control for service access to developers.


14

4.3 Travel Industry Actors, Systems and Processes

4.3.1 Types of Travel Ecosystem Participants

Figure 4-1: Actor types in the travel industry Ecosystem.

As per Figure 4-1, the Travel Industry Ecosystem comprises several types of actors: Travel operators - Airlines, hotels and transportation companies; these organisations use resources such as planes, properties, vehicles to provide services for travellers. Distributors - Computer Reservations Systems (CRSs) and Global Distribution Systems (GDSs). These consist of technology companies that consolidated supplier information, inventory and pricing data, and provided a way to electronically search, book and issue tickets and documents. Travel Agents (both physical and online-OTA ones) - Using CRSs and GDSs they provide leisure and business travellers with one-stop shopping guidance and pricing and schedule advice to make reservations, issue tickets and provide ancillary services such as passport processing or currency conversion. They operate in a variety of market segments, such as wholesale, retail, business, leisure and specialty packages. Credit/charge Card companies - They play a role by making purchasing more convenient and secure for consumers, and by providing corporate buyers consolidated transaction data about their company’s activities, which helped them with purchasing decisions and policy tracking. Value added service providers - They customise, combine (aggregate/’mash up’) or otherwise add value to existing travel services.


15

Travellers - The end-user or customer, who may be leisure and/or corporate traveller, or a travel planner who books trips for an employee to take.

4.3.2 Travel Processes and their architectural scope in EuTravel. To better describe the meaning of optimodal travel services, some commonly used industry terms are presented below [1] (see also Terminology section in D1.1):

• Multimodal travel: The combination of two or more modes of travel. • Co-modality / Intermodality: the utilization of multiple transport modes as a way to improve

quality and environmental performance of the travel sector. • Co-modal retailing: The purchase of several travel products under different transport

contracts for a single trip. (e.g. air, rail). • Intermodal retailing: Purchasing several travel products under one contract for a single trip

based upon prior commercial agreements between multimodal passenger carriers.

In the context of the EuTravel project, Optimodal travel is defined as intermodal travel, optimized with respect to synchronization between modes, passenger experience and rights, and environmental considerations. As shown in Figure 4-2, the entire travel process can be seen as consisting of six discrete steps, which are further detailed in Table 4-1. The steps of the travel process have been elaborated in Deliverable D1.4 ‘EU Travel Optimodality Framework’ and are listed here for the purpose of scoping the ‘Super Travel API’ architecture only.

Figure 4-2: The steps of the travel process

According to the architectural scope therefore, and for the purpose of the reference implementation (D2.2) steps 1 (‘journey planning’) and 2 (‘booking’) are fully covered by the ‘Super Travel API’ architecture, while other steps such as ticketing are simulated, i.e. without integrating with real ticketing systems.

Table 4-1: Travel tasks and associated services

Travel Tasks Associated Services

Journey Planning Traveller can choose preferred modes; service provides optimized end-to-end itineraries, e.g. quickest, cheapest, least Greenhouse Gas (GHG) modes.

Ticketing and payment

Service offers single account payment for multiple journey legs, so no need to purchase tickets, especially valuable for tourists and occasional users.

Alerting about disruptions Online service monitors execution of itinerary on all modes, calculates actual versus planned service quality, identifies and notify service incidents and degradation as support services.

Continuously updated travel time

Service provides continuous journey/arrival time estimates based on real reported journey times of all connected travellers.


16

information Replanning-rerouting Service offers best alternatives to travellers.

4.3.3 Travel Services from the end-user/traveller perspective The diagram of Figure 4-3 shows that, increasingly, the traveller interacts with the service providers through electronically delivered (e.g. Web) services, that are accessed through web applications and mobile devices. However, such services are neither standardised across the whole industry, nor they cover the whole industry, i.e. there is often lack of interoperability between different travel modes (sea, air, rail, etc.). Figure 4-3 also emphasises that the customer (traveller) receives the services via several layers of systems where a system at each layer has to connect to several systems at the layer prior to it. Today’s travel agencies and developers are challenged by having to tap into multiple websites, GDSs, and supplier-direct channels to access the content, functionality, and pricing they need to satisfy consumer demand. As these systems often are not integrated, the traveller often fails to experience a ‘one stop shop’ experience. This therefore, hampers the goals of optimodality.

Figure 4-3: A view of the travel industry’s value chain (based on [7])

5 Travel Services Interoperability imperative

5.1 Introduction and rationale In this section we discuss the reasons why travel services need to be interoperable, and we review current main industry initiatives and standards for interoperability. The general finding is that several industry efforts to interoperability that involve standardisation of the technical processes (e.g. electronic messages) and data currently exist. Such initiatives vary in scope (i.e. single travel mode vs multiple travel modes), provenance of the standard (i.e. proprietary or maintained by a standards organisation or association) and maturity level. As already mentioned, most industry initiatives are concerned with the standardisation of the electronic messages exchanged between travel industry partners. While electronic messaging (in particular using XML messages) pre-dates API technology there are common elements between the two technologies, namely in terms of the schema of the message payload data. Therefore, the design of the data models of the universal API can be informed by the choice of data models used by the most significant messaging standards.


17

5.2 Online Travel Services Online travel services are delivered today through Web channels such as portals and Web sites of online travel agencies (OTAs) to travel service consumers (B2C), and also through web services to corporate partners (B2B). Figure 5-1 and Figure 5-2 show two representative examples of such travel service provision systems for the rail sector. One observation is that such systems do not always share common data models and thus are difficult to interoperate, for example in sharing train schedules, booking and ticketing.

Figure 5-1: Service and API oriented IT architecture for SilverRail

Figure 5-2: Services Architecture for FGC

Figures 5-1 and 5-2 show examples of travel service provision architectures for the intercity and regional rail industry. It is explicitly shown how internal services are exposed to the various business


18

and retail channels (travel agents, other intermediaries and passengers) as Web services. In Figure 5-1 an API is also shown that allows third party applications to access the seat search and reservation systems. The systems reviewed in this section do not use common APIs for their B2B and B2C services.

5.3 Towards Travel Services Interoperability The European Commission’s 2011 White Paper on Transport [2] envisages a future European Union with a single integrated travel and transport market enabling European residents and visitors to travel across Europe easily and seamlessly as a means to shift passengers from private car usage to more environmentally friendly forms of transport. Numerous benefits, social, environmental and economic are associated with this vision, which is key to the EU strategy on reducing carbon emissions generally. The single most profound obstacle to realizing this one-stop-shop capability is the fragmentation of the market place, which exhibits a proliferation of different formats and protocols for accessing information and processing for the different modes/operators [6]. This is a ‘show-stopper’ obstacle, since harnessing the distribution mechanisms which can handle the variety and multitude of TSP protocols and formats in a sufficiently comprehensive way, is prohibitive from both cost and time perspectives. Whilst adoption of sector-wide standards (formats/protocol) has proven useful in the airline industry, and ongoing improvements can be expected in the railway and public transport sectors as well, full interoperability across modes through ‘super standardization’ is currently unrealistic. Solutions which render fragmentation less important, by offering translation and conversion capabilities, need to be pursued since they obviate the requirement for players to adopt, or conform to, the same set of protocols / formats. This approach is captured in the attempt to harness semantic web technology in the projects IT2Rail [30], Shift2Rail (IP4) [31] and as well as the EuTravel project. Some of the interoperability initiatives and standards pertinent to this report are reviewed below. The “Super Travel API” proposed in Section 9 of this report utilises current travel interoperability standards such as those reviewed in this section. Thus, such standards are seen as underpinning the Super Travel API.

5.3.1 General Travel and Transport Data Standards Several interoperability industry standards for travel and transport related data exist, i.e.: Transmodel (formally CEN TC278, Reference Data Model for Public Transport, EN12896) which is the CEN European Reference Data Model for Public Transport Information, provides an abstract model of common public transport concepts and data structures that can be used to build many different kinds of public transport information system, including for timetabling, fares, operational management, real time data, journey planning etc. The ATA/IATA Reservations Interline Message Procedures-Passenger (AIRIMP) developed by the members of IATA and ATA for the purpose of establishing standard methods of communications with each other when making interline reservations. These procedures apply to mechanical or computerised reservation systems to ensure uniformity, accuracy and economy. IFOPT (CEN/TS 00278207), a CEN Technical Standard defining a data model for the Identification of Fixed Objects in Public Transport (e.g. stop points, stop areas, stations, connection links, entrances, etc.).


19

Aviation Information Data Exchange (AIDX) which is the new official world standard for exchanging flight data between airlines, airports, vendors and systems. AIDX was proposed by the Air Transport Association (ATA) and Airports Council International (ACI). The General Transit Feed Specification (GTFS) [38] defines a common format for public transportation schedules and associated geographic information. Concepts from GTFS have been used to describe intermodal concepts in our Common Information model (Section 9.4) and to strengthen the important intermodal concept of transit between legs of a journey/trip.

5.3.2 The OpenTravel Standard OpenTravel [32] is a not-for-profit trade association, founded in 1999 by travel companies, with a primary focus on the creation of electronic message structures to facilitate communication between the disparate systems in the global travel industry. OpenTravel standard is an open 'syntax' standard that takes communication down to the individual data element level and allows two parties to communicate individual data elements in any order and quantity that they wish. OpenTravel travel standards are intended to create new opportunities for travel agencies as the cost to communicate directly with a supplier for information will be greatly reduced and standardized using a common, widely used, proven protocol. The OpenTravel specification is a large collection of XML schema that are organized hierarchically. This design enables an efficient method for maintaining, understanding, and implementing the specification. It also leverages proven design techniques from XML schema design as well as other software disciplines such as object orientation. Any data exchange that uses the OpenTravel specification may require content from several messages within the OpenTravel schema hierarchy. For example, an airline reservation booking message sent from one trading partner may involve validation by an XML schema that includes several other schema. Those files may define much of the content (e.g., elements, attributes, types) that comprises that booking request message. Each message-level XML schema in the OpenTravel specification represents a particular type of business transaction. The OpenTravel organizational structure is divided into four groups: Hospitality, Transport, Architecture and Travel Integration and this structure is reflected in the message-level XML schema. Each message-level XML schema references other XML schema that, in turn, reference others. Overall the Open Travel Standard is established and influential representing the consensus of an alliance that includes airlines, hotel companies, car rental companies, cruise lines, railways, global distribution systems, distribution companies, solutions providers, software developers and consultants. As such it will be used to inform the design of EuTravel’s Common Information Model.

5.3.3 Rail Services Interoperability Standards Most rail operators in Europe uses national information systems for schedule information, booking and settlement. Data formats are mostly not interoperable and hard to merge. Although there is a certain amount of cooperation between European rail operators, the only approach to a common information platform for the rail industry at the moment is MERITS (Multiple European Railways Integrated Timetable Storage), a single database, which contains the schedule data of all participating rail operators. The platform is for B2B purposes only, and does not provide travellers with schedule information. In order to improve international rail travel, the European Commission has developed TAP-TSI [28] an ongoing initiative to implement pan-European information and booking standards for rail travel. The purpose of the TAP-TSI is to define European-wide procedures and interfaces between all types of railway industry actors (passengers, railway undertakings, infrastructure managers, station managers, public transport authorities, ticket vendors and tour operators). It will contribute to an interoperable and cost-efficient information exchange system for Europe that enables the provision


20

of high quality journey information and ticket issuing to passengers in a cost-effective manner, thus also fulfilling requirements of the Passenger Rights Regulation (Regulation (EC) No 1371/2007). This includes the commitment of making schedule and fare information publicly available to travellers and other rail operators. The contents of this regulation are for example the exchange of data on timetables, tariffs, reservations, fulfilment information to passengers in stations and the vehicle area and train running information. TAP-TSI also aims at a common standard in case of station codes. The implementation of TAP-TSI is ongoing at the time of writing this report. (See also EuTravel white paper A Train Of Thoughts, found on www.eutravelproject.eu).

5.3.4 Ferry Services Interoperability Standards

5.3.4.1 FerryGateway FerryGateway [29] is an initiative of eight major Ferry companies in North-West Europe. The purpose is to have a new standard for communication between Ferry Operators and Agents or other Leisure organizations. The new standard, FerryGateway, whose concept is illustrated in Figure 5-3, provides new opportunities for both Ferry operators, Agents and other Travel organizations and can be beneficial both from a commercial and technical point of view. The two most important benefits are that Ferrygateway will be one common standard and that it will embrace all important products and services that ferry operators may wish to sell online.

Figure 5-3: The Ferrygateway concept (from www.ferrygateway.org)

5.3.4.2 Other Ferry Messaging Based Standards All standards below except Unicorn utilise XML Web Services messaging.

Table 5-1: Ferry Messaging Based Standards

De Jure Standards 1 Unicorn – Unicorn is a mature standard (1985-to date) defined by the European ferries

industry. Pharos is contracted to maintain this standard on behalf of the TTI.

http://www.ferrygateway.org/


21

2 FerryXML – is a mature set of Web service messages defined and maintained by The Travel Technology Initiative (TTI), TTI was founded in 1989 to establish technology standards within the travel industry.

De Facto Standards 3 Xchange Ferry – proprietary schema based, related to TTI FerryXML message structures,

created and supported by Pharos.

4 Pharos Own design XML Web Services (proprietary) – supported by owners.

5 Entee (proprietary)– created by and supported by the AFerry Ltd (formerly The Travel Gateway Ltd) the world’s largest ferry distribution company.

6 Seatravel – OpenTravel Alliance 2.0 object-oriented structures, WSDL (Web Services Description Language) based, travel industry compatible; created by Pharos.

7 FCGp – embryonic standard – based on TTI FerryXML with data element harmonisation.

5.3.4.3 Provenance of Standards Of the above standards 3, 5 and 7 are derived from 1 or 2. They are intimately related to the original Unicorn message structures. This is the reason of their incompatibility with mainstream travel API message structures. The view of Pharosdatacom: To facilitate modern trading, changing the operators’ (some 70+ of them) IT systems to utilise a common API standard which is travel-compatible is not a practical proposition in the short term. Aside from the enormous project program and investment required there would need to be the necessary change of heart and conviction across the ferry sector that travel and other transport markets are a valuable achievable objective. This situation is counter to the aims of the EuTravel project which seeks to demonstrate the practicality of multimodal travel, and requires intimate online collaboration at the reservation transaction level between the selected types of transport booking systems. A new universal ferry API standard is required therefore to promote the ferry industry. This can be a subset of the ‘Super Travel API’, proposed in this report.

5.3.4.4 The Coach Services Interoperability Initiatives Coach services can be classified as:

• Regular (domestic and international) services operate at specified times on defined routes, with specific boarding and alighting points, and are open to all.

• Special regular services operate on defined routes and at defined times, but provide for the carriage of specific types of passengers to the exclusion of others.

• Occasional services are services which do not meet the definition of regular or special regular services, and which are characterized above all by the fact that they carry groups of passengers assembled on the initiative of the customer or the carrier itself.

• Demand-responsive coach services (e.g. Shuttle bus services). The sector is extremely fragmented in terms of the authorities in charge of its regulation, the size and type of market operators and the range of transport services, from scheduled long-distance services,


22

to school transport services, and shuttle services operated for tourists between airports and hotels [8]. The importance of these different types of services varies significantly between Member States of the European Union. In comparison to the rail and air transport sectors, there is little European legislation applying to the bus or coach sectors and as a result, there are significant differences in the regulatory environment within which the bus and coach sector operates in different Member States. Again, because of the fragmentation of the sector there is little evidence of IT interoperability standards, in terms of messages or APIs. Every organisation implements its own proprietary standards. Some exceptions include the use of the GTFS timetable format [38] by the larger coach operators.


23

6 APIs and the Travel Industry

6.1 Introduction APIs are increasingly the preferred technology for service interoperability, composition (mashup) and consumption by consumer devices, in particular mobiles. In this section we explain why the API approach is key for the travel industry, and how segments of the industry such as GDS providers approach it. These findings further confirm the need for a universal API as proposed by EuTravel. Kaplan and others [9] have coined the term API economy, “where the value of a vendor solution is only as good as the APIs that surround it,”. APIs have become the currency for success in the SaaS (software as a service) and broader cloud computing marketplace. Companies that have opened their software to third-party integration via APIs are in a good position to succeed, by making their solutions that much easier for their customers to integrate into a multi-vendor or hybrid environment. APIs are the way in which the software solutions and computing services initially connect with each other and therefore serve as the starting point or foundation for interoperability and fuller operational integration. For developers, this means not only capitalizing on existing APIs but also making their own applications open via APIs. APIs are not the same as a service interface. An API is a direct gateway to company resources from a client perspective, while a service is company perspective of what the company provides to external world. A new API standard for the travel industry should meet the following requirements:

• durable technology and comprehensive functionality • user interface resilient to source operator API developments • easy to implement by the user to minimise integration costs • travel industry compatible, using for example standardised message structures (Section 5) • present a robust user interface; backwards compatible • ultimately embody business rules at the operator level • map all current API operator interfaces to ensure industry continuity (acting as a wrapper) • facilitate online trading with transport and mainstream travel sectors • may be adopted, owned and used as ‘native’ by the industry sectors.

6.2 From Travel Services to Travel APIs Increasingly, as shown in Figure 6-1, the key systems and data (e.g. timetables) of the travel service providers, are accessed through API interfaces. Although Web services are useful for integrating Business to Business (B2B) processes of existing participants, APIs can leverage and expose organisational resources to bring more dynamicity to the travel Ecosystem. Therefore, EuTravel, aims to transform the travel industry from the currently service oriented one, to one where the focus is on APIs. Although services and APIs share many similarities, services such as those reviewed in the previous sections, are primarily B2B oriented, while APIs offer the potential to open up novel B2C services of the industry to the general public and value adding services (VAS) to third parties.


24

Figure 6-1: Travel service and API layers

A travel service exposing an API is in principle more flexible than a fixed travel service designed to support a single system or application (e.g. of a single OTA). An API enabled service is designed to be easier interoperable with other travel services, allowing a chain of intermodal services to be created. For example, a service API can expose more information about the status of the service (for example delays or alterations) that in turn allows other services to handle in order to create a seamless experience to the traveller, by stopping from the whole planned itinerary to collapse because of problems in a single service.

6.3 Travel API Classification There are several types of APIs but they can generally be classified as:

• APIs oriented towards developers that want to integrated/aggregate existing travel services (e.g. to create portals and mashups, for travel aggregators). These also cover multiple travel modes (sea, land, air) and facilities (e.g. car and hotel hire). These APIs have transactional capability (e.g. create bookings).

• APIs oriented towards one type of service/travel mode (e.g. air travel) and/or one provider (e.g. one particular airline only). These APIs also may have transactional capability.

• APIs that provide travel related but static information (e.g. about locations such as places to visit or airports) but they do not (normally) support itinerary planning as timetabling and dynamic travel information is not included

• APIs that provide timetable-like information such as bus or flight arrival information, flight tracking, for single or multi-mode but (normally) no booking functionality.

• APIs that allow the sharing of information or resources between travellers, such as recommendations about visiting places, travel routes and trails etc.


25

6.4 Travel Industry API Perspective

6.4.1 GDS Perspective Global Distribution System (GDS) owners and Global Commerce Platforms (GCP) are key players in the travel sector; they are both networks operated by companies enabling automated transactions between vendors and booking agents in order to provide travel related services to the end consumers. They work as a communication channel, linking services, rates and bookings consolidating products and services across many travel sectors. Primary customers of GDS are travel agents to make reservation on various reservations systems run by the vendors. GDS systems have real-time link to the vendors’ databases and provide and process massive amounts of travel data, acting as:

• distribution partners for airlines, hotels, car rental companies, tours, extra services etc., (GDSs have also expanded to the rail sector and there is also limited access to ferry, coach and bus services);

• service providers for traditional travel agencies, online travel agencies and corporations.

Arguably, APIs play particular role in the case of GDSs who act mainly as service aggregators. GDSs can act both as API providers and consumers by offering API access to their own systems, but also integrating systems and services of their partners through partner APIs.

6.4.2 Ferry industry Perspective The ferry industry’s use of APIs consists of many reservation services and techniques of many designs, provenance and varying quality, resulting in incompatibility between the operator reservation services seen via their APIs by users: This causes high investment cost thresholds to potential users. The interface technology pattern has caused a split user market:

• Implementers of the APIs to date are all ferry specialists: the APIs are too complex and diverse to justify integration by users not specialised in ferries. These users specialise or are particularly dependent upon ferries.

• For mainstream travel and transport organisations, given the small size of the ferry sector, the required high investment for integration and without the necessary ‘ferry culture’, integration is uneconomic. These would-be users have not overcome the API technology gap, are not particularly dependent on ferries and represent the vast majority in number of potential users

Due in large part to this factor, a gap exists between the whole ferry sector and other travel and transport sectors. Ferry is isolated technically, and as a result commercially. This prevents the exploitation of the ferry sector by mainstream travel and transport organisations. Strategic alliances for trading are inhibited. The trend in the techniques used in APIs is moving away from Unicorn towards Web Services, but without a significant trend towards commonality or the means of distribution to the wider transport and travel sectors.

6.5 Review of specific Travel APIs In the following sections we review some APIs of GDSs that participate in EuTravel. Due to their comprehensive functionality, these APIs have been studied as starting points towards specifying the ‘Super Travel API’. Their functionalities can be compared with the ‘Super Travel API’ listed in Section 9.


26

6.5.1 SilverRail Journey Planner API SilverRail Journey Planner provides an API that allows clients to obtain public transport information for a variety of countries, cities, and regional areas via a single, easy to use interface. The SOAP interface is defined via a publicly available WSDL file. A REST interface is also available. The system provides the following services:

• Journey Planning: Using this method, clients can enter details about the journey they would like to undertake (such as origin, destination and time) and the journey planner will respond with a set of journey plans which satisfy this request.

• Fares: Where available, each Journey Plan will include fares information. • Stop Timetables: Using this method, clients can retrieve all trips arriving or departing at stop

within a given time period. • Trip Timetables: Using this method, clients can retrieve the full details for a particular trip,

including the geographical path (for display on a map). • Nearby Stops: Using this method, clients can obtain a list of public transport stops near a

specified geo coordinate. • Route Maps: Using this method, clients can obtain the geographical path(s) covered by a

particular route, for display on a map. • Isochrones: Using this method, clients can obtain details of each stop in the network which is

reachable from a single user specified point (geocoordinate); departing within a user specified window, and arriving within a user specified maximum travelling duration.

• Reference Data: Using this method, clients can obtain lists of service providers, transit stops, landmarks, transport modes, routes and route timetable groups servicing a region.

• Stops Lookup: Using this method, clients can obtain all transit stops whose name contains a given search term.

• Route Lookup: Using this method, clients can obtain all routes which either completely or partially match the Route Code or Route Name of a given search term.

• Timetable Lookup: Using this method, clients can generate Timetable information for a specified combination of: From StopUid, To StopUid, list of permitted Routes.

• Available Reference Data: Using this method, clients can obtain download urls for reference data, without the risk of truncation or timeout when accessing very large datasets.

• API Keys: Clients can obtain additional API keys for direct access to the service from end users' devices.

6.5.2 Travelport Universal API Travelport Universal API is the GDS industry’s first application programming interface (API). The Universal API offers the power to aggregate travel content and related services from multiple sources through a single interface. This includes:

• GDS content • Low-cost carrier content • Directly connected high-speed rail content • Merchandising content including optional services content from travel suppliers worldwide,

regardless of the filing method

As a result of the new technology, developers can access content efficiently by coding to one single solution instead of multiple APIs. Third-party developers, online travel agencies (OTA), travel agencies and consolidators globally can experience many benefits using Travelport Universal API when building travel related applications for deployment on the web, for desktop solutions or mobile applications, including:

• Improved efficiency and time-to-market,


27

• Streamlined travel supply chain, • Reduced software development costs.

Customers using applications built with Travelport Universal API can leverage seamless booking experiences through the use of the Travelport Universal Record – a Super PNR. Travelport Universal Record is an off-host structured database that stores data for all segments booked through the Travelport Universal API – regardless of content source – with full synchronisation back to the GDS PNR to maintain mid- and back-office integration. Travelport Universal API also works side-by-side with existing APIs. Agencies and developers can maximize their IT investments by gradually supplementing their existing content feeds and functionality as they transition to the new content resources and tools made available through Travelport Universal API. Travelport Universal API is also a key interface and central to the underlying architecture of Travelport’s next-generation technologies, including Travelport Universal Desktop, the booking solution that unifies travel selling and merchandising onto a single platform.

6.5.3 Pharos Seatravel API The Pharos Seatravel API supports many European car ferry services, including those required in the project scope of travel journeys to be exercised in the Living Lab. Seatravel is an (Open Travel Alliance) OTA v2 object-oriented methods API. Service is provided by Pharos’ B2B hub which connects users to all partner ferry operators. There are two web services – Informational and Transactional. Typically, applications will utilise the informational service followed by the transactional service. Informational – the cache enables enquiries about groups or individual methods comprising:

• Ferry Operators, • Routes, • Scheduled timetables for departure and arrivals, • On-board accommodation types, • Supported methods of Travel, • Supported Passenger Types, • Supported Vehicle types and Trailers, • Port Geocodes, • Countries, • Journeys.

Transactional functions: • Specify Sailing Time/ date / Route, • Request Sailing availability, • Get Available accommodation, • Specify passengers and vehicles, • Request Quotation, • Reserve / Ticket.

6.6 Criticism of Current Travel Industry APIs There are both de jure standards and de facto API standards in use. De facto standards are those APIs between an operator and many user partners which are not formal de jure. De facto standards are also used by intermediaries to overcome the myriad standards, unifying them by offering a single API to users.


28

This pattern of API use illustrates the extensive disparity of standards in the sector and the complexity of trading relationships of the supply chains [17].

• The de jure standards are not successful, not of current technology nor suitable for trading with other market sectors.

• There are myriad de facto API standards in use, none of which are mainstream travel and transport compatible.

• Sectors like the ferry sector has been left behind in the implementation of API technology for modern online trading with strategic partners and is isolated, i.e. is not being utilised by other travel and transport sectors.

The travel industry representatives participating in the project have suggested that1: The industry needs a path to significantly better, sustainable expansion. This re-invigoration should begin with better, durable API technology as the mechanism of trading with travel and transport players. An alternative approach would be a technique which would deliver access to the market quickly and allow the operators to adapt over a long period of time. In essence, a user interface which will hide the disparity between systems and ensure a basis for users to affordably invest in it, because it is durable. This is a valid and much needed solution. With such a technique, the travel industry could benefit quickly from the fruits of sustainable expansion and distribution, in a trading scenario mirroring and engaging with mainstream travel and transport sectors. Following from the above, it can be argued that the project’s approach to develop a common Travel API that unifies the disparate travel APIs in existence today is a valid one. Furthermore, this approach will have a positive impact to all types of stakeholders in the travel industry.

1 Alan Warburton- Pharosdatacom: Input to deliverable D2.1


29

7 Semantic Technologies for Travel Services and Data

7.1 Purpose of Semantic Web technologies in EuTravel The Project is utilizing semantic web technologies as a key feature of its architecture. More specifically, a new travel ontology extending Schema.org and incorporating elements from the above travel related ontologies will be developed. The purpose of the EuTravel ontology will be twofold:

• To define the Common Information model that achieves data interoperability between different APIs (Deliverable D2.2), and

• to semantically annotate Value Added Services that will be developed in the Project (described in deliverable D2.4).

In this section therefore, we review semantic technologies with the purpose of identifying those that serve the project requirements and will provide a baseline for developments.

7.2 The potential of semantic technologies for enhancing travel services The new role of the Web as a communication and transactional medium in all areas of economic activity, including travel, has resulted in a proliferation of electronically delivered travel services and of digitised online travel data. However, such services and data are usually oriented for human consumption and lack precisely defined machine interpretable semantics. This means that the automation of many travel tasks, especially searching for travel related information is hard. It is difficult to find within the Web large sources of semantically annotated travel content (in particular, travel related content). Text mining techniques can be applied to analyse classify and annotate web pages containing various travel-topics. A possible solution to this problem has been suggested, in the form of semantic demarcation of Web resources or, more generally, the Semantic Web as proposed by Berners-Lee and others [25][26]. When properly applied, semantic languages like RDF, OWL or DAML can turn human oriented web pages into machine-consumable data repositories. Semantic Web can deliver on its promises coupled with software agents that are highly interdependent and work together to deliver services needed by the user. Agents can be used to implement a complete platform for travel support that will utilize semantically annotated travel data. Such agents can act as infomediaries by indexing and linking to the actual sources of travel information. Agents can also cache travel information where actual content is brought to the central repository of the agent. If travel data are represented as RDF triplets, i.e. as a resource that is located somewhere within the Web and can be found through a generalized resource locator. Semantic technologies are based on formally describing and using the meaning of information and services. This enables machines to understand and potentially satisfy user requests, by processing the meaning or ‘semantics’ of information. The Semantic Web aims at improving the current Web by increasing the automation and accuracy for retrieval of information, extraction of information as well as combining and processing of information. Semantic Web is powered by a set of languages and frameworks that provide the fundaments for building the intelligent, semantic layer on top of the classical Web, including the Resource Description Framework (RDF) [27], RDF Schema (RDFS) [13], SPARQL [14], the Web Ontology Language (OWL) [15], its newest version OWL2 [18] and the Rule Interchange Format (RIF) [33]. The underlying syntactic layers include technologies such as Unicode: the Uniform Resource Identifier (URI) [34], the Extensible Markup Language (XML) [35], the Document Type Definition (DTD) [36] and the XML Schema [37]. RDF, RDFS, SPARQL and OWL are at the core of the Semantic Web. RDF is a simple yet powerful data model and language for describing Web resources. RDF models information as triple (subject, predicate, object), which can be interconnected (e.g. the object of one triple is the subject of another triple) and in this way graph models can be created. RDFS extends RDF by introducing means to model


30

classes, properties, hierarchy of classes and properties, and simple domain and range restrictions. SPARQL is the defacto standard used to query RDF data. Finally, OWL (version 1 and 2) is the standard language for representing knowledge on the Web.

7.3 Data interoperability using Semantic Technologies A challenge that we address in EuTravel is data interoperability, due to the use of different formats, models, schemas in the travel domain. The main idea is to use semantics, in particular the EuTravel unifying ontology to support the mapping process. On one hand the EuTravel Travel Ontology can be used as a central mediator structure to which the different schemas that need to be mapped are connected. On the other hand, the ontology can further support the mapping process by acting as a domain specific i.e. travel specific thesaurus that can be used to facilitate the mappings between related terms.

7.3.1 Semantic Web Services Semantic Web services (SWS) aim at providing more sophisticated Web service technologies along with support for the semantic Web. SWS utilise ontologies as the underlying data model in order to support semantic interoperability between Web services and clients and apply semantically enabled automated mechanisms that span the whole SWS usage lifecycle, comprising discovery, selection, composition, mediation, negotiation, and execution of Web services. More generally, the introduction of semantics as an extension of Service-Oriented Architectures, and thus the creation of Semantically Enabled Service Oriented Architectures (SESAs), provides for next generation of service-oriented computing based on machine-processable semantics. The advantages of SWS stem from the fact that explicit, formal semantics is associated with the Web service description, and that the execution environment for SWS is able to interpret and use this semantics appropriately. This supports direct understanding of the Web service functionality at design as well as at run time. The earliest approaches to SWS are the so-called top-down approaches, such as OWL-S and WSMO. Following these approaches, the designer starts with a high-level conceptualisation of all the knowledge related to the services (using ontologies), and then “grounds” it down to actual services. These are also called “heavyweight” approaches, as they provide powerful but very complex frameworks, based on logics, to describe Web services. Such complexity, however, proved to be too high and often unneeded, and together with the difficulty of applying a top-down design to real Web service usage scenarios it determined the substantial failure of such approaches. To address these issues, “lightweight” approaches emerged, based on more lightweight semantics, which provide less ambitious automation capabilities but offer a simpler, bottom-up, approach based on semantically annotating current Web service descriptions (i.e. WSDL). The most relevant for the needs of EuTravel are described in Appendix 2.

7.3.2 Travel Ontologies Semantic Web services can be also achieved by using ontologies such as schema.org, namely schema.org actions. Schema.org actions is a vocabulary that enable websites to describe actions they enable and how these actions can be invoked. Some example of actions relevant in the travel domain that can be described using schema.org actions vocabulary would be: provide a travel plan or book tickets for the planed itinerary. To support service reuse and integration, we aim to use Semantic Web services standards to annotate services and provide service related tasks. Ontologies in the travel domain should be able to describe three important aspects: 1. Capability to describe activity of moving from one location to another

a. Describe who is travelling b. Describe the original location c. Describe the final location


31

2. Capability to describe means of transportation used when moving from one place to another 3. Capability to describe activity to stay for a relatively short time in between movements Below we describe some additional travel related ontologies that have informed the design of the EuTravel ontology.

7.3.2.1 Travel Ontology from SWAT Project A travel ontology has been proposed by the SWAT Project [39]. Version (v26) of the ontology consists of 146 classes, 64 object properties, and 8 data properties.

7.3.2.2 General Transit Feed Specification (GTFS) GTFS [38] which has been superseding the Transit vocabulary [40] is a translation of the General Transit Feed Specification [41] as an open standard data format for public transport schedules. Latest version (03.02.2016) has 29 classes, 19 object properties and 22 data properties.

7.3.2.3 Travel Agent Game in Agent cities (TAGA) TAGA [42] is an agent framework for simulating the global travel market on the web. The framework provides several ontologies:

• Travel Business • Auction • FIPA OWL content language • TAGA Query language • The travel business ontology contains 34 classes and 16 object properties.

7.3.2.4 Travel Guides Travel Guides [43] utilizes Semantic Web technologies to decrease the maintenance efforts required for existing e-Tourism systems and ease the process of searching for vacation packages. It provides a travel ontology as an extension of the PROTON Ontology, contains 67 classes, 19 object properties and 3 data properties.

7.3.2.5 Knowledge Model for City and Mobility (KM4C) KM4C [44] is a knowledge model to describe a smart city, that interconnect data from infomobility service, Open Data and other sources. Latest version 1.6.1 (2015) contained 582 classes, 214 object properties and 120 data properties.


32

8 API Design Approaches

In this section we discuss the API techniques, concepts and patterns that we used to design the ‘Super API’ architecture that is presented in Section 9.

8.1 API Gateway Pattern The granularity of APIs is often different than what a client needs. When an API is fine grained, it means that clients need to interact with multiple services. For example, a, e-shopping client needing the details for a product needs to fetch data from numerous services. Different clients also need different data. For example, the desktop browser version of a product details page desktop is typically more elaborate then the mobile version. Network performance is also different for different types of clients. For example, a mobile network is typically much slower and has much higher latency than a non-mobile network. This means that a mobile client using the mobile data network that has very difference performance characteristics than a corporate API client that uses a web application from inside a LAN. The LAN web application can make multiple requests to backend services without impacting the user experience where as a mobile client can only make a few. Finally, the number of service instances and their locations often changes dynamically. Partitioning into services can change over time and should be hidden from clients. An API gateway (or ‘broker’) is the single-entry point for all clients. The API gateway handles requests by proxied/routed to the appropriate service/API. It handles other requests by fanning out to multiple services/APIs. Thus, with an API gateway a uniform client interface can be used to connect to different APIs in a way that addresses the requirements of each client. The API gateway can also implement security, e.g. verify that the client is authorized to perform the request.

8.2 API Orchestration The API Orchestration Layer is an abstraction layer that takes individual APIs and orchestrates them in a specific way to implement a composite service (‘mash-up’). The API orchestration layer itself can be made available as a service, allowing companies to combine multiple APIs in their services and applications. While there are many ways in which to implement this architectural construct, the concept remains the same across all of them. An API controller is an application delivered as a service that controls API requests received and applies authorisation and authentication policies and coordinates resources needed to fulfil the API request.

8.3 API Result caching When making requests to an external service’s API, some requests will frequently occur with the same parameters and return the same result. If requests or responses are cached, we can reduce HTTP requests, which can improve performance and avoid hitting rate limits. However, we don’t always need to cache the entire API response. We can save space, by saving only the results we are interested in. Expiration policies need to be defined as to how long the data can remain in the cache before they need to be flushed.


33

9 API-centred Travel Ecosystem Architecture

As explained in Section 6, there is a plethora of travel related APIs. While each of them has unique strengths and weaknesses, it is hard to know what might best enhance user experience and/or add value. In particular, most APIs do not provide adequate coverage for multi-modal/inter-modal transportation, as they tend to specialise in one aspect of the trip such as flights or hotels. It is also hard to combine (‘mash-up’) APIS due to semantic incompatibilities. What is still lacking, therefore, is the ability to give users a way to search transport on a “door to door” basis showing them different possibilities and making travel trip planning more flexible in terms of time/money ratio.

The ‘Super Travel API’, that will be developed by EuTravel will provide the capability to combine information obtained from different APIs in an intelligent way, based on semantics and therefore to utilise services with existing protocols and standards, regardless of the underlying APIs. The EuTravel ontology will be used to describe the semantics of the API, as it is particularly suited to modelling applications which involve distributed information sources, publication of shared vocabularies to enable interoperability and development of resilient networks of systems which can cope with changes to the data models. The ‘Super Travel API’ borrows from concepts of the semantic web and linked data (see Section 7 and Appendix 2). The great advantage of that is that, in principle, there is only need for just one common API. However, the semantic Web has not made significant progress in the travel industry yet, thus the Project will need to develop its own comprehensive travel ontology as well as tools for semantically annotating travel services and APIs. . The semantics based ‘Super Travel API’, will provide the capability to bridge both internal IT as well as external travel services with existing protocols and standards, regardless of the underlying APIs. Another benefit of this approach is that of future proofing (addressing the likelihood that both application APIs will evolve, and the ways users will want to access the applications will also change).

9.1 Overview of the Architecture The high-level components of the Super Travel API IT Architecture are shown in Figure 9-1.

Figure 9-1: Architectural Layers of the API

The ‘Super Travel API’ implemented in terms of the API Gateway, Common Information Model and API Registry components. These components provide filtered travel data extracted from GDS systems to travel planner applications. In turn, such planners interact with user-oriented travel planning and booking applications. The ‘Super Travel API’ presents a single universal interface (API) to all clients. It acts as a ‘gateway’ and ‘broker’ (see Section 8) to translate the client API request to the correct API call to the back-end systems of GDSs, OTAS and other service providers.

UI Travel Planner OptimodalPlanner

API registry

API Gateway GDS SYSTEM

Common Information

Model

Searchquery Travel

Datarequest

Travel dataFiltered results

User preferences

& choices

Filtered and ranked itineraries

Proprietary API


34

One client request can be ‘fanned out’ to multiple GDS systems for example, to retrieve travel data such as flight availability and pricing, for a route requested by the user/planner component. API information is retrieved from the API Registry component where information about each travel provider API registered with the Super Travel API is maintained. Finding appropriate APIs to invoke is via pattern matching and utilisation of the Common Information model that semantically links travel domain concepts. This allows finding semantically linked resources between an API request and an API response, ensuring that meaningful data are returned to the requester. The API parameter marching algorithm will be explained in subsequent deliverables, i.e. D2.2. Responses from the GDS systems are cached by the ‘Super Travel API’ to avoid the overhead of unnecessary API calls. The cache is refreshed periodically depending on how long different travel data remain ‘live’. In the remaining of the Section we specify the components of the ‘Super Travel API’. Specification and design of other components of the architecture will be the responsibility of other WP2 tasks (2.3 and 2.4). Detailed specification of the ‘Super Travel API’ will be provided in further project deliverables such as Deliverable D2.2 ‘Ecosystem Specification and proof of Concept Implementation’.

9.2 Functional subsystems and interfaces of the Ecosystem Architecture Figure 9-2 shows the proposed architecture of the Optimodal Framework’s IT architecture, from a functional viewpoint, which exploits the functionality of the ‘Super Travel API’. In this viewpoint, only functions of services and the interfaces they expose are defined.

Figure 9-2: Architectural Blocks and Interfaces of the Ecosystem Architecture

These services are assumed to be deployed on the Cloud, travel service providers web sites and portals, GDS systems, etc. These functional blocks will be implemented as mobile or Web applications,

UI-User Interface(traveller)

OTS-OnlineTravelService

Orchestrator

TOP-TravellerOnline Profile

and Record

OPS-Optimodal PlannerService

GDS-GDSsystems

OTD- Online travel

Data sources

I1: travelrequirements I2itinerary requests

Super API

I3: traveler profile details

I6 timetable data

GDS-GDSsystems

Super API

GDS-GDSsystems

Super API

I5x travel data & booking requests

TPS-Third party services

(ticketing, payment,…)

Super API

TPS-Third party services

(ticketing, payment,…)TPS-Third party

services (ticketing,

payment,…)

I1.1 itinerary details

I4x ticketing/payment transaction

I7: other travel information I2.1 proposed itinerary

Super API

Super API


35

XML Web services, etc., depending on the particular software technologies used by the Ecosystem participants. The central concept of this approach is that travel services expose APIs that are compatible with the ‘Super Travel API’ specification, allowing services to be composed and orchestrated with greater ease, as API incompatibilities have been removed. Travel services are accessed by route planners that create ‘optimodal’ travel plans. Table 9-1 lists the functional blocks and provides short descriptions, while Table 9-2 describes the interfaces to these functional blocks.

Table 9-1: Functional Module descriptions

Functional Block id

Functional Block name Description

UI User interface (Traveller) Functions of the User Interface allowing the traveller to interact with the travel service provider and consume services such as create itineraries, make bookings and payments, make changes and cancellations to his/her bookings, receive paperless tickets etc.

TOP Traveller Online Profile and Record

This is the online record of customer information containing both the basic profile of the customer (with basic preferences and other information the traveller has elected to share with service providers). It also contains descriptions of the customer itineraries with references to the status of the different itinerary segments (e.g. booked, ongoing, completed, cancelled, etc.).

OTS Online Travel Service Orchestrator

This is the central service that allow a customer to create book and manage multimodal journeys. This service relies on APIs that are compatible with the ‘Super Travel API’ provided by the systems of GDSs, travel operators etc. This allows services to be composed (orchestrated) and managed as a single trip on behalf of the traveller.

OPS Optimodal planner service

This is the service that allows itineraries to be created that meet the EuTravel Optimodality Framework criteria, i.e. synchronization between modes, passenger experience and rights, and environmental criteria (e.g. emissions for the total journey).

OTD Online Travel data resources

These are online resources such as travel operators’ timetables that are used by the service orchestrator and the planner service in order to make correct and feasible itineraries (e.g. with feasible transit routes and travel times). Timetable data are sent using industry standard formats such as GTFS.

GDS GDS (systems) These are the systems that allow booking of the various segments of the journeys (e.g. the air, sea, rail, hotel, etc. legs of the journey to be booked.) It is assumed that all these systems expose ‘Super Travel API’ compatible APIS, allowing the same call to be issued to the different systems by the service orchestrator, i.e. without the need for different API calls with all the overheads such as data conversions etc.

TPS Third party services These are the services used for ticketing and payment. Due to the proliferation of financial service providers, it


36

can be assumed that a single aggregator service is used as front end, allowing the traveller service to issue a single payment request which is then mapped to the different payment systems. The same principle can be applied to ticketing systems, although legal and other constraints as identified in the EuTravel Optimodality Framework must be addressed.

Table 9-2: Architectural interface descriptions

Interface id

Interface name Comments

I1 Travel requirements This allow a data structure containing travel requirements, to be issued by the User Interface Service to the Travel Service Orchestrator (OTS). It contains traveller identification information and permissions, allowing the OTS to access the traveller profile. Travel requirements can vary from source-destination to the inclusion of intermediate stops, as well as preferences to the mode of travel.

I1.1 Itinerary details OTS service passes the itinerary created by the Optimodal Planner to the User Interface for user approval or further modifications. This is displayed visually so the user can understand the proposal itinerary in terms of stops, durations and costs

I2 Itinerary request The itinerary request is a structure containing a constrained partial goal (i.e. travel from A to B with additional constraints provided by the traveller and the availability of services) and sent by OTS to OPS

I2.1 Proposed itinerary This is the itinerary returned by the OPS. It contains a number of plans that satisfy the requirements and constraints of the itinerary request, or null, if no such plans can be found. The plans are returned in order specified in the user preferences (e.g. shortest time, least cost, environmental impact, etc.)

I4x Ticketing/payment transaction

This is the interface exposed by the ticketing and payment service aggregator. This service provides a single interface for payment through different financial service providers (e.g. credit cards and other online payment systems) and manages the ticketing functionality, managing a virtual single ticket for the traveller, while in the background managing multiple ticketing systems

I5x Travel data & booking requests

This is the request sent by OTS to the GDS and other travel operator systems to obtain information about availability, cost and other details of a particular travel service (e.g. of flights from A to B). Because all these systems expose ‘Super Travel API’ compatible APIs, one single request is issued to all different systems.

I6 Timetable data Timetable data that are not provided by the booking systems of GDS/other operators need to be accessed from their sources online, through this interface. For


37

compatibility it is assumed that a single standard (e.g. GTFS) is supported, otherwise additional data conversions will have to be performed by the OTS.

I7 Other travel information This is an interface managed by the OTS that is responsible for handling any events related to the traveller’s itinerary, for example changes to timetable or cancellations of a travel service. OTS receives such notifications from GDS systems and presents it to the user so that he/she can take appropriate action if required

9.3 Super Travel API operations In this section we describe use cases for the API enabled Travel Ecosystem, based on the new capabilities made possible by the ‘Super Travel API’. It must be noted that the ‘Super Travel API’ is essentially a specification, one however that is based on semantics describing the key travel data and processes. All future travel systems and services are expected to expose APIs that are compatible with that single ‘Super Travel API’ specification. By facilitating API compatibility, the ‘Super Travel API’ will give rise to new business models and new types of travel services to emerge in the Ecosystem. The use cases are described in Table 9-3.

Table 9-3: Use cases of the Travel Ecosystem

Actor Use case API producer Register a new API: The API developers can utilise several software tools

and development platforms to specify, develop test and deploy APIs that are technically and semantically compatible with each other, enabling so interoperability of services across the Ecosystem. API developer tools for example include the semantic tools reviewed in Section 7.5.2, that allow the developers to map the concepts referenced by their own API to the concepts of the Common Information Model. To make all APIs semantically compatible and to overcome data model heterogeneity problems between APIs, the ‘Super Travel API’ references a Common Information Model that contains the common information entities of the travel domain and their relationships.

API mashup/integrator

Search for APIs: All APIs of travel services are catalogued in an API registry) that allows APIs to be searched, documented and invoked. Thus, the registry can be searched for APIs using unambiguous, semantically defined terms. This extends the capabilities of API registries of today such as for example Swagger(swagger.io).

Third party Value Adding Service provider

Invoke APIs as part of new services. Actors in this use case are developers of value adding services such as customized route planners, travel recommender services etc. With the use of the ‘Super Travel API’ therefore, new intermodal and multimodal travel services, both B2B and B2C oriented can be easily developed. Such services include ticketing, inventory management, itinerary management, CRM and other future ones. Service descriptions can be registered in a Marketplace for the travel industry, from where they can be discovered and used for the development of new innovative multimodal travel services and applications.


38

9.4 Common Information Model and EuTravel Ontology The Common Information Model is a data model that integrates the key data models of the travel industry segments (reviewed in Section 5) using the EuTravel travel ontology (Section 7) and provides a neutral, implementation independent view of the travel domain and allows different API implementations to interoperate. The Common Information Model represents a bottom up effort of EuTravel partners, driven by existing available data formats and standards for air, coach, rail and ferry. It utilizes semantic technologies and ontologies to abstract and unify such data formats. By applying a bottom-up pragmatic approach the Common Information Model does not require wide industry consensus, from the start, that could prove infeasible to reach in the lifespan of the EuTravel project. The EuTravel unifying ontology includes the terminology (classes, properties, axioms) for modeling any multi modal travel including rail, ferry, air, coach, etc. The approach for developing the EuTravel unifying ontology was to reuse as much as possible existing vocabularies, schemas and ontologies for the travel domain as well as to be align with existing standards in the domain. We deliver our EuTravel unifying ontology as a set of extensions for a very popular vocabulary on the Web, namely Schema.org. Schema.org introduced in section 7.3.2, is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond. It is sponsored by the four largest search engines i.e. Google, Bing, Yahoo and Yandex. It is possible to provide schema.org extension for various travel models i.e. rail, ferry, air, coach, and bike, that extend also the Common Information Model to cater for different travel modes.

9.5 API subject areas As per Figure 9-3, the API is organised in different logical subsets addressing:

• Intermodality in the different legs of a journey support for planning the complete itinerary including interchanges/transit points.

• Synchronisation between the different legs, particularly from different modes;

• Booking and ticketing, supporting financial matters of the transport contract such as refunds, compensations, attributions of liabilities etc., based on commercial. relations between agents, travel service providers/operators etc.

• Passenger information including travel preferences, for identification and contacting of participating parties, shared passenger information (Passenger Name Record).

Figure 9-3: Super API subject areas

Intermodal API

Intermodal Network Model

Subject Area

Travel Operations Synchronisation

Subject Area

Booking Financial Management Subject Area

Passenger Name Record Data Subject Area


39

9.6 API Operations The following tables (Table 9-4, Table 9-5) present the main domain entities of the Common Information Model organised under travel modes. Detailed contents of the model will be made available in forthcoming EuTravel deliverable (D2.2: Ecosystem Specification and Prototype Implementation). Table 9-6 lists the main REST operations currently supported by the API. The detailed specification of these operations is listed in Appendix 1.

Table 9-4: Main subjects and entities of EuTravel’s Common Information Model (1)

Subject areas

AirTransport MarineTransport RailTransport TerrestrialTransport2

Clas

ses

Airport Port Train Station Flight Place Vehicle Place Airline MarineAgency TrainStation TerrestrialTransportation Place Organization Place Vehicle Organization ShippingLine RailLine TerrestrialTransportationType Aircraft ItinerarySegment RailAgency TerrestrialLines Vehicle Ship Organization ItinerarySegment ItinerarySegment Vehicle ItinerarySegment StationType MarineSegment RailSegment TerrestrialSegment Fare Fare LineDirection

Table 9-5: Main subjects and entities of EuTravel’s Common Information Model (2)

Subject areas

Trip Location Organization ApplicationContext

Cl

asse

s

Itinerary PostalAddress ContactInfromation Application ItinerarySegment Place Person ApplicationSetting GeoCoordinates GeoCoordinates PostalAddress Vehicle GeoBoundaries Fare LocationType ItinerarySegmentType Place

Table 9-6: Main Operations of the Super API

Operation Description POST /api/EuTravelService/GetLegsDetails

Returns the details of a journey leg such as origin, destination, dates/times, fare price

GET /api/EuTravelService/GetSolutionsForLeg

Returns all the travel modes available to use for a journey leg

GET /api/EuTravelService/GetSolutionDetails

Returns all details for each travel mode solution in each leg such as duration, fare price

POST /api/EuTravelService/BookingConfirmation

Confirmation of a booking for a journey leg including details of passengers

2 TerrestrialTransport – It refers to the modes of transport that operate on road or tracks that are not intercity or cross country rail networks


40

Operation Description POST /api/EuTravelService/PlanningInternal

Information about all solutions for a proposed journey and their attributes- to be used by a route planner

POST /api/EuTravelService/ShoppingInternal

Booking and ticketing information (e.g. whether the leg can be ticketed in advance) for each journey leg

GET /api/EuTravelService/RoutesCount

A count of all solutions available per travel mode

GET /api/EuTravelService/KPIs

Administrative information for the travel APIs accessed by the Super API

GET /api/EuTravelService/KPI

Admin information per individual API called

GET /api/EuTravelService/simpledoortodoor

Returns the total travel time (door to door) for a journey

GET /api/EuTravelService/doortodoor

Breakdown of travel time and related parameters per journey leg, used by the route planner

GET /api/EuTravelService/NearbyStations

Returns list of terminals (air, rail, sea) in proximity to a location.

POST /api/EuTravelService/PlanningGraph

Detailed information per route for planning, ticketing and UI (display) purposes

POST /api/EuTravelService/PlanningDemokritos

A planned route returned by a specific route planner module (by partner NCSRD)

It should be mentioned that the implementation of the prototype Super API (in task T2.2) will use APIs and data sources available from project partners and EuTravel Forum members, thus covering airplanes, trains (speed rail, conventional rail, light rai), ferries, and long-distance coach and local transport services, including metro. In that respect the Common Information Model (CIM- built following the bottom up approach), includes the subjects and entities of the aforementioned scheduled transport modes. The EuTravel architecture and design though, enables the extension of the CIM, which is an ever-evolving domain model, to support any mode of transport such as local bus, demand-responsive transport modes (e.g. Shuttle bus, taxi, car-sharing, car-pooling, car-hire, bike-sharing, bike-hire) and in general any transportation mode in both urban or rural areas. Apart from transportation, new classes can be added to the CIM related to hotels, parking, car hiring services etc., enabling the integration of such services. The operation of the Super API depends apparently on the availability of such services (through APIs) by the operators.

10 Conclusions, Discussion, and Recommendations

10.1 Main Findings of Task 2.1 The objectives set for this task has been successfully met. The main findings of Task 2.1 are summarised as follows:

• The de jure travel API standards of today are not suitable for interoperating between travel modes and related market sectors.

• There are myriad de facto API standards in use, but they do not interoperate.


41

• The travel industry needs a better API technology (i.e. based on semantic technologies), as the mechanism of interoperating with travel and transport, hospitality and other service operators and creating seamless optimodal services.

Optimodality in the context of EuTravel refers to the optimal method of integrating multiple means of travel information, such as availability, fares or even legal considerations, by abstracting this information through the Common Information Model and, as a result, to extract optimised results for a travel query from point A to point B. Key part of the realisation of the project’s vision is the “Super Travel API” or “API of APIs” which is a single configurable API for multimodal travel, that provides the necessary common framework to unify heterogeneous APIs of several modes, under a common collaboration ground. The modelling and implementation approach of the EuTravel Ecosystem is based on the development of the Common Information Model (CIM), a data model that integrates the key data structures of the travel industry segments (D1.4, D2.2). Building a Universal Travel API is a challenging task requiring both ‘top down’ and ‘bottom up’ design work. Semantic technologies such as an ontology and common data model can help in understanding the semantics of the different APIs. Thus, a high-level IT architecture addressing the above has been proposed, centred on a universal Travel API, utilising ongoing data standardisation work, semantic technologies such as travel ontologies, and advanced software design techniques. In turn, the high-level architecture described in this section will guide detailed design and implementation of architectural components defined in diagram 9.2, under task 2.2, namely:

• API Gateways (access/entry points) incorporating advanced security and data quality services

• Service registry, service discovery implementing the API specification listed in Table 9-3 to

Table 9-6.

• Real time engine for dynamic, spontaneously forming of Optimodal itineraries.

• Semantically annotated services of participating travel service providers.

Some technical obstacles regarding the realisation of the high-level ‘Super Travel API’ architecture are discussed below. More obstacles and challenges are expected to be discovered as the actual work of integrating data, services and existing travel APIs in to the EuTravel prototype system progresses. The first obstacle is related to the quality of the Common Information Model and to how well it models the semantics of the travel domain. It is expected that the Common Information Model will be refined as actual experience is gained from incorporating real travel APIs. The second technical obstacle is the real time performance of the system as a whole, i.e. the ability to connect to existing APIs, retrieve and compose data and create optimodal itineraries within acceptable response times. Towards this, experience and solutions from designing other types of online transactional systems will be sought. There are however, non-technical obstacles and inhibitors to the adoption of the Super Travel API, as discussed in the following section.


42

10.2 Inhibitors for the acceptance of the ‘Super Travel API’ Approach It is unlikely that a single organisation will have the capacity to tap into this wealth of travel data, even if it owns such data outright. A key business enabler of the Ecosystem is for large data set owners to make available such data to third parties through the ‘Super Travel API’ and special agreements, or even through the formation of new organisations dedicated to that (e.g. through partnerships between travel operators and IT specialists in cloud and big data). Also, further industry collaboration will be required to define and agree trans-modal transport ontologies for conversion/translation mechanisms to combat interoperability issues (co-modal and intermodal cases, and also to agree on industry compatible travel entitlement issuance and consumption management standards in order to encourage intermodality in the marketplace. Finally, acceptance of the ‘Super Travel API’ by software developers will be predicated upon how simple it is to use, how easy to access, how fast it is, and how well documented it is.

10.3 Potential impact of the proposed Universal API on the Travel Industry The ‘Super Travel API’ is expected to stimulate the market for intermodal/multimodal travel services. However, for the sort of modal shift, envisaged by the Project, to occur, a merge of the current, silo structured, transport markets (each with their distinct and different type of retail outlets) needs to occur. A critical mass of travel retail outlets is capable of offering comprehensive European Transport content for search, planning, booking, purchase and ticketing. The project envisages the Travel Services marketplace, a generic ‘one-stop-shop’ capability (fuelled by the Universal Travel API) where the traditionally very manual search, plan and purchase activities can be fully automated, eliminating the risk and effort normally attached to the manual execution of such activities. This generic one-stop-shop capability in the market place, places a significant role on the 3rd party retailer (online travel agency- OTA) because dedicated Travel Service Provider (TSP) retail outlets (such as commercial airlines, rail companies etc.) will, logically, only ever offer multimodal services which are complementary to the main TSP products and services on offer, but not those which are competitive with them. Our universal travel API approach will enable travel industry participants to exploit new businesses and revenue models:

• Direct revenue: For example, with new web APIs for purchasing travel and ancillary services.

• Indirect revenue: For example, earning a commission by providing aggregation services to

other travel service providers.

• Cost saving: For example, through new mobile apps that enable self-service in order to scale

down an expensive customer service.

• Marketing: By putting product information about their products and services in front of a

wider customer base.

While the proposed ‘Super Travel API’ may not disrupt existing business models, it could shift the balance of power towards those organisations that can tap into travel service consumer data, turning such data into knowledge and insight. Big travel operators and travel service providers are currently the main holders of such data, with secondary but important sources of such data include web sites and forums such as Trip advisor. The advent of online travel has created new business models that altered the relationships among the key players making them less interdependent and more competitive. APIs can provide the basis for a thriving ecosystem in the travel industry. Analysts predict that by the year 2020 there will be a permanently established network of collaborating operators in the travel industry [45], that will be able to deliver optimal customised


43

services to cater for any type of specialised multimodal travel needs, where specialisation is defined in terms of customer unique needs in terms of one or more of mobility, origin destination route and mode of travel, including eco criteria. These services will be delivered through the portals and web sites of current and future travel operators which include traditional travel agencies, transport operators servicing directly the public, and new forms of specialist travel agents. The main difference between the current and future play of customised optimodal travel, will be the ease with which new players can enter the market, or existing ones being able to adopt their current offerings. The new market will also be driven directly by the consumers and be limited not by the technological capabilities of the IT systems of the industry, but only by what is physically possible. The travel industry Ecosystem as proposed in this report will grow through IT (API) enablement, i.e. through better linking and overhauling current IT using APIs, through demand driven IT services and through opening up supply and demand data using Big Data, Linked Data and Cloud technologies, all underpinned by a common API approach. With access to a wider variety of more readily available travel supplier information, travel agencies will be able to better serve their clients. For the GDSs, also the new API standard will afford new opportunities as well. Developing and maintaining current messaging standards is expensive and uses highly specialized programming. An API-centred Ecosystem can create a win-win situation, in the sense that it will not threaten to disrupt established business models, partnerships and alliances: it will tap into a largely unexplored and emerging market of travel consumers with new tastes expectations and requirements. It will also stimulate demand in the sector by creating novel travel package offerings. This report sets the architectural grounds for prototyping and validating in experimental settings the premises of the ‘Super Travel API’ and provides input to T2.2 Ecosystem Specification and Prototype Implementation (D2.2). Some aspects of the ‘front end’ – user facing interfaces and services are mentioned where necessary for completeness and coherence, but discussed in further detail in D2.3, D3.2 and D3.3, while Value Added Services of the EuTravel ecosystem are discussed in D2.4.


44

11 Bibliography

[1] All Ways Travelling ‘To develop and validate a European passenger transport information and booking system across transport modes’. All Ways Travelling Consortium, Final report, June 17th 2014

[2] White Paper Roadmap to a Single Transport Area – Towards a competitive and resource efficient transport system, COM(2011)0144 final.

[3] Briscoe, Gerard and Marinos, Alexandros (2009), Digital ecosystems in the clouds: towards community cloud computing. In: IEEE, (corp. ed.) 2009 3rd IEEE International Conference on Digital Ecosystems and Technologies (Dest 2009).

[4] Digital-Age Transportation: The Future of Urban Mobility. Deloitte Press, 2013. [5] Amadeus (2012a). The Always-Connected Traveler: How Mobile Will Transform the Future of

Air Travel. [6] Tom Jones, Amadeus: Paper supporting technology research on an: ‘Airline-compatible’ Travel

Entitlement Issuance and Consumption Management Standard, February 2016 [7] Harrell Associates. The Internet Travel Industry: What Consumers Should Expect and Need to

Know, and Options for a Better Marketplace. 2002 [8] EUROPEAN COMMISSION Study of passenger transport by coach Final Report June 2009 [9] Moshe Kaplan- the API Economy http://www.slideshare.net/RockeTier/the-api-economy-

42779822 [10] Instant Mobility Project (http://www.instant-mobility.com/) [11] Data transfers outside the EU (http://ec.europa.eu/justice/data-protection/international-

transfers/index_en.htm) [12] European Parliament and Council Directive 95/46/EC, Protection of personal data (http://eur-

lex.europa.eu/legal-content/EN/TXT/HTML/?uri=URISERV:l14012&from=EN) [13] Tony Williams, Pharos DataCom: White paper on ‘Ferry API Standards’, 2015 [14] D. Brickley, and R.V. Guha: RDF vocabulary description language 1.0: RDF schema. W3C

Recomendation. Tech. rep. (2004). Available at http://www.w3.org/TR/rdf-schema/ [15] S. Harris and A. Seaborne, “SPARQL 1.1 Query Language,” W3C Working Draft, no. May. W3C,

2010. [16] D.L. McGuinness, and F. van Harmelen: Owl web ontology language overview (february 2004).

Technical report, W3C (2004). Http://www.w3.org/TR/owl-features/ [17] API gateway pattern - Microservices.io microservices.io/patterns/apigateway.html [18] B. Motik, B.C. Grau, I. Horrocks, Z. Wu, A. Fokoue, and C. Lutz: OWL 2 web ontology language

profiles. Recommendation 27 October 2009, W3C (2009) [19] D. Martin, M. Burstein, E. Hobbs, O. Lassila, D. Mcdermott, S. Mcilraith, S. Narayanan, B. Parsia,

T. Payne, E. Sirin, N. Srinivasan, and K. Sycara, “OWL-S: Semantic Markup for Web Services,” 2004.

[20] D. Fensel, H. Lausen, A. Polleres, J. de Bruijn, M. Stollberg, D. Roman, and J. Domingue. 2006. Enabling Semantic Web Services: The Web Service Modeling Ontology. Springer-Verlag New York, Inc., Secaucus, NJ, USA.

[21] J. Kopecky, T. Vitvar, C. Bournez, and J. Farrell, “SAWSDL: Semantic Annotations for WSDL and XML Schema,” IEEE Internet Computing, vol. 11, no. 6, pp. 60–67, 2007.

[22] T. Vitvar, J. Kopecky, J. Viskova, and D. Fensel, “WSMO-lite annotations for web services,” Exchange Organizational Behavior Teaching Journal, vol. 5021, pp. 674–689, 2008.

http://www.slideshare.net/RockeTier/the-api-economy-42779822

http://www.slideshare.net/RockeTier/the-api-economy-42779822

http://ec.europa.eu/justice/data-protection/international-transfers/index_en.htm

http://ec.europa.eu/justice/data-protection/international-transfers/index_en.htm

http://www.w3.org/TR/rdf-schema/

http://www.w3.org/TR/owl-features/


45

[23] Charfi, B. Schmeling, F. Novelli, H. Witteborg, and U. Kylau, An Overview of the Unified Service Description Language, vol. 0. IEEE, 2010, pp. 173–180.

[24] HYDRA viewed at http://www.hydra-cg.com/spec/latest/core/#introduction [25] Berners Lee. The Semantic Web A new form of Web content that is meaningful to computers

will unleash a revolution of new possibilities. Scientific American: Feature Article: The Semantic Web: May 2001

[26] Nigel Shadbolt and Wendy Hall, Tim Berners-Lee. The Semantic Web Revisited. IEEE INTELLIGENT SYSTEMS, May/June 2006

[27] Resource Description Framework (RDF), viewed at https://www.w3.org/TR/rdf-concepts/ [28] TAP-TSI initiative, viewed at http://tap-tsi.uic.org/ [29] FerryGateway Initiative, viewed at http://ferrygateway.org/ [30] IT2Rail Project, http://www.it2rail.eu/ [31] Shift2Rail Programme – Innovation Programme 4 (IP4), viewed at

http://www.shift2rail.org/ip4/ [32] Opentavel Standard, viewed at http://opentravel.org/ [33] Rule Interchange Format (RIF), viewed at

https://en.wikipedia.org/wiki/Rule_Interchange_Format [34] Uniform Resource Identifier (URI), viewed at

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier [35] Extensible Markup Language (XML), viewed at https://www.w3.org/XML/ [36] Document Type Definition (DTD), viewed at

https://en.wikipedia.org/wiki/Document_type_definition [37] XML Schema, viewed at https://www.w3.org/XML/Schema [38] GTFS Specification, viewed at http://vocab.gtfs.org/ [39] SWAT Project, viewed at http://swatproject.org [40] Transit vocabulary, viewed at https://github.com/iand/vocab-transit [41] General Transit Feed Specification, https://developers.google.com/transit/gtfs/reference [42] TAGA Framework, viewed at http://taga.sourceforge.net/ [43] Travel Guides, viewed at https://sites.google.com/site/ontotravelguides/Home [44] KM4C, viewed at http://lov.okfn.org/dataset/lov/vocabs/km4c [45] T. Ying1, W.C. Norman, and Y. Zhou, Online Networking in the Tourism Industry: A

Webometrics and Hyperlink Network Analysis Journal of Travel Research 2016, Vol. 55(1) 16–33

[46] Unified Service Description Language (USDL), viewed at http://linked-usdl.org/

http://www.hydra-cg.com/spec/latest/core/#introduction

https://www.w3.org/TR/rdf-concepts/

http://ferrygateway.org/

http://www.it2rail.eu/

http://www.shift2rail.org/ip4/

http://opentravel.org/

https://www.w3.org/XML/Schema

http://vocab.gtfs.org/

http://swatproject.org/

http://lov.okfn.org/dataset/lov/vocabs/km4c


46

Appendices 12 Appendix 1: Super API Swagger JSON Specification

"swagger": "2.0" "info": "version": "v1" "title": "EuTravel2.Web" "host": "EuTravel-api-staging.clmsuk.com" "schemes": ["http"] "paths": "/api/BusinessAnalytics/airsegmentsinsoluion": "get": "tags": ["BusinessAnalytics"] "summary": "" "operationId": "BusinessAnalytics_AirSegmentsInSolution" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/System.Object" "deprecated": false "/api/BusinessAnalytics/marinesegmentinsolution": "get": "tags": ["BusinessAnalytics"] "summary": "" "operationId": "BusinessAnalytics_MarineSegmentsInSolution" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/System.Object" "deprecated": false "/api/BusinessAnalytics/railsegmentsinsolution": "get": "tags": ["BusinessAnalytics"] "summary": "" "operationId": "BusinessAnalytics_RailSegmentsInSolution" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/System.Object"


47

"deprecated": false "/api/BusinessAnalytics/shoppingrequestsinpast": "get": "tags": ["BusinessAnalytics"] "summary": "" "operationId": "BusinessAnalytics_ShoppingRequestsInPast" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "responses": "200": "description": "OK" "schema": "type": "object" "additionalProperties": "format": "int32" "type": "integer" "deprecated": false "/api/BusinessAnalytics/multimodalsolutionsselected": "get": "tags": ["BusinessAnalytics"] "summary": "" "operationId": "BusinessAnalytics_MultiModalSolutionsSelected" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/System.Object" "deprecated": false "/api/EuTravelService/GetLegsDetails": "post": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_Planning" "consumes": ["application/json" "text/json" "application/xml" "text/xml" "application/x-www-form-urlencoded"] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "requestWrapper" "in": "body" "required": true "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RequestWrapperDTO" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LegsDetailsResponseDTO"


48

"deprecated": false "/api/EuTravelService/GetSolutionsForLeg": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_Shopping" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "legId" "in": "query" "required": false "type": "integer" "format": "int64" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GetSolutionsForLegResponseDTO" "deprecated": false "/api/EuTravelService/GetSolutionDetails": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_Pricing" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "legId" "in": "query" "required": false "type": "integer" "format": "int64" "name": "solutionId" "in": "query" "required": false "type": "integer" "format": "int64" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GetSolutionDetailsResponseDTO" "deprecated": false


49

"/api/EuTravelService/BookingConfirmation": "post": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_Booking" "consumes": ["application/json" "text/json" "application/xml" "text/xml" "application/x-www-form-urlencoded"] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "data" "in": "body" "required": true "schema": "$ref": "#/definitions/EuTravel2.Web.Code.WebApi.EuTravelServiceBookingDto" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.BookingConfirmationDTO" "deprecated": false "/api/EuTravelService/PlanningInternal": "post": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_PlanningInternal" "consumes": ["application/json" "text/json" "application/xml" "text/xml" "application/x-www-form-urlencoded"] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "requestWrapper" "in": "body" "required": true "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RequestWrapperDTO" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LegsDetailsResponseDTO" "deprecated": false "/api/EuTravelService/ShoppingInternal": "post": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_ShoppingInternal" "consumes": ["application/json" "text/json" "application/xml" "text/xml" "application/x-www-form-urlencoded"] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "sq"


50

"in": "body" "required": true "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ShoppingQueryDTO" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ShoppingResponseDTO" "deprecated": false "/api/EuTravelService/RoutesCount": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_RoutesCount" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RoutesCountResponseDTO" "deprecated": false "/api/EuTravelService/KPIs": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_KPIs" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.KPIsResponseDTO" "deprecated": false "/api/EuTravelService/KPI": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_KPI" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "KPICode" "in": "query" "required": false


51

"type": "string" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.KPIsResponseDTO" "deprecated": false "/api/EuTravelService/simpledoortodoor": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_SimpleDoorToDoor" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "time" "in": "query" "required": false "type": "string" "name": "date" "in": "query" "required": false "type": "string" "name": "maxWalkDistance" "in": "query" "required": false "type": "integer" "format": "int32" "name": "fromPlace" "in": "query" "required": false "type": "string" "name": "toPlace" "in": "query" "required": false "type": "string" "name": "showIntermediateStops" "in": "query" "required": false "type": "boolean" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.ExternalStructs.NCSRDDoorToDoor.NCSRDDoorToDoorSimpleRoot" "deprecated": false "/api/EuTravelService/doortodoor": "get": "tags": ["EuTravelService"]


52

"summary": "" "operationId": "EuTravelService_DoorToDoor" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "time" "in": "query" "required": false "type": "string" "name": "date" "in": "query" "required": false "type": "string" "name": "maxWalkDistance" "in": "query" "required": false "type": "integer" "format": "int32" "name": "fromPlace" "in": "query" "required": false "type": "string" "name": "toPlace" "in": "query" "required": false "type": "string" "name": "showIntermediateStops" "in": "query" "required": false "type": "boolean" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.NCSRDDoorToDoorRootDTO" "deprecated": false "/api/EuTravelService/NearbyStations": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_NearbyStations" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "trainStation" "in": "query" "required": false "type": "boolean" "name": "airport" "in": "query" "required": false "type": "boolean"


53

"name": "port" "in": "query" "required": false "type": "boolean" "name": "latitude" "in": "query" "required": false "type": "number" "format": "double" "name": "longitude" "in": "query" "required": false "type": "number" "format": "double" "name": "distance" "in": "query" "required": false "type": "number" "format": "double" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.StationResponseDTO" "deprecated": false "/api/EuTravelService/PlanningGraph": "post": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_PlanningInternalGraph" "consumes": ["application/json" "text/json" "application/xml" "text/xml" "application/x-www-form-urlencoded"] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "requestWrapper" "in": "body" "required": true "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RequestWrapperDTO" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LegsDetailsResponseDTO" "deprecated": false "/api/EuTravelService/PlanningDemokritos": "post": "tags": ["EuTravelService"] "summary": ""


54

"operationId": "EuTravelService_PlanningInternalDemokritos" "consumes": ["application/json" "text/json" "application/xml" "text/xml" "application/x-www-form-urlencoded"] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "requestWrapper" "in": "body" "required": true "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RequestWrapperDTO" ] "responses": "200": "description": "OK" "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LegsDetailsResponseDTO" "deprecated": false "/api/EuTravelService/Plan": "post": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_Plan" "consumes": ["application/json" "text/json" "application/xml" "text/xml" "application/x-www-form-urlencoded"] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "planningRequest" "in": "body" "required": true "schema": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RequestWrapperDTO" ] "responses": "200": "description": "OK" "schema": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SolutionDTO" "deprecated": false "/api/EuTravelService/Shop": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_Shop" "consumes": [] "produces": [] "responses": "204": "description": "No Content"


55

"deprecated": false "/api/EuTravelService/GetTravelOptions": "get": "tags": ["EuTravelService"] "summary": "" "operationId": "EuTravelService_GetTravelOptions" "consumes": [] "produces": ["application/json" "text/json" "application/xml" "text/xml"] "parameters": [ "name": "legId" "in": "query" "required": false "type": "integer" "format": "int64" "name": "solutionId" "in": "query" "required": false "type": "integer" "format": "int64" ] "responses": "200": "description": "OK" "schema": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GetSolutionDetailsResponseDTO" "deprecated": false "definitions": "System.Object": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.RequestWrapperDTO": "type": "object" "properties": "LocationPairs": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LocationPairDTO" "UserPreferences": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.UserPreferencesDTO" "NumberOfAdults": "format": "int32" "type": "integer" "NumberOfChildren": "format": "int32" "type": "integer" "NumberOfInfants":


56

"format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.LocationPairDTO": "type": "object" "properties": "OriginLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LocationInputDTO" "DestinationLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LocationInputDTO" "DepartureDate": "type": "string" "ArrivalDate": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.UserPreferencesDTO": "type": "object" "properties": "TravelDuration": "format": "int32" "type": "integer" "Distance": "format": "int32" "type": "integer" "PriceOrdering": "type": "boolean" "SpecialAssistance": "type": "boolean" "CarbonEmission": "type": "boolean" "MaximumReturnedSolutions": "format": "int32" "type": "integer" "PreferredMeansOfTransport": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.LocationInputDTO": "type": "object" "properties": "Lat": "format": "double" "type": "number" "Long": "format": "double" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.LegsDetailsResponseDTO": "type": "object"


57

"properties": "Legs": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LegDTO" "Error": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ErrorDTO" "EuTravel2.Services.EuTravelService.DataContracts.LegDTO": "type": "object" "properties": "Id": "format": "int32" "type": "integer" "LegOrder": "format": "int32" "type": "integer" "TravelDate": "format": "date-time" "type": "string" "NumberOfSolutions": "format": "int32" "type": "integer" "Fare": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FareDTO" "Preferences": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.PreferenceDTO" "OriginLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LocationDTO" "DestinationLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LocationDTO" "Solutions": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SolutionDTO" "ArrivalDate": "format": "date-time" "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.ErrorDTO": "type": "object" "properties": "Code": "type": "string" "Description": "type": "string"


58

"EuTravel2.Services.EuTravelService.DataContracts.FareDTO": "type": "object" "properties": "TotalPrice": "format": "double" "type": "number" "Description": "type": "string" "Charges": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ChargeDTO" "TaxAmount": "format": "double" "type": "number" "BasePrice": "format": "double" "type": "number" "Currency": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.CurrencyDTO" "EuTravel2.Services.EuTravelService.DataContracts.PreferenceDTO": "type": "object" "properties": "PreferenceValue": "type": "string" "PreferenceType": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.PreferenceTypeDTO" "EuTravel2.Services.EuTravelService.DataContracts.LocationDTO": "type": "object" "properties": "Name": "type": "string" "MapUrl": "type": "string" "GeoCoordinates": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "EuTravel2.Services.EuTravelService.DataContracts.SolutionDTO": "type": "object" "properties": "Id": "format": "int32" "type": "integer" "Source": "type": "string"


59

"MarineSegments": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.MarineSegmentDTO" "TerrestrialSegments": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TerrestrialSegmentDTO" "RailSegments": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RailSegmentDTO" "FlightSegments": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FlightSegmentDTO" "TerrestrialStart": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TerrestrialLocationPairDTO" "TerrestrialEnd": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TerrestrialLocationPairDTO" "EuTravel2.Services.EuTravelService.DataContracts.ChargeDTO": "type": "object" "properties": "ChargeType": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ChargeTypeDTO" "EuTravel2.Services.EuTravelService.DataContracts.CurrencyDTO": "type": "object" "properties": "Name": "type": "string" "ISO4217Code": "type": "string" "Symbol": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.PreferenceTypeDTO": "type": "object" "properties": "Code": "type": "string" "Description": "type": "string"


60

"EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO": "type": "object" "properties": "Latitude": "format": "double" "type": "number" "Longitude": "format": "double" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.MarineSegmentDTO": "type": "object" "properties": "ItinerarySequenceNumber": "format": "int32" "type": "integer" "MarineRoute": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.MarineRouteDTO" "DateBooked": "format": "date-time" "type": "string" "DateCancelled": "format": "date-time" "type": "string" "Status": "format": "int32" "enum": [0 1 2 3] "type": "integer" "TermsAndConditions": "type": "string" "ExternalIdentifier": "type": "string" "Fare": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FareDTO" "DepartureDateTime": "format": "date-time" "type": "string" "ArrivalDateTime": "format": "date-time" "type": "string" "TravelTime": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.TerrestrialSegmentDTO": "type": "object" "properties": "ItinerarySequenceNumber":


61

"format": "int32" "type": "integer" "Origin": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.StationDTO" "Destination": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.StationDTO" "TerrestrialTrip": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TerrestrialTripDTO" "DateBooked": "format": "date-time" "type": "string" "DateCancelled": "format": "date-time" "type": "string" "Status": "format": "int32" "enum": [0 1 2 3] "type": "integer" "TermsAndConditions": "type": "string" "ExternalIdentifier": "type": "string" "Fare": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FareDTO" "DepartureDateTime": "format": "date-time" "type": "string" "ArrivalDateTime": "format": "date-time" "type": "string" "TravelTime": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.RailSegmentDTO": "type": "object" "properties": "RailRoute": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RailRouteDTO" "DateBooked": "format": "date-time" "type": "string" "DateCancelled": "format": "date-time" "type": "string" "Status": "format": "int32" "enum": [0 1 2 3] "type": "integer"


62

"TermsAndConditions": "type": "string" "ExternalIdentifier": "type": "string" "Fare": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FareDTO" "DepartureDateTime": "format": "date-time" "type": "string" "ArrivalDateTime": "format": "date-time" "type": "string" "TravelTime": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.FlightSegmentDTO": "type": "object" "properties": "ItinerarySequenceNumber": "format": "int32" "type": "integer" "FlightRoute": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FlightRouteDTO" "UpdatedAt": "format": "date-time" "type": "string" "FlightTime": "format": "int32" "type": "integer" "DateBooked": "format": "date-time" "type": "string" "DateCancelled": "format": "date-time" "type": "string" "Status": "format": "int32" "enum": [0 1 2 3] "type": "integer" "TermsAndConditions": "type": "string" "ExternalIdentifier": "type": "string" "Fare": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FareDTO" "DepartureDateTime": "format": "date-time"


63

"type": "string" "ArrivalDateTime": "format": "date-time" "type": "string" "TravelTime": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.TerrestrialLocationPairDTO": "type": "object" "properties": "OriginLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "DestinationLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "EuTravel2.Services.EuTravelService.DataContracts.ChargeTypeDTO": "type": "object" "properties": "Id": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.MarineRouteDTO": "type": "object" "properties": "ETicketability": "type": "boolean" "Active": "type": "boolean" "OnTimePercentage": "format": "double" "type": "number" "Agency": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.MarineAgencyDTO" "Ship": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FerryDTO" "Origin": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.PortDTO" "Destination": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.PortDTO" "Duration": "format": "int32" "type": "integer" "Remarks": "type": "string" "Distance": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DistanceDTO"


64

"CO2Emissions": "format": "int32" "type": "integer" "Datasource": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DatasourceDTO" "PriceRangeMax": "format": "double" "type": "number" "PriceRangeMin": "format": "double" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.StationDTO": "type": "object" "properties": "GTFSId": "type": "string" "StationType": "format": "int32" "enum": [0 1] "type": "integer" "WheelchairAccess": "format": "int32" "enum": [0 1 2] "type": "integer" "Name": "type": "string" "MapUrl": "type": "string" "GeoCoordinates": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "EuTravel2.Services.EuTravelService.DataContracts.TerrestrialTripDTO": "type": "object" "properties": "GTFSId": "type": "string" "Headsign": "type": "string" "ShortName": "type": "string" "Direction": "format": "int32" "enum": [0 1] "type": "integer" "TerrestrialRoute": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TerrestrialRouteDTO"


65

"Duration": "format": "int32" "type": "integer" "Remarks": "type": "string" "Distance": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DistanceDTO" "CO2Emissions": "format": "int32" "type": "integer" "Datasource": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DatasourceDTO" "PriceRangeMax": "format": "double" "type": "number" "PriceRangeMin": "format": "double" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.RailRouteDTO": "type": "object" "properties": "OriginStation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TrainStationDTO" "DestinationStation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TrainStationDTO" "OperatingAgency": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.RailAgencyDTO" "Duration": "format": "int32" "type": "integer" "Remarks": "type": "string" "Distance": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DistanceDTO" "CO2Emissions": "format": "int32" "type": "integer" "Datasource": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DatasourceDTO" "PriceRangeMax": "format": "double" "type": "number" "PriceRangeMin": "format": "double" "type": "number"


66

"EuTravel2.Services.EuTravelService.DataContracts.FlightRouteDTO": "type": "object" "properties": "ETicketability": "type": "boolean" "OnTimePercentage": "format": "double" "type": "number" "FlightNumber": "type": "string" "Origin": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.AirportDTO" "Destination": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.AirportDTO" "OperatingAirline": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.AirlineDTO" "MarketingAirline": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.AirlineDTO" "Aircraft": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.AircraftDTO" "Duration": "format": "int32" "type": "integer" "Remarks": "type": "string" "Distance": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DistanceDTO" "CO2Emissions": "format": "int32" "type": "integer" "Datasource": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DatasourceDTO" "PriceRangeMax": "format": "double" "type": "number" "PriceRangeMin": "format": "double" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.MarineAgencyDTO": "type": "object" "properties": "Description": "type": "string" "Name": "type": "string" "Url": "type": "string"


67

"Contact": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ContactInformationDTO" "OperatingTimezone": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TimezoneDTO" "EuTravel2.Services.EuTravelService.DataContracts.FerryDTO": "type": "object" "properties": "SeatAssignable": "type": "boolean" "RegistrationID": "type": "string" "Name": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.PortDTO": "type": "object" "properties": "PharosCode": "type": "string" "Name": "type": "string" "MapUrl": "type": "string" "GeoCoordinates": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "EuTravel2.Services.EuTravelService.DataContracts.DistanceDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.DatasourceDTO": "type": "object" "properties": "Name": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.TerrestrialRouteDTO": "type": "object" "properties": "GTFSId": "type": "string" "Name": "type": "string" "ShortName": "type": "string" "RouteType":


68

"format": "int32" "enum": [0 1 2 3 4 5 6 7] "type": "integer" "TerrestrialAgency": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TerrestrialAgencyDTO" "EuTravel2.Services.EuTravelService.DataContracts.TrainStationDTO": "type": "object" "properties": "Name": "type": "string" "MapUrl": "type": "string" "GeoCoordinates": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "EuTravel2.Services.EuTravelService.DataContracts.RailAgencyDTO": "type": "object" "properties": "SilverRailCode": "type": "string" "Name": "type": "string" "Url": "type": "string" "Contact": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ContactInformationDTO" "OperatingTimezone": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TimezoneDTO" "EuTravel2.Services.EuTravelService.DataContracts.AirportDTO": "type": "object" "properties": "IATACode": "type": "string" "Name": "type": "string" "MapUrl": "type": "string" "GeoCoordinates": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "EuTravel2.Services.EuTravelService.DataContracts.AirlineDTO": "type": "object" "properties": "Description":


69

"type": "string" "BlackListed": "type": "boolean" "IATACode": "type": "string" "Name": "type": "string" "Url": "type": "string" "Contact": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ContactInformationDTO" "OperatingTimezone": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TimezoneDTO" "EuTravel2.Services.EuTravelService.DataContracts.AircraftDTO": "type": "object" "properties": "Id": "format": "int32" "type": "integer" "SeatAssignable": "type": "boolean" "EuTravel2.Services.EuTravelService.DataContracts.ContactInformationDTO": "type": "object" "properties": "Phone": "type": "string" "Email": "type": "string" "Address": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.PostalAddressDTO" "EuTravel2.Services.EuTravelService.DataContracts.TimezoneDTO": "type": "object" "properties": "Code": "type": "string" "Description": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.TerrestrialAgencyDTO": "type": "object" "properties": "GTFSId": "type": "string"


70

"Name": "type": "string" "Url": "type": "string" "Contact": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ContactInformationDTO" "OperatingTimezone": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TimezoneDTO" "EuTravel2.Services.EuTravelService.DataContracts.PostalAddressDTO": "type": "object" "properties": "Province": "type": "string" "Locality": "type": "string" "AddressLine1": "type": "string" "PostalCode": "type": "string" "PostOfficeBoxNumber": "type": "string" "AddressLine2": "type": "string" "AddressNumber": "type": "string" "AddressLine3": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.GetSolutionsForLegResponseDTO": "type": "object" "properties": "Solutions": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SolutionWrapperDTO" "Error": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ErrorDTO" "OriginLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LocationInputDTO" "DestinationLocation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LocationInputDTO" "DepartureDate": "type": "string" "ArrivalDate":


71

"type": "string" "EuTravel2.Services.EuTravelService.DataContracts.SolutionWrapperDTO": "type": "object" "properties": "Currency": "type": "string" "NetPrice": "type": "string" "TotalDuration": "format": "int32" "type": "integer" "Tax": "type": "string" "Transports": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TransportsDTO" "SolutionId": "format": "int32" "type": "integer" "DepartureDate": "format": "date-time" "type": "string" "ArrivalDate": "format": "date-time" "type": "string" "TotalCO2": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.TransportsDTO": "type": "object" "properties": "MarineRoute": "format": "int32" "type": "integer" "FlightRoute": "format": "int32" "type": "integer" "TerrestrialRoute": "format": "int32" "type": "integer" "RailRoute": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.GetSolutionDetailsResponseDTO": "type": "object" "properties": "TotalDuration":


72

"format": "int32" "type": "integer" "Currency": "type": "string" "NetPrice": "format": "double" "type": "number" "Tax": "format": "double" "type": "number" "Transports": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TransportsDTO" "StartPoint": "type": "string" "EndPoint": "type": "string" "SolutionId": "format": "int64" "type": "integer" "Error": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ErrorDTO" "Solution": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SolutionDTO" "TerrestrialStart": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.NCSRDDoorToDoorRootDTO" "TerrestrialEnd": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.NCSRDDoorToDoorRootDTO" "EuTravel2.Services.EuTravelService.DataContracts.NCSRDDoorToDoorRootDTO": "type": "object" "properties": "plan": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.planDTO" "requestParameters": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.requestParametersDTO" "EuTravel2.Services.EuTravelService.DataContracts.planDTO": "type": "object" "properties": "date": "format": "int64" "type": "integer" "from": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.fromDTO" "itineraries":


73

"type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.itinerariesDTO" "to": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.planToDTO" "EuTravel2.Services.EuTravelService.DataContracts.requestParametersDTO": "type": "object" "properties": "body": "type": "string" "date": "type": "string" "fromPlace": "type": "string" "maxWalkDistance": "type": "string" "mode": "type": "string" "optimize": "type": "string" "showIntermediateStops": "type": "string" "time": "type": "string" "toPlace": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.fromDTO": "type": "object" "properties": "lat": "format": "float" "type": "number" "lon": "format": "float" "type": "number" "name": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.itinerariesDTO": "type": "object" "properties": "duration": "format": "int64" "type": "integer" "elevationGained":


74

"format": "int32" "type": "integer" "elevationLost": "format": "int32" "type": "integer" "endTime": "format": "int64" "type": "integer" "startTime": "format": "int64" "type": "integer" "tooSloped": "type": "boolean" "transfers": "format": "int32" "type": "integer" "transitTime": "format": "int64" "type": "integer" "waitingTime": "format": "int64" "type": "integer" "walkDistance": "format": "float" "type": "number" "walkTime": "format": "int32" "type": "integer" "evaluation": "format": "float" "type": "number" "phi1": "format": "float" "type": "number" "phi2": "format": "float" "type": "number" "phi3": "format": "float" "type": "number" "legs": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.legsDTO" "EuTravel2.Services.EuTravelService.DataContracts.planToDTO": "type": "object" "properties": "lat":


75

"format": "float" "type": "number" "lon": "format": "float" "type": "number" "name": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.legsDTO": "type": "object" "properties": "bogusNonTransitLeg": "type": "boolean" "distance": "format": "float" "type": "number" "duration": "format": "int32" "type": "integer" "endTime": "format": "int64" "type": "integer" "mode": "type": "string" "route": "type": "string" "startTime": "format": "int64" "type": "integer" "steps": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.stepsDTO" "from": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.fromDTO" "legGeometry": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.legGeometryDTO" "to": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.toDTO" "agencyId": "type": "string" "routeShortName": "type": "string" "routeLongName": "type": "string" "headsign": "type": "string"


76

"routeColor": "type": "string" "routeTextColor": "type": "string" "intermediateStops": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.intermediateStopsDTO" "EuTravel2.Services.EuTravelService.DataContracts.stepsDTO": "type": "object" "properties": "distance": "format": "float" "type": "number" "streetName": "type": "string" "absoluteDirection": "type": "string" "lon": "format": "float" "type": "number" "lat": "format": "float" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.legGeometryDTO": "type": "object" "properties": "points": "type": "string" "length": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.toDTO": "type": "object" "properties": "arrival": "format": "int64" "type": "integer" "departure": "format": "int64" "type": "integer" "stopCode": "type": "string" "lat":


77

"format": "float" "type": "number" "lon": "format": "float" "type": "number" "name": "type": "string" "stopId": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.toStopIdDTO" "EuTravel2.Services.EuTravelService.DataContracts.intermediateStopsDTO": "type": "object" "properties": "name": "type": "string" "lat": "format": "float" "type": "number" "lon": "format": "float" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.toStopIdDTO": "type": "object" "properties": "agencyId": "type": "string" "id": "type": "string" "EuTravel2.Web.Code.WebApi.EuTravelServiceBookingDto": "type": "object" "properties": "solutionId": "format": "int32" "type": "integer" "passengerArray": "type": "array" "items": "$ref": "#/definitions/EuTravel2.BO.PersonHelperDTO" "EuTravel2.BO.PersonHelperDTO": "type": "object" "properties": "Name": "type": "string" "Surname": "type": "string"


78

"Phone": "type": "string" "Email": "type": "string" "Age": "format": "int32" "type": "integer" "DateOfBirth": "format": "date-time" "type": "string" "NationalityCode": "type": "string" "Title": "format": "int32" "enum": [0 1 2 3] "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.BookingConfirmationDTO": "type": "object" "properties": "Legs": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LegConfirmationDTO" "Error": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ErrorDTO" "Passengers": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.PersonHelperDTODTO" "EuTravel2.Services.EuTravelService.DataContracts.LegConfirmationDTO": "type": "object" "properties": "Success": "type": "boolean" "Message": "type": "string" "LegID": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.PersonHelperDTODTO": "type": "object" "properties": "Name": "type": "string" "Surname":


79

"type": "string" "Phone": "type": "string" "Email": "type": "string" "Title": "format": "int32" "enum": [0 1 2 3] "type": "integer" "Age": "format": "int32" "type": "integer" "DateOfBirth": "format": "date-time" "type": "string" "NationalityCode": "type": "string" "EuTravel2.Services.EuTravelService.DataContracts.ShoppingQueryDTO": "type": "object" "properties": "NumberOfAdults": "format": "int32" "type": "integer" "NumberOfChildren": "format": "int32" "type": "integer" "NumberOfElders": "format": "int32" "type": "integer" "NumberOfPRMs": "format": "int32" "type": "integer" "NumberOfInfants": "format": "int32" "type": "integer" "DepartureDate": "format": "date-time" "type": "string" "ArrivalDate": "format": "date-time" "type": "string" "NumberOfVehicles": "format": "int32" "type": "integer" "Direct": "type": "boolean" "NumberOfStops": "format": "int32"


80

"type": "integer" "MaxPrice": "format": "float" "type": "number" "NumberOfResults": "format": "int32" "type": "integer" "CommunicationToken": "type": "string" "Transaction": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TransactionDTO" "Currency": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.CurrencyDTO" "TravelClass": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TravelClassDTO" "GeoCoordinates": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.GeoCoordinatesDTO" "EuTravel2.Services.EuTravelService.DataContracts.TransactionDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.TravelClassDTO": "type": "object" "properties": "ClassCode": "type": "string" "ClassDescription": "type": "string" "ClassName": "format": "int32" "enum": [0 1 2] "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.ShoppingResponseDTO": "type": "object" "properties": "Currency": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.CurrencyDTO" "Trip": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TripDTO" "EuTravel2.Services.EuTravelService.DataContracts.TripDTO": "type": "object" "properties": "TripCode": "type": "string" "Name": "type": "string"


81

"Description": "type": "string" "Legs": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LegDTO" "Reservation": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ReservationDTO" "EuTravel2.Services.EuTravelService.DataContracts.ReservationDTO": "type": "object" "properties": "Status": "type": "string" "Price": "format": "double" "type": "number" "CreationDate": "format": "date-time" "type": "string" "Currency": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.CurrencyDTO" "EuTravel2.Services.EuTravelService.DataContracts.RoutesCountResponseDTO": "type": "object" "properties": "MarineRoutes": "format": "int32" "type": "integer" "RailRoutes": "format": "int32" "type": "integer" "TerrestrialRoutes": "format": "int32" "type": "integer" "FlightRoutes": "format": "int32" "type": "integer" "MarineAgencies": "format": "int32" "type": "integer" "RailAgencies": "format": "int32" "type": "integer" "TerrestrialAgencies": "format": "int32" "type": "integer" "FlightAgencies":


82

"format": "int32" "type": "integer" "Error": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ErrorDTO" "EuTravel2.Services.EuTravelService.DataContracts.KPIsResponseDTO": "type": "object" "properties": "SOLCOV": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SOLCOVDTO" "FBSCO": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FBSCODTO" "DATUR": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DATURDTO" "TIMBO": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TIMBODTO" "COMCP": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.COMCPDTO" "TIMUC": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TIMUCDTO" "STEPA": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.STEPADTO" "MONEP": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.MONEPDTO" "FBPEN": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FBPENDTO" "STEAU": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.STEAUDTO" "SRTHR": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SRTHRDTO" "EXTEVG": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.EXTEVGDTO" "TIMPL": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TIMPLDTO" "TIMPA": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TIMPADTO" "CLINF": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.CLINFDTO" "COMIS": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.COMISDTO" "LTBRA": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.LTBRADTO" "SOLCOM": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SOLCOMDTO" "SRINT":


83

"$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SRINTDTO" "TIMTI": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TIMTIDTO" "AVGAT": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.AVGATDTO" "FOCIM": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.FOCIMDTO" "SRAVG": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SRAVGDTO" "COMBS": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.COMBSDTO" "SOLPO": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.SOLPODTO" "DATEF": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.DATEFDTO" "Error": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.ErrorDTO" "EuTravel2.Services.EuTravelService.DataContracts.SOLCOVDTO": "type": "object" "properties": "NumberOfSegmentsAvailableForBooking": "format": "int32" "type": "integer" "TotalNumberOfSegmentsReturned": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.FBSCODTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.DATURDTO": "type": "object" "properties": "TotalTimeOfSystemActivity": "format": "int64" "type": "integer" "DatasetUpdatesForEurolines": "format": "int32" "type": "integer" "DatasetUpdatesForSilverrail": "format": "int32" "type": "integer" "DatasetUpdatesForTravelport": "format": "int32" "type": "integer" "DatasetUpdatesForPharos": "format": "int32"


84

"type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.TIMBODTO": "type": "object" "properties": "AverageResponseTimeForBookingRequests": "format": "float" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.COMCPDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.TIMUCDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.STEPADTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.MONEPDTO": "type": "object" "properties": "NumberOfMonitoredServices": "format": "int32" "type": "integer" "NumberOfTotalServices": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.FBPENDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.STEAUDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.SRTHRDTO": "type": "object" "properties": "NumberOfSuccessfulResponses": "format": "int32" "type": "integer" "NumberOfTotalResponses": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.EXTEVGDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.TIMPLDTO": "type": "object" "properties":


85

"AverageResponseTimeForPlanningRequests": "format": "float" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.TIMPADTO": "type": "object" "properties": "AverageResponseTimeForPaymentRequests": "format": "float" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.CLINFDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.COMISDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.LTBRADTO": "type": "object" "properties": "TotalNumberOfSuccessfulShoppingResponses": "format": "int32" "type": "integer" "TotalNumberOfSuccessfulBookingResponses": "format": "int32" "type": "integer" } "EuTravel2.Services.EuTravelService.DataContracts.SOLCOMDTO": "type": "object" "properties": "TotalNumberOfSegmentsReturned": "format": "int32" "type": "integer" "TotalNumberOfSegmentFieldsWithActualValues": "format": "int32" "type": "integer" "TotalNumberOfSegmentFieldsWithNullValues": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.SRINTDTO": "type": "object" "properties": "TimePeriodDetails": "format": "date-time" "type": "string" "NumberOfInterruptions": "format": "float" "type": "number"


86

"EuTravel2.Services.EuTravelService.DataContracts.TIMTIDTO": "type": "object" "properties": "AverageResponseTimeForTicketingRequests": "format": "float" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.AVGATDTO": "type": "object" "properties": "AverageAfterworkTime": "format": "float" "type": "number" "EuTravel2.Services.EuTravelService.DataContracts.FOCIMDTO": "type": "object" "properties": "NumberOfServicesIntegrated": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.SRAVGDTO": "type": "object" "properties": "NumberOfSuccessfulResponses": "format": "int32" "type": "integer" "NumberOfTotalResponses": "format": "int32" "type": "integer" "EuTravel2.Services.EuTravelService.DataContracts.COMBSDTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.SOLPODTO": "type": "object" "properties": } "EuTravel2.Services.EuTravelService.DataContracts.DATEFDTO": "type": "object" "properties": } "EuTravel2.ExternalStructs.NCSRDDoorToDoor.NCSRDDoorToDoorSimpleRoot": "type": "object" "properties": "durationInMillis": "format": "int32" "type": "integer" "estimatedArivalTimeInMillis": "format": "int64" "type": "integer" "meanList": "type": "array" "items":


87

"type": "string" "EuTravel2.Services.EuTravelService.DataContracts.StationResponseDTO": "type": "object" "properties": "Airports": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.AirportDTO" "Ports": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.PortDTO" "TrainStations": "type": "array" "items": "$ref": "#/definitions/EuTravel2.Services.EuTravelService.DataContracts.TrainStationDTO" }


88

13 Appendix 2: Semantic Web Services – Lightweight Approaches

13.1 Introduction In this Appendix we review four lightweight approaches to annotating web services with semantic descriptions. In the context of EuTravel, the purpose of such annotation is to make travel services searchable/discoverable by automated programs such as search engines and software agents, and also to make them more easily ‘mashable’, i.e. combined into composite services. All semantic annotation approaches reviewed here are possible candidates for inclusion in a future ‘EuTravel development environment’ for travel service mashups. It has to be taken into account however that additional effort will be required in order to develop or customise existing annotation tools that come with each approach in order to accommodate the EuTravel Ontology and Common Information Model to be used for annotations.

13.2 SAWSDL (Semantic Annotations for WSDL and XML Schema) The Web Services Description Language (WSDL) specifies a way to describe the abstract functionalities of a Web service, and concretely how and where to invoke it. WSDL descriptions do not however include any semantics; therefore, two services can have similar descriptions while meaning different things, or very different descriptions yet similar meaning. Resolving such ambiguities in Web service descriptions is a fundamental step towards automating the discovery and composition of Web services. SAWSDL (Semantic Annotations for WSDL and XML Schema) is a W3C Recommendation that defines mechanisms using which semantic annotations can be added to WSDL descriptions, referencing concepts in semantic models (e.g. ontologies). SAWSDL enables semantic annotations for Web services not only for discovering Web services but also for invoking them, giving the possibility to reference lifting and lowering schema mappings (i.e. transformations between the conceptual representation and the syntactical representation). SAWSDL does not specify or mandate a specific language for representing semantic models, so any suitable language may be used (e.g. OWL, RDFS). In order to enable semantic annotations of WSDL components, SAWSDL defines three new attributes that can be added to WSDL elements:

• one attribute, named modelReference, to specify the association between a WSDL component and a concept in some semantic model. This modelReference attribute can be used especially to annotate XML Schema type definitions, element declarations, and attribute declarations as well as WSDL interfaces, operations, and faults.

• two attributes, named liftingSchemaMapping and loweringSchemaMapping, that are added to XML Schema element declarations and type definitions for specifying mappings between semantic data and XML. These mappings can be used during service invocation.

Regarding shortcomings of the approach, SAWSDL relies on outside software to solve semantic heterogeneities and this task needs to be assigned to external mediators. Thus, SAWSDL is not a standalone solution to semantic web services implementation.

13.3 WSMO-Lite (Web Service Modeling Ontology Lite) SAWSDL provides the grounds for a bottom-up approach to semantic Web service modelling: it supports the idea of adding small increments (and complexity) on top of WSDL, allowing results from various existing approaches to be adopted. As the basis for bottom-up modelling, SAWSDL is independent of any particular semantic technology, i.e., it does not define any types, forms or languages for semantic descriptions. The WSMO-Lite service ontology fills the SAWSDL annotations with concrete semantic Web service descriptions. A Web Service Modeling Ontology (WSMO-Lite) description contains three parts:

• the information model, represented using a domain ontology;


89

• functional descriptions, which can have two components: classifications, which link to a functional taxonomy via a concrete root class, and capabilities, which express the (pre)conditions and effects of the services and of their operations;

• non-functional descriptions, used to formalise non-functional properties (e.g. policies).

WSMO-Lite descriptions are serialised in RDF and can thus be stored in RDF repositories (also called triplestores). Figure 13-1 shows the relationship between WSDL, SAWSDL, and WSMO-Lite.

Figure 13-1: Relationship between WSDL, SAWSDL, and WSMO-Lite

13.4 USDL/Linked USDL Unified Service Description Language (USDL) can be defined as a platform-neutral language for describing services. It was the result of the experience in several services-related research projects that materialized as a W3C Incubator Group from September 2010 to October 2011. USDL defines a language for describing general and generic parts of technical and business services to allow services to become tradable and consumable. Figure 13-2 represents the different parts of business services covered by USDL.

Figure 13-2: USDL packages

WSDL

SAWSDL

extends

annotationspoint to

Service DescriptionLayer

Semantic AnnotationLayer

WSMO-LiteService ontology


90

Along with the USDL specification, the Linked USDL initiative, the purpose of which is to promote and support the use of the Unified Service Description Language (USDL) on the Web [46]. Linked USDL is a remodeled version of USDL that builds upon the Linked Data principles and the Web of Data, promoting the use of well-known vocabularies such as GoodRelations, the Minimal Service Model and FOAF among others.

13.5 HYDRA HYDRA [24] combines the REST architectural style and the Linked Data principles. It allows data to be enriched with machine-readable ‘affordances’ (such as hyperlinks) which enable interaction. The basic idea behind Hydra is to provide a vocabulary which enables a server to advertise valid state transitions to a client who then uses this information to construct HTTP requests which modify the server’s state so that a certain desired goal is achieved.

Documents

D2.1: Technology Ecosystem Architecture Ecosystem... · Deliverable leader VLTN 29-02-2016, 10-03-2018 Quality manager JR 28-02-2016 Project manager IF 29-02-2016, 13-03-2018