Services Documentation

Transcription

1 INFORMATION SOCIETY TECHNOLOGIES (IST) PROGRAMME IT IST Services Documentation Deliverable No. (use the number indicated on technical annex) Workpackage No. WP2 D2.1.2 IT services documentation Workpackage Title Service development and data management Activity No. A2.1 - A2.4 Activity Title A2.1 Traffic information services A2.2 Mode specific travel services A2.3 Geo-referenced services A2.4 Touristic information services Authors (per company, if more than one company provide it together) Status (F: final; D: draft; RD: revised draft): File Name: Project start date and duration TIETOTALO: Risto Virkkala, Markku Mäkelä, SISO: N. Spanoudakis, MMS: Monica Raimondi, TREDIT: Vasilis Mizaras, PTV: Markus Kauber F IM@GINE IT D2.1.2 after 1 st review.doc 01 January 2004, 24 Months

2 List of contents 1. Introduction IM@GINE IT Objectives Overview of WP2 work and link with other project work elements IM@GINE IT service design and implementation process Introduction IM@GINE IT end user services Distributed, multi-source and integrated content IM@GINE IT Content flow model Link to MAS System integrator and ontology solution framework Navigation to the remaining contents of the current report Service descriptions and documentation Decomposition of Transport & Travel Content Domains Project objectives in transportation and travel IM@GINE IT business domains Service domain analysis Traffic information services Multi-modal Routing/Mapping services Public transport (timetable & routing) related services Touristic information services Synthesis of business domains services Data Management Module (DMM) Operation IM@GINE IT basic content services documentation Identification of basic content required Basic content Service organisation within IM@GINE IT IM@GINE IT web services identification & documentation Identification of web services required Identification of service instances Web service organisation in IM@GINE IT IM@GINE IT Ontology solution General overview of Ontology concept Ontology implementation & use Ontology methodological steps Overview of steps taken Ontology implementation modules Identification of domain elements Traffic information services Mapping services Geocoding service Mapping service Public transport (timetable & routing) related services Touristic information services POI and event search Hotel reservation Ontology definition & documentation August 2005 i

3 4.6. Abstract service specification Metadata information required Dynamic Car and Pedestrian Routing Mapping Service Geocoding Service PT Routing Service Traffic Information POI and Event Information PT Time Table Information Dynamic PT Information Hotel Reservation Mapping Service instances to IT Ontology Mapping services to IT ontology Metadata information for service instances MMS Services PTV Services TIETOTALO Services TREDIT Services TOPO Services T Services Conclusions Innovations References Annex A: IT Basic content services documentation Traffic Information service instances Routing/Mapping Service instances Public Transport related service instances Touristic Information service instances Annex B: IT Ontology definition (documentation) Class AgentAction Class Coordinates Class Address Class BoundingBox Class ScreenSize Class POIForMap Class Line Class ClickablePOI Class ImageCoordinates Class Map Class Image Class RouteSegmentDetail Class CoordinatesInCountry Class RouteSegment Class Route August 2005 ii

4 8.16. Class PublicTransportTimetable Class OptionalInformation Class LineTimetable Class TrafficEvent Class PublicTransportEvent Class HotelGuestInformation Class RoomAvailabilityResponse Class MakeBookingResponse Class GeocodedAddress Annex C: IT Ontology modelled in Protege tool Protégé Classes view Protégé Slots view Annex D: IT Ontology abstract service descriptions Hotel reservation / requestroomavailability Hotel reservation / makebooking Hotel reservation / cancelbooking Hotel reservation / requestbookingdetails Hotel reservation / requestroomtypes Geocoding service Mapping service Dynamic car and pedestrian routing PT routing service Traffic information POI and event search PT time table information Dynamic PT information Annex E: Mapping service instances to Ontology TIETOTALO's services Hotel reservation service Mapping services POI and Event Search service PT Routing service MMS' services Mapping service, Routing service, POI and Event search service PTV's services Mapping service, Routing service, POI and Event search service TREDIT's services POI and Event Search service Routing service PT timetables service, Traffic information service TOPO's services Mapping service, touristic information service, routing service, PT timetable service 99 August 2005 iii

5 List of figures Figure 1: Role of WP2 in IT project and system... 3 Figure 2: Generic use case diagram... 6 Figure 3: Overall system s decomposition & WP2 implementation framework... 8 Figure 4: Abstract content flow model... 9 Figure 5: IM@GINE IT ontology framework Figure 6: Interfacing to individual web services through ontology solution Figure 7: Basic configuration Figure 8: Aggregator service provider s configuration Figure 9: Agent based service provider s configuration Figure 10: Web based prototype of Inter-modal router (plane not yet included) Figure 11: Web based prototype of Inter-modal router (plane not yet included) Figure 12: Modelling an in-door map in VISUM (Frankfurt Airport) Figure 13: Centralised content editing from distributed sources Figure 14: Business domains in a service environment Figure 15: Example ontology in Protégé Figure 16: Ontology implementation modules List of tables Table 1: Basic configuration Table 2: Aggregator service provider s configuration Table 3: Agent based service provider s configuration Table 4: Cross-fertilisation of business domains in IM@GINE IT Table 5: IM@GINE IT content and service providers Table 6: Basic content services per test site and content provider Table 7: Service instances Table 8: Service providers and sub-service providers (basic content providers) per test site Table 9: Availability of web services instances Table 10: Matching service instances to abstract service descriptions Table 11: Traffic Information Services provided within the project by Service Provider partners Table 12: Mapping/Routing Services provided within the project by Service Provider partners Table 13: Public transport related services provided within the project by Service Provider partners Table 14: Touristic information services provided within the project by Service Provider partners Table 15 Mapping of FTB's attributes to IM@GINE IT ontology Table 16 Mapping of Go Finlands's attributes to IM@GINE IT ontology Table 17 Mapping of Finnish PT routers attributes to IM@GINE IT ontology Table 18 Mapping of MMS' services to IM@GINE IT ontology Table 19 Mapping of PTV's services to IM@GINE IT ontology Table 20 Mapping of TREDIT's services to IM@GINE IT ontology Table 21 Mapping of TOPO's services to IM@GINE IT ontology August 2005 iv

6 List of abbreviations Term Explanation DM Data Management Module FIPA Foundation of Intelligent Physical Agents GIS Geographic Information System GPS Global Positioning System GPRS General Packet Radio Service GUI Graphical User Interface HMI Human Machine Interface IMAGE IMAGE Project JVM Java Virtual Machine MAC Apple Macintosh computer MAS Multi Agent System OOSE Object Oriented Software Engineering OTA Open Travel Alliance OWL Web Ontology Language PC Personal Computer PDA Personal Digital Assistant POI Point Of Interest RDF Resource Description Framework RDFS Resource Description Framework Schema UC Use Cases UDDI Universal Description, Discovery and Integration UML Unified Modelling Language UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier URL Uniform Resource Locator W3C World Wide Web Consortium WLAN Wireless Local Area Network XML extensible Markup Language XSLT Extensible Stylesheet Language Transformations OML Outline Markup Language XOL XML-based Ontology Exchange Language DAML-OIL DARPA Agent Markup Language Ontology Interchange Language August 2005 v

7 Executive Summary Deliverable D2.1.2 constitutes the services documentation, which describes the common IT ontology for each service (traffic information, mapping, routing and touristic information) and a way of transforming local services to MAS level using these ontology specifications. The current Deliverable 2.1.2: Documentation of Services is a report, and its main purpose is to document the achievements of WP2. More precisely, there is a two-fold aim: Describe and document the services implemented in the framework of WP2. Describe and document the work of actual service ontology definition performed in WP2 and enable the use of implemented services by the system. It describes the work performed in the context of the following WP2 Activities: A2.1, Traffic information services, leaded by MMS. A2.2, Mode specific travel services, leaded by HACON. A2.3, Geo-referenced services, leaded by PTV. A2.4, Touristic information services, leaded by TIETOTALO. The deliverable also reports the combined work executed between WP2 and WP3 (leaded by SISO) in the framework of Ontology definition. The Deliverable is a technical report, and as a result most of the achievements are described by using a technical terminology and provided as annexes (i.e. documentation of software engineering effort). Contents of the deliverable are introduced in Chapter 1. Further chapters go into details as follows: Chapter 2 presents the overall service design and implementation process followed in the project, and WP2 in particular. It includes an analysis of the multi-source content aggregation rationale implemented in the project, the content flow model as well the method by which web services are interfacing MAS by using the Ontology solution. Chapter 3 presents a description and documentation of the content services and web services implemented in the project. Chapter 4 presents the Ontology concept solution of transforming web services through a common IM@GINE IT ontology, allowing a top-level system to communicate and handle data with a single data model. The chapter describes the ontology methodology and its objectives, identifies the individual elements in the IM@GINE IT ontology and gives abstract descriptions of the services related to these domains, and lists the meta-data used with the services. It also presents the mapping of local service instances to IM@GINE IT ontology. Chapter 5 ends the report with a conclusion. However, the most important contents of the current deliverable are included in Annexes as technical documentation. More specifically, the deliverable includes Annexes as follows: August

8 Annex A includes a documentation of available basic content services. Annex B includes a documentation of the IM@GINE IT Ontology definition. Annex C includes the IM@GINE IT Ontology modelled in Protégé. Annex D includes the abstract service descriptions for the IM@GINE IT Ontologies. Annex E includes the mappings of service instances to the IM@GINE IT Ontology. August

9 1. Introduction 1.1. IT Objectives IT project s aim is to develop one and single access point, through which the end user can obtain location-based, intermodal transport information (static and dynamic), mapping and routing, navigation and other related services everywhere in Europe, anytime, taking into account personal preferences of the user. Thus, IM@GINE IT targets the facilitation of seamless travel in Europe. In this framework, IM@GINE IT should exploit a variety of content resources, which are aggregated at various levels by different service/content providers. WP2 task in the project is thus to implement, aggregate and deliver the necessary content services to the IM@GINE IT system, for further use by the Multi-Agent System (MAS) Overview of WP2 work and link with other project work elements WP2 of IM@GINE IT is called Service development and data management and it aims to make content available for urban, regional and interurban, mode-specific travel information (car, bus, tram, metro, ship, airplane), geo-referenced web services and touristic Points Of Interest, through a single system, in order to provide and implement a set of web services to MAS. These services objectives are: Support multiple digital map formats for mapping services. Support multiple geocoding standards. Support different travel modes and mode-specific services on routing services. Seamless real multi-modal navigation and routing services. WP4 Devices applications; Delivery to end user WP3 MAS; Integration of Services WP2 Services; Content & Interfaces Figure 1: Role of WP2 in IM@GINE IT project and system. August

10 2. IT service design and implementation process 2.1. Introduction The current section includes a description of the methodological process followed for preparing and converting content services according to IM@GINE IT specifications, as well as for the documentation of the actual web services utilised by the system for the final service delivery. The IM@GINE IT project followed a top-down approach in designing and implementing the required services. The analysis and specification part was executed in the framework of WP1: Services specification, design and system architecture, and reported in three distinct deliverables, namely D1.1, D1.2, D1.3. WP2 uptakes the findings of the above mentioned deliverables in order to implement the specified services. Description and documentation of those services is included in the current report. The structuring of the content aggregation and distribution within the IM@GINE IT system is specified by a technical solution developed by the project, which is underpinned by the following essential concepts, analysed in following sections: IM@GINE IT end user services: they define the system s objective. Although not within WP2 responsibility, these are mentioned since they constitute the basis for the service/content definition analysis. Distributed, multi source and integrated content rationale: it explains the IM@GINE IT concept of exploiting multiple content sources, and the layered, structured approach proposed for building up content for use by the multiagent system. Content flow model: it explains the abstract flow model used by the project in order to implement the above-mentioned multi source and integrated content rationale. Link to MAS & Ontology: it explains how the last mile content provision is implemented in the IM@GINE IT system, by exploiting the Ontology concept. Finally, the current section also includes a guidance/navigation for reading the remaining documentation parts of the report IM@GINE IT end user services IM@GINE IT delivers a border-free location-based trip planning and support application, which satisfies the following end users travel needs: August

