An Agent-based System for Infomobility Services.

Abstract

This paper describes an agent-based service network architecture proposed for a real world application for the infomobility sector. This sector demands that mobile users (i.e. roaming users using mobile phones, PDAs, etc) have access to accurate real-time location-based services that are inherently distributed throughout the web. Such are traffic information, geo-reference, routing, or mapping services that are usually offered as web services. Thus, there is the need for a service network for the infomobility sector, which integrates electronic services for mobile users as well as it caters for services personalization. This issue was addressed using agent technology in the context of the IST project Im@gine IT. The overall system architecture and business model are presented along with a particular focus on the multi-agent system which is the core component of the Im@gine IT system.

Full text

AN AGENT-BASED SYSTEM FOR INFOMOBILITY SERVICES
Pavlos Moraitis a Eleftheria Petraki b Nikolaos I. Spanoudakis b
a Dept. of Mathematics and Computer Science, University René Descartes-Paris 5,
45 rue des Saints-Pères, 75270 Paris Cedex 06, France,
pavlos@math-info.univ-paris5.fr,
b Singular Software SA, Al. Panagouli & Siniosoglou, 14234 -Nea Ionia, Greece,
{epetraki, nspan}@singular.gr
Abstract
This paper describes an agent-based service network architecture proposed for a real world
application for the infomobility sector. This sector demands that mobile users (i.e. roaming users using
mobile phones, PDAs, etc) have access to accurate real-time location-based services that are inherently
distributed throughout the web. Such are traffic information, geo-reference, routing, or mapping services
that are usually offered as web services. Thus, there is the need for a service network for the infomobility
sector, which integrates electronic services for mobile users as well as it caters for services
personalization. This issue was addressed using agent technology in the context of the IST project
Im@gine IT. The overall system architecture and business model are presented along with a particular
focus on the multi-agent system which is the core component of the Im@gine IT system.
1 Introduction
The infomobility business sector concerns the servicing of mobile users (usually using a mobile phone
and/or a PDA, his car’s system, etc) through wireless networks, based on a variety of technologies like
GPS and GIS – routing and mapping systems – and different kinds of distributed content like public
transport timetables, traffic information, etc. This complex environment motivates the combination of
simple services in order to provide more complex ones [17]. In this context, a user can for example find
a route from one place to another, see it in a map and be able to bookmark it.
Moreover, a service must be multi-modal in the sense that the user continuously changes his
transportation means and thus this service has to support him differently each time, e.g. when he is in
the car the messages should be audio messages rather than icons on the PDA (i.e. a palm-top
computing device) screen.
Furthermore, the services may be accessible in a local area using technologies like WLAN or
bluetooth. Such services and their utilization on behalf of a user constitute the ambient intelligence.
Finally, the users want accurate, up-to-date information and ability to roam through other
countries. Thus, they need information that is generated at a local level and disseminated globally
through a service network. This network should allow for the easy integration of dispersed service
providers that provide different services, not necessarily known before system development. All these
user demands constitute a brand new area of services, namely the mobile, global, personalized, multi-
modal infomobility services.
These are the main goals for the Im@gine IT system, proposed in the context of the IST project
Im@gine IT and mainly the multi-agent system (MAS) which is its core component. This paper aims to
show, how such services will be offered, how they are going to be available world-wide through a
service network and in parallel via this real world application, the added value that emerges from agent
technology use (see e.g. [22]). In this context, the possibility for getting services through mobile
devices based on distributed brokering is in our knowledge an innovative element.
The rest of the paper is organized as follows. Section 2 presents the problem description and
Section 3 the application description. In Section 4 issues related to the application’s benefits are
discussed. Finally, Section 5 discusses related work and conclusions.

