Knowledge-Based Front-Ends as Games - CiteSeerX

Knowledge-Based Front-Ends as Games Kostas Stathis and Marek Sergot Department of Computing, Imperial College of Science, Technology and Medicine, 180 Queen's Gate, LONDON SW7 2BZ, UK Email: fks,[email protected] Tel: +44-(0)171-594-8218 Fax: +44-(0)171{589-1552

Abstract: We present a framework for building complex interactive systems from simple

components, with particular attention to the development of Knowledge-Based FrontEnds to software packages. The work is motivated from problems with the interactions of GLIMPSE 21] and FAST 14], two Knowledge-Based Front-Ends developed using logic programming tools and techniques. To avoid the pitfalls of GLIMPSE and FAST but to keep their characteristic features, we view interaction as a rule governed activity which may be usefully regarded as a game 18]. Given a specication of the rules, implementation of the Knowledge-Based Front-End requires the construction of an umpire, a component that enforces compliance of the players with the rules and thereby controls the interaction. Advice giving components added to the system are analogous to games played in the presence of an advisor who recommends moves to the participants. We also investigate how to customise existing games by studying how to expand and lter their moves. More generally, we examine how to develop compound games built up from sub-games coordination of moves chosen from sub-games is then a key issue. This is resolved by treating sub-games as active components that communicate the results of interactions from subgames to more complex games illustrated by examples from LAST, a reconstruction of the GLIMPSE and FAST systems in the game-playing framework.

Keywords: Knowledge-Based Front-Ends, Query-the-User, Transition Rules, Games.

1 Introduction

Computers that enable users to interact with other computers and users are becoming increasingly more popular. Novel applications suggest that computing machines are not simply number crunching devices but in fact can take part and manage processes by which people and machines can exchange and share information irrespectively of their position in a network. In fact, a number of enabling technologies facilitate the connection between humans and machines and support in practice their graceful interactions. Such technologies further encourage the construction of complex interactive systems from existing components, where existing functionality is aggregated from interaction and communication of the parts to form the more complex whole. 1

A characteristic example of complex interactive systems built from simpler components is the development of Knowledge-Based Front-Ends (KBFEs) to software packages. A frontend to a software package (or back-end (BE)) is designed principally to make the package easier to use and to extend the facilities provided by it. Knowledge-Based Front-Ends (KBFEs) are front-ends that contain explicitly represented knowledge about the package and its domain 4]. They can therefore oer to a user advice on the system in general, and how to use the system in certain situations in particular. More generally, KBFEs have the potential of interfacing more than one software packages in one system. In this way, building KBFEs does not only increase the lifetime of a software but can also make it useful in a wider context, by making it available to a broader class of users. Nevertheless, to combine dierent packages in a complex whole involves, in general, the composition of heterogeneous BEs and their command languages. As a result, the graceful interoperation of the resulting system is not a trivial problem in practice. The aim of this work is to analyse and reuse the lessons learned from the development of GLIMPSE 21] and FAST 14], two Knowledge-Based Front-End systems developed using logic programming tools and techniques. To present the lessons learned from developing these two systems, we analyse their problems and we concentrate on the choices made to design, specify and implement the interactions between the user and system components. The purpose of the analysis is twofold. Firstly, to point out how certain assumptions made in building GLIMPSE and FAST have aected the future development of these systems. Secondly, to show how the pitfalls of both GLIMPSE and FAST motivate a new framework for developing KBFEs as games. This framework is particularly appealing in that it supports the development of complex interactions characteristic of GLIMPSE and FAST. After this introduction, the paper is organised as follows. In Section 2 we discuss the main features of the GLIMPSE system followed by the analysis of its development and interaction problems. Some of these problems are addressed in Section 3, where we present the main features of FAST. An analysis of the FAST development, however, introduces new problems which together with the problems of GLIMPSE are addressed in Section 4 where we discuss the relation of KBFEs and games. To exemplify the application of games in KBFES we show in Section 5 how to use games to build LAST 18], a new system intended as a reconstruction of GLIMPSE and FAST. A general knowledge representation framework for games is presented in Section 6. This game-playing framework is extended in Section 7 for more complex, compound games including the games used to develop LAST. We conclude the presentation of our work in Section 8.

2 The GLIMPSE system

GLIMPSE 21, 20] is the result of a collaborative research project whose primary objectives were to investigate the feasibility of using logic programming tools and techniques, modied and extended as necessary, to develop front-end systems to software packages, and, by way of demonstration to develop a front-end to the package GLIM version 3.77 10]. 2.1 Tasks Interaction between the user and the back-end in GLIMPSE is organised in terms of tasks . These combine one or more GLIM commands into higher level actions. For example, to enter a vector in GLIM the appropriate command must be specied by the user as: $data 5 v1$read 1 2 3 4 5.

2

To achieve the same result in GLIMPSE one had to use the task language and supply the task: enter vector v1 = (1 2 3 4 5).

Tasks are translated to GLIM commands by a system component called the translator . This component contains explicit descriptions of tasks in terms of the checks, results and the actions required if the task succeeds. For example, in the case of entering a vector the checks guarantee that the name of the vector and the values are valid, the result is the length of the vector and the actions execute the back-end to enter the vector and assert the name and the values in the knowledge-base (KB) of the front-end. The following program summarises the steps of the translator in this case: do task( Task ):checks and results(Task, Checks, Results), (succeed(Checks) -> necessary actions(Task, Results, Acts), do actions(Acts) explain failure(Checks)).

If the checks of the task fail, GLIMPSE can provide an explanation of failure 20]. 2.2 Activities The main characteristic of the back-end GLIM is that it requires from the KBFE to handle interactions with the user that are multi-stage . This mode of working required from the front-end that the output obtained from user interactions at one stage to be fed back to the system as input to the next. To reect these dierent stages of the statistical analysis, tasks in GLIMPSE are grouped into activities , some of which are shown in Figure 1(a). DV

