The DESIGN MAP MAKER was run on the example directory which recorded the design of the Tertiary Mirror Assembly (1.3MB of text graphic data, 76 files, 145 screenfulls). The pages had been tagged by designers, and the TMA Reqmt To Query Table had been constructed as described above.

One possible user scenario: a new person has joined the design team, taking over Margot's job on the Tertiary Mirror Assembly. He is particulary interested in material she and the rest of the team generated relating to the magnetic bearing (a crucial part of the TMA design). At this point his knowledge of the project is abstract      he got it by reading the initial project material      and it is in terms of requirements, specifications and parameters. So from this view, and his general engineering background, he constructs the following query in order to find all of the pages having to do with magnetic bearings:

:requirements RELIABILITY SEATING FORCE

:parameters MOUNT WEAR MAGNETIC FIELD MAGNETIC FIELD DEGRADATION MAGNET ALIGNMENT

Submitting this query to the map maker then results in a map of the 7 pages with material on the subset of the requirements that deal with the magnetic bearing. The map clearly presents the following:

a list of the relevant pages

a thumbnail summary of each page (including graphics)
a hypertext(graphic) link to each page
the filter used to process the user stated requirements
the key features of the processed requirements
the text graphic features inferred to be relevant to the key requirements
the text graphic data base query submitted to the logic system for page retrieval

Because this information is presented along with the map, the user can see the procedure used by the system to produce the map. If the results are not what the user had in mind, then it is easy to tune the query to get a different, more appropriate map of the design information.

A crucial part of the map making activity is use of the TMA Reqmt To Query Table to deduce a relation between requirements and the TMA ideas (idea tags) of the designers who wrote and drew the notebook pages. Those ideas represent the designer's view used in tagging the pages, and a mapping must be established between that view and the top down organizational view natural to a manager or someone new on the project, familiar with the specifications and their parameters but not the design stemming from them.

The goal of upward compatibility with more traditional AI techniques was acheived in two ways. Because of the great ease of processing text graphic objects in vmacs, in the long run substantial progress is expected in the realm of natural text graphic understanding [footnote viz grams ref ]. And in the short run, again because of the great ease of processing text graphic objects in vmacs, interfaces to systems employing more traditional AI techniques can easily be written. Some of the systems running at this time are listed below.

It is important to realize that all these systems operate on particular text graphic images constructed by the designer within the pages of the general Electronic Design Notebook. The presence of those images, along with the "text graphic spoor" left behind by the systems that operate on them, are easily recognized features which can be utilized in making maps of the information on those pages.

Declarative Programming in Rigid Body Mechanics Don Brown, Utah and Larry Leifer, Stanford
parser by Lakin

Rationale Inference in Optics Design
Cecilia Sivard, NASA AI Branch
parser by Lakin

Optics Design Aid
Catherine Baudin, Jody Gevins and Cecilia Sivard, NASA AI Branch
parser by Lakin

Dedal Design Reuse Assistant
Catherine Baudin and Jody Gevins, NASA AI Branch
with help from Vinod Baya and Ade Mabogunje, Stanford

Scratchpad Interface: engineer's equation based modelling system
Gene Bouchard, Lockheed