11 1. Where am I (In terms of location, POIs around me and transportation mean)? 2. Where is a specific POI (or event/activity)? 3. How can I get there (Multimodal route guidance including Via points)? It may also include the following: 3a. What is the traffic situation/conditions (Private transport)? 3b. What is the itinerary (PT timetables)? 4. Can I make a reservation? 5. How to pay & receive ticket? 6. Anything interesting along the route (Positive events, extension of service)? 7. Anything interesting at the destination (Positive events, extension of service)? 8. Any problem during the ride/trip (Negative events, disruption of service)? The analysis of the above-mentioned needs and their transformation into system use cases has been performed in WP1, and reported in deliverable D1.1: Use cases and user/vehicle profile requirements. The following figure presents the entire suite of use cases that could cover all travel planning & support related requirements. August

12 Figure 2: Generic use case diagram. The delivery of the end user services is mainly a responsibility of software modules developed in the framework of WP3 and WP4, however, the system use cases is the basis for any further analysis and content models followed in the course of the project s execution, and as a result have been analysed by WP2 in order to define the content services needed Distributed, multi-source and integrated content A key innovation factor of IM@GINE IT project is that the overall system will aggregate information from multiple service content providers in Europe, and allow the end user to access this information though a set of web services designed for varieties of business domains (for example, transport, tourism and travel). The core principle in the system design is to allow more service content providers to be integrated into the system later on. August

13 Although, each market player (content or service provider) could actually interface directly the system in order to provide his/her content products, the project designed a hierarchical, layered content aggregation & integration approach, which includes the following abstract levels of aggregation: Level 1: Sub-service providers: simple content or service provider. At this level the service provider offers only a segment of the required service. The level 1 service provider could be or could not be a part of the IM@GINE IT service network. Level 2: Service Providers. This is a new integration level introduced by IM@GINE IT project. At this level some kind of further development is needed in order to follow IM@GINE IT interface guidelines. The level 2 service providers operate Local Platforms that provide hold agreements with service/content aggregators or simple service/content providers. Level 3: Service integrator platform. The MAS level; it packages and produces final IM@GINE IT services. It is operated on behalf of the level 2 service providers. The solution adopted by IM@GINE IT is the level 2 integration to be executed by multiple services platform running in several countries (Test sites), which aggregate country or city specific traffic, mapping, public transportation and touristic information, which is gathered by many content sources (Level 1 of the layered approach above-mentioned). Many of these services are already implemented using various technologies and data models, and offer different interfaces for accessing the content through web services, XML-interfaces and other interface types. These are the basic content services required for synthesizing the final IM@GINE IT system use cases. Sub-service and sub-content providers are, for example public authorities for traffic or public transport information, private enterprises specialised on certain content, etc. The connection to sub-service and sub-content providers is not relevant for the system architecture, and may be established with other means (DATEX, XML over TCP, proprietary protocols, CORBA, RPC, etc.). The basic content services are integrated by level 2 service providers and offered to MAS through a specific set of web services. MAS is exploiting the web services by using an ontology definition for Transport & Travel domains. WP2 goes into describing the actual implementation and details of the web services as well as the Ontology IM@GINE IT Content flow model The technical solution proposed by the project for the content aggregation and integration described in the previous section is described in deliverable D1.3, system architecture. The solution is extensible and allows more service content providers to be added to the system later on with ontology transformations without requiring thirdparty system re-design. Compared to centralized system solutions, the ontology model is more innovative way of allowing future integration of services. August

14 The following figure demonstrates the overall system decomposition and specifies the WP2 implementation framework. End-user End-user End-user End-user End-user B2C Operator Platform B2C Operator Platform Service Integrator Platform Service Integrator Platform Service Provider Service Provider Service Provider Service Provider Service Provider Sub-Service Provider Sub-Service Provider Sub-Service Provider Sub-Service Provider Enabled Device Enabled Device Enabled Device Enabled Device Enabled Device Enabled Device MAS MAS WP2 implementation Framework Figure 3: Overall system s decomposition & WP2 implementation framework. Focusing on the WP2 implementation framework, IM@GINE IT is producing an abstract Content flow model, in which the following elements can be identified: o Basic content service, which is provided by a Sub-service provider (Level 1) a, b, c, and it is characterised by domain, type, and geographic coverage (for example, public transport timetables for city of Athens), x, y, z. o Web service, which is provided by a Service Provider (Level 2) A, B, and it is matching a defined Ontology Abstract Service X, Y, Z, while it is characterised by meta-data information of the service. o Ontology, which includes the abstract descriptions and meta-data of all X, Y, Z, while also specific descriptions and meta-data of all AX, BY, etc. August

15 MAS Ontology X, Y, Z Web service A (X, Y) Web service B (X, Z) Service provider A Service provider B Content x, y Content x, y, z Basic content service xa, ya Basic content service xb, yb Basic content service zc Sub-service Provider a Sub-service Provider b Sub-service Provider c Figure 4: Abstract content flow model Link to MAS System integrator and ontology solution framework The ontology solution proposed by the project and described in current report aims to allow the content to be accessed and also aggregated through one system, the Multi Agent System (MAS). The MAS consists of several agents built to communicate with the local services using ontology transformations, which allow the content and functionality to be transformed into a common standard. The overall Ontology rationale and framework was described in deliverable D1.2: Service specification, and it is visualized at the following figure. August

16 Figure 5: IT ontology framework. How is this solution actually being implemented? The interface between all service provider modules (comprising a platform of GIS, DMM sub-modules) and the Service Integrator Module (MAS) will be SOAP over HTTP. The service definition will consist of: o The WSDL document, which defines the syntax of the service itself, or a web URL pointing to such a WSDL document; o The RDF/OWL-S document mapping service-specific aspects to the general IM@GINE IT ontology, or a web URL pointing to such a WSDL document. Generally speaking, the modules themselves shall be implemented in any technology able to expose a SOAP-based Web Service. Due to the use of Web Services and the IM@GINE IT ontology implementation, the underlying technology of the service provider modules does not affect the MAS. The MAS handles the functionality and aggregation of the requested content from the local services. It makes requests for content to local services accessing the required local services (one or many) through specific Provider agents. The implementation of the interfaces of the different web services is possible through an ontology solution as shown in figure below, which includes: August

17 o A pre-defined IM@GINE IT ontology definition. o A pre-defined mapping of individual web services to the IM@GINE IT ontology. Service A X interface Map service A X to ontology Provider Agent IM@GINE-IT ontology MAS Service Integrator Figure 6: Interfacing to individual web services through ontology solution. The content flow continues from this point to be processed by the MAS level to serve the end-user s request. There are three configurations that could be used for interfacing the Service to the MAS, explained in more detail in deliverable D1.3: System architecture : o Basic: the module exposes a basic service that is already existing and available. Connection to the Service Integrator may only need adaptation of its interface to the IM@GINE IT ontology, but no new service functionality needs to be developed. o Aggregator: the module exposes aggregated services that combine a number of sub-services into an added value service. Aggregation typically requires the development of some software. The interface to the aggregated service respects the IM@GINE IT ontology. o Agent-based Aggregator: the services package a number of sub-services into a compound by exploiting semantic, agent-based aggregation techniques. Here, Complex Service Providers are used. Module Description Interfaces/Protocols IM@GINE IT specific? Basic Service Module Software component, providing kind of basic functionality: mapping, routing, PT timetable access, etc. which is already existing and ready to connect to the Service Integrator Application. SOAP over HTML Towards the Service Integrator Platform. The service is advertised as a WSDL + RDF document. NO Inner Technology: non relevant. Table 1: Basic configuration. August

18 Service integrator Platform Service Provider ( Basic ) Service Integrator Application (Java) JADE SOAP Basic Service Module (Server) Figure 7: Basic configuration. Module Description Interfaces/Protocols IM@GINE IT specific? Aggregated service provider module Sub-service provider Software module that packages a complex service, based on a number of sub-services and possibly locally added value. The compound service is exposed to the Service Integrator Application via SOAP. Inner Technology: non relevant. Software component, providing kind of basic functionality to the Service Aggregation Module Inner Technology: non relevant. SOAP over HTML Towards the Service Integrator Application. Inner protocol (non relevant) Towards the subservices. Non relevant Table 2: Aggregator service provider s configuration. YES NO August

19 Service Integrator Application (Java) JADE SOAP Aggregated Service Module (Server) Sub- Service (Server) Sub- Content Server Service integrator Platform Service Provider ( Aggregator ) Figure 8: Aggregator service provider s configuration. Module Description Interfaces/Protocols IM@GINE IT specific? Agent-based Aggregated service module Sub-service Agent-based software that is able to package a complex service, based on a number of sub services and a locally added value, and to advertise it on the Service Integrator Application by means of a Broker Agent. Inner Technology: non relevant (probably Java on Jade). Software component, providing kind of basic functionality: to the Agent-Based Aggregated Service module. Inner Technology: non relevant. SOAP over HTML Towards the sub-services. FIPA ACL Towards the Service Integrator Application. Non relevant Table 3: Agent based service provider s configuration. -- NO August

20 Service Integrator Application (Java) JADE ACL Agent-based Aggregated service module (Java) JADE Sub-Service (Server) Sub-content (Server) Service integrator Platform Service Provider ( Agent-based aggregator ) Figure 9: Agent based service provider s configuration Navigation to the remaining contents of the current report Following the analysis of the previous paragraphs in current section 2, the remaining content documentation is organised in the following manner: Section 3 includes the analysis of the relevant to IM@GINE IT domains, definition and documentation of basic content services, as well as identification and documentation of the web services instances provided by the Test sites Service providers Section 4 includes the Ontology definition methodology followed, the Ontology definition itself, and the mapping of service instances to Ontology The following terminology is defined and followed throughout the report: o Basic content services: basic content required for the satisfaction of system use cases; are provided by the sub-service providers modules (level 1), and are mostly available. Their interface could be non-im@gine IT specific. Their type, content and coverage are specific. They are used for further aggregation/synthesis in order Web services are produced. They are documented in section 3. o Web services: SOAP/XML based services required by the MAS for synthesising the system use cases; are provided by the service providers modules (level 2). Their interface is always IM@GINE IT specific. Their type, content and coverage are specific. They are documented in section 3. o Ontology abstract services: the abstract specifications of the services used by the Ontology. In fact they are abstract & generic representations, thus their content and coverage are not specific. They are documented in section 5. August

21 o Service instances: instances of the Web services matching the Ontology abstract services. They are listed in section 3, and further mapped to the ontology in section 6. August

