Large Human-Machine Information Spaces

1 · The .!.-SPA~ Concept

Information growth in mod~rn society is out­ pacing the individual human s ability to access and synthesize information. While th1s froblem applies to all segments of society, it 1a most noticeable in large commercial and governmental organizations, where teams of both technical and non-technical professionals must work coopera­ tively toward goals whose solutions demand the coordination of substantial amounts of information in a timely fashion. The very existence of such large societal entities and their often ambitious goals can be attrihuted, in part, to computers and advanced software tools. It seems appropriate, therefore, that computers be applied toward the solution of problems which result from this infor­ mation explosion.

We deocribe here the I-SPAC!<; project, a human-machine system designed to interface both technical and non-technical professionals to the large, dynamic, and diffuse information space" in which they conduct their daily professional activities. Tht's project sharjs some goals with the PI~ project Go4dstein 19U0a and the ZOG pro­ ject LNevell 1 77J, both advanced human-machine information systems. However, in our project, more emphasis is placed on the real-time acquisi­ tion and synthesis of information from diverse, often geographically distributed sources.

Goddard Space Flight Center, an example of an organization with needs in these areas, is the environment for which we are designing the current I-SPAC~;. At this Ctmter, '"' wtny ., ,. ;>O data pro­ cessing "empires" engage in project-spec1fic activities involving the engineerin6 1 science, and administration of near-earth satellltes. Data is everywh~re: science databases, engineering infor­ mation tsome on-line, some not), administrative

* This research was supported by the Goddard Space Flight Center under contract NASS-25764.

Chuck Rieger, Hichard Wood, C:lizaueth Allen

l!,aryland Artificial Intelligence Group Department of Computer Science University of ~i aryland College Park, l·iaryland 20742

schedules, system documentation, exptlriment schedules, and so forth. While each empire r·unu adequately, there is no central inforn·ation hub which allows, for example, a utlwildered visiting scientist to gain a t;rasp of what science data is available, or a Goddard administrator to ascertain the adrainistra tive or technical status of some subproject. '£he dynamic nature of (;oddard s rnis­ sion operations, and the need for timely access of information, magnify the basic problem of a human's inability to deal with massive amounts of infonnation.

The I-SPACE is a frototyve information huu for Goddard. By logg1ng into this hub, a user enters the Goddard information space, ~ poten­ tially vast collection of frames takld to Smalltalk's classes and object~ lincalls 197& 'J~s used in the PIE system Goldstein 198 b J. Hegions of }he I-SPACE de~l wi h various aspects of Goddard s operations te.g., science, engineer­ ing, specific projects, administration, mainte­ nancef experiment scheduling, specific space­ craft 1 and the user roams through this space intel 1gently assisted by the system. As he proceeds, the current frame generates a high reso­ lution CRT representat~on of itself as a form with a collectiQn of slots tthe specific contents of the frame). When he reaches 8 frame of in~erest 1 he requests that the I-SPACt. system "focus' that frame. As we describe below, a focused frame puts the user in real-time touch with that frame's con­ tents, providing in effect a constantly updated, synthesized view of selected I-SPAC~ infonnation relevant to some task. "Invoking" a focused frame's slot is tantamount to reguesting that some computation be performed, so tnat the 1-SPAC~ is in fact a programming environment as well as an information system. In effect, the I-SPACE replaces the conventional operating system.

In the sections below, we describe the system's conceptual design, hardware and software architectures, hwnan-mach1ne interface and current and potential qualities as an artiticially intelligent manager of larce amounts of infonna­ tior..

2 . ~onceptual Design

The main goal of an I-SPACE is to deliver a simple interface through wh i ch the user cains screen access to all information and tools appropriate to the solution of his task at hand. A second goal is that infonnation be delivered in a dynamic fashion, which often means real-time. The user must be given the illusion of looking throuch powerful windows at data that may ue chang1ng by the second or minute. At GoddardL such data could be orbital or eneineerinr. data Irom 8 s pacecraft, data beinc routed from one administrator's screen to another's scree11, newly updated science data, a bulletin about a hardware failure or schedule change , and so forth. '£he user must be given direct conduits to and from the informs tion sources with wh i ch he must deal in perfonning his job.

An interesting ima6e comes to mind at God­ dard, where there are already many pools of infor­ mation individually managed by ex1sting equipment.

Suppose there were a room at Goddard whose walls were covered with information conduits flowing to every reach of the organization. Suppose also that a user enters the room and, using "patch cords", simultaneously taps into some arbitrarily chosen set of conduits and interacts with the information sources at the other ends of those conduits in a vholistic fashion. For example information received from various conduits mighl be combined to derive certain synthesized informa­ tion, or information might be sent to several con­ duits to effect a complex task. Further suppose that each specific setup of patch cords is named, saved, and later reinstalled automatically to bring the user back to the same information con­ text when he next enters the room. Finally, ima­ gine that many users are in this room, all simul­ taneously patching to and sharing sets of conduits with minimal interference.

Would not such a system be a foundation for a very intelligent distributed information system? And would not such a system represent an incremen­ tal advance in interfacing humans to large computer-based information systems? We, of course, believe that both answers are yes!

