Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
Using Context for Supporting Users Efficiently Patrick Brézillon LIP6, Case 169, University Paris 6
[email protected]
Abstract A good software is a software that is invisible for the user. This is possible by making context explicit in the software. The increasingly interest for the notion of context appears through the number of approaches based on it. Initially, context was mainly considered in Engineering and Cognitive Science. Now even in Engineering, one sees two sub-approaches considering context at the level of the knowledge or the data, namely context-based and context-aware systems. For contextbased systems, most of the non formal approaches focus, in one way or another, on context in relationships with the user, aiming at a good computer system that is invisible for the user. Context-aware systems are concerned indirectly with users through a modeling of their dynamic environment. In this paper, we present, first, different viewpoints on context related to humanmachine interaction. We then consider why we need to focus on users through two aspects, on the one hand, on planning and plan execution, and, on the other hand, procedures and practice. The lesson learned is that an improvement of user’s support needs a consideration of context.
1 Introduction Now, there is a well established community that is 1 interested by the notion of context, with a web site , a mailing list and a series of biannual conferences. This is an international and interdisciplinary community. An application developed in this community on context is 2 the SART project [7]. Its objective is the design and the development of a Context-based Intelligent Assistant System (CIAS) to support an operator who is responsible of a subway line, especially when an incident occurs. (This application concerns the subways in Paris, France, and in Rio de Janeiro, Brazil). A first result of the SART application is a formalism for the context-based representation of knowledge and reasoning called contextual graphs. A second result is the integration in 1 2
See at: http://context.umcs.maine.edu/ See at http://www.lip6.fr/SART/
a same structure of an official procedure for solving an incident, and all the practices (contextualized variants of procedures) established by operators that take into account the context in which occurs an incident. A third result is the natural functionality of learning, incremental knowledge acquisition and explanation generation offered by the formalism because they are intrinsic parts of the task at hand. Indeed, the approach in SART is essentially user centered and takes explicitly into account the dynamical dimension of context. However, the environment (e.g. control panel in SART) is not really taken into account. In parallel to this community, mainly interested by the understanding of the user’s activity and theoretical aspects of context, another community emerges since few years. This community is more oriented towards the practical use of context through data (location and time). One goal of this community is to help person mobility and the different ways to support it. Such applications are called context-aware applications (CAS, and, to some extend, smart devices, pervasive computing, etc.) and are developed in domains, say, as different as tourism and e-maintenance. In the tourism example, the idea is to provide tourists with real-time information, context being here mainly tourist’s location and request time. Means for interaction between tourists and the system can be mobile phone, PDA, fixed, information dispenser or FM radio. Weaknesses of these applications are threefold: (1) context is mainly limited to data as location and time: information on the tourists (e.g. from a model of the tourist) is generally ignored, (2) there is no consideration for the dynamic dimension of the context, and (3) works in this area are only equipmentbased. It is clear that none of the two communities is totally right. It is necessary to find a generalization based on the advantages of both communities, but avoiding their respective weaknesses. This supposes the ability to manage: Information that evolves with time (e.g. time schedule for visiting a castle); Information coming from heterogeneous sources (e.g. weather, hotels, press, etc.); Knowledge about users (including their preferences and profiles as perceived by the system through users' actions); Software with a centralized part and mobile
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
1
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
parts attached to a user or group of users; and Hardware and interaction among pieces of hardware. The position defended in this paper is close to the concept of embodiment of Dourish [14]. Making context explicit permits to face such challenges (use context of the information, user's context, context of the user's request, etc.) Context-aware applications will then become real autonomous extensions with a central source of information that will be updated in real time. Moreover, autonomous extensions could exchange between them information mirroring their own experience with users in order to address the specific problem of a given user. Hereafter the paper is organized in the following way. Section 2 presents different points of view on context. Section 3 discusses the need to focus on users through two points, namely planning and plan execution and the distinction between procedures and practices. Section 4 presents the ways in which context can be made explicit. Section 5 gives an illustration of a context-based representation of the knowledge and the reasoning called contextual graphs. Section 6 presents some challenges that seem possible to tackle from the experience from context modeling and from the realm of context-aware systems.
2. Viewpoints on Context There are different points of view on context: context as conceptual drift (a context engine), context as a layer above application, context as an implicit input to an application, context as a medium for the representation of knowledge and reasoning, context as what surrounds the focus of attention, etc. Indeed, there are several contexts to deal with, but only one is of interest: the context of the interaction because it is in this context that other contexts evolve. For example, by providing the context to the caller there is an implicit negotiation, where the caller balances his own need to establish the communication against how receptive the other person is. In HCI, a definition is that a context feature is any information that can be used to characterize and interpret the situation in which a user interacts with an application at a certain time. In context-aware applications area, Dey and Abowd [13] define context as any information that characterizes a situation related to the interaction between humans, applications and the surrounding environment. In Artificial Intelligence, Brézillon [4] defines context as what does not intervene explicitly in a problem solving but constrains it. All these definitions are very close and mainly differ by their context of use. From an informational perspective, context aims to provide an information space that can be “adapted according to the user’s context (modulo group context)”,
and complemented by tools/processes that promote the socially situated construction and sharing of context. A fact is not meaningful in itself, but acquires meaning in the context of someone using it, in an account of what happened today. From a device perspective, context concerns how devices can be made to “blend naturally into the normal interactions and physical space of human work practice as they gather, integrate and display information that assists work”. From an infrastructural view, context provides a computing device with information about its environment as provided by other system components. As a consequence, different ‘types’ or ‘dimensions’ of context emerge, e.g., physical context (ambience), computational context, informational context modified by notions of individual and group (information ecology), situated context. In the example of tourism, the objective is to provide tourists with realtime information. Information concerns the environment in which tourists are (from inside a building to a whole geographical region), the moment at which they send their request, external factors (e.g. weather and events in progress), and above all tourists' interest. Such information is called contextual information because it does not intervene directly in the tourist’s request but constrains the answer that will be made. Systems using such contextual information are called Context-Aware Systems (CASs) because their efficiency rely heavily on contextual information (e.g. tourist's location and weather) they take into account explicitly. For example, a context-aware system can propose the visit of a castle at 10 mn by foot from where is the user. The user indicates to the CAS that he is tired or the CAS checks the weather and identifies that is just beginning to rain. The CAS then proposes an alternative by bus, with where and how to have a ticket, where is the station, at which stop to leave the bus, etc. This points out the dynamic dimension of the context and a need for an active wake state of the CAS during the accomplishment of the task by the user. A context-aware intelligent environment is a space in which a ubiquitous computing system has contextual awareness of its users and the ability to maintain consistent, coherent interaction across a number of heterogeneous smart devices. Specifically, the CAS community recognize four primary methods of utilizing context information: resolving references, tailoring lists of options, triggering automatic behaviors, and tagging information for later retrieval. Moreover, contextawareness implies two attributes of a system: the ability to obtain context, and the ability to utilize contextual information. However, context-aware systems are not directly concerned by users. For example, a system can know what the location of the user is but cannot know what the user is doing at this location.
3 Need to focus on users
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
2
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
Users’ needs are often intangible, affected by habit, self-image, and even issues of motivation (i.e. a person might be more efficient in the morning than the evening). The design of a system thus must focus on reducing communication barriers by analyzing what can be known about a user and how to support that information with task, user, and system models. As a rule, the user must play an active role in the definition of the context about which the system must be aware of. In this section, we discuss two users' activities, namely the need to intertwined plan and execution of the plan and the difference between the official procedure and the number of practices built from each procedure. We finally sum up the lessons learned.
3.1 Planning and plan execution Nowadays, we observe the multiplication and the specialization of procedures in a number of domains. This is a general trend overtaking the railway control process. In aeronautics, operators always adapt the actual procedures to the current situation. De Brito and Boy [10] explain that the aircraft operators prefer to plan again their actions instead of following non-adapted procedures, even if the new plan is inspired of these procedures. Britanik and Marefat [8] also propose a plan merging methodology that merges partially-ordered plans based on the notion of plan fragments. Their notion of plan fragments encapsulates actions with their context. Hayes-Roth and Hayes-Roth [17] proposed a socalled opportunistic approach to planning. This nonhierarchical planning assumes that a plan is executed with the help of some mental blackboard where pieces of information, relevant cues and possible sub-goals are stored. They claimed and showed that planning happens asynchronously and is determined by the momentary aspects of the problem. No fixed order of operations exists; the plan execution and the steps to be taken, grow out of the problem stage at hand. Xiao et al. [32] study anesthesiologists' work for which each patient can represent a drastically different “plant” and thus there are relatively few well-defined procedures stipulated either by inside professional communities or by outside regulatory agencies. They think that the planning process is necessarily fragmentary and non-exhaustive. When applying a plan to a concrete problem, the situated actions performed in the activity often mirror the plan, but are adjusted to the concrete details and conditions of the context. The same conclusion is observed in other domains too by Hoc [18], Debenham [11] and Bainbridge [1]. The main reason is the difficulty of making explicit the relationships between a system and its changing environment. Bardram [2] speaks of situated planning and others of opportunistic planning, reactive planning,
etc. In an application in air control, Degani and Wiener [12] shown that the descent phase is highly context dependent due to the uncertainty of the environment (e.g. air traffic control, weather), making it quite resistant to procedurization. Hollnagel [19] proposes a contextual control model that distinguishes between a competence model (actions, heuristics, procedures, plans) and a control model (mechanisms for constructing a sequence of actions in context), which are both heavily influenced by context (skills, knowledge, environmental cues, etc.). Note that there are domains--as industrial projects-- in which one does not know the structure of the product in advance but the structure is progressively specified by the design activities. This means that a large portion of the planning activities can only be executed after some design activities have been carried out. However, before we can execute any design activities, they have to be planned. There is thus a dynamic interplay between the design process that refines the goals of the project and the planning process that keeps the activities consistent with the goals. (In other domains, as space exploration, no procedures are available when a space vessel is sent for the first time.) A solution to the impossibility of a comprehensive a priori planning is the acquisition of skills for anticipating or look-ahead as proposed by Pomerol [26]. For Hoc [18], the anticipative mode is the usual functioning mode of human beings: the human operator always checks, more or less explicitly, hypotheses instead of being in a situation of discovery or surprise. An anticipatory system would be a system that uses knowledge about future states to decide what action to make at the moment. Ekdahl et al. [15] suggest that an anticipatory system has a model of itself and of the relevant part of its environment and will use this model to anticipate the future). The system then uses the predictions to determine its behavior, i.e., it lets the future state to affect its present states. An intelligent system should be able to predict what will happen probably and pre-adapt itself for the occurrence of a crucial or time-critical event. This implies that an intelligent system must be equipped with a simulation component.
3.2 Procedures and practices Degani and Wiener [12] distinguish procedures, practices and techniques. Procedures are specified beforehand by developers to save time during critical situations. Practices encompass what the users do with procedures. Ideally, procedures and practices should be the same, but the users either conform to procedure or deviate from it, even if the procedure is mandatory. Techniques are defined as personal methods for carrying out specific tasks without violating procedural constraints. Techniques are developed by users over
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
3
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
years of experience. Knowledge acquisition focuses on procedures and, eventually, practices, but rarely on techniques. Moreover, Forslund [16] points out that in most of real-world applications, a decision maker faces ill-defined situations where the form of the argumentation rather than the explicit decision proposal is crucial. This implies that it would be better to store advantages and disadvantages rather than the complete decisions. Medicine is also a domain where the distinction between procedure and practice in the one hand, and the notion of context, in the other hand, is very important. A practice can be considered as a kind of causal explanation for an incident solving in the spirit of the graphs in ABEL system described by Patil et al. [24] called patient-specific model on the basis of the situation-specific models proposed by Clancey [9] in diagnosis. In the ABEL system, a causal explanation is represented as a five-layered graph containing the particular findings, disorders, and their causal or subtype relations that are believed to be present in the particular patient being diagnosed. Such specific models are causal arguments having the structure of a proof (in our case, the effective solving of the incident). Bouaud et al. [3] describe also in medicine this type of operationalization of the knowledge from procedures to practices when a physician can make different therapeutical choices for a diagnosis according to the instantiation of the clinical context built from his perception of his patients understanding. Strauss et al. [30] give the example of the unravelling plan for an osteoarthritis patient that might state that an X-ray image of the hip is necessary. But when applying the plan to Mr. Jones, who doesn’t have any problems with his hips, this part of the plan may be skipped – and other examinations, like a blood test, might be added to Mr. Jones’ unraveling plan. Thus, a protocol in medicine is a standard operating procedure that must be adapted for each context of use. In high technical and heavily dynamical process regulation domains, operators who are responsible for the process control have to rapidly react. If an incident occurs, they have only few minutes to forge a representation of the issue, gather information on the situation, analyze the incident and undertake the correcting actions. To ease their job, many companies have established fixed procedures. Initially, general procedures have been designed to provide operators with a secure reference for incident solving. However, these general procedures forget the contextual dimension of the case at hand. Nowadays, companies are diversifying these procedures by introducing increasingly contextual considerations. This operation multiplies and specializes the available procedures for each type of incident. In the SART application [7], procedures are based on practices, but eliminate from them most of contextual information and particularities of each incident. Trying to promote sufficiently general procedures results often
in sub-optimal solutions for incident solving. In this sense, procedures are useful guidelines for operators, but they have to be adapted for each new incident situation. Conversely, each operator develops his own practices to solve an incident, and one observes almost as many practices as operators for a given procedure because each operator tailors the procedure in order to take into account the current context, which is particular and specific. There are two main reasons. Firstly, the selected procedure is not always perfectly adapted to the situation at hand and can lead to improper actions or suboptimal incident resolution strategies. Secondly, if the operator relies on a procedure, he can miss some important facts and notice them too late to adequately solve the incident. Operators prefer generally to plan again their action continuously according to the situation. Procedures are then used as frames to construct a genuine strategy tailored to the specificity of a given situation.
3.3 Lessons learned with the focus on users The modeling of operators' reasoning is a difficult task because operators use a number of contextual elements for making a decision for solving complex incidents with degrees of freedom. As such, practices are what we call hereafter proceduralized contexts. These knowledge pieces, which are not necessarily expressed, result in more or less proceduralized actions that are compiled with the relevant contextual-knowledge pieces. Very often many pieces of proceduralized context are structured together in comprehensive knowledge about actions. As a consequence: 1. Plans are intertwined with actions, 2. Users do not know what their real question is or how to express it clearly. 3. Optimality of a solution is relative to a context (context-dependent solutions), 4. There are an infinite number of pieces of contextual knowledge, and 5. It could be useful to keep a trace of all the alternatives of the retained solution if a change is needed.
4. Making context explicit Context must be made explicit to be used by a computer system. Few real-world applications use explicitly the context: Turner (http://cdps.umcs. maine.edu/orca.html) developed such an approach in the project ORCA for underwater vehicles and Chen and Kotz (http://citeseer .nj.nec.com/390713.html ) give a survey on context-aware mobiles. However, both of them consider context uniquely through location and time. Brézillon et al. [7] propose a context-based
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
4
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
representation of knowledge and reasoning called contextual graphs in a system to support incident management on a subway line (http://www.lip6.fr/SART). In this application, context is strongly related to human's reasoning and different types of knowledge.
4.1. Data, information and knowledge Knowledge is generally defined by a progressive construction going back to data, which are the symbols perceived by a subject whether these data are already structured either by the perception device or by the machine that conveys them. From data emerges information which is data with a strong semantic content. Thus, information is structured data with a semantic content expressible by natural language. People transform data into information and this transformation depends on the context but relies on knowledge. Context is one of the elements of the transformation of data into information on the basis of context and experience [21]. The next transformation is the passage from information to knowledge. This appropriation process relies on prior knowledge and is made consistent with the values and beliefs of a subject. Thus, the role of knowledge is to: (1) transform data into information, (2) derive new information from existing ones, and (3) acquire new knowledge pieces. As such, knowledge is both a means and a result of this complex process: Knowledge must be managed as an object and a process. Beyond knowledge generation, two types of knowledge are more particularly considered, namely explicit and tacit knowledge. Explicit knowledge is easily shared whereas implicit knowledge is highly personal.
knowledge. Knowledge externalization refers to the conversion of tacit knowledge into explicit knowledge. Knowledge combination refers to the creation of new knowledge through the exchange and combination of explicit knowledge held by individuals in the organization. Knowledge internalization takes place when explicit knowledge becomes tacit, in a way similar to learning. The process of externalization is especially interesting as regards context because it corresponds to the process of proceduralization that we introduce in [28]. Thus, a system must deal with an ocean of data (e.g. user's location), information (e.g. the rain would fall down soon) and knowledge (the user has no umbrella with him) through a net of heterogeneous databases. Facing a dynamic environment, a system must give a clear view of data, information and knowledge to the user. These points are the central questions for developing context-based intelligent assistant systems as underlined in [7].
4.2. Context identification McCarthy [20] defined a context as the generalization of a collection of assumptions. Contexts are thus formalized as first class objects (formal objects). The basic relation is ist(c,p) that asserts that the proposition p is true in the context c, where c is meant to capture all that is not explicit in p that is required to make p a meaningful statement representing what it is intended to state. Formulas ist(c,p) are always asserted within a context, i.e., something like ist(c', ist(c,p)): c': ist (c, p). The consequences are that a context is always relative to another context, contexts have an infinite dimension, contexts can not be described completely, and when several contexts occur in a discussion, there is a common context above all of them into which all terms and predicates can be lifted. Proceduralized contexts
Internalization
Combination
Socialization
Focus (e.g., a triggering event)
Explicit knowledge
Tacit knowledge
CONTEXT External knowledge
Contextual knowledge 1
Externalization
Figure 1: Movements between tacit and explicit knowledge Nonaka and Takeushi [22] describe four types of exchange between tacit and explicit knowledge (see Figure 1): socialization, externalization, combination and internalization. Knowledge socialization refers to the creation of new tacit knowledge from shared tacit
Contextual knowledge 2
Figure 2: The three types of context
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
5
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
At a given step of a decision process or of a task performing, Pomerol and Brézillon [27] distinguish between the part of the context which is relevant at this step, and the part which is not relevant (see Figure 2). The latter part is called external knowledge. The former part is called contextual knowledge, and obviously depends on the agent and on the decision at hand. At the step of the decision making, a part of the contextual knowledge is proceduralized. We call it the proceduralized context. It is a part of the contextual knowledge which is invoked, structured and situated according to a given focus. Thus, context is not distinguished from other objects of reasoning, learning, etc., objects being in the context or not according to circumstances. The contextual knowledge is a backstage knowledge whereas proceduralized context is immediately useful for the task at hand. In our representation of context, the contextual knowledge is largely tacit, mainly because it is the context that everybody knows without expressing it. An important issue is the passage from contextual knowledge to proceduralized context. There is a building of the proceduralized context at each step of the problem solving. However, from one step of the problem solving to the following one, the contextual knowledge change (e.g. the result obtained at one step becomes contextual knowledge at the next one). Thus, a new proceduralized context is built, the previous one being obsolete or goes back to the contextual knowledge as a whole (a chunk of knowledge a la Schank). This dynamic dimension of the context is generally not considered, at least explicitly.
In this section we present some results obtained in the framework of the SART application [7], a context-based intelligent assistant system. However, the interest of these results is not limited to SART.
4.3. Lessons learned with context and knowledge
5.2. A reasoning representation based on contextual graphs
There are strong links between context and knowledge and we retain that: - Context is knowledge, and knowledge is context. - Context is defined with respect to a focus of attention (e.g. the context of knowledge use). - At a given time, there are external knowledge and contextual knowledge, and the part of the contextual knowledge that is not directly into the focus of attention is called the proceduralized context. - Pieces of contextual knowledge are structured around the focus of attention (e.g. in layers as in the onion metaphor in [5]). - Contextual knowledge has a granularity that depends on the distance to the focus of attention. - Context structure evolves dynamically with the focus of attention. - Context is relative to an observer.
5. Context-based representation of knowledge and reasoning
5.1. A knowledge representation based on the onion metaphor The context-based modeling of knowledge along the onion metaphor, which is proposed by Brézillon et al. [5], reveals several interesting results: 1. A step in a problem solving takes a meaning in a given context. Contextual knowledge does not intervene directly at this step but constrains it. 2. Pieces of contextual knowledge may be partially ordered in layers around the knowledge used for the incident solving at a given step (the proceduralized context). 3. Contextual knowledge takes itself a meaning in a context. This is a concrete example of McCarthy's claims [20] about the definition of a context in an outer context and the infinite dimension of context. 4. Pieces of contextual knowledge relate incidents together. With an association between a number of contextual-knowledge pieces, it appears that there is relationships between incidents. Establishing such an incident net accounts for the occurrence in reallife conditions of combinations of incidents that seem apparently not related.
Brézillon et al. [6] and Pasquier et al. [23] show the evolution of the reasoning representation from a decision tree in SART. A branch expresses a practice, depending on a context (the sequence of contextual nodes leading to this branch) to achieve it. Thus the progression along a path in the tree corresponds to a context that becomes more and more precise. The transformation of the decision trees into contextual graphs followed the following steps: 1. Macro-actions were introduced to replace recurrent sub-sequences of actions, thanks to the fact that most of contextual nodes are considered before actions; 2 . Branches of the tree are merged as soon as the sequence leading to the end are identical (e.g. reuse of well-known procedures). Merging two branches means that contextual differences between them has disappeared. Cognitively speaking, a scarcity principle leads the operators to try to reuse wellknown procedures as soon as possible.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
6
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
3. Parallel groupings represent actions or macro-actions that are only partially ordered (i.e. can be executed in one order or another one). 4. Identification of the sub-graphs that appear in different contextual graphs. Thus, a contextual graph is a hierarchy of sub-graphs at different levels of granularity. The change of the structure introduces a dynamics comparable to the dynamics of the change between the proceduralized context and contextual knowledge. Indeed, when two branches are merged, it means that the undertaken actions led to a common situation from different contexts. The contextual elements attached to the different branches are proceduralized at the diverging node. They stay in this state for the different action sequences, because they intervene in the branch decisions. Finally, they are deproceduralized when the branches are merged. By this way we explicitly express the life duration of the contextual elements. Contextual graphs appear to us as a computer expression of schemes of action considered in Cognitive Ergonomics (e.g. Vergnaud [31] discusses this point), some for solving problems, others for completing subgoals. Each scheme organizes the activity around an object and can call other schemes to complete specific sub-goals. Each scheme has a name, a goal and a contextual graph representing the decision-making that permits to achieve its goal depending on the context. Both contextual graphs and schemes allow: the representation of operators’ activity and all the variants (procedures and practices), the integration of automatic learning and adaptation in a system, a clear representation of the context in operators’ reasoning, and the organization of the operators’ activity itself. Thus, Contextual Graphs allows the representation of all the richness of the operators’ activity. As a consequence, a context-based intelligent assistant system is more capable than an ordinary system to interact with a user and thus provide an efficient support to operators.
6. CHALLENGES 6.1. Introduction In 1969, Frederik Pohl [25] wrote a science fiction novel called "The Era of the Satisfactor". In the story, each person possess a mobile device--called Satisfactor-by which the person can order and buy a product, pay something in a store, have news, communicate with another person, command the TV channel, control what the children are doing, and even can receive (or send on someone) some chemical drugs (e.g. a relaxing drug). As a corollary, if a person loses his satisfactor, this person is anymore a person recognized by the society, cannot buy food, etc. This is a novel of science fiction. However, some research is in the realm of this story: identification
of a person entering a room, location of a person from his cellular phone, paiement through internet, etc. The focus is now on mobile devices, and the hardware aspect of such devices would be soon under control. More than for devices, the acute identification of the context is crucial for mobile device. In the later case, most of the parameters stay constant, when in the latter case parameters can be different, for a same mobile device, from one place to another one, and at the same place from one instant to another one. For a given mobile device in a given environment, some external events (e.g. the rain) can modify the current context and makes non optimal the current plan, and a need for replanning the actions. Now, it is possible to specify a fixed context for a mobile device, and, eventually, to take into account some changes in the environment. This concerns data and partially information from the environment. Accounting for knowledge coming from the environment or the user is the next step along which we present some challenges. Some challenges to explore are: - To provide users with a first approximation of environmental trends and events; - To point out useful information implicit in large volumes of data to alert users of sudden changes; - To develop multiple scenarios and perspectives on a given line of actions; - To attract users' attention upon existing and emerging strategic issues; - To support users in sharing and communicating their views and perspectives; - To guide users' attention to specific data and the interpretation of the accessed data in relation to particular issues. Hereafter, we discuss in more details a challenge in which context plays a leading role.
6.2. Dealing with individual contexts and interaction context among users We have shown in previous sections that making context explicit allows data, information and knowledge to be structured in order to facilitate the user's navigation (e.g., at each time, present the minimum number of relevant items). However, a computer system can do more by being a real intelligent assistant system: the system can "learn by interacting". Thus, the system becomes increasingly familiar with the user, and his way to accomplish his activity. From an observation of operator's actions to accomplish a task (e.g. using shortcuts or not), the system can accompany the user (attentive wake state) in the accomplishment of his task by using anticipation means (e.g. forecast). For example, when a tourist is in a street, the system can warn and propose alternatives, by
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
7
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
recall of memo with respect to the location (buy bread before to go home), in a foreign country by automatic changes for currency or translation. Moreover, having support the operator in the accomplishment of a task may help the system to support the user in the accomplishment of other tasks. Here a system will have to make compatible the context of the task (as context-aware applications) and the context of the user (as in artificial intelligence). A goal could be to present an ordered list of alternatives with explanations to the user. This is not science fiction. Schmidt et al. [29] present a study in which a system assists a user wishing to give a phone call to a friend. The system presents the list of his friends with their availability before the call itself (e.g. Tom does not want to be disturb, Mary is already in communication and John has put his voice recorder). Then, the user makes himself the compromise between his wish to contact the person and the availability of the person. Beyond the support that the system can bring to a user by managing his personal context in relationship to the working context, a system can also reuse its experience with a user when it interacts with other users taken individually or in a collaborative work. The former case is similar to the case considered by Maes' team for which an agent interacting with a user can require a support from other agents with other users to help it to solve a particular problem. The latter case is more general and concerns different aspects of cooperation as negotiation. However, it seems to us that an important point by making context explicit is the adjustment of all users' contexts to make compatible their interpretations and understandings on a given problem, even with radically different viewpoints as specialists in the building of a spacecraft or a family of tourists in a city with different objectives.
7. Conclusion The design and development of a context-aware system supposes an access to large databases updated in real-time (e.g. social events, weather), an efficient context-based representation of a user model, data, information and knowledge, a communication through mobile phone, PDA, fixed information dispensers or FM radio; and an efficient association of software and hardware constraints. Clearly, this can only be the result of a cooperative work with abilities in different technical domains. Context representation supposes a dynamic organization of the knowledge in the memory. This is necessary (1) for giving learning capability to a system, and (2) for making memory organization dependent of external conditions, dependent of its context- of use. Each approach (context-based and context-aware) considers the context from a different viewpoint when we compare them with the distinction
data/information/knowledge: The Context-Aware Systems (CASs) deal essentially with data, when Context-based Intelligent Assistant Systems (CIASs as in the SART application) focus mainly with knowledge. Figure 3 gives a picture of this position. Data Information Knowledge C.A.S.
C.I.A.S.
Figure 3: From CAS to CIAS through data-informationknowledge The innovative aspect of our proposal concerns the use of context at the different levels: (1) the modeling of the context (including a maximum of contextual elements), (2) representation and storage of data, information and knowledge, (3) retrieval of the relevant data, information and knowledge, and (4) presentation of the data, information and knowledge. Globally the proposed approach is a user centered approach accounting for preferences, language, financial possibility, the number of persons in the group, his/her interest for the History or stories, etc. In that sense, the joint consideration of CAS and CIAS will aim at developing social sensitive applications.
8. References [1] Bainbridge, L., “The change in concepts needed to account for human behavior in complex dynamic tasks”, IEEE transactions on Systems, Man and Cybernetics, 1997, 27, 351359. [2] Bardram, J.E., « Plans as situated action: An Activity Theory approach to workflow systems ». Proceedings of ECSCW’97 Conference, Lancaster UK, September, 1997. http://www.daimi.aau.dk/~bardram/ ECSCW97.html [3] Bouaud, J., Séroussi, B. and Antoine, E.-Ch., « OncoDoc: modélisation et “opérationalisation” d'une expertise thérapeutique au niveau des connaissances ». Actes de Ingénierie des Connaissances (IC'99), Palaiseau, 1999, pp. 6169. [4] Brézillon, P., “Context in problem solving: A survey”, The Knowledge Engineering Review, 1999, 14(1), 1-34. [5] Brézillon, P., Gentile, C., Saker, I., and Secron, M., « SART: A system for supporting operators with contextual knowledge ». Proceedings of the First International and Interdisciplinary Conference on Modeling and Using Context (CONTEXT-97). Federal University of Rio de Janeiro Ed., 1997, pp. 209-222. [6] Brézillon, P., Pasquier, L. and Pomerol, J. Ch., “Reasoning with contextual graphs”. European Journal of Operational Research, 2001, 136(2): 290-298.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
8
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
[7] Brézillon, P., Cavalcanti, M., Naveiro, R. and Pomerol, J.Ch., « SART: An intelligent assistant for subway control ». Pesquisa Operacional, Brazilian Operations Research Society, 2000, 20(2): 247-268. [8] Britanik, J.M. and Marefat, M.M., « Hierarchically merging plans in decomposable domains ». IEEE Trans. on Systems, Man, and Cybernetics, 1999, 29(1): 27-39. [9] Clancey, W.J., « The knowledge level reinterpreted: modeling socio-technical systems », Proceedings of the AAAI'92 Worshop on Cognitive Aspects of Knowledge Acquisition, Stanford, CA, March, 1992, pp. 47-56. [10] de Brito, G. and Boy, G., « Situation awareness and procedure following ». CSAPC'99, Villeneuve d'Ascq, Presses Universitaires de Valenciennes, 1999, pp 9-14. [11] Debenham, J., « Strategic workflow management: An experiment ». Proceedings of the International Workshop “Distributed Artificial Intelligence and Multi-Agent Systems”, DAIMAS'97, 1997. [12] Degani, A. and Wiener, E.L., « Procedures in complex systems: The airline cockpit ». IEEE Trans. on Systems, Man, and Cybernetics-Part A: Systems and Humans, 1997, 27(3): 302-312. [13] Dey, A.K. and Abowd, G.D., “A conceptual framework and a toolkit for supporting the rapid prototyping of contextaware applications”. 1998, http://www.cc.gatech. edu/fce/contextexttoolkit [14] Dourish, P., « Seeking a Foundation for context-aware computing ». Human-Computer Interaction, 2001, 16 (2-4). http://hci-journal.com/editorial/vol-16.html [15] Ekdahl, B., Astor, E. and Davidsson, P., “Toward anticipatory agents”. In: Intelligent Agents, M. Wooldridge & Jennings N. (Eds.), Lecture Notes in AI, 890, Springer Verlag, Berlin, 1995, pp. 191-202. [16] Forslund, G., « Toward cooperative advice-giving systems. The expert systems experience », Ph. D. Thesis 518, Linkoping University, Sweden, 1995. [17] Hayes-Roth, B. and Hayes-Roth, F., « A cognitive model of planning », Cognitive Science, 1979, 3, 275-310. [18] Hoc, J.-M., « Supervision et Contrôle de Processu s ». La cognition en Situation Dynamique. Grenoble: P.U.G., 1996. [19] Hollnagel, E. (Ed.), « Human Reliability Analysis, Context and Control. » London: Academic Press, 1993.
[20] McCarthy, J., « Notes on formalizing context ». Proceedings of the 13th IJCAI, Vol.1, 1993, pp 555-560. [21] Huang, K.-T., Yang, W.L. and Wang, R.Y., « Quality information and knowledge ». Upper Saddle River, NJ: Prentice Hall, 1999. [22] Nonaka, I. and Takeuchi, H., “The Knowledge-Creating Company.” Oxford University Press, New York, 1995. [23] Pasquier, L., Brézillon, P. and Pomerol, J.-Ch., “Learning and explanation in a context-sensitive adaptive support system”. In: C. Faucher, L. Jain & N. Ichalkaranje (Eds.) Innovative Knowledge Engineering. Springer-Verlag, 2002 (to appear). [24] Patil, R.S., Szolovits, P. and Schwartz, W.B., “Causal understanding of patient illness in medical diagnosis”. Proceedings of the 7th International Joint Conference on Artificial Intelligence, 1981, pp. 893-899. [25] Pohl, F., “L'ère du Satisfacteur”. Paris: Librairie des Champs Elysées, Série Science Fiction, 1969. [26] Pomerol, J.-Ch., « Artificial Intelligence and Human Decision Making », European Journal of Operational Research, 1997, 99, 3-25. [27] Pomerol, J.-Ch. and Brézillon, P., “Dynamics between contextual knowledge and proceduralized context”. Modeling and Using Context (CONTEXT-99). In Lecture Notes in Artificial Intelligence, n°1688, Springer Verlag, 1999, pp. 284295. [28] Pomerol, J.-Ch., Brézillon, P. and Pasquier, L., “Operational knowledge representation for practical decision making”. Journal of Management Information Systems, 2002, 18(4): 101-116. [29] Schmidt, A., Takaluoma, A. and Mantyjarvi, “Contextaware telephony over wap”. Personal Technologies, 2000, 4(4): 225-229. [30] Strauss, A., Fagerhaugh, S., Suczek, B. and Wiener, C., « Social Organization of Medical Work ». Chicago and London: University of Chicago Press., 1985 [31] Vergnaud, G., “Concepts et schèmes dans la théorie opératoire de la représentation”, Les Représentation, Psychologie Française, 1985, 30 (3 et 4): 245 - 252. [32] Xiao, Y., Milgram, P. and Doyle, D.J., « Planning behavior and its functional role in interactions with complex systems ». IEEE Trans. on Systems, Man, and CyberneticsPart A: Systems and Humans, 1997, 27(3): 313-324.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
9