2 Problem description
Let us now precisely define the new services that were the requirements of the Im@gine IT system.
Actually, this system must be able to provide transport solutions and tourist services from a various set
of providers, according to the user needs, matched to his/her profile and habits. More specifically, the
system must be able to:
• Support different “types of users”. The user himself/herself will choose his/her type and
preferences (i.e. tourist, public transport user, driver, etc.) and will receive services that take
these parameters into account. Actions will be taken to secure user’s sensitive personal
information. Moreover the user can choose to edit more than one profiles (i.e. commuter,
tourist, business traveler, etc) in order to have different modes of service.
• Adapt the service according to user’s habitual patterns. Also, supply any missing information
based on user profiling. Nevertheless, system initiated actions will always be subjected to
user’s permission, to avoid user frustration or surprise.
• Receive the user request, as analyzed by the user interface, his/her position (through GPS co-
ordinates if available) and suggest optimal transportation solutions, tourist events and nearby
attractions.
• Monitor the user’s route and automatically provide related events during the journey (i.e. info
on traffic jams or emergencies on route).
• Support the user while he is roaming between countries. Always allow him to use local, real-
time services that are accurate and quick to download.
• Support the user while he changes the modality of travel. Allow for audio messages while
he/she is in the car, real-time information about next stop while he/she is in the train and
information about the street name for the next turn while walking.
The Im@gine IT requirements and use cases were presented by Mizaras et al. [10].
2.1 Why Use Agent Technology
The agent-based approach has been selected for developing this system, since the following
requirements posed by such an application:
• Timely and geographical distribution of users and services, have to be taken into account.
• Heterogeneity of services, devices and networks are provided by different sources; services
can be tailored to users profiles.
• Coordination of elementary services in order to provide the user with a complex, personalized
service.
The above requirements invoke characteristics as autonomy, pro-activeness, intelligence and
cooperation, which relate to basic motivations that would make someone utilizing agent technology
(see e.g. [22]). More precisely agents can have the sufficient intelligence to achieve more (e.g.
personalized assistance) or less complex (e.g. travel information retrieval, user location, etc.) tasks in
an autonomous way. Such tasks can be achieved either by agents equipped with the appropriate
individual capabilities, or by efficient interaction among agents of different types that have
complementary capabilities. In the application described in this paper, agents belong to different types
(i.e. interface, travel guide, educator, event handler, services, assistant and personalized assistant), and
fulfil different tasks associated to the functionalities of the multi-agent system (MAS). In some cases,
agents, due to their characteristic of pro-activeness, will be able to take the initiative to provide users
with information related to their context. The MAS is the core module of the IM@GINE IT system that
services mobile users through a variety of devices (i.e. mobile phones, PDAs, PCs). The Im@gine IT
project foresees the use of several Im@gine IT platforms in order to assist mobile users around the

world and thus interoperability is a crucial point, which can be also very well achieved through the use
of agent technology. This technology can presently provide, in combination with other adopted
technologies (e.g. Web Services [21], the Semantic Web [20]), appropriate solutions for the
interoperability issue among heterogeneous agents.
3 Application description
3.1 The Im@gine IT concept
The Im@gine IT project aims to create an information system that will satisfy the requirements
presented above. The proposed services will be customizable, adapted to user habits (personalized
service) and location based. The challenge is to integrate simple services, offered by different business
entities, at different geographic areas and by heterogeneous information systems. Thus, the first step
was to identify the interested parties and define a viable business model [8].
B2C Operator
Service
Integrator
Service Provider
Content Provider
End User
Figure 1: Im@gine IT business model
The overall Im@gine IT concept/business model is presented in Figure 1. In every box more than
one player may be active. The identified business entities can be:
• End User. He/She is the owner of an enabled user device, or owner of a vehicle with an
enabled in-car device through which he/she can access the Im@gine IT services.
• Business to Consumer (B2C). It is the entity that interconnects end users and their mobile
devices with the Im@gine IT services. The B2C entity can be a mobile network operator
company and may integrate the Im@gine IT services with the other voice and data services
that already offers to its customers. It can advertise and sell the product to its customers,
provide the necessary network infrastructure (GPRS) and is responsible for regular customer
care.
• Service Integrator. This entity handles the marketplace between B2C entities and service
providers. This entity does not have information about the end users; its purpose is to provide
integrated services to B2C operators. It accepts the service advertisements coming from
service provider entities and matches an incoming request to the appropriate service.
• Service Provider: It is the entity that owns or supplies (basic) content and (basic) services. The
service provider can publish services on the service integrator’s platform.
• Content providers: entities that provide e-content such as a list of hotels for a city, points of
interest (POIs), public transport time tables, real time traffic information, etc.
• According to the above business model the Im@gine IT system’s main goals are:
• To successfully personalize the service for the end user.