The I-SPACE conc,ptual design follows this image closely (Fig. 1;. The "room" is the central I-SPAC~ computer, currently our Departmental VAX 11/780 running C and LISP under UNIX. The valls filled with information conduits~ v~ich we call th9 I-BANK, will be realized by ZMOv LRieger 1981] ~Appendix), a 256 processor research com­ puter under current construction by our AI group lZMOB i~ currently being simulated by UNIX processes;. The collections of patch cords that route, synthesize 1 and present information from the conduits are tne I-SPACE frames. The ability for many users to use the room simultaneously translates to our implementation of the I-SPACE as a UNIX shell which coordinates several UNIX processes per user.

2 . 1. I-SPACE Frames --------

I-SPACE frames are LISP data structures that contain all the information required to set up, maintain, synthesize, and display information from a set of information "conduits" on regions of the user's screen. Structurally, a frame is a collec­ tion of named slots. Each frame corresponds to an activity 1 or local environment 1 upon which a user might v~sh to focus his a·ten}ion. Bach slot represents an aspect of the frame s environment, and generally will be responsible for bringing a tool, service, or information to the user via a region of h~s display screen. Visually, a frame resembles a form-like description of an associated I-SPACE activity. It is presented by displaying all its slots at an appropriate level of activa­ tion for that user. Each slot is presented as a three window display: the slot name, the slot value or work area, and a status region. The shapes and locations of windows on the screen, and whether or not all three are displayed at the current level of activation are init~ally deter­ mined by information in the frame·s representation. ·

Categorically, I-SPACE frames include :

MBNU FRAMES: Frames whose slots will move --~user to other frames in the re­ ~ion of the 1-SPACB where the user ~s presently situated.

REAL-TIME CONTHOL FRAMES: ~' rames whose ---slOts g~ve ~er access to real­ time information about ~ynamic re­ gions of the I-SPACE.

INFORMATION FRAMI>S: Frames whose slots prov~de--wTndows into external data­ bases.

DOCUMENTATION FHAMI>S: Frames that docu­ ------merrr--Teatures and capabilities of the I-SPACE itself.

SYSTB~l TOOL FRAMES: ---user- -access tools, such as languages, an~ Frames that give the to standard system editors, higher level utility packages.

I-SPACE DEVELOPMEN'r FRAMES: Frames that ----allow the user--tO extend, modifyJ and create new I-SPAC!> frames an procedures, and that deliver I-SPACE status and user information.

Within each category there is considerable diver­ sity. For example, administrative plans and schedules, science data, engineering schedules , and build1ng and grounds maintenance are all exam­ ples of information frames, found in different regions of the 1-SPAC!>. Real-time interpersonal communications! satellite science and engineering control channe s, and ground-based equipment moni­ tors and sensors are all examples of real-time control frames that reside in various reaches of the I-SPACE. Furthermore, most frarnes will have characteristics of several of these categories, since the slots which comprise the frame may address different needs. For example, one user may find ij; convenient to define a frame whose slots ~r': l1 J a screen-screen link with a 90lleague, ~2; a real-time conduit to a sat~lliteL ~3) a win­ dow to an external datab,s~, l4) a t'ORTHA~ pro­ gramming environment, and \5J a window into a local piece of documentation. Focusing such a frame would set up all the necessary communica­ tions channels, then present the user with this miniature world which keeps him in touch with several parts ot his environment simultaneously.

Slots

The logic of a slot depends upon the nature of the task it is designed to perfonu. 'i'he slots of a menu frame are generally descriptions of other frames to which the user can move. The slots of a real-time frame associated with the attitude control of a satellite would have names like "Current Attitude" "Alter Current Attitude", and so forth. The sl\)ts of an infonotation frame about an administrator s weekly schedule would have names like "Person For Whom Schedule Desired", "Week Desired" and "The Schedule". Slots in a system tool tram~ for a class of util~tie~ might be such things as Run File Transporter , Rew1nd Tape", an~ so forth. Slots of a higher level language to111 su11h as LISP migh~ b~ "Run The Interpreter , Debug Some Code 1 Load Saved Code , and so forth. Generally, slo·s will follow an imperative style of programming, and the invo­ ca~ion of a slot always means "do your thing for me .

Frame and Slot Activation Levels

Three ~evels of frame/,slot possible: browse", "focus', and three "activation procedures" can with each slot of a frame, 11ctivat~on are invoke . Up to be associated each procedure correspondinG to one of the three levels of activation. When the user initially brin~s s frame to his screen, the entire frame is act1vated at the browse level by individyally efecuting each slot's browse level procedur11 ~if any), which then performs a computation ~t¥pically one which displays the name of the slot 1n the name window and, perhaps, other information in the value win­ dow.) Since activati9n procedures can also be sen­ sitized to the users priority and clearance lev­ els, different events may occur for different users when an activation procedure is applied. Typically, brow11e level l!rocedures will attempt to present only enough inJonnation to give the user an overview of the frame s contents or capabili­ ties, under the assumption that the user is not interested in frames he passes through in reaching his target frame in the I-SPAC~.