DI

DD DI

DE DV (a)

DI>>enter vector v1=(1 2 3 4 5) DI>>move DD DD>>type count (v1) DD>>move DI DI>>read file "experiments/data1" (b)

Does the graph: log((y+0.5)/n) vs x confirms that a pattern exists? [yes,no,explain,suggest] >>suggest find pattern log((y+0.5)/n) vs x pattern 3.465 with 4 points answer: yes, pattern exists [accept,reject,answer,explain] >>accept (c)

Figure 1: GLIMPSE Activities and Dialogues For example, the task of entering a new vector or the task of reading a set of vectors from a le both belong to the data input (DI) activity. Similarly, the tasks of dening the values of a vector and relating statistically their values belong to the data denition (DD) activity. Other activities in GLIMPSE include the data validation (DV) activity which must be successfully completed before mathematical models may be investigated by data exploration (DE), model selection (MS) and model checking (MC) activities. In the course of an analysis the user supplies tasks in a specic activity. The dialogue shown in Figure 1(b) shows a user interleaving activities DI and DD in order to input and dene data. Note that in order to execute a task belonging to a dierent activity the user has to supply explicitly a task to move from one activity to the other. 3

2.3 Advice Facilities GLIMPSE provides advice and help at dierent levels. As an example, consider the dialogue of Figure 1(c) where GLIMPSE advises the user on the statistical strategy of the data exploration (DE) activity. The user is asked about whether a graph (previously presented on the screen and the details of which we omit for simplicity) exhibits an obvious pattern. Unable to answer the question posed by the system the user asks for a suggestion 21]. The system calculates, using the statistical package, a pattern statistic which subsequently changes the state of the KB and enables it to conclude that the graph has a pattern. Once the suggestion is presented, the user accepts the answer and the consultation continues in a non-authoritarian style { suggestions of the system can be overridden by answers of the user. Moreover, advice dialogues are very exible. For example, the user can edit the dialogue and retract the contents of already answered questions. Advice in GLIMPSE is interpreted by APES 9], a logic programming environment based on a Prolog interpreter handling negation, system predicates, and explanation by recording the computation trace. Interaction with the user is further handled by the Querythe-User (QtU) mechanism whereby the user is asked to supply any missing information of a logic program 13] the key assumption is that the facts supplied by the user could in principle be listed in advance, before the interaction. A simplied sketch of the integration of QtU in APES is shown below: interp all( ], ] ):-!. interp all( Goal | Goals], Trace | Traces] ):interp( Goal, Trace ), interp all( Goals, Traces ). interp( not Goal, not Goal ):- !, not interp all( Goal], ). interp( Goal, system(Goal) ):system( Goal ),!, call( Goal ). interp( Goal, user(Goal) ):askable( Goal ),!, query the user( Goal ). interp( Goal, Goal | SubTrace] ):rule( Goal, SubGoals ), interp all( SubGoals, SubTrace ).

Using APES, the application domain is specied as a set of rules that can be amended and added by the programmer who needs not to be concerned with the question of how these rules are interpreted. In other words, logic and control are kept separate in GLIMPSE, thus the maintenance of the KBM is considerably simplied in that modications to the control component are localised 3]. The general form of advice rules in GLIMPSE is: advise action(Task) :- Conditions.

Advice dialogues are generated by querying all solutions of advise action/1 rules using APES to interpret the Conditions. This method produces the right behaviour in that it advises tasks incrementally until all the advise rules are tried. Also, the method has the extra advantage that a strategy can be stopped and resumed at any point because the answers of the user are stored as lemmas { the advice rules are re-interpreted when the 4

strategy is resumed. 2.4 Modications to QtU and APES To interpret advice rules in GLIMPSE the original QtU was changed to treat GLIM as if it was the user. This change, called Query-the-Back-End (QtBE), could in principle be used with any back-end assuming that this system is connected in the same way GLIM was to GLIMPSE. Also, to provide help with tasks, the QtU model had to be further modied. Normally, when a question was asked by QtU the answer was stored as a lemma 13] in the database for later use. In task help, however, if the system stored all the answers supplied by the user, the task advised at one stage would also be advised by the system at the next. To avoid this undesirable behaviour, QtU model was modied to allow answers to certain predicates to be forgotten at the next stage of the interaction. Statistical analysis with GLIM involved reasoning about how and when to nd facts of data sets. The addition of the user in the analysis required that the user should be informed about these new results { the whole point of involving the user in the analysis is to gain new information about the data. More specically, a change due to the user gaining new information required a change of state in the KB of the system. However, QtBE did not recognise this change of state since it assumed (as QtU did) that the software package has available all results at any time. This issue was eventually resolved by splitting the GLIMPSE tasks into nding tasks and setting tasks 20]. Based on this split the suspending interpreter idea was introduced and incorporated into APES 21]. This was a major modication of both the APES interpreter and QtU because execution of tasks are used as a way of nding information missing from the KB. 2.5 Problems with GLIMPSE Although GLIMPSE established a number of useful notions for developing a KBFE, it also hit some hard problems related to the maintenance of the system's KB. For example, in advice interactions a user was allowed to edit previous answers to questions of a dialogue. In this case, if an early answer was deleted by the user, the rest of the answers stored as lemmas had to be deleted by the system since APES did not provide any belief revision/truth maintenance mechanism. However, retracting an earlier reply from the dialogue often implied that the user had to repeat answering the questions already answered, and in most cases, give the same answers all over again. More generally, the development of GLIMPSE raised some serious questions of how to systematically develop KBFEs. At the end of the project APES developed into a complex system. For example, modications such as the suspending interpreter, although suciently high-level, were inappropriate for the kind of conceptual model provided by QtU. These modications involved interactions that required changes of state, where information could not all be listed in advance, as QtU assumed, but they were instead dependent on the current state. Moreover, problems with a tty-based interface and difculties with porting and reconguring the system begged for a dierent approach of developing KBFEs.