22 3. Service descriptions and documentation 3.1. Decomposition of Transport & Travel Content Domains The IT project s identified services are properties of either two major, related but not always interconnected Domains, namely Transport & Travel. Planning and carrying out a trip requires collecting a wide range of information from a large number of sources, including information on transportation options, routing, PT schedules, hotel locations, etc. Much of this information is now available on the Internet and it can be used to enable travellers to better plan and execute their trips. The normal approach to planning e.g. business trips is to select the flights, reserve a hotel, and possibly reserve a car at the destination. The choices of which airports to fly into and out of, whether to park at the airport or take a taxi, and whether to rent a car or use the PT at the destination are often made in an impulsive way based on past experience. These kinds of multimodal travel chains and multi-distribution-channels cause s major problems to the potential travellers; in worst case this complex environment prevents willingness to travel. Distribution of content: Main organisational and technical obstacles today are hindering seamless multi-modal services. The most important is the distribution of the necessary partial information, as: Private traffic databases with routers are clearly separated from Public Transport (PT) information systems. Within the private traffic mode, dynamic routing plays an important role. However, this dynamic data is generated in separate sources, close to its origin. Also within PT, timetable information is held in several databases of regional and national coverage or related to a local or nation-wide operator. Flight information and booking facilities are also stored in separated databases due to the growing number of low cost airlines. Long distance bus / coach as well as ferry services are not available in an overall database in the internet like trains and flights by now. Pedestrian and bicycle routers are at least separate components. This distributed landscape of relevant routing information probably remains existing and will become even more important with increasing availability of any kind of dynamic information. The distribution of the information sources leads to: August

23 Lack of integration: The high variety of different distributed data sources leads to a lack of format consistency and standards. The data sources are mostly owned and supported by different institutions, which until today are focused on proprietary systems. Different business models: There are different business models for generating the content of infomobility services. Also transport modes and content have different approaches in the different countries and regions. Current business models are limited and cannot be extended to a pan- European business model. Official legal constraints: Talking about a pan-european service also legal constraints might play a major role. Business models not only have to focus on b2c relations, but also on b2b and the mixture of both: mobile work forces. Private legal constraints: International processing of private user data is a very critical point. The European and national legislation framework has to be considered very carefully. Many previous mobile services failed because the providers could not guarantee the security of private user data. VAD s may differ between cultures: Depending on the culture, Value Added Services will differ from region to region. An obvious example is multilingual services. Technological constraints: Today s network transfer rates are far too low and data transfer costs are much too high in many countries. As long as these obstacles to the successful introduction of mobile ITS services are not removed, they will remain in niches, only used by pioneer users. Functionality within different HMI (Human Machine Interface) environments (in-car HMI, web browser, mobile phone) is very different, thus posing problems in offering seamless and self-explanatory services. Service roaming constraints: Another issue covering several of the above points is the ability of international roaming of infomobility services and the roaming of private user data Project objectives in transportation and travel The main objective of IM@GINE IT is to provide one and single access point through which the end user can obtain location based, intermodal transport information (dynamic and static), mapping & routing, navigation and other related services everywhere in Europe, anytime, taking into account personal preferences. Thus, the key phrase behind IM@GINE IT is: facilitation of seamless travel in Europe. Therefore, IM@GINE IT will: Cater for intermodality & seamlessness of travel. The mobility network is in reality seamless, thus IM@GINE IT should synthesise information of all modes, and of both urban and interurban environments. The constraints and specific August

24 requirements of all modes and environments involved should be taken into account. Bridge the gap between in-vehicle and off-board information and navigation systems. Bridge the gap between vehicle and pedestrian navigation method to provide a seamless intermodal navigation. Be capable of collecting and managing data from different sources. Cater for interchangeability & seamlessness of communication technologies (access everywhere). The back end (platform) as well as the front end (device) should be able to accommodate and/or switch to different communication networks according to the needs of the moment and place. Be able to roam between different media providers. Be capable of acknowledging the location of the end user wherever he/she is, thus switch between different positioning methods depending on the special requirements of the place or mode in which the end user is. Be capable of navigating the end user at as many different levels as possible (micro, within an airport for example, middle, within a city or area, and macro), and for the whole intermodal travel. Provide other related location based or travel oriented services, such as booking/ticketing and emergency services. Perform complex tasks on behalf of the user, and according to his/her preferences. These tasks may include: automatic selection of best travel plan, intelligent filtering & synthesis of information & services, automatic change of travel plans according to unexpected events, booking and ticketing. Interface with external systems at the platform and/or the device point. Provide an external data editor, which allows to an external content provider to update and enhance a central IM@GINE IT database. Increase safety while driving by using IM@GINE IT personalised services to adapt accordingly the warnings and information coming from the vehicles ADAS and IVIS and by automate procedures like route planning, information filtering etc, allowing the driver to focus to its primary task (following the relevant AIDE algorithms). IM@GINE IT platform is directly interfaced to in vehicle network, so its actions are based on vehicle s status and road conditions. Accordingly to these features the platform can understand the level of risk concerning the present driver work, again through AIDE. Also increase safety of pedestrians by minimising any disturbing information or confusing tasks which will reduce the drivers' attention to the possible dangers around the August

25 IT business domains The basic Transport & Travel domains can be further decomposed into further business domains. Business domains in IT can be considered as "global" market segments that are covered by the project services. Although there may be an overlapping between the different business domains, each of them comprises certain kinds of services, which are essential to serve the needs of the end user and thus can be occupied by different players that try to gain revenue out of their activities. The following business domains have been defined within the IT project: o Traffic Information. o Routing/Mapping services. o PT related information. o Touristic information Service domain analysis This section briefly describes the basic content services related to different business domains within the IM@GINE IT project: Traffic information services, Multi-Modal Routing/Mapping services, Public Transport related information and Touristic information. The different business domains all contain domain specific services, which are described for each domain with their parameter types and usage summarized. These are the basic content services that already mostly exist and are required to satisfy the end user requirements. These services are provided by the sub-service providers and are mostly implemented using non-im@gine IT specific interfaces Traffic information services Traffic information services publish planned and/or real time data, which is related to road traffic. Traffic information can be available in two major formats: traffic events, coming with their own location and description: accidents, incidents, road works, queues, etc.; and travel times, e.g. the measured traveling time of vehicles moving on the road network. Traffic events are normally collected by the road network operator(s), that is authorities or private companies managing specific (kind of) roads. Most European countries have national Traffic Information Centres or Traffic Control Centres which are responsible for coordination and management of whole/part of the road network of the single countries. The scenario is quite varied, however, as data can be integrated/improved by other sources such as: local/regional administration, road police, private initiatives. August

26 Network travel times can be measured directly, e.g. by sensors embedded in the road: this is the case with some (sub-)urban areas, and is normally managed by the local administration (municipality), such as in Turin. Travel times can also be deduced indirectly by processing data of position and speed of fleet of individual vehicles. This approach is less accurate and requires large fleets of vehicles, but in principle it can be put in place by anyone. Depending on the technical environment, either approach can produce accurate real time information or may be used just for building historical databases and profiles of travel times. In the past (early/mid 90s), the EC already recognized the need for harmonization in the exchange this field and promoted several initiatives. The most notable outcome is DATEX a messaging protocol for the exchange of traffic-related information, which became a EU standard and has been implemented throughout Europe. The work in DATEX was closely related to other existing standards, such as RDS-TMC a protocol for the delivery of traffic related information on-the-air over the RDS data channel and to the ALERT-C location coding scheme. Traffic events and travel times are complementary, in the sense that the QoS is maximized when both are actually used. Traffic Information services as they are intended in IM@GINE IT concentrate on individual traffic events, since this is the form which is immediately understandable by any end-user who receive this information on their personal device. Hence, Traffic Information services deliver the location and textual description of the single events, as well as complementary information useful for the accurate rendering of this information to the user. Travel times are also included in the IM@GINE IT experimentation. In fact, some of the routing services internally make use of network travel times in order to find the best route according to the current traffic conditions in the involved areas. Here the service provider is actually operating a synthesis between the routing service and the travel time traffic information. Four service providers are involved that cover three of the five Pilot Sites. 5T provides real-time (sub-)urban traffic information for the city of Turin as well as the surrounding area. 5T can provide information about queues, accidents and incidents as well as road works and restrictions. Number of events averages 10, with a peak of 20. Mizar Mediaservice provides real-time information for Italy, on motorways ( autostrade ) and national roads ( strade statali ). Traffic information includes position and extent of queues, accidents and incidents. Number of events averages 300, with a peak of 450. PTV provides real-time traffic information covering German roads and highways. PTV can provide information about viability condition, position and length of queues, accidents and road works. Number of events averages 500, with a peak of 800. August

27 Topolisz provides planned traffic-related information on Hungary, such as restrictions and road works and expected weather conditions. Number of events averages 30, with a peak of 50. Events will be positioned thanks to their coordinates, as the TMC/ALERT location coding is not common among the providers and is not really handy in order to match information with the user s current position. Thus, information shall be searched by indicating the geographical area of interest and/or the type of event. As explained above, each provider may collect and organize information coming from several sources and is responsible for its quality and homogeneousness. Each provider may consider providing information, which is actual (= collected) or as predicted (= expected due to historical analysis). Providers shall be in charge of validating of the events, that is detecting and removing out-of-date, inaccurate information. The client, e.g. the MAS, can now access a distributed database of traffic events that are published homogeneously by the different providers. The concept of a logical platform, which was partially available even before the project, is hereby enforced. In the future, further content/service providers may join this context covering traffic information for the other sites or even for other areas not included among the IM@GINE IT project. New providers may also provide traffic information for the areas already covered by existing providers, thereby promoting competition Multi-modal Routing/Mapping services The Routing/Mapping services provide the end user with two geo-referenced tools: A comprehensive route list (see figure 11). This route list comprises the travel details in text and icon format of the journey planned by the user. A high level of detail (which will include for example the in-door routing of Frankfurt Airport) indicates also a good quality of service. The route list shows the user the first time whether his route is completely covered by the service or not (if he knows his route). Overview maps and detailed maps. The calculated route can be visualized on maps. Single parts of the route (e.g. in-door) can be covered by more detailed additional maps. Such a map can be retrieved for example by clicking on the respective icon in the textual description. August

28 Figure 10: Web based prototype of Inter-modal router. The above figure shows a Web based prototype of the IM@GINE IT inter-modal router. At the time of the preparation of this deliverable the Product or Travel Mode PLANE was not yet implemented. The user can select his start and destination in two different ways. He can either enter a start and destination address, or he can click on a certain location in a map. In the below route list (figure 11) it is shown, that the router selects the next train station (with train as selected travel mode) to the destination which was again selected interactively from a map. August

29 Figure 11: Web based prototype of Inter-modal router (airplanes not yet included). Similar to the other services the mapping service of the project is provided by different partners located in different regions of Europe. However, in no other service this will be so obvious to the end user: the maps will consist of different map layouts, colors and icons. In addition, no other service (except the routing service) reveals in such a obvious way whether a travel chain is comprehensively covered by a service or not. For example, if a user plans a trip from his home door to a meeting in some other city of Europe, the quality of the service can be measured according to the availability of information throughout the trip. Black holes during trip planning will be a poor sign for quality in future. On the level of demonstration the IM@GINE -IT project thus tries to close the missing gaps in such a comprehensive travel chain for the first time. Always depending on the availability of data the consortium is convinced to be able to demonstrate scenarios in which a traveler will have almost 0 % uncertainties regarding remaining time, distance and direction information for his trip. The mapping service (for services see also D1.2) builds on standardized mapping functions such as Scrolling, Zooming and Panning. The map size is dependant on the device on which it shall be displayed. As all project services are based on Web services, this is done automatically with the request for a map. The area that shall be displayed in a map is defined by the so called Bounding Box which describes the geographical borders of a map. These are mostly default values within the service. The output can be either GIF, BMP, JPG or PNG files retrieved from a URL, or a binary stream that comes with the service response. One step ahead of mapping is always the geo-referencing of a certain position. This is also the reason why geo-coding is not described as a separate service. Geo-coding supports the standard formats such as WGS84 (Geo-Decimal and Geo-Min-Sec), MERCATOR and SUPERCONFORM. Other formats such as the Finish system KKJ 3 are possible but not implemented, as it is not used outside Finland. As GALILEO is August

