An Information Presentation System

1. Display Description Structure

As shown in Figure l, various display formats are represented as sub-categories of DISPLAY, which is the principal top-level Concept of the information presentation model. There are two important themes in each such description: a characterization of the information involved in the display, and a characterization of its visible components. These are represented respectively by the Application and Realization Roles of DISPLAY.

The Realization Role is differentiated (split into multiple sub-Roles) and rroclified at the various descendants of DISPLAY. For example, MAP's visible c:orrponents: Border, Label, ~· ~· etc. are all represented as differentiating sub-lbles of DISPLAY's Realization Role (See Figure 2).

Notice that the ValueRestriction of Realization is the ooncept DISPLAYI'lm, which is a super­ Concept of DISPLAY. DISPLAYI'lm provides a characterization of a piece of a display in purely graphic terms. Attribute Roles of DISPLAYI'lm relate such things as the location, orientation, scale, width and height of a display element. Because DISPLAYI'lm is a super-concept of DISPLAY, the eventual fillers of (sub-lbles of) the Realization role in any Display may be either simply treated syntactically (as Displayitems) or may in fact be Displays in their own right, carrying an explicit treatment of the information they depict. Also, any Display inherits all of the syntactic attributes of DISPLAYI'lm, and thus can be described in terms of attributes such as location, width, height, etc. 'rhe advantage of treating the structural components of a display as Displays (and thus making an explicit treatment of their semantic content) is that this can provide a basis for the interpretation of graphic input.

The Application Role of DISPLAY indicates the information being expressed in a given Display, though not necessarily all of the information involved. Rather, this Role is a kind of binding mechanism that characterizes a Display's application to or depiction of specific information, as opposed to the inherent use of information that might be made in the nisplay' s generic definition (e.q. a sub-category of MAP which always labels items with their names, regardless of whether or not that attribute is mentioned at the Application.)

Of course, a sub-category of DISPLAY may add additional lbles that are sub-lbles of neither Realization nor Arelication. For example, MAP may have a Role InJection which characterizes the scaling transformation for a map.

2. The Characterization of Information

At DISPLAY, the Application Role is value restricted to one or l!Dre individuals of category 'l»tPPA'lE. A Template is simply a means of indicating the cross product of sane set of descriptions in the subject knowledge base with some subset of their Roles. Thus, 'ID1PI.ATE has tw:> roles: ConceptGroup and RoleGroup. The fillers of ConceptGroup iildicate the (bi\ilin ll'Odel objects of concern in a Display; the fillers of RoleGroup indicate which attributes of those objects are involved. If the semantic ccntent of a display does oot factor into a single such cross product, several Templates may be used to capture the disjuncts.

A Template gets its necessary descriptive "qrip" on Concepts and Roles in the cbmain knowledge base through use of I<Ir-OOE's meta-<'lescription feature. The Roles to be included in a Template are themselves treated as objects to be described. Individuals of the met<H:oncept RJIE are used to describe them. These individuals becane the fillers of the Role�rou~ of the Template. Meta-description is used 1n a similar way to indicate the Concepts involved in a Template via the meta-concept cno:Pl'. See Figure 3 for an example of a Template used to meta-indicate the names and locations of two ships.

Templates are also useful as meta-descriptions of display formats. For example, a Template can be used to indicate the kind of information that is well depicted in a particular format.

3. Procedural Knowledge in the Presentation System

The process of creating a display begins by creating a "blank" individual (i.e. none of its Roles are yet filled) of some sub-category of DISPLAY and filling its ~lication with the Template or Templates specifl bY the user. If the user does oot specify the desired format, AlPS compares the Template with meta-descriptions on the formats it koows about and selects a suitable category. From this p:>int, display ccnstruction proceeds in three phases: derivation, location, and drawing. Each phase is supported by its own set of procedural attachments to the knowledge base.

During the derivation phase, the description of the Display is expanded at least to the extent that all sub-Roles of Realization are filled with some Displayltem; each of these descriptions is then recursively expanded in the same manner. For example, for the case shown in Figure 4, the ~ Role of the Map being constructed is filled w1th an individual of TABlE whose Application Role filler indicates the set of symbols used in the map. The derivation process then recurses on this Table to fill out its internal structure.

The derivation phase procedures are attcched as tags to the Roles for which they produce fillers. These tags specify what information nust already be known in order to run a procedure, so that a demand to fill a Role may first result in the filling of other Roles oo which its derivation depends. Also, the t:ody of an attcched derivation procedure can dynamically call for the derivation of some other Role and suspend processing until the information is provided. Derivation procedures are inherited and rrore than one derivation procedure may be attcched. At Role filler derivation time, all of the available procedures are tried in order from the rrore specific to · the rrore general until one succeeds.

The second or location phase proceeds by means of messages passed among the constituent objects of the Display, which were identified and constructed in the preceding derivation phase. Displayitems receive Toi.Dcate messages which tell them where they are located relative to the coordinate system of the Display's viewing surface (which entities by now have also · t:oth been CXll'l'pletely described) · If the recipient Displayitem contains separately described OOII{X>I'lents, the attached Toi.ocate procedure computes the locations of these constituents and recurses the location process by dispatching further Toi.ocate messages.

The final or drawing phase is handled in a similar manner. Displayitems receiving TbDraw messages execute ToDraw procedures which ultimately call the drawing routines of a graphics package. Displayitems with separately described carp:ments send further ToDraw messages.

C. Conclusions