When he reaches a frame in the I-SPfiC~ witu which he wishes to interact, the user focuses that frame. This causes all browse level activa­ tion procedures su~erceded by focus level pro­ cedures to be terrnna ted r and all superceding focus level procedures "o be applied. Conceptu­ ally, this results in more detailed or accurate services being run at each slot.

In either browse or focus mode, the user can move to a certain slot and invoke it. If the invoke level activation procedure exists for that slot and if it is determined that the user is qualified to invoke that slot, the invoke level procedure supercedes the running browse or focus level procedure at the slot, tjpically resulting in some control or sensing event within the I­ SPACI!:. When the invoke procedure relinquishes con­ trol, the slot is returned to its ~rev1ous activa­ tion level. When the entire frame 1s left, it may 9e left either in a focused Qr defocused state t i.e. , left active, or discarded), permit tint; the user t6 interact sequentially with several focused frames (which are v1sually overlaid and restored on the screen). As in f.II!:, the I-SPACE U§er inter­ face provideos for the · 'cluttered desktop' display control 1 where partially occluded frames may actu­ ally st1ll be running in focus mode and keeping themselves up to date visually even though they are not at the top of the pile.

Invoking an I-SPACE frame's slot is tan­ tamount to computin~. Since all activation pro­ cedures are unrestr1cted LISP functions, the effects on the I-SPACE of an invoked slot can be srbitrarf. Simple examples of invocation results are sue things as one-time data acquisition and displa_y e.r,. 1 a therm~l value for a satellite, a fact from a aata base), and frame changing (e.g., by invokinr, a "menu" frame's slot, the uoer runs a procedure which moves to another frame). More com­ plex exaoples include such activities as repeti­ tive real-time data acquisition and display u~dat­ ing, and the running of ~n entire processor w1thin the slot's val11e window. In t!lis last case, invok­ ing, say, the Hun the Editor' slot of the current frame can cause the system editor to be invoked within the slot's value window. Hence, conven­ tional computing is considered a subset of the larger I-SPACE organization.

2.2. Example Scenario

In the context of the applications at God­ dard, a sample session of a visiting scientist employing the I-SPACE to obtain data or effect experiments would proceed as follows. Since the sc1entist is not an efperienced I-SPACE user 1 he depends on the s~stem s expertise to assist h1m in locating the des1red information and accomplishing his tasks. The flavor of a session with an experi­ enced user differs from the following scenario in that users familiar with the I-SPACE can move quickly from one frame to another without passing through intermediate frames.

Initially the system presents to the scien­ tist a series of MENU frames which describe the information available in the Goddard I-SPACE. When each frame is browsed the title of an available category of infonnation is displayed. Focusing the slot associated with a category produces a brief, but more detailed description of the category. When a slot in a hi!:HU frame is invoked, the scientist moves through the I-SPACt.: to another frame, presumably more specific than the previous one, which is then browsed. Our scientist is interested in experimenting with the Space Tele­ scope. lle traverses the I-SPACt; from general frames describing Goddard at large through science-specific frames to the "!~ear l::arth Satel­ lites" frame and arrives at the "Space Telescope" frame. Browsing this frame he discovers thwt the following categories of informs tion about the SRace Telescope are available: "Documensation", "~atellite StaSus , "jxperiment Data Bas~· , Con­ trol Operations' , and Personnel Contacts · Focus­ ing on the "Satellite Status" slot of this frame produces the information that the Space 1'elescope 1s operational and available for experimentation. The scientist then invokes the "t.:xperiment Date Base" slot to browse through the results of previ­ ous experiments, discovers that the results he is interested in are not available and decides to ilerform the experiment himself. He returns to the ~pace 'l'elescope" frame to examine the available documentation and then moves from the Documenta­ tion frame to the Control Operations frame. The scientist then invokes the appropriate slot in the Control Operations frame intending to accomplish his eoal. Unfortunately the experiment does not run, perhaps because scientist aid not speciAY the task correctly. Returning again to the Space Telescope" frame, he invokes the "Personnel Con­ tact" slot creating a screen-to-screen conversa­ tion with the project manaeer, determines his ini­ tial error in operating the ~pace Telescope and retries his experiment. Now successful in his guest our scientist moves on to other uses of the I-SPAt~. perhaps investigating topics mentioned in other frames that were v1sited during this ses­ sion.

A few points of interest should be made. At no point in the scenario did our scientist realize that the information he requested, or the opera­ tions he invoked, might have been accomplished on remote hosts. ~ncoded in the procedures contained in the individual frames of the 1-SPAC~ is the expertise to accomplish any activity, be it locat­ ing pertinent data or performing specific calcula­ tions. Our scientist's screen-to-screen conversa­ tion may have been with a pro~ect manager located in the next office or an indiv1dual on a remote host. Infonnation describine the current status of the telescope may have been stored in a data base, or it may have been the result of an actual request to the satellite via a controlling com­ puter to report its current status. The individual I-GPACE frames determine the source of the infor­ mation and via the I-:Jilt,;LL schedule requests to retrieve the information or execute procedures to produce the result.