3 The FAST System

Problems with GLIMPSE motivated FOCUS 8], a new research and development project aiming to build generic tools for building KBFEs. In this new project, parts of GLIMPSE were reconstructed in the FAST system 14, 15]. This new system aimed at providing an alternative model for state-based interactions and provide a more structured, graphical 5

user interface for GLIMPSE. 3.1 The FOCUS Architecture The building of FAST is based on the FOCUS architecture 5] shown in Figure 2. A BE in FOCUS is, as in GLIMPSE, an existing software system requiring non-trivial extensions. The dierence with GLIMPSE, however, is that a BE is not not simply a numerical or graphical packages but can also include software libraries. An assumption made here is that normally a BE would be easily accessible, for example, in the case of an interactive package through a command language or in the case of a library through a procedure call. Moreover, in FOCUS, many BEs can be combined together. For this purpose, FOCUS introduces a Back-end Manager (BEM) to control the compositions of one or more heterogeneous BEs. More specically, the BEM provides a variety of tools that makes the composition easier and a data manager (DM) that stores and manages data in dierent forms. D I S P L A Y

HARNESS

KBM

KBM

COMMUNICATION MANAGER

BACK-END MANAGER DATA MANAGER

BE BE

. . .

. . .

BE

. . .

KBM

Figure 2: The FOCUS architecture for a KBFE Another component of FOCUS is a Knowledge-Based Module (KBM), a Prolog database specifying the knowledge component of the KBFE. A KBM would typically contain explicit domain knowledge about the correct use of packages residing in the BEM. Again, unlike GLIMPSE, more than one KBM can be combined composition is achieved by having the components to interact. Interaction is coordinated by the Harness, a tool that mediates the communication between the user and the other system components at the physical level. Operations of the Harness include: starting and stopping individual components, manage resources, take appropriate action if failure is detected, deliver all the communication messages sent by the various components. Messages to the user are actually delivered in the display of the system by using a presentation module. Moreover, the Harness allows the building of KBFEs whose components may reside at dierent physical locations in a network. Components (ie. KBM, USER, BEM) communicate by sending and receiving messages that are Prolog terms. In this way, FOCUS supports the construction of systems whose components are loosely coupled thus making a KBFE system easier to recongure. 3.2 Interface Organisation of FAST Tasks in FAST are organised around a control panel Figure 3(a) shows the panel of the complete prototype. Items of the panel correspond to classes of KB objects like les, vectors etc. When the user clicks on a panel item, the system generates a menu of options, the menus present operators of tasks. For example, the operator corresponding to the task `read a le' is read and if chosen the system displays the interface object shown in Figure 3(b). To classify and provide context for tasks, FAST reuses the activities of GLIMPSE. However, FAST is built on a dierent activity network than that of GLIMPSE presented in 6

save/load/exit.. define/type/associate/.. invalidate remove plot/find/.. DD validate

(a) DA set entry

invalidate

set

memo DV

DE

unset read/enter DI

generate/replace/..

(b)

(c)

Figure 3: FAST Dialogues and Activities Figure 3(c). A new activity called data analysis (DA) includes the activities DI, DD, DV and DE as sub-activities. General tasks, like for example saving a session, fall naturally within DA. Moreover, DA contains transition tasks that allow users to move from one sub-activity to another and thus specialise the context provided by DA in consequence. In Figure 3(c), operators of transition tasks label the moves between nodes of the activity network. In this way, a user interleaves activities in FAST by supplying transition tasks and does not need to specify explicit moves as in GLIMPSE 14]. 3.3 FAST Interactions To avoid the problems of QtU with state-based dialogues, messages received in the KBM of FAST trigger the dialogue manager. This is a nite automaton based on state transitions { messages in this model are treated as if they are parts of events that change the global state of the system. Along these lines, the dialog manager is dened as: dialog manager( Event ):state( State ), transition( State, Event, Reply, NewState ), communicate( Reply ), move to( NewState ).

The State in the dialogue manager contains a list of labels that summarise the dialogue. The labels typically describe information about interface objects, the interaction mode, the current activity and the stage of interaction. Given this state, a KBM transition takes place which may alter global state properties depending on the nature of the incoming Event. Transitions are dened as rules of the form: transition( State, Event, Reply, NewState ):- Conditions.

and they specify the dialogue of the KBM with the user and the BEM. After a transition takes place, a new dialogue state is set and the response of the KBM is communicated to the appropriate component: it may be either the display or the BEM. Eventually, the system moves into the new state generated by the transition at that stage. Both task and advice interactions are developed with the state transition model. In addition, to avoid problems with editing the dialogue and the issues of truth maintenance 7

and belief revision, FAST uses domain specic solutions. For each activity, the system contains an explicitly ordering of goal descriptions. Based on goal orderings more complex goals may contain control structures dening if then else and while loop constructs, the specic ordering gives rise to domain specic interactive procedures. Control for interactive procedures allow that goals are tried in turn. There is a current goal which after interaction between the user and the system is marked either as tried or achieved. When all the goals have been tried the procedure specifying the advice strategy is terminated (for more details see 15]). Then editing the dialogue becomes just another domain specic interaction procedure that helps the user to bring the dialogue in a consistent form, without the need of truth maintenance. Moreover, it is up to the programmer to dene interactive procedures for strategies that after editing of a previous answer are re-entered at the right point. 3.4 Problems with FAST At the initial stages of developing FAST, transition rules were very exible in that they allowed the programmer to provide specic rather than general solutions. At the end of developing the prototype, however, transitions were found to be too low level in that they lacked a specication language and mixed logic and control at the same level. Moreover, the FOCUS architecture was too centralised. For example, every message sent from a component to another had to go always through the Harness even messages sent from a KBM to BEM (and vice versa). However, one would expect that only messages with destination the user should go through the Harness. By a similar argument, one could further object to the organisation of the BEM, for instance, why back-ends need to be combined only via this system is not clear. In the case of FAST this is not so important because there is only one back-end. However, in general, one may require to adopt solutions similar to those described in 7]. Moreover, the way the Harness coordinated the various interactions were closed to the programmer of the KBFE (in the same way APES was). What we really need instead is to give programmers the exibility of producing new functionality in an open but systematic way.

4 Knowledge-Based Front-Ends and Games

To address the development problems of GLIMPSE and FAST we have presented in 18] a metaphor of interaction that is higher level than the state transition rules and applicable to forms of interaction where QtU does not t. In this metaphor, interaction is viewed as a rule-governed activity which we may think of as a game. The emphasis is on the existence of clearly specied valid moves (as in `dialogue games') rather than on any notion of `winning'. Construction of a KBFE proceeds by building up a complex game from simpler, easily implementable ones. The value of the metaphor, however, is intended primarily for the system developer rather than the end-user, to serve as a conceptual device for the organisation and development of interactive systems, in general, and KBFEs, in particular. In this Section we present the games metaphor in the context of interactive systems exemplied by KBFEs. 4.1 The Games metaphor The principle of the games metaphor is that we interpret the rules governing an interactive system as the rules specifying a game. In this context, interactions made by the participants of an interactive system are interpreted as moves selected by the players of a game. Specifying the valid moves of a game corresponds to dening the preconditions of actions in the interactive system. The eects of a move on the state of the game correspond to 8