30 not yet available and no mobile network operator is participating in the consortium, logical localization is restricted to travel mode dependant localization. This means for example, that through agent technology and the GPS signal the user can be localized on his trip. If the system knows that the user is currently on the road according to his schedule, it can push related information such as traffic information onto the users mobile unit in the car. The following two figures are an example on how the project aims to close the above described Black Holes in a travel chain (see also Figure 10). Figure 12: Modelling an in-door map in VISUM (Frankfurt Airport). Up to today travel services have not been able to show maps of complex buildings with routing options. At Frankfurt Airport (Figure 12) a prototype of in-door routing will be implemented by establishing a routable network on the background layer of the airport building. Once the service is finalised, the user will have a routing from the car park or the train station to his check-in desk and then to his gate. The route will be visualised by an in-door map and additional icons indicating shops, post offices etc. In the show case of the Athens airport the user will experience in-door localisation with additional information matching his current position. In a travel scenario including for example car train flight - car the user will have a closed chain of information throughout his trip. August

31 Figure 13: Centralised content editing from distributed sources. Figure 13 shows a prototype of a Web based database in which content owners are able to manage their POI and other geographical content, including networks. This way it is possible for example to provide the user an integrated routing network that is based on different sources, such as the integration of a bicycle network with a car network. Without giving their content away, content providers are able to add and modify their networks where necessary. From a technical point of view, the operator is editing a certain map segment, makes his changes and writes it back into the database. Special security mechanisms take care of redundancies and multiple access violations Public transport (timetable & routing) related services Public transport related services provide the end user with means of retrieving information on public transport timetables and routing. Included are the available public transport modes in each city or area, e.g. busses, trams, metro and trains. PT routing is overlapping with the Multi-modal routing services, as the currently existing basic content services provide routing information restricted to public transport only. Public transport timetable information tells the end user when a public transport should leave or arrive at a given point of its route. This information is static in nature and contains the planned timetable for each route. However, in real world when a long delay happens or a route is not driven for some reason, this information changes. A construction work might temporarily change routes or timetables. This is August

32 called Dynamic PT Information, which generates event messages that change the static timetable and routing information temporarily. The Public transport related services can be used in different ways by the end user: o By providing a public transport route s code or number, and asking for its timetable: at what times the route leaves. o By providing a stop point, and asking which public transport routes pass by it and at what times. o By providing a start point and destination, and asking which public transport route or routes can be used to travel to the destination from the start point. This is handled by the Multi-modal routing services in the IM@GINE IT project Touristic information services The touristic information services provide the end user with current touristic attractions and general information within a particular region. Such information is anything that a tourist usually needs when traveling or visiting a foreign city or country: accommodation, attractions such as museums, sightseeing, historical places, food & drink and entertainment. The above mentioned information is stored as Points of Interest (POI) by the basic content service providers, assigning the given information to a spot by coordinates and possible other specifying information. A single POI can happen between a given time, as is the case with for example entertainment events. POIs can have all sorts of extra information, like price, recommendations or instructions. Part of the Touristic information services is Hotel booking service, that provides the end user with the possibility of checking room availability and reserving accommodation within a region of interest. The Hotel reservation service makes it possible to make an online reservation. The Touristic information services can be used in different ways by the end user: o By providing a bounding box : given a set of coordinates, the services return all the POIs within the rectangular area. o Proximity search: By providing coordinates, the service returns all the POIs in vicinity of the point. o By providing keywords or other search parameters: given a set of parameters, the services return all the POIs that could interest the end user. o By querying room availability of a given hotel. o By reserving a room or other accommodation online with the system. August

33 Synthesis of business domains services However, the market situation is such that the services of each business domain are not stand alone or independent, but are used in an interchangeable manner in order to cater for the satisfaction of end user s requests. Figure 14 describes the relationship between business domains, users and market players. Every market player can offer a set of services to one or more certain business domains, that is, for example, a routing service can be offered by more than one market player to more than one business domain (e.g. touristic services, telematic services). The end user is free to not only select the business domain but also the service he wants to use. In IM@GINE IT the flexibility of this choice is guaranteed by the agent platform, which selects the most optimal service out of a service portfolio in each business domain. Figure 14: Business domains in a service environment. IM@GINE IT, in fact exploits independent content products (services) in order to provide new services spanning more than one domain, as shown in the following matrix. This is especially true for the routing & mapping domain, which obtains input from and provide outputs to all other domains; IM@GINE IT is essentially a trip planning and routing application. August

34 Traffic information Multi-modal routing & mapping Public transport information Touristic information Traffic information Dynamic routing car NA NA Multi-modal routing & mapping Georeferenced traffic events Georeferenced PT events Georeferenced POI and events Public transport information Touristic information NA PT routing NA NA POI mapping NA Table 4: Cross-fertilisation of business domains in IT Data Management Module (DMM) Operation In some cases, the basic content services are not direct service providers to the IT project MAS level, so their contents and interfaces are transformed into a Web Service by a Service Provider. These Web Services interfaces are going to be designed using the IM@GINE IT Ontology, thus making them directly compatible with MAS. Service Providers can aggregate a set of basic content services as one Web Service. For example TIETOTALO acts as a Service Provider and aggregator for Finnish region Touristic Information services. TIETOTALO s DMM will aggregate POI information content from GoFinland and FTB using (proprietary) interfaces, transforms the information into the IM@GINE IT Ontology format and allows MAS to connect to a single point Web Service with standard interface. In these cases, the Ontology mapping does not take place between MAS and the Service Provider. Instead it takes place between the DMM and Service Provider IM@GINE IT basic content services documentation Identification of basic content required The satisfaction of the use cases, mentioned in the previous sections, requires a wide set of content services being available at different geographic locations. The basic services identified are: o Reservation service of flight / train. August

35 o Reservation service of hotel. o Reservation service of car rental. o Geocoding service. o Mapping service. o Dynamic car and pedestrian routing service. o PT routing service. o Traffic information service. o POI and event search service. o Public transport time table information. o Dynamic PT information. o Parking availability. o Navigation. With the term basic content services are meant all those simple but autonomous pieces of information required to satisfy a complex end user request (i.e. as deriving from the System Use Case listing). The above-mentioned list of basic services was described and specified in deliverable D1.2: Service specification. A complete and complex travel chain consists at a minimum of the following items: o Inter-modal travel segments that can be processed one by one (car segment, foot segment, plane segment, train segment, ship segment, bicycle segment, tram or subway segment, in-door segment, etc.). o Static information about each segment, for example type and accessibility. o Dynamic information about each segment, for example traffic or time table information. Dynamic information has to be considered for push services in order to inform the user about changes without his interaction Basic content Service organisation within IM@GINE IT A basic content service documentation of IM@GINE IT relevant services follows in Annex A. The following table presents the content and service providers relevant to the IM@GINE IT system. HACON Content and Service Providers Provider Content/Service PT Time table information, PT routing August

36 Content and Service Providers Provider Content/Service TIETOTALO PT Time table information BMS Traffic Information FRAPORT Airport information 5T PT time table information, traffic information Others Traffic information Top-Map Geographic Data MTC Time tables and PT route information GoFinland Hotel and touristic information Finnish Tourist Board (FTB) Accommodation, attraction and events information PTV Map data and car routing, traffic information, POI information MMS Mapping, routing, traffic information, POI information AIA Dynamic Flight information (Push service) Airport information TREDIT Inter-urban PT Time Table information/ Trip Planning Urban PT time table information (for specific routes and modes in Athens) HIT POI Information TOPO Mapping, routing, PT and POI information FŐVINFORM Car routing information BKV PT information TeleAtlas POI and event information Table 5: IT content and service providers. Services Test Beds Germany Finland Greece Italy Hungary Reservation of flight / train NA NA (AIA) NA NA Hotel Reservation NA TIETOTALO NA NA NA Car Reservation car NA NA NA NA NA Geocoding service PTV PTV PTV MMS TOPO Mapping service PTV PTV PTV MMS TOPO Dyn. car and ped. routing PTV PTV PTV MMS TOPO PT routing service HACON TIETOTALO TREDIT Na TOPO Traffic information PTV NA NA MMS NA POI and event search PTV TIETOTALO HIT MMS TOPO PT time table information HACON TIETOTALO TREDIT 5T TOPO Dynamic PT information HACON NA AIA 5T NA Parking availability NA NA NA NA NA Navigation PTV/DC NA NA MMS/CRF NA User account administration service NA NA NA NA NA NA: not available. Table 6: Basic content services per test site and content provider IM@GINE IT web services identification & documentation Identification of web services required The following list includes the entire suite of web services that could be used by the MAS, for synthesising system use cases: August

37 o Reservation of flight/train. o Hotel reservation. o Geocoding service. o Mapping service. o Car & pedestrian routing service. o PT routing service. o Traffic event information. o POI & event search. o PT timetable information service. o Dynamic PT information service. All services mentioned in the above list have been defined within the ontology, modelled and mapped to actual service instances by specific service providers Identification of service instances The following table presents the identified service instances per IM@GINE IT service provider. Service instances Services PTV MMS TIETOTALO TREDIT TOPO Reservation of flight/train Hotel X reservation Geocoding X X X X X service Mapping X X X X X service Car & X X X X X Pedestrian routing PT routing X X X X Traffic event information POI & event information PT time table information Dynamic PT information X Table 7: Service instances. X X X X X X X X X X X X X X August

38 The mapping of the above-mentioned service instances to the IT ontology is performed in section Web service organisation in IT The following table presents the web services instances per test site. The Service Provider shows the partner responsible for providing or aggregating the services to MAS level. The Content (sub-service) Provider shows the individual content providers, which the Service Provider connects to. Services Reservation of flight / train Hotel reservation Geocoding service Mapping service (Dynamic) car and pedestrian routing PT routing service Traffic information POI and event search PT time table information Dynamic PT information Service provider Content Providers Service provider Content Providers Service provider Content Providers Service provider Content Providers Service provider Content Providers Service provider Content Providers Service provider Content Providers Service provider Content Providers Service provider Content Providers Service provider Content Providers Service Aggregators and Content Providers Germany Finland Greece Italy Hungary N/A N/A N/A N/A N/A N/A TIETOTALO N/A N/A N/A GoFinland PTV PTV TREDIT MMS TOPO PTV PTV PTV TOPO PTV PTV TREDIT MMS TOPO PTV PTV PTV TOPO PTV PTV TREDIT MMS TOPO PTV PTV PTV ÚTINFORM FŐVINFORM TREDIT PTV TIETOTALO 1) N/A TOPO HACON MTC INTELLECT project BKV PTV N/A N/A MMS,5T N/A Various Various PTV TIETOTALO TREDIT MMS TOPO PTV PTV GoFinland FTB TIETOTALO TREDIT TeleAtlas, MMS TOPO TREDIT 2) 5T TOPO HACON MTC TREDIT BKV PTV N/A TREDIT 5T N/A HACON AIA (Flight only) Table 8: Service providers and sub-service providers (basic content providers) per test site. Remarks: 1. Inter-urban PT modes trip planning including railway, maritime and flights. August