~·2· I-SPACE Real-Time Scheduling and Processes

Consider the genera} character of an I-SPACE session from one user s point of view. At any given moment, the user will have a currently browsed or focus~d frame (some of whose slots may have been invoked), and possibly a collection of other focused and partially invoked frames in the background. Each slot of each of these frames has been activated at some level. If the slot's activation procedure is one which is concerned with repetltive or real-time updating, or is on the lookout for certain events or data in the I­ SPACE at-large, then it will be making demands on the I-SPACE for periodic attention. For this rea­ son, the system must include a scheduler process per user, as well as a system-level scheduler for mediating the u~er schedulers' requests of the I­ BANK t i.e., ZNOBJ.

The architecture of the I-SPAC~ scheduling system is shown in Fig. 2. As the I-SPACE shell interprets user desires, and slots become activated, slot activation procedures run and send scheduling tasks to the U-SCHEDUL~R, a separate process that rnanar,es its one user s scheduling needs. The U-SCHEDULER in turn determines the fre­ quency by which a procedure should be run and makes appropriate demands on the S-SCHEDULER. The S-SC!lEIJULER is a system-wide process which syn­ thesizes all U-SCI!t.:DULER requests to the I-BANK, prioritizes them (from user priority and real-time requirements of the scheduled event), then passes them to the I-BANK which finally carries out the requested interactions with the outside. Results are returned as named message packetst which are sorted out by the S-SChEilULER ana sent to the various requeating U-SCHBilULERS, which in turn route results to their I-SHELLs.

Status Information Display

Because of the design goal of presenting a user interface that has appearances of both a PIE-like programmin~/personal environment and real-time windows 1nto dynamic regions of the I­ SPACE, the I-SHELL must take care in how it processes responses. First, associated with any slot that displays real-time information, or that serves as a user comnand window to a real-time device somewhere in the I-SPACE, ·is a separate status or synchronization window. Using informa­ ~from the U-SCHEDULER, this window is illuminated when the main window's real-time scheduling falls behind, and a real time clock begins disj:·) .. :~yint: the delay time until the currently scheduled event is completed. For exam­ ple, if the U-SCHJ::IlULJ:.:H has been instructed to acquire updnted thermRl information from a space­ craft every 30 seconds, and there has been a delay beyond this period, the synchronization window illuminates and bct:ins di svl aying the overrun time until the data becomes ava1lable. On output, if, say, the user has requested that text be sent to another host, and there are I-SPACE delays in get­ ting the infonnation out (and returnine the con­ finnation that it vas sent) beyond the tlme deemed reasonable by the sending slot, the status window will Rlso be activated.

Multiple Active Frames

Another topic of interest that arises because of the !-SPACE's blend of a PIE-like environment with real-time scheduling is that of routing incoming real-time results to the users display in meaningful ways. Because the user may have focused a frame that has given rise to recurring real-time schedulin~ events, then moved to another frame without hav1ng defocused the current one, the I-SHELL must properly manage the arrival of scheduled information associated with the setaside, but not defocused frame (or frames). '!'his requirement demands that the logic of each frame be isolated from its display manifestation, so that the 1-SHJc:LL can maintain a pool of currently running and up-to-date frames, even if not all are completely v1sible on the display screen. Because of this separation of frame lot;ic 1111d frame display in the I-SHELL, the user is free to focus or 1nvoke slots of a frame, then move on to another frame before those effects are fully felt. Visually, the effect is a cluttered screen of the current frame and other partially occluded frames, all of whose visible parts may be changing to reflect real-time updates from completed scheduled events. Additionally, completions of invoked slots for set-aside frames w1ll be noted by a flashed message in the display's status area.

Since the logic of I-SPACE frames is what binds together the scheduling and user interface aspects of the I-SPACE, we turn next to a descrip­ tion of the structure and contents of I-SPACE frames.

1· Organization of~~ I-SPACE

l·l· Frame Logic and Scheduling

A frame in the I-SPACE is a LISP data struc­ ture containing a set of slots which correspond to each subactivity of a task in the 1-SPACB. A slot is a description of a particular aspect of a frame and contains the slot's name, value, display descriptor, activation procedures, and access channels. Associated with each slot are three lev­ els of activation which correspond to the three ll!(l(fesof processing in the 1-SPACI::.