the eects of an action on the state of the interactive system. Games with more than one player correspond to interactive systems with more than one interactive participant. In order to implement an interactive system we construct an umpire. This is a component that displays the current state of the game in some appropriate fashion, provides means by which users can select their moves, enforces compliance of the players with the rules of the game and thereby controls the interaction. An important characteristic of the umpire is that it allows variations of play. For example, through the umpire players may play the game from physically distant locations over a network as in networked-games. This resembles interactive systems whose participants interact from physically distant places 12]. The analogy between an interactive system spread in a network and a networked game is depicted in Figure 4. Umpire PlayerA

Network

State

PlayerB

Connection Interactive System

User

Network

Application program Connection

Display

Figure 4: Playing a Game vs Interacting with an Interactive System What is to be gained from thinking in these terms? The idea is that specifying a simple game and implementing it by means of an umpire is easy. Complex interactive systems can then be built up as compound games composed from simpler sub-games. As an example of a compound game consider a master's game of Chess, where a Chess master plays several Chess games with dierent student players simultaneously, as shown in Figure 5. This game has many similarities with interactive systems: the Chess master is like the user of the system the Chess games that are in progress are like the components of an interactive system that the user can invoke the totality of all the valid Chess moves in all of the currently active games corresponds to the collection of system operations from which the user is able to select. Of course in an interactive system the component sub-games are not normally all instances of a single game as in master's Chess they would normally correspond to dierent application programs 6], but the system as whole may be viewed as a compound game nevertheless. Master’s Game

Master

g1

Player1

g2

Player2

gn

PlayerN

Figure 5: The Master's Game A further benet of the games metaphor is that the addition of advice-giving components to the interactive system 21] can be done in a structured and natural way, by providing an 9

advisor for the corresponding game 19]. Both context sensitive and strategic advice can be formulated in terms of best moves as determined by some expert strategy. More than one advisor can be present in a game in the same way that dierent types of advice may be available in an interactive system. It is important to note that the advisor itself does not necessarily need to incorporate the rules of the game in order to make recommendations. A winning strategy for the game of Nim, for instance, can be formulated as a simple arithmetic test without reference to the rules of the game. A Chess-playing program will calculate the relative strengths of various positions and moves without using an explicit representation of the valid moves of Chess. This point is important because it allows the advice-giving components of an interactive system to be separated and developed independently of the other parts. The advisors can be added or replaced in a modular way as they become available. Advisor

Advisor

Communication Channel

Advice Game

Interaction Game State

Interaction Game

Application Program

Application Program

Compound Game (b) Advice through Games

(a) Introducing an Advisor

Figure 6: Adding an Advisor to an Interactive System Game It should be noted that in some cases the advisor itself may have to interact with the user. In GLIMPSE, for example, the advisor sometimes needed to be told whether a given displayed graph was linear, or nearly linear, since this was something that the user could determine more easily than the system. Similarly, advisors sometimes need to ask users about their intentions before they are able to oer advice on recommended moves. The conceptual structure of an interactive system incorporating an advisor is depicted in Figure 6(a). Note that communication between the user and the advisor can also be regarded as a game, the advice game. In this new game, the advisor is a player containing an explicit representation of how various user goals can be achieved at dierent stages of the interaction. Note also that the advice game is a sub-game of the interactive system that is now seen as a compound game, as shown in Figure 6(b). Furthermore, in the process of providing advice, the provision of explanations from the advisor can be seen as a sub-game of the advice game. In particular, the request for an explanation by the user can sometimes be seen by the system as a challenge that has to be met, as in a dialogue game 1]. It may even be helpful to interpret the successful provision of explanation from the system as the system winning and the user losing an argument 2]. These points, however, and further consideration of these suggestions is beyond the scope of this paper.