39 2. Inter-urban PT modes trip planning including railway, maritime and flights. Also urban (Athens) PT timetable information for buses/metro leavingapproaching the airport, and flight schedules from/to AIA. The following table presents the availability of web services per service provider. Business Domain Mapping Service Service Provider - Geocoding service Service Provider Traffic Information - Service Provider Dyn. Car and ped. routing - Service Provider PT Routing service Web Service availability per Country Germany Finland Greece Italy Hungary IT Mizar Mediaservice sdl PTV PTV TREDIT [PTV] MMS TOPO PTV PTV TREDIT [PTV] MMS TOPO PTV N/A N/A Mizar Mediaservice sdl MMS, 5T in Turin sdl PTV PTV TREDIT [PTV] MMS TOPO PT Journey Planner, pas/en/ N/A Service Provider PT Time Table Information - Service Provider Dynamic PT Information Service Provider - Tourism Information and Hotel Res. Service Provider - PTV TIETOTALO TREDIT N/A TOPO PT Journey Planner, pas/en/ IT PTV TIETOTALO TREDIT 5T TOPO IT PTV N/A TREDIT [AIA] 5T N/A PTV GoFinland, FTB TIETOTALO Table 9: Availability of web services instances. IT TREDIT [TIETOTALO] Mizar Mediaservice sdl MMS N/A TOPO Table 9 lists some already available (or in development stage) Web services, which are listed with web URL addresses. August

40 Partner names in brackets means that service is primarily provided by one partner using another partner s technology: PROVIDER [TECHNOLOGY PROVIDER]. August

41 4. IT Ontology solution 4.1. General overview of Ontology concept Service description is a very important matter in an interconnected world and the semantic web (see W3C, The Semantic Web activity), where it is information systems, not users that access services and proceed with transactions. In order to describe a service in the semantic web one needs an ontology to describe the domain (e.g. in.owl or RDF schema format) and a service description language. Ontologies establish common terminologies between members of a community. These members can be human or automated agents. To represent an ontology a description language is needed. Because XML is the de-facto standard language for data interchange on the web, many ontology description languages are themselves XMLbased, such as DAML-OIL, XOL, OML or RDF. Also, the W3C has nearly finished the definition of a web ontology language (OWL) as a result of the combination of existing languages. This will be probably the pre-eminent standard in the next years. The reasons for choosing this technology are the two major benefits of ontologybased information architectures: First they render possible scalable handling of mismatches on the syntactical, the structural and the semantic level and secondly XML-based Semantic Web Languages are employed and thus information exchange over the Internet as well as transformation for presentation on different end-user devices is enabled. The development of this information mediation architecture will be linked to current standards in web-technologies and contribute to current research in the area of Semantic Web enabled information integration. In well-known world of web services (see W3C, Web Services Activity) this service description language is the well-known WSDL that has been successfully used in order to describe web services. In the world of semantic web services WSDL is not enough. The added value that they propose with regard to WSDL is that in a service provisioning world, the services do not only need to be invoked by other services. They want to model how their invocation modifies the world (e.g. an amount of money changes pockets), provide meta-data regarding their functionality like the offered quality of service (e.g. refresh rate of their data), limitations (e.g. areas that they cover) and optional features. The semantic web services community has tried to address the matter in the past by the DAML-S and now the experimental OWL-S format (Martin, 2004). Their usability and applicability is still unknown and untested in the industrial sector. Thus, we turn to a more applicable and well-tested field, that of agent technology in order to address the matter. Agents can invoke web services but also have the communication languages and performatives needed in order to define service advertisements, create such repositories and match service requests to the best fitting provider. The messages that they exchange can be conformant to existing standards, allowing, thus, new agents to use them. Moreover, the messages that they exchange use an ontology in order to define the concepts that they use. August

42 Thus, if a domain has been encapsulated in an ontology it is very easy for agents to exchange information regarding it in a standardized manner. The IM@GINE IT service networks, comprises of web service providers that want to disseminate their services in an agent-based service network. The only thing that is missing is a transport and tourism domain ontology that agents will use in order to model all services Ontology implementation & use The IM@GINE IT Ontology captures the elements of the business domains within the project scope, that is the Travel and Transport domains. This step is done by several domain experts, who each concentrate on different concepts of the domains, e.g. POI, PT timetable information, Route, etc. The Protégé ontology tool is used in the IM@GINE IT project in order to implement the ontology definition. In this way it makes it will easily available for JADE agents. Protégé is an open source tool and used in order to export the developed ontology to RDFS and/or OWL. So, the model is exported to all known types and is also used for internal development. The following figures provide some examples on how the ontology can be defined (Protégé tool but also using OWL and UML): August

43 a) Example ontology in Protégé: Figure 15: Example ontology in Protégé. August

44 b) In OWL: <rdf:rdf xmlns:rdf=" xmlns:rdfs=" xmlns:owl=" IT.eu/ontology#" IT.eu/ontology"> <owl:ontology rdf:about=""/> <owl:class rdf:id="coordinates"/> <owl:class rdf:id="boundingbox"/> <owl:objectproperty rdf:id="upperleft"> <rdfs:range rdf:resource="#coordinates"/> <rdfs:domain rdf:resource="#boundingbox"/> </owl:objectproperty> <owl:datatypeproperty rdf:id="x"> <rdf:type rdf:resource=" <rdfs:domain rdf:resource="#coordinates"/> <rdfs:range rdf:resource=" </owl:datatypeproperty> <owl:functionalproperty rdf:id="lowerright"> <rdfs:range rdf:resource="#coordinates"/> <rdf:type rdf:resource=" <rdfs:domain rdf:resource="#boundingbox"/> </owl:functionalproperty> <owl:functionalproperty rdf:id="y"> <rdfs:domain rdf:resource="#coordinates"/> <rdfs:range rdf:resource=" <rdf:type rdf:resource=" </owl:functionalproperty> </rdf:rdf> c) In UML: Coordinates -X : float -Y : float Bounding Box -upperleft : Coordinates -lowerright : Coordinates The java sources produced by PROTÉGÉ tool are then product of WP3. This product is available to service providers that would like to use the mature transport and tourism ontology along with the service descriptions in order to implement new services (e.g. Topolitz). Therefore there are two uses for them, one for WP3 and another for service providers to be. In WP3 the provider agents use the generic services descriptions in their service providing protocols with the broker agent, transforming the input parameters to the web-services specific parameters and then getting August

45 the web-services responses, translating them to the output parameters and providing them to the semantic service network in a unified way. A more detailed description of the technical implementation of ontology will be provided in deliverable D Ontology methodological steps Overview of steps taken The D1.2 Services Specification document described the proposed approach to implement an overall project ontology, recommending RDF and OWL as the tools for describing the IM@GINE IT Ontology. This chapter goes into describing the actual objectives and methodology in implementing the proposed approach. The methodology for implementing a methodology is made of few but difficult steps: 1. Start with a sketch of the domain concepts. 2. Gather all existing services and refine the model by adding attributes to the concepts. 3. Make a mapping between all services and the ontology. A domain expert usually does the first step. He/she identifies all key concepts (e.g. coordinates, route, traffic event, POI, etc) and models them using an ontology description language (UML, RDF schema, OWL, etc). Then in step 2 the modeller enters the real world and tries to make the concepts solid. Therefore he needs to see how they are modelled in services (e.g. coordinates concept has two attributes, x and y that are of type real) and then he can add attributes to his concepts. Finally, in step 3, the modeller gathers all existing services in the domain and maps their inputs and outputs to concepts of his ontology. There are two major hazards that the modeller should try to skip. The first one is to not try to model more concepts than needed because he can easily end up trying to model the whole universe. Secondly, he must have an overall knowledge of the domain, not stick on one found service and define everything based on that because the world is big, different people bring different ideas and he might end up re-defining a developer s UML diagram Ontology implementation modules The above mentioned steps have been implemented following the structured methodology model explained in the following scheme. In this scheme the following Ontology implementation modules are identified: The ontology, in which the needed domain elements are defined. August

46 The abstract service descriptions, including method signatures and metadata descriptions. The definition of the actual services instances, and their input/output parameters mapping to respective abstract service specifications. The mapping of classes between actual services instances to classes of ontology concepts. IT ontology Route POI Public Transport Information Timetable IT ontology: It captures the needed elements of the transport and tourism domains Map to ontology class «metaclass» RoutingServiceMetaClass -Country -CrossborderRoadPoints -SupportedLanguages getroute() +...() IT abstract service specification: It provides abstract method signatures and the service description meta-data (service profile) MMSRoute PTVRoute Output parameter Output parameter «interface» PTV Interface +getroute() : PTVRoute «interface» MMS Interface +getroute() : MMSRoute... Zoom in -> Map to ontology class Im@gine IT service instances: It defines the available services for our project, including their signatures and maps the input/ output parameters to the Im@gine IT ontology. Every service instance must be implementing an abstract service specification The PTV Route elements map to the respective Im@gine IT Route elements PTVRoute Im@gine IT Route Figure 16: Ontology implementation modules. In the following sections, the description of methodology implementation by IM@GINE IT is described, and more precisely the identification of domain elements, the definition and documentation of the IM@GINE IT ontology itself, the abstract service specification and metadata, and finally the mapping of IM@GINE IT service instances to the ontology. Thereafter, the entire set of this documentation is used by WP3 for implementation of the MAS platform and final service delivery. August

