information s technologies (ist) · level using these ontology specifications. the current...

INFORMATION SOCIETY TECHNOLOGIES (IST) PROGRAMME

IM@GINE IT

IST-508008

Services Documentation Deliverable No. (use the number indicated on technical annex)

D2.1.2 IM@GINE IT services documentation

Workpackage No. WP2 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)

TIETOTALO: Risto Virkkala, Markku Mäkelä, SISO: N. Spanoudakis, MMS: Monica Raimondi, TREDIT: Vasilis Mizaras, PTV: Markus Kauber

Status (F: final; D: draft; RD: revised draft):

F

File Name: IM@GINE IT D2.1.2 after 1st review.doc Project start date and duration 01 January 2004, 24 Months

IM@GINE IT Deliverable 2.1.2 Public Contract N. IST-508008

August 2005 i

List of contents 1. Introduction ............................................................................................. 3

1.1. IM@GINE IT Objectives ........................................................................... 3 1.2. Overview of WP2 work and link with other project work elements ...... 3

2. IM@GINE IT service design and implementation process .................. 4 2.1. Introduction .............................................................................................. 4 2.2. IM@GINE IT end user services................................................................ 4 2.3. Distributed, multi-source and integrated content .................................. 6 2.4. IM@GINE IT Content flow model ............................................................. 7 2.5. Link to MAS – System integrator and ontology solution framework.... 9 2.6. Navigation to the remaining contents of the current report ............... 14

3. Service descriptions and documentation ........................................... 16 3.1. Decomposition of Transport & Travel Content Domains .................... 16

3.1.1. Project objectives in transportation and travel ................................................. 17 3.1.2. IM@GINE IT business domains ...................................................................... 19

3.2. Service domain analysis ....................................................................... 19 3.2.1. Traffic information services ............................................................................. 19 3.2.2. Multi-modal Routing/Mapping services ............................................................ 21 3.2.3. Public transport (timetable & routing) related services ..................................... 25 3.2.4. Touristic information services .......................................................................... 26 3.2.5. Synthesis of business domains’ services ........................................................ 27 3.2.6. Data Management Module (DMM) Operation .................................................. 28

3.3. IM@GINE IT basic content services documentation ........................... 28 3.3.1. Identification of basic content required ............................................................ 28 3.3.2. Basic content Service organisation within IM@GINE IT................................... 29

3.4. IM@GINE IT web services identification & documentation ................. 30 3.4.1. Identification of web services required ............................................................ 30 3.4.2. Identification of service instances .................................................................... 31 3.4.3. Web service organisation in IM@GINE IT ....................................................... 32

4. IM@GINE IT Ontology solution ............................................................ 35 4.1. General overview of Ontology concept ................................................ 35 4.2. Ontology implementation & use ........................................................... 36 4.3. Ontology methodological steps ............................................................ 39

4.3.1. Overview of steps taken ................................................................................. 39 4.3.2. Ontology implementation modules .................................................................. 39

4.4. Identification of domain elements ........................................................ 41 4.4.1. Traffic information services ............................................................................. 41 4.4.2. Mapping services............................................................................................ 41

4.4.2.1. Geocoding service ...................................................................................... 41 4.4.2.2. Mapping service ......................................................................................... 42 4.4.2.3. Public transport (timetable & routing) related services ................................. 42

4.4.3. Touristic information services .......................................................................... 43 4.4.3.1. POI and event search ................................................................................. 43 4.4.3.2. Hotel reservation ........................................................................................ 44

4.5. Ontology definition & documentation .................................................. 45


August 2005 ii

4.6. Abstract service specification .............................................................. 46 4.7. Metadata information required .............................................................. 46

4.7.1. Dynamic Car and Pedestrian Routing ............................................................. 46 4.7.2. Mapping Service ............................................................................................. 47 4.7.3. Geocoding Service ......................................................................................... 47 4.7.4. PT Routing Service ......................................................................................... 47 4.7.5. Traffic Information........................................................................................... 48 4.7.6. POI and Event Information .............................................................................. 48 4.7.7. PT Time Table Information ............................................................................. 48 4.7.8. Dynamic PT Information ................................................................................. 48 4.7.9. Hotel Reservation ........................................................................................... 49

4.8. Mapping Service instances to IM@GINE IT Ontology ......................... 49 4.8.1. Mapping services to IM@GINE IT ontology ..................................................... 49 4.8.2. Metadata information for service instances ..................................................... 50

4.8.2.1. MMS Services ............................................................................................ 50 4.8.2.2. PTV Services ............................................................................................. 52 4.8.2.3. TIETOTALO Services ................................................................................. 54 4.8.2.4. TREDIT Services........................................................................................ 55 4.8.2.5. TOPO Services .......................................................................................... 57 4.8.2.6. 5T Services ................................................................................................ 59

5. Conclusions .......................................................................................... 60 5.1. Innovations ............................................................................................. 61

6. References ............................................................................................ 62 7. Annex A: IM@GINE IT Basic content services documentation ........ 63

7.1. Traffic Information service instances ................................................... 63 7.2. Routing/Mapping Service instances ..................................................... 64 7.3. Public Transport related service instances ......................................... 67 7.4. Touristic Information service instances ............................................... 69

8. Annex B: IM@GINE IT Ontology definition (documentation) ............ 71 8.1. Class AgentAction ................................................................................. 71 8.2. Class Coordinates ................................................................................. 71 8.3. Class Address ........................................................................................ 71 8.4. Class BoundingBox ............................................................................... 72 8.5. Class ScreenSize ................................................................................... 72 8.6. Class POIForMap ................................................................................... 73 8.7. Class Line ............................................................................................... 74 8.8. Class ClickablePOI ................................................................................ 74 8.9. Class ImageCoordinates ....................................................................... 75 8.10. Class Map ........................................................................................... 75 8.11. Class Image ........................................................................................ 75 8.12. Class RouteSegmentDetail ................................................................ 76 8.13. Class CoordinatesInCountry ............................................................. 77 8.14. Class RouteSegment ......................................................................... 77 8.15. Class Route ........................................................................................ 79


August 2005 iii

8.16. Class PublicTransportTimetable ....................................................... 79 8.17. Class OptionalInformation ................................................................ 80 8.18. Class LineTimetable .......................................................................... 80 8.19. Class TrafficEvent .............................................................................. 81 8.20. Class PublicTransportEvent.............................................................. 81 8.21. Class HotelGuestInformation ............................................................ 82 8.22. Class RoomAvailabilityResponse ..................................................... 83 8.23. Class MakeBookingResponse .......................................................... 83 8.24. Class GeocodedAddress ................................................................... 84

9. Annex C: IM@GINE IT Ontology modelled in Protege tool ............... 85 9.1.1. Protégé Classes view ..................................................................................... 85 9.1.2. Protégé Slots view .......................................................................................... 86

10. Annex D: IM@GINE IT Ontology abstract service descriptions ........ 88 10.1.1. Hotel reservation / requestRoomAvailability .................................................... 88 10.1.2. Hotel reservation / makeBooking .................................................................... 88 10.1.3. Hotel reservation / cancelBooking ................................................................... 89 10.1.4. Hotel reservation / requestBookingDetails ....................................................... 89 10.1.5. Hotel reservation / requestRoomTypes ........................................................... 89 10.1.6. Geocoding service .......................................................................................... 89 10.1.7. Mapping service ............................................................................................. 89 10.1.8. Dynamic car and pedestrian routing ................................................................ 90 10.1.9. PT routing service........................................................................................... 90 10.1.10. Traffic information .................................................................................. 91 10.1.11. POI and event search ............................................................................. 91 10.1.12. PT time table information ........................................................................ 91 10.1.13. Dynamic PT information ......................................................................... 91

11. Annex E: Mapping service instances to Ontology ............................. 93 11.1. TIETOTALO's services ....................................................................... 93

11.1.1. Hotel reservation service ................................................................................ 93 11.1.2. Mapping services............................................................................................ 93 11.1.3. POI and Event Search service ........................................................................ 93 11.1.4. PT Routing service ......................................................................................... 95

11.2. MMS' services .................................................................................... 95 11.2.1. Mapping service, Routing service, POI and Event search service.................... 95

11.3. PTV's services .................................................................................... 97 11.3.1. Mapping service, Routing service, POI and Event search service.................... 97

11.4. TREDIT's services .............................................................................. 99 11.4.1. POI and Event Search service ........................................................................ 99 11.4.2. Routing service ............................................................................................... 99 11.4.3. PT timetables service, Traffic information service ............................................ 99

11.5. TOPO's services ................................................................................. 99 11.5.1. Mapping service, touristic information service, routing service, PT timetable service 99


August 2005 iv

List of figures Figure 1: Role of WP2 in IM@GINE 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 ............................................................. 10 Figure 6: Interfacing to individual web services through ontology solution. .............. 11 Figure 7: Basic configuration ................................................................................... 12 Figure 8: Aggregator service provider’s configuration .............................................. 13 Figure 9: Agent based service provider’s configuration............................................ 14 Figure 10: Web based prototype of Inter-modal router (plane not yet included) ....... 22 Figure 11: Web based prototype of Inter-modal router (plane not yet included) ....... 23 Figure 12: Modelling an in-door map in VISUM (Frankfurt Airport) .......................... 24 Figure 13: Centralised content editing from distributed sources ............................... 25 Figure 14: Business domains in a service environment ........................................... 27 Figure 15: Example ontology in Protégé. ................................................................. 37 Figure 16: Ontology implementation modules. ......................................................... 40