5 The LAST system

To show how the games metaphor can be applied to a practical application we show here how to develop interactions of LAST, a KBFE that attempts to reconstruct the interactions of GLIMPSE and FAST. LAST is designed as a compound game called the mediation game with players a user, the back-end GLIM and the advisor. The user makes 10

moves in the mediation game via the control panel shown in Figure 7. CONTROL WINDOW file

vector

graph

data-matrix

advise

special

enter delete transform type associate show

Figure 7: The Main Window of LAST Like the master in the master's game of Chess, the user interleaves sub-games of the mediation game selecting them via items of the panel and their moves from the corresponding menus. The valid moves that are exclusive to the mediation game are accessed from the special item of the panel. The rest of the valid moves in the mediation game are valid moves that can be made by the user in the sub-games. Some of the sub-games of the mediation game are outlined next. 5.1 The Facilitation Game The facilitation game is a compound game consisting of four task facilitation games corresponding to the panel items le,vector, data-matrix and graph. The umpire of the facilitation game acts as a facilitator between the user and the back-end GLIM, the only two players of this game. 5.1.1 Task facilitation games Task facilitation games are also compound games where the user and GLIM are the players. In these games, moves of the user select items from menus accessed via panel items (see for example Figure 7). These moves enable the user to start new tasks by starting new sub-games these allow the specication and execution of tasks. In general, depending on how many moves a task facilitation game has, menus can be structured in sub-menus. Dierent organisations are possible in this case for instance, items in submenus may be regarded either as a set of moves of the task facilitation game or moves that belong to sub-games of the task facilitation game. In other words, games provide a exible device supporting dierent interface organisations of an interactive system. 5.1.2 Task games Moves in task facilitation games start tasks, that is, sub-games normally played between the user and GLIM. Moves of the user specify the parameters of the task while moves of GLIM execute the task. In Figure 8 we present an example task game showing how the system interacts with the user for the entry of vectors. This game is a sub-game of the vector game and is started as a result of applying the eects of the move made in Figure 7. Figure 8 shows the initial state of the task game where the task parameters for the name and the values of the vector are undened. The game has three further moves for the user: edit a task parameter (one of Name: and Values:), submit the task for execution (by pressing the ok button) and cancel the task (by pressing the cancel button). Execution of the task is a move made by the GLIM player. As in FAST, we use the notion of a 11

Vector Entry Please enter a vector: vector Name: Values: ok

cancel

Figure 8: The vector entry task game in LAST Back-End Manager (BEM) 11] to allow the GLIM package to communicate in the same language with the rest of the system components. 5.2 The Advice Game The advice game allows the user to obtain recommendations and suggestions from the advisor components. Moves of this game are accessed via the advise panel item. The advice game shares the state of the task facilitation game, thus enabling the advisor to observe the most recent development of the interaction. Some moves made in the advice game allow the user to request information about the area of the statistical domain where advice is needed. These moves initiate advice sub-games which further provide context for giving advice in GLIMPSE and FAST context was provided through the use of activities. Also, the advice game and its sub-games are based on interactive procedures as in FAST 15]. An interactive procedure is part of the knowledge representing how the advisor player has to play the advice game. Using these procedures the advisor decides which tasks to recommend next at the various stages of the advice game. Interactive procedures will also be discussed next because they are relevant to the issue of coordinating sub-games. 5.3 Coordination Issues The main issue in specifying compound games, such as LAST, is controlling interleaving of moves between sub-games. Interleaving provides a means of coordinating sub-games in compound games. It is dened by specifying under which conditions a sub-game is active in a compound game. The valid moves of a compound game are then dened to contain the valid moves exclusive to that game plus all the moves in the active component sub-games. Dierent forms of coordination are possible and given by suitable denition of what is an active game. We distinguish two main classes of interleaving: free interleaving where moves from the sub-games can be selected freely by players and constrained interleaving where there are restrictions on selections of sub-games determined by domain specic constraints. In LAST, we use free interleaving to support multi-threading for sub-games of the task facilitation game. In this case, any task facilitation game can be played by the user concurrently. Constraint interleaving, on the other hand, is used to dene single-threading in LAST. In this mode of interaction, a task sub-game of the facilitation game is active if in a task facilitation game there is a task sub-game that has not been completed. Otherwise, if there is no pending task game, any task facilitation game can be selected from the facilitation game as in free interleaving. The representation of interleaving will be discussed later in Section 6. One requirement of LAST is to retain the non-authoritarian structure of the GLIMPSE advice. To provide this we need additional coordination primitives supported in the form 12

of moves. For example, in the case of advice, the mediation game supports as a move the suspension of the advice game. Once the advice game is suspended, the user can make another move in the facilitation game, so avoiding the advice recommended by the advisor. The advice game can be subsequently resumed  this too is formulated as a move at the higher-level mediation game. Other types of coordination primitives can be dened for compound games. In sequenced games, a sub-game must be terminated before the next sub-game is played. There are two types of sequenced games that we nd useful. One is where all games that need to be sequenced are started in advance. In this case, sequencing can be achieved via constraint interleaving | constraints always select the rst active game. The other form of sequencing requires that games are started dynamically by moves of a player. In this case, sequences are achieved by players that follow interactive procedures. An example of this form of sequencing in LAST is dened in the advice game. In particular, suitable denitions of the selection strategy of the advisor simulate conditional statements, loops and procedures as part of sequenced games 16]. In this way, the designers can control domain strategies specifying what are the best task games that must be played next.