47 4.4. Identification of domain elements The following paragraphs describe the results of the first step, analysis of domains by domain experts and identification of their elements, and is the basis for next step: ontology definition Traffic information services The traffic information service realizes the search for traffic messages based on region, street name or bounding box. Traffic messages are treated as (line-based) POI s. See also traffic service meta data list. The gettrafficinfos method retrieves traffic messages for a list of road names. The parameter providerlist is used to specify the set(s) of traffic providers wherein the traffic POI s are searched. The available traffic providers and the available message attributes may be determined using the Preferences Module. With a getregions request the traffic information can be filtered by region (not listed here). Field roadnamelist [String] ProviderList [String]) Language [String] Return Type [POIViewSet] Description List of road names to be searched for traffic messages One or more traffic providers (traffic POI types Optional ISO code for setting the language of the returned traffic messages. If not set, UK-en is used Traffic message POI s for the roads Mapping services Geocoding service The method takes full or partial address information and returns a list of best matching addresses including their coordinates for it. The geocoding may be influenced by setting options in the LocateProperties parameter. The reverse locate (reverse geocoding) method searches for the addresses nearest to a given coordinate. In brackets = DataType Field a [Adress] p [Locate Properties] GeoDataSource [String] ReturnType [Adress List] Description Address to be geocoded Optional properties for geocoding Name of geographic data source List of best matching addresses in decreasing matching quality (the first entry matches best) including their full address and coordinates. If the list is empty, the geocoding was unsuccessful. August

48 Field c [Coordinate] p [ReverseLocateProperties] GeoDataSource [String] ReturnType [AdressList] Description Coordinate to be reverse geocoded Optional properties for reverse geocoding Name of geographic data source List of best matching addresses in decreasing matching quality (the first entry matches best) including their full address and coordinates. If the list is empty, the geocoding was unsuccessful Mapping service The service retrieves a map for a full or partial address and a logical width and height. If POI s should be displayed in the map, the respective parameters have to be set. The returned image is influenced by setting device and type information in the parameter stream. The image is retrieved from an URL, but can also be requested as a byte stream. Field c [Coordinate] width [double] height [double] poiviewsets [POIViewSet] routes [RouteView] p [ImageProperties] geodatasource [String] targetmapname [String] Return Type [MapView] Description Center coordinate of the map Logical width of the map in km Logical height of the map in km Optional list of POI sets to be displayed in the map, may also be an object of the subtype POIViewMapSet to specify additional drawing parameters Optional list of routes to be displayed in the map Dimensions and type of the returned image Name of geographic data source Optional name for resulting map for later referencing Map or URL pointing to the map Public transport (timetable & routing) related services Each of the below fields matches one routing segment. The first part is the current PTV routing service. The second part is the parameters, which may be handled separately, depending on the service. Field Stations [CoordinateList] Rp [RouteProperties] S [POIViewSet] GeoDataSource [String] Return Type [RouteView] CalcType Description Two or more coordinates defining start, via points and destination of the route Properties to be set for influencing route calculation (optional) Optional POI s for corridor search Name of geographic data source Routing result RouteProperties Type of route calculation (static or dynamic) August

49 [RouteCalcTypeEnum] DistanceUnit [DistanceUnitEnum] SpeedProfile [SpeedProfileEnum] Optimization [RouteOptimizationEnum] Time [datetime] UseTimeAsArrival [Boolean] Language [String] RouteDetail [RouteDetailEnum] Dist [DistanceProperties] RequestLine [Boolean] ReMapProperties [RouteElementMapRect] AdditionalInfos [String] AvoidHighways [Boolean] ExcludeFerries [Boolean] Unit of distances for routing result (km, miles) Speed profile (fast car, slow car, ) Option for setting routing preferences (fastest route, shortest route, most economic route) Start time for route. If empty, current time is used If not set or false, the parameter time is considered as start time. If true, time is considered as arrival time Language for routing result texts Option for influencing the details returned in the route description (number of route elements returned) Option to affect the connection of corridor POI s If not set or false, the line in the routing result will be empty. If true, the line is filled Optional properties for calculation of maximap and detailmap sections. If null, the sections are not calculated. Request of additional information for routing results, for internal use only. This parameter should only be used with prior consultation with PTV Option to avoid using highways for routing Option to prevent using ferries for routing Touristic information services POI and event search POI (Point Of Interest) data model describes each POI item as a separate entry with the following information: Field ID Type Name Validity Address Coordinates Description Distinct ID string for POI. This ID will be used to track the updates to a particular POI. Enumerative type of POI, pre-defined list of POI types. Title of POI, string type. Optional: Validity time for POI, may have start and end validity date and time, or either. Validity period is used represent events as POIs. Example: a happening, concert, exhibition. If not defined, POI is considered to be permanent and always valid. Optional: Address of POI, string type. Optional: Coordinates consists of Longitude, Lattitude and Coordinate system (WGS84 on most cases). Longitude and Lattitude are given is degrees x August

50 Field Description Optional Description Optional: Description of POI, string type. Optional list: A list of key-value pairs which define the POI on a more detailed level. Different types of POIs may have different optional parameters, for example a concert may have a ticket price given in the Optional parameters (Example: price=25eur) or an attraction may have a reference to multimedia information (Example: multimediacontent= The search POI method retrieves POI s located in an area defined by a center coordinate. The parameters may be used to specify the set(s) of POI s wherein the POI s are searched. The return type of the method is a list of POIs, containing the POI s of all requested types lying in the specified circle. The amount of results may be reduced using filter parameters. Field c [Coordinate] p [ProximityProperties] s [POIViewSet] Return Type [POIViewSet] Description Center coordinate for the POI search Properties used for circle search Empty POISets containing just the names of POI types to search for and/or sets with external POI s POI s lying around the center Hotel reservation Field Hotel reservation services data model describe a attributes required to check room availability and make room reservations. The terms hotel and room may include all types of resorts available for reservation, such as hostels, cabins etc. The data model consists of parameters required for availability, room reservation and return types for these requests. HotelName Guest RoomType RoomQualifier Product code arrivaldate, departuredate Return Type [makebookingresponse] Return Type [RoomAvailabilityResponse] Description Name of the hotel Hotel guest details (name, credit card, etc) Type of room. (For example Double) Room qualifier (For example standard or superior) Product code (For example RACK or CAMPAIGN) Date of arrival and departure Status of booking request List of available rooms August

51 4.5. Ontology definition & documentation Based on the analysis performed in the previous section, the ontology definition is deployed. The IT Ontology consists of all the necessary elements ( Concepts ) and their attributes gathered by domain experts, worked with Protégé in a standard format, as well as their documentation (definition of relevant classes). The concepts defined are the following: o AgentAction; o Coordinates; o Address; o BoundingBox; o ScreenSize; o POIForMap; o Line; o ClickablePOI; o ImageCoordinates; o Map; o Image; o RouteSegmentDetail; o CoordinatesInCountry; o RouteSegment; o Route; o PublicTransportTimeTable; o OptionalInformation; o LineTimetable; o TrafficEvent; o PublicTransportEvent; o HotelGuestInformation; o HotelAvailabilityResponse; o MakeBookingResponse; For example the POI concept describes a Point of Interest, a place or an event for a tourist. POI is located somewhere, it presents a place or an event that can happen in given timeframe, and it may have several attributes to describe it in more detail. Different and distinct real-life examples are taken under investigation when modelling the POI element. When the concept of POI is clear enough for the modeller, the descriptive attributes are gathered and added to the POI concept with limited types. For example, POI has o A name (String). o A description (String). August

52 o A location (Address fields and coordinates in the given coordinate system). o Several optional attributes such as a supplier, possible price, timeframe for a happening or an event, etc. The documentation of the Concepts follows in Annex B. Some screenshot examples of the modelling of concepts performed in the Protégé follows in Annex C. The full range explanation of Protégé use is described and analysed in the framework of deliverable D Abstract service specification Annex D presents the available services in a unified way using the IM@GINE IT ontology concepts. Only the services that are of interest to the MAS and that will participate in the IM@GINE IT service network are presented herein. The services are described with four attributes: Service name: It is a name for the generic service Service invocation parameters: The parameters that are used for invoking the service. They are separated by commas, while those in parenthesis are optional parameters. Each parameter has a type that refers to the concept with the same name in the IM@GINE IT ontology, followed by a name. A pair of brackets [] after a parameter concept denote that an array of that concept s instances are to be returned (zero or more) Service results: The parameters that are returned by the service. They are separated by commas, while those in parenthesis are optional parameters. Each parameter has a type that refers to the concept with the same name in the IM@GINE IT ontology, followed by a name. A pair of brackets [] after a parameter concept denote that an array of that concept s instances are to be returned (zero or more) Text description: A simple text description of the service (it will also be used for the service profile by the MAS) 4.7. Metadata information required This chapter lists the metadata information required by services. Required metadata is listed here by service types. Metadata of individual service providers service instances is listed below in chapter Dynamic Car and Pedestrian Routing Supported Languages: - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost August

53 - In Euro Adjacent Countries - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Auto-route Connection Points (with other adjacent countries) - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Supported Transportation Means - List of: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY Mapping Service Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost - In Euro Can Draw Lines - Boolean Geocoding Service Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost - In Euro PT Routing Service Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost - In Euro Supported Transportation Means - List of:: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY August

54 Traffic Information Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost - In Euro Refresh Rate - Times of refresh per day POI and Event Information Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost - In Euro Refresh Rate - Times of refresh per day Available POI Types - List of available POI Types PT Time Table Information Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost - In Euro Refresh Rate - Times of refresh per day Dynamic PT Information Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international August

55 Service cost - In Euro Refresh Rate - Times of refresh per day Hotel Reservation Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL) Area covered - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service cost - In Euro 4.8. Mapping Service instances to IM@GINE IT Ontology Mapping services to IM@GINE IT ontology Ontology Name PTV TIETOTALO TREDIT MMS TOPO geocodeaddress locate same as PTV same as PTV findaddress GeoCode createmap getmap same as PTV same as PTV getmap DrawMap createroute getroute same as PTV same as PTV findroute Route gettrafficevent GetRoadsWithMess ages, getroute NA NA gettrafficinfo GetTrafficEvent proximitysearch GetRoute, getmap proximitysearch NA findpois PoiSearch getpoiinfo SeachPOI, getmap, getroute getpoiinfo same as TIETOTALO GetParkInfo GetPoiInfo getpttimetable getroute getpttimetable getpttimetable getpttimetable GetPTTimeTabl e getptevent NA NA GetDynamicFlightI nfo getptevent NA Table 10: Matching service instances to abstract service descriptions. August

56 Detailed service instance mappings to the IT Ontology are presented in Annex E Metadata information for service instances In this section, the needed meta-data descriptions of all available services are presented. MMS MMS Services Dynamic Car and Pedestrian Routing Metadata field Supported Languages Area covered Service Cost Adjacent Countries Auto-route Connection Points (w/ other adjacent countries) Supported Transportation Means Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro NA NA List of: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY MMS Mapping Service Metadata field Supported Languages Area covered Service Cost Can Draw Lines Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro Boolean MMS Geocoding Service Metadata field Supported Languages Area covered Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international August

57 MMS Geocoding Service Metadata field Service Cost Metadata content in Euro MMS PT Routing Metadata field Supported Languages Area covered Service Cost Supported Transportation Means Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro List of: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY MMS Traffic Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro NA MMS POI and Event Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Available POI Types Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro NA NA August

58 PTV PTV Services Dynamic Car and Pedestrian Routing Metadata field Supported Languages Area covered Service Cost Adjacent Countries Auto-route Connection Points (w/ other adjacent countries) Supported Transportation Means Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro NA NA List of: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY PTV Mapping Service Metadata field Supported Languages Area covered Service Cost Can Draw Lines Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro Boolean PTV Geocoding Service Metadata field Supported Languages Area covered Service Cost Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro PTV PT Routing Metadata field Supported Languages Metadata content List of country codes August

59 PTV PT Routing Metadata field Area covered Service Cost Supported Transportation Means Metadata content List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro List of: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY PTV Traffic Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro NA PTV POI and Event Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Available POI Types Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro NA NA PTV PT Time Table Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Metadata content List of country codes List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international in Euro NA August

60 PTV PT Time Table Information Metadata field Metadata content Supported Languages List of country codes (ISO 639-1) PTV Dynamic PT Information Metadata field Metadata content Supported Languages List of country codes Area covered List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL), INT for international Service Cost in Euro Refresh Rate NA Supported Languages List of country codes (ISO 639-1) TIETOTALO PT Routing TIETOTALO Services Metadata field Supported Languages Area covered Service Cost Supported Transportation Means Metadata content FI, GB FI NA List of: PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, TRAIN TIETOTALO POI and Event Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Available POI Types Metadata content FI, GB FI NA Once/day Accommodation, Sight, Attraction TIETOTALO PT Time Table Information Metadata field Supported Languages Metadata content FI, GB August