List of tables Table 1: Basic configuration .................................................................................... 11 Table 2: Aggregator service provider’s configuration ............................................... 12 Table 3: Agent based service provider’s configuration ............................................. 13 Table 4: Cross-fertilisation of business domains in IM@GINE IT ............................. 28 Table 5: IM@GINE IT content and service providers ............................................... 30 Table 6: Basic content services per test site and content provider ........................... 30 Table 7: Service instances ...................................................................................... 31 Table 8: Service providers and sub-service providers (basic content providers) per

test site ............................................................................................................ 32 Table 9: Availability of web services’ instances ....................................................... 33 Table 10: Matching service instances to abstract service descriptions .................... 49 Table 11: Traffic Information Services provided within the project by Service Provider

partners. .......................................................................................................... 64 Table 12: Mapping/Routing Services provided within the project by Service Provider

partners. .......................................................................................................... 67 Table 13: Public transport related services provided within the project by Service

Provider partners. ............................................................................................ 69 Table 14: Touristic information services provided within the project by Service

Provider partners. ............................................................................................ 70 Table 15 Mapping of FTB's attributes to IM@GINE IT ontology ............................... 94 Table 16 Mapping of Go Finlands's attributes to IM@GINE IT ontology .................. 94 Table 17 Mapping of Finnish PT routers attributes to IM@GINE IT ontology ........... 95 Table 18 Mapping of MMS' services to IM@GINE IT ontology ................................ 96 Table 19 Mapping of PTV's services to IM@GINE IT ontology ................................ 98 Table 20 Mapping of TREDIT's services to IM@GINE IT ontology .......................... 99 Table 21 Mapping of TOPO's services to IM@GINE IT ontology ............................102


August 2005 v

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 1

Executive Summary Deliverable D2.1.2 constitutes the services documentation, which describes the common IM@GINE 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 2.1.2 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 2005 2

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 2005 3

1. Introduction

1.1. IM@GINE IT Objectives

IM@GINE 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).

1.2. 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.

Figure 1: Role of WP2 in IM@GINE IT project and system.

WP2 – Services; Content & Interfaces

WP3 – MAS; Integration of Services

WP4 – Devices applications; Delivery to end user


August 2005 4

2. IM@GINE 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 multi-agent 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.

2.2. 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 2005 5

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 2005 6

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.

2.3. 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 2005 7

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.

2.4. 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 third-party system re-design. Compared to centralized system solutions, the ontology model is more innovative way of allowing future integration of services.


August 2005 8

The following figure demonstrates the overall system decomposition and specifies the 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.

B2C Operator Platform

Service Integrator Platform

B2C Operator Platform

Service Integrator Platform

Service Provider

Service Provider

Service Provider

Service Provider

Service Provider

Sub-

Ser

vice

P

rovi

der

Sub-

Ser

vice

P

rovi

der

Sub-

Ser

vice

P

rovi

der

Sub-

Ser

vice

P

rovi

der

End-user

Enab

led

Dev

ice

Enab

led

Dev

ice

Enab

led

Dev

ice

Enab

led

Dev

ice

Enab

led

Dev

ice

Enab

led

Dev

ice

End-user End-user End-user End-user

WP2 implementation

Framework

MAS MAS


August 2005 9

Figure 4: Abstract content flow model.

2.5. 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.

Service provider A Service provider B

OntologyX, Y, Z

MAS

Web service A (X, Y) Web service B (X, Z)

Content x, y Content x, y, z

Sub-service Provider a

Sub-service Provider b

Sub-service Provider c

Basic content service xa, ya Basic content service xb, ybBasic content service zc


August 2005 10

Figure 5: IM@GINE 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 2005 11

o A pre-defined IM@GINE IT ontology definition.

o A pre-defined mapping of individual web services to the IM@GINE IT ontology.

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.

Inner Technology: non relevant.

SOAP over HTML

Towards the Service Integrator Platform. The service is advertised as a WSDL + RDF document.

NO

Table 1: Basic configuration.

interfaceinterface

MASService

IntegratorService AX

Map service AXto ontology

ProviderAgent

IM@GINE-IT ontology


August 2005 12

Figure 7: Basic configuration.

Module Description Interfaces/Protocols IM@GINE

IT specific?

Aggregated service provider module

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.


SOAP over HTML Towards the Service Integrator Application.

Inner protocol (non relevant) Towards the subservices.

YES

Sub-service provider

Software component, providing kind of “basic” functionality to the Service Aggregation Module Inner Technology: non relevant.

Non relevant NO

Table 2: Aggregator service provider’s configuration.

Service integrator Platform

JADE

Service Integrator

Application (Java)

Service Provider(“Basic”)

Basic Service Module(Server)

SOAP


August 2005 13

Figure 8: Aggregator service provider’s configuration.

Module Description Interfaces/Protocols IM@GINE

IT specific?

Agent-based Aggregated service module

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).

SOAP over HTML

Towards the sub-services.

FIPA ACL Towards the Service Integrator Application.

--

Sub-service Software component, providing kind of “basic” functionality: to the Agent-Based Aggregated Service module.


Non relevant NO

Table 3: Agent based service provider’s configuration.

Service Provider(“Aggregator”)

Aggregated Service Module(Server)

Sub-Service(Server)

Sub-Content Server


JADE

Service Integrator

Application (Java)

SOAP


August 2005 14

Figure 9: Agent based service provider’s configuration.

2.6. 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.

Service Provider(“Agent-based aggregator”)

JADE

Agent-based Aggregated service

module(Java)

ACL

Sub-content(Server)

Sub-Service(Server)


JADE

Service Integrator

Application (Java)


August 2005 15

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 2005 16

3. Service descriptions and documentation

3.1. Decomposition of Transport & Travel Content Domains

The IM@GINE 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 2005 17

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.

3.1.1. 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 2005 18

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 2005 19

3.1.2. IM@GINE IT business domains

The basic Transport & Travel domains can be further decomposed into further “business domains”. Business domains in IM@GINE 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 IM@GINE IT project: o Traffic Information.

o Routing/Mapping services. o PT related information.

o Touristic information.

3.2. 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.

3.2.1. 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 2005 20

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 2005 21

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.

3.2.2. 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 2005 22

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 2005 23

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 2005 24

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 2005 25

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.

3.2.3. 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 2005 26

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.

3.2.4. 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 2005 27

3.2.5. 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 2005 28

Traffic information

Multi-modal routing & mapping

Public transport information

Touristic information

Traffic information

Dynamic car routing

NA NA

Multi-modal routing & mapping

Geo-referenced traffic events

Geo-referenced PT events

Geo-referenced POI and events

Public transport information

NA PT routing NA

Touristic information

NA POI mapping NA

Table 4: Cross-fertilisation of business domains in IM@GINE IT.

3.2.6. Data Management Module (DMM) Operation

In some cases, the basic content services are not direct service providers to the IM@GINE 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.

3.3. IM@GINE IT basic content services documentation

3.3.1. 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 2005 29

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.

3.3.2. 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.

Content and Service Providers Provider Content/Service

HACON PT Time table information, PT routing


August 2005 30

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: IM@GINE 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.

3.4. IM@GINE IT web services identification & documentation

3.4.1. 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 2005 31

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.

3.4.2. 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 reservation

X

Geocoding service

X X X X X

Mapping service

X X X X X

Car & Pedestrian routing

X X X X X

PT routing

X X X X

Traffic event information

X X

POI & event information

X X X X X

PT time table information

X X X X X

Dynamic PT information

X X X

Table 7: Service instances.


August 2005 32

The mapping of the above-mentioned service instances to the IM@GINE IT ontology is performed in section 4.8.

3.4.3. Web service organisation in IM@GINE 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 Service Aggregators and Content Providers Germany Finland Greece Italy Hungary

Reservation of flight / train

Service provider N/A N/A N/A N/A N/A

Content Providers

Hotel reservation Service provider N/A TIETOTALO N/A N/A N/A

Content Providers GoFinland

Geocoding service Service provider PTV PTV TREDIT MMS TOPO

Content Providers PTV PTV PTV TOPO

Mapping service Service provider PTV PTV TREDIT MMS TOPO

Content Providers PTV PTV PTV TOPO

(Dynamic) car and pedestrian routing

Service provider PTV PTV TREDIT MMS TOPO

Content Providers PTV PTV PTV ÚTINFORM

FŐVINFORM

PT routing service Service provider PTV TIETOTALO

TREDIT 1)

N/A TOPO

Content Providers HACON MTC INTELLECT

project BKV

Traffic information Service provider PTV N/A N/A MMS,5T N/A

Content Providers Various Various

POI and event search

Service provider PTV TIETOTALO TREDIT MMS TOPO

Content Providers PTV GoFinland

FTB TREDIT TeleAtlas, MMS TOPO

PT time table information

Service provider PTV TIETOTALO

TREDIT 2)

5T TOPO

Content Providers HACON MTC TREDIT BKV