6 A Framework for Knowledge{Based Front{Ends as Games

In this Section we present a knowledge representation framework for developing games. The purpose of the framework is to identify a basic set of logic programs that specify the rules of a game and enable the implementation of these rules by constructing an umpire. This basic set of game-playing programs is then extended to customise interactions of simple games by expanding and ltering them. 6.1 The Rules of a Game The basic form of a game is formulated in the games framework by the logic program: game(State, Result):terminating(State, Result). game(State, Result):not terminating(State, ), valid(State, Move), eects(State, Move, NewState), game(NewState, Result).

The two clause above are interpreted as follows. In a terminating State the Result of the game is returned as output. In a non-terminating State, however, the eects of a valid Move are applied to produce a NewState. Interaction as a game continues in the new state until a terminating state is reached. Then to specify a particular game we need to decide on an appropriate representation of the state { normally represented as complex Prolog terms, and moves { normally represented by a term of the form: select(Player, Move). We also need to specify the lower level predicates: terminating/2, valid/2 and eects/3 for dierent games representing KBFE interactions. 6.2 The Umpire of a Game Given a set of rules characterising a game and an initial state, execution of the game/2 program generates all possible plays for that game. A game playing program however requires a dierent mode of execution, whereby players eectively select one complete 13

play from all the possible ones. The communication of the players' choices is the main form of interaction that must be supported. Thus, to implement a game playing program based on the rules, it is necessary to dene how players communicate their choices and, assuming a display, how the eects of these choices are presented on the display. We also need to specify how to remove from the display the state of the game when this has been terminated. To do all these we introduce an umpire whose behaviour is dened by the logic program: game(State, Result), State, Result):stop(terminating(State, Result), State, Result). play(game(State, Result), State, Result):play(

not terminating(State, ), choose( , State, Move),

valid(State, Move) eects(State, Move, NewState), State, Move, game(NewState, Result), NewState, Result).

display( play(

NewState),

The denition of play/3 treats terms of the game specication as data and relies upon the use of unication to select parameters of specication terms. This technique is used for accessing parts of the specication from the implementation. For example, the relevant parts of a term describing a player's communication channel can be used by the umpire to access the channel and subsequently receive the player's move as a message. Moreover, this denition of play/3 above is easily portable. For example, to port an implementation of a game to a dierent platform one needs only to re-implement the predicates stop/3, choose/3 and display/4 in the dierent platform. 6.3 Choices as Valid Moves selected from Players The umpire of a game must enforce the rules when dierent players select moves. A move is enabled in the game by dening further the choose/3 predicate. This can be dened either in forward mode where the umpire constructs all the valid moves from the rules and the player selects one, or, in backward mode where a player selects a move and the umpire checks that the move is valid using the rules. The forward mode may be represented by the clause: Valid,State,select(P,Move)):Valid, Moves),

choose(

findall(Move,

select(P, State, Moves, Move).

and the backward mode by the clause: Valid,

choose(

State, select(P, Move)):-

select(P, State, Move), .

Valid

In both denitions above, the variable Valid unies during execution with a term of the form: valid(State, Move)

dening when a Move is valid in a specic State (We shall provide a denition of valid moves shortly). Also in both denitions, the selection of a move from a player is dened for forward mode by rules of the form: select(P, Game, Moves, Move):- Conditions

and for backward mode with rules of the form: 14

select(P, Game, Move):- Conditions.

The dierence in arity between selection rules in the two modes reects their characteristic dierence, namely, that in forward mode the set of moves from which a player selects from is constructed by the umpire before the selection is made while in backward mode the player selects any move rst and the umpire checks immediately after the move is made. Moreover, the separate denition of selection rules allows us to dene control strategies for players of specic games generally. Such an example is the denition of control for interactive procedures to provide advice in LAST, as developed in 16]. 6.4 Structuring Valid Moves So far we have dened a game by specifying a set of valid moves. In practice, however, we want to structure the denition of valid moves further. It is convenient to express this structure in terms of available and legal moves: valid(State, Move):available(State, Move), legal(State, Move).

Conceptually, we may think of available moves as the moves that can be physically selected at the state of the game. Some of the available moves will not always be legal. To ensure that legal moves are always selected we specify them separately. We can think of the same concepts in programming terms too: available/2 denitions act as generators and legal/2 denitions act as lters. In practice, the new denition of valid moves can be dened further. In many games, for example, there are certain types of moves that must be forced at a specic stage of the game, irrespectively of what other moves are possible. In other words, for some game situations certain legal moves need to overwrite the rest of the legal moves. To formulate these situations we dene legal moves in terms of necessary and possible moves: legal(State, Move):necessary(State, Move). legal(State, Move):not necessary(State, ), possible(State, Move).

The clauses above ensure that necessary/2 denitions always overwrite the rest of the legal moves dened by possible/2 denitions. Using this structure for valid moves, dierent applications can be specied by dening separately when a move is available, possible or necessary and as result when a move is legal and valid. 6.5 Customised Games It is often more natural and in most cases computationally more desirable to allow moves that are not valid. Many Chess playing programs, for instance, allow players to move a pawn backwards (as when Chess is played without a computer) and complain only when the move is detected as illegal. In both GLIMPSE and FAST, the task for entering a vector was implemented in such a way that the user enters any vector rst and received a warning later if the entered vector is illegal. This solution is easier to implement: if we allowed only entries of legal vectors then we would have to disable moves at the physical level (eg. keyboard). We refer to moves that are possible but not legal as extra-legal moves. To represent these moves in 17] we have introduced rules of the form: extra legal(State, Move):- Conditions.

15

to specify the extra-legal Move made in the expanded game represented by its State. However, this representation assumes that the name of the game remains the same and cannot handle nested expansions (see 16] for a detailed discussion). A more general formulation of expansions can be obtained by introducing a new name for the game dened by the extra-legal moves. These can now be captured by the denition: valid(NewGame, Move):valid(OriginalGame, Move). valid(NewGame, Move):available(NewGame, Move), legal(NewGame, Move).

To play the expanded game the specication of eects/3 predicate of the legal game needs to be extended to cater for the eects extra-legal moves have in the original game. Moreover, an existing game can be ltered as well as expanded. Filtering reduces the existing game so that only a subset of the moves are legal in the new game the legal moves of the new game can be dened as the valid moves of the old game that are not extra-legal. In terms of KBFEs, ltering corresponds to situations where the system's functionality has to be customised to the needs of less demanding users.

7 The Formulation of Compound Games

Compound games are complex games composed from sub-games, as in master's Chess where a master can play dierent games with dierent players. Following 18], in Section 4 we have shown how compound games can be used to construct complex interactive systems built from simpler components. We have also shown how interactions of GLIMPSE and FAST can be seen as compound games. In this Section we formulate compound games by keeping the basic game-playing program the same but by introducing additional structure to the lower level predicates. 7.1 The Rules of a Compound Game We have already seen that one of the main issues in compound games is the selection and coordination of sub-game interactions. In this paper, we dene compound games by treating coordination as a separate game, the coordination game. The termination rules of a coordination game played in interleaving mode Mode are dened as: terminating(Mode(State), Result):terminating(State, Result).

Valid moves in a coordination game are dened as a valid moves in any active sub-game:

valid(Mode(State), inside(SubState, Move)):active(Mode(State), SubState), valid(SubState, Move). The term inside(SubState, Move) represents a compound move . This is a move made either

in the state of the compound game or in a state of one of its sub-games. These are interleaved here by specifying active/2 clauses dening when a particular sub-game is active. Free interleaving (discussed in Section 5) is denoted by the atom freeint and is dened through running/2 clauses specifying when a sub-game is running: active(freeint(State), SubState):running(State, SubState).

Constraint interleaving on the other hand (also discussed in Section 5), is denoted by 16

the atom constint and is specied by a set of domain specic constraints represented by overtaking/2 and running/2 clauses: active(constint(State), SubState):overtaking(State, SubState). active(constint(State), SubState):not overtaking(State, ), running(State, SubState).

Overtaking games are active games that, at specic stages of the interaction, have higher priority than the rest of the active games that are running. Eects of compound moves are then dened in terms of the eects that they have in the compound game or in terms of the eects that it has in one of the sub-games: eects(Mode(State), inside(State, Move), Mode(NewState)):eects(State, Move, NewState). eects(Mode(State), inside(SubState, Move), Mode(NewState)):eects(SubState, Move, NewSubState), substitute(State, SubState, NewSubState, AState), eects(AState, inside(SubState, Move), NewState).

We dene separately how a sub-game term is substituted in the compound game state with rules specifying substitute/4. 7.2 The Umpire of a Compound Game To develop the umpire of a compound game we need to develop an umpire for the coordination game. A compound game is stopped when the coordination game can be stopped: terminating(Mode(State), Result), Mode(State), Result):stop(terminating(State, Result), State, Result).

