- Email: [email protected]
The CONTEXT: a high-level structuring concept for GKS input
Comput. & Graphic~Vol. 9. No. 3, pp. 211-220. 1985
"
0097-8493/85 $3.00 + .00 © 1985 Pergamon Press Ltd,
Printed in Great Britain,
Graphics Dialogue P r o g r a m m i n g
THE CONTEXT: A HIGH-LEVEL STRUCTURING CONCEPT FOR GKS INPUT MICHEAL MAC AN AIRCHINNIGH Department of Computer Science, University of Dublin. Trinity College. Dublin, Ireland Abstract--All human beings interact in some context or other. The concept of context has been explored by researchers in many different fields. A survey of some of this work is presented here. Using conceptual graph notation as a knowledge representation language, an introductory analysis of the concept of context and related notions is carried out and the results applied to GKS input. The outline of a possible implementation in Ada, with the (generic)package as the principal structuring unit and the task as the (low-level) implementation unit, is illustrated with a simple example. of contexts described above,~one identifies certain features common to all of them. Some of these are
I. I N T R O D U C T I O N
Where am I? What can I do here? How did I get here? Where can I go, and how do I get there?" [1] Everything that a human being does is done in a context. In other words, the human being's interaction with its environment takes place within a specific context. To motivate the definition of the concepts introduced in this paper, it will be helpful to consider a journey that I have undertaken in January 1984 between my home town, Maynooth, Ireland, and a small village, Wenschdorf, Federal Republic of Germany, for the purpose of attending the EUROGRAPHICS Workshop on Graphics Programming and at which, incidentally, the idea of a CONTEXT as a high-level structuring concept for GKS input first originated [2]. We can say that this journey was undertaken in the context of that Workshop. A topological diagram of the itinerary, to a first approximation, is shown in Fig. 1. To get from Maynooth to Dublin, ! travelled by bus. In this context (CXTI), my primary interaction (INT 1) was with the bus conductor from whom 1 obtained a one-way ticket in exchange for money. I travelled from Dublin to Frankfurt by plane. This was made possible in the context (CXT2) of obtaining a return ticket from my travel agent in exchange for credit. It should be noted that this interaction (INT2) in CXT2 took place prior to INTI in CXT1, though this need not have been the case. In Frankfurt I obtained a one-way ticket in exchange for money from an official of the Bundesbahn (i.e. German Railways) in order to travel by train to Miltenberg. This interaction (INT3) was done in another context (CXT3). Finally, it was necessary to get from Miltenberg to Wenschdorf. In this final context (CXT4), my interaction (INT4) was with the taxi driver who drove me there. However, no money changed hands until I arrived in Wenschdorf. At my destination, in exchange for my money, 1 received a Quittung (i.e. a receipt). Of course, the above is only an outline of the itinerary in one direction. One can refine it further to include, for example, the journey from Dublin city centre to Dublin airport by bus. In analysing the set c~ 9:3-c
( 1) an interaction took place between myself and another human being; (2) during the.interaction a transaction took place in which a service was obtained in exchange for money/credit. Part of the exchange involved the handing over ofa ticket/Quittung which, in a sense, symbolised the service offered: (3) the context, interaction, and transaction all had a finite duration and began at a specific point in time. There are obviously other common features not listed above. Among these are the mode of conveyance, and the source and destination involved. Everyone who has travelled has used contexts such as the above. We use the appropriate context to obtain the service we require. We would not expect to obtain the taxi service for the journey from Miltenberg to Wenschdorf from the bus conductor in Ireland. Such an idea is ludicrous. Thus we can conclude that users of public transport have certain conceptual models (UCMs) [3] that enable them to obtain the offered service. I propose that the CONTEXT is a structure which is a constituent part of such UCMs. Section 2 examines how the concept of CONTEXT is used in a number of disciplines, including that of computer science. This concept, together with other related notions, is expressed in the terminology of conceptual graph notation. This is the subject of Section 3. GKS input is considered in Section 4 where it is associated with the concepts developed in Section 3. Sample encodings are given in the programming language Ada.t Finally, Section 5 shows how the Ada task might be used for the implementation of the package specifications given in Section 4.
211
2. THE CONCEPT OF CONTEXT
"Commands are issued within command contexts, which are conversational contexts limiting what
t Ada is a registered trademark of the U.S. Department of Defense, Ada Joint Program Ot~ce (AJPO).
212
MICHEAL MAC AN AIRCHINNIGH
FRANKFURT (FR Germany)
D~LIN
MAYNOOTH (Ireland)
(ireland) Q
Dos
plane
train
MILTE~BE~3 ( ~ Germany)
taxi
WI~SCHDORF
(FR Germany) Fig. 1. Topological map of a journey. commands the user can issue at a given time and which define the scope of other command language entities." [4] The notion of CONTEXT as a structure for human interaction is not new. Apart from its use in the Command Language Grammar by Moran, cited above, it also turns up in the IFIP WG2.7 Reference Model for Command and Response Languages [5]. Here, "a context defines for the user which operations can be performed on which objects and the effect of those operations." In addition, there are the notions of default context, current context and context switching. Related to the concept of CONTEXT in command and response languages are the notions of frame [6] and script [7] in artificial intelligence. Essentially, a frame was to be thought of as a data structure for representing a stereotyped situation. It was supposed to consist of a two-level hierarchy. At the top level, the knowledge represented was always true (i.e. absolute knowledge). On the other level, the knowledge represented was only relative to a particular situation. A script, on the other hand, was considered to be a predetermined sequence of actions that define a situation. For example, the script for eating in a restaurant is generally well known. Researchers other than computer scientists have considered the role of context in their own respective disciplines. For example, in the field of philosophy Frege was the first to enunciate the dictum "'a word has a meaning only in the context of a sentence" [8]. This idea led to the "doctrine" ofcontextualism which purported to be a general programme for an account of language, meaning and understanding. Frege's dictum is reechoed by Wittgenstein. "Nut der Satz hat Sinn; nur in Zusammenhange des Satzes hat ein Name
Bedeuteung"t [9]. However, Wittgenstein does not completely agree with Frege. An analysis of that by which he differs from Frege would take us to far afield. For our present purposes it is sufficient to note the role of context with respect to the meaning of words/names in sentences/propositions. In the field of interactive computer graphics, the enduser of the application software expresses himself/herself in a language that consists of"words" and language. From the discussion above we may infer that all such expressions between user and program are to be understood within contexts. In other words, the context is that structure which guarantees the possibility/validity of the interaction/dialogue. 3. CONCEPTUAL GRAPH NOTATION AND FUNCTIONAL GRAMMAR
"Definition. Let p be a concept of type PROPOSITION whose referent is the set {u, . . . . . u, } of conceptual graphs: (PROPOSITION: {ul . . . . . u, }]. Then each graph ,i in referent (p) is said to be asserted by the proposition p, and ui is said to occur in the context ofp." [10]. Sowa, cited above, uses the term context much in the same manner as Wittgenstein [9]. He goes on to discuss negative contexts, outermost contexts, overlapping contexts and dominating contexts. Conceptual graphs form a knowledge representation language based on linguistics, psychology, and philosophy, and are extensively dealt with in [10]. Essentially, conceptual graph notation (CG notation) employs two distinct kinds of entities: concepts and conceptual relations. %"Only the proposition has sense; only in the context of a proposition has a name meaning."
CONTEXT: A high-levelstructuring concept for GKS input Concepts are represented by type labelsuwords in capital letters enclosed in square brackets. Thus the concept of "context" may be denoted by [CONTEXT]. Type labels are also used to represent conceptual relations. To distinguish lhe latter from concepts, round brackets are used. (OBJECT) and (DURATION). for example, denote typical conceptual relations according to Sowa. The sentence "a context is activated for a specific time period" may be represented by the conceptual graph (in linear form): [CONTEXT](OBJECT) ~ [TO_ACT1VATE](RESULT) --. [ACTIVATION: *x] (LINK) ~ [ACTIVATION: *x](DURATION) ~ [TIME_PERIOD] A CONTEXT is the OBJECT of the verb TO_ACTIVATE and the corresponding RESULT is a state called ACTIVATION. There is an anonymous LINK between the CONTEXT and the ACTIVATION state. To indicate that the same ACTIVATION is used, the , x symbol appears in the referent field of the ACTIVATION. This ACTIVATION has a DURATION which is a TIME_PERIOD. The use of CG notation as a knowledge representation language in ComputerAided Design has been explored in [11]. A moment's reflection on the above conceptual graph will reveal a major weakness in CG notation that is also shared incidentally by many sorted logic, for example. Consider DURATION. In the conceptual graph it is used as a conceptual relation linking ACTIVATION to TIME_PERIOD. However, it is conceivable that in another context we might be interested in the concept of DURATION itself! In general, conceptual relations may be subject to conceptual analysis and as such may be treated themselves as concepts. This dichotomy is resolved in CG notation by employing two different kinds of parentheses. Thus [DURATION] is distinct from (DURATION). In Ada, type labels are provided by a generic package. Separate instantiations for concept type labels and conceptual relation type labels preserve this distinction [11]. Hence the strong typing of Ada enables us to determine whether we are dealing with [DURATION] or (DURATION). Referring to the contexts C X T I . . C X T 4 in the introduction, let us consider how we may further elaborate on the definition of the concept CONTEXT. We have seen that a CONTEXT contains a set (possibly empty) of INTERACTIONs, each of which, in turn, contains a set (possibly empty) of TRANSACTIONs. A CONTEXT is possessed by a human being. In general, we may widen this to some ANIMATE object in order to allow for the possibility of a robot, or a computer program, for example, to possess a CONTEXT. As noted above, a CONTEXT may be activated by the ANIMATE object and endure for a specific TIME_PERIOD. At present, it seems reasonable that the possessor of the CONTEXT should also be the one who activates that CONTEXT. INTERACTIONs and TRANSACTIONs also have DURATION. Further-
213
more, we can identify a POINT_IN_TIME at which each of these, as well as the CONTEXT, are initiated. Continuing in this vein, we eventually build up a working definition of the concept. A possible expression in CG notation might be [CONTEXT] (OBJECT) - - [TO_ACTIVATE](RESULT) ~ [ACTIVATION: *x] (AGENT) ~ [ANIMATE: ,y] (LINK) ~ [ACTIVATION: *x](DURATION) ~ [TIME_PERIOD] (POINT_IN_TIME) - - [TIME] (POSSESSOR) ~ [ANIMATE: ,y] (CONTENT) - - [INTERACTION: I*--l] Let us turn now to the concept of INTERACTION. This is a state which is the RESULT of the verb TO_INTERACT. INTERgCTION involves a twoway COMMUNICATION. The concept TO_COMMUNICATE and its expression in CG notation using a variety of different natural languages may be found in [12]. One may construct type definitions in CG notation out of lambda expressions, the bodies of which are conceptual graphs. One possible type definition for TO_INTERACT in terms of the concept TO_COMMUNICATE, taken from [11] is type TO_INTERACT (x. y) is Lr [TO_COMMUNICATE: *x] ( A G E N T ) - [ANIMATE: ,p] (RECIPIENT) ~ [ANIMATE: ,q] (INSTRUMENT) - - [ENTITY] (OBJECT) - - [INFORMATION] and ~.y [TO_COMMUNICATE: ,y] (AGENT) ~ [ANIMATE: ,q] (RECIPIENT) - - [ANIMATE: ,p] (INSTRUMENT) - - [ENTITY] (OBJECT) - - [INFORMATION] We may now use this type definition in the conceptual graph for the concept INTERACTION:
[INTERACTION] (RESULT) - - [TO_INTERACT] (DURATION) - - [TIME_PERIOD] (POINT_IN_TIME) ---, [TIME] (CONTENT) ~ [TRANSACTION: {,t/] Note that for both the CONTEXT and the INTERACTION, I have specified a POINT_IN_TIME at which they commence. This suggests a possible reorganisation of the graphs to allow for a TO__,BEGIN verb. Finally, I wish to consider the concept TRANSACTION which is a result of the verb TO_TRANSACT. Let us look once more at CXTI which involves a journey from Maynooth to Dublin by bus. INTI was concerned with the obtaining of a ticket in excliange for a sum of money from the bus conductor. This exchange is effectively a TRANSACTION. To distinguish clearly between a TRANSACTION and an INTERACTION, let us sup-
214
MICHEAL MAC AN AIRCHINNIGH
pose that at some~other time on the bus journey a ticket inspector gets on the bus. In another INTERACTION between myself and the inspector, he/she validates the TRANSACTION that took place in INTl. This VALIDATION process which may be considered to be a kind of TRANSACTION is different in nature from that which took place in INTl. Using a type definition and the concept TO_GIVE, we build the following conceptual graph: type TO_TRANSACT(x, y) is k r [TO_GIVE: *x] (AGENT) - - [ANIMATE: ,p] (RECIPIENT) ~ [ANIMATE: ,q] (OBJECT) ~ [ENTITY] and hy [TO_GIVE: ,y] (AGENT) ---, [ANIMATE: ,q] (RECIPIENT) - - [ANIMATE: ,p] (OBJECT) ~ [ENTITY] Just as in the case of INTERACTION, we would now build a conceptual graph for TRANSACTION. The details are left to the reader. As noted in [12], CG notation is a possible basis for conducting further research in the formal specification of UCMs and user-computer interaction. However, I feel that it is not complete in itself. To complement the CG notation l am presently looking at the functional grammar approach (FG) of Dik [ 13]. Essentially, FG considers language as an instrument of social interaction between human beings, used with the primary aim of establishing communicative relations between speakers and addressees. Thus it would seem that FG would be eminently suited to the area of user-computer interaction. There is a correspondence between the FG of Dik and the CG notation of Sowa, which is not unexpected, since conceptual graphs of a particular kind can be mapped into first order predicate calculus, and Dik's FG is based on the concept of (nuclear) predicates. Consider, for example, the conceptual graph of the verb TO_GIVE: [10] [TO_GIVE] (AGENT) - - [ANIMATE] (RECIPIENT) - - [ANIMATE] (OBJECT) ~ [ENTITY] The corresponding nuclear predicate [13] is givev[x~ :animate(xt)]^s(x2)Go[X3:animate(x3)]R~ where V denotes a Verb, Ag an Agent, Go a Goal, and Rec a Recipient. The two expressions are practically identical! Because of space considerations, I will touch upon two aspects of FG that are of immediate interest, but only very briefly. First, there are the so-called pragmatic functions, two of which are external---_Theme and Tail, and two of which are internal--Topic and Focus. The T h e m e specifies the universe of discourse with respect to which the subsequent predication is presented as
relevant. The Tail presents, as an "'afterthought'" to the predication, information meant to clarify or modify it. Topic presents the entity "'about" which the predication predicates something in the given setting. The Focus presents what is relatively the most important and salient information in the given setting. Consider INTI of CXTI. It is a peculiarity of the Dublin area public bus transport system that to obtain a ticket from a conductor, it is sufficient to state the fare. in my own case the expression "'one pound please" is all that is required. From the point of view of Dik's pragmatic functions this constitutes the Focus of the expression. There is no explicit Theme, Tail or Topic. On the other hand, in CXT3, 1 do not know how much the train fare will cost. A suitable introductory statement that I use is something like "Ich moechte yon hier nach Miltenberg fahren"t. The Focus in this case is "'nach Miltenberg.'" The usefulness of these pragmatic functions with respect to the user-computer dialogue lies in the fact that they provide guidelines for the actualstructure of the (command language) expressions involved. Second, one of the goals in the development of the formal specification of UCMs is to find a canonical form, that is natural language independent, for the specification of the concepts and conceptual relations possessed by the user [12], The work done by Dik on language independent preferred order of constituents (LIPOC) seems to be of particular relevance. I quote: "Although much more evidence will have to be produced in order to further substantiate the quite general claims made in this chapter, especially on a cross-linguistic basis, we believe that there is sufficient support for the general hypothesis that constituents prefer to be linearised in an order of increasing internal complexity, and that this preference may interfere with patterns which we would expect in terms of other rules and principles operating in the language" [l 3]. How LIPOC relates to user-computer dialogue is a topic worthy of future research. 4. GKS INPUT AND THE GKS CONTEXT "The GKS input concept represents a rather complex area of application and implementation details." [ 14] In this section 1 want to show how the concept of CONTEXT and the other related notions that we have seen so far may be used to reduce the complexity presented by the GKS logical input devices, their associated values and operating modes. It is assumed that the reader is already familiar with the logical input devices of GKS. A good reference work is that cited above [14]. At the EUROGRAPH1CS Workshop on Graphics Programming, a working group was given the task of considering how to design new GKS application software [2]. It was there that the idea of a CONTEXT concept might prove useful as a high-level structuring concept for GKS input. A distinction was made, by Weber, between a GKS_CONTEXT and a
t I want to travel from here to Miltenberg.
CONTEXT: A high-levelstructuring concept for GKS input human factors context (HF_CONTEXT). Specifically, the HF_CONTEXT belonged to the UCM whereas the GKS_CONTEXT was to be considered as a programming concept. Initially, a GKS_CONTEXT was viewed as an analogue'of the GKS WORKSTATION concept and there was to be a one-one correspondence between the two. Default information for such a context was stored in a CONTEXT_DESCRIPTION_ TABLE (CDT). Upon invocation of the OPEN_ CONTEXT function, this information would be copied into a CONTEXT__STATE_L1ST (CSL). Other functions that might operate on a context were CLOSE_CONTEXT. ACTIVATE_CONTEXT and
215
Ada has already been used for the specification and implementation of GKS application software [l 6], applied to the computational geometry facet of Computer-Aided Design [l 7], and for the encoding of CG Notation [l I]. However, the particular methodology adopted, AdaM, is based on the abstract data type approach. This methodology and the corresponding Ada programming support environment, INTERAda, is outlined in [18]. AdaM is an object oriented Ada software methodology wherein the objects of interest together with their respective operations are encapsulated as an Ada package. For example, an outline package specification for a GKS_CONTEXT might take the f o r m :
- - some with/use clauses package GKS_CONTEXT_MODEL is type GKS_CONTEXT is limited private; function MAKE (CXTID: STRING: - - n a m e of the context SINT: SET_OF_INTERACTION_UNIT; T: TIME: --creation time of the context •
.
,)
return GKS_CONTEXT: function SELECT_CXT1D(CXT: GKS_CONTEXT) return STRING: function SELECT_SINT(CXT: GKS_CONTEXT) return SET_OF_INTERACTION_UNIT; function SELECT_T(CXT: GKS_CONTEXT) return TIME; ----
.
.
.
procedure ACTIVATE(CXT: GKS_CONTEXT; D: D U R A T I O N : . . . ) ; ----
.
.
.
private - - F O R IMPLEMENTOR'S EYES ONLY! end GKS_CONTEXT_MODEL;
DEACTIVATE_CONTEXT. The principal constituent part of a GKS_CONTEXT was the INTERACTION_UNIT. It, in turn, was thought to consist of prompts, echoes, user actions, evaluated results and state changes. The "goodness of fit" between the HF_CONTEXT and the corresponding GKS_CONTEXT would determine the quality of the interaction. Using these original findings as a starting point and in
The types STRING, TIME, and DURATION are predefined in Ada. The generic package feature of Ada allows one to build the usual kind ofcompoter science data structures: SET_OF(. • • ), STACK_OF(- • • ), QUEUE_OF(. • • ), etc. Barnes [9] illustrates the construction of a generic package for sets. However, his package is totally inadequate for our purposes since it can only be instantiated to give sets of objects that have no intrinsic structure. We require a generic package of the form:
generic type ELEMENT is limited private; with function SELECT_S(E: ELEMENT) return STRING; with function EQUAL(El, E2: ELEMENT)return BOOLEAN; package SET_OF_MODEL is type SET is limited private; - - etc.
the light of the conceptual analysis carried out in the earlier part of this paper, 1 propose to present some possible encodings in the programming language Ada [15].
where S E L E C T S returns the name of the base element of the set and the function EQUAL is used in the determination of set membership, equality being based on structure and not on name. We can use such a generic package as follows
216
MIcHEALMAC AN AIRCHINNIGH
package SET_Old_INTERACTION--UNIT is new SET_OF_MODEL(INTERACTION_UNIT, SELECT_INT1D, EQUAL): Let us now turn our attention to the INTERACTION_UNIT as the current object of interest. As a first approximation, we will consider it to be composed of a LOGICAL_INPUT_DEVICE, an OPERATING_MODE and a set of TRANSACTION_UNIT. The package specification outline is, therefore,
5. ADA TASKS
" ' . . . the package should be considered to be the main tool for structuring purposes whereas the task is intended for synchronisation. Thus typical subsystems will consist of a (possibly generic) package containing one or more tasks." [19]
- - s o m e with/use clauses package INTERACTION_UNIT_MODEL is type INTERACTION_UNIT is limited private; function MAKE(INTID: STRING: - - n a m e of the interaction unit LID: LOG1CAI__INPUT_DEVICE; OM: OPERATING_MODE; STRNS: SET_OF_TRANSACTION_UNIT; •
.
,
.)
return INTERACTION_UNIT; function SELECT_INTID(INT: INTERACTION_UNIT) return STRING: --etc., as for GKS_CONTEXT end INTERACTION_UNIT_MODEL; Finally, a TRANSACTION_UNIT is considered to be an object consisting of a USER_ACTION, SYSTEM_ACTION pair:
The TRANSACTION is a concept which is of great importance in the area of data base theory. [21]. Although we have defined our own concept, it would be
- - s o m e with/use clauses package TRANSACTION_UNIT_MODEL is type TRANSACTION_UNIT is limited private; function MAKE(TRNSID: STRING; UA: USER_ACTION; SA: S Y S T E M _ A C T I O N : . . . ) return TRANSACTION_UNIT; --etc.
end TRANSACTION_UN IT_MODEL; The overall approach to the implementation in Ada of the concepts specified in CG notation should now become clearer. Although only a very cursory sketch has been given, the objectification of the concepts via Ada package specification is reducing the overall complexity. At this point it would be helpful to represent the information generated so far by an abstract data type (ADT) lattice [20] (see Fig. 2). There are two important observations which ought to be made at this point. First, no implementation details have been given. There are even some named but as yet undefined ADTs, such as LOGICAL_ INPUT_DEVICE, which are of great interest, especially to implementers of GKS. Second, apart from the conceptual analysis presented earlier, no semantics have been given. One possible approach to the incorporation of semantics into Ada package specifications has been illustrated in [l 6]. The GKS_CONTEXT concept, introduced at Wenschdorf, has undergone a transformation in the process of Ada package specification. Tx~conclude this paper let us turn to Ada's tasking mechanism, the use of which is essential for real interactive programs.
foolish not to learn from the work and experience of others. One of its important properties is that of atomicity "in that if one component operation fails then the transaction fails and all of its (partial) effects are undone" [21]. Such a notion fits in nicely with the history concept proposed for the construction of usercomputer interfaces [3]. In a user interface management syslem, different kinds of history serve different purposes. There is user history, session history, context history and activity history. This latter history might be renamed as transaction history in order to accommodate the current approach. A history is a structure which supports the user's interactions with the system and is essential for the implementation of operations such as "'undo." Let us consider how Ada tasks might be employed in the implementation of the TRANSACTION_ UNIT. First, it is important to note that the theory of Ada tasking methodology is vast and complex. The reference work by Buhr [22] is a good introduction to tasking at "implementation" level• Ideally for the purposes of reusability of Ada software, the tasks ought to be embedded in (generic) packages. The accompa-
CONTEXT: A high-level Structuring concept for GKS input
217
Fig. 2. Lattice of abstract data type. nying methodology by which this may be achieved is the subject of a forthcoming paper. For the present, I will outline the general approach by choosing a very simple paradigm--that of the user/server. Essentially, the user calls the server to have some request processed. However, the server does not call the user. Rather a mailbox is used as an intermediary between the two. This particular paradigm is given in [19]. A MAILBOX, which is just a buffer of size 1, is implemented as the generic package: generic type ITEM is limited private: with procedure ASSIGN(IL: in out ITEM: IR: in ITEM): package MAILBOX_MODEL is type MAILBOX is limited private: procedure DEPOSIT(M: in out MAILBOX; h in ITEM); procedure COLLECT(M: in out MAILBOX; h in out ITEM): private - - F O R IMPLEMENTOR'S EYES ONLY! task type CONTROLLER is entry DEPOSIT(I: in ITEM); entry COLLECT(h in out ITEM): end CONTROLLER; type MAILBOX is new CONTROLLER; end MAILBOX_MODEL:
I
package body MAILBOX_MODEL is task body CONTROLLER is STORE: ITEM; begin accept DEPOSIT(I: in ITEM) do ASSIGN(STORE,I); end DEPOSIT: accept COLLECT(h in out ITEM) do ASSIGN(I,STORE); end COLLECT: end CONTROLLER: procedure DEPOSIT(M: in out MAILBOX; 1: in ITEM) is begin M.DEPOSIT(1); end DEPOSIT: procedure COLLECT(M: in out MAILBOX: I: in out ITEM) is begin M.COLLECT(1); end COLLECT; end MAILBOX_MODEL; Now let LOCATOR__ITEM be the object that is associated with the LOCATOR input device. Then we obtain a LOCATOR__MAILBOX thus:
package LOCATOR__MAILBOX_MODEL is new MA! LBOX_MODEL(LOCATOR__ITEM.ASSIGN);
218 _
MICHEALMAC AN AIRCHINNIGH
Different users of-the LOCATOR._MAILBOX require their own mailbox addresses. This is accomplished by using a generic package such as generic type OBJECT is limited private: package OBJECT___ADDRESS_MODEL is type OBJECT___ADDRESS is limited private; function GENERATE return OBJECT_ADDRESS: function ADDRESSEE(OA: OBJECT_ADDRESS) return OBJECT; - - this is believed to be legal in Ada procedure ASSIGN(PAL: in out OBJECT_._ADDRESS; OAR: in OBJECT__ADDRESS); private - - FOR IMPLEMENTOR'S EYES ONLY! type OBJECT___ADDRESS is access OBJECT; end OBJECT___ADDRESS_MODEL; and then package LOCATOR_MAILBOX_ADDRESS_MODEL is new OBJECT_ADDRESS_MODEL(LOCATOR-MAILBOX);
Finally, let us construct a LOCATOR_SERVER to handle the different user requests. The actual Ada code presented here is at the task level. The job of developing a generic package for servers is currently under investigation.
presentation. For example, the necessary with/use clauses have been omitted for simplicity. Furthermore, names such as LOCATOR_MAILBOX_ADDRESS must be provided via a renaming technique. This is
task LOCATOR__SERVER is entry REQUEST(LMA: LOCATOR__MAILBOX.__ADDRESS; LI: in LOCATOR._ITEM); end LOCATOR_.SERVER; task body LOCATOR__SERVER is REPLY__ADDRESS: LOCATOR__MAILBOX___ADDRESS; STORE: LOCATOR_ITEM; begin loop accept REQUEST(LMA: LOCATOR_MAILBOX_ADDRESS; LI: in LOCATOR_ITEM) do ASSIGN(REPLY_ADDRESS,LMA); ASSIGN(STORE,LI); end REQUEST; - - service this REQUEST DEPOSIT(ADDRESSEE(REPLY_ADDRESS),STORE); end loop; end LOCATOR_SERVER;
Those who are well acquainted with Ada will doubtless recognise that there are many omissions in the above
effectively done by building a package from the instantiated one and then defining
subtype LOCATOI~,_MAILBOX_ADDRESS is OBJECT__ADDRESS"
CONTEXT: A high-level structuring concept for GKS input However, a complete presentation of the Ada details will only bewilder the uninitiated. A typical U S E R _ A G E N T that avails of the services of the LOCATOR__SERVER has the general form (again as a task):
219
Acknowledgement~The initial ideas concerning CONTEXT were developed in the context ofiFIP WG2.7 to whose members 1 am very grateful. Further elaboration of the concept with particular reference to GKS took place at the EUROGRAPHICS Workshop on Graphics Programming in
task USER__AGENT; task body USER__AGENT is O W N _ A D D R E S S : LOCATOR__MAILBOX.__ADDRESS; O W N _ I T E M : LOCATOR__ITEM; begin ASSIGN(OWN_ADDRESS,GENERATE); LOCATOR_SERV ER.REQUEST(OWN__ADDRESS,OWN_ITEM); - - poll mailbox for reply select C O L L E C T ( A DDRESSEE(OWN__ADDRESS),OWN_ITEM); else - - do something while waiting? end select: end U S E R _ A G E N T : Now given this overall approach to an implementation, we can define both the USER_ZtCT1ON and SYST E M _ A C T I O N to be a L O C A T O R _ I T E M . In other words, the T R A N S A C T I O N _ U N I T consists of a pair of LOCATOR._ITEMS, the first of which is the user's request, and the second the result of the system's response. With this configuration, it is possible to build our software with "data base transaction' properties. Let me conclude this section with a brief c o m m e n t on the Ada tasks presented here. The purpose of including the Ada code was to indicate how one might proceed with an implementation of C O N T E X T using tasks embedded within generic packages. Naturally, a theory of tasking coupled with a theory of h u m a n computer interaction is necessary to obtain the "perfect" solution. Such a solution in Ada is still some distance away. There is an immediate need for rapid prototyping in Ada and evaluation of the corresponding implementations. Furthermore, experience gained in such prototyping will in turn refine the concept of C O N T E X T as outlined in this paper. O f course, CONT E X T is applicable in the general setting of h u m a n computer interaction and not just related to GKS. Again, it is to be expected that results derived from the applicability of C O N T E X T in G K S will have significant impact in the wider domain. 6. CONCLUSION Starting with a simple analogy of a journey, we have shown that the concept of C O N T E X T is a general one for all kinds of interaction. A conceptual analysis of C O N T E X T and other related notions has been presented using the formalism of conceptual graph notation. The passage from analysis to Ada package specification is straightforward. Ultimately, for a complete implementation of these concepts in Ada, the (lowlevel) task construct is essential. We have suggested a possible approach using a very simple user/server model. However, actual synchronisation details have not been addressed.
Wenschdorf. Discussions with H. Hanusa, G. Pfaff and H. Weber, in particular, sharpened those ideas. Not having a full Ada implementation at the time of writing, 1 am indebted to my colleague Hans-Juergen Kugler for his cooperation in analysing the fragments of Ada code presented herein. Finally, i wish to thank the guest editors, H. Hanusa and H. Weber, for their invitation to make this contribution.
REFERENCES
1. J. Nievergelt and J. Weyden, Sites, Nodes, and Trails: Telling the User of an Interactive System Where he is. What he can do, and How to get to places, In Methodology qflnteraclion (Edited by R. A. Guedj, P. J. W. ten Hagen, F. R. A. Hopgood, H. A. Tucker and D. A. Duce), pp. 327-338. North-Holland, Amsterdam (1980). 2. D. Everett, Working Group Report on the Design of New GKS Application Software. In Workshop on Interfacing Old and New Graphical Software to GKS (Edited by K. Brodlie and G. Pfaff). Springer-Verlag, Berlin, to be published. 3. M. Mac an Airehinnigh, A Model of the User's Conceptual Model o f . . . In User Interface Managemem Systems (Edited by G. Pfaff), pp 203-224. Spdnger-Verlag, Berlin (1985). 4. T. P. Moran, The Command Language Grammar: a representation for the user interface of interactive computer systems. Int. J. Man-Mach. Stud. 15, 3-50 (1981). 5. D. Beech and H.-J. Kugler, The Reference Mode/.for Command and Response Languages. IFIP WG2.7, to be published. 6. M. Minsky, A Framework for Representing Knowledge. In The Ps~'holog.v t?/'Compuler Vision (Edited by P. H. Winston), pp. 21 1-277. McGraw-Hill, New York (1975). 7, R. C. Schank and R. P. Abelson, Scripts, Plans. Goals and Understanding, An lnquir.v into Knowledge Understanding. Lawrence Erlbaum Associates, Hillsdale, NJ (1977). 8. G. P. Baker and P. M. S. Hacker, Essays on the Philosophical Investigations. Vol. I Willgenslein, Meaning and Underslanding. Basil Blackwell, Oxford (1983). 9. L. Wittgenstein and C. K. Ogden (trans.), Traclalus Logico-Philosophicus. Routledge & Kegan Paul, London (1972). 10. J. F. Sowa, Conceplual Stntctures: ln/ormation Processing in Mind and Machine. Addison-Wesley, London (1983). 1I. M. Mac an Airchinnigh, CAD, KE, and Ada. in Proc. of
220-
12.
13. 14. 15. 16. 17.
MICHEAL MAC AN AIRCHINNIGH
the IFIP WG5.2 ~l,'orking Conference on Knowledge Engineering in Computer-Aided Design (Edited by J. Gero). North-Holland, Amsterdam, to be published. M. Mac an Airchinnigh, Report of Working Group Omega on the User's Conceptual Model. In UserInterface Management Systems (Edited by G. Pfaff). Springer-Verlag, Berlin (1985). S. C. Dik, Functional Grammar. Foris, Dordrecht, Holland ( 1981 ). G. Enderle, K. Kansy, and G. Pfaff. Computer Graphics Programming. GKS-- The Graphics Standard. SpringerVedag, Berlin, (1983). DoD, The Ada Language ReferenceManual. ANSI/MILSTD 1815,4, Alsys. La Celle-Saint-Cloud, France (1983). M. Mac an Airchinnigh, The Specification and Implementation of GKS Application Software in Ada. Comput. Graphicv Forum 3(2), 153-167 (1984). M. Mac an Airchinnigh, CAD, GKS, and Ada. In Workshop on lnte(/acing Old and New Graphical Software to
18.
19. 20.
21. 22.
GKS (Edited by K. Brodlie and G. Pfaff). Springer-Verlag, Berlin, to be published. M. Mac an Airchinnigh, Some Educational Principles Related to the Teaching and Use of Ada. Proceedings of the Ada-Europe/AdaTEC Joint Conferenceon Industrial Applications of Ada and ProgrammingSupport Environments (Edited by J. Teller), pp 201-210. Cambridge University Press, (1985). J.G.P. Barnes, Programmingin Ada, second ed. AddisonWesley, London (1984). M. Mac an Airchinnigh, Mathematical Lattices of Abstract Data Types in Ada, In Proceedings of Colloquium on Object-based Destgn. pp. 5/1-5/7. Institute of Electrical Engineers, Savoy Place, London (Nov. 1984). M. L. Brodie, J. Mylopoulos, and J. W. Schmidt, On Conceptual Modelling. Springer-Verlag, Berlin (1984). R. J. A. Buhr, System Design with Ada. Prentice-Hall, Englewood Cliffs, NJ (1984).
"
0097-8493/85 $3.00 + .00 © 1985 Pergamon Press Ltd,
Printed in Great Britain,
Graphics Dialogue P r o g r a m m i n g
THE CONTEXT: A HIGH-LEVEL STRUCTURING CONCEPT FOR GKS INPUT MICHEAL MAC AN AIRCHINNIGH Department of Computer Science, University of Dublin. Trinity College. Dublin, Ireland Abstract--All human beings interact in some context or other. The concept of context has been explored by researchers in many different fields. A survey of some of this work is presented here. Using conceptual graph notation as a knowledge representation language, an introductory analysis of the concept of context and related notions is carried out and the results applied to GKS input. The outline of a possible implementation in Ada, with the (generic)package as the principal structuring unit and the task as the (low-level) implementation unit, is illustrated with a simple example. of contexts described above,~one identifies certain features common to all of them. Some of these are
I. I N T R O D U C T I O N
Where am I? What can I do here? How did I get here? Where can I go, and how do I get there?" [1] Everything that a human being does is done in a context. In other words, the human being's interaction with its environment takes place within a specific context. To motivate the definition of the concepts introduced in this paper, it will be helpful to consider a journey that I have undertaken in January 1984 between my home town, Maynooth, Ireland, and a small village, Wenschdorf, Federal Republic of Germany, for the purpose of attending the EUROGRAPHICS Workshop on Graphics Programming and at which, incidentally, the idea of a CONTEXT as a high-level structuring concept for GKS input first originated [2]. We can say that this journey was undertaken in the context of that Workshop. A topological diagram of the itinerary, to a first approximation, is shown in Fig. 1. To get from Maynooth to Dublin, ! travelled by bus. In this context (CXTI), my primary interaction (INT 1) was with the bus conductor from whom 1 obtained a one-way ticket in exchange for money. I travelled from Dublin to Frankfurt by plane. This was made possible in the context (CXT2) of obtaining a return ticket from my travel agent in exchange for credit. It should be noted that this interaction (INT2) in CXT2 took place prior to INTI in CXT1, though this need not have been the case. In Frankfurt I obtained a one-way ticket in exchange for money from an official of the Bundesbahn (i.e. German Railways) in order to travel by train to Miltenberg. This interaction (INT3) was done in another context (CXT3). Finally, it was necessary to get from Miltenberg to Wenschdorf. In this final context (CXT4), my interaction (INT4) was with the taxi driver who drove me there. However, no money changed hands until I arrived in Wenschdorf. At my destination, in exchange for my money, 1 received a Quittung (i.e. a receipt). Of course, the above is only an outline of the itinerary in one direction. One can refine it further to include, for example, the journey from Dublin city centre to Dublin airport by bus. In analysing the set c~ 9:3-c
( 1) an interaction took place between myself and another human being; (2) during the.interaction a transaction took place in which a service was obtained in exchange for money/credit. Part of the exchange involved the handing over ofa ticket/Quittung which, in a sense, symbolised the service offered: (3) the context, interaction, and transaction all had a finite duration and began at a specific point in time. There are obviously other common features not listed above. Among these are the mode of conveyance, and the source and destination involved. Everyone who has travelled has used contexts such as the above. We use the appropriate context to obtain the service we require. We would not expect to obtain the taxi service for the journey from Miltenberg to Wenschdorf from the bus conductor in Ireland. Such an idea is ludicrous. Thus we can conclude that users of public transport have certain conceptual models (UCMs) [3] that enable them to obtain the offered service. I propose that the CONTEXT is a structure which is a constituent part of such UCMs. Section 2 examines how the concept of CONTEXT is used in a number of disciplines, including that of computer science. This concept, together with other related notions, is expressed in the terminology of conceptual graph notation. This is the subject of Section 3. GKS input is considered in Section 4 where it is associated with the concepts developed in Section 3. Sample encodings are given in the programming language Ada.t Finally, Section 5 shows how the Ada task might be used for the implementation of the package specifications given in Section 4.
211
2. THE CONCEPT OF CONTEXT
"Commands are issued within command contexts, which are conversational contexts limiting what
t Ada is a registered trademark of the U.S. Department of Defense, Ada Joint Program Ot~ce (AJPO).
212
MICHEAL MAC AN AIRCHINNIGH
FRANKFURT (FR Germany)
D~LIN
MAYNOOTH (Ireland)
(ireland) Q
Dos
plane
train
MILTE~BE~3 ( ~ Germany)
taxi
WI~SCHDORF
(FR Germany) Fig. 1. Topological map of a journey. commands the user can issue at a given time and which define the scope of other command language entities." [4] The notion of CONTEXT as a structure for human interaction is not new. Apart from its use in the Command Language Grammar by Moran, cited above, it also turns up in the IFIP WG2.7 Reference Model for Command and Response Languages [5]. Here, "a context defines for the user which operations can be performed on which objects and the effect of those operations." In addition, there are the notions of default context, current context and context switching. Related to the concept of CONTEXT in command and response languages are the notions of frame [6] and script [7] in artificial intelligence. Essentially, a frame was to be thought of as a data structure for representing a stereotyped situation. It was supposed to consist of a two-level hierarchy. At the top level, the knowledge represented was always true (i.e. absolute knowledge). On the other level, the knowledge represented was only relative to a particular situation. A script, on the other hand, was considered to be a predetermined sequence of actions that define a situation. For example, the script for eating in a restaurant is generally well known. Researchers other than computer scientists have considered the role of context in their own respective disciplines. For example, in the field of philosophy Frege was the first to enunciate the dictum "'a word has a meaning only in the context of a sentence" [8]. This idea led to the "doctrine" ofcontextualism which purported to be a general programme for an account of language, meaning and understanding. Frege's dictum is reechoed by Wittgenstein. "Nut der Satz hat Sinn; nur in Zusammenhange des Satzes hat ein Name
Bedeuteung"t [9]. However, Wittgenstein does not completely agree with Frege. An analysis of that by which he differs from Frege would take us to far afield. For our present purposes it is sufficient to note the role of context with respect to the meaning of words/names in sentences/propositions. In the field of interactive computer graphics, the enduser of the application software expresses himself/herself in a language that consists of"words" and language. From the discussion above we may infer that all such expressions between user and program are to be understood within contexts. In other words, the context is that structure which guarantees the possibility/validity of the interaction/dialogue. 3. CONCEPTUAL GRAPH NOTATION AND FUNCTIONAL GRAMMAR
"Definition. Let p be a concept of type PROPOSITION whose referent is the set {u, . . . . . u, } of conceptual graphs: (PROPOSITION: {ul . . . . . u, }]. Then each graph ,i in referent (p) is said to be asserted by the proposition p, and ui is said to occur in the context ofp." [10]. Sowa, cited above, uses the term context much in the same manner as Wittgenstein [9]. He goes on to discuss negative contexts, outermost contexts, overlapping contexts and dominating contexts. Conceptual graphs form a knowledge representation language based on linguistics, psychology, and philosophy, and are extensively dealt with in [10]. Essentially, conceptual graph notation (CG notation) employs two distinct kinds of entities: concepts and conceptual relations. %"Only the proposition has sense; only in the context of a proposition has a name meaning."
CONTEXT: A high-levelstructuring concept for GKS input Concepts are represented by type labelsuwords in capital letters enclosed in square brackets. Thus the concept of "context" may be denoted by [CONTEXT]. Type labels are also used to represent conceptual relations. To distinguish lhe latter from concepts, round brackets are used. (OBJECT) and (DURATION). for example, denote typical conceptual relations according to Sowa. The sentence "a context is activated for a specific time period" may be represented by the conceptual graph (in linear form): [CONTEXT](OBJECT) ~ [TO_ACT1VATE](RESULT) --. [ACTIVATION: *x] (LINK) ~ [ACTIVATION: *x](DURATION) ~ [TIME_PERIOD] A CONTEXT is the OBJECT of the verb TO_ACTIVATE and the corresponding RESULT is a state called ACTIVATION. There is an anonymous LINK between the CONTEXT and the ACTIVATION state. To indicate that the same ACTIVATION is used, the , x symbol appears in the referent field of the ACTIVATION. This ACTIVATION has a DURATION which is a TIME_PERIOD. The use of CG notation as a knowledge representation language in ComputerAided Design has been explored in [11]. A moment's reflection on the above conceptual graph will reveal a major weakness in CG notation that is also shared incidentally by many sorted logic, for example. Consider DURATION. In the conceptual graph it is used as a conceptual relation linking ACTIVATION to TIME_PERIOD. However, it is conceivable that in another context we might be interested in the concept of DURATION itself! In general, conceptual relations may be subject to conceptual analysis and as such may be treated themselves as concepts. This dichotomy is resolved in CG notation by employing two different kinds of parentheses. Thus [DURATION] is distinct from (DURATION). In Ada, type labels are provided by a generic package. Separate instantiations for concept type labels and conceptual relation type labels preserve this distinction [11]. Hence the strong typing of Ada enables us to determine whether we are dealing with [DURATION] or (DURATION). Referring to the contexts C X T I . . C X T 4 in the introduction, let us consider how we may further elaborate on the definition of the concept CONTEXT. We have seen that a CONTEXT contains a set (possibly empty) of INTERACTIONs, each of which, in turn, contains a set (possibly empty) of TRANSACTIONs. A CONTEXT is possessed by a human being. In general, we may widen this to some ANIMATE object in order to allow for the possibility of a robot, or a computer program, for example, to possess a CONTEXT. As noted above, a CONTEXT may be activated by the ANIMATE object and endure for a specific TIME_PERIOD. At present, it seems reasonable that the possessor of the CONTEXT should also be the one who activates that CONTEXT. INTERACTIONs and TRANSACTIONs also have DURATION. Further-
213
more, we can identify a POINT_IN_TIME at which each of these, as well as the CONTEXT, are initiated. Continuing in this vein, we eventually build up a working definition of the concept. A possible expression in CG notation might be [CONTEXT] (OBJECT) - - [TO_ACTIVATE](RESULT) ~ [ACTIVATION: *x] (AGENT) ~ [ANIMATE: ,y] (LINK) ~ [ACTIVATION: *x](DURATION) ~ [TIME_PERIOD] (POINT_IN_TIME) - - [TIME] (POSSESSOR) ~ [ANIMATE: ,y] (CONTENT) - - [INTERACTION: I*--l] Let us turn now to the concept of INTERACTION. This is a state which is the RESULT of the verb TO_INTERACT. INTERgCTION involves a twoway COMMUNICATION. The concept TO_COMMUNICATE and its expression in CG notation using a variety of different natural languages may be found in [12]. One may construct type definitions in CG notation out of lambda expressions, the bodies of which are conceptual graphs. One possible type definition for TO_INTERACT in terms of the concept TO_COMMUNICATE, taken from [11] is type TO_INTERACT (x. y) is Lr [TO_COMMUNICATE: *x] ( A G E N T ) - [ANIMATE: ,p] (RECIPIENT) ~ [ANIMATE: ,q] (INSTRUMENT) - - [ENTITY] (OBJECT) - - [INFORMATION] and ~.y [TO_COMMUNICATE: ,y] (AGENT) ~ [ANIMATE: ,q] (RECIPIENT) - - [ANIMATE: ,p] (INSTRUMENT) - - [ENTITY] (OBJECT) - - [INFORMATION] We may now use this type definition in the conceptual graph for the concept INTERACTION:
[INTERACTION] (RESULT) - - [TO_INTERACT] (DURATION) - - [TIME_PERIOD] (POINT_IN_TIME) ---, [TIME] (CONTENT) ~ [TRANSACTION: {,t/] Note that for both the CONTEXT and the INTERACTION, I have specified a POINT_IN_TIME at which they commence. This suggests a possible reorganisation of the graphs to allow for a TO__,BEGIN verb. Finally, I wish to consider the concept TRANSACTION which is a result of the verb TO_TRANSACT. Let us look once more at CXTI which involves a journey from Maynooth to Dublin by bus. INTI was concerned with the obtaining of a ticket in excliange for a sum of money from the bus conductor. This exchange is effectively a TRANSACTION. To distinguish clearly between a TRANSACTION and an INTERACTION, let us sup-
214
MICHEAL MAC AN AIRCHINNIGH
pose that at some~other time on the bus journey a ticket inspector gets on the bus. In another INTERACTION between myself and the inspector, he/she validates the TRANSACTION that took place in INTl. This VALIDATION process which may be considered to be a kind of TRANSACTION is different in nature from that which took place in INTl. Using a type definition and the concept TO_GIVE, we build the following conceptual graph: type TO_TRANSACT(x, y) is k r [TO_GIVE: *x] (AGENT) - - [ANIMATE: ,p] (RECIPIENT) ~ [ANIMATE: ,q] (OBJECT) ~ [ENTITY] and hy [TO_GIVE: ,y] (AGENT) ---, [ANIMATE: ,q] (RECIPIENT) - - [ANIMATE: ,p] (OBJECT) ~ [ENTITY] Just as in the case of INTERACTION, we would now build a conceptual graph for TRANSACTION. The details are left to the reader. As noted in [12], CG notation is a possible basis for conducting further research in the formal specification of UCMs and user-computer interaction. However, I feel that it is not complete in itself. To complement the CG notation l am presently looking at the functional grammar approach (FG) of Dik [ 13]. Essentially, FG considers language as an instrument of social interaction between human beings, used with the primary aim of establishing communicative relations between speakers and addressees. Thus it would seem that FG would be eminently suited to the area of user-computer interaction. There is a correspondence between the FG of Dik and the CG notation of Sowa, which is not unexpected, since conceptual graphs of a particular kind can be mapped into first order predicate calculus, and Dik's FG is based on the concept of (nuclear) predicates. Consider, for example, the conceptual graph of the verb TO_GIVE: [10] [TO_GIVE] (AGENT) - - [ANIMATE] (RECIPIENT) - - [ANIMATE] (OBJECT) ~ [ENTITY] The corresponding nuclear predicate [13] is givev[x~ :animate(xt)]^s(x2)Go[X3:animate(x3)]R~ where V denotes a Verb, Ag an Agent, Go a Goal, and Rec a Recipient. The two expressions are practically identical! Because of space considerations, I will touch upon two aspects of FG that are of immediate interest, but only very briefly. First, there are the so-called pragmatic functions, two of which are external---_Theme and Tail, and two of which are internal--Topic and Focus. The T h e m e specifies the universe of discourse with respect to which the subsequent predication is presented as
relevant. The Tail presents, as an "'afterthought'" to the predication, information meant to clarify or modify it. Topic presents the entity "'about" which the predication predicates something in the given setting. The Focus presents what is relatively the most important and salient information in the given setting. Consider INTI of CXTI. It is a peculiarity of the Dublin area public bus transport system that to obtain a ticket from a conductor, it is sufficient to state the fare. in my own case the expression "'one pound please" is all that is required. From the point of view of Dik's pragmatic functions this constitutes the Focus of the expression. There is no explicit Theme, Tail or Topic. On the other hand, in CXT3, 1 do not know how much the train fare will cost. A suitable introductory statement that I use is something like "Ich moechte yon hier nach Miltenberg fahren"t. The Focus in this case is "'nach Miltenberg.'" The usefulness of these pragmatic functions with respect to the user-computer dialogue lies in the fact that they provide guidelines for the actualstructure of the (command language) expressions involved. Second, one of the goals in the development of the formal specification of UCMs is to find a canonical form, that is natural language independent, for the specification of the concepts and conceptual relations possessed by the user [12], The work done by Dik on language independent preferred order of constituents (LIPOC) seems to be of particular relevance. I quote: "Although much more evidence will have to be produced in order to further substantiate the quite general claims made in this chapter, especially on a cross-linguistic basis, we believe that there is sufficient support for the general hypothesis that constituents prefer to be linearised in an order of increasing internal complexity, and that this preference may interfere with patterns which we would expect in terms of other rules and principles operating in the language" [l 3]. How LIPOC relates to user-computer dialogue is a topic worthy of future research. 4. GKS INPUT AND THE GKS CONTEXT "The GKS input concept represents a rather complex area of application and implementation details." [ 14] In this section 1 want to show how the concept of CONTEXT and the other related notions that we have seen so far may be used to reduce the complexity presented by the GKS logical input devices, their associated values and operating modes. It is assumed that the reader is already familiar with the logical input devices of GKS. A good reference work is that cited above [14]. At the EUROGRAPH1CS Workshop on Graphics Programming, a working group was given the task of considering how to design new GKS application software [2]. It was there that the idea of a CONTEXT concept might prove useful as a high-level structuring concept for GKS input. A distinction was made, by Weber, between a GKS_CONTEXT and a
t I want to travel from here to Miltenberg.
CONTEXT: A high-levelstructuring concept for GKS input human factors context (HF_CONTEXT). Specifically, the HF_CONTEXT belonged to the UCM whereas the GKS_CONTEXT was to be considered as a programming concept. Initially, a GKS_CONTEXT was viewed as an analogue'of the GKS WORKSTATION concept and there was to be a one-one correspondence between the two. Default information for such a context was stored in a CONTEXT_DESCRIPTION_ TABLE (CDT). Upon invocation of the OPEN_ CONTEXT function, this information would be copied into a CONTEXT__STATE_L1ST (CSL). Other functions that might operate on a context were CLOSE_CONTEXT. ACTIVATE_CONTEXT and
215
Ada has already been used for the specification and implementation of GKS application software [l 6], applied to the computational geometry facet of Computer-Aided Design [l 7], and for the encoding of CG Notation [l I]. However, the particular methodology adopted, AdaM, is based on the abstract data type approach. This methodology and the corresponding Ada programming support environment, INTERAda, is outlined in [18]. AdaM is an object oriented Ada software methodology wherein the objects of interest together with their respective operations are encapsulated as an Ada package. For example, an outline package specification for a GKS_CONTEXT might take the f o r m :
- - some with/use clauses package GKS_CONTEXT_MODEL is type GKS_CONTEXT is limited private; function MAKE (CXTID: STRING: - - n a m e of the context SINT: SET_OF_INTERACTION_UNIT; T: TIME: --creation time of the context •
.
,)
return GKS_CONTEXT: function SELECT_CXT1D(CXT: GKS_CONTEXT) return STRING: function SELECT_SINT(CXT: GKS_CONTEXT) return SET_OF_INTERACTION_UNIT; function SELECT_T(CXT: GKS_CONTEXT) return TIME; ----
.
.
.
procedure ACTIVATE(CXT: GKS_CONTEXT; D: D U R A T I O N : . . . ) ; ----
.
.
.
private - - F O R IMPLEMENTOR'S EYES ONLY! end GKS_CONTEXT_MODEL;
DEACTIVATE_CONTEXT. The principal constituent part of a GKS_CONTEXT was the INTERACTION_UNIT. It, in turn, was thought to consist of prompts, echoes, user actions, evaluated results and state changes. The "goodness of fit" between the HF_CONTEXT and the corresponding GKS_CONTEXT would determine the quality of the interaction. Using these original findings as a starting point and in
The types STRING, TIME, and DURATION are predefined in Ada. The generic package feature of Ada allows one to build the usual kind ofcompoter science data structures: SET_OF(. • • ), STACK_OF(- • • ), QUEUE_OF(. • • ), etc. Barnes [9] illustrates the construction of a generic package for sets. However, his package is totally inadequate for our purposes since it can only be instantiated to give sets of objects that have no intrinsic structure. We require a generic package of the form:
generic type ELEMENT is limited private; with function SELECT_S(E: ELEMENT) return STRING; with function EQUAL(El, E2: ELEMENT)return BOOLEAN; package SET_OF_MODEL is type SET is limited private; - - etc.
the light of the conceptual analysis carried out in the earlier part of this paper, 1 propose to present some possible encodings in the programming language Ada [15].
where S E L E C T S returns the name of the base element of the set and the function EQUAL is used in the determination of set membership, equality being based on structure and not on name. We can use such a generic package as follows
216
MIcHEALMAC AN AIRCHINNIGH
package SET_Old_INTERACTION--UNIT is new SET_OF_MODEL(INTERACTION_UNIT, SELECT_INT1D, EQUAL): Let us now turn our attention to the INTERACTION_UNIT as the current object of interest. As a first approximation, we will consider it to be composed of a LOGICAL_INPUT_DEVICE, an OPERATING_MODE and a set of TRANSACTION_UNIT. The package specification outline is, therefore,
5. ADA TASKS
" ' . . . the package should be considered to be the main tool for structuring purposes whereas the task is intended for synchronisation. Thus typical subsystems will consist of a (possibly generic) package containing one or more tasks." [19]
- - s o m e with/use clauses package INTERACTION_UNIT_MODEL is type INTERACTION_UNIT is limited private; function MAKE(INTID: STRING: - - n a m e of the interaction unit LID: LOG1CAI__INPUT_DEVICE; OM: OPERATING_MODE; STRNS: SET_OF_TRANSACTION_UNIT; •
.
,
.)
return INTERACTION_UNIT; function SELECT_INTID(INT: INTERACTION_UNIT) return STRING: --etc., as for GKS_CONTEXT end INTERACTION_UNIT_MODEL; Finally, a TRANSACTION_UNIT is considered to be an object consisting of a USER_ACTION, SYSTEM_ACTION pair:
The TRANSACTION is a concept which is of great importance in the area of data base theory. [21]. Although we have defined our own concept, it would be
- - s o m e with/use clauses package TRANSACTION_UNIT_MODEL is type TRANSACTION_UNIT is limited private; function MAKE(TRNSID: STRING; UA: USER_ACTION; SA: S Y S T E M _ A C T I O N : . . . ) return TRANSACTION_UNIT; --etc.
end TRANSACTION_UN IT_MODEL; The overall approach to the implementation in Ada of the concepts specified in CG notation should now become clearer. Although only a very cursory sketch has been given, the objectification of the concepts via Ada package specification is reducing the overall complexity. At this point it would be helpful to represent the information generated so far by an abstract data type (ADT) lattice [20] (see Fig. 2). There are two important observations which ought to be made at this point. First, no implementation details have been given. There are even some named but as yet undefined ADTs, such as LOGICAL_ INPUT_DEVICE, which are of great interest, especially to implementers of GKS. Second, apart from the conceptual analysis presented earlier, no semantics have been given. One possible approach to the incorporation of semantics into Ada package specifications has been illustrated in [l 6]. The GKS_CONTEXT concept, introduced at Wenschdorf, has undergone a transformation in the process of Ada package specification. Tx~conclude this paper let us turn to Ada's tasking mechanism, the use of which is essential for real interactive programs.
foolish not to learn from the work and experience of others. One of its important properties is that of atomicity "in that if one component operation fails then the transaction fails and all of its (partial) effects are undone" [21]. Such a notion fits in nicely with the history concept proposed for the construction of usercomputer interfaces [3]. In a user interface management syslem, different kinds of history serve different purposes. There is user history, session history, context history and activity history. This latter history might be renamed as transaction history in order to accommodate the current approach. A history is a structure which supports the user's interactions with the system and is essential for the implementation of operations such as "'undo." Let us consider how Ada tasks might be employed in the implementation of the TRANSACTION_ UNIT. First, it is important to note that the theory of Ada tasking methodology is vast and complex. The reference work by Buhr [22] is a good introduction to tasking at "implementation" level• Ideally for the purposes of reusability of Ada software, the tasks ought to be embedded in (generic) packages. The accompa-
CONTEXT: A high-level Structuring concept for GKS input
217
Fig. 2. Lattice of abstract data type. nying methodology by which this may be achieved is the subject of a forthcoming paper. For the present, I will outline the general approach by choosing a very simple paradigm--that of the user/server. Essentially, the user calls the server to have some request processed. However, the server does not call the user. Rather a mailbox is used as an intermediary between the two. This particular paradigm is given in [19]. A MAILBOX, which is just a buffer of size 1, is implemented as the generic package: generic type ITEM is limited private: with procedure ASSIGN(IL: in out ITEM: IR: in ITEM): package MAILBOX_MODEL is type MAILBOX is limited private: procedure DEPOSIT(M: in out MAILBOX; h in ITEM); procedure COLLECT(M: in out MAILBOX; h in out ITEM): private - - F O R IMPLEMENTOR'S EYES ONLY! task type CONTROLLER is entry DEPOSIT(I: in ITEM); entry COLLECT(h in out ITEM): end CONTROLLER; type MAILBOX is new CONTROLLER; end MAILBOX_MODEL:
I
package body MAILBOX_MODEL is task body CONTROLLER is STORE: ITEM; begin accept DEPOSIT(I: in ITEM) do ASSIGN(STORE,I); end DEPOSIT: accept COLLECT(h in out ITEM) do ASSIGN(I,STORE); end COLLECT: end CONTROLLER: procedure DEPOSIT(M: in out MAILBOX; 1: in ITEM) is begin M.DEPOSIT(1); end DEPOSIT: procedure COLLECT(M: in out MAILBOX: I: in out ITEM) is begin M.COLLECT(1); end COLLECT; end MAILBOX_MODEL; Now let LOCATOR__ITEM be the object that is associated with the LOCATOR input device. Then we obtain a LOCATOR__MAILBOX thus:
package LOCATOR__MAILBOX_MODEL is new MA! LBOX_MODEL(LOCATOR__ITEM.ASSIGN);
218 _
MICHEALMAC AN AIRCHINNIGH
Different users of-the LOCATOR._MAILBOX require their own mailbox addresses. This is accomplished by using a generic package such as generic type OBJECT is limited private: package OBJECT___ADDRESS_MODEL is type OBJECT___ADDRESS is limited private; function GENERATE return OBJECT_ADDRESS: function ADDRESSEE(OA: OBJECT_ADDRESS) return OBJECT; - - this is believed to be legal in Ada procedure ASSIGN(PAL: in out OBJECT_._ADDRESS; OAR: in OBJECT__ADDRESS); private - - FOR IMPLEMENTOR'S EYES ONLY! type OBJECT___ADDRESS is access OBJECT; end OBJECT___ADDRESS_MODEL; and then package LOCATOR_MAILBOX_ADDRESS_MODEL is new OBJECT_ADDRESS_MODEL(LOCATOR-MAILBOX);
Finally, let us construct a LOCATOR_SERVER to handle the different user requests. The actual Ada code presented here is at the task level. The job of developing a generic package for servers is currently under investigation.
presentation. For example, the necessary with/use clauses have been omitted for simplicity. Furthermore, names such as LOCATOR_MAILBOX_ADDRESS must be provided via a renaming technique. This is
task LOCATOR__SERVER is entry REQUEST(LMA: LOCATOR__MAILBOX.__ADDRESS; LI: in LOCATOR._ITEM); end LOCATOR_.SERVER; task body LOCATOR__SERVER is REPLY__ADDRESS: LOCATOR__MAILBOX___ADDRESS; STORE: LOCATOR_ITEM; begin loop accept REQUEST(LMA: LOCATOR_MAILBOX_ADDRESS; LI: in LOCATOR_ITEM) do ASSIGN(REPLY_ADDRESS,LMA); ASSIGN(STORE,LI); end REQUEST; - - service this REQUEST DEPOSIT(ADDRESSEE(REPLY_ADDRESS),STORE); end loop; end LOCATOR_SERVER;
Those who are well acquainted with Ada will doubtless recognise that there are many omissions in the above
effectively done by building a package from the instantiated one and then defining
subtype LOCATOI~,_MAILBOX_ADDRESS is OBJECT__ADDRESS"
CONTEXT: A high-level structuring concept for GKS input However, a complete presentation of the Ada details will only bewilder the uninitiated. A typical U S E R _ A G E N T that avails of the services of the LOCATOR__SERVER has the general form (again as a task):
219
Acknowledgement~The initial ideas concerning CONTEXT were developed in the context ofiFIP WG2.7 to whose members 1 am very grateful. Further elaboration of the concept with particular reference to GKS took place at the EUROGRAPHICS Workshop on Graphics Programming in
task USER__AGENT; task body USER__AGENT is O W N _ A D D R E S S : LOCATOR__MAILBOX.__ADDRESS; O W N _ I T E M : LOCATOR__ITEM; begin ASSIGN(OWN_ADDRESS,GENERATE); LOCATOR_SERV ER.REQUEST(OWN__ADDRESS,OWN_ITEM); - - poll mailbox for reply select C O L L E C T ( A DDRESSEE(OWN__ADDRESS),OWN_ITEM); else - - do something while waiting? end select: end U S E R _ A G E N T : Now given this overall approach to an implementation, we can define both the USER_ZtCT1ON and SYST E M _ A C T I O N to be a L O C A T O R _ I T E M . In other words, the T R A N S A C T I O N _ U N I T consists of a pair of LOCATOR._ITEMS, the first of which is the user's request, and the second the result of the system's response. With this configuration, it is possible to build our software with "data base transaction' properties. Let me conclude this section with a brief c o m m e n t on the Ada tasks presented here. The purpose of including the Ada code was to indicate how one might proceed with an implementation of C O N T E X T using tasks embedded within generic packages. Naturally, a theory of tasking coupled with a theory of h u m a n computer interaction is necessary to obtain the "perfect" solution. Such a solution in Ada is still some distance away. There is an immediate need for rapid prototyping in Ada and evaluation of the corresponding implementations. Furthermore, experience gained in such prototyping will in turn refine the concept of C O N T E X T as outlined in this paper. O f course, CONT E X T is applicable in the general setting of h u m a n computer interaction and not just related to GKS. Again, it is to be expected that results derived from the applicability of C O N T E X T in G K S will have significant impact in the wider domain. 6. CONCLUSION Starting with a simple analogy of a journey, we have shown that the concept of C O N T E X T is a general one for all kinds of interaction. A conceptual analysis of C O N T E X T and other related notions has been presented using the formalism of conceptual graph notation. The passage from analysis to Ada package specification is straightforward. Ultimately, for a complete implementation of these concepts in Ada, the (lowlevel) task construct is essential. We have suggested a possible approach using a very simple user/server model. However, actual synchronisation details have not been addressed.
Wenschdorf. Discussions with H. Hanusa, G. Pfaff and H. Weber, in particular, sharpened those ideas. Not having a full Ada implementation at the time of writing, 1 am indebted to my colleague Hans-Juergen Kugler for his cooperation in analysing the fragments of Ada code presented herein. Finally, i wish to thank the guest editors, H. Hanusa and H. Weber, for their invitation to make this contribution.
REFERENCES
1. J. Nievergelt and J. Weyden, Sites, Nodes, and Trails: Telling the User of an Interactive System Where he is. What he can do, and How to get to places, In Methodology qflnteraclion (Edited by R. A. Guedj, P. J. W. ten Hagen, F. R. A. Hopgood, H. A. Tucker and D. A. Duce), pp. 327-338. North-Holland, Amsterdam (1980). 2. D. Everett, Working Group Report on the Design of New GKS Application Software. In Workshop on Interfacing Old and New Graphical Software to GKS (Edited by K. Brodlie and G. Pfaff). Springer-Verlag, Berlin, to be published. 3. M. Mac an Airehinnigh, A Model of the User's Conceptual Model o f . . . In User Interface Managemem Systems (Edited by G. Pfaff), pp 203-224. Spdnger-Verlag, Berlin (1985). 4. T. P. Moran, The Command Language Grammar: a representation for the user interface of interactive computer systems. Int. J. Man-Mach. Stud. 15, 3-50 (1981). 5. D. Beech and H.-J. Kugler, The Reference Mode/.for Command and Response Languages. IFIP WG2.7, to be published. 6. M. Minsky, A Framework for Representing Knowledge. In The Ps~'holog.v t?/'Compuler Vision (Edited by P. H. Winston), pp. 21 1-277. McGraw-Hill, New York (1975). 7, R. C. Schank and R. P. Abelson, Scripts, Plans. Goals and Understanding, An lnquir.v into Knowledge Understanding. Lawrence Erlbaum Associates, Hillsdale, NJ (1977). 8. G. P. Baker and P. M. S. Hacker, Essays on the Philosophical Investigations. Vol. I Willgenslein, Meaning and Underslanding. Basil Blackwell, Oxford (1983). 9. L. Wittgenstein and C. K. Ogden (trans.), Traclalus Logico-Philosophicus. Routledge & Kegan Paul, London (1972). 10. J. F. Sowa, Conceplual Stntctures: ln/ormation Processing in Mind and Machine. Addison-Wesley, London (1983). 1I. M. Mac an Airchinnigh, CAD, KE, and Ada. in Proc. of
220-
12.
13. 14. 15. 16. 17.
MICHEAL MAC AN AIRCHINNIGH
the IFIP WG5.2 ~l,'orking Conference on Knowledge Engineering in Computer-Aided Design (Edited by J. Gero). North-Holland, Amsterdam, to be published. M. Mac an Airchinnigh, Report of Working Group Omega on the User's Conceptual Model. In UserInterface Management Systems (Edited by G. Pfaff). Springer-Verlag, Berlin (1985). S. C. Dik, Functional Grammar. Foris, Dordrecht, Holland ( 1981 ). G. Enderle, K. Kansy, and G. Pfaff. Computer Graphics Programming. GKS-- The Graphics Standard. SpringerVedag, Berlin, (1983). DoD, The Ada Language ReferenceManual. ANSI/MILSTD 1815,4, Alsys. La Celle-Saint-Cloud, France (1983). M. Mac an Airchinnigh, The Specification and Implementation of GKS Application Software in Ada. Comput. Graphicv Forum 3(2), 153-167 (1984). M. Mac an Airchinnigh, CAD, GKS, and Ada. In Workshop on lnte(/acing Old and New Graphical Software to
18.
19. 20.
21. 22.
GKS (Edited by K. Brodlie and G. Pfaff). Springer-Verlag, Berlin, to be published. M. Mac an Airchinnigh, Some Educational Principles Related to the Teaching and Use of Ada. Proceedings of the Ada-Europe/AdaTEC Joint Conferenceon Industrial Applications of Ada and ProgrammingSupport Environments (Edited by J. Teller), pp 201-210. Cambridge University Press, (1985). J.G.P. Barnes, Programmingin Ada, second ed. AddisonWesley, London (1984). M. Mac an Airchinnigh, Mathematical Lattices of Abstract Data Types in Ada, In Proceedings of Colloquium on Object-based Destgn. pp. 5/1-5/7. Institute of Electrical Engineers, Savoy Place, London (Nov. 1984). M. L. Brodie, J. Mylopoulos, and J. W. Schmidt, On Conceptual Modelling. Springer-Verlag, Berlin (1984). R. J. A. Buhr, System Design with Ada. Prentice-Hall, Englewood Cliffs, NJ (1984).