Dynamic PT information

Service provider PTV N/A TREDIT 5T N/A

Content Providers 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 2005 33

2. Inter-urban PT modes trip planning including railway, maritime and flights. Also urban (Athens) PT timetable information for buses/metro leaving-approaching the airport, and flight schedules from/to AIA.

The following table presents the availability of web services per service provider.

Business Domain

Web Service availability per Country Germany Finland Greece Italy Hungary

Mapping Service http://62.103.51.34/IM@GINE

IT Mizar Mediaservice

http://api.map-and-go.com/3.2.2/mms_MizGIS.w

sdl

- Service Provider

PTV PTV TREDIT [PTV] MMS TOPO

Geocoding service

Service Provider PTV PTV TREDIT [PTV] MMS TOPO

Traffic Information

Mizar Mediaservice http://api.map-and-

go.com/3.2.2/mms_MizGIS.wsdl

- Service Provider

PTV N/A N/A MMS, 5T in Turin N/A

Dyn. Car and ped. routing

http://api.map-and-


- Service Provider

PTV PTV TREDIT [PTV] MMS TOPO

PT Routing service

PT Journey Planner, http://aikataulut.ytv.fi/reittio

pas/en/

Service Provider PTV TIETOTALO TREDIT N/A TOPO

PT Time Table Information

PT Journey Planner, http://aikataulut.ytv.fi/reittio

pas/en/

http://62.103.51.34/IM@GINE IT

- Service Provider

PTV TIETOTALO TREDIT 5T TOPO

Dynamic PT Information

http://62.103.51.34/IM@GINE IT N/A

- Service Provider

PTV N/A TREDIT [AIA] 5T N/A

Tourism Information and Hotel Res.

GoFinland, http://www.gofinland

.net

FTB http://www.mek.fi/

http://62.103.51.34/IM@GINE IT

Mizar Mediaservice http://api.map-and-


- Service Provider

PTV TIETOTALO TREDIT [TIETOTALO] MMS TOPO

Table 9: Availability of web services’ instances.

Table 9 lists some already available (or in development stage) Web services, which are listed with web URL addresses.


August 2005 34

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


August 2005 35

4. IM@GINE 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 XML-based, 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 ontology-based 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 2005 36

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.

4.2. 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 2005 37

a) Example ontology in Protégé:

Figure 15: Example ontology in Protégé.


August 2005 38

b) In OWL: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns="http://IM@GINE IT.eu/ontology#" xml:base="http://IM@GINE 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="http://www.w3.org/2002/07/owl#FunctionalProperty"/> <rdfs:domain rdf:resource="#Coordinates"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> </owl:DatatypeProperty> <owl:FunctionalProperty rdf:ID="lowerRight"> <rdfs:range rdf:resource="#Coordinates"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/> <rdfs:domain rdf:resource="#BoundingBox"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="Y"> <rdfs:domain rdf:resource="#Coordinates"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> </owl:FunctionalProperty> </rdf:RDF> c) In UML:

-upperLeft : Coordinates-lowerRight : Coordinates

Bounding Box

-X : float-Y : float

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 2005 39

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 D3.1.

4.3. Ontology methodological steps

4.3.1. 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.

4.3.2. 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 2005 40

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.

IM@GINE ITontology

POI Public TransportInformationTimetable

+getRoute() : PTVRoute

«interface»PTV Interface

PTVRoute

+getRoute() : MMSRoute

«interface»MMS Interface

MMSRoute

+getRoute()+...()

-Country-CrossborderRoadPoints-SupportedLanguages-...

«metaclass»RoutingServiceMetaClass

Im@gine IT ontology: It capturesthe needed elements of thetransport and tourism domains

Im@gine IT abstract servicespecification: It provides abstractmethod signatures and the servicedescription meta-data (serviceprofile)

Im@gine IT service instances: Itdefines the available services forour project, including theirsignatures and maps the input/output parameters to the Im@gineIT ontology. Every service instancemust be implementing an abstractservice specification

...

OutputparameterOutputparameter

Map to ontology class

Route

PTVRoute Im@gine IT Route

Zoom in -> Map to ontology class

The PTV Route elements map tothe respective Im@gine IT Routeelements

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 2005 41

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.

4.4.1. 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 Description roadNameList [String] List of road names to be searched for traffic