stop(

Compound moves are chosen by checking (using trigger/3 denitions) that the sub-game triggered is indeed active: valid(Mode(State), Move), Mode(State), inside(SubState, active(Mode(State), SubState), State, SubState), valid(SubState, Move), SubState, Move).

choose( trigger( choose(

Move)):-

Once a compound move is chosen, the umpire of the coordination game displays it by either calling the display facility of the compound game or the display of one of its subgames: Eects

display( , constint(S), inside(S, Move), constint(NewS)):display(effects(S, Move, NewS), S, Move, NewS).

Eects

display( , constint(S), inside(SubS, M), constint(NewS)):display(effects(SubS, M, NewSubS), SubS, M, NewSubS),

substitute(S, SubS, NewSubS, NewS), S, SubS, NewSubS, AnS), display(eects(AnS, inside(SubS, M), NewS), AnS, inside(SubS, M), NewS). refresh(

As an implementation counter-part for substituting a sub-game we need to dene how the state of that sub-game is refreshed after a compound move. This is needed just in case the sub-game has terminated in which case refreshing the state of the compound game means that the umpire needs to stop that sub-game.

17

7.3 Handling Sub-games via Moves in Compound Games Another issue that arises in compound games is how to handle sub-games via moves. To deal with this issue we have identied a set of primitives that allow the dynamic manipulation of sub-games via moves. The rst primitive denes the dynamic starting of sub-games. To formulate this we dene at the specication level how a sub-game is initiated by a specic move of a compound game: initiating(State, Move, NewState):new(State, Move, SubState), linking(State, SubState, NewState).

The new sub-game is initiated by creating a new game state and linking it in the state of the main game. The initiation of a game can then be implemented in the umpire by dening how the game is started: initiating(State, Move, NewState), State, Move, NewState):create(new(State, Move, SubState), State, Move, SubState), activate(linking(State, SubState, NewState), State, SubState, NewState).