• To allow for seamless interoperation between all business entities in order to achieve a global
service.
• To acquire services from different and possibly heterogeneous external – third party service
providers.
3.2 Agent roles and types
We employed the Gaia methodology [23] for system analysis and design and the work proposed by
Moraitis and Spanoudakis [12] on the use of the JADE [4] platform for implementing Gaia models.
During the Gaia design phase the following roles were identified. The Im@gine IT MAS is composed
of several types of agents that correspond to these roles and they are displayed in the MAS architecture
presented in Figure 2.
Mapping Services,
Routing Services,
Touristic Information Services,
Traffic Information Services,
Reservation Services
Web Services,
SOAP, XML
Interface Agent
Complex Services
Agent
Middle Agent Events Handler
Agent
Transport Mode
Agent
Personal Assistant
Agent
Mobile User
Provider Agents
JAVA
JAVA
Site services
In-vehicle
services
Figure 2: MAS architecture.
Each identified role was mapped to an agent type. Briefly, the main characteristics of each agent
type are:
• Personal Assistant (PA) Agent: This agent resides on the end user’s device servicing the user
in a personalized and intelligent way. He interacts with the on the device graphical user
interface, accepting the user’s requests and providing the results of the accomplished service.
He maintains the user’s profile that enables him to manipulate the requests and the results
according to the specific user’s preferences.
• Transport Mode Agent: This agent is also implemented on the end user’s device and supports
the personal assistant role. He monitors the user’s active route and tracks his progress

notifying the PA whenever a route segment has been completed. He also can send information
to the user, e.g. about the next bus-stop. It is also used for accessing nearby services supplying
the results to the personal assistant for further processing (e.g. can understand when the user
enters his car).
• Interface Agent: This role controls the access of the end user to the local main MAS platform.
The interface role is a part of a B2C operator site in which the user authentication and profile
data reside. He provides the end user an ID which will be used in all subsequent interactions
with the main MAS platform. The interface role is also responsible of maintaining a backup
copy of the user’s profile.
• Middle Agent: The middle agent resides on the main MAS platform acting as service
integrator. The middle agent accepts advertisements from complex or simple service provider
agents and also accepts requests for service from the personal assistant agents. A received
service request is matched with the available advertisements and if the middle agent finds a
successful match forwards the user request to the selected advertisement service provider.
When he gets the answer he forwards it to the personal assistant agent. The middle agents are
federated so if a request asks for a service that is made available to the network through
another middle agent closer to the user location, the request is forwarded to the latter. With the
type of middle agent we use (i.e. broker) the roles that participate to the transaction are
unknown to each other.
• Service Provider Agent: This role provides a service to the network advertising it to the
geographically closest middle agent and subsequently accepting and servicing any requests
that concern the specific service. The advertising of the service is a specification of the service
accompanied by metadata that specify conditions under which the service will be offered
(geographical area that the service can be achieved, price, availability, etc). In the MAS
architecture a provider role can be:
- Simple. The simple service provider role advertises and accepts simple services such as
mapping or geocoding.
- Complex. The complex service provider role is capable of synthesizing a complex service
requested by the user (e.g. plan a trip), interacting with one or more simple service providers.
- Events Handler (subscription service). This role accepts events and forwards them to the
interested personal assistant agent. The events can be traffic events along a specific route that
a certain user has activated and submitted to the events handler.
3.3 Middle agents
In order to realize the service brokering layer we used the middle agent concept. The middle agent type
that covered the needs of our application was the broker agent [6]. A broker agent can actively
interface between the requester and provider agents by facilitating the requested service transaction.
Thus, all communication between requester and provider agents has to go through the broker. As soon
as he gets a request, the broker performs a matchmaking process aiming to locate the most relevant
service with an available description, previously advertised by a provider agent. Then he contacts the
associated provider agent to that service description, negotiates for, executes and controls appropriate
transactions and returns the result of the services to the requester. Moreover, in our system brokers can
be distributed and each one can specialize to a specific domain of services. In this process the
requester’s identity is unknown to the service provider. Thus, assuming the business role of a service
aggregator the broker services his customers using providers as resources.
The service requesters are assumed to be aware of the services that they need. In our system, the
role of the broker is to either select the best service for the requester, or to redirect the request to the
appropriate broker. In Im@gine IT the brokers are based on location that means that each of them is
responsible for a specific geographical area. For this type of project there could be many competing
service providers per area.
The greatest challenge in designing a broker is to model the service descriptions and requests, and
to define the matchmaking process. These two tasks are highly interrelated since the input to the
matchmaking process is the service request and the descriptions of available services.