messages ProviderList [String]) One or more traffic providers (traffic POI types Language [String] Optional ISO code for setting the language of the

returned traffic messages. If not set, UK-en is used Return Type [POIViewSet] Traffic message POI’s for the roads

4.4.2. Mapping services

4.4.2.1. 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 Description a [Adress] Address to be geocoded p [Locate Properties] Optional properties for geocoding GeoDataSource [String] Name of geographic data source ReturnType [Adress List] 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 2005 42

Field Description c [Coordinate] Coordinate to be reverse geocoded p [ReverseLocateProperties] Optional properties for reverse geocoding GeoDataSource [String] Name of geographic data source ReturnType [AdressList] 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

4.4.2.2. 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 Description c [Coordinate] Center coordinate of the map width [double] Logical width of the map in km height [double] Logical height of the map in km poiViewSets [POIViewSet] 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

routes [RouteView] Optional list of routes to be displayed in the map p [ImageProperties] Dimensions and type of the returned image geoDataSource [String] Name of geographic data source targetMapName [String] Optional name for resulting map for later

referencing Return Type [MapView] Map or URL pointing to the map

4.4.2.3. 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 Description Stations [CoordinateList] Two or more coordinates defining start, via points

and destination of the route Rp [RouteProperties] Properties to be set for influencing route calculation

(optional) S [POIViewSet] Optional POI’s for corridor search GeoDataSource [String] Name of geographic data source Return Type [RouteView] Routing result

RouteProperties CalcType Type of route calculation (static or dynamic)


August 2005 43

[RouteCalcTypeEnum] DistanceUnit [DistanceUnitEnum]

Unit of distances for routing result (km, miles)

SpeedProfile [SpeedProfileEnum]

Speed profile (fast car, slow car, …)

Optimization [RouteOptimizationEnum]

Option for setting routing preferences (fastest route, shortest route, most economic route)

Time [dateTime] Start time for route. If empty, current time is used UseTimeAsArrival [Boolean]

If not set or false, the parameter “time” is considered as start time. If true, “time” is considered as arrival time

Language [String] Language for routing result texts RouteDetail [RouteDetailEnum]

Option for influencing the details returned in the route description (number of route elements returned)

Dist [DistanceProperties] Option to affect the connection of corridor POI’s RequestLine [Boolean] If not set or false, the line in the routing result will be

empty. If true, the line is filled ReMapProperties [RouteElementMapRect]

Optional properties for calculation of maximap and detailmap sections. If null, the sections are not calculated.

AdditionalInfos [String] Request of additional information for routing results, for internal use only. This parameter should only be used with prior consultation with PTV

AvoidHighways [Boolean] Option to avoid using highways for routing ExcludeFerries [Boolean] Option to prevent using ferries for routing

4.4.3. Touristic information services

4.4.3.1. POI and event search

POI (Point Of Interest) data model describes each POI item as a separate entry with the following information:

Field Description ID Distinct ID string for POI. This ID will be used to

track the updates to a particular POI. Type Enumerative type of POI, pre-defined list of POI

types. Name Title of POI, string type. Validity 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.

Address Optional: Address of POI, string type. Coordinates Optional: Coordinates consists of Longitude,

Lattitude and Coordinate system (WGS84 on most cases). Longitude and Lattitude are given is degrees x


August 2005 44

Field Description 10000.

Description Optional: Description of POI, string type. Optional 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= http://media.service.net/video.avi).

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 Description c [Coordinate] Center coordinate for the POI search p [ProximityProperties] Properties used for circle search s [POIViewSet] Empty POISets containing just the names of POI types to search

for and/or sets with external POI’s Return Type [POIViewSet]

POI’s lying around the center

4.4.3.2. Hotel reservation

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.

Field Description HotelName Name of the hotel Guest Hotel guest details (name, credit card, etc) RoomType Type of room. (For example Double) RoomQualifier Room qualifier (For example standard or superior) Product code Product code (For example RACK or CAMPAIGN) arrivalDate, departureDate Date of arrival and departure Return Type [makeBookingResponse]

Status of booking request

Return Type [RoomAvailabilityResponse]

List of available rooms


August 2005 45

4.5. Ontology definition & documentation

Based on the analysis performed in the previous section, the ontology definition is deployed. The IM@GINE 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 2005 46

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 D3.1.

4.6. 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 4.8.2.

4.7.1. 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 2005 47

- 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

4.7.2. Mapping Service

Supported Languages - List of country codes (CH;AT;IT;FR;FI;DE;DK;GB;BE;NL)



- In Euro Can Draw Lines

- Boolean

4.7.3. Geocoding Service




- In Euro

4.7.4. PT Routing Service




- In Euro Supported Transportation Means

- List of:: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY


August 2005 48

4.7.5. Traffic Information




- In Euro Refresh Rate

- Times of refresh per day

4.7.6. POI and Event Information





- Times of refresh per day Available POI Types

- List of available POI Types

4.7.7. PT Time Table Information





- Times of refresh per day

4.7.8. Dynamic PT Information



for international


August 2005 49

Service cost - In Euro

Refresh Rate - Times of refresh per day

4.7.9. Hotel Reservation




- In Euro

4.8. Mapping Service instances to IM@GINE IT Ontology

4.8.1. 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 GetRoadsWithMessages, 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 GetPTTimeTable

getPTEvent NA NA GetDynamicFlightInfo

getPTEvent NA

Table 10: Matching service instances to abstract service descriptions.


August 2005 50

Detailed service instance mappings to the IM@GINE IT Ontology are presented in Annex E.

4.8.2. Metadata information for service instances

In this section, the needed meta-data descriptions of all available services are presented.

4.8.2.1. MMS Services

MMS

Dynamic Car and Pedestrian Routing

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 Adjacent Countries NA Auto-route Connection Points (w/ other adjacent countries)

NA

Supported Transportation Means

List of: CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, AIRPLANE, TRAIN, FERRY

MMS

Mapping Service



Service Cost in Euro Can Draw Lines Boolean MMS

Geocoding Service




August 2005 51

MMS

Geocoding Service

Metadata field Metadata content Service Cost in Euro MMS

PT Routing



Service Cost in Euro Supported Transportation Means


MMS

Traffic Information



Service Cost in Euro Refresh Rate NA MMS

POI and Event Information



Service Cost in Euro Refresh Rate NA Available POI Types NA


August 2005 52

4.8.2.2. PTV Services

PTV




Service Cost in Euro Adjacent Countries NA Auto-route Connection Points (w/ other adjacent countries)

NA



PTV

Mapping Service



Service Cost in Euro Can Draw Lines Boolean PTV

Geocoding Service



Service Cost in Euro PTV

PT Routing

Metadata field Metadata content Supported Languages List of country codes


August 2005 53

PTV

PT Routing

Metadata field Metadata content Area covered List of country codes


Service Cost in Euro Supported Transportation Means


PTV

Traffic Information



Service Cost in Euro Refresh Rate NA PTV




Service Cost in Euro Refresh Rate NA Available POI Types NA PTV




Service Cost in Euro Refresh Rate NA


August 2005 54

PTV


Metadata field Metadata content Supported Languages List of country codes (ISO 639-1) PTV




Service Cost in Euro Refresh Rate NA Supported Languages List of country codes (ISO 639-1)

4.8.2.3. TIETOTALO Services

TIETOTALO

PT Routing

Metadata field Metadata content Supported Languages FI, GB Area covered FI Service Cost NA Supported Transportation Means

List of: PEDESTRIAN, URBAN_PUBLIC_TRANSPORT, BUS, TRAIN

TIETOTALO


Metadata field Metadata content Supported Languages FI, GB Area covered FI Service Cost NA Refresh Rate Once/day Available POI Types Accommodation, Sight, Attraction TIETOTALO


Metadata field Metadata content Supported Languages FI, GB


August 2005 55

TIETOTALO


Metadata field Metadata content Area covered FI Service Cost NA Refresh Rate Once/day TIETOTALO

Hotel Reservation

Metadata field Metadata content Supported Languages FI, GB Area covered FI Service Cost Depending

4.8.2.4. TREDIT Services

TREDIT


Metadata field Metadata content Supported Languages GB, GR Area covered Athens, Thessaloniki Service Cost in Euro Adjacent Countries NA Auto-route Connection Points (w/ other adjacent countries)

NA


List of: CAR, PEDESTRIAN

TREDIT

Mapping Service

Metadata field Metadata content Supported Languages GB, GR Area covered Athens, Thessaloniki Service Cost in Euro Can Draw Lines Boolean TREDIT

Geocoding Service

Metadata field Metadata content Supported Languages GB, GR Area covered Athens, Thessaloniki


August 2005 56

TREDIT

Geocoding Service

Metadata field Metadata content Service Cost in Euro TREDIT

PT Routing

Metadata field Metadata content Supported Languages GB, GR Area covered Greece Service Cost in Euro Supported Transportation Means

List of: BUS, AIRPLANE, TRAIN, FERRY

TREDIT


Metadata field Metadata content Supported Languages GB, GR Area covered Athens, Thessaloniki Service Cost in Euro Refresh Rate NA Available POI Types NA TREDIT


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


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 2005 57

4.8.2.5. TOPO Services

TOPO


Metadata field Metadata content Supported Languages INT Area covered HU Service Cost Free of charge for IM@GINE IT pilots. Adjacent Countries AT;SI;HR;CS;RO;UA;SK Auto-route Connection Points (w/ other adjacent countries)

AT;SI;HR;CS;RO;UA;SK


CAR, PEDESTRIAN, URBAN_PUBLIC_TRANSPORT (UPT for Budapest only)

TOPO

Mapping Service

Metadata field Metadata content Supported Languages INT Area covered HU Service Cost Free of charge for IM@GINE IT pilots. Can Draw Lines True TOPO

Geocoding Service

Metadata field Metadata content Supported Languages INT Area covered HU Service Cost Free of charge for IM@GINE IT pilots. TOPO

PT Routing

Metadata field Metadata content Supported Languages INT Area covered HU Service Cost Free of charge for IM@GINE IT pilots. Supported Transportation Means

URBAN_PUBLIC_TRANSPORT (Budapest only)


August 2005 58

TOPO


Metadata field Metadata content Supported Languages HU;EN Area covered HU Service Cost Free of charge for IM@GINE IT pilots. Refresh Rate 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

Available POI Types Car services Banks Petrol stations Restaurants Pharmacies Hotels Surgeries Monuments Pubs Post offices Police stations Turist information ATM

TOPO


Metadata field Metadata content Supported Languages INT Area covered HU Service Cost Free of charge for IM@GINE IT pilots. Refresh Rate per day Supported Languages See above


August 2005 59

4.8.2.6. 5T Services

5T


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


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


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 2005 60

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 2005 61

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 IM@GINE 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.

5.1. 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 ontology-based 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 2005 62

6. References

JADE – Java Agent Development Environment, http://jade.tilab.com/

Protégé, An Ontology Editor and Knowledge Acquisition System. http://protege.stanford.edu

Martin, D. (editor): OWL-S: Semantic Markup for Web Services. W3C Member Submission, 2004

The World Wide Web Consortium (W3C). The Semantic Web activity http://www.w3c.org/2001/sw/

The World Wide Web Consortium (W3C). Web Services Activity, http://www.w3.org/2002/ws/

D1.1. Use Cases and User/Vehicle Profile Requirements, IM@GINE IT project

D1.2. Services Specification, IM@GINE IT project

D1.3. System Architecture, IM@GINE IT project


August 2005 63

7. Annex A: IM@GINE IT Basic content services documentation

7.1. Traffic Information service instances

5T Description 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.

Sources 5T systems, Municipality police and municipality viability offices Covered area Turin Covered street types

Urban

Languages supported

Italian & English

Standards Datex, RDS TMC Publication method

Http, html

XML availability

No

Suggested PUSH request frequency

15 Minutes

Number of events

Average: 10 Peak: 20

Event types supported

ACC, INC, LOS, RES, RMT,

Event types (data objects) supported: please indicate the event types using the following data object codes:

Data Object Code Event Description ACC Accident

ACT Activities APL Action Plan EQU Traffic Equipment Status EXH Exhaust pollution FOS Fog/smoke/dust INC Incident LOS Level of service MHZ Moving hazards OHZ Obstruction Hazards OPA Operator Actions PRE Precipitation RES Traffic Restrictions


August 2005 64

Data Object Code Event Description RMT Road works ROU Rerouting SHZ Skid hazards SNE Snow/Ice Equipment SNO Snow on the road(s) WDA Weather data WIN Wind

PTV Description 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.

Sources ADAC, BMS/PTV TIC-NL, GEI, Traffic First, ITIS, (TRAFFIX), ORF

Covered area Germany, Switzerland, UK, France, NL, Austria

Covered street types German road network including cities

Languages supported German, English

Standards TMC Publication method

FTP, Web service

XML availability

yes


5 min

Number of events

Average: 500-600 Peak: 800


Event code table.

Table 11: Traffic Information Services provided within the project by Service Provider partners.

7.2. Routing/Mapping Service instances

PTV Description The mapping service covers the test sites of Germany, Greece

and Finland. Sources Navteq, PTV Content Road geometries, area layers, POI Covered area Central Europe, parts of Scandinavia and parts of Greece


August 2005 65

PTV Languages supported

German, English, others

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 supported

Italian

Standards Publication method Web service SOAP/XML XML availability yes MMS Description Routing service Sources MMS Content Road geometries, area layers Covered area Italy, Germany, Austria, France, Switzerland, S.Marino, Monaco

Public transport routing is supported in Turin Languages supported

Italian

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 area

Helsinki Region (Nationwide later 2005)

Languages supported

FI, EN

Standards XML Publication method

Http, html

XML availability

Yes


August 2005 66

TIETOTALO Update frequency

Static, 1 month

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 Static data: navigation map for the whole Hungary including each settlement. Dynamic data: for country road network and Budapest only.

Covered street types

All in covered area

Languages supported

Hungarian, English, German

Standards TMC in advance (not implemented yet) Publication method

Internet: www.utvonalterv.hu, www.bkv.hu, WAP

XML availability

Planned for next year


Twice pro day

Number of events

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 supported

German, English, other

Standards NA Publication method Web service SOAP/XML


August 2005 67

PTV XML availability Yes Update frequency Depending on release dates

Table 12: Mapping/Routing Services provided within the project by Service Provider partners.

7.3. 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 area

Helsinki Region (Nationwide later 2005)

Languages supported

Finnish, English

Standards XML Publication method

Web service, Proprietary XML interface, web interface

XML availability

Yes

Update frequency

Static, 1 month

5T Description Public transport information Sources 5T Content PT timetables Covered area

Turin

Languages supported

Italian, English

Standards Web service Publication method

Web service

XML availability

Yes

Update frequency

Once a day

TOPO Description Public transport information Sources BKV Content PT timetables


August 2005 68

TOPO Covered area

Budapest

Languages supported

Hungarian

Standards Web service SOAP Publication method

Web service SOAP

XML availability

Yes

Update frequency

Once a day

AIA Description 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.

Sources AIA server Covered area Athens International Airport Covered Flights

All (incoming & outgoing)

Languages supported

English

Standards - Publication method

ftp

XML availability

No


2 Minutes

Number of events

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 2005 69

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.

7.4. 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

and event information Accommodation, Point of interest information, hotel reservation

Covered area

Finland Finland

Languages supported

English Finnish, English

Standards XML Java (Hotel reservations), XML (POI information)

Publication method

FTP based XML feed HTTP based XML feed

XML availability

Yes Yes

Update frequency

Once a day POI information once a day Real time accommodation reservation and availability

MMS Description Touristic information offered through MMS Sources MMS Content Point of interest information Covered area

Italy

Languages supported

Italian

Standards Web Service/SOAP Publication method

Web Service/SOAP.

XML availability

Yes

Update frequency

Once a day


August 2005 70

PTV Description Touristic information offered through PTV Sources PTV Content Point of interest information Covered area

Germany

Languages supported

German, English

Standards Web Service/SOAP Publication method

Web Service/SOAP.

XML availability

Yes

Update frequency

Once a day

Table 14: Touristic information services provided within the project by Service Provider partners.


August 2005 71

8. Annex B: IM@GINE 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


Class Documentation: these refer to WGS84 coordinates format

Template Slots

Slot name Documentation Type Allowed Values/Classes Cardinality Default

hasCoordinateX Integer 1:1

hasCoordinateY Integer 1:1 hasCoordinateZ

8.3. Class Address



August 2005 72

Direct Instances: None


Template Slots


inCity String 0:1

onStreet String 0:1 withStreetNumber String 0:1

hasPostalCode String 0:1 inDistrict String 0:1

forCountry String 0:1 -

8.4. Class BoundingBox


Direct Instances:

None


Template Slots


hasUpperRightCoordinates Instance Coordinates 0:1

hasLowerLeftCoordinates Instance Coordinates 0:1

8.5. Class ScreenSize


Direct Instances:

None


August 2005 73


Template Slots


hasPixelsWidth Integer 0:1 hasPixelsHeight Integer 0:1

8.6. Class POIForMap


Direct Instances:

None

Direct Subclasses: POI

Template Slots


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)