start(

As before, we dene separately rules that dene how the sub-game are created and how they are activated at the implementation level. Moreover, there are a number of other primitive that we dene similarly, the most important ones we list below: interrupting(State, Move, NewState), State, Move, NewState):- Conditions. reinitiating(State, Move, NewState), State, Move, NewState):- Conditions. close(suspending(State, Move, NewState), State, Move, NewState):- Conditions. open(resuming(State, Move, NewState), State, Move, NewState):- Conditions. combine(merging(State, Move, NewState), State, Move, NewState):- Conditions. separate(splitting(State, Move, NewState), State, Move, NewState):- Conditions. kill(

restart(

These primitives too are specied and implemented separately. For example, the implementation primitive for resuming a suspended game { specied by resuming/3 clauses, supports the opening of the game at the display of the application { implemented separately by open/4 clauses. In this way, one can support via moves in compound games a range of primitives that start, interrupt, restart, suspend, resume, merge and split sub-games in a systematic way.

8 Conclusions

The pitfalls of GLIMPSE and FAST have motivated us to view KBFEs, and, more generally interactive systems, as if they were games. We have used games to specify components of interaction and we have sketched a game-playing framework where these components can be dened, customised, combined and ported in an open and systematic way. For this purpose, we have investigated both simple and complex, compound games composed from sub-games. The application of the resulting game-playing framework in LAST { the reconstruction of GLIMPSE and FAST { is very encouraging in that it has demonstrated that games support the development of complex interactive systems in general and KBFEs in particular. The existing formulation of games, however, requires a more concise and perspicuous formalism for specifying game states, rules and the various forms of coordination such as coordination primitives. Playmaker, a specication language that we have introduced in 16], supports these requirements and provides a formalism that has a direct translation to the representation framework discussed in this paper. These details we shall present in future work. 18

References

1] T. J. M. Bench-Capon, P. E. S. Dunne, and P. H. Leng. A Dialogue Game for Dialectical Interaction with Expert Systems. In 12th Annual Conference on Expert Systems and their Applications, Avignon, 1992. 2] T. J. M. Bench-Capon, D. Lowes, and A. M. McEnery. Using Toulmin's Argument Schema to Explain Logic Programs. Knowledge{Based Systems, 4(3):177{83, 1991. 3] K. A. Bowen and R. A. Kowalski. Amalgamating Language and Metalanguage in Logic Programming. In K. L. Clark and S. A. Tarnlund, editors, Logic Programming, pages 153{172. Academic Press, 1982. 4] A. Bundy. Intelligent Front Ends. Research Paper No. 227, Department of Articial Intelligence, University of Endibourgh, 1984. 5] E. A. Edmonds and E. McDaid. An Architecture for Knowledge{Based Front{Ends. Knowledge{Based Systems, 3(4):221{224, 1990. 6] E. A. Edmonds, B. S. Murray, J. Ghazikhanian, and S. P. Heggie. The Re{use and Integration of Existing Software: A Central Role for the Intelligent User Interface. In A. Monk, D. Diaper, and M.D. Harisson, editors, HCI '92, People and Computers VII, British Computer Society Conference Series, pages 415{427. Cambridge University Press, 1992. 7] M. R. Genesereth, N. P. Singh, and M. A. Syed. A Distributed and Anonymous Knowledge Sharing Approach to Software Interoperation. In International Symposium of Fifth Generation Computing Systems, pages 125{139, Japan, 1994. 8] S. Hague and I. Reid. FOCUS: Fourth Annual Report. Technical Report FOCUS/NAG/16/23.3-P, NAG Ltd, Oxford, UK, February 1993. 9] P. Hammond and M. J. Sergot. APES: Augmented Prolog for Expert Systems, Programmer's Manual. Logic Based Systems Ltd, London, UK, 1987. 10] P. McCullagh and J. A. Nelder. Generalized Linear Models. Chapman and Hall, London, 1987. 11] A. Prat, J. Lores, P. Fletcher, and J. M. Catot. The Back{End manager: An Interface between a Knowledge{Based Front{End and its application subsystems. Knowledge{Based Systems, 3(4):225{229, 1990. 12] M. A. Sasse, M. J. Handley, and S. C. Chuang. Support for Collaborative Authoring via Email: The MESSIE Environment. In Giorgio de Michelis, Carla Simone, and Kjeld Schmidt, editors, Proc. Third European Conference on Computer-Supported Cooperative Work - ECSCW93, pages 249{264, Milan, Italy, 13-17 September 1993. Dordrecht, The Netherlands: Kluwer Academic Publishers. 13] M. J. Sergot. A Query{the{User Facility of Logic Programming. In P. Degano and E. Sandewall, editors, Integrated Interactive Computer Systems, pages 27{41. North Holland, 1983. 14] K. Stathis. A FAST Front End Application. In L. Sterling, editor, Proceedings of the 2nd International Conference on the Practical Applications of Prolog, pages 537{548, London, UK, April 1994. 15] K. Stathis. How to give FAST Advice. In Proceedings of the 7th Symposium and Exhibition on Industrial Applications of Prolog, INAP'94, pages 59{67, Tokyo, Japan, October 1994. 16] K. Stathis. Game-Based Development of Interactive Systems. PhD thesis, Imperial College, November 1996.

19

17] K. Stathis and M. J. Sergot. A Fast Glimpse of Knowledge-Based Front-Ends as Games. In D. Batanov and P. Brezillon, editors, Proc. of 1st International Conference on Successes and Failures of Knowledge-Based Systems in Real World Applications, pages 19{33, Bangkok, Thailand, October 1996. AIT Press. 18] K. Stathis and M. J. Sergot. Games as a Metaphor for Interactive Systems. In M. A. Sasse, R.J. Cunningham, and R. L. Winder, editors, People and Computers XI (Proceedings of HCI'96), BCS Conference Series, pages 19{33, London, UK, August 1996. Springer-Verlag. 19] M. H. van Emden. Chess-Endgame Advice: A Case Study in Computer Utilisation of Knowledge. Research Report CS-80-05, Computer Science Department, University of Waterloo, Canada, January 1980. 20] D. E. Wolstenholme. External Data in Logic{based Advice Systems. PhD thesis, Imperial College, London, UK, 1990. 21] D. E. Wolstenholme, C. M. O'Brien, and J. A. Nelder. GLIMPSE : a Knowledge{Based Front{End for statistical analysis. Knowledge{Based Systems, 1:173{178, 1988.

20