Similarly to the work of Li and Horrocks [7] both the service advertisements and requests are
accompanied by a service profile. The service profile (SP) defines the type of the service (e.g. mapping
service), describes input and output parameters, as well as preconditions and post-conditions. The
service advertisement defines this profile while the service request, defines the type of requested
service, describes input and output parameters and also places values to input parameters. For the
definition of the service profile we use the relevant specification by OWL-S [9]. Then we use the FIPA
request/inform performatives in order to provide a service provisioning protocol (see Figure 3).
The matchmaking process can be now facilitated since the input requests and profiles are well
defined. We need to match a service advertisement to a service request. Two types of matching were
found to best serve our needs [7, 18]:
• the exact matching, which demands that the advertised service has the same semantics and
equal inputs/outputs with the requested service, and
• the plug-in matching, which will allow for the advertisement to have more inputs/outputs than
the ones requested. The exact matching is obviously always preferable.
The matchmaking algorithm that we conceived gradually filters the repository of advertisements
until the one best to serve the request is found. Three types of filters, originally proposed by Sycara et
al. [18] were used:
• Semantic Match (SM). This type of matching searches the service profile advertisements
(PAs) for a service that matches the request (RP). In our case, SM will be selecting all the
“routing” services for example.
• Profile Match (PM). This type of matching searches the PAs provided by the SM for input and
output parameters that match those of the request. PM determines which PAs are exact or
plug-in matches and sorts them accordingly.
• Constraint Match (CM). This type of matching shall determine which of the PAs provided by
the SM, matches the constraints of a request (e.g. language should be Greek). CM is
performed to the sorted list provided by PM and the first PA that successfully matches the
constraints will be the selected service.
A special CM is needed before SM (named Pre-CM) so that the broker agent (BA) can determine
if he can serve the request or it needs to redirect the request to another broker. This CM will be based
on a broker capability property. In Im@gine IT the distributed broker capability will be the location of
the request (i.e. the country).
For querying the PAs repository we use RDQL (RDF Query Language) of the Jena [5] open
source tool.
Requester
Agent Broker
Agent Provider
Agent
request request
informinform
Broker
Agent
request inform
Provider
Agent
request
inform
Figure 3: Service provisioning protocol

Thus, according to our matchmaking algorithm, the broker first applies the pre-CM filter. If he can
handle the request, he then sequentially applies the three other filters (SM, PM, CM) to his PA
repository. Otherwise, he forwards the request to the broker that can facilitate him and waits for the
answer which he subsequently forwards to the user. The service provisioning protocol is presented in
Figure 3.
3.4 The agent-based service network
The agents of our system form a service network if looked from a business viewpoint (see Figure 4). It
is conceptually a brokering network where new services appear while old ones disappear, allowing for
dynamic value flows throughout the value chain. Moreover, it allows for the introduction of new
services not known before system deployment.
This service network is synthesized by four different layers (Figure 4). The top layer is the
consumer layer. Here are two business entities, the end users and the resellers namely the network
operators or other B2C entities that advertise and sell the services to the end user. The users are
represented by their personal assistant agents, while the B2C entities by their interface agent.
Service Network
Service Brokers
Service Providers
B2C Network Operator
Greek
WS
Service Brokers
Hungary
WS
Service Providers
B2C Portal
German
WS
B2C Layer Service
Brokering Layer
Semantic
Service
Providers
Web Services/
Legacy Systems
Legend
Personal Assistant Agent or Interface Agent
Service Provider Agent
Broker Agent
... ...
Figure 4: Im@gine IT service network
The next layer is the service aggregator layer namely the delivery channel. Here are the middle
agents, who know the service providers (i.e. the goods producer agents) and play the role of the
brokers.
The following two layers are of the service providers and the external legacy systems that through
web services offer the actual services. Content and service providers can enter the service network
either using their own agent (in that case there is not a 4th layer) or using legacy systems (e.g. a web
service). If they use their own agent they should use the ACL protocols that the Im@gine IT system
uses. The content of the ACL messages exchanged between a broker and a service provider is encoded
in RDF format, so the provider can use his own ontology provided that there is an OWL file that can
map concepts between the two ontologies. Those that use legacy systems should create the appropriate
provider agent that wraps their services.

