ATTENTION
Ceci est l'archive du site web de démonstration du projet de recherche européen AtGentive dans le cadre du FP6-IST, datant de la période 2005-12-01 à 2007-11-30.
Les outils nécessitent des technologies obsolètes, tels les applets java. Les démonstrateurs en ligne peuvent donc pas fonctionner dans votre environnement.
Les publications de Damien Clauzel dans le cadre du projet AtGentive sont en ligne (BibTex, articles).
AtGentive means Attentive Agents for Collaborative Learners
The objective of the AtGentive project is to investigate the use of artificial agents for supporting the management of the attention of young or adult learners in the context of individual and collaborative learning environments.
Practically, this project consists in the design of artificial agents that are able to coach the learners in reaching higher level of performance in managing their attention in the learning process. These agents, which appear as embedded characters, are able to profile the state of the attention of the learners (short or long term) by observing their actions, to assess, to analyse and to reason on these states of attention, and to provide some proactive coaching (assessment, guidance, stimulation, etc.).
These attentive agents will be designed and delivered as part of two different learning infrastructure/contexts:
The result of this project will be validated with two pilot sites:
Within AtGentive systems, an independent module, the Reasoning Module, performs all reasoning about attention. The reasoning module is in charge of processing the events sent by the application, the user, or other environmental tracking devices, in order to produce interventions aimed at supporting users' attentional processes These interventions are passed to the application that may trigger an embodied agent.
The multi-agents approach chosen to develop the reasoning module allows us to easily extend it by adding new agents, to customize it by creating several types of agents (rule based, neural network based) and even to externalize some of its components.
We have three types of agents:
The current implementation also includes a set of communication agents that implement the communication protocol between the reasoning module and the external components. As planned, the following agents are implemented in the reasoning module:
Currently all agents use a rule-based engine for processing the information about the environment and the user activity. Three types of events have already been introduced in deliverables D1.3 and further specified in D2.2: user events, application events, and environment tracking events. In the current implementation, events are also generated internally by agents (internal events) in order to synchronise their activities. As planned, the following events are managed in the prototype:
In order to offer personalised support, the agents maintain a user model. This model has already been described in D2.2. As planned, the prototype implements the following user model's fields: Foci List, Intervention History, Intervention List, Time available, Preferred intervention modes, User-task model, Social network (a simple version), Events history, User acquisition time.
The task model contains the description of the tasks that might be performed by the user. The tasks described in the task model are user independent and application dependant. The prototype implements an improved version of the task model described in D2.2 in that it allows describing task hierarchies. Such hierarchies include both complete and partial orders over tasks, and both mandatory and optional tasks. Implementing task hierarchies, not only allow a better description of tasks, but enable the continuation agent to generate foci on tasks that logically follow tasks that the user has just completed or suspended. Further, task hierarchies enable the evaluation of breakpoints. Because the prototype implements a significantly improved task model as compared to the one described in D1.3 and D2.2, we include a section on task modelling in this document (see section 2.4).
The task model still includes all the fields identified in D2.2: id, applicationIdentifier, applicationType, taskCategory, keywords, maximumIdleTime, name, socialNetworkElements, requiredResources, parentId, isVisible, difficultyLevel, parent, subtasks, expectedDurationInSeconds, isOptional, subtasksInOrder.
The test center is an application that allows us to easily test our work, and demonstrate the inner workings of the reasoning module. The reasoning module Test Center's first responsibility is to let the user simulate a Task Structure of his/her choice and a sequence of user-created events. Alternatively, if the user is not familiar with the inner workings of the reasoning module, he/she can run Scenarios, which are predefined sequences of events with an associated task structure, along with some explanatory text. An example of a Scenario would be the user receiving a new e-mail while working on some other task. Based on information about the mail, the user characteristics, and his/her current activity, the reasoning module reaches a decision and the email is either forwarded to the user or kept until a later time when the user is available / idle. This is a very basic example but the Test Center allows for much more complex scenarios. Of course, these Scenarios are not set in stone and new Scenarios can easily be created via an intuitive interface. The decisions that are made by the reasoning module are displayed to the user in the form of Intervention Strings.
Go to the private area.