String 0:*

hasCoordinates Instance Coordinates 0:1

hasPOIName String 0:1


August 2005 74

Template Slots


hasPOIID String 0:1

8.7. Class Line


Direct Instances:

None


Template Slots


hasOrderedCoordinatesList Instance Coordinates 0:*

8.8. Class ClickablePOI


Direct Instances:

None


Template Slots


hasPOIName String 0:1

hasImageCoordinates Instance ImageCoordinates 0:1


August 2005 75

8.9. Class ImageCoordinates


Direct Instances:

None


Template Slots

Slot name Documentation Type Allowed

Values/Classes Cardinality Default

hasXPos Integer 0:1 hasYPos Integer 0:1

8.10. Class Map


Direct Instances:

None


Template Slots


hasBoundingBox Instance BoundingBox 0:1 showsPOIs Instance ClickablePOI 0:*

hasImage Instance Image 0:1 showsRoute Boolean 0:1

8.11. Class Image



August 2005 76

Direct Instances: None


Template Slots


hasURL String 0:1

hasFileFormat Type of image, e.g. GIF, JPG, etc String 0:1

8.12. Class RouteSegmentDetail


Direct Instances:

None


Template Slots


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


August 2005 77

property of RouteSegment

hasDestinationInfo

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:1

8.13. Class CoordinatesInCountry


Direct Instances:

None


Template Slots


hasCoordinates Instance Coordinates 0:1 forCountry String 0:1

8.14. Class RouteSegment


Direct Instances:

None

Direct Subclasses:


August 2005 78

None

Template Slots

Slot name Documentation Type Allowed

Values/Classes Cardinality Default

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 the place of starting a route segment

Instance CoordinatesInCountry 0:1

finishesAt Instance CoordinatesInCountry 0:1

routeSegmentReservationInfo what is in this field? String 0:1

routeSegmentDetail Instance RouteSegmentDetail 0:*

hasCost in Euro String 0:1

hasOptimization String 0:1

usingBrand

This is the company operating the public transport line or car brand.

String 0:1

startsAtPlace

Name of the starting point eg. Helsinki Railway station

String 0:1

finishesAtPlace

Name of the finishing point eg. Helsinki airport

String 0:1

PTLine

bus number, flight number, metro line number

String 0:1

routeSegmentMapID String 0:1


August 2005 79

8.15. Class Route


Direct Instances:

None


Template Slots


routeSegments Instance RouteSegment 0:* distance in meters Integer 0:1

duration seconds of travel time for this detail Integer 0:1

8.16. Class PublicTransportTimetable


Direct Instances:

None


Template Slots


usingTransportType String 0:1

startsAt the place of starting a route segment Instance CoordinatesInCountry 0:1

startsAtPlace Name of the starting point eg. Helsinki Railway station

String 0:1

timetable Instance LineTimetable 0:*


August 2005 80

8.17. Class OptionalInformation


Direct Instances:

None


Template Slots


optionalAttributeName the name of an optional attribute

String 0:1

withStringValue String 0:1

8.18. Class LineTimetable


Direct Instances:

None


Template Slots


PTLine bus number, flight number, metro line number

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


August 2005 81

8.19. Class TrafficEvent


Direct Instances:

None


Template Slots



additionalInformation String 0:1 trafficEventType String 0:1

expiresOn date/time String 0:1

8.20. Class PublicTransportEvent


Direct Instances:

None


Template Slots


PTLine bus number, flight number, metro line number

String 0:1

usingBrand

This is the company operating the public transport line or car brand.

String 0:1

departureOn Date/Time String 0:1

PTEventType e.g. Delay, Cancel, etc String 0:1


August 2005 82

Template Slots


additionalPTInfo

possibly destination, check counters and gate for airplanes, track for train, dock for ships, etc

String 0:1

8.21. Class HotelGuestInformation


Direct Instances:

None


Template Slots


guestName String 1:1

guestPhone String 1:1

guestAddress Instance Address 1:1

guestEmail String 1:1

guestFreeText Free text information concerning for example arrival

String 0:1

guestETA Estimated time of guests arrival String 0:1

guestCreditCardType Credit card type String 0:1

guestCreditCardNO Credit card number String 0:1

guestCreditCardEXP Credit card expiry date eg. 10/05

String 0:1


August 2005 83

8.22. Class RoomAvailabilityResponse

Concrete Class Extends HotelBookingResponse

Direct Instances:

None


Template Slots


roomQualifier Room qualifier (e.g. standard) String 1:1

roomType Room type e.q. double 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

8.23. Class MakeBookingResponse

Concrete Class Extends HotelBookingResponse

Direct Instances:

None



August 2005 84

Template Slots

Slot name Documentation Type Allowed Values/Classes

Cardinality Default

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 Room qualifier (e.g. standard) String 1:1

roomType Room type e.q. double String 1:1

numberOfBeds Integer 1:1

numberOfPersons Integer 1:1

8.24. Class GeocodedAddress


Direct Instances:

None


Template Slots


hasAddress Instance Address 0:1



August 2005 85

9. Annex C: IM@GINE IT Ontology modelled in Protege tool

9.3.1. Protégé Classes view


August 2005 86

9.3.2. Protégé Slots view


August 2005 87


August 2005 88

10. Annex D: IM@GINE IT Ontology abstract service descriptions

10.1.1. Hotel reservation / requestRoomAvailability

Service name requestRoomAvailability Service invocation parameters

String hotelName Date arrival Date departure int numberOfPersons String roomType (optional may be null) String productCode (optional may be null)

Service results RoomAvailabilityResponse[] rooms Text description This service checks room availibility for a given hotel

for a given date period. Service name requestRoomAvailability Service invocation parameters

String country String region Date arrival Date departure int numberOfPersons String roomType (optional may be null) String productCode (optional may be null)

Service results RoomAvailabilityResponse[] rooms Text description This service checks room availibility for a given

country / area

10.1.2. Hotel reservation / makeBooking

Service name makeBooking Service invocation parameters

String hotelId String roomId Date arrival Date departure int numberOfPersonsPerRoom int numberOfRooms String extraInformation Map optionalAttributes HotelGuestInformation guestInformation;