3.5 Federation of agents – MAS deployment
The Im@gine IT system is distributed across different geographical areas, each of them serviced by
one service integrator (i.e. broker agent), one or more service providers (i.e. simple & complex service
provider agents and events handler agents) and one or more B2C operator platforms (interface agent,
see Figure 5). The area-relevant services that are advertised from the service provider agents to the
local broker agents may differ in quantity and nature from other geographical areas. However, these
services can be accessed by the end users everywhere since the broker agents of the entire Im@gine IT
distribution cooperate, forming a consortium. Each broker agent is aware of the network addresses of
the other broker agents in the community as well as the geographical area they cover. A request for a
cross boundary service, for example a trip to another country, can be serviced for the initial part of the
trip by the local broker agent and be forwarded for completion to the appropriate remote broker agent.
This collaboration among the broker agents is transparent to the end user who shall receive a complete
description of the requested trip.
Service Integrator &
Provider for
Geographical Area B
Geographical Area B
Personal
Assistant
Agent
Interface Agent
Broker & Service
Provider Agents
Nomad Device
Service Integrator for
Geographical Area A
B2C Operator
Geographical Area A
Service Provider
Interface Agent
Service Provide
r
Agents
Broker Agent
Nomad Device
B2C Operator
Nomad Device
Personal
Assistant
Agent
Personal
Assistant
Agent
Figure 5: Federation of agents
This federation scheme allows for a seamless expansion of the Im@gine IT service network as
new geographical areas and their service integrators and providers can dynamically be introduced and
made available to the rest of the community. Each geographical area can support a number of
independent B2C operators that can host, maintain and authenticate end users and grant them access to
the Im@gine IT services, acting as portals. All the functionalities of a B2C operator are accomplished
by the interface agent who after the successful authentication, assigns a user ID that is subsequently
used for accessing the Im@gine IT services. In the case of the roaming user the authentication

procedure is initiated on the local business partner of the B2C operator that he/she was initially
registered. The local partner is responsible to contact the remote B2C operator and to forward the
authentication request. As soon as the end user is authenticated he/she can access directly the local
broker agent with the assigned ID and bestow his/hers requests. With this scheme the end user can
benefit from the Im@gine IT services regardless of his/hers location.
3.6 Achievements
An Im@gine IT prototype has been developed and deployed using a subset of the initially declared
services. Through this prototype an end user can access directly a service integrator and request a “plan
a trip” and a “show me around” service. A “plan a trip” service can automatically decode the current
user’s position, decide the desired destination if one is not provided, calculate a number of routes
according to the user’s preferences in his/hers profile, and present the routes to the user. Similarly the
“show me around” service presents a map around the automatically calculated user position that
contains the points of interest (POIs) that fit to the user’s profile.
We used the JADE-LEAP [5] framework for the development of the agents both on the user’s
mobile device (personal assistant agent) and in the service integrator and provider platforms (broker
agent & simple and complex provider agents respectively).
The advertisement of the services is realized with the RDF codec embedded in the JADE
framework and the ontology necessary for the interpretation of the message content was developed
with the Protégé tool [16]. A problem that we had to overcome is that FIPA ACL allows for a single
ontology to be included in the content of an ACL message. Thus, it is not possible to use different
existing ontologies when defining the ACL protocols, and thus we had to create a new one with all the
concepts that we need.
The FIPA [2] ACL SL0 was employed for modeling the agent coordination protocols using the
request, inform, failure and refuse performatives. Finally, the actual services are accessed using SOAP
and WSDL [21].
With this prototype we managed to address the system requirements and accommodate through the
use of appropriate agents all entities described in the business model.
4 Application benefits
The proposed architecture offers many major advantages compared to others [15, 14, 11, 3]. First of all
it is modular, allowing for dynamic addition and removal of various components. Actually, the MAS
that we developed consist of three different products:
• The personal assistant and the transport mode agents (device application) that any user can
purchase and install on his device (PC, mobile phone, PDA, in-car device).
• The interface agent that manages the users of a portal or network operator. Note that any
mobile network operator can choose to supply the device application for free.
• The broker agent with optional add-ons in the form of service provider agents.
Secondly, the user (using a personal assistant) can access all available infomobility services
through any known access node (i.e. broker agent). New services appear dynamically (even new types
of services), along with new personal assistants that can take advantage of them. Thus the system is
expandable and FIPA compliant, thus allowing for heterogeneous agents to fit in (either as service
providers or requesters).
Moreover, the user can have a service tailored to his needs. The personal assistant not only profiles
the user but using a statistical learning method can anticipate his needs and successfully personalize the
service. Compared to [11] the innovation is on an algorithm that learns the maximum number of
transportation type changes (e.g. a trip with the user changing three buses/trains to get to his destination
involves 3 changes of transportation type) that are acceptable by the user in a multi-modal trip chain.
Thus the personal assistant agent proposes only the routes that the user is more likely to select.
Additionally, the user can access the Im@gine IT services anonymously (through the broker), thus
ensuring his privacy.
Furthermore, the concept of complex provider agents that provide added value services allows for
the anonymous submission of user profile information by the personal assistant, so that the information

