Centre for Virtual Working Systems, School of Computer Studies, The University of Leeds, Leeds LS2 9JT, United Kingdom. Tel: +44 1132 335474, Fax: +44 1132 335468, email: ali@scs.leeds.ac.uk

The effective access to information through WWW[1] has motivated the need to investigate new system architectures to deal with the heterogeneous nature of information available. A further problem is the volume of information available, most of which is irrelevant for any individual task at hand. To deal with this problem, personalised event management procedures are needed where information is customised according to user need. In the ADVISER project, which aims to provide a personalised system for access research to European research results, a system architecture has been developed for finding information sources available in the EU network. This includes: locating and monitoring the relevant information applied to different clients, formulation of queries which are compatible with the available data resources, interpretation and filtering of the retrieved information, pesonalised information and finally making clients aware of the new information available through a notification process.

The ADVISER system consists of an EU Dynamic Knowledge Service (EUDKS) that contains summaries of, and pointers to, European research activities and a Broker Information Service (BIS) and delivering a number of added value information services. This added value information consists of statement exploitation opportunities, regional implementation or native language translations.

The EUDKS has been built around a well-defined, domain specific, information model[3]. The domain is confined to the European research structure. The model consists of directory "entities", "attributes" and "relationships". Entities define the main objects representing the data content. Currently, these are: Research Area, Organisation, People, Programme, Project, Deliverable, Open Programme, Main Broker, and Added Value. However, the information model is flexible and allows new entities to be created and added to the system if required.

Entities are distinguished by a unique identifier (entity ID) and a set of attributes. The attributes consist of a name and a value. The name of the attribute is unique within the entity it belongs to. Entities are connected by relationships, thus allowing any search in the directory the ability to move from one entity to the other.

The Broker Information System (BIS) provides three main services to users: local added value information, interactive communications and user profile. Entries in the BIS can be linked to entities in the EUDKS adding an extra set of integrated services to the ADVISER system.

Finally, the ADVISER system is designed to be "Person Centred" which means that the information inside the EUDKS leads the users of the ADVISER system to a person entity that is richly linked to other entities.

ADVISER can be viewed as multi-layered system architecture (Figure 1).

1. Presentation layer: A WWW user interface. It provides access to main application services.
1. Application layer: User services such as Search/Navigate and Early Alert.
1. Information management layer: Abstract layer to the mediated data comprising Event Management and Intelligent Query interfaces.
1. Mediation service: This service mediates the raw information to support the application services. The key to this layer is a well-structured Information Model and support for subject classification. The current implementation of this layer uses X.500/LDAP technology.
1. Data wrappers: This layer contains the "device driver" to provide a logical interface to directory services.
1. Data sources: This is the ADVISER data space that covers a wide range of data resources.

The second part of the early alert system indicates to the user that some new items been added to the database which are of interest. The user will be notified about these items (if any) on entering the system.

This provides users with information on significant "events" within the information space. A clear definition of the meaning of an event is needed. An event is defined as "a significant change between the new and past data that occurs in the data domain or in the information". Comparison algorithms have been developed to differentiate between new and past information. The events are generated from the data event management and compared with the existing data available in the system and user profiles are matched with EUDKS information structure to target the relevant information to interested users. Figure (2) illustrates the different components of the event management system within the ADVISER system architecture.

Figure 2. ADVISER Event System Architecture

This section describes an important part of the event management module of the ADVISER system. It consists of three main parts: data sources, data wrappers and data updating tools.

The ADVISER data space comprises a heterogeneous set of data sources whose formats require different approaches to their acquisition. At present, there are three different types of formats available:

1. Data collected though extraction of static unformatted web pages
1. Data collected through extraction of formatted/semi-formatted web pages with/out meta data
1. Relational databases (SQL)

Data is collected on-line or off-line depending on the information provider. Each data source is represented in a specific format and acquired differently. Data sources are created and maintained either by the system, or by the data provider. This is time dependent and needs regular updates. Collection of data depends on the data format. However, data is mainly collected by extracting data from different web sites. Extraction of data is not a straightforward operation as it unstructured and without any specific standarisation[5]. Furthermore, data may be incomplete in terms of consistency, not updated, or does not follow a general pattern. To achieve a unified view of data content, data should be managed within an architecture that can be evolved into European frameworks.

"Data wrappers" refer to the method required to retrieve data from data sources that may be controlled by a number of independent authorities rather than one central authority, and mapping these data from the logical standard data interface to the databases. Each independent authority is responsible for the information stored in its area of the database. Examples of external data may be databases information from European resources WWW pages. There are three types of data wrappers that can be integrated in the directory. These are:

1. Data Extraction from the WWW and associated documents.
1. Database interfaces to on-line or off-line ODBC links.
1. Direct entry to the directory through Directory Service Editor.

Data updating tools are needed to transform data provided by data wrappers into events to be used by the information event management part of the system. Data wrappers provide a standarised way for the acquisition and monitoring of EUDKS information space. Data updating tools have two major capabilities[6]:

1. To compare the "new" event(s) with the similar data inside the databases and to perform a decision whether the event has significantly changed. The procedure is to search for a data object inside the ADVISER databases similar to the one taken from outside (i.e. the one that performs the new event). If past data is not found, then the new data is entered into the database and date stamped. If the past data exists, then it will be compared with "new" data and if there are significant changes then new data will be substituted with the old data and date stamped. In some cases, the significance of a change can be determined automatically - for instance, a new entry in a table that is "well meta-tagged" - in other cases a human decision is required.
2. To generate a information events for new data and classify them according to some criteria such as to which application the information belongs, what are the involved objects, what kind of data the information packets contains, time stamping, etc.

Once a new event is sent from the data event part, the databases updates its content and the event is sent to the event filtering. The event filtering determine both the event classification criteria and the user event generation process.

Recall user interests, event monitoring receives user interests and puts them on separate files, checks previous ones, provides agents with an idea of what sort of information users are interested in, etc. The code behind the above two modules is a set of "rules" that group "conditions" and "actions" together.

To illustrate the process of the information event management more clearly, suppose a project named "ABC" exists in the database. The user has asked to be notified about any new information in a project within a "multimedia" subject area. Suppose that the "ABC" project provided a new information within that subject and that a new information about this project emerged in the event filtering. Then,

user interest : <project, multimedia, email notification>

Directory event : project ABC <multimedia>

event filtering : <Directory event .AND. user interest>

User event : project ABC <new information data>

Conditions : Project object exists in the subject area "Multimedia"

Event monitoring works together with the event filtering in determining the generation of user events. These events are normally notification messages. These can be of various types, for example, an email, a pop-up menu on the desk top, a screen saver, or a notification when users logon to the system. The last and the email notifications are currently provided by the ADVISER system. Notification messages can be classified according to the user and system profiles. Some events are general and could be pushed to all users, some data will be sensitive and sent to specific users only. All other data will be sent according to user profiles.

The authors would like to acknowledge the contribution from the Telematics for Research Sector of the Telematics Application Programme of the European Commission, DG XIII. We would like also to thank Dr Fabio Gabrieli and Prof. Chris Leigh, for their valuable comments. Other members’ work of the ADVISER consortium is greatly acknowledged.