Service results MakeBookingResponse response Text description This service books a room from a given hotel.


August 2005 89

10.1.3. Hotel reservation / cancelBooking

Service name cancelBooking Service invocation parameters

String bookingId

Service results int status; Text description This service cancels a booking

10.3.4. Hotel reservation / requestBookingDetails

Service name requestBookingDetails Service invocation parameters

String bookingId

Service results MakeBookingResponse response Text description This service requests details of a previously made

booking

10.3.5. Hotel reservation / requestRoomTypes

Service name requestRoomTypes Service invocation parameters

-

Service results RoomTypesResponse response Text description This service requests details of room types and

qualifiers

10.3.6. Geocoding service

Service name geocodeAddress Service invocation parameters

Address address, Integer maximumReturnedAddresses

Service results GeocodeAddress[] geocodedAddresses Text description This service translates an address to coordinates. The

output is a GeocodedAddress list that will only have one element in the case of a successful geocoding, and several suggestions otherwise. The returned geocoded addresses are not unlimited, they are limited by the maximumReturnedAddresses integer.

10.3.7. Mapping service

Service name createMap Service invocation parameters ScreenSize screenSize, BoundingBox boundingBox,

(POIForMap[] showPOIs), (Line[] routeLines), (String routeMapID)


August 2005 90

Service results Map map Text description This service draws maps and stores them in a URL

from where anyone can access them for a short period. This service needs basically a bounding box and a screen size in order to produce a map. Optional things that can be shown on the map are a line (i.e. the user’s route, that can also be inserted as a routeMapID) and some POIs (the user’s position, bus/train stations, other POIs ). The service returns a URL of the created map, the final bounding box and, possibly, some clickable POIs that are shown on the map (including user position, PT stops, POIs). All outputs are included in the Map concept of the ontology.

10.1.8. Dynamic car and pedestrian routing

Service name createRoute Service invocation parameters Coordinates origin, Coordinates destination, String[]

usingTransportType, (String usingOptimization), (DateTime start), (DateTime finish), (String language), Integer maximumReturnedRoutes

Service results Route[] routes Text description The basic invocation parameters are the origin, the

destnation and the transport type to use (one or more of Car, Pedestrian, urban PT, train, boat, airplane). Optional invocation parameters include transport optimization modes for car (shortest, fastest), date of arrival or departure and, finally, the maximum returned number of routes (inter-modal routes). Pedestrian or car must always be an option if public transport is used.

Possible values of usingTransportType: CAR PEDESTRIAN URBAN_PUBLIC_TRANSPORT BUS AIRPLANE TRAIN FERRY Possible values of usingOptimization (car): FASTEST SHORTEST

10.1.9. PT routing service

Same with Dynamic car and pedestrian routing


August 2005 91

10.1.10. Traffic information

Service name getTrafficEvent Service invocation parameters Service results TrafficEvent[] trafficEvents Text description This service provides the requester with information

about disrupted traffic in specific areas. The service returns all disrupted areas and the projected dates until which they will be valid (road works, for example, have a known duration, while other events have rough estimations).

10.3.11. POI and event search

Service name proximitySearch Service invocation parameters BoundingBox boundingBox, String[] POITypes,

(String language) Service results POIForMap[] showPOIs Text description The proximity search service gets a bounding box

that defines an area and POI types and returnes those POIs that are within the specified area and of the requested typs. Some POIs may have more than one types.

Service name getPOIInfo Service invocation parameters String[] POIID, (String language) Service results POI[] POIs Text description This service accepts as inputs some POI names and

returns their full information.

10.3.12. PT time table information

Service name getPTTimeTable Service invocation parameters DateTime time, (String PTLine), Coordinates origin,

(String station), (String brand), String usingTransportType

Service results PublicTransportTimetable PTTimetable Text description This service allows the requester to get the next

departures of a public transport type and line (e.g. bus line, tram line, train, flight number, etc) from a specific location (station, e.g. bus stop, airport, station, etc, with coordinates), possibly for a specific brand (PT operator).

10.3.13. Dynamic PT information

Service name getPTEvent


August 2005 92

Service invocation parameters DateTime getEventsThatHappenedSince Service results PublicTransportEvent[] PTEvents Text description This service provides the requester with information

about events affecting public transportation. The only input parameter is a date. The service returns all disrupted lines since that date and the projected dates until which they will be valid (e.g. flight “OA234” is disrupted and a new time of departure is announced) with additional info. The PublicTransportEvents attributes are in line with the ones of the PublicTransportTimetable.


August 2005 93

11. Annex E: Mapping service instances to Ontology

This annex presents the mapping between the service instances and the IM@GINE IT Ontology (Annex E).

Mappings are presented as tables which describe mapping between IM@GINE IT ontology and local service instances parameters.

Mappings are color coded using the following scheme: Black: One to one direct mapping between ontologies Blue: Minor incompatibilities found that can be overcome by composing similar

infomation found elsewhere or for example combining values of multiple parameters

Red: More severe incompatibilities exists. For example either of the ontologies does not have the corresponding attribute. These are solved for example using default values for attributes or these attributes require additional logic to be composed.

11.1. TIETOTALO's services

11.1.1. Hotel reservation service

No mapping required. Hotel booking service is implemented using IIT ontology.

11.1.2. Mapping services

Tietotalo uses PTV's GIS services for mapping.

11.1.3. POI and Event Search service


August 2005 94

Concept Slot Type XML structure Field name NotesPOI Accommodation

additionalInformation.Description String DescriptionhasAddress.inCity String LocCityhasAddress.onStreet String SupplierStreetAddresshasAddress.withStreetNumber String SupplierStreetAddresshasAddress.hasPostalCode String SupplierPostNumberhasAddress.inDistrict String ProvincehasAddress.forCountry String "Finland"hasCoordinates.hasCoordinateX Double x_cordshasCoordinates.hasCoordinateY Double y_cordshasCoordinates.hasCoordinateZ Double "0"hasEmail String SupplierEmailhasFax String SupplierFaxPrefix+SupplierFaxNumberhasPicture String N/AhasPOIID String ProdUniqueIDhasPOIName String BookingNamehasPOIType String ProdTypehasTelephone String SupplierPhonePrefix+SupplierPhoneNumberhasURL String SupplierWWW

POI AttractionadditionalInformation.Description String DescriptionhasAddress.inCity String LocCityhasAddress.onStreet Integer SupplierStreetAddresshasAddress.withStreetNumber String SupplierStreetAddresshasAddress.hasPostalCode String SupplierPostNumberhasAddress.inDistrict String ProvincehasAddress.forCountry String "Finland"hasCoordinates.hasCoordinateX Double x_cordshasCoordinates.hasCoordinateY Double y_cordshasCoordinates.hasCoordinateZ Double "0"hasEmail String SupplierEmailhasFax String SupplierFaxPrefix+SupplierFaxNumberhasPicture String N/AhasPOIID String ProdUniqueIDhasPOIName String BookingNamehasPOIType String BookingNamehasTelephone String SupplierPhonePrefix+SupplierPhoneNumberhasURL String Links

POI EventadditionalInformation.Description String DescriptionhasAddress.inCity String LocCityhasAddress.onStreet Integer SupplierStreetAddresshasAddress.withStreetNumber String SupplierStreetAddresshasAddress.hasPostalCode String SupplierPostNumberhasAddress.inDistrict String ProvincehasAddress.forCountry String "Finland"hasCoordinates.hasCoordinateX Double geoCode(EventStreetAddress,EventPostCode) FTB's event does nothasCoordinates.hasCoordinateY Double geoCode(EventStreetAddress,EventPostCode) contain coordinateshasCoordinates.hasCoordinateZ Double geoCode(EventStreetAddress,EventPostCode)hasEmail String SupplierEmailhasFax String SupplierFaxPrefix+SupplierFaxNumberhasPicture String N/AhasPOIID String ProdUniqueIDhasPOIName String BookingNamehasPOIType String BookingNamehasTelephone String SupplierPhonePrefix+SupplierPhoneNumberhasURL String InfoURLstartDate Date StartingDate_D+StartingDate_M+StartingDate_YendDate Date EndingDate_D+EndingDate_M+EndingDate_Y

IMAGINE-IT TIETOTALO / Finnish Tourist Board

Table 15: Mapping of FTB's attributes to IM@GINE IT ontology.

Concept Slot Type XML structure Field name NotesPOI Location

additionalInformation.Description String location/texts/descriptionhasAddress.inCity String location/post_officehasAddress.onStreet String location/street_addresshasAddress.withStreetNumber String location/street_addresshasAddress.hasPostalCode String location/po_boxhasAddress.inDistrict String ProvincehasAddress.forCountry String "Finland"hasCoordinates.hasCoordinateX Double geoCode(hasAddress) Go Finland does nothasCoordinates.hasCoordinateY Double geoCode(hasAddress) have coordinates.hasCoordinates.hasCoordinateZ Double geoCode(hasAddress)hasDateEnd String N/A POIs are valid allwayshasDateStart String N/AhasEmail String location/emailhasFax String location/telefaxhasPicture String location/big_imagehasPOIID String IDhasPOIName String location/texts/namehasPOIType String typeof(sublocation)hasTelephone String location/telephonehasURL String location/homepage