Ffr each activation level (browse, focus or invoke a slot specifies (1) the channel to be us~d, ~) the procedure to be run on that channel~ (3J the tarameters passed to the procedure, (4 the schedu e by winch the procedure is run 1 (5 the consumers that hanQl~ the results returned from the procedures, and (6) the priosit\ required to activate the slot at this lev~ o specifi­ cations may be explicitly included in the frame or implicitly refer to sys tern defaults. ~·or instance, the absence of a channel indicates that the slot is to be executed by the 1-~ I! ELL itself (without interaction with the I-BANK). An example of this is the slot description for browsing the Space Telescope frame visited by ou~ientist during the scenario.

slot orbit browse null, consume = Display( name, value);

This slot specification causes tbe con~ents of the name and value windows of the 'orbit' slot tg be sent to the user's terminal for Display. ~The null procedure is used to indicate that no compu­ ""tiitTon is necessary before executing the consumer function.) Another common slot procedure is HoveToFrame , the mechanism which moves the user to a different frame us the result of invokiH1; a olot of a HEr,u frame.

An I-SPACE information condu i t is called a channel. Chan9els access various object s in the extefiiiil world te. g ., mainframe computers, satel­ lite controllers, admi nistrator's desktop coruput­ ers and so forth) 11-s well as the internal comput­ ing environment \e.g., UNIX tools, such as, edi­ tors, high level languages and program development tools). <;:urrently chan(lels refer to speci fie resources (or connections) in the 1-DA·K, and have associated capabilities (or sets of procedures that can be executed on the channel). We are currently developing plans for decoupling the relations hip of channel and procedure and replac­ ing specific references to a channel vith descrip­ tions of the inforwation requirements of the chan­ nel. This in turn will change the nature the S­ SCHEDULER to resemble more a problem-solver than a resource scheduler.

Bach slot contains three window descrittors that specify the visual presentat1on of the s ot's name, value, and status windows to the user. This description includes each window's location (two­ dimension subregion) within the frame and, possi­ bly! the initial contents of the window. Typl­ cal y, the name window contains onhy th~ slot s name e·t;·, "'Near Earth Satelli tea , or Orbit 9f Satellite , the value window contains the slot s value as obtained by running one of the slot's procedures, and the status window contains infor­ mation describing the current status of the run­ ning procedure. This includes messages such as: "'Connectinj; to Remote Host"', "'Remote Host is Down"', or Result Late, 5 sec"'. Both the value window and the status window of a slot are optional. The value window is not specified for slots that correspond to activities in the I-SPACE that do not return specific values, but are exe­ cuted for their side-effects (e.~., slots in ~1ENU frames). 'rhe status window is opt1onal for slots that do not monitor recurring events.

A partial frame description corresponding to some of the activities our scientist may have viewed during the scenario is shown below:

frame SpaceTeleControlOper type control

slot orbit

consume = Display(name,value);

browse null

focus GetOrbitinfo,

channel · sraceTeleChan,

schedule = 0 se9,

consume z Update(value)

& Display(value); "'Orbit of Space Tele,cof'"'

window descriptor · (3, ) {1 ,25);

window descriptor = (3,30) (1 ,25)

name

value 34000km Od,

ends lot;

slot attitude

consume · Display(name,value);

browse null,

focus GetAttinfo,

channel · SpaceTeleChan,

schedule z 5 sec consume · Update(valye)

invoke AdjustAttitude

& Display( value);

(user ("'Bnter degrees (r,p,y):"')),

name Attitude"', window descriptor= (5,1) (1,25);

whannel E SpaceTeleChan;

value 22r 36p 15y,

end slot window descriptor z (7,1) (2,25)

slot SpaceTelcFrame

consume= Dt"splay(name);

browse null,

invoke MoveToFrame SpaceTeleFrame);

name "'Space Telescope FraiJie"',

ends lot window descriptor = (10, 1) (1 ,25);

end frame

The arguments passed to slot procedures are constants~ values taken from a slot's value field in the I-~PACE, or supplied py the user. If an argur.~en t is used from a slot s value field, it may be taken from the current slot, or another slot in the current frame, or a slot in a different frame. This supports a form of communication between slots s1tuated in different frames and can be employed to form complicated slot procedures that syn thesi"ze information from varying sources.

Each result of a procedure execution is passed to the consumers specified in the slot. Consumers are taken from a library of consumers, which includes procedures that upaate the contents of fields in a slot, that send requests to the U­ T~;R~II!lAL to display the contents of a field, or that pass the new results to other slots in the frwne or to slots in other frames. This, too, sugports communication to other sections in the I-vPACE.

As an illustration of the frame-to-scheduler link suppose the following slot from the Spa­ ceTeleControlOper frame above is focused:

focus GetOrbitinfo, channel · SfaceTeleChan, schedule z 0 sey, consume · Update(valye) II. Display( value)

This leads to scheduling activities that result in running GetOrbitinfo on SpaceTeleChan every 10 seconds by the 5-SCREDULER. Each time the orbit information is returned, the consumers are run. Update stores the value in the value window of the ~ and Display tells the U-TERMINAL to display the value window. The user then sees the orbit position updated every 10 seconds. If the orbit 1nfopnation is delayed or cannot be obtained the slot s real-time window is activated informing the user of the difficulty. In general, numerous scheduled slots such as this one will be running simultaneously as the result of user browse, focus, and invoke requests.

2·~· Frame Creation and Editing

At various times, the user may decide that he would like to create a new frame to perfonn a dif­ ferent set of operations or to synthesize and displa~ a new set of infonpation, or he may want to mod1fy an existing frame (by making a copy of the frame and then changing it to meet h1s own needs). These operations are done through a spe­ cial set of I-SPACE development frames which allow the user to edit frwnes ana add new frames to the I-SPACE.

The I-SPACE editor accepts new frame defini­ tionp via a spjcial descript~on language akin to KRL LBobroy 1977 called ISFL (the I-SPACE Frame Language LAllen 1981J, the examples in this paper are written in ISFL). The editor aids the user by providing templates of the various types of frames 1n the I-SPACE. These templates contain default slot values as well as variables whose values are supplied by the user when he creates a new frame. The ISFL templates allow the user to enter frames into the system without undue concern with the ISFL details. This method of creating frames is simillr to the o~e used in the BROWSE system of ~~~essp~~ali~f~Ies ~~e ~~~~d~~!~orwr~~o g~~~~~: and consumers from wh1ch the user may choose in creating his frame. The editor also knows the syntax of the language and can direct the user in designing a frame without the use of a template. Thus, the user may create a frame completely from scratch or create a frame using one of the given templates. He may also create his own templates, specifying variables that will be supplied when a frame is created using the template. In order to edit an existing frame, the Reverse Parser ·automatically translates the LISP frame structure into ISFL and then invokes the I-SPACE editor. If a template was used in creatin~ the frame, this template is once again used to a1d the user in mod1fying the frame. After the user is finished editing a frame, the ISFL specification is translated by e special parser into its corresponding LISP structure and the frame is added to the I-SPACE frame library.

The F-SPACE and Frame Librarian --- - ----- --- -----

1'he repository of all I-SPACE frames is called the F-SPACE. This library of frames and associated procedures is, in effect, the knowledge base for the I-SPACE. The F-SPACE is managed by a separate process which is responsible for coorai­ nating the insertion and moaification of I-SPACE frames, and for overseeing the "'checking out" of frames by individual user I-ShBLLs as their users roam the apace. As the central I-SPACE librarian, the F-SPACI> manager must also be responsible for coordinating information flow among multiple users of a checked out frame, in case several I-SHELLs are actively manipulating it, and for performing global F-SPACE searches for users looking for fast access to a relevant frame by description rather then normal local browsing (i.e., global F-SPACE

browsing).

There are three ways a user can "check out" a frame from this library: by copyi by update, and by command. The user automatics ly accesses a frame by cop~ when he is browsing since browsing returns essent1ally no new information. Also, the user only needs a copy of a frame if he is only usi~g it to accomplish certain t~sks (e.g., edit­ ing) that do not generate any new informahon that should be stored back into the F-SPAC~ for later uae. If, however the user is gener~ting new information to be stored back into the }'-SPAC~, then he will have to access the frame by update. In update mode, another user sees the updates, but is not allowed to manipulate the frame himself. If the user needs to rrn certain procedures that require exclusive use e.g., procedures to control a satellite at ~oddard , he w1ll have to access the frame b~ command. In this rnode, another user can see the frame as the first manipulates it, but he cannot run the procedures that require access by command.

4 ·. User Interface

The I-sm:LL

The I-SH~LL is the main per-user operating system in the I-SPACE, and is responsible for pro­ cessing user commands and coordinating the system responses. The main functions in the I-SHELL are browseframe, focusframe, focusslot, and invokeslot wh1ch are run 1n response to user requests. when the user first signs onto the system or moves to another frame two functions are called. The first is dispia~frame which sends the initial visual descri~h n 61-the frame to the U-TEIH.UNAL. This descript1on includes a list of the slots and where the w1ndows associated with the slots should be located. After displa{frarue is run, the second function, browseframe, s called. For each slot in the frame, browse! rame runs the browse pro­ cedure associated with that slot. When the user focuses a frame, focusframe is called. It first checks which slots have focus procedures. }'or all of those, it checks if there are already active procedures running in the slot. An active pro­ cedure is any recurrent procedure or any procedure that is only run on~e but has not yet completed its task. If focusframe finds no active pro­ cedures, it runs the focus procedure. If it f1nds an active browse procedure!. it terminates that procedure and runs the rocus procedure. If it finds and active focus procedure, it will allow the procedure to continue. If 1t finds an active invoke procedure, it waits and focuses the slot when the invoke procedure is done.

In an unfocused frame, the user may focus particular slots. When he focuses a slot, focusslot is called. Focusslot checks to be sure there lB a focus procedure for that slot, and, if there is stops any active browse or invoke pro­ cedure for the slot and runs the focus procedure. When the user invokes a slot, invokeslot is called which stops any active browse or focus procedure for the slot and runs the invoke procedure. When the invoke procedure terminates, the browse or focus procedure will be restarted if it was active at the time of invocation. In every case, these procedures are treated as if they were not there if the priority of the user is not high enough to allow him to run them.

Browseframe, focusframe, focusslot, and invokealot call an internal !Unction that actually takes the action necessary to run the procedures. This function first gets any user-supplied arsu­ ments, and then evaluates the other argurnents. If there is a channel for the procedure, the I-SHELL sends 11 request to the U-SCIIEDULEH to run the pro­ cedure. The I-SHELL is interrupted whenever the U-scm;DULEH has a result. The I-SJIBLL takes this result and runs the consumers for the slot and activation level. If there is not a channel, the I-SIIBLL runs the procedure locally and then calls the consumers. If the procedure is to be run in the window, the I-SHELL passes the procedure to the U-TERMINAL to process it there.

The consumers for a ~iven slot and activation level are run every t1me the procedure for the slot and activation level returns a result or fin­ ishes execution. When they are run, they know the frame, the slot, and the activation level informa­ tion that caused them to be called. They also know what value\ if any, was returned from execut­ ing the proceaure. With this information, they are able to update the I-SPACE and tell tne U­ Tt:H~IINAL to d1splay the new results.

4.2. The Display Screen

Given the power of the I-SiiELL to coordinate the accessing of information from the diverse resources of the I-SPAC~, it is crucial that this informs tion be presented to the user in an. effi­ cient manner. The U-T~HKIKAL is an intelligent terminal handler that has simi~ar characte~istics ~ o the displa~ systems of Lantz 1979j and Teitelman 1977 · It supports he modes of opera­ ions of the I- lii!:LL by providin~ sophisticated displays, called viewportsf througn which the user examines a section of the -SPAC~. Each viewport is a two-dimensional subsection of the total CRT screen area and corresponds to a specific active frame in the I-SPACE. For each slot in a fr~me, ~ he correspond~ng viewport contains three windows or subreg1ons) t~at are associated with the thre~ ields of a slot i.e., Name, Value, and Status) Each of the win ows of a v1ewport may be manipu­ lated independently of the other windows on the CRT and supports a full spectrum of oper~tions I}Ormally associated with . a computer termin{ll (e.g., partial and total clear1ng, scrolling). Each window can be displa~ed with a variety of ~ ruphical rendi tiona, wh1ch are nonn~lly employed o 1ndicate the st~tus of the associated slot i.e., whether it is browsed, focused, or invoked).

