Workpackages

WP I. An Infrastructure for Mobile Information Service Support

Based on the conceptual solution presented in the previous section, we are going to develop a general infrastructure for adaptive information services (see Figure 5). We see this infrastructure as a high level middleware which is above the CORBA level but still general enough to support basic components of the information services.
The basic components of the platform are as follows:

Customer profile description module
Service description module,
Customer-Assistant communication module,
Assistant -Service communication module,
Assistant functionality module,
Assistant deployment module.

The work on this general infrastructure includes designing basic interfaces between components of the infrastructure and communication mechanisms.

Figure 5. General architecture of platform

Basic research issues in the package: Communicative aspects of adaptive information services provision, middleware architecture.

Technologies that we see to be relevant for this workpackage are as follows: CORBA, FIPA ACL, OMG MASIF.

Results: detail architecture, definition of interfaces with components and system tools

Other workpackages consider design and implementation of the components of the infrastructure.

WP II. Customer Profile Description Module

Each user should be able to present his or her profile by telling the assistant what are his/her preferences/interests. Since most non-experienced customers probably may find this a hard and time consuming task, it should be possible to create certain default profiles target at large groups of users (see Figure 6).

Figure 6. Customer profile presentation

In this package we are going to develop means (a language and representation technique) for user profile description and analysis. The means will be based on developed customer models.

Basic research issues in the package: User modeling in mobile information services environment (models and tools), user profiles creation and composition

Technologies that we see to be relevant for this workpackage are as follows: XML, KIF, Prolog, Ontology

Results: analysis and development of customer models, methods and tools for profiles creation, pro-active modification, composition and selection.

WP III Service Profile Description Component

Presentation of services will use means similar to the Customer Profile Description means. This is necessary for performing successful matching user needs and service provider offers. However, the difference of this component with the Customer Profile description module is in taking into account a context of communication for offering relevant services. In particular, location based service provision/offering should be a central part of this module.

Basic research issues in the package: Models and tools for information service presentation, selection and provision, information service creation and composition

Technologies that we see to be relevant for this workpackage are as follows: XML, GSM positioning, GPS.

Results: models, methods and tools for service description, developing methods and tools for utilization of contextual information in service provision

WP IV. Customer-Agent Communication Module

Communication between the customer and the agent can be done in two ways (see Figure 7).

Figure 7. Customer-Agent communication module

1. In the case of indirect communication, the customer can read pages from the Internet, for example, via a WAP-enabled mobile device, and the assistant prepares such pages containing data to be read by the customer.

2. In the case of direct communication, the agent sends SMS (Short Messaging Service) messages to the customer's mobile phone. Contents of the messages may include brief notifications of important events and the URL address of the web/WML-page(s) where more detailed information can be found.

We would like to note that in case of only short notification messages, cellular phones without WAP could also be used for notification of customers. We also would like to note that the WAP technology for mobile devices is not critical in our approach. Any other protocol allowing communication of mobile phones with Internet should be easily attached to the platform.

Customers will input information for the agent via menus on their phones, and this allows making changes into customer profile in real-time.

Customers can be represented by several assistants (corresponding to different customer interests) and the assistants can form coalitions in order to provide more detailed and personalized communication.

Basic research issues in the package: Communicative aspects of adaptive information services provision, coalitions formation for information services provision and selection

Technologies that we see to be relevant for this workpackage are as follows: WAP, WML, SMS

Results: designing models and tools for mobile device-based user interface, designing models and tools for coalitions formation, designing methods and algorithms for coordination and negotiation between assistants using marketplaces.


WP V. Assistant -Service Communication Module

Communication between customer assistants and service provider assistants can be organized using pull and/or push techniques. Both these techniques can be utilized depending on situations and their implementation should be symmetric. This means that both parties can initiate communication and select the communication method.

We believe the pull technique will most often be used for regular service provision and consumption, while the push technique seems to be more suitable for urgent notification. For example, a stock market service provider may regularly put stock quotes into a common message-pool. A similar pool can be used by an assistant for requests to a service provider. However, notifications of significant changes in DJIA (Dow Jones Industrial Average) or NASDAQ stock indexes can be pushed directly to assistants without letting them wait to read such news from the message-pool after a time interval which is defined for them.

Service provider assistants can be involved into communication with customer software assistants and the communication may include service marketing, customer's needs identification and price negotiation. This already refers to the group view in the service provision approach, and it requires high-level language-based communications and applying advance negotiation techniques.

Basic research issues in the package: Communicative aspects of adaptive information services provision, negotiation protocols, coalitions formation, notification models

Technologies that we see to be relevant for this workpackage are as follows: FIPA ACL, Ontology management, XML, WML.

Results: designing methods and tools for service marketing, identification, customization and selection, coalition formation methods and negotiation models.

WP VI. Assistant Functionality Module

Functionality of the assistant can be different for different applications, and may, for example, include:

Filtering information,
Search for services,
Comparison of services,
Finding other agents that carry similar user preferences (Collaborative filtering) [7,18],
Learning from the customer behavior/interaction [8,9,10].

In our project proposal we assume that the functionality of the assistant is implemented as an independent software component that can be overridden when needed. Complexity of assistant functionality will depend on amount of resources allocated to the project.

Basic research issues in the package: Learning assistants in mobile information services, semantic aspects of information retrieval, collaborative filtering

Technologies that we see to be relevant for this workpackage are as follows: Prolog, XML, Ontology, KIF, FIPA

Results: models and tools for information search, analysis, filtering and composition.


WP VII. Assistant Deployment Module

In order to support the creation of software assistants, we need a deployment module. The module will implement general assistant functionality and supports easy customization, overriding and extension. An assumed assistant functional structure is presented on Figure 8.


Figure 8. Assistant functional structure

The functional structure includes the following blocks:

Communication blocks including ACL communication with other assistants and a low-level (signal-level) communication with the environment.
Goal Analyzer/Synthesizer (GA) module perceives the environment, synthesizes a goal description, evaluates incoming messages and selects a plan from a collection of alternative plans.
Planner module creates a collection of plans based on the goal and Knowledge Base (KB).
Executor - performs actions according to assistant machinery level rules.
Reactive block - perceives and act with environment
Declarative reflection manager - the ability of an assistant to observe itself and to modify its behavior on the basis of this observation.

Basic research issues in the package: Knowledge representation, action planning, learning methods, reflection support in adaptive information services

Technologies that we see to be relevant for this workpackage are as follows: Prolog, KIF, FIPA ACL, XML.

Results: detail architecture of a generic software assistant, general methods and tools for implementing assistants' components.