The version of AIPS described here runs on a Decsystem-20 uooer the Interlisp-10 interpreter, using a bitmap graphics terminal of BBN's design. The J:t.C graphics language [15] used in this 1o.0rk was developed and implemented as part of the AIPS effort, which also made substantial cootr ibutions to the current implementation of Kir-CNE.

AIPS was a:>nceived as a display management tool sui table for 1o.0rk environments supported by fast personal mcchines with large virtual memories, such as the MIT CADR [16], Xerox PARC' s Dorado [17], or the Jericho symbolic processor developed here at BBBN [18, 19]. The current AIPS is a carefully delimited prototype which barely fits into Interlisp-lO's available storage. We are presently rroving AIPS (and the Interlisp environment which supports it) onto Jericho. acx:orrplished, we will be in When that has been a p::>si tion to further elaborate the structure of AlPS' display descriptions.

Many of the benefits of information presentation are available through less powerful and more widely available bools than KL-ONE and LISP, albeit at the cost of some generality. The broadest ~rtance of our work is that it dei0Cll1strates one method of ra1s1ng the level of interaction between a knowledge base and its graphic display function. We are not alone in this p;rsui t. What distinguishes AlPS is its direct assault on the inherent knowledge representation issues.

• (1] '1-b:>ds, W.A., "A Scenario for Natural Language Control of Visual Displays," BBN Rep::>rt No. 4693, Bolt Beranek and Newman Inc., June 1981.
• [2) Kay, A. and Goldberg, A., "Personal Dynamic Media," IEEE Ca!plter, March 1977,
• [3) Borning, A., TH~LAB- A Constraint-oriented Simulation Laboratory, PhD dissertation, Stanford university, March 1979.
• (4] Robson, D., personal COI!ITllnication, 1980.
• (5] Herot, C.F., Wilson, G.A, "Semantics Versus Graphics - To Show or Not to Show," Technical Rep::>rt a:A-80-09, Cortputer Corp::>ration of America, March 1980.
• [6) Donelson, w., "Spatial Management of Data," Proceedings of SIGGRAPH 78, Association for COIIpllting MaChinery, Atlanta, GA.
• (7] Cattell, R.G.G., "Integrating a Database System and Programming/Information Environment," Proceedi~s of the \'brkshop on Data Abstraction, Data seS'; ana Conceptual ~lllng, Natlonal Bureau ofStandards and the Association for Computing Machinery, Pingree Park, <X>, June 1980.
• [8) Mitchell, J., Maybury, w. and Sweet, R.Xerox Palo Alto Research Center, Mesa Lar1guage Manual, Version 5.0 ed., Palo Alto, CA, 1979.
• [9) Gnanamgar i, S., "Providing Automatic Graphic nisplays through Defaults," Proceedings of the Third National Conference of Canadian SOCi"etfior Ca!pltatlonal Studies of Intelllgence, Canadian Soc1ety for Coop.ltational Studies of Intelligence, May 1980.
• [10) Yonke, M.D. , and Greenfeld, N.R., "AlPS: An Information Presentation System for Decision Makers," Proceedires of the Thirteenth Hawaii International Con erence on System Sclences,­ the Un1vers1ty of Hawai1 and the Assoc1ation for Computing Machinery, January 1980. A revised version of this paper is also available as BBN Rep::>rt No. 4228, Bolt Beranek and Newman Inc., December 1979.
• [ll) Zdybel, F., Greenfeld, N.R., and Yonke, M.D., "Awlication of Symbolic Processing to Command and Control: An Advanced Information Presentation System, Annual Technical Rep::>rt," BBN Rep::>rt No. 4371, Bolt Beranek and Newman Inc., April 1980.
• [12) Brachman, R.J., Bobrow, R.J., Cohen, P.R., ~lovstad, ~ .W., webber, B.L., '1-b:>ds, W.A., Research 1n Natural Language Understanding - Annual Re{X)rt: 1 Sept 78 - 31 Aug 79," BBN Rep::>rt No. 4274, Bolt Beranek and Newman Inc., August 1979.
• (13] Brachman, R.J., "On the epistemological status of semantic networks," in Associative Network~ --the Representation and Use of Knowl§e in canputers, N.V.Findler;-ea., Academ1c Press, New York, 1979, pp. 3-50.
• [14) Weinreb, D. and Moon, D., ~ispMachine Manual, Massachusetts Inst1tute of Technology Artif7cial Intelligence Laboratory, Cambr1dge, MA, 1981, ch. 20.
• [15) Greenfeld, N.R., Zdybel, F. , Ciccarelli, E., and Yonke, M.D., "13M:> Reference Manual," BBN Rep::>rt No. 4368, Bolt Beranek and Newman Inc., April 1980.
• [16) Greenblatt, R., Knight, T., Holloway, J., Moon, D., The LISP Machine, Massachusetts Institute or-Technology Artificial Intelligence Laboratory, 1978.
• [17) Lampson, B.W. ,and Pier, K.A., "A Processor for a High-Performance Personal Corrq:luter," 7th Int. ~· on canputer Architecture, 7th Int. Symp. on Corrputer Arch1tecture, Le Baule, France, May 1980.
• [18) Greenfeld, N.R., "Jericho: A Professional's Personal CoJl1P:Iter System," 8th Int. ~· on Computer Arch1tecture, 8th Int. Symp. on -­ Corrputer Arch1tecture, Rochester, Mn. May 1981. ,
• [19) Yonke, M.D., "A Lisp Machine should only be thought of as an expensive terminal," Proceedings of the 11th Annual Microprogramming \'brKShOp, Proceedings of the llth Annual Microprogramming \'brkshop, November 1978.