Viewports may be manipulated in a manner akin to sheets of paper on a desk. They can be st~cked on top of one another, moved to various locations on the screen, etc. This allows a user to place interesting information in different locations on the screen, much like a scientist spreads the several journals he is currently reading over the surface of his desk. Information ~ddressed to viewports whose windows are covered by other viewports will be stored in individual window buffers so that when the overlapping windows are removed, the viewport that was partially obscured is refreshed without loss of information.

The user operation of the U-'l'ERMI!lAL has been simpl~fied and uses short (nonnally a single keys­ troke) com:nands to issue requests to the I-SHELL. Graphic enhancements of the display windows pro­ vide the user with instantaneous status informa­ tion about previously issued requests. Infonua­ tion addressea to obscured viewports updates the covered windows without causing undue interference with the user's operations on another frame.

Finally a panic facility is provided that displays the currently available options to the user, as well as the capability to invoke a system l!I:;LP frame for more complex problems. The U­ 'l'EH!H~AL has been inte~ra tea into the I-SPACE sys­ tem and specific tennnal drivers for low resolu­ tion C~T and Tektronix terminals have been inst~lled. While adeguate for use during the development of the I-SPACE these devices will be replaced by memory-mapped high resolution displays in the final development phase of the project.

I-SHELL to U-TERN!l~AL Interface