IMAGINE-IT TIETOTALO / GO FINLAND

Table 16: Mapping of Go Finlands's attributes to IM@GINE IT ontology


August 2005 95

11.1.4. PT Routing service

Concept Slot Type XML structure Field name NotesRoute Route

distance Integer LENGTH/distduration Integer LENGTH/timehasMap Map N/ArouteSegments RouteSegment ROUTE/(LINE | WALK)

RouteSegment WALK WALK describesdistance Integer LENGTH/dist segment which duration Integer LENGTH/duration transporttype is OnFootfinishesAt.x Integer (POINT | STOP)[last()]/xfinishesAt.y Integer (POINT | STOP)[last()]/yfinishesAtPlace String (POINT | STOP)[last()]/NAMEfinishesOn String (POINT | STOP)[last()]/ARRIVAL/date+timestartsAt.x Integer (POINT | STOP)[1]/xstartsAt.y Integer (POINT | STOP)[1]/ystartsAtPlace String (POINT | STOP)[1]/NAMEstartsOn String (POINT | STOP)[1]/ARRIVAL/date+timehasCost String N/AhasId String N/AhasOptimization String N/ArouteSegmentReservationInfo String N/ArouteSegmentDetails RouteSegmentDetail N/AusingTransportType String OnFoot

RouteSegment LINE LINE describesdistance Integer LENGTH/dist segment which duration Integer LENGTH/duration transporttype is PTfinishesAt.x Integer STOP[last()]/xfinishesAt.y Integer STOP[last()]/yfinishesAtPlace String STOP[last()]/NAMEfinishesOn String STOP[last()]/ARRIVAL/date+timestartsAt.x Integer STOP[1]/xstartsAt.y Integer STOP[1]/ystartsAtPlace String STOP[1]/NAMEstartsOn String STOP[1]/ARRIVAL/date+timehasCost String N/AhasId String N/AhasOptimization String N/ArouteSegmentReservationInfo String N/ArouteSegmentDetails RouteSegmentDetail N/AusingTransportType String typerouteSegmentInformation String code

IMAGINE-IT TIETOTALO / MTC / YTV

Table 17: Mapping of Finnish PT routers attributes to IM@GINE IT ontology.

For car routing Tietotalo uses PTV's dynamic routing service. See PTV's mapping tables.

11.2. MMS' services

11.2.1. Mapping service, Routing service, POI and Event search service


August 2005 96

Concept Slot Type SOAP Structure Direct match Indirect match/notesCoordinates mms:CoordinatesType

hasCoordinateX Float longitude WGS'84hasCoordinateY Float latitude WGS'84hasCoordinateZ Float N/A

Address mms:AddressSearchTypeinCity String placeonStreet String streetwithStreetNumber Integer houseNumberhasPostalCode String N/AinDistrict String Using place for city and/or districtforCountry String countryCode ISO-3166 country code

GeocodedAddress mms:AddressTypehasAddress Address (explicit fields)hasCoordinates Coordinates coordinates

BoundingBox mms:BoxTypehasUpperRightCoordinates Coordinates topRighthasLowerLeftCoordinates Coordinates bottomLeft

ScreenSize mms:ImageSizeTypehasPixelsWidth Integer widthhasPixelsHeight Integer height

POIForMap mms:MapIconType/mms:PoiTypehasPOIType String iconTypehasCoordinates Coordinates coordinateshasPOIName String Derive from POI.infohasPOIID String iconId

POI mms:PoiTypehasPOIType String categorieshasCoordinates Coordinates coordinateshasPOIName String namehasPOIID String poiIdhasAddress Address Must be deduced from fields in mms:PoiTypehasTelephone String Must be deduced from fields in mms:PoiTypehasFax String Must be deduced from fields in mms:PoiTypehasURL String Must be deduced from fields in mms:PoiTypehasEMail String Must be deduced from fields in mms:PoiTypeadditionalInformation String Must be deduced from fields in mms:PoiTypeoptionalInformation OptionalInformation[]

OptionalInformation mms:PoiInfoTypeoptionalAttributeName String typewithStringValue String value

Line N/AClickablePOI mms:MapIconType Used to display arbitrary icons, not only POIs

hasImageCoordinates ImageCoordinates pointhasPOIName String N/A

ImageCoordinates mms:ImagePointTypehasXPos Integer xhasYPos Integer y

Map mms:MapTypehasBoundingBox BoundingBox boxshowsPOIs ClickablePOI[] iconshasImage Image N/AshowsRoute Boolean N/A

Image mms:MapTypehasURL String imageUrlhasFileFormat String N/A. Matches the requested format

RouteSegmentDetail mms:RouteStepTypehasDestination Coordinates N/AisUsingMeans String Deduce from segment itselfhasDestinationInfo String Deduce from "description" fieldhasID Integer N/Aduration Integer durationdistance Integer distance

CoordinatesInCountry N/ARouteSegment mms:RouteSegmentType

hasID Integer N/AusingTransportType String vehiclerouteSegmentInformation String N/AstartsOn String startingTimefinishesOn String N/Aduration Integer durationdistance Integer distancestartsAt CoordinatesInCountry originfinishesAt CoordinatesInCountry destinationrouteSegmentReservationInfoString N/ArouteSegmentDetail RouteSegmentDetail[] stepshasCost String N/AhasOptimization String N/AusingBrand String N/AstartsAtPlace String N/AfinishesAtPlace String N/APTLine String N/ArouteSegmentMapID String N/A

Route mms:RouteTyperouteId String routeIdrouteSegments RouteSegment[] MMS has an extra-level (RoutePart)distance Integer distanceduration Integer duration

LineTimetable N/ATrafficEvent mms:TrafficInfoType

hasCoordinates Coordinates coordinates trafficEventType String dob May need conversionsadditionalInformation String Must be deduced/composed from place, direction and text.expiresOn String N/A

PublicTransportEvent N/A

IMAGINE-IT MMS

Table 18: Mapping of MMS' services to IM@GINE IT ontology.


August 2005 97

11.3. PTV's services

11.3.1. Mapping service, Routing service, POI and Event search service

Concept Slot Type SOAP Structure Field name Indirect match/notesCoordinates Coordinates

hasCoordinateX Float xhasCoordinateY Float yhasCoordinateZ Float NA

coordinateTypeAddress Address

inCity String cityonStreet String streetwithStreetNumber Integer houseNumberhasPostalCode String zipcodeinDistrict String cityDistrictforCountry String country

coordinateBoundingBox BoundingBox

hasUpperRightCoordinates Coordinates leftUpper Left upper coordinatehasLowerLeftCoordinates Coordinates rightLower Right lower coordinate

ScreenSize ScreenSize hasPixelsWidth Integer deviceWidth Map width in pixelhasPixelsHeight Integer deviceHight Map height in pixel

POIForMap POIForMap See POIhasPOIType StringhasCoordinates CoordinateshasPOIName StringhasPOIID String

defaultSymbol

The icon is used as default forvisualizing all POI’s of the set in a map.

profileName of a POI profile specifying how thePOI’s are rendered.

POI POI hasPOIType String poiTypehasCoordinates Coordinates coordinatehasPOIName String namehasPOIID String poiIDhasAddress Address attributes Map to optional attributeshasTelephone String attributeshasFax String attributeshasURL String attributeshasEMail String attributesadditionalInformation String attributes

poiViewsindexcontext

Line N/AClickablePOI ClickablePOI

hasImageCoordinates ImageCoordinates see ImageCoordinateshasPOIName String name

ImageCoordinates ImageCoordinates

hasXPos Integer devx

Device X as pixel; Device Coordinate object, used e.g. for determine the position of a POI relative to the map in which it is displayed.

hasYPos Integer devy Device Y as pixel

IMAGINE-IT PTV


August 2005 98

Map Map hasBoundingBox BoundingBox bbox BoundingBox of generated map

showsPOIs ClickablePOI[] poiViewSetsList of poiViewSets containing all POI’sdisplayed in the map

hasImage Image imageshowsRoute Boolean routes

mapNamea Partial or full addresswidth Logical width of the map in kmheight Logical height of the map in km

maxAdresses

Max. number of addresses returned if geocodingresult is not unique (if set to 0 all addresses arereturned)

poiVeiwSets

Optional list of POI sets to be displayed in the map,may also be an object of the subtypePOIViewMapSet to specify additional drawingparameters

p Dimensions and type of the returned imagegeoDataSource Name of geographic data source

targetMapNameOptional name for resulting map for laterreferencing

Image Image

hasURL String urlOnly

If set to true, the image is stored on theserver and just an URL pointing to theimage is returned

hasFileFormat String fileFormat GIF, JPG, etc.RouteSegmentDetail

hasDestination Coordinates N/AisUsingMeans String N/AhasDestinationInfo String N/AhasID Integer N/Aduration Integer N/Adistance Integer N/A

RouteSegment hasID Integer N/A

usingTransportType String N/AWill be transport mode such as Train, Plane, etc.

routeSegmentInformation String N/AstartsOn String N/A Will be departure timefinishesOn String N/A Will be arrival timeduration Integer time Time of route in [s]

distance Integer distanceDistance of route with unit depending onDistanceUnitEnum