filtering for the specific user takes place on the server side. This is an advantage since the transfer of
redundant information on a user device can be time consuming (low wireless bandwidth, e.g. GPRS)
and expensive. When the user asks “show me around” there may be hundreds of POIs in his vicinity,
while after the relevant filtering only a small number will be shown to him (e.g. 10).
5 Related work and conclusions
This paper presented an agent based, real world application in the context of the proposed Im@gine IT
IST project. This system integrates a set of intelligent agents having different functionalities that are
necessary in order to cover the infomobility services application field. Through the detailed description
of the conceived system, we have shown that agent technology responds perfectly to the basic
requirements of such applications and thus is well suited for developing information systems for a
modern and important domain of application, the one providing integrated services for mobile users.
The characteristics of Im@gine IT system are presented in Table 1, side by side with other
products of similar research projects and Maporama. The latter included as a commercial product that
offers a wide range of services, typical in this domain of services provisioning. This table provides a
user-centric comparison on the capabilities of these systems.
Characteristic \ System
Im@gine IT
Image
Crumpet
PTA
Maporama
Use external service providers 9 9
Route to POI 9 9
User profiling 9 9 9 9
Adaptive to user habits 9 9 9
Bookmarking 9 9 9
Agent on the device 9 9 9
World-wide coverage 9 9
Multi-modal trip planning 9
Ambient Intelligence 9
Table 1: Comparison of infomobility services products
The implementation advantages of our approach related to these approaches have already been
presented in Section 4. The presented architecture provides solutions for the future personal travel
assistant (PTA) developments as they have been identified by FIPA [1]. We address the challenges: a)
of agent mobility in a network (the personal assistant agent delegates the task of filtering huge amounts
of data to the complex provider agent by sending parts of the user profile along with the user request),
b) travel monitoring (through the concept of complex provider and events handler agents) and c) inter-
operation between agents and workflow (by allowing the interface agent to manage value flows
between the user and the brokers, the latter managing the value flow towards the provider agents).
We extend the work of Varga and Hajnal [19] who propose a methodology for providing web
services through the usage of wrapper agents. We put forward another way to engineer web service
wrapper agents that is in-line with semantic web developments [20]. In our notion any service
aggregator entity will be offering services using ontology for defining concepts and services. The
problem is not to translate a service to ontology but to map the service to the broker ontology. This can
be done at the broker or provider agent level since the ACL messages are RDF encoded and an OWL
file providing the translation can be dynamically used by both agents.
In comparison to Infosleuth (that uses distributed brokers, [13]), our approach provides many
advantages. The first one is its compatibility with FIPA standards that allows for heterogeneous FIPA
compliant agents to easily request/provide services. The second and most important is that brokers do
not simply exchange their advertisements. They rather define their special capabilities over the
provided services in the domain (e.g. transport and tourism). Finally, in our approach the personal