The communication protocols between the I­ SHELL and U-TI:;HAI~AL parallels the interface between the I-!JPACC: and the user. ~·rom the 1SHC:LL perspective information correspondine to events occurrine in the I-SPACt:: must be communi­ cated to the user. These activities include operations such as browsing, focusing, or invokine a slot in a frame aml as returning the---reB"Ul ts of user init~ated requests. Additional!~, the I­ SHC:LL must have a mechanism for obtain1ng v~lues from the user that are needed by the functions used by the slots.

The user on the other hand wishes to communi­ cate his requests for specific frame manipulation operations to the I-SHC:LL. This includes focusing the current frame or specific slots within the frame, invoking an interesting slot in a frame, or moving to u different point of interest within the I-SPACC:. This could be either a previously activated frame, or an untouched area in the I­ SPACE. Additionally the user wants local control over the wuy that the information is displayed on his termin11l, including the ability to dynamically modify the nrrungemcnt of active frumes.

1'he U-Tl!:HhBAL und the I-SIIl!:LL communicate using a messn~e {'assing paradiem (~mrlemented usin~ the IPC facihty of lRashid 19!30j) lfl 11hich requests to the I-SHC:LL are constructed by the U­ Tl::il~\L~AL as a response to a user command in terms of frame manipulation functions. lnfonr.ation directed from the I-Sl!C:LL to the U-TER~ii:\AL is first mapped to the correspondin~ viewports and windows anu then sent to the CRT where, the infor­ mation nay be displayed, determined by whether the window is covered or not.

.2.· Global C:vent-Driven Pattern HatchinG

Longer range I-SPACE: research calls for the inclusion of a global, event-driven pattern match­ ing system which will more fully automate the flow and dissemination of information throughout the I-SPACE:. This system will have acces~ to both the F-SPACl!: managers activity queues \to watch the flow of frames to and from the F-SPACE), and selected I-BAUK channels. Users wishing to define personal or ~roup-related event patterns will do so by runn~ng special I-SPACE frames which are experts at this activity. Event patterns will make reference to frame-checking-out events in the F­ SPACB, to slot-filling events by individuql users, to general announcements from the I-llAIIK \e.g., an I-BANK processor reporting that its remote host has just co1~e up or gone down, or that a real-time satellite event of community-wide interest has just occurred), and to a real-time clock. 'rhis event-driven layer will enhance the character of the I-SPACE as expert assistant, by watching for its user in off moments, and by automatically ini­ tiating activities for its user.

