MUSETTE: a Framework for Knowledge Capture from Experience Pierre-Antoine Champin1, Julien Laflaquière1,2 , Alain Mille1, Yannick Prié1 1
LIRIS, FRE 2672 CNRS - University Lyon 1 Bât Nautibus - UFR Informatique Université Claude Bernard Lyon 1 F-69622 Villeurbanne Cedex,
[email protected] http://liris.cnrs.fr/surname.name
2
AMOWEBA, 89 boulevard Sébastopol,75002 Paris http://www.amoweba.com/
Abstract. In this article we present a new approach for modelling user’s experience in using a computer system, with the perspective of reusing this experience as knowledge in context for helping a user along his task. The MUSETTE (Modelling USEs and Tasks for Tracing Experience) approach relies on the capturing of a use trace conforming to a general use model, describing the objects and relations handled by the user of the computer system. This primitive trace can be seen as a task-neutral knowledge base, which can further be analysed with respect to explained task signatures, in order to locate emerging significant episodes, which can be re-used as useful contextual pieces of knowledge by software assistants. The advantages of this approach are demonstrated through four scenarios. We also present a Musette modelling of a real application and compare Musette to other approaches dealing with user’s tasks and uses.
1 Introduction It is a triteness to say that computers are widely used, for more and more various and numerous tasks, which mainly rely on “information management”: information organization, storage, communication, retrieval, sharing… Furthermore, the spectrum of computer-mediated tasks becomes wider, and tools for performing these tasks become more versatile and customisable. For example, we could consider that an environment composed of a/ the web as a resource provider (documents, data) and b/ a tool for viewing and editing HTML documents, is adapted to any task involving information gathering and publication. Since, on the other hand, those tasks have more and more (often inexperienced) users, there is a increasing need for assisting the latter in using tools or sets of tools. As a consequence, there is a need to design software agents as assistants, which would take advantage of knowledge describing the task at hand. Indeed it becomes
necessary to take into account user’s tasks in order to be able to interpret, in their context, the traces left by the use of the computer environment. Of course, in many situations of user assistance, there can be a wide variety of questions that can be formulated, depending on the context of use. Let us stress the fact that this notion of “context” has nothing to do with what is commonly addressed in the so-called “contextual help”: the latter is exclusively considering the computer environment context (e.g., selected item, current menu) while we are focusing on the user’s context, in particular the task he or she is willing to perform. More precisely, we do consider two kinds of tasks. First, we consider tasks that are well identified, for which assistance would rely on knowledge described in carefully designed ontologies. A great part of the Semantic Web effort (Handschuh, 2003) is devoted to studying how to model such knowledge, represent it into web documents with XML-based languages, extract it more or less automatically from texts, or get it from user annotations. As an example, an RDF triple can describe that a particular fragment of a web page is a postal address (as defined in an Office ontology), allowing automatic management by an aware assistant that could add it to an address book. In such a case, the underlying assumption is that it is interesting to tag postal addresses, for they are used to send postal mails in a classical office task. An assistant would add knowledge to the address book without considering what the user had actually done with the address. However, it is also important to consider a second kind of tasks, which are hard to anticipate, and should be recognized from their manifestations and defined on the fly, considering actual experience of use of the system. In our example, the user could use the textual fragment with the address for searching a phone number in a digital phone book, and then add the phone number to the address book. Of course, such behaviour could not be assisted the first time it occurs, but we think that if it became usual, assistants should be able to take advantage of it. Designing such kind of assistant requires high versatility of task description models, but it also being able to take into account the actual users’ experience of using the system. In fact, we claim that the challenge resides in being able to trace concrete experience (i.e. experience acquired through actual uses) in such a way that it could be re-exploited to provide useful answers to questions that were not fully defined from the start. Let us restate our main question: how is it possible to model and capture experience in using a system, so that it can be reused as knowledge for user assistance? Moreover, how could it be that the assistance itself could evolve with concrete experience? Our group, which comes from the Case-Based Reasoning (CBR) research field as a mean of tracking and reusing experience, has been attempting to propose solutions for this challenge across several research works (Prié 2000, Egyed-Zsigmond et al. 2000, Corvaisier et al. 1997, Champin 2003). This led us to elaborate MUSETTE (Modelling USEs and Tasks for Tracing Experience), a general framework for representing concrete experience in relation with its context of use. In the next section, the MUSETTE global approach is shortly presented. The two following sections present and exemplify the notions of use model and traces, then of explained task signature as a mean to split a trace into episodes, or potential reusable cases. The fifth section deals with scenarios demonstrating different kinds of
MUSETTE assistants in action. The sixth section presents an ongoing work aiming at modelling a real application in the field of Web intelligence, while the seventh section is devoted to discussing related works, mainly in the field of CBR and task modelling. The last section draws the opened perspectives of our work through some current research projects and developments.
User direct assistance
Observation Model
System
interaction system mediated assistance
Observation
Use Model
....
trace generation
Primitive trace
Assistant agents Episode reuse
Observer agent
Generic trace analyser Task signature 1
Episodes
episode extraction
............
Task signature 2
Episodes
Fig. 1. Introducing our approach and vocabulary
2 Global approach Figure 1 presents the general framework of our approach, leading (clockwise) from the observation level (upper-right corner) to the experience reuse level (lower-left), with two levels of experience modelling. A user interacts with a system, leading to changes in this computing system (events, files...). An observer agent, observing these changes according to an observation model, generates a primitive trace, which conforms to a general use model. Then, a generic trace analyser extracts significant episodes from the primitive trace, according to explained task signatures. These episodes can be (re)used by assistant agents, which can assist the user, either being clearly distinct from the system (direct assistance), or modifying the system (system mediated assistance). In the latter case, the assistance interaction can in turn be observed by the observer agent, allowing assistance episodes to be also reused. Let us emphasize the fact that Musette is only a general framework. It can be implemented using various languages or representation formalisms, provided that those enable the representation of every component of the Musette approach, as described hereafter.
3 Use model and traces 3.1 What do we observe? Since the Musette approach requires a representation, as a primitive trace, of the interactions between the user and the system, the first step in applying that approach is to decide what the trace will be made of, and how it will actually be constructed. Those questions must be answered respectively by the use model and the observation model, in order to build the observer agent in charge of producing the trace (cf. fig. 1). Basically, the trace will be composed of Objects of Interest (OI). Those can belong to one of the three following categories: entities, events and relations. Entities can be characterized as objects being present to the user in their interaction with the system, while events can be characterized as objects happening during the interaction. Objects make sense for both the computer application and for the user. Relations are binary, and can imply either entities or events. The use model can be thought of as an ontology of the observed system: it describes what kind of entities, events and relations will actually be observable to produce the primitive trace. Depending on the expressiveness of the implementation language, additional constraints can also be part of the use model (attributes of OIs, allowed values, etc.). Let us emphasize the fact that the objects of interest used to describe a system, as the word ‘interest’ implies, depend on the particular focus, however general, of the use model. Deciding how the user-system interaction will be observed is bound to be biased by the use model designer’s goals. 3.2 How do we observe? Describing the components of the to-be-produced trace is not sufficient to build an observer, though. The observation model still has to be described, as a set of means to access relevant data in the system, as well as rules constraining the process of producing the trace —e.g., which relevant subset of all the observable entities must be written to the trace at a given moment? Unlike the use model, the observation model is not specified by the Musette approach for the moment. Indeed, producing a trace conforming to a given use model, by observing the interactions between the user and the system, highly depends on the system itself, on which we deliberately made no assumptions. We envision that software systems will become more and more self-explicative, and more and more expandable. Therefore, generic observers, controlled by a set of system-dedicated formal observation rules, may eventually become a reality. However in the current state of the art, an ad-hoc observer has to be built for every system and with a particular use model in mind and the observation model has to be hard-coded manually in such an observer.
3.3 Modelling traces Once the observer agent has been specified by the use model and the (possibly hardcoded) observation model, it can produce traces from the observation of the interactions between the user and the system. The structure of the trace is not limited to a continuous stream of entities and events, possibly in relation with one another. Indeed, entities are used to represent the state of the system at a given moment (or during a period considered to be an instant in the context of the use model). On the other hand, events happen in the transitory period between two states. Hence the grouping, in the trace, of OIs according to their category, turns the trace into an alternate sequence of states and transitions. It is worth noting that states and transitions in the Musette approach merely have a temporal role. They are not intended to convey any predefined causal meaning; in particular, the entities of a state together with the events of the following transition are not bound to logically imply the following state (see in the example below, the note about Transition 6). Of course, a given use model can add such causal semantics to specific kinds of entities, events or relations it defines. However, the approach does not require it in any way. Observable Object of interest
Constraints
Relations
Entity
Event
State
Transition
Cust
Lang
Fr
Image
Bm Sav
Observation
Page 1
Link Click
Page
Use model
Persistence
Link2
Link1
Click1
Fr Page 2
Lang1
En
Bm1
Page 2
State 5 Transition 5 State 6 Transition 6 State 7
Fig. 2. A simple use model and a web navigation trace
3.4 Example Figure 2 gives an example of a rather simplistic use model for a web browser, together with a fragment of a primitive trace conforming to that use model. Entities of the use models are web pages (Page), hyperlinks (Link), images (Image) and customisation features (Cust). Events are the user clicking on a hyperlink (Click), saving a page or an image locally (Save), setting a bookmark on a page (Bm) and changing the preferred language of the browser (Lang). In the following, we will consider that pages also have an internal attribute url containing their address. For the sake of readability, all the possible relations are not represented in the use model, but the relation from a link entity to a click event, and from a click event to a
page entity —obviously meaning that the corresponding link was clicked, leading to the corresponding page to be displayed. Other relations appear in the trace only, but would in principle be defined in the use model as well: from page to link (“the page contains the link”), from page to bookmarking (“the bookmarking applies to the page”), from page to page (“the page is reloaded”) from customisation feature to language change, then to another customisation feature (where the customisation features represent the previous and new language settings). Note that the Transition 6 contains the events ‘Lang1’ and ‘Bm1’. This means that those two events are independent from each other; the order in which they happened is not given by the trace. The fact that no state was constructed between them comes from the fact that the underlying observation model (not described in this paper) specifies that states are to be constructed only when a page is (re)loaded. The Persistence relation is also worth commenting: it allows, in this particular use model, to express the fact that entities of different states actually represent the same object from the system point of view. The identity of objects may not be necessary in any use model, so it is not a part of the core Musette model. However, the Persistence relation is one possible mean of expressing it in a particular use model, when needed (another one being a dedicated internal attribute representing identity).
4 Extasis and episodes Assuming that the use model enables an appropriate description of the interactions of the user with the system, the user’s experience is potentially retrievable from the primitive trace. More precisely, we call an episode any part of the trace corresponding to a specific experience in performing a specific task, and which can be reused in a similar situation. Pieces of the trace are recognized as episodes related to a particular task thanks to EXplained TAsk SIgnatures (Extasis). 4.1 Explained Task Signatures We need a mean to locate episodes in the primitive trace. We assume that episodes related to a particular task usually share some common features: involving the same kind of entities or events, co-occurring or occurring in a given order, etc. More generally, we consider that these common features can be expressed by: − A pattern of the graph constituted by the objects of interest (i.e. events and entities) and their relations. − Constraints on the relative positions of OIs in the trace (e.g. co-occurrences in observations – States or Transitions –, distance between observations in the trace). − Language-dependent constraints on the internal structure of OIs (e.g. attribute values).
Once these common features have been identified for a particular task, they can be considered a signature of this task. Indeed, their instantiation in the trace can be interpreted as an evidence of the user performing that task in the corresponding period. Episodes are not limited to parts of the trace instantiating a task signature, though: once identified the task performed by the user, one can improve their interpretation of the trace. The roles that the OIs play in that trace may be easier to understand; additional relations, not captured by the observer agent, and not present in the use model, may be inferred; etc. Therefore, the episode can be annotated, or explained, by some information coming from the fact that it has been recognized as an occurrence of a particular task. Explanations may take the form of free text annotation (that a human could interpret), or of formal knowledge annotation (aimed at an automated agent interpretation). A number of explained task signatures thus allow the generic analyser (cf. figure 1) to produce, from the primitive trace, episodes instantiating the signature part of Extasis and annotated by their explanation part. Of course, there is a trade-off between the versatility and the efficiency of such a system, and it highly relies on the use model. Should it be too general, different tasks will be indistinguishable from one another, and episodes will be too vague to be efficiently reused. Should it be too specific, some tasks outside its focus will become plainly undetectable.
4.2 Example We show here how two common web browsing tasks can be identified in our example use model, and how their signature can be explained by annotations on the matching OIs. When discovering an interesting web page, we often want to put a bookmark on the site containing this page, since it probably contains other interestingly related pages. Such tasks can easily be spotted in the primitive trace: from a first Page, a second one is accessed whose url is a prefix of the former one’s url, then a Bm (bookmark) event occurs in relation with the latter Page. The upper EXTASI in figure 3 has such a signature (note the dotted arrow representing a language-dependent constraint over url attributes). Explanations are also provided in this EXTASI: the Bm event is annotated with textual explanation, potentially useful for episode interpretation, while both pages in the signature are annotated by ‘Inner page’ and ‘Site homepage’. We could consider that these annotations act as additional formal knowledge, being instances of concepts defined in a Web site ontology (defined out of MUSETTE), and usable by some specialized assistant. Another task consists in changing the web browser language setting in order to view different versions of a web page available in different languages. Our use model allows detecting such a task, since changes in the language settings are represented by a Lang event, as well as the corresponding page change (without clicking on a link). The lower EXTASI in figure 3 has such a signature, with dotted circles representing a
co-occurrence constraint of Page OIs with Cust OIs representing the currently set language. Here again, a textual annotation provides explanations about the OIs. One will remark that both EXTASI presented here have a matching in the example trace of figure 2: from state 5 to transition 6 is an episode of “bookmarking an interesting site”, and from state 6 to state 7 is an episode of “changing language”. Explained task signature : Bookmarking an interesting site Page
Click
Link
Page
URLContainment
Inner page
Allow to browse to the inside page
Bm Site homepage
FIG. 3 - Explained task signatures and episodes.
Explained task signature : Changing language
Page
Page Cust
Lang
Cust
This page is prefered in that language
Fig. 3. Explained Task Signatures and episodes
5 Scenarios Let us demonstrate how different kinds of assistants can be designed on top of the Musette approach. A specific assistant can take into account one given task by reusing the episodes instantiating the corresponding Extasi. For example, given the upper Extasi of figure 3, we could build an assistant that would notify the user whenever she is browsing a page in an interesting site —that is, whenever it would find an episode matching the Extasi “Bookmarking an interesting site” whose site is the current site. Such a specific assistant can apply case based reasoning mechanisms (Aamodt 1994) to reuse relevant episodes in a given context. However, an advantage of the Musette approach is that the same knowledge base (the primitive traces) can be shared by many different assistants extracting different episodes from it. Moreover, a new assistant can be added without needing to build a completely new knowledge base: only a new Extasi has to be provided in order to extract new episodes from existing traces. The second scenario involves a generic assistant capable of handling any number of tasks, via their Extasi, in a regular way: exploring the current trace with respect to a particular task, rather than the flat history list usually provided by web browsers,
suggesting or doing automatically some actions when they seem relevant, the way spellchecker or auto-correctors work, etc. In our example, the user could browse all the interesting sites he has already visited, or all the pages he preferred to read in French. He could also be suggested to put a bookmark on a page, or change the language setting, when he has already done so with a similar page. Again, the assistant could even perform those actions automatically. The advantage of Musette here is that every particular task is reified and elicited by the corresponding Extasi, and that the explanations provided in the Extasi can be used to guide the assistant as well as to make it understandable by the user. In the third scenario, the user explicitly asks the assistant for help. The latter then has to identify the task being performed by the user in order to select appropriate episodes for reuse. Task identification can range from explicit selection of an Extasi by the user, to fully automatic detection in the current trace according to the available Extasis. An intermediate solution is for the system to propose various interpretations of the user’s activity, based on the partially instantiated Extasis and corresponding explanations. The user may then accept or reject those interpretations until a consensus is reached. The assistant can then retrieve similar episodes based on the same Extasi in order to reuse them. For an example of this scenario, we will assume a richer use model than the one proposed previously (cf. figure 2). In particular, we assume that it enables the description of web forms and e-mail sending, and that two Extasis are defined. A first Extasi called “Query refinement” consists in two successive queries to a search engine: after a first query which has returned too many answers, the user decided to send the same query but added other keywords to filter out irrelevant answers. A textual explanation tags the first result page: “too many answers”. Another Extasi called “Asking someone” consists in a query to a search engine followed by the sending of an e-mail containing all the words of the query (such as the one presented in section 6.3). In this case, a textual explanation tags the result page of the first query: “no relevant answer”. Now consider a user who, after a first query to a search engine (say, Google), asks the assistant for help. The assistant recognizes the beginning of both Extasis described previously. It proposes one interpretation of the result page as “too many answers”, but the user rejects it. It then proposes “no relevant answer”, which is accepted. The assistant will then look for episodes matching the Extasi “Ask someone” for a similar episode. The recipient of the e-mail, in the reused episode, will be all the more likely to be the right person to ask, that the episodes, and especially the keywords of the queries, are similar. The interest of using Musette in this scenario lies in the fact that querying the experience base is done by simply using the system (thus instantiating a particular Extasi). No additional skill is required (as opposed to using a dedicated query language), hence reducing the risk of biasing assistance. The fourth scenario goes a step further than the previous one. Assume none of the proposed Extasis satisfy the user. The assistant could provide a mean for him to specify even more precisely what task he is willing to perform. For example, our user does not want to ask someone, nor to refine his query by adding more keywords, but
would rather submit the same query to a more specialized search engine (e.g., field specific or language specific). What the user is actually doing is describing a new task with its own Extasi —without specifying it completely, of course, since the user wants help to find the appropriate specialized search engine. Even though this Extasi was not known before, this task might have been already performed, and therefore some trace might contain episodes matching this newly created Extasi. The user can indeed describe a previously unknown task on the fly, and still obtain assistance about it. We see here how the separation in Musette, between the general use model and specific task signatures, leverages user assistance.
6 An experience of Musette modelling The Musette framework has been used for modelling and designing assistance in the use of existing software. Some aspects of this modelling are presented in the following. 6.1 Human-Links Human-Links (HL) is a documentary workspace management software developed by Amoweba1, supporting strategic intelligence on the web (CSI: Computer Supported Intelligence). HL is designed to visualize, organize, search and share information. The HL interface contains an interactive “thematic” map (fig.4) allowing to visualize and to handle a set of textual documents organized in a hierarchical system of thematic categories. The spatial distance between items on the map represents a semantic distance determined by the program2, thanks to keywords automatically extracted from textual documents. HL has also meta-engine search capabilities. Results of queries appear progressively on the map, allowing users to assess their thematic pertinence relatively to the categories and documents already presents in workspace. Finally HL is based on a “peer to peer” architecture. This distributed solution allows collaborative information searching and sharing. HL is the core of the digital system the use of which we will trace, in the context of strategic intelligence. Indeed, thanks to an analysis of CSI activity, we have been able to determine five general tasks of digital documentary workspace management: document Searching, Consulting and Creating, workspace Organizing, and Communicating.
1 2
See http://www.amoweba.com/ and http://www.human-links.com/ HL uses an enhanced TF-IDF approach.
Categories Hierarchy
Current Category
Keywords of current category profile
Thematic Map
A document of the current category
Detailed items lists
Fig. 4. Human-Links interface
These general tasks cover the CSI activity. This activity is observed through the use of a compound system which enables its achievement. More precisely, the observed system is a set of complementary and co-operating tools, structured around HL: Operating System and files manager (MS Windows), viewers/editors for textual files (Acrobat, MS Word, WordPad, Internet Explorer), communication tools (Outlook), Web browser (Internet Explorer) and HL itself. 6.2 Use model We have designed a specific use model for the observed system, and hence defined a specific set of OIs. It contains 35 types of Musette entities. Entities may differ in their nature or abstraction level. For example {MS Word}, {User}, {Assistant}, {Outlook} describe components of the global system. {Query}3, {HL_Document}4, {Correspondence}5 describe entities which are closer to tools interfaces, particularly HL’s one. Finally some entities have a higher abstraction level (ex: {Category selection}6, {User focus}). This use model defines also 40 types of Musette events, with varying abstraction levels. Some events directly correspond to software functionalities (ex: {Remove}, {Move}), some others do not (ex: {Chat to}, {Back to root}). Events have a more or less general meaning with regard to the kind of Entities with which they can be in relation. The {Open} event for example, can be applied on (hence related to) any document type and any tool. It is different for {Launch Query} which can be applied only on a Query. Finally a set of Relations has been determined. Let us simply stress that Relations are typed and oriented. 3
Query of Human-Links search engine. HL_Document is a document appearing on HL maps, i.e. indexed by the user. 5 Contents of mails, discussion and exchanged files between user and his contacts. 6 Set of categories selected at the same time. 4
A simplified part of the UM is presented in figure 5. It contains 6 events, 5 entities and some relations. Even simplified, we can’t describe here each OI, and we should highlight the fact that we did not report on the figure all the existing relations between the described OIs, so as to enhance legibility. As an example, one can read relations as following: {Launch Query} event is related to {HL_Document} entity, with a {Give} relation, because a running query makes HL_documents appear on the workspace. It can be pointed out that OIs involved in category splitting attempt to deal with the documentary workspace organization dimension of the CSI activity whereas OIs involved in query working rather deals with the searching dimension. OIs OIs Relations Relations
Open
Entities Entities
Category
Split Cat.
Constraints
Events Events
Query
Modify Query
Keywords
Run Query
Exchange
HL _Document
Index
Contact
Fig. 5. Simplified part of Use Model
6.3 Task signatures and assistance We have designed about twenty tasks signatures characterizing particular tasks performed by a user. Some of these patterns describe episodes in the trace that are near tools manipulation, at a low abstraction level, such as “saving a document locally”; some others, are closer to the task, at a higher abstraction level, such as “search by web browsing”. Let us present a quite realistic example. Suppose a Human-Links user is searching a particular document to integrate it into his HL workspace. He creates a query with keywords, launches it, and obtains documents as responses. The signature (cf. fig.6) start point occurs when a transition contains three events (Stop, Modify and Launch Query). The first one (Stop Query) implies that the user has created a Query, launched it with some keywords and obtained results. The user, unsatisfied with the results, modifies the Query7 and launches it again. Then, in the following state, we find the Query entity, keywords entity8 and resulting HL_Documents entities. The same operation (transition K and state K+1) can be repeated. Resulting documents remaining unsatisfying after several query launching, the user decides to communi-
7 8
He can add, change or remove keywords, use new operators, etc. Groups all keywords used by the user during his search.
cate (Exchange event) with a contact9 to solve his problem. The Correspondence entity contains all contents10 of exchanged information between the user and his contact. In this particular signature, the contact sends an attached file. The user is satisfied and locally records this particular document (which appears as Local_doc entity), and then indexes it in his HL workspace (Index event). Then when the user will have to deal with the same kind of search problem, an assistant agent will be able to recall that he has already encountered this problem and that the solution was to communicate with a contact. This agent would be able to propose, for example, the most pertinent contact relatively to the keywords used in the current search and keywords contained in the contact profile.
A. Stop Q.
Query
Modify Q. Launch Q.
Keywords
Transition K
…
State.K+1
Exchange Correspondence
…
Local_Doc Index
Keywords Transition K + n
State.K+ n+1
B. Stop Modif
HL_doc1 HL_doc1
Q.1
Launch
Modif I.E.
KeyW
Stop
Launch
HL_doc3 HL_doc4
Q.1
HL_doc5
Corsp.
I.E.
KeyW
Loc_Doc1
Exchg.
Contact
HL_doc4
Outlook
Trans. K +n+ p
State K+n+ p
Open Move
Acrobat
Index
KeyW
KeyW
Fig. 6. The task Signature (A) is instantiated in an Episode (B)
We don’t take for granted that about twenty Musette Signatures could be an efficient set to perform a complete assistance. A Musette model designer cannot and does not have to be exhaustive, and we wish assistant agents to be able to deal with new signatures designed during the system use (cf. 5.). Our twenty tasks signatures are just a “primer” for the system we would set up. At this time, our goal is to validate the modelling and to evaluate modalities of an assistant agent implementation into HL. Furthermore, those task signatures could be reconsidered by first real use traces obtained or by users themselves. 6.4 Musette modelling approach for Human-Links As described in 6.1, the observed system was defined according to an analysis of CSI activity. The OIs were determined by the model designer so as to describe different user tasks with various abstraction levels. In fact, the determined OIs have to enable coherent and pertinent user task description, i.e. task signatures creation. In9
Other HL users on the peer to peer network. Contents of mails, chats, attached files.
10
deed these signatures are created by the model designer according to the assistance – hence the episodes– he would set up. The main difficulty in the present modeling was to deal with the different abstraction levels between Entities, Event and task Signatures. OIs have been first determined by the model designer according to an observation work of observed system used in a CSI context11. Then OIs have been discussed with an expert HL user and the HL designer. Finally OIs and created task Signatures have been validated by an expert HL user and the HL designer.
7 Related works Long before digital computers and the Internet, Vannevar Bush (1945) was dreaming of what he called the “MEMEX”, a device that would capture everything a scientist looked at or commented about, creating a trail of information which he or other scientists could later retrieve. In the 90's, Hill et al. (1992) saw cumulative interactions of users with digital objects as a form of wear and tear, comparable to the torn pages in a manual. More recently, Wexelblat and Maes (Wexelblat 1997) have developed a tool enabling users to visualize the paths the others have taken through a site. These preliminary works focused on what could be presented directly to users as footprints to follow for their (unformulated) request. They aimed to work as generic assistants. Some works focused on the user task to put in context such assistance (Farell et al. 2000, Francisco-Revilla 2000) while others tried to capture general web navigation episodes on static signatures (Corvaisier et al. 1997, Jaczinski 1998) or, like Takano et al. (2000), used past procedure cases to help their use in specific applications. These last works rely on the Case-Based Reasoning paradigm, which is widely used for Help Desk systems. Those need cases to be described through forms (Herbeaux 1999) or during a “conversation” (which assumes that questions can be structured in order to fit the cases of a library) (Aha et al. 2001). Therefore, case structure has to be defined in advance and case libraries are built according to it. The experience stored in them thus becomes scarcely exploitable for unanticipated questions. If cases have to be relaxed as use episodes dynamically found in the trace, it is nevertheless necessary to take into account the context of user’ tasks. Task modelling has been widely studied by the knowledge engineering community as well as in the Human-Machine interaction domain [Eamonn et al. 1996]. This modelling can be performed in the context designing knowledge-based systems (Schreiber et al. 1999) and is increasingly used for knowledge management purpose (Holz et al. 2001). In the same way, ontology design is more and more explicitly task driven (Reynaud 1997). We could see episodes as chronicles [Dousson 1999], but Extasis are not specifically devoted to express temporal or causal relations and the goal is not explicitly given. Extasis could be described at different level of abstraction as tasks in [Wincler et al. 2002]. Knowledge engineering proposes models, methods and tools, often implying great efforts to elicit tasks from users’ actual behaviours. On the other hand, 11
Note that the model designer is always influenced by the assistance he tries to create.
computer assistants helping users to perform a task only need it to be expressed in terms of relevant resources for the assistance, rather than full-fledged task modelling. Nevertheless, in an experience reuse approach, it is necessary to spot pieces of the use traces that would refer to some user’s task. Hence, we proposed Extasis as simplified views of task models. Such signatures can be designed according to classical knowledge engineering approaches in order to be integrated in a computer environment, before the system is ever used; but they can also be designed on demand at run-time by the user himself. This approach assumes that end users are co-designers of their assistance environment [Muller et al. 2002].
Fig. 7. MUSETTE prototyping tool in PROTÉGÉ
8 Perspectives The application of the Musette model to an interaction needs a prototyping phase: in many cases, observer agents will have to be coded from scratch, and therefore need significant development efforts. To go further than plain pen-paper modelling, we needed a graphical tool for rapidly prototyping use models, primitive traces and first task signatures. Such a prototype has been developed as a plug-in for PROTÉGÉ12 (see figure 4). In that case, we use the PROTÉGÉ knowledge representation language OKBC as an implementation language for Musette. It allows us to model the Musette upper ontology (Observable, Relations, Events, Entities, States and Transition), which controls the creation of the use model as an ontology, and of a trace as composed of instances of both ontologies. PROTÉGÉ also allows us to export models and traces in XML-based languages, such as RDF triples or OWL ontologies and descriptions. Indeed, we systematically favour that kind of languages for all of our implementations, and will compare the representations produced with PROTÉGÉ from our own build-in ones. We have already built CBR and Experience-Based systems, upon whose creation experience we designed Musette, and therefore which – to some extend – imple12
See http://protege.stanford.edu/
mented parts of the Musette approach. We consider that they, and many successful CBR systems with them, also validate the Musette approach to some extend, as Musette can be seen as a generalization of the CBR approach. We are also using the Musette approach for various assistances design: − We presented in 6th section how we applied our approached to the Human-Links tool for Web intelligence. An important feature of this modelling is that it does not restrain to this single tool, but on the contrary models the use to a set of tools at a rather high abstraction level. This real application modelling will go on with the development of several Musette assistants. We will also investigate how Musette could be used for activity modelling in the context of several cartographic tools (mail exchange activity, web archive exploration), and how it can specialize in the context of application re-engineering. − Another project considers a tool for digital simulation design and results exchange among groups of experts. We focus on the shared documentary knowledge space they built, and on document exchange and annotating. On the first level, we consider that each user is accompanied by a digital alter ego. This agent uses the Musette approach to trace its related user’s experience, and can help him along his tasks. On the second level, we consider societies of alter egos, exchanging experience and constructing shared use experience, mainly as shared ontologies. The new model is called MAZETTE, for Multi-agent Musette. − We also consider the use a basic navigation tool, so as to study how we could annotate web resources by their uses and reuse these annotations for user adaptation and help in the context of the Semantic Web, cf. (Champin and Prié 2003). Developing Musette analysis and building Musette tools will lead to the development of real methodologies for experience reuse according to Musette principles. Such methodology should help building evolutionary assistants for human computer interaction, able to cope with new task descriptions without needing either a complete redesign or a new knowledge base.
References 1. 1. Aamodt, A., Plaza., E.: Case-based reasoning; Foundational issues, methodological variations, and system approaches. AI Communications, Vol.7, No.1 (1992) 2. Aha, D.-W., Breslow, L., Munoz-Avila. H.: Conversational case-based reasoning. Applied Intelligence, Vol. 14 Num.1 (2001) 9–32 3. Bush, V.: As we may think, Atlantic Monthly, Vol. 176 N. 1 (1945) 101–108 4. Champin, P.A.: Ardeco: an assistant for experience reuse in Computer Aided Design. In WS5: From Structured Cases to Unstructured Problem Solving Episodes for ExperienceBased Assistance, Workshop at ICCBR’03, Trondheim (2003) 5. Champin, P-A., Prié, Y.: Musette: uses-based annotation for the Semantic Web, In Annotation for the Semantic Web, IOS Press, Amsterdam (2003) 180–190 6. Corvaisier, F., Mille, A., Pinon, J.-M. : Information retrieval on the world wide web using a decision making system. In RIAO’97 (1997) 284–295
7. Dousson, C., Vu Duong T., “Discovering chronicles with numerical time constraints from alarm logs for monitoring dynamic systems”, In proc. Of the 16th International Joint Conference on Artificial Intelligence (IJCAI’99), pp.620-626 8. Eamonn J., "Task Model Support for Cooperative Analysis," CHI'96 Conference Companion, Vancouver, April 1996, ACM Press, New York, pp. 259-260. 9. Egyed-Zsigmond, E., Prié, Y., Mille, A., Pinon, J.-M. : A graph-based audiovisual document annotation and browsing system. In RIAO 2000, Vol. 2, Paris (2000) 1381–1389 10. Farrell, R., Fairweather, P., Brumer, E.: A task based architecture for application aware adjuncts, ACM International Conference on Intelligent User Interfaces, New Orleans, LA USA (2000) 82–85 11. Francisco-Revilla, L. Breimer, E.: Adaptive medical information delivery combining user, task and situation models, Internation Conference on Intelligent Interfaces, New Orleans, LA USA (2000) 94–97 12. Handschuh, S., Staab, S. (eds.): Annotation in the Semantic Web, IOS Press, Amsterdam (2003) 13. Herbeaux, O., Mille. A.: Accelere: a case-based design assistant for closed cell rubber industry. Knowledge-Based Systems, Vol. 12 (1999) 231–238 14. Hill, W.C., Hollan, J.D., Wroblewski, D., McCandless, T.: Edit Wear and Read Wear. In Proceedings of ACM Conference on Human Factors in Computing Systems, CHI'92, New York ACM Press (1992) 3–9 15. Holz, H., Könnecker, A., Maurer, F.: Task-specific knowledge management in a processcentred see. In Althoff, K.D., Feldmann, R.L., Müller, W. (Eds.): Advances in Learning Software Organizations, Proc. of LSO 2001, LNCS Vol. 2176 (2001) 16. Jaczinski, M., Trousse, B.: WWW Assisted Browsing by Reusing Past Navigations of a group of users, in Advances in Case-Based Reasoning, 4th EWCBR, Dublin, Ireland (1998) 17. Muller, M.J., Carey, K.: Design as a Minority Discipline in a Software Company: Toward Requirements for a community of Practice, In CHI 2002, April 20-25 2002, ACM 1-58113453-3 (2002) 18. Prié, Y., Mille, A.: Reuse of knowledge containers: a local semantics approach. In M. Minor, editor, Workshop on Flexible Strategies for Maintaining Knowledge Containers, ECAI 2000, Num. 33 (2000) 38–45 19. Reynaud, C., Tort, F.: Using explicit ontologies to create problem-solving methods. International Journal of Human-Computer Studies, Vol. 46 (1997) 339–364 20. Schreiber, G., Hakkermans, A., Anjewierden, A., de Hoog, R., Shadbolt, N., Van de Welde, W., Wielinga, B.:. Knowledge Engineering and Management: The CommonKADS methodology. The MIT Press (1999) 21. Selker, T.: Coach: A teaching agent that Learns, Communication of the ACM, Vol. 37, Num. 7, (1994) 92–99 22. Takano, A., Yurugi, Y., Kaenaegami, A.: Procedure Based Help Desk System, ACM IUI 2000, New Orleans, LA USA (2000) 264–272 23. Wexelblat, A., Maes, P.: Footprints: History-rich web browsing, In Proc. Conf. Computer-Assisted Information Retrieval RIAO (1997) 75–84