assistant agent doesn't have to define a search policy for the broker. He doesn’t have such knowledge
he just knows a broker and requests for a service.
Acknowledgements
We gratefully acknowledge the European Cimmission Information Society Technologies (IST)
Programme and specifically the Specific Targeted Research Project (STRP) “Intelligent Mobility
AGents, Advanced Positioning and Mapping Technologies, INtEgrated Interoperable MulTimodal
location based services” (IM@GINE IT, IST-2003-508008) project for contributing in the funding of
our work.
References
[1] FIPA: Personal Travel Assistance Specification. Foundation for Intelligent Physical
Agents, XC00080B, http://www.fipa.org, 2001
[2] FIPA: ACL Message Structure Specification. Foundation for Intelligent Physical Agents,
SC00061G, http://www.fipa.org, 2002
[3] C. Gerber, B. Bauer and D. Steiner. Resource Adaptation for a Scalable Agent Society in
the MoTiV-PTA Domain. Hayzelden, Bigham (Eds): Software Agents for Future
Communication Systems, Springer, 183-206, 1999
[4] JADE – Java Agent Development Environment, http://jade.tilab.com/, 2005
[5] Jena – A Semantic Web Framework for Java, http://jena.sourceforge.net/, 2005
[6] M. Klucsh, K. Sycara. Brokering and Matchmaking for Coordination of Agent Societies:
A Survey. In Omicini et al (editor), Coordination of Internet Agents, Springer, 2001
[7] L. Li and I. Horrocks. A software framework for matchmaking based on semantic web
technology. International Journal of Electronic Commerce, Vol. 8, No 4, 2004
[8] T. Manos, V. Mizaras, A. Bolelli, A. Bekiaris, M.Panou. D8.1 Dissemination and Use
Plan. IST-508008 project deliverable, http://www.imagineit-eu.org/, 2004
[9] D. Martin (editor). OWL-S: Semantic Markup for Web Services. W3C Member
Submission, 2004
[10] V. Mizaras, T. Manos, T. Pachinis, A. Batsis, P. Beck, J. Weisser, T. Pretsch. D1.1 Use
Cases and user/vehicle profile requirements. IST-508008 project deliverable,
http://www.imagineit-eu.org/, 2004
[11] P. Moraitis, E. Petraki and N. Spanoudakis. Providing Advanced, Personalised
Infomobility Services Using Agent Technology. In: 23rd SGAI International Conference
on Innovative Techniques and Applications of Artificial Intelligence (AI2003),
Cambridge, UK, 2003
[12] P. Moraitis and N. Spanoudakis. The Gaia2JADE Process for Multi-Agent Systems
Development. Applied Artificial Intelligence, 20(4-5), April, 2006
[13] M. Nodine, W. Bohrer, A. Ngu. Semantic Brokering over Dynamic Heterogeneous Data
Sources in InfoSleuth. In Proceedings of the International Conference on Data
Engineering, 1999
[14] A. Pétrissans. Geocentric Information. IDC http://www.maporama.com, 2000
[15] S. Poslad, H. Laamanen, R. Malaka, A. Nick, P. Buckle and A. Zipf. CRUMPET:
Creation of User-friendly Mobile Services Personalised for Tourism. Proceedings of the
2nd International Conference on 3G Mobile Communication Technologies. London, UK,
2001
[16] Protégé, An Ontology Editor and Knowledge Acquisition System.
http://protege.stanford.edu, 2005
[17] D. Sonnen. Market Research: What does the future hold for mobile location services?
Business Geographics, http://www.geoplace.com/bg/2001/0101/0101mrk.asp, 2001
[18] K. Sycara, S. Widoff, M. Klusch and J. Lu. LARKS: Dynamic Matchmaking Among
Heterogeneous Software Agents in Cyberspace. Journal of Autonomous Agents and
Multi-Agent Systems, 5, 173–203, 2002.

[19] L.Z. Varga and A. Hajnal. Engineering Web Service Invocations from Agent Systems.
LNCS, Vol. 2691, Springer-Verlag, Heidelberg, 2003
[20] W3C. The Semantic Web activity. The W3 Consortium, http://www.w3c.org/2001/sw/,
2001
[21] W3C. Web Services Activity. The W3 Consortium, http://www.w3.org/2002/ws/, 2002
[22] G. Weiss. Multi-Agent Systems: A Modern Approach to Distributed Artificial
Intelligence. MIT Press, 1999
[23] M. Wooldridge, N.R. Jennings, D. Kinny. The Gaia Methodology for Agent-Oriented
Analysis and Design. Journal of Autonomous Agents and Multi-Agent Systems, 3(3) 285-
312, 2000