G. Summary

An I-SPACE: is a new form of intelligent operating s;ystem and human-machine interface which we bel~eve, holds promise for large scale, real-time infonnation systems. Without the abili­ ties to locate, access, manipulate, and synthesize infonnation fragments efficiently and in user­ idiosyncratic ways, managers and technical staff in large organ~za tiona., and proerammers in large teams, will become increasingly less productive as members of their large or~anization. An I-SPACE gives these abilities to a w~de user population by allowing a user to bring to his screen a number of conduits to what would otherwise be unrelated information sources or services. The result for the user is a heightened ability to synthesize infonnation relevant to decision making in complex tasks, or critical to large scale development pro­ jects. The I-SPACB concept is proving to be a workable one, and establishes a framework in which more advanced tools, including advanced event­ driven pattern matchers and more intelligent data­ base searchers, can be developed.

APPENDIX: A Brief Overview of ZKOB ---- ---

ZMOU is a 256 processor multiprocessor research computer under current construction with funding from HOSR. Architecturally it is 256 Z!:lOA microprocessors, eacn having G4K bytes of memOrY~ and all connected as mail stops" around a 2~1 stat~e, 48 bit wide "conveyor belt" shift regis­ ter) which shifts at 10 mhz. Each processor is completel;y autgnomous and is given the illusion of non-block~ng 1 'instantaneous" c9mmunication with anott1er arb~trary processor or \subset of proces­ sors) by the high data switching capacity of the conveyor ·belt. At large, the machine will have an instruction throughput of 100 million instructions per second, a cumulative main memory of 16 million bytes, and an I/O throughput of 20 million bytes per second. Additionally, each processor indivi­ dually has a high speed parallel and serial inter­ face to the outside world, making possible remote data acquisition and information sw~tchinc. Indi­ yidual ZMOD processor~ will run one of three \assembly! PASCAL, LISP) operatinc systems, and will col ectively communicate w~th the out~idc world via the 257th mail stop, which is a m·,A interface to the VAX. 'l'he machine will be par·­ tially running by Sum;aer 1981 , and fully runniuc by the end of 1981.

REFJ;RENCi!:S

• lAllen 1981] Allen, E. H., "The I-SPACt; Frame LanguaGe" Univ of Maryland Technical Report in prepara­ tion, 1981.
• [Bobrow 1977] Bobrow D.G., Winograd, T., "An Overview gf KRL, A Knowledge Repre~e~tation Language' , Cognitive Science, Vol. 1\1), 1977 ·
• [Goldstein 1980a1 , Goldstein, t.P., Bobrow 1 D. G., 'Descriptions for a Programming J.::nv~ronment", Proceedings of The Firat Annual National Conference on ~tT!Tc~I~gence, ~tanlord, CA, Aul7 19eo.
• [Goldstein 19!30b] Goldstein, I.P., Bobrow, D.G., "E:xtendiug Object Oriented Programming in Smalltalk , Conference Record of the 1980 LISP Confer­ ~· Stanroru;-cA-;-Aug. 1'98(). --
• [Ingalls 19761 Ingalls,~.H.H., "The Smalltalk-76 Programming System Design and Implementation", Conference Record of the Fifth Annual ACM Sympos~um on 1'I'Di'ClpTes-oY' ?i"'gl'aiiiiiii"iigL&nguages, 19 I 6. -
• [Lantz 1979] Lantz, K.A., Rashid, R.F., "Virtual 'l'erminal Manat;ement in a l"ultiple Process Environ­ ment , Proceedin~s of the Seventh SymposiuDl on Operat~ng Sys ems-Principles Asilomar, CA, tree. 19/9.
• (Newell 1977] Newell, A. 1 Notes for a Hodel of Human Per­ formance ~n ZUG, Carnegie-Nellon University, Aug ·. 1 977.

lPalay 1980] Palsy, A.J ·· Fox, M.S., "Browsing Through Data Bases Proceedin~s of the Stm¥osium on Research and DeaelopE nt-- ~ n ormati~ Retr~eval,-c&mbr~ ge,ngiana;-June 1~u.

• [Rashid 19801 Rashid,I!.F., "An Inter-Process Communication Facility for UNIX"\ CMU-CS-80-1 24, Carnegie­ Mellon University, Jun. 1980.
• (Rieger 19!31) Rieger, C.,Trigg, R.,Bane, B:,· "ZMOB: A New Comput~ng Eng~ne for A.I. , Proceedings of IJCAI-~, Vancouver, BC, Aug. 19el. -
• [Teitelman 1977] Teitelman, w. "A Display Oriented Programmer's Assistant" 1 Proceedings of IJCAI-77, Cambridge, MA, Aug. 197/.