Embed Size (px)
Citation preview
This article was downloaded by: [Uppsala universitetsbibliotek]On: 11 October 2014, At: 02:12Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK
Journal of Decision SystemsPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/tjds20
Representation of real-time decision-making by contextual graphs basedsimulationPatrick Brézillon a & Anissa Aroua aa LIP6 , University Pierre and Marie Curie (UPMC) , Paris , FrancePublished online: 15 Feb 2013.
To cite this article: Patrick Brézillon & Anissa Aroua (2013) Representation of real-time decision-making by contextual graphs based simulation, Journal of Decision Systems, 22:1, 28-42, DOI:10.1080/12460125.2012.760270
To link to this article: http://dx.doi.org/10.1080/12460125.2012.760270
PLEASE SCROLL DOWN FOR ARTICLE
Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis,our agents, and our licensors make no representations or warranties whatsoever as tothe accuracy, completeness, or suitability for any purpose of the Content. Any opinionsand views expressed in this publication are the opinions and views of the authors,and are not the views of or endorsed by Taylor & Francis. The accuracy of the Contentshould not be relied upon and should be independently verified with primary sourcesof information. Taylor and Francis shall not be liable for any losses, actions, claims,proceedings, demands, costs, expenses, damages, and other liabilities whatsoever orhowsoever caused arising directly or indirectly in connection with, in relation to or arisingout of the use of the Content.
This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions
Representation of real-time decision-making by contextual graphs basedsimulation
Patrick Brézillon* and Anissa Aroua
LIP6, University Pierre and Marie Curie (UPMC), Paris, France
(Received 10 August 2012; final version received 16 December 2012)
An important aspect of mobile decision is its temporal nature. Experts develop a decision-making process jointly with the progressive elaboration of a context-specific model of thedecision-making. However, context modeling is generally not considered explicitly, becauseonly the result of the decision-making process is supposed to be of interest. For mobiledecision, modeling this contextualization process supposes a formalism allowing a uniformrepresentation of knowledge, reasoning and contexts like the Contextual-Graphs formalismin which all the contextual variants of a decision-making process are represented as acontextual graph. This paper presents the example of a workflow manager that is developedin a large project in breast cancer diagnosis. The workflow manager is a real-time decision-making process in which the result of an action may change the context of the decision-making process. Managing context jointly with the decision-making process is a way totackle time and model effectively mobile decision-making.
Keywords: decision-making; context modeling; contextual graphs; contextual graph basedsimulation; workflow manager; mobile decision
Introduction
Workflows are a way to automate task realisation in the engineering area, during whichdocuments, information or tasks are passed from one participant to another for action, accord-ing to a set of procedural rules for representing the corresponding decision-making process.Workflows represent declaratively the components or codes that need to be executed in a com-plex application, as well as the data dependencies among those components and peopleinvolved. This distinction between components and their assembling is particularly importantfor scientific workflows (SWFs) that are often described as ‘knowledge intensive’ (Deelman &Chervenak, 2008).
SWFs are published in repositories to be shared with other researchers. This implicitlysupposes that published SWFs are usable directly by others, while they result from a contex-tualization process (and thus cannot be reused directly in any other context). This is a well-known ambiguity between procedures and practices (Brézillon, 2007). A procedure is theway in which the head of a company thinks that a problem must be solved, based on com-pany policy and strategy. A practice is the way in which an actor applies the procedure onthe basis of tactical and operational considerations. Each actor tailors the procedure in orderto take into account his particular and specific context, the task to accomplish, the workingsituation and the local environment where the available resources are.
*Corresponding author. Email: [email protected]
Journal of Decision Systems, 2013Vol. 22, No. 1, 28–42, http://dx.doi.org/10.1080/12460125.2012.760270
� 2013 Taylor & Francis
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
With some success, an application for docking in virtual screening (Brézillon, 2011; Fanet al., 2011) models the SWF-building process rather than the SWF alone and points out therole of decision-making, thanks to the use of the Contextual-Graphs formalism in the explicitassembling of workflow components as a context-based decision-making process.
In this paper, we extend this work by considering the time dimension in the decision-making process proposed in Brézillon (2012). Initiated in the framework of the MICO (COg-nitive MIcroscope) project, our contribution aims to support the real-time decision-makingprocess of an anatomo-cyto-pathologist (ACP) in his interpretation of digital slides for diag-nosing breast cancer. Concretely, we implement a workflow manager to make more system-atic the identification of particular forms (mitosis actually). Temporal modulation of theworkflow occurs by taking into account explicitly the outcomes of SWF-component executionon the decision-making process. For example, a program execution may require a delay forits completion or may fail. Another consequence of a component execution can imply achange of the working context of the SWF execution and the need to revise it. This studypoints out some new aspects of contextual graph-based simulation by intelligent assistant sys-tems and their importance for mobile decision.
The paper presents contextual graph-based simulation for studying real-time decision-making. Section 2 discusses the relationships between real-time decision-making and context.Section 3 introduces the Contextual-Graphs formalism and its implementation. Section 4 pre-sents how an intelligent assistant system (IAS), working on a contextual graph, can give anabstracted presentation of the decision-making process taking into account some standard out-comes of action (or component) execution. Section 5 illustrates the application of ourapproach on a workflow manager developed in the MICO project that aims to design, developand implement a cognition-driven visual explorer for anatomo-cyto-pathologists in anapplication to breast cancer grading with a discussion on the challenge opened by ourapproach for the design of IASs for managing contextual graphs (CxG) -based simulation.Section 6 concludes the paper.
2. Real-time decision making
The decision-making process during task realisation: (1) is composed of a number ofdecisions more or less independent and described in different activities (eventually under theresponsibility of different actors), (2) must be flexible enough to take into account theenvironment evolution, and (3) may modify the working context, which may motivate achange in the decision-making. Activities can be affected, for example, by data processing orthe need to wait for some information. Mobile decision-making requires the additional consid-eration of the technological dimension (mainly handheld computers and wireless access). Asa consequence, looking for feed forward strategies becomes irrelevant and new approachesmust be developed for integrating decision and action in a time-compatible way.
2.1. Lessons learned at a workshop
Interesting lessons were learned at the workshop ‘Supporting real time decision-making: Therole of context in decision support on the move’ (Burstein et al., 2008). Power (2008) openedthe workshop by noting that sophisticated real-time decision support is both possible andpractical to implement today if (1) managers can address several challenges when evaluatingand implementing real-time decision support systems, and (2) real-time systems must accom-modate a wide variety of processing objectives. Technical, organizational and business issuesare due to a large extent to the context in which managers and their organizations operate.
Journal of Decision Systems 29
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
This working context constrains the implications for the way transactions are processed andthe decision situations faced by managers (Carton et al., 2008).
Real-time decision support involves accessing diverse data sources in different formats,including spatial and non-spatial, and use of dynamic, high-resolution displays, high-speedwireless remote access, and automatic data collection, processing and distribution. Thesystems are driven by external world events because the external environments cannot becharacterized accurately a priori. There are important data flows, hard real-time deadlines,asynchronous, event-based low latency responses, soft real-time processing requirements,reaction time paths across multiple hardware and software components, a wide dynamic rangeof processing loads, operator display and control requirements, high availability andsurvivability requirements, and stringent certification and safety requirements (Masters &Welch, 2008). We can add the need to lead routine activities several times during reasoning,say for monitoring or analysing continuous data (Clancey et al., 2009).
To sum up, a real-time decision support system must possess some fundamental character-istics. The system needs to be flexible and reactive with an important observation: Decision-making and action must be considered jointly as two intrinsic and interdependent parts of theprocess, not separately. This supposes real-time monitoring, data-driven decision, sense-mak-ing and situation understanding under time-critical requirement. A key element of real-timedecision support systems would be a continuous process of contextualization, decontextualiza-tion and recontextualization (CDR). This supposes, first, to use a formalism allowing auniform representation of knowledge, reasoning and context, and, second, an IntelligentAssistant System with powerful functions for exploiting such a representation, especially formobile systems dealing with environments where unpredicted events are the norm rather thanthe exception.
2.2. The CDR process
The problem of decision-making reuses can be explained in the light of the well-known ambi-guity between procedures and practices (Brézillon, 2007), task and activity (Leplat & Hoc,1983), logic of functioning and logic of use (Richard, 1983), etc. Indeed, such ambiguitiesdepend on the consideration that the actor realises a task in a particular situation with theavailable resources in the local environment. In this paper, we interpret ambiguities by con-sidering how context intervenes in real-time problems.
A procedure is a decontextualized translation of a task realisation at the operational level.The translation takes into account task realisation and the constraints imposed by the logic offunctioning at the strategic level. In this section, we sum up the discussion held in Brézillon(2011) on procedures and practices, and, after, we defend the idea that, focusing on practicesrather than procedures, we must consider activity management rather than task realisation.
The head of a company specifies a procedure to cover a large class of similar tasks in adecontextualized way. A procedure expresses a compromise between policy/strategy of thecompany and operationalization of a task realisation. For example, Pomerol et al. (2002) pres-ent an application on the subway in Paris where most procedures are imposed either to maketrains empty of travelers before incident solving or to do cut-off power supply if somethinghappens on the tracks. Such procedures correspond to a strong policy at the subwaycompany: Traveler safety is mandatory.
A practice is the way in which an actor adapts a (company) procedure relying on his pref-erences, the particularities of the task, the situation and the local environment where resourcesare available. The practice emerges from a contextualization process of a procedure, and isthe operational expression of the activity developed by an actor during task realisation in a
30 P. Brézillon and A. Aroua
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
given context. As a consequence, there are as many practices (or activities) as actors andcontexts for a given procedure (i.e. for a given task realisation). The important point is thatpractices are developed to integrate the effective task realisation, not what is supposed tohappen (prescribed task). This is particularly important when the local environment is highlyvariable, as in mobile decision.
3. Contextual-Graph representation
3.1. Dynamics of context
Context is related to a focus, the actor, the task realisation, the situation, and the local envi-ronment. Thus, context cannot be considered in an abstract way. The context constrains whatmust be done in the current focus without appearing in it explicitly (Brézillon & Pomerol,1999). The focus determines in the context what is contextual knowledge and external knowl-edge at a given moment. At any step of the focus, some contextual elements are consideredexplicitly, say, for the choice of a method in the task realisation. These contextual elementsare collected, organized and structured according to the focus, and thus can be considered asa part of the way in which the problem is solved at the considered step. This ‘proceduralizedcontext’ is a context-specific model progressively built during the practice development. It isimportant to note that the context-specific model of an item in the contextual graph isconstant (an ordered series of instantiated contextual elements), but the context-specific modelof the practice development evolves dynamically, some contextual elements entering theproceduralized context and leaving it once the corresponding action is executed.
During the practice development, the focus crosses a series of contextual elements (CEs)and actions to execute. With the dynamics of the focus, there is a dynamics of the workingcontext (i.e. the set of contextual elements and their known values as well as the currentinstantiations of the contextual elements): The focus and its context are intertwined. Thus, thefrontier between external and contextual knowledge is porous and evolves with the progressof the focus.
3.2. The Contextual-Graphs formalism
A context-based reasoning has two continuous interlocked parts, namely diagnosis and action.The diagnosis part analyses the situation at hand and its context in order to extract the essen-tial facts for the actions. Actions are undertaken in a foreseen order to realise the desired task.Sometimes, actions are undertaken even if the situation is not completely analysed (or evennot analysed at all). Other actions are carried out before the proceduralisation of a part of thecontextual knowledge.
Contextual graphs (CxGs) are acyclic due to the time-directed representation and guaran-tee algorithm termination. Each contextual graph (and any activity in it) has exactly one rootand one end node because the decision-making process starts in a state of affairs and ends inanother state of affairs (not necessarily with a unique solution on all the paths) and thebranches express only different contextually-dependent ways to achieve this goal. A contex-tual graph represents a task realisation, and the paths the different practices developed byactors for realising the task. There are as many paths as practices known by the system.
Among the four elements of a contextual graph (Brézillon, 2007), we focus here onactions and contextual elements. An action is the building block of contextual graphs at thechosen granularity of the representation. A contextual element is a pair of nodes, a contextualnode and a recombination node; a contextual node has one input and N exclusive branches
Journal of Decision Systems 31
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
corresponding to the N known values of the contextual element (considered as exclusivevalues leading to different alternative methods). The recombination node is [N, 1] andrepresents the moment at which the instantiation of the contextual element does not matteranymore and branches can be merged. Sources of contextual elements are very diversified:the actor, the task to be realised, the situation in which the task is realised by the actor, andthe local environment. A particular problem solving (an actor, a task, a situation and a localenvironment) corresponds to a set of selected values of the contextual elements calledinstantiations. This means that real-time decision-making requires considering, with thecontextual graph, its working context, which is a representation of the mobility impact ondecision-making.
In the CxG formalism, contextual elements (CEs) represent diagnosis. When a contextualnode is encountered on a path, an element of the situation is analysed in real time. Its currentvalue (the instantiation) is taken into account as long as the situation is analysed. Once thecorresponding action is executed, the instantiation does not matter in the line of reasoning,and the different branches corresponding to the exclusive values of the contextual elementcan be merged together again at the recombination node. Thus, the CxG formalism allows awide range of diagnosis/action items for a given task realisation.
3.3. Practices in the Contextual-Graphs formalism
A contextual graph corresponds to an organization of practices that have been built for a taskrealisation. For this reason, a contextual graph is assimilated to a base of all the experiencesof actors with the task realisation. This experience base represents an important step from theprevious knowledge bases: The latter were represented in a flat way, and the former in astructured way. This supposes that a system exploiting contextual graphs as an experiencebase must possess some functionality that was not necessary for past expert systems.
Figure 1 gives a contextual-graph representation of a task realisation. Circles (1 and 2)represent contextual elements (CEs) with exclusive values V1.1 or V1.2, V2.1 or V2.2.Square boxes represent actions (the components in a SWF), the building blocks at the chosengranularity of the representation. There are three paths representing three different practicesfor realising the task. For example, in a working context where Contextual Element 1 isinstantiated to V1.2, the activity corresponds to the execution of Action 6. Thus,
Figure 1. Task realisation and activity in a contextual graph representation.
32 P. Brézillon and A. Aroua
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
contextual-element instantiation only matters when the focus during the development of apractice arrives on this contextual element. In Figure 1, because the instantiation of Contex-tual Element 1 is V1.2, the other contextual element, 2, and its instantiation are not consid-ered in the practice development (leading to the execution of Action 6 in Figure 1). Thismeans that contextual-element instantiation can be done only in real-time conditions. We call‘working context’ the set of all the contextual elements (1 and 2 in Figure 1) and theirinstantiations, i.e. the chosen values at the observation time.
4. Intelligent Assistant Systems for managing CxG-based simulation
4.1. Simulation of practice development
Intelligent assistant systems (IASs) represent a generation after expert systems. Both build aspecific situation model of the task realisation in a specific context. However, an IAS uses astructured representation of practices as a contextual graph. Each path in a contextual graphcorresponds to the development of a practice by an actor for realising a task in a specificworking context. This supposes the possibility to ‘simulate’ a practice development in twoways, first, for analysing (browsing) a practice development with its alternatives, and, second,for simulating the actor’s behavior and action execution.
An IAS works on a contextual graph and a working context. The IAS needs severalmechanisms, like a browser to explore the experience base, a simulator of practice develop-ment, a learner for acquiring new practices, and an explainer for presenting the rationalbehind a practice. Consider the example of choosing a recipe in a cookbook as a task realisa-tion. Browsing is the reading of the recipe and its variants in the cookbook, simulation corre-sponds to the activity of a person preparing ingredients from the recipe at home according toan initial context (his taste, guests, social importance of the meal, available ingredients,equipment, etc.), and learning is, for example, the writing of comments of the guests’feedback on the dish (cooking, taste, salty or not, etc.).
Browsing and simulation are quite different with respect to the time dimension in thedecision-making process. A CxG browser works at a qualitative level where the temporaldimension is not considered explicitly (e.g. duration of an action and loop of a routine actiondo not matter) because browsing concerns an abstracted way in which all values of acontextual element are considered at the same level (e.g. the cookbook or any user manual).The focus is more on the realisability of the task than its effective realisation.
A CxG simulator is time-dependent (a contextual graph is a directed acyclic graph). Thetime dependency appears because (1) an unpredicted event may modify the instantiation of acontextual element in the working context, (2) the duration of actions must be taken intoconsideration in the decision-making process, or (3) the execution of an action may lead to achange of CE instantiation. A CxG-based simulation corresponds to the progressive buildingof a practice corresponding to the working context.
4.2. Contextual Graph-based simulation
A procedure cannot be applied directly because its development requires the instantiation ofcontextual elements in the working context. A practice (developed by an actor) is a contextu-alization of the procedure, i.e. the building of a context-specific model (or proceduralizedcontext) during practice development.
A CxG-based simulation supposes the instantiation of contextual elements and theexecution of actions. The working context may evolve due to action execution during practicedevelopment. The execution of an action may lead to a change of instantiation of a contextual
Journal of Decision Systems 33
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
element. In the recipe example, the ‘chef’ may decide to replace pepper that is missing in thekitchen by paprika if the chef is in a hurry or, otherwise, s/he goes out and buys pepper. Thechange of working context may lead the IAS to re-evaluate the current CxG-based simulation:(1) The simulation must be restarted in the new working context and a new practice will bedeveloped; (2) A routine action must be executed several times; and (3) The CE with a modi-fied instantiation has not yet been met during the current practice development and thechange of working context concerns only practice development.
In the last option, the simulation can be pursued because the divergence between thepractice under development and the future practice is not yet met. The CxG Simulator is atool at the tactical or operational level that takes into account the specificity of the workingcontext to find the best practice. Its two main functions are context management and actionmanagement.
4.3. Context management
Contextual elements allow the management of alternatives (e.g. different methods) for theaccomplishment of a part of the task realisation. An alternative corresponds to a given valuetaken by a contextual element in the working context. A contextual element, CE°, has asmany (qualitative or quantitative) values as known alternatives:
Value (CE°) =V1°, V2°, V3°, etc.
Arriving at a contextual element, the IAS looks for the CE instantiation in the workingcontext to select the right action to execute. The instantiation can be: (1) known prior to thedevelopment of the practice, (2) provided by the actor during the practice development, and(3) found by the system in the local environment for mobile decision-making.
In the example given in Figure 1, the working context will be defined by the list ofcontextual elements:
Contextual element 1
Values: V1.1, V1.2
Instantiation: V1.2
Contextual element 2
Values: V2.1, V2.2
Instantiation: N/A
During a CxG-based simulation, the contextual element instantiation may be altered byeither an external event or an internal event. The external event corresponds to an unpredict-ed event, i.e. not represented in the contextual graph. For example, an external resourcestops being available, like GPS functioning that stops when the car enters a tunnel. An inter-nal event occurs as the result of an action execution. For example, the user arrives in aplace where he did not know that a friend was present and changes his mind about his cur-rent action to having a drink with his friend in a bar. The change of instantiation implies achange of the working context. The IAS has two options for reacting to a change of theworking context. First, the altered instantiation concerns a contextual element already treated;the IAS must decide (1) to stop the development of the current practice and restart the simu-lation; (2) to redo the part of the practice concerned (e.g. for a routine action); or (3) to fin-ish the development of the practice at hand and then analyse the need for a new simulation.
34 P. Brézillon and A. Aroua
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
In the second option, the new instantiation concerns a contextual element not yet crossed bythe focus, and the IAS can continue its simulation to progress in the contextual graph.Except for routine action, the IAS will have to interact with the actor to make a decision onthe strategy to apply. Different options are represented in Figure 2 in a contextual-graph rep-resentation.
When monitoring a CxG-based simulation, the IAS that arrives at a contextual elementmust check the status of the instantiation and choose to continue the CxG-based simulationor not. The fact that a change of the working context may come from the execution of anaction, supposes that the IAS must also have (1) a module for action management, and (2) a‘personal experience base’ for detecting changes in the working context.
4.4. Action management
The IAS needs a module for Action Management that gives an abstracted representation ofthe action execution at a finer granularity than the CxG representation (e.g. execution of anexternal program or service). The CxG simulator must take into account the effects of theaction execution on the practice development. According to the feedback on the action execu-tion (a stop, a context change, etc.), the IAS has to make a decision on the consequences forthe CxG-based simulation at hand. For example, if action execution modifies the instantiationof a contextual element, the IAS must check the position of this contextual element withrespect to the current position of the focus on the practice development. The CE may be on apart of the practice already developed or in the ‘future’ of the practice development.
Beforehand, the IAS has to determine if the action is passive or active. A passive actionprovides only information (something to note or record) and has no impact on the simulation.The execution of an active action, which is triggered by the IAS, may impact practicedevelopment in the following ways:
Figure 2. A representation of context management as a contextual graph.
Journal of Decision Systems 35
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
• Start the execution of an external program (e.g. leave the street and enter the baker’sshop to buy bread) and thus the IAS must interrupt the simulation until the completionof the action execution;
• Abandon the practice development because it is worth continuing the task realisation(e.g. going to the hairdresser, abandon because too many people are already waiting);
• Wait during the action-execution duration that constrains the progress of the simulation(e.g. stop at the station to fill the gas tank);
• May depend on an external event (e.g. entering a tunnel stops GPS);• Must be repeated several times as a part of the global task realisation (e.g. we are
monitoring continuously other drivers’ behaviors on a highway);• May be ‘frozen’ by the lack of a resource produced by another action (e.g. waiting for
the end of a file download before uploading a picture).
In all these options, time plays a central role. Actions are domain dependent, but we proposeto model action execution from abstracted characteristics that could be challenging for thesimulation, such as duration, effect, dependency upon other actions, dependency upon actors,consequences on the simulation, etc.
Thus, the IAS will use an action model to monitor the experience base. A possiblemodeling of action management as a contextual graph is represented in Figure 3.
The outputs of the action-management module (e.g. the alerts to the IAS) are recorded inthe working context that is managed by the IAS, which will decide to end the simulation orcall for the context-management module.
4.5. Working-context management
The working context meets contextual elements contained in the contextual graph and theirinstantiations. The working context is associated with the simulation. The instantiations areknown prior the simulation or asked of the actor when the IAS focus arrives on a contextual
Figure 3. A Representation of the IAS module ‘Action Management’.
36 P. Brézillon and A. Aroua
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
element that is not instantiated. In the latter situation, the IAS must stop and ask the actor thecurrent value of the contextual element. A third option is a change of a contextual-elementinstantiation due to an action execution. This modifies the working context and may affectthe simulation if the development of the practice at hand is concerned by this change.
Working-context management is a task of the IAS for managing its interaction withactors, information received from external sources, the impact of action on the practicedevelopment, and the simulation itself.
5. Application to the workflow manager
5.1. Origin
TheMICO project aims to improve breast cancer diagnosis quality. An actor called an anatomo-cyto-pathologist (ACP) makes a diagnosis based on patient information and examination results(i.e. a practice development). The diagnosis relies on an examination of whole slide images(WSIs) on which many shapes (representing some type of cells or nuclei) are searched. Theanalysis provides information that is collected and annotated by the ACP during the practicedevelopment, like score counting, that participates in the definition of cancer grade.
IPAL (Image & Pervasive Access Labs, one partner of the MICO project) developsimage-processing programs for automating score counting practice. IPAL organizes programswith a workflow manager (see Figure 4) for monitoring and controlling program execution.The workflowmanager and the different programs are installed on the platform Calopix ofTRIBVN (another partner of the MICO project) as a platform between theACP and the imag-ing programs. In this paper, we discuss the representation as a contextual graph and the simu-lation of the workflow manager (our task realisation).
5.2. Description of the workflow manager
The flowmanagermonitors the computing-scoreworkflow from aWSI. The computing scoreworkflow is a series of programs (i.e. the components of the workflow). Each programrealises an elementary task such as sampling (Frame_Sampler) that decomposes a Region ofAnalysis (ROA) and returns the list of frames in the ROA. Theworkflowmanager is ascheduler that ensures the selection and coordination of the programs for the given task,which are monitored through their inputs/outputs.
Figure 4. The Workflow Manager and programs designed by IPAL.
Journal of Decision Systems 37
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
The workflow manager is responsible for the automated part of the process, although thehuman actor keeps global control, especially of aspects that cannot be determined in advancebecause there are too many contextual elements to consider. The actor intervenes when deci-sion-making is required, for example, for the selection of a score-computing method (differentmethods are: the mitotic score, the cyto-nuclear atypicality score, the architecture score)according to the actor’s focus.
Figure 4 shows the workflow manager where boxes represent programs and arrowsbetween boxes represent inputs and outputs of programs. The rules associated with programs(written under the boxes) define how to use the programs.
The inputs of the computing-scoreworkflow are the request for score computing and theidentification of a RegionOf Interest (ROI). The ACP provides the tumor territory as a ROI(see Figure 5). The ROI is identified by a polygon drawn on the WSI. The program,‘ROA_Extractor’, extracts Regions Of Analysis (ROAs) in the ROI as a set of frames. The‘Frame_Sampler’ retrieves the list of the frames in the ROA.
Once the list of ROA frames is known, the ‘Frame_Selector’ selects the most relevantframes to analyse according to some criteria. These criteria are represented as rules that corre-spond to ACP’s expectations for detecting mitosis. The ‘Pattern_Detector detects patterns thatare the shapes to search (e.g. mitosis). Finally, the ‘Frame_Scoring’ computes a score for eachframe. Because there are several frames, the operations ‘Frame_Selector’, ‘Pattern_Detector’,and ‘Frame_Scoring’ are grouped into the routine action ‘Dynamic Sampling explorer’ that isused in a cyclic way. The output of the workflow is the global score computed from thedensity map that depends on the score computing method chosen.
At this step of the MICO project, we consider only test medical cases for testing modulefunctionality on two score-computing methods, but the number of score-computing methodsdoes not matter and can be added incrementally. Score computing is made by different meth-ods managed by programs, and the workflow manager only has an abstracted representationto it.
Figure 5. Tumoral territories drawn at La Pitié Hospital on a WSI using the Calopix Framework ofTRIBVN.
38 P. Brézillon and A. Aroua
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
5.3. CxG representation of the workflow manager
Figure 6 shows the CxG representation of the workflow manager given in Figure 4. The leftpart of Figure 6 gives the graphical presentation of the Workflow Manager, the middle partgives its legends and the right part shows the content of the activity ‘ROA_Extractor’(numbered 5 in the complete graph).
For mitotic score, a program is run and returns the ROA; otherwise the ROI is the wholeROA. With the play of activities being embedded one in another (e.g. Activities 14, 20, 26are inside Activity 13), the IAS, which exploits the contextual graph, also monitors the actionprocessing. For example, Action 33 (in Figure 6, middle part) specifies the number of itera-tions of the routine activity ‘Dynamic Sampling explorer’ that is composed of the programs‘Frame_Selector’, ‘Pattern_Detector’ and ‘Frame_Scoring’ (see Figures 4 and 6). This numbercan be defined either in a hard way, e.g. a passive action in the contextual graph that modifiesthe instantiation of the contextual element ‘iteration number’ in the working context, or by aquestion to the ACP when the focus is on this action (with some alteration of the workingcontext), or as a contextual element in the working context.
The engineer’s focus is on the assembling of the workflow components, i.e. the modelingof the engineer’s decision-making on image analysis, not the specific problem of the ACP thatis the identification of mitosis. In this viewpoint, the flow manager will require ACP’s supportwhen needed. In Figure 6, Activity 13 representing ‘Dynamic Sampling explorer’ first orga-nizes the components ‘Frame_Selector’, ‘Pattern_Detector’ and ‘Frame_Scoring’, and, second,asks the ACP to differentiate ‘mitotic score’ and ‘CNA score’ for monitoring the cycle accord-ing to the ACP’s focus. The advantage of such a representation is its reuse because it is easierto add new score computing methods: it is equivalent to adding a branch in the contextualgraph. The series of programs corresponding to this method are represented as activities.
5.4. Discussion
The contextual-graph representation of the workflow manager puts in the front stage severalimportant findings:
Figure 6. CxG representation of the Workflow Manager Graph in Figure 1.
Journal of Decision Systems 39
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
• It is important to avoid the mixing of different types of knowledge such as domainknowledge, engineer knowledge and implementation knowledge. For example, theACP is not concerned with the technical details of the workflow manager, which arethe engineer’s responsibility. Distinguishing these three types of knowledge leads oneto consider the problem at the right level and understand that any representation ismade to address a question. The same problem from the ACP’s viewpoint will necessi-tate another representation.
• The CxG representation is made at a higher granularity than usual workflow manage-ment. Indeed, a contextual graph allows the representation of the real-time buildingand use of the workflow, thanks to a user-oriented modelling of actions (the programsin the flow manager).
• For interacting intelligently with an actor who is an expert in his domain, the IAS, onthe one hand, must adhere to the expert’s viewpoint (through the experience base),and, on the other hand, make explicit needed tools that are required for the manage-ment of context, actions, the contextual graph, learning, explanations, etc. We areworking on such IAS architecture (see Figure 7). The key point here is that all theknowledge and expertise of the domain are only in the contextual graph and the work-ing context, and thus the IAS architecture is domain-independent.
6. Conclusion
Our goal is to develop a decision support system for users who have a high level of expertisein a domain not well known or too complex. Their expertise is composed of chunks of con-textual knowledge built mainly by experience under a compiled expression. The decision-making process uses this expertise to propose critical and definitive decisions. In the MICOproject, the expert is an anatomo-cyto-pathologist who analyses digital slides (coming frombiopsies) to diagnose if a patient in a surgery has or does not have breast cancer.
Figure 7. Proposed architecture for the IAS (the shadowed part represents the work realised for theMICO project and presented in this paper).
40 P. Brézillon and A. Aroua
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
The consequences are:
(1) The decision support system must behave as an intelligent assistant, following whatthe expert is doing and how s/he is doing it, anticipating potential needs and issues.This supposes that the system possesses a representation of experts’ reasoning. TheIAS must be able to solve alone simple problems and prepare complete folders oncomplex situations for the expert.
(2) For working on practices developed by the experts, the IAS must be aware of all thecontextual elements and alternative actions used by experts during practice develop-ment, contextual-element instantiation and eventual changes. The line of reasoning ofthe system is drawn from lines of experts’ reasoning described in a contextual graph,which gives a strong user-centered representation of the domain and task realisation(Brézillon, 2003).
(3) The decision support system must be able to develop the decision-making process inreal time to analyse the association diagnosis and action built by experts during theirreasoning (Brézillon & Pomerol, 2010). Indeed, the IAS simultaneously develops thedecision-making process and the context-specific model of this process.
(4) The decision-making process being highly contextual, the decision support systemmust benefit from its interaction with the expert to learn new practices by acquiringmissing knowledge incrementally and learning new practices, and thus enriching itsexperience base.
(5) Making context explicit in the experience base leads to the possibility to generaterelevant explanations for:
(6) Presenting the rationale behind a practice with the alternatives abandoned;(7) Training (future) experts on the different practices developed;(8) Facilitating experience sharing among experts in a kind of dynamic corporate
memory;(9) Allowing a first step towards the certification of their protocol.
(10) The main tool of an intelligent assistant system for working in real-time conditionsis the CxG-based simulator, thanks to a uniform representation of elements of knowl-edge, reasoning and contexts. Its originality is to develop at the same time the prac-tice and its execution. Indeed the CxG-based simulator is the key element of real-time decision-making because it is possible to account for unpredicted events, thankto an explicit modeling of context as contextual elements covering the user, the taskrealisation, the working situation, the local environment with its available resourcesand, thus, any change in one of these items. All the items are interdependent andtime-dependent. Thus, intelligent assistant systems cover a more general problematicthan context-aware applications. This seems to us the key point for mobile decision-making because mobility is considered in our approach by the play of the instantia-tions of contextual elements (the actor, the task, the situation, the environment) thatare related to mobility at any moment it is necessary and their processing by theIAS.
AcknowledgementsThis work is supported by grants from ANR TecSan for the MICO project (ANR-10-TECS-015), andwe thank our partners (IPAL, TRIBVN, Service d’Anatomie Cytologie Pathologie at La Pitié, Thalèsand Agfa) for fruitful discussions.
Journal of Decision Systems 41
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
ReferencesBrézillon, P. (2003). Focusing on context in human-centered computing. IEEE Intelligent Systems, 18
(3), 62–66.Brézillon, P. (2007). Context modeling: Task model and model of practices. In B. Kokinov, et al. (Eds.),
Modeling and Using Context (CONTEXT-07), LNAI 4635 (pp. 122–135). Heildelberg: SpringerVerlag.
Brézillon, P. (2011). Contextualization of scientific workflows. In M. Beigl et al. (Eds.), Modeling andUsing Context (CONTEXT-11), (pp. 40–53) LNAI 6967. Springer, Heidelberg: Springer-Verlag.
Brézillon, P. (2012). Modeling activity management instead of task realisation. In A. Recipio & F.Burstien (Eds.), Fusing DSS into the Fabric of the Context (pp. 51–62). Amsterdam: IOS Press.
Brézillon, P., & Pomerol, J.-C.h. (1999). Contextual knowledge sharing and cooperation in intelligentassistant systems. Le Travail Humain, 62(3), 223–246.
Brézillon, P., & Pomerol, J.-C.h. (2010). Framing decision making at two levels. In A. Respicio, et al.(Eds.), Bridging the Socio-Technical Gap in Decision Support Systems. Challenges for the next Dec-ade (pp. 358–368). Amsterdam: IOS Press.
Burstein, F., Brézillon, P., & Zaslavsky, A., Eds. (2008). Supporting Real Time Decision-Making. Annalsof Information Systems, 13. Springer.
Carton, F., Adam F. & Brézillon, P. (2008). Why real time transaction processingfails to capture thecontext required for decision support. Proceedings of the SIG DSS Pre-ICIS Workshop on RealTime Decision Support - RTDMC 2008.
Clancey, W.J., Sierhuis, M., & Seah, C. (2009). Workflow agents versus expert systems: Problemsolving methods in work systems design. Artificial Intelligence for Engineering Design, Analysisand Manufacturing, 23, 357–371.
Deelman, E & Chervenak, A.L. (2008). Data Management Challenges of Data-Intensive ScientificWorkflows. Proc. of the 8th IEEE International Symposium on Cluster Computing and the Grid(CCGrid’08), (pp. 687–692), IEEE CS Press.
Fan, X., Zhang, R., Li, L., & Brézillon, P. (2011). Contextualizing workflow in cooperative design.Proceedings of the 15th International Conference on Computer Supported Cooperative Work inDesign (CSCWD-11), Lausanne, Switzerland, 17–22.
Leplat, J., & Hoc, J.-M. (1983). Tâche et activité dans l'analyse psychologique des situations. Cahiersde Psychologie Cognitive, 3, 49–63.
Masters, M., & Welch, L.R. (2008). Challenges for Building Complex Real-time Computing Systems’,retrieved from http://www.nitrd.gov/subcommittee/sdp/ vanderbilt/ position_papers/michael_mas-ters_challenges_for_building.pdf.
Pomerol, J.-C.h., Brézillon, P., & Pasquier, L. (2002). Operational knowledge representation for practicaldecision making. Journal of Management Information Systems, 18(4), 101–116.
Power, D. (2008). Challenges of real-time decision support. Proceedings of the SIG DSS Pre-ICISWorkshop on Real Time Decision Support - RTDMC 2008.
Richard, J.-F. (1983). Logique du fonctionnement et logique de l'utilisation. Rapport de RechercheINRIA No 202.
42 P. Brézillon and A. Aroua
Dow
nloa
ded
by [
Upp
sala
uni
vers
itets
bibl
iote
k] a
t 02:
12 1
1 O
ctob
er 2
014