61 TIETOTALO PT Time Table Information Metadata field Area covered Service Cost Refresh Rate Metadata content FI NA Once/day TIETOTALO Hotel Reservation Metadata field Supported Languages Area covered Service Cost Metadata content FI, GB FI Depending TREDIT Services TREDIT Dynamic Car and Pedestrian Routing Metadata field Supported Languages Area covered Service Cost Adjacent Countries Auto-route Connection Points (w/ other adjacent countries) Supported Transportation Means Metadata content GB, GR Athens, Thessaloniki in Euro NA NA List of: CAR, PEDESTRIAN TREDIT Mapping Service Metadata field Supported Languages Area covered Service Cost Can Draw Lines Metadata content GB, GR Athens, Thessaloniki in Euro Boolean TREDIT Geocoding Service Metadata field Supported Languages Area covered Metadata content GB, GR Athens, Thessaloniki August

62 TREDIT Geocoding Service Metadata field Service Cost Metadata content in Euro TREDIT PT Routing Metadata field Supported Languages Area covered Service Cost Supported Transportation Means Metadata content GB, GR Greece in Euro List of: BUS, AIRPLANE, TRAIN, FERRY TREDIT POI and Event Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Available POI Types Metadata content GB, GR Athens, Thessaloniki in Euro NA NA TREDIT PT Time Table Information Metadata field Metadata content Supported Languages GB, GR Area covered Greece Service Cost in Euro Refresh Rate 1 time/day Supported Languages List of country codes (ISO 639-1) TREDIT Dynamic PT Information Metadata field Metadata content Supported Languages GB, GR Area covered Athens International Airport Service Cost in Euro Refresh Rate 48 times/day Supported Languages List of country codes (ISO 639-1) August

63 TOPO TOPO Services Dynamic Car and Pedestrian Routing Metadata field Supported Languages Area covered Service Cost Adjacent Countries Auto-route Connection Points (w/ other adjacent countries) Supported Transportation Means Metadata content INT HU Free of charge for IT pilots. AT;SI;HR;CS;RO;UA;SK AT;SI;HR;CS;RO;UA;SK CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT (UPT for Budapest only) TOPO Mapping Service Metadata field Supported Languages Area covered Service Cost Can Draw Lines Metadata content INT HU Free of charge for IT pilots. True TOPO Geocoding Service Metadata field Supported Languages Area covered Service Cost Metadata content INT HU Free of charge for IT pilots. TOPO PT Routing Metadata field Supported Languages Area covered Service Cost Supported Transportation Means Metadata content INT HU Free of charge for IT pilots. URBAN_PUBLIC_TRANSPORT (Budapest only) August

64 TOPO POI and Event Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Available POI Types Metadata content HU;EN HU Free of charge for IT pilots. Car services - Refresh rate per year Banks - Refresh rate per three month Petrol stations - Refresh rate per three month Restaurants - Refresh rate per three month Pharmacies - Refresh rate per year Hotels - Refresh rate per three month Surgeries - Refresh rate per year Monuments - Refresh rate per year Pubs - Refresh rate per three month Post offices - Refresh rate per year Police stations - Refresh rate per year Turist information - Refresh rate per three month ATM - Refresh rate per three month Car services Banks Petrol stations Restaurants Pharmacies Hotels Surgeries Monuments Pubs Post offices Police stations Turist information ATM TOPO PT Time Table Information Metadata field Supported Languages Area covered Service Cost Refresh Rate Supported Languages Metadata content INT HU Free of charge for IM@GINE IT pilots. per day See above August

65 5T T Services PT Time Table Information Metadata field Metadata content Supported Languages IT;GB Area covered IT; Only Turin area Service Cost 0 Refresh Rate 1 Supported Languages List of country codes (ISO 639-1) 5T Dynamic PT Information Metadata field Metadata content Supported Languages IT;GB Area covered IT; Only Turin area Service Cost 0 Refresh Rate 5 Supported Languages List of country codes (ISO 639-1) 5T POI and Event Information Metadata field Metadata content Supported Languages IT, GB Area covered IT; Only Turin area Service Cost 0 Refresh Rate 15 Available POI Types Park, Road works, Incidents, demonstrations August

66 5. Conclusions The main objective of D2.1.2 is to provide technical documentation of the work performed in project s WP2, and more specifically of the content/service applications implemented. These content/services are provided to the MAS ( System integrator ) through web service communication for further use and satisfaction of the IM@GINE IT use cases. Thus, there is a two-fold aim of this deliverable: Describe and document the services implemented in the framework of WP2. Describe and document the work of actual service ontology definition performed in WP2 and enable the use of implemented services by the system. The following conclusions derive from this work: IM@GINE IT has specified a content flow model, a respective system architecture and an Ontology based technical solution, in order to give the end users a possibility to use a single service to access content information within the selected business domains of Travel & Transport, that are gathered from multiple sources in several countries across Europe. The information aggregation is performed at two levels. One at national level (called Service provider level), at which basic content services are gathered and then synthesised and provided to the next level as web services. The second level is the MAS itself (called Service integrator level), at which the web services are transformed to system use cases. In between the two levels there are a few alternatives as per interfacing (either web service alone or agent based communication), all of which are implemented through the use of an Ontology. The basic content services needed, as well as the web service required for the implementation of the content flow model are defined, described and documented. The approach followed included a top down approach, in which the Travel & Transport domains are de-composed into more specific business domains such as Traffic information, routing & mapping, public transport information and finally touristic information. These areas are looked into in more detail and service instances are identified. Their specific end user related functionalities and content are listed. Furthermore, the availability and organisation of both the basic content services and web services within the IM@GINE IT project has been defined. The conclusion is that there is a great diversity and full completeness of the required content for satisfying test cases at Germany, Italy, Finland, Hungary and Greece, while other European countries can be also covered. The ontology concept adopted by IM@GINE IT (the ontology framework was described in deliverable D1.2) is implemented, in cooperation with WP3, through a specific methodology developed by the project. The Ontology model, a way of using or transforming existing information into a common terminology, includes: capture of the Travel & Transport domains elements, August

67 documentation of the domains (ontology definition), description of abstract service specifications (i.e. what are and how the ontology understands the services of the domains), metadata description, and more importantly, mapping of specific service instances to the ontology (output web service parameters and classes). The ontology is modelled in the Protégé tool, and thereafter the java classes produced are used by WP3 for implementing the provider agents, which are the entry point for the IT MAS. Besides its use in the project, the ontology can be used as a basis for future service providers developing their own web services (given that their basic content applications exist). The current deliverable provides all the Public Use documentation (technical information) available for specifying the relevant service domain (i.e. Travel & Transport infomobility services), as well as the Ontology model, which could be exploited by various content/service providers across Europe, in view of developing web services or a future semantic service net Innovations The main innovation of D2.1.2 together with the previous work packages is the idea of using ontologies as a communication tool between different existing and future systems. The objective was not to create comprehensive ontology description for the Travel & Transport business domain, but to create a framework which enables applications to work with ontologies. This innovation makes it possible to create an extensible system which combines data and functionality from heterogeneous applications under one extensive application. The difference between the ontologybased solution compared to typical data structures is the transformation of different kind of data and interfaces into a common base, which is the ontology itself. This allows the application, MAS in IM@GINE IT s case, to be extended more easily in the future by extending the ontology and by connecting new services into it. The idea of using ontologies in applications to describe data and functionalities is not in any way limited to the scope of Travel & Transport domains, but could be taken into wide use in other domains as well. The way the ontology framework is designed and described in D1.2 allows data and services to be combined from multiple sources even if they differ largely, as long as an agent can be designed to handle the ontology transformation. August

68 6. References JADE Java Agent Development Environment, Protégé, An Ontology Editor and Knowledge Acquisition System. Martin, D. (editor): OWL-S: Semantic Markup for Web Services. W3C Member Submission, 2004 The World Wide Web Consortium (W3C). The Semantic Web activity The World Wide Web Consortium (W3C). Web Services Activity, D1.1. Use Cases and User/Vehicle Profile Requirements, IT project D1.2. Services Specification, IT project D1.3. System Architecture, IT project August

69 7. Annex A: IT Basic content services documentation 7.1. Traffic Information service instances 5T Description Sources Covered area Covered street types Languages supported Standards Publication method XML availability Suggested PUSH request frequency Number of events Event types supported 5T Transport and Traffic Information services supply information about the real time situation of Turin roads viability situation, travel time, position and length of queues, accident, road works, P.T. transport network situation, timetable, travel time, service disruptions. The service are available via a dedicated web site. 5T systems, Municipality police and municipality viability offices Turin Urban Italian & English Datex, RDS TMC Http, html No 15 Minutes Average: 10 Peak: 20 ACC, INC, LOS, RES, RMT, Event types (data objects) supported: please indicate the event types using the following data object codes: Data Object Code ACC ACT APL EQU EXH FOS INC LOS MHZ OHZ OPA PRE RES Event Description Accident Activities Action Plan Traffic Equipment Status Exhaust pollution Fog/smoke/dust Incident Level of service Moving hazards Obstruction Hazards Operator Actions Precipitation Traffic Restrictions August

70 Data Object Code RMT ROU SHZ SNE SNO WDA WIN Event Description Road works Rerouting Skid hazards Snow/Ice Equipment Snow on the road(s) Weather data Wind PTV Description Sources Covered area Covered street types Languages supported Standards Publication method XML availability Suggested PUSH request frequency Number of events Event types supported PTV Traffic Information services provide availability of traffic data details as date of event, source of information, involved road stretch with the indication of the direction, description of the event. PTV supplies information about the real time situation of road and highway viability situation, travel time, position and length of queues, accident and, road works. ADAC, BMS/PTV TIC-NL, GEI, Traffic First, ITIS, (TRAFFIX), ORF Germany, Switzerland, UK, France, NL, Austria German road network including cities German, English TMC FTP, Web service yes 5 min Average: Peak: 800 Event code table. Table 11: Traffic Information Services provided within the project by Service Provider partners Routing/Mapping Service instances PTV Description Sources Content Covered area The mapping service covers the test sites of Germany, Greece and Finland. Navteq, PTV Road geometries, area layers, POI Central Europe, parts of Scandinavia and parts of Greece August

71 PTV Languages German, English, others supported Standards Navteq (GDF), PTV Publication method Web service SOAP/XML XML availability yes Update frequency Half year MMS Description Mapping service Sources MMS Content Road geometries, area layers, POI Covered area Italy, Germany, Austria, France, Switzerland, S.Marino, Monaco Languages Italian supported Standards Publication method Web service SOAP/XML XML availability yes MMS Description Sources Content Covered area Routing service MMS Road geometries, area layers Italy, Germany, Austria, France, Switzerland, S.Marino, Monaco Public transport routing is supported in Turin Italian Languages supported Standards Web service SOAP/XML Publication method Web service SOAP/XML XML availability yes TIETOTALO Description Ministry of Transport and Communicatons and Helsinki Metropolitan Area Council offering PT information, Sources Ministry of Transport and Communications (MTC)/Helsinki Metropolitan Area Council Content PT routing (Only public transport modes supported) Covered Helsinki Region (Nationwide later 2005) area Languages FI, EN supported Standards XML Publication Http, html method XML Yes availability August