startsAt (mixed) typeType of route element (START, VIA,END, INFO)

finishesAt (mixed) typeType of route element (START, VIA,END, INFO)

routeSegmentReservationInfoString NArouteSegmentDetail RouteSegmentDetail[] textInfo Aggregated textual information for guidancehasCost String toll Tollroads

hasOptimization String optimization

Option for setting routing preferences(fastest route, shortest route, mosteconomic route)

Route

routeSegments RouteSegment[] elementsThe route elements in the order they aretravelled through

hasMap Map NA

distance Integer distanceDistance of route with unit depending onDistanceUnitEnum

duration Integer time Time of route in [s]

lineThe polyline of the route, used fordisplaying the route in a map

stationsTwo or more addresses defining start, via points and destination of the route

maxAddresses Max number of addresses returnedrp Settings for route calculations Optional POIs for corridor searchGeoDataSource Name of geographic data source

Table 19: Mapping of PTV's services to IM@GINE IT ontology.


August 2005 99

11.4. TREDIT's services

11.4.1. POI and Event Search service

TREDIT uses TIETOTALO's Data Management Module (DMM) to implement its POI and Event Search services.

11.4.2. Routing service

TREDIT uses PTV's GIS services to implements its Routing service.

11.4.3. PT timetables service, Traffic information service

Concept Slot Type SOAP Structure Field name Type NotesCoordinates Same as PTV

hasCoordinateX FloathasCoordinateY FloathasCoordinateZ Float

PublicTransportTimetable tredit:PublicTransportTimetable usingTransportType String usingTransportType String startsAt Coordinates startsAt CoordinatesstartsAtPlace String startsAtPlace String timetable LineTimetable timetable PTTimetable

LineTimetable tredit:PTTimetablePTLine Id StringN/A Company String 3 letter codes, displayed as part of additionalPTInfo fieldN/A Origin String 3 letter code of the airport, displayed as part of additionalPTInfo fieldN/A Destination String 3 letter code of the airport, displayed as part of additionalPTInfo fieldN/A Via String 3 letter code of the airport, displayed as part of additionalPTInfo fieldarrivalOn ETA DateTimeN/A ATA DateTime displayed as part of additionalPTInfo fielddepartureOn ETD DateTimeN/A ATD DateTime displayed as part of additionalPTInfo fieldN/A CheckIn_Counters String displayed as part of additionalPTInfo field

additionalPTInfo

Remark, Company, Origin, Destination, Via, ATA, ATD

String, String, String, String, String, Datetime, Datetime

TransportEvent tredit:PTTimetablePTLine String Id StringusingBrand String Company StringN/A Origin String displayed as part of additionalPTInfo fieldN/A Destination String displayed as part of additionalPTInfo fieldN/A Via String displayed as part of additionalPTInfo fieldN/A ETA DateTime displayed as part of additionalPTInfo fieldN/A ATA DateTime displayed as part of additionalPTInfo fielddepartureOn String ETD DateTimeN/A ATD DateTime displayed as part of additionalPTInfo fieldadditionalPTInfo String CheckIn_Counters String

PTEventType String

Remark, Origin, Destination, Via, ETA, ATA, ATD

String, String, String, String, Datetime, Datetime, Datetime

IMAGINE-IT TREDIT

Table 20: Mapping of TREDIT's services to IM@GINE IT ontology.

11.5. TOPO's services

11.5.1. Mapping service, touristic information service, routing service, PT timetable service


August 2005 100

Concept Slot Type SOAP Structure Field name Notes

Address forCountry String strCountryCode ISO-3166 country code

strCountyinCity String strCityinDistrict String strDistrict

strQuarteronStreet String strStreetwithStreetNumber Integer strHouseNumberhasPostalCode String strPostalCode

GeocodedAddress : Address GeoCodedAddress:AddresshasCoordinates Coordinates cCoordinate

eResultsCoordinates Coordinate

hasCoordinateX Float dXhasCoordinateY Float dYhasCoordinateZ Float N/A

eCoordinateTypeN/A CoordinateTypeEnum

WGS84EOVSTEREO

N/A GeoCodedAddressResultEnumGCAR_OK Address was fully correctGCAR_CORRECTED Misstyped, but correected unumbiguously

GCAR_NEAR_HOUSENUMBER House number not found, replaced by the nearest availableN/A GeoCodedProperties

iFirst indexiLast index

N/A ReverseGeoCodedPropertiesiFirst indexiLast indexiRadius Limit in meter+G136eDetailLevel

N/A DetailLevelEnumDL_COUNTRYDL_COUNTYDL_CITYDL_STREETDL_HOUSENUMBER

BoundingBox BoundingBoxhasUpperRightCoordinates Coordinates cUpperRighthasLowerLeftCoordinates Coordinates cLowerLeft

N/A PoiId srtPoiTypestrPoiNamestrPoiId

POIForMap PoiForMap:PoiIdhasPOIType String Inherited from PoiID::strPoiTypehasCoordinates Coordinates cCoordinatehasPOIName String Inherited from PoiID::strPoiNamehasPOIID String Inherited from PoiID::strPoiId

N/A PoiSearchPropertiesiFirst indexiLast index

POI:POIForMap Poi:PoiIdhasAddress Address aAddresshasTelephone String strTelephonehasFax String N/AhasURL String strURLhasEMail String strEMailadditionalInformation String strGeneralDescription

IM@GINE-IT TOPO

Geocoding types

POI searching types


August 2005 101

N/A RoutePropertieseTransportTypeeOptimizationsbRoadCategories Used for optimizationdtTimebStartTime true: dtTime is departure time, false: dtTime is arrive time

bMultiAddressOptimizetrue: optimize address sequence, false: keep original address sequence in case of multi-address route

N/A TransportTypeEnumTT_CARTT_PEDESTRIANTT_PUBLIC

N/A OptimizationEnumO_FASTESTO_SHORTEST

Route Route Contains a multi-address route descriptionrouteSegments RouteSegment[] rmRouteMainshasMap Map

bbBoundingBoxstartsOn dtStart

dtFinishdistance Integer iDistance in meterduration Integer iDuration in second

RouteSegment RouteMain Contains a two-address route descriptionhasId Integer usingTransportType StringrouteSegmentInformation String

bbBoundingBoxstartsOn String dtStartfinishesOn String dtFinishduration Integer iDistance in meterdistance Integer iDuration in secondstartsAt Instance poiFromfinishesAt Instance poiTorouteSegmentReservationInfo String routeSegmentDetail Instance rsRouteSubshasCost String hasOptimization String

iRunChanges

RouteSegmentDetail RouteSub

Contains a part of two-address route. In case of PT, part means one run (line). Otherwise it means road sections with identical road name.A99

hasDestination Instance plPolyLinesPolyline for each section beeween two stops/junctions within RouteSub.

isUsingMeans String eVehicleTypehasDestinationInfo String eTurnInfo this is the next turn information for pedestrian and car

strDestinationInfo next stop info for PThasID Integer iId

bbBoundingBoxdtStartdtFinish

distance Integer iDistance in meterduration Integer iDuration in second

strNames Route name + alternate names if alternate runs exist.iStops # of stops + # of alternate runs's stops.

Routing types


August 2005 102

Line PolyLinehasOrderedCoordinatesList Coordinate[] cPoints

laAttributeN/A LineAttribute

strNameiRediGreeniBlueiWidthiBorderRediBorderGreeniBorderBlueiBorderWidth

N/A TurnInfoEnumTI_STRAIGHTTI_LIGHTLEFTTI_LIGHTRIGHTTI_LEFTTI_RIGHTTI_SHARPLEFTTI_SHARPRIGHTTI_NOTURNINFO

N/A VehicleTypeEnumVT_PEDESTRIANVT_CARVT_BUSVT_TROLEYVT_METROVT_TRAMVT_LOCALRAILWAY

PublicTransportTimetable PublicTransportTimetable usingTransportType String eVehicleTypePTID String strRunNamestartsAt (mixed) cStartPointPTTimetable String dtPTTimeTable

N/A ConnectBorderstrBorderPointName Name of border settlementcBorderPointCoordinate Coordinate of border settlement

N/A MapPropertiesbURL Use URL if truecsSizeeImageTypebScale Metric scale on map image if true.

ScreenSize ScreenSizehasPixelsWidth Integer iWidthhasPixelsHeight Integer iHeight

N/A ImageTypeEnumIT_PNGIT_GIFIT_BMPIT_JPG

Map MaphasImage Image imImagehasBoundingBox BoundingBox bbBoundingBoxshowsPOIs ClickablePOI[] cpPoisshowsRoute Boolean crRoutes

Image ImagehasURL String strURLhasByteCodeStream String binImagehasFileFormat String N/A

ClickablePOI ClickablePoi:PoiIdhasPOIName String Inherited from PoiID::strPoiNamehasImageCoordinates ImageCoordinates scCoordinate

ImageCoordinates ScreenCoordinatehasXPos Integer iXhasYPos Integer iY

N/A ClickableRouteiIdscPoints

Mapping types

Table information types

Traffic information types

Table 21: Mapping of TOPO's services to IM@GINE IT ontology.

information s technologies (ist) · level using these ontology specifications. the current...

Documents