72 TIETOTALO Update Static, 1 month frequency TOPO Description TOPO has a pre-trip routing service for cars in the whole Hungary (country road network and settlements) and for PT in Budapest. Only planned (kvazi)dynamic data are built in, such as planned road restrictions, planned events, planned time table changes, meteorological information connected to a time period. These kinds of data are put into dynamic database once or two times every day. Sources The sources of the data are the following: for country road network ÚTINFORM (Hungarian Road Information Board), for Budapest street network FŐVINFORM (Budapest Traffic Information Board), for public transport BKV (Budapest Public Transport Company) Covered area Covered street types Languages supported Standards Publication method XML availability Suggested PUSH request frequency Number of events Event types supported Static data: navigation map for the whole Hungary including each settlement. Dynamic data: for country road network and Budapest only. All in covered area Hungarian, English, German TMC in advance (not implemented yet) Internet: WAP Planned for next year Twice pro day Average: 30 Peak: 50 FOS,RES,RMT, SNO,WDA PTV Description The PT routing service covers different travel modes, thus offering inter-modal features to the end user. Sources PTV, HACON, Content Road networks, pt train data base, flight data base Covered area Similar to map service. Higher coverage with flight data, less coverage with pt data (mainly national agencies) Languages German, English, other supported Standards NA Publication method Web service SOAP/XML August

73 PTV XML availability Update frequency Yes Depending on release dates Table 12: Mapping/Routing Services provided within the project by Service Provider partners Public Transport related service instances TIETOTALO Description Ministry of Transport and Communicatons and Helsinki Metropolitan Area Council PT information, Sources Ministry of Transport and Communications (MTC)/Helsinki Metropolitan Area Council Content PT timetables Covered Helsinki Region (Nationwide later 2005) area Languages Finnish, English supported Standards XML Publication Web service, Proprietary XML interface, web interface method XML Yes availability Update Static, 1 month frequency 5T Description Public transport information Sources 5T Content PT timetables Covered Turin area Languages Italian, English supported Standards Web service Publication Web service method XML Yes availability Update Once a day frequency TOPO Description Public transport information Sources BKV Content PT timetables August

74 TOPO Covered area Languages supported Standards Publication method XML availability Update frequency Budapest Hungarian Web service SOAP Web service SOAP Yes Once a day AIA Description Sources Covered area Covered Flights Languages English supported Standards - Publication ftp method XML No availability Suggested 2 Minutes PUSH request frequency Number of events Event types supported Flight information service supply real time information regarding incoming and outgoing flights in the Athens International Airport. The information contains static data such as flight id, airline, origin, destination and via points, as well as dynamic data like ETA, ATA, ETD, ATD and remarks. The data is available in ASCII format via an ftp server. AIA server Athens International Airport All (incoming & outgoing) Average: 100 Peak: 300 (???) EXP - Expected Time of Flight Arrival DLY - Flight is Delayed DIV - Flight has Diverted CNL - Flight has been Cancelled XXX - Flight has Landed DEP - Flight has Departed BRG - Flight is Boarding GCL - Gate closed for Flight FNL - Final call for Flight GTP - Gate open for Flight ARR - Flight has Arrived LND1 - Expected Time of Flight Landing August

75 AIA RTN Flight has Return LND - Flight has Arrived NEW Flight has a New Time Table 13: Public transport related services provided within the project by Service Provider partners Touristic Information service instances TIETOTALO Description Finnish Touristic Information service instances are, Finnish Tourist Board offering accommodation, attraction and event information and Go Finland offering accommodation information, POI information and hotel reservation service. Sources Finnish Tourist Board (FTB) Go Finland Content Accommodation, attraction Accommodation, Point of interest and event information information, hotel reservation Covered Finland Finland area Languages English Finnish, English supported Standards XML Java (Hotel reservations), XML (POI information) Publication FTP based XML feed HTTP based XML feed method XML Yes Yes availability Update frequency Once a day MMS Description Touristic information offered through MMS Sources MMS Content Point of interest information Covered Italy area Languages Italian supported Standards Web Service/SOAP Publication Web Service/SOAP. method XML Yes availability Update Once a day frequency POI information once a day Real time accommodation reservation and availability August

76 PTV Description Touristic information offered through PTV Sources PTV Content Point of interest information Covered Germany area Languages German, English supported Standards Web Service/SOAP Publication Web Service/SOAP. method XML Yes availability Update Once a day frequency Table 14: Touristic information services provided within the project by Service Provider partners. August

77 8. Annex B: IT Ontology definition (documentation) 8.1. Class AgentAction Abstract Class Extends Concept Direct Instances: None Direct Subclasses: None Class Documentation: The common ancestor for all actions in an ontology (e.g. Sell, Buy...) 8.2. Class Coordinates Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Class Documentation: these refer to WGS84 coordinates format Template Slots Slot name Documentation Type Allowed Values/Classes hascoordinatex Integer 1:1 hascoordinatey Integer 1:1 hascoordinatez Cardinality Default 8.3. Class Address Concrete Class Extends Concept August

78 Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes incity String 0:1 onstreet String 0:1 withstreetnumber String 0:1 haspostalcode String 0:1 indistrict String 0:1 Cardinality Default forcountry String 0: Class BoundingBox Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hasupperrightcoordinates Instance Coordinates 0:1 haslowerleftcoordinates Instance Coordinates 0:1 Cardinality Default 8.5. Class ScreenSize Concrete Class Extends Concept Direct Instances: None August

79 Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes haspixelswidth Integer 0:1 haspixelsheight Integer 0:1 Cardinality Default 8.6. Class POIForMap Concrete Class Extends Concept Direct Instances: None Direct Subclasses: POI Template Slots Slot name Documentation haspoitype More concepts than the POI share this slot. We must have a complete list of POI types that sum up the whole spectrum of POI types. Then each service must map the POI types described here to its own encoding. Moreover, a POI can have more than one types (e.g. bank+atm, or hotel+restaurant) Type Allowed Values/Classes String 0:* hascoordinates Instance Coordinates 0:1 haspoiname String 0:1 Cardinality Default August

80 Template Slots Slot name Documentation Type Allowed Values/Classes haspoiid String 0:1 Cardinality Default 8.7. Class Line Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hasorderedcoordinateslist Instance Coordinates 0:* Cardinality Default 8.8. Class ClickablePOI Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes haspoiname String 0:1 hasimagecoordinates Instance ImageCoordinates 0:1 Cardinality Default August

81 8.9. Class ImageCoordinates Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hasxpos Integer 0:1 hasypos Integer 0:1 Cardinality Default Class Map Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hasboundingbox Instance BoundingBox 0:1 showspois Instance ClickablePOI 0:* hasimage Instance Image 0:1 showsroute Boolean 0:1 Cardinality Default Class Image Concrete Class Extends Concept August

82 Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hasurl String 0:1 hasfileformat Type of image, e.g. GIF, JPG, etc String 0:1 Cardinality Default Class RouteSegmentDetail Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hasdestination Instance Coordinates 0:1 isusingmeans this is the street name for pedestrians and car (e.g. "boulevard romance") and line name for public transport (e.g. "bus 31", or "flight OA 234") probably equivalent to PTLine String 0:1 Cardinality Default August

83 hasdestinationinfo property of RouteSegment this is the next turn information for pedestrian and car (e.g. "turn left") and next stop info for PT (e.g. "next stop - university") String 0:1 hasid Integer 0:1 distance in meters Integer 0:1 duration seconds of travel time for this detail Integer 0: Class CoordinatesInCountry Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hascoordinates Instance Coordinates 0:1 forcountry String 0:1 Cardinality Default Class RouteSegment Concrete Class Extends Concept Direct Instances: None Direct Subclasses: August

84 None Template Slots Slot name Documentatio n Type Allowed Values/Classes Cardi nality hasid Integer 0:1 usingtransporttype String 0:1 routesegmentinformation String 0:1 startson date/time String 0:1 finisheson date/time String 0:1 duration seconds of travel time for this detail Integer 0:1 distance in meters Integer 0:1 startsat finishesat routesegmentreservationinfo routesegmentdetail the place of starting a route segment what is in this field? Instance Instance CoordinatesInC ountry CoordinatesInC ountry 0:1 0:1 String 0:1 Instance RouteSegment Detail 0:* hascost in Euro String 0:1 hasoptimization String 0:1 usingbrand startsatplace finishesatplace PTLine This is the company operating the public transport line or car brand. Name of the starting point eg. Helsinki Railway station Name of the finishing point eg. Helsinki airport bus number, flight number, metro line number String 0:1 String 0:1 String 0:1 String 0:1 routesegmentmapid String 0:1 Default August

85 8.15. Class Route Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes routesegments Instance RouteSegment 0:* distance in meters Integer 0:1 duration seconds of travel time for this detail Integer 0:1 Cardinality Default Class PublicTransportTimetable Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes usingtransporttype String 0:1 startsat startsatplace the place of starting a route segment Name of the starting point eg. Helsinki Railway station Instance CoordinatesInCountry 0:1 String 0:1 timetable Instance LineTimetable 0:* Cardinality Default August

86 8.17. Class OptionalInformation Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots optionalattributename Slot name Documentation Type the name of an optional attribute Allowed Values/Classes String 0:1 withstringvalue String 0:1 Cardinality Default Class LineTimetable Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation PTLine bus number, flight number, metro line number Type Allowed Values/Classes String 0:1 arrivalon Date/Time String 0:1 departureon Date/Time String 0:1 additionalptinfo possibly destination, check counters and gate for airplanes, track for train, dock for ships, etc. String 0:1 Cardinality Default August

87 8.19. Class TrafficEvent Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hascoordinates Instance Coordinates 0:1 additionalinformation String 0:1 trafficeventtype String 0:1 expireson date/time String 0:1 Cardinality Default Class PublicTransportEvent Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation PTLine usingbrand bus number, flight number, metro line number This is the company operating the public transport line or car brand. Type Allowed Values/Classes String 0:1 String 0:1 departureon Date/Time String 0:1 PTEventType e.g. Delay, Cancel, etc String 0:1 Cardinality Default August

88 Template Slots Slot name Documentation additionalptinfo possibly destination, check counters and gate for airplanes, track for train, dock for ships, etc Type Allowed Values/Classes String 0:1 Cardinality Default Class HotelGuestInformation Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes Cardinality Default guestname String 1:1 guestphone String 1:1 guestaddress Instance Address 1:1 guest String 1:1 guestfreetext guesteta Free text information concerning for example arrival Estimated time of guests arrival String 0:1 String 0:1 guestcreditcardtype Credit card type String 0:1 guestcreditcardno guestcreditcardexp Credit card number Credit card expiry date eg. 10/05 String 0:1 String 0:1 August

89 8.22. Class RoomAvailabilityResponse Concrete Class Extends HotelBookingResponse Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type roomqualifier roomtype Room qualifier (e.g. standard) Room type e.q. double Allowed Values/Classes String 1:1 String 1:1 productcode String 1:1 numberofbeds Integer 1:1 datearrival String 1:1 datedeparture String 1:1 totalprice Float 1:1 informationmessage String 0:1 hotelname String 1:1 Cardinality Default Class MakeBookingResponse Concrete Class Extends HotelBookingResponse Direct Instances: None Direct Subclasses: None August

90 Template Slots Slot name Documentation Type Allowed Values/Cl asses Cardinality Defaul t totalprice Float 1:1 hasnumberofpersons Integer 1:1 datearrival String 1:1 datedeparture String 1:1 hasuniquebookingcode String 1:1 productcode String 1:1 roomqualifier roomtype Room qualifier (e.g. standard) Room type e.q. double String 1:1 String 1:1 numberofbeds Integer 1:1 numberofpersons Integer 1: Class GeocodedAddress Concrete Class Extends Concept Direct Instances: None Direct Subclasses: None Template Slots Slot name Documentation Type Allowed Values/Classes hasaddress Instance Address 0:1 hascoordinates Instance Coordinates 0:1 Cardinality Default August

91 9. Annex C: IT Ontology modelled in Protege tool Protégé Classes view August

92 Protégé Slots view August