Full report

Original page 1

NASA’s Scientific s

Original page 2

~- NASA Technical Memorandum 87821 The Development of a Prototype Intelligent User Interface Subsystem for NASA’s Scientific Database Systems William J. Campbell Goddard Space Flight Center Greenbelt, Maryland Larry H. Roelofs Computer Technology Associates Mchan, Virginia Nicholas M. Short, Jr. Science Application Research, lnc. I Lanham, Maryland National Aeronautics and Space Administration Scientific and. Technical Information Office 1987

Original page 3

~ -~ ~~ Table of Contents Chapter 1 Introduction Chapter 2 Background 1 3 Task Overview And Technical Objectives 5 Chapter 3 The Intelligent User Interface Concept 6 Chapter 4 The Intelligent User Interface and Database Views 7 4.1 4.2 Conceptual Graphs 10 4.3 The Application of Expert Systems to the Intelligent User Interface 11 Chapter 5 Prototype Development And Implementation 5.1 Development Objectives 5.2 Development Protocol 5.3 Development Task Effort 5.4 The Completion of CRUDDES 13 13 13 14 27 Research Results and Future Direction 28 Chapter 6 REFERENCES APPENDIX A SAMPLE CONSULTATION APPENDIX B CRUDDES LISTING: SEGMENT 1 30

Original page 4

Table of Acronyms AI Artificial Intelligence ART Analytical Reasoning Tool CRUDDES CRUstal Dynamics Database Expert System DBMS DataBase Management System DIS Data InformationSystem EOS Earth Observation System GSFC Goddard Space Flight Center KEE Knowledge Engineering Environment LISP LlSt Processing (a symbol manipulationcomputer language) IDM Intelligent Data Management IDMC Intelligent Data ManagementController IUI Intelligent User interface NSSDC National Space Science Data Center NLQP Natural Language Query Processor SAlS Science and Applications Information System SLR Satellite Laser Ranging VLBi Very Long Baseline Interferometry V

Original page 5

CHAPTER 1 INTRODUCTION In the past decade, operations and research projects that support a major portion of NASA's overall mission have experienced a dramatic increase in the volume of generated data and resultant informationthat is unparalleledin the agency's history. The effect of such an increase is that most of the science and engineering disciplines are suffering from an information glut, which has occurred, not only because of the amount, but also because of the type of data being collected (generally spatial and most often continuous in nature such as images, maps, two and three dimensional drawings and figures). This information glut is growing nonlinearly and is expected to continue to grow in this fashion for the foreseeable future. Consequently, it is becoming physically and intellectually impossible to identify, select, and access the most suitable information specifically applicable to the various engineering and research projects of interest. For example, in the earth sciences such vast amounts of data are now being collected and/or are available (e.g., satellite images) that it now exceeds the ability of the professionals in the field to process, manage, and study it . In addition, the number of professionals in the application disciplines is not expected to increase significantly enough to resolve this data problem in the foreseeable future. Thus, the dilemma arises that the amount and complexity of information has exceeded and will continue to exceed, using present information systems, the ability of 1 :he scientists and engineers to understand and take advantage of this information. Based on the scope, expected growth and dominance of this problem, it is anticipated that the future ability of NASA to function and perform meaningful space and earth related research will be significantly affected by its inability to manage and use its collected information to derive knowledge. Consequently, it is envisionedthat dramatically different approaches to data management will be needed if earth and space related operations and scientific investigations are ever to take full advantage of the information and data being collected and stored. Considering the trends of present computer science technologies, it appears that an approach to data management that employes Artificial Intelligence (AI) coupled in a distributed environment with powerful super mainframe, and micro based computer systems offers a reasonable solution for resolving many present and future data management problems. It is expected that such a system will, when operational, be able to: Deal with the massive data ingest and update problem, Manage concurrently both spatial and meta data in a logical manner, Provide intelligent user access to database systems and services,

Original page 6

Support large numbersof users interactively over a distributed environment. Based on the above concept an approach for the development of such a system has been formulated and a demonstration prototype completedfor an operational science research database. It is the purpose of this paper to present the results of the prototype demonstration effort. 2

Original page 7

CHAPTER 2 BACKGROUND In October of 1984, the Office of Aeronautics and Space Technology provided funding to Data Management Systems Facility, under the National Space Science Data Center (NSSDC), to initiate a research effort to develop a new generation of data management technologiesto support the needs of NASA’s future operational, engineering, and scientific programs thorugh the beginningof the twentyfirst century. The research effort is the Intelligent Data Management (IDM) project which has the following long term research goals: to develop very powerful database management systems using advanced technologies, to develop intelligentvalue-added services that will enable users to interact with the most complex database systems with minimal understanding of the systems architecture, stored data, or query language, to allow automatic data ingest and maintenancewith minimal user guidance and interaction, to manage symbolic and spatial data in the same database systems. The IDM project has been addressing those areas of data management that could potentially be improved by the applications of artificial intelligencetechnologies including: 3 User Interfacing, System management and control, Spatial database management, Automatic data ingest and system maintenance, Dynamic database systems using AI design concepts. A top level diagram of the IDM concept that includes each of the above areas, except dynamic database systems is shown in Figure 1. Although each of the above topics are important to the overall goal of producing intelligent database services, it was recognized early in the project that some areas clearly are more difficult to develop than others and in fact the development of some areas is predicated on the previous development of others. For example, intelligent ingest and maintenance services must not only support the database, but also any intelligent user interface. This is true since to perform maintenance and updating properly on a database system with intelligent value added services, some or all of the services themselves must be updated in the process. The reason for this assertion is that there will exist in the knowledge base which controls the intelligent user interface, informationabout the objects in the database and their relationships to

Original page 8

/ H \ 4

Original page 9

each other and to identifiedvirtual objects with little understanding of the database (objectswhich do not exist in the database architecture,data objects (data) or query but which can be definedby the clustering language. The IUIdevelopment concepts and analysis of several existing database are predicatedon using powerfulworkobjects). stations, expert systems, and natural language processingtechnologies. It was en- After careful considerationof the operation visioned that a database enhanced with a of database systems, it was determined functioning IUIsystem would enable that the development of an intelligent user scientific and supporting (non-database) interfaceofferedthe best chance for near technical usersto access and use the term success while at the same time, pro- stored informationwith little or no viding technical direction for most of the understanding of the database's architecother services in the overall concept. ture, the actual data content or the system's query language. This technical memorandum presentsthe It is believedthat the development and results of a research and development implementationof such a prototype subeffort relatedto user interfacing,called the system not only will demonstrate the con- Intelligent User Interface(IUI) task. The IUI cept of applying artificial intelligence to task was initiated at the beginning of FY85 data management, but also will enable with the goal of developing a prototype NASA to assess the long term applicability intelligent value-addedservice that would of A technologiesto its operational needs. allow users access to a given database 5

Original page 10

CHAPTER 3 TASK OVERVIEW AND TECHNICAL OBJECTIVES The objectivesof the initial IUI effort were to use existing NASA hardware and software systems to perform the functions of database managementand to extend and enhance their performance by designing and developingintelligent value-added services that would give such systems the capabilitiesto "reason" and make decisions similar to a human expert with database experience in the knowledge domain of interest. The specific goals of the IUI Task for FY85 were as follows: pert system development tools for a selected operationaldatabase, The customization of the NLQP "THEMIS" (creation and installationof a dictionary of lexicons that is the same as the expert system) to support the interfacing of the IDMC to the selected operational database, The demonstration of a prototype IUI customized for the selected operational database. The refinementof the IUI concept in the During FY85,the IUI research effort succontext of the IDM project goals, The review, selection, and acquisition of a low cost expert system developcessfully achieved all the above goals including the demonstration of a microcomputer based expert system that performed intelligent user interfacingto a NASA ment tool to support the development of operational database. However,the IUI a prototype IUI, effort is still in the initial stages of concept formulation and system development. The review, selection and acquisition of Therefore, it is expectedthat with the aca functioning Natural Language Query quisition of advanced AI hardware and Processing (NLQP) system to use in the software tools (a LISP workstation with the prototypingof a IUI, expert system development tools), significant advances can be made in the develop- The creation of an Intelligent Data Man- ment of a next generation of value-added agement Controller (IDMC) using exservices for NASA database operations. 6

Original page 11

CHAPTER 4 THE INTELLIGENT USER INTERFACE CONCEPT The IUI, as envisioned, is a system that will "serve as an intermediary between a database and a user" who has little or no knowledge of the database's architecture, language, or content.['] Such an interface would allow the user to operate a database by locating, identifying and selecting specific informationusing the context of his particular knowledge domain by communicating in the medium that is most suitable to him ( i.e. in the user's natural language, English). The advantages of such a concept are that: It can facilitate understanding by specifying the contents and meanings of a collection of data as well as the relation between objects within the data; [*I It will be able to support approximate reasoning to infer conclusionsthat are not explicitly stated by the user, such as an imprecise or fuzzy query which can be stated without mentioning file names or table joins; It will serve as the semantic basis for understanding the user's data needs in conjunctionwith the natural language query system; It will provide a logical representation of the database architecture and information stored in the database to the casual user; It can be used to facilitate the identification and understanding of database informationfrom the database operational view (the database design model which can be relational, network, etc.) to the user relatedviews by using conceptual graphs that translate between the database's meaning and the user's meaning of data and sets of data (31; It will provide a physical and logical link between information contained in the meta-knowledge database and the spatial database (the actual data) in the overall IDM concept. It can handle fuzzy concepts, express- To support such a design concept, two ed by using a fuzzy query; ideas need to be developed: It will be able to handle information demands for which the database is used routinely, rapidly and efficiently with little understanding by the user; It will be able to communicate with the user in plain Englishtext; 7 First, the creation of multiple views of the database that are functionally appropriate from the perspective of a nonexpert database user and, at the same time, operationally necessary, from the database's perspective of supporting the physical storage and management of the data,

Original page 12

Second, the creation of a means for approach will allow the search and identfrom one type of view to another ification of a desired data objects based on moving using logical inference statements (i.e., rules) called conceptual graphs, as proposed by Sowa P I . A singularly important feature of such a concept is its role as a mediator between subject context, inherited object attributes, and search strategy heuristics. The second view, the application view, is just a specific view point about the data objects in the database organized to sup- Such a system port an application. What is unique about the user and the database. must deal with the duality of the views (or contexts) in order to maintain both the integrity of the database and the user's understanding of the needed information. this view is that it will be constructed based on specific set of data object goals. These goals contain objects that are the result o the clustering or processing of real data objects into infered or virtual objects. In Using such a concept, the IUI deals with a addition, this view will be supported by user in his syntax and understanding of the specific heuristics in an associated know objects in the database. Also, at the same time, the IUI understandsthe database's ledge base that will enable the user to interact with the view as if he were the viewpoint, based on the physical and oper- expert that constructed the view and is ational organization of the data and the relationships between objects within the data. Based on our present understanding of database operations, as well as our readfamiliar with its operation. The last view, database operational view, is the view that representsthe actual database design (tables, key fields, join fields etc.,). This view is necessary being of the supporting literature, there are at cause all other views must translate to it in least three types of views required for a functionally complete IUI. These views are: The Architectural view, Multiple application views, The Operational view. The first view, the architecturalview, is the logical taxonomy of the objects contained in the database organized in a hierarchorder to get informationfrom the database. Based on the premise that the design of the IUI requires an awareness of all the above types of views, one can postulate a model that considers such views collectively linked by intelligent processeswhich translate between the views. Such a model is shown in Figure 2. and, as can be observed, the primary function of the IUI is to translate between the various database views and the user in a fashion The purpose of this view is to that best supports the user's needs. The ical schema. organize the information contained in the database in a structure that is most commonly used by humans when dealing with large amounts of data. Such an operational view must be included as part of the model even though this view, which is the actual DBMS, exists independently. 8

Original page 13

9

Original page 14

4.1 The lntelliaent User Interface and Database Views The multiple view concept upon which the IUI is based is an extension of an earlier concept presented in a popular text book by C. J.Date.FI This concept involvedthe representationof database architectures using levels of abstraction. In Date's which includes the relationship of the database objects to the general knowledge of the expert database user, defines the architectural view. This view is organizedto minimize processes that a user will apply when trying to locate a particular object or relationship between objects. Although the architecturalview is similar to some existing database design concepts, concept, the architecture is represented by two differences exist. First, the objects and three levels: internal, external, and conceptual. The internal level is concerned with the way data are stored and is the closest to physical storage; the external level is the view closest to the user's understanding of the data; and, the conceptual level is a "level of indirection" between the other two levels. the language used to describe them in the architecturalview are based on the user's language and understanding of the information of interest. Second, this view may contain objects which do not exist as real data objects in the actual database. These objects, known as virtual objects, result from the clustering of real data objects. In the context of the IDM concept, the intel- The second view, the domain-specificapligent user interface serves as both conplication view, includes all the knowledge, ceptual and external level processes. Such facts, and metaknowledge known to the an approach allows for powerful indirection expert user working in a particulartechby dealing with the user in his own syntax and logical processes while at the same nical area for which the database has been designed. The application view will time understandingthe database's design, include three different types of knowledge data content, and query language. The IUI concept model shown in Figure 2. postulatedtwo types of views to support the conceptual level: an architectural view and multiple user application views. However, because of the broad definitions given to the two types of views, part of the design formulation includes specifically limitingthe view's scope in order to avoid the uncertainties and ambiguities that can occur when considering database concepts. In the context of the IUI concept, a logical taxonomy of the database's organization, and facts: Heuristic knowledge related to obtaining particular informationfor specific applications; Procedural knowledge that is used by an expert user to obtain information from the database for a specific application; Virtual objects that are inferred objects resulting from the clustering of tuples based on application expertise. Supplementary to the current application view, several user application views are 10

Original page 15

3xpected to arise for different areas of database expertise. Because of this, lormulation of an IUI design capable of 3asily representing and modelling an 'expert" user's knowledge of the meaning Df the collected data is necessary in the design phase. Such informationwill enable the expert system to include functional and semantic interrelationships among database entities, domain specific attribut- ES, as well as content descriptions of obiects. The effect of the multiple view approach on the development of the IUI model is that when views are integrated with a database, two basic schemas of the database arise: a conceptual schema consisting of multiple logical views and the database architectural schema (Le., relational model).161 Both are necessary for a complete description of the database. TABLE 5 Lc_7 DATABASE VIEW (RELATIONAL) 4.2 ConceDtual GraDhS The use of the conceptual graph in the intelligent user interface process is presented in Figure 3. To better understand the application of the conceptual graph to the database problem the following example is presented. In the Crustal Dynamics Project's Data Information System (DIS) V I , a database has been developed at the NSSDC to support the storage of collected and analyzed crustal motion data from sensing stations located at many sites over the earth's entire surface. The users of the Crustal Dynamics database fall into two classes: engineers and scientists. The latter group is primarily interested in the database for studying motion of the earth's crust and earth rotation. The area of science related to crustal motion is commonly called plate I ACONCEPTUALGRAPH (EXPERT SYSTEM) J\"\\"""" CONCEPTUAL SCHEMA USER VIEW Figure 3. Representationof a Conceptual Graph 11

Original page 16

tectonics. To get the necessary information Using the conceptual graph concept to related to plate motion, an expert database user must query the database about a specific set of stations, calculate the chord between them for a specific period of time, and then determine the slope of the chord. However, the objects (the calculatedslope of the chord between any two sites) are not stored explicitly in the database. Therefore, the only way to determine a specific plate's motion is to identify the stations that are located on the specific plate and measure the motion of those stations with respect to stations on another plate (i.e. baseline measurements). Thus, there exist data objects needed in the identification and selection of the appropriate database information that do not exist in the actual database. Furthermore, only the experienced database user can know how to calculate the chords between the stations and their slope. In the IUI concept, such missing informasupport a multiview representation of the database, we believe that the IUI model allows for the creation of at least one logical translation path between a user's view of the data (domain specific) and the database management system's view. This path is, in fact, an expert system (see Figure 3). 4.3 The Atmlication of Exr>ertSvstems to the IUI The IUI design is predicated on the hypothesis that an expert system can be developed with the ability to reason about database information, both from the user's view and from the database's view. Such a design will allow the intelligent identification and selection of required information with only limited guidance by the user. Thus, the expert system will contain all the necessary facts and knowledge about the structures and contents of the various tion is accounted for so that, when informa- views of the database as well as the transtion about a specific plate's motion is desired, the IUI knows how to calculate the motion based on the type of sensing system used (SLR or VLBI) VI. However, to the casual database user, this intellectual transformationwill be transparent. To the IUI developer, this transformation (also lation among the views. Such an expert system will actually emulate an expert database user within his limited expertise domain. The decision to use an expert system as the operational environment for IUI softreferred to as a transform filter) is in fact thc ware is based on the following considerconceptual graph which facilitates the understandingof the meaning of objects in the context of the user's needs and translates those objects into different objects with meaning to the database. In the formulation of the IUI, one of the primary functions of the expert system is the creation of such conceptual graphs. ations: 1. A database has a finite and rather limited knowledge space making the development of an expert system possible; 2. Certain important operations that are performed by an expert database user are based on heuristics (Le., search 12

Original page 17

strategies usedto find information based on past experience); soning about such views and objects in a very sophisticatedmanner. 3. Although a database has a large num- Inthe history of expert systems, the most ber of potentialdata sets available, the successful development efforts have inactual number of sets is usually limited volved goal-directed, backward chaining paradigms such as MYCIN [81and to a small number, comparedto the large number of data objects that could PROSPECTOR[9]. In the case of the IUI, potentially be extractedfrom the data- where domain-specificinformation is rebase: quired, the same kinds of problem solving strategies, which were successfully used in 4. Many of the operations performed by the aforementioned examples, can also be the expert user are procedural in nat- applied to this development effort. Also, ure; the abilityto construct expert systems as conceptual graphs is based on the finite 5. Expert system development tools, espe- knowledge and syntax domains of a datacially the advanced ones that employ base. frame representation schemas (e.g., LISP with flavor extensions), allow not The impact of the above assertions lies in only the implementationof multiple the potential to develop intelligent prodatabase views but also the construc- cesses for the IUI using expert system tion of a logicaltaxonomy of objects in development tools for any prototyping the database and the subsequent rea- effort. 13

Original page 18

CHAPTER 5 PROTOTYPE DEVELOPMENT AND IMPLEMENTATION The approach used to develop a functionreal-time manner and allow the deming IUI was based on a phased effort which onstration of the IUI concept. included access to a functioning,operational database. Such a phased effort allowed the development of the IUI processes (databaseviews and transform filters) to be done in a stepwise fashion so that performance, feasibility, and operability could be tested for each functional 5.2 Development Life-Cvcle The following is the planned protocol consisting of 12 tasks for the development of a prototype IUI system. element. The development of the first proto- 1. Hardware & Software Selection type IUI had the following objectives and protocoI. 5.1 DeveloDment Obiectives 1. Formulate a design for a prototype Intelligent User Interface system that can be usedto demonstrate the proof of the concept as well as support and guide the technical direction of the overall IDM project. 2. Designand implement an expert system development environment using an IBM PC AT computer with the capability of supporting all the necessary system hardware and application software needed for a prototype IUI. 3. Design, develop, and prototype an IUI for a selected operational database using an expert system development tool. The proposed IUI will consist of the architectural view, one application view, and supporting transform filters. The system will be tech- Select and acquire the proper development tools, both hardware and software, for the initial development effort. 2. Database Identification & Selection Select a functioning, operational database that uses a relational DBMS model for the prototype IUI. 3. Database Evaluation & Characterization Study the selected database and develop a first order understanding of the database's architecture including the organization of tables, the information in the tables as well as the information objects that the database system manages. 4. Evaluation of the Use of the Database b_vthe ExDert User Interview the expert database users and determine the uses of the database that can be represented by domain-specificapplication views. enough to interact 5. IUI PrototvDe Desian Formulation nically sophisticated with the selected database in a near Formulatea design for a prototype IUI 14

Original page 19

System based on the concepts presented in Chapter 4 of this Technical Memorandum and on the results of tasks 3 and 4. 6. Formulate & Develoo The A.oplication -View Construct the selected application view of the database, assuming that there is more than one view. Based on the interviews with expert users, the selected view should include specific application goals, procedural knowledge, and identifiable virtual objects and be implemented using an expert system development tool. 7. Formulate & DevelooThe Architectural View Developthe architectural view of the database using the logical taxonomy schema formulated in task 3 of the protocol. 8. Develoo Transform FiltersTo Su-opofl TheTranslation Between The Application & Architectural Views &The Ooerational View Develop a set of transform filters that will support the translation between the application view of the database and the operational (relational model)[lolview of the database. 9 Interface Aoolication & Architectural Views' Transform Filters ToTheNLQP Develop a question/phrase construction process to interface between the NLQP and the application & architectural view transform filters. 10. customize NLQP To Supoort The Application & Architectural Views Customize the natural language 15 query processor so that it contains a dictionary of the lexicons used in the application view of the database. 11. Pevelor>Transform Filters To Suoport TheTranslation BetweenThe Aoolication View & TheArchitectural View Develop a set of transform filters that will support the translation between the architectural view and the application view of the database. 12. IntearateTransform Filters Into A Sinale Knowleda- e Base lntegrate the common elements of the three expert systems processes that perform the transformation filtering. 5.3 DeveloDment Task Effort Based on the development protocol listed above, an operational database was selected and the first prototype intelligent user interface developed. The IUI System was named CRUDDES (CRUstal Dynamics Database Expert System) after the database selected. The following tasks, which follow the above protocol, describe how the prototype lUlS was developed and implemented. TASK 1 HARDWAREAND SOFTWARE SELECTION The selection of the hardware and software for the CRUDDES development effort was based on the availability of allocated funds for FY85. Because of these limitations, the hardware selected was an IBM PC AT, microcomputer system with a 20 megabyte hard disk drive, 512 Kbytes of RAM memory, two displays (mono screen and a

Original page 20

color screen), and an external modem all the control structure, facts, variables, and utilizing the DOS operating system. A dia- meta-knowledge. gram of the system is presented in Figure 4. Software selected for the project included the expert system development tool, M.l [lo], developed by Teknowledge, the full screen editor, XYWRITE [111, from The procedure used to develop the expert system with the selected software depended on the installation of DOUBLEDOS. After DOUBLEDOSwas booted, two separate operating system partition areas were created each with its own monitor, Xyquest Corporation, and the multiprocess- one with 256Kbytes of RAM and one with ing environment, DOUBLEDOS [121, by Softlogic. Specifically, M.l was written using PROLOG 86 [13l (a popular IBM PC languagethat supports symbolic manipulation) and can support up to 200 facts and rules without segmentation (if the atoms are relatively small). Modelled somewhat after EMYCIN, the M.l system performs only goal-directedbackward chaining [ ' A ] . In fact, we found M.l far superior to other IBM PC based development tools because of the way it handled M1 EXPERT SYSTEM DEVELOPMENT TOOL h- 200 Kbytes of RAM. In the first partition M.l was installed and in the second XYWRITE. Both software packages have access to a common file area on the hard disk. This environment allows for the development of the expert system using the editor in the first segment and the concurrent testing of M.l in the other segment. The development team found this configuration extremely valuable over normal single process DOS operations. This is because it allowed rapid develop- XYWRITER TEXTEDITOR DOUBLEDOS MULTIPROCESSING OPERATING SYSTEM 20MB 512KB IBM PC AT Figure 4. Development System Configuration 16

Original page 21

ment and testing of software without the constant changing from the editor to M.l and back to the editor again. Furthermore, it was felt that the ability to develop software with an external editor allows for a great deal more flexibility in the development process thus creating a more robust expert system. TASK 2 DATABASE 1DENTlFlCATlON AND SELECTlON The database selected was one develop d to support the Crustal Dynamics Project. Implemented in ORACLE WI, a relational DBMSI161[171, and operating on a DEC VAX-11/780, the database consisted of 104 tables that supported the management of crustal movement , related engineering data collected by many sites over the earth's surface, and project management data. The sensors used to detect earth crustal movement are of two types: the first uses a satellite with a laser ranging device (SLR); the second uses a radio emitting stellar object and Very Long Baseline Interferometry (VLBI). Specifically, the VLBl method involves using two or more widely separated radio telescopes to observe radiationfrom extragalactic radio sources, typically quasars. In the Crustal Dynamics Project, SLR or VLBl is used to observe signals from various points on the surface of the earth, take a time lag measurement of their arrival with respect to a local clock at each site, and recordthe "time tagged" signals on tape in order to sense crustal movement. A key feature in selecting the ORACLE DBMS over other systems was that an operational natural language query proces- 17 sor supported it. The need for the query processor is that the formulation of a desired database query in English is a much less complicated problem for an expert system than the translation from English to the query language SQL.[181 In some of our initial research, we determined that performing language parsing and translation in an expert system overly burdens the system (Le., makes it too large and cumbersome) and reduces the ability of the lUlS to formulate the "best" query. In fact, we found such a task almost impossible to generalize without actually developing a natural language processor as part of the expert system task. Thus, the incorporation of parsing and translation was avoided in all parts of the development effort. TASK 3 DATABASE EVALUATlON AND CHARACTERlZATlON The evaluation and characterizationof the Crustal Dynamics Project database was performed by the development of an Entity Relationship (E/R) [*OI diagram (Figure 5. presents a simplistic example) which is commonly used in initially designing a relational database. In addition to creating the E/R diagram, it was necessary to develop a logical taxonomy of the objects in the database using an approach that is commonly found in a thesaurus. This logical taxonomy, along with conversations with the expert users, helped to identify virtual objects. The result was the identification of three object classes in the architecturalview of the database: experimentaldata, site data, and project management data. Because

Original page 22

18

Original page 23

CRUDDES is a prototype, only the first two data classes, namely site data and experimentaldata, were dealt with in two separate steps for early validation in the development effort. TASK 4 EVALUATION OF THE USE OF THE DATABASE BY EXPERT USERS This portion of the development effort involved the application of knowledge engineering techniques to determine the utilization of database by the application database experts. Two scientists that support the Crustal Dynamics Project were identified and contacted in regard to collecting information related to the actual use of the project's database. The scientistswere interviewed on several occasions and, based on the interviews, three domain specific application views were identified: Scientific applications, Engineering applications, Project management applications. The information gained from this task determined the basis for the design of the prototype IUI formulated in task 5. TASK 5 IUlS PROTOTYPE DESIGN FORMULATlON With the three application views identified from the expert users it was then possible to formulate a design for the initial prototype IUI, presented conceptually in Figure 6. Consisting of a single scientific application view, related to plate tectonics, and the architectural view, the design is founded on two sources of information: first, from the information gained during task 3 and, second, from the interviewswith the expert users in task 4. Likewise, the basis for the design are the concepts discussed in Chapter 4. Once the functional design was completed, a software design of the knowledge base evolved based on the the characteristics and limitations of the expert system development tool, M.l, and on the IBM PC AT computer system. A top level overview of the resultant knowledge base design is presented in Figure 7. TASK 6 FORMULATE & DEVELOP THE APPLICATION VIEW After finishing the overall prototypedesign, the development team conducted subsequent interviews with the expert users in order to specifically understandthe database utilization and support the development of the application view. This resulted in a design concept that decomposed the scientific application view into two subviews: plate tectonics and earth rotation, each with specific sets of information extraction goals. For the subview plate tectonics, the informationextraction goals were: whole plate motion, regional deformation, and plate stability; and for earth rotation: polar motion (precession)and rotationalvelocity. Each of the listed information extraction goals were further affected by the application of necessary modifiers such as year, site location, and measurement method. However, even when the whenfound modifiers (those procedures which set exception parameters like year, 19

Original page 24

Figure 6. IUI Prototype Conceptual Design 20

Original page 25

CONTEXT RESOLUTION ARCHITECTURAL APPLICATION KNOWLEDGEBASE PARAMETERS RULESFOR KNOWLEDGE BASE RULESFOR REPORT @-PREPARING GENERATION QUERIES Figure 7. Overview of Cruddes Knowledge Base Design site location, etc.) are considered, the number of variables was fairly limited. Since the application view query usually included both procedural and heuristic knowledge, apparently, the development of a scientific application view was a fairly straightforward process using expert systems technologies. During this task effort, it became apparent that more consideration for the development of the overall design of the expert system processes would be required. Initially, it was thought that the application view could be developedseparately from the architectural view. However, it became evident that any single view lackedthe minimum necessary content requiredto assist the nonexpert database user. The reason for this conclusion was that nonexpert users understood little about the information in the database. Conse- 21 quently, they might think there was, or should be, more informationextraction goals than had been provided. In other words, the lUlS has to accommodate for the "I don't know what to select" response. This additional complication resulted in the development of a design, called the user context resolutionprocess, which attempts to resolve what view best serves the user's needs. The resolution of the context could only be assured by concurrently providing an application view and an architectural view. A model of the proposed final design concept is presented in Figure 8. The final step in this task involved deterrnining all of the possible combinations of unique data extraction goals (the database objects with their wherefore clauses) required in getting the desired information from the database for the scientific view.

Original page 26

After all the information extraction goals for the scientific domain (application view) had been identified and characterized and a strategy for resolving view conflict resolution determined, it was then possible to begin development of the expert system. The goal of the first expert system was to support the automated reasoning required in the determination of a user's desired knowledge from his interaction with the system. This is done in the context of the various information extraction goals available in the scientific application view or, where applicable, in the architectural view. This first expert system dealt with the knowledge area involving plate tectonics. The system's inference process, based exclusively on backward chaining, dealt with the various alternative selections available in the query formulation process by using generalized rule forms with variables. The expert system, in a planned structured selection process, identified the various componentsthat would make up a question and instantiatedthem into the variables where rules were used to construct the desired English question. The resultant expert system enabled a user scientist, with little experience with, or knowledge about the database, to easily get desired scientific information. To elucidate for the reader a better understanding of how the system supported its database interface function with a nonexpert user, a sample consultation is preented in Appendix A. In addition, Appendix B.presents a listing of the first segment of the knowledge base that involves context resolution and the selection of data obects related to plate (tectonics) motion. TASK 7 FORMULATE & DEVELOP THE ARCHITECTURAL VIEW The development of the architecturalview of the database is based on the premise that it is necessary to provide to the user a generalized view of the database which is a logical organization of the objects that exist in the database and their interelationships. With the knowledge gained from this view, one could identify information that is not available through the other views (applicationand operational) or an extension of an already available application formed query. As discussed in task 6, one of the primary reasons for the architecturalview is to support the "I don't know what I want" response expected from a new database user. The approach taken in designing the CRUDDES architecturalview was predicated on the concept of object relationships that will be required in developing the next generation IUI system using a frame based expert system. The decision to mimic a frame type organization came from an initial development effort that organized the database into a tree structure. The impact of selecting the frame over the tree approach was twofold. First, a frame provided the most complete relationship organization possible including virtual objects, and second, it makes the view reasonably easy to port to a new expert system development tool being acquired as part of the FY86 project effort. The development of the rules that created the architecturalview was segregated into 22

Original page 27

23

Original page 28

two stages. Taking about six weeks to com- manner similar to what would have been plete, the first stage involvedthe creation of two alternative view structures and an assessment of their performanceto provide the necessary information to the user about the objects in the database. The first architectural view structure was based on a functional representation of the actual database design and the second, a structure using the object relationship concept. The results of an evaluation of the two design alternatives indicated that the first was incapable of supporting the needs of the CRUDDES effort because it did not include all the necessary objects. The second would be impossible to implement with M.l because the software did not include the LISP flavors feature that enables objectlsubobject inheritance to be defined. The organizationfor the architectural view is show in Figure 9. As can be observed, the highest level object is the database world in which every other object is a component. The next level of decomposition in the architectural view is site information and experiment information. At this level, objects are clustered by their relationship to the ordering. The beauty of this type of view structure is that when inheritance is considered, objects will be able to receive new attributes by the very fact that features have been addedto objects at lower levels. Thus, inheritance allows a system to respond as if it were learning automatically. Because of the limited capabilities of M.l, no possibility existed to create a true framebased structure for the architecturalview of the Crustal Dynamics Project Database. However, it was possible using M.l to organize the objects within the view in a possible with frames. The exception, however, is that no inheritance exists. This organization was carried out and demonstratedto a limited extent in about three weeks. TASK 8 DEVELOP TRANSFORM FILTERS TO SUPPORT THE TRANSLATION BETWEEN THE APPLICATION & ARCHITECTURAL VIEWS & THE OPERATlONAL VIEW The development of expert system based transform filters functioning as the interface between the architectural view and the operational view did not require a great deal of development because only a portion of the architecturalview was implemented in the first phase of the CRUDDES development effort. The approach for the development of transform filters between the architecturalview and the operational view were very similar to those developed from the application view to the operational view. For both cases, once objects and cluster object relationshipwere determined, it was only a matter of creating the necessary rule base to provide a functioning transform filter capability. In this task, identified objects were translated from the application and architectural view to objects that exist in the operational view and then translated into a syntax that could be understood by the database (SQL). The most dificult problem in the prototype development effort was the formulation of a SQL query, once the English question 24

Original page 29

Figure 9. Architectural View 25

Original page 30

phrase had been constructed. The reason for the difficulty is twofold. First, it was necessary to translate the object information identifiedin the application and archiecturalviews to objects that existed in the operational view. Second, once an object translation had occurred that resolved all operational view ambiguity, the query then had to be translated into the database's query language (SQL). The first translation process is one of the most important components of the IUI concept becausethis is where the expert database user is needed in order to translate from what the user comprehends and needs to what the database understands. This assertion is based on the hypothesis that there exists in the application and architecturalviews many objects that do not exist singularly in the operational view. These consist of the clustering or grouping of several objects that exist in the operational view. It is this expertise along with the procedure knowledge that is required to form the proper query that signifies the expert database user. In the prototyping of CRUDDES, such knowledge was identified and captured in the expert system. TASK 9 INTERFACEAPPLICATION & AND ARCHITECTURAL VIEWS TRANSFORM FILTERS TO THE NLQP The translation, from English to SQL, was a more difficultproblem to resolve. It became evident early in the development effort that an approach which supported the translation from English to SQL would be an extremely complex and difficult task involving the development of parsers that could convert from English to SQL. The 26 reason this approach was undertaken was that the natural language query processor had not yet been customizedto interface with the Crustal Dynamics database due to the lack of necessary computer resources. Therefore, an alternative approach had to be taken to allow the parsing of an English query into SQL. The result of the initial development effort was a version of CRUDDES that performed inadequately. Although it worked well for the limited information goals in the application view that had been included in the knowledge base, it lacked the robustness for dealing with the broader range of English to SQL parsing problems that would have to be resolved when the application and the architecturalviews were extended and other application views added. One important result of this effort was the appreciation for the robustness of the English language in being able to formulate, in a very compact way, an expression that communicatedthe desired information. It would appear that, when dealing with or reasoning about an object (or information about the object) that exist in a domainspecific space, it is best to formulate the questions in the context of that domain using the syntax applicable to it. The result of this conclusion for the IUI design is that, it is best to stay in an object's conceptual domain until the entire query expression has been formed and only then translate the question to a database query using its language. It is easy to see how a simple English question quickly becomes very long and complex when converted to a SQL expression. Because of the complexity of developing an effective English to SQL conversion

Original page 31

process, it was decided to terminate that part of the task before it was completed. This decision was made for two reasons; first, because the project's primary focus is on the development of intelligent processes using expert systems and not in developing natural language processors; second, because the project had the foresight to acquire a commercially available natural language query processor that was able to translate easily from English to SQL. Given that CRUDDES would not have to contend with the database's language, whatsoever, the creation of the interface between the NLQP and the transform filters became a fairly straight forward process. What was required was a means of storing, in a temporary file, the English question formed by CRUDDES so that it could be passed to the NLQP via a communications process. Since M.l supported such a capability, this process was coded into CRUDDES, tested, and demonstrated. TASK 10 CUSTOMIZATION OF THE NLQP FOR THE APPLICATION & ARCHITECTURAL VIEws The customization of the natural language query processor, THEMIS, was a very simple and straight forward process because the system is a functioning commercial product that has been built to support rather large and complex relational database systems. In addition, since Consequently the dictionary of lexicons that had to be added was also rather small (due to the limited number of information goals coded into the knowledge base). However, because the lUlS had to resolve ambiguity in the user to system communication, special attention was paid to the formulation of English queries on the CRUDDES side and their response on the database side. If the CRUDDES system were expanded, the ability of the NLQP to handle imprecise queries would become a more important issue. Consequently, how the system will deal with imprecision is unclear. However, in the long term, it appears that any IUI system must be able to understandthe user based on more than syntax. Presently, creating systems that understand queries at the contextual and semantic level of abstraction is quite difficult because of the limitation of M.l. However, with the use of third generation expert system development tools (e.g. ART, KEE) it will be possible to capture database context and semantics in the expert system knowledge base. 5.4 The Completion of CRUDDES The last two tasks in the protocol are presently under development. Currently, the intentionfor CRUDDES is to serve as both a learning tool and a demonstration system. After the current effort's completion, further development is not planned for the follow- CRUDDES is a prototype system that deals ing reasons: with only a portion of the selected database, the number of English queries it is capable of generating is rather small. 1. The CRUDDES effort demonstratedthat expert systems can be used to develop 27

Original page 32

intelligent user interfacesto database systems, 2. More can be learned about developing an lUlS by moving as quickly as possible to a more robust expert system development environment. 28 Given the above, we believe that we now have the technical basis to begin the design and development of a next generation IUI system that should be able to function very effectively in many NASA operational database environments where research scientists need better and more responsive data management support.

Original page 33

CHAPTER 6 RESEARCH RESULTS AND FUTURE DIRECTION 6.1 Research Results Based on the research to date, the following important results have been determined: 1. It is best to represent a database as a collection of logical views; 2. At a minimum the collection of views must include an architectural view and at least one application view; 3. The architecturalview provides a logical taxonomy of the database; 4. The application views are where real database user expertise is captured because this is the view dominated by procedures and heuristics: 5. The context and semantics of a database can be captured and representedin an expert system; 6. The expert system must be linked to a natural language query processor to support the translation of the English formed question about the data into a query in the database's Ianguage; 7. For both development and explanation purposes,the expert system should reason in the domain of the user, using English; 8. The most efficient method for translating between views is by creating conceptual graphs (or transform filters ) to allow translation amongst the various views; 9. Virtual objects, created via the clustering of real database objects, can only be represented in the knowledge base of the expert system. 6.2 Future Directions The near term IDM effort plans are to extend the capabilities of the intelligent data management controller using an advanced expert system development tool like ARTW, or KEEP31and to begin the development of some of the other IDM subsystems that were presented in a summary form in Chapter 2. Based on our present understanding of the capabilities of the more advanced development tools we plan to begin development of a second prototype IUIthat supports, to some degree, the following capabilities: Structured object relationshipswith inheritance using a frame based schema, Concurrent data-driven and goal-driven data object identification and query formulation, Concurrent multiview representation of the database, Learning by example using the frame based schema to add new objects and virtual objects, 29

Original page 34

Multiple application views for different domain-specificinformationgathering tasks. As in the original design the NLQP, THEMIS, will be interfacedto the IUIS. However, in this case, the communications will be supported by a broad band local area network usingthe communication protocol TCP/IP[24]. In addition to the IUItechnical effort, the project will also be formulating and assessing alternativedesigns for an advanced dynamic DBMS architecture that can create "on the fly" search structures and strategies to support a near real-time dynamic database system. Over the next 3 to 5 years, it is the goal of the IDM effort to design, develop and implement a completely functioning intelligent data managementsystem that will supPOrt: A sophisticatedsystem interface that will be able to interact with and understand a user's data needs based on the users Englishand graphical representations of informationentirely in a ap- 30 plication context. An intelligent automatic data ingest and maintenancesystem that will allow spatial and non-spatialdata to be automatically input into the various databases that the system will interface; A spatial database system that will be able to manage and reason about spatial information to support domain specific applications; A dynamic database system that will be able to perform complex data management operations by using pattern matching and "on the fly" network and tree structure construction to perform optimal object identificationand selection. Concurrent with the above technical development effort, the project will select a suitable candidate test bed project, such as Science and Applications InformationSystem (SAIS) or Earth Observation System (EOS) to use for test and evaluation. Once selection has been made, a test bed IDMS will be customized based on the data maagement needs and technical direction of the selected project.

Original page 35

~~ REFERENCES 1 1 Shi-Kuo Chang, Jyh-Sheng Ke, [9] Duda, R. O., Gaschnig, J. G., Hart, P. E., "Translation of Fuzzy Queries for Relational "Model design in the PROSPECTOR Database Systems", I€€€ Transactions on consultant system for mineral exploration. Pattern Analysis and Machine Intelligence, In. D. Machine, ed., Expert system in the Vol. PAMI-1, NO.3,July 1979. [2]ibid. micro-electronic age. Edinburgh; EDINBURGH University Press, pp.153- 167,1979 "Artificial 1101 D'Ambrosio, B., "Building Expert [3]Campbell, W. J., Roelofs, L. H., Intelligence Applications Concepts for the Remote Sensing and Earth Science Community", Systems with M1,"BYTE Magazine, June 1985. Proceedings of the IX Pecora Conference, [l 11 XyWrite Reference Guide," XYQUEST IEEE Publication Catalog No. 84CH2079- 2,October 2 - 4 1984,PP 232. [4]Sowa, J. F. "Conceptual Graphs For A Corp, BEDFORD MA, 1985. [12]SoftLogic Solutions, Inc. DoubleDos Reference Manual, Manchester, N. H. ISM J. Res Develop., 1984. Data Base Interface," July 1976. [13]"Prolog - 86 Technical Summary," to Database Solution Systems Inc. Norwell MA, 1984. [5]Date, C.J. "An Introduction Systems", Third Edition, Addison-Wesley 13- [14]op. cit., Shortliffe, E. H.,Buchannan, B. Publishing Co., Reading, MA, 1981, pp. 17. [6]op. cit. Campbell, W. J., Roelofs, L. H., "Artificial Intelligence Applications Concepts for the Remote Sensing and Earth Science Community" [7]Noll, C.E., "The Development of Selected Database Applications for the Crustal Dynamics Data Information System", NASA Technical Memorandum 83886,December 16,1981. [8]Buchanan, B. G., Shortliffe, E. H., "Rule- Based Expert Systems, The MYCIN Experiments of the Stanford Heuristic PROGRAMMING Project,I1Addison-Wesley Publishing Co., Reading, MA, 1984. G., "Rule-Based Expert Systems, The MYCIN Experiments of the Stanford Heuristic PROGRAMMING Project," pp. 302- 313. [15]"SQUUFI Reference Manual, Version 4.0,"ORACLE Corp., June 1984,D002- 0684-840521. [16]Codd, E. F., A Relational Model of Data for Large Shared Data Banks," Commun. Ass. Comput. Mach., Vol. 13, June 1970. [17]op. cit. Date, C. J. "An Introduction to Database Systems", pp. 73- 81. [18]Denny, G. H. "An Introduction to SQL: A structured query language,", IBM Tech. Rep. RA93(28099),May 1977. 31

Original page 36

[19] Chamberlin, D. D., Boyce, R. F., SEQUEL: A structured English query language," ACM-SIGMOD Workshop on Data Description, Access, and Control, May 1974. [20] Chen, P. P. S.,"The entity-relationship model: Toward a unified view of data," ACM Trans. Database Syst., Vol. 1, pp. 9- 36, 1976. [21] Davis, D. B., English: The newest computer language," High Technology, Vol 4, No.2, Feb. 1984. pp. 59 - 65. 32 [22] Clayton, B. D., "ART Programming Primer," InferenceCorp., Los Angles, CA, 1985. [23]Kinnucan, P.,"Software Tools Speed Expert System Development," High Technology, Vol5, No.3, March 1985, pp. 22 - 27. [24] Tannenbaum, A. S., "Computer Networks," Prentice-Hall Inc. Englewood Cliffs,NJ, 1981, pp. 371 - 377.

Original page 37

APPENDIX A I,

Original page 38

APPENDIX A : SAMPLE DIALOG FOR APPLICATON CASE OF WHOLEPLATE MOTION ENGLISH QUERY CONSULTATION WELCOME to t h e CRUSTAL DYNAMICS DATABASE EXPERT SYSTEM (CruDDES) Developed as part of the Intelligent Data Management Project This system provides assistance for supporting access to the crustal dynamics database at GSFC using t h e ORACLE database management system. I f you are certain of your scientific application and we support it, CruDDBS will direct you quickly to t h e information needed t o generate a query. Otherwise, CruDDES will help you determine what information you require to prepare a query and then assist you in generating a query. NOTE--if you do not understand any question throughout the session, t y p e "uncertain". NOTE--if y o u are uncertain of how to respond please type "options". consultation is application oriented. This phase of the Do you want: pt) plate tectonics info. o r er) earth rotation info. o r type "uncertain". > > pt D o you want information related to: r ) regional deformation p) plate stability w) whole plate motion > > w We support two applications areas related t o whole plate motion. We can supply you with information either for the motions between two regions on the respective plates or for the motions between entire plates relative to each other. The latter choice will supply information method ,using all baselines, for the needed t o implement a least square rates o f change between the entire plates. Do you want: p) plate motions between regions I e) entire motion between plates > > e Choose t w o plates from this list: p) pacific n) nasca na) north american c) carribean*S sa) s o u t h american e) eurasian a) australian af) africanSf A- 1

Original page 39

**no data from these plates, yet. What is the letter of the reference or "fixed" plate? > > P What is the letter of the "moving" plate? > > na ->enter in the first year for your baseline measuring time (78 to 83). > > 78 - > enter in the final year for the time range (78 to 83) > > 83 Do you want data acquired through the satellite laser ranging (slr) method or through the very long baseline interferometry (vlbi) method? Type slr or vlbi. > > slr CRUDDES THEMIS SUB-EXPERT SYSTEM You have now entered a generic subroutine which determines how you want your query presented. The following English question has been formulated from this consultation and will be presented to the database management system via the natural language query interface: Get all slr baselines between the pacific plate and the north american plate during 1978 and 1983. Please type "n" for the next page! > > n NOTE: remember to type "log off" if you logged printer earlier!! Are you satisfied with the results? > > yes Thank you for your CRUD-es M . 1 > log off A-2

Original page 40

SQI, Q U E R Y CONSULTATION M.1) l o a d [ c r u d d s ~ s g l ) . M.1> go. WELCOME t o t h e CRUSTAL D Y N A M I C S DATABASE EXPERT SYSTEM (CruDDES) Developed as part o f the Intelligent Data Management Project This system provides assistance for supporting access to t h e crustal dynamics database at GSFC using the O R A C L E database management system. I f you are certain of your scientific application and we support it, CruDDES will direct you quickly to the information needed to generate a query. Otherwise, CruDDES will help you determine what information you require to prepare a query and then assist you in generating a query. NOTE--if yod do not understand any question throughout t h e session, t ype "un ce r t a i n " . NOTE--if you are uncertain o f how to respond please type "options". This phase of the consultation is application oriented. Do you want: p t ) plate tectonics info. or er) earth rotation info. or type "uncertain". > > pt. Do you want information related to: r) regional deformation p) plate stability w) wliole plate motion > > w. We support two applications areas related t o whole plate motion. We can supply you with information either f o r the motions between two regions on t h e respective plates or for t h e motions between entire plates relative to each other. The latter choice will supply information needed t o implement a least square method ,using all baselines, for t h e rates of change between the entire plates. Do you want: p) plate motions between regions e) entire motion between plates > > e. Choose two plates from this l i s t : p) pacific na) north american c ) carribeanSS n) nasca sa) south american a) australian a f ) africanSS e) eurasian **no data from these plates, yet. A-3

Original page 41

. W h a t is the letter o f the reference o r "fixed" plate? > > p. What is t h e letter o f the "moving" plate? > > na. Do you want data acquired through the satellite laser ranging ( s l r ) method or through the very long baseline interferometry (vlbi) method? Type slr or vlbi. > > slr. timelegvals entered at the end o f the knowledge base. I - > e n t e r in the first year for your baseline measurtng time (78 to 83). > > 78. - > enter in the final year for the time range ( 7 8 t o 8 3 ) > > 83. QUERY INFORMATION: --You have two choices in accessing your desired information: either you'can use a batch or canned query, if i t exists, on the ORACLE system by typing "staboth5.ufi" or you can type the query by generate 8 queries. using the below information to There are several alternatives for obtaining t h e proper information. The recommended sources in order o f preference are: a) t h e canned query generation information before the parameter list b) t h e printed version of the required query c ) the multiple screen presentation o f required query information. Which do y o u want? > > b . NOTE: TURN ON YOUR PRINTER Please type "n" for the next page! > > n. COLUMN F-STATION HEADING "FROM" JUSTIFY CENTER FORMAT 99999 COLUMN S-STATION HEADING "TO" JUSTIFY CENTER FORMAT 99999 COLUMN CUR-NAME FORMAT A 1 5 TRUNC COLUMN PLATE FORMAT A15 TRUNC SELECT F.STATION,F.CURR_NAME,F.PLATE,S.STATION,S.CUR-NAME,S.PLATE, BASELINE, CHORD,GEODES IC FROM BASELINE78-SLRGSFC,SITES F,SITES S WHERE F-STATION = F.STATION AND S-STATION = S.STATION AND F.PLATE = pacific AND S.PLATP = north american A N D F-STATION IN (SELECT S- STATION FROM BASELINEt33-SLRGSFC) A-4

Original page 42

AND S-STATION IN (SELECT S-STATION FROM BASELI NE83- S LRGSFC ) SELECT F.STATION,F.CURR_NAME,F.PLATE,S.STATION,S.CUR-NAME,S.PLAT~, BASELENE,CHORD,GEODESIC FROM B A S E L I N E 8 3 . S L R G S F C , S I T E S F,SITBS S WHERE F-STATION = F-STATION AND S-STATION = S.STATION AND F.PLATE = pacific AND S.PLATE = north american AND F-STATION IN (SELECT S-STATION FROM BASELINE78-SLRGSFC) AND S-STATION IN (SELECT S-STATION FROM BASELINE78-SLRGSFC) SELECT F.STATION,F.CURR_NAME,F.PLATE,S.STATION,S.CUR-NAME,S.PLATE, BASELINE,CHORD,GEODESIC FROM BASELINE78_SLRGSFC,SITES F,SITBS S WHERE F-STATION-9000 = F.STATION KND S-STATION-9000 = S.STATION AND F.PLATE = pacific AND S.PLATE = n o r t h anerican AND F-STATION IN (SELECT S-STATION FROM BASELINE83-SLRGSFC ) AND S-STATION IN (SELECT S-STATION FROM BASELINE83-SLRGSFC) SELECT F.STATION,F.CURR_NAME,F.PLATE,S.STATION,S.CUR-NAME,S.PLATE, BASELINE,CHORD,GEODESIC FROM BASELINE83-,SLRGSFC,SITES F,SITES S WHERE F-STATION-9000 = F.STATION AND S-STATION-9000 = S.STATION AND F.PLATE = pacific AND S.PLATE = north american AND F-STATION IN (SELECT S-STATION FROM BASELINB78-SLRGSFC) AND S-.STATION IN (SELECT S-STATION FROM BASELINE78-SLRGSFC) SELECT F.STATION, F.CURR-NAME, F.PLATE,S.STATION,S.CUR-NAME,S. PLATE, I BASELINB,CHORD,GBODBSIC FROM BASELINE78-SLRGSFC,SITES F,SITES S WHERE F-STATION-9000 = F.STATION AND S-STATION = S.STATION AND F.PLATE = pacific AND S.PLATE = n o r t h anerican AND B-STATION IN (SELECT S-STATION FROM BASELINE83-SLRGSFC) AND S-STATION IN (SELECT S-STATION A-5

Original page 43

FROM BASE L INE83-S LRGSFC ) SELECT F.STATION,F.CURR_NAME,F.PLATE,S.STATION,S.CUR.-NAME,S.PLATE, BASELINE,CHORD,GEODESIC FROM BASELINE83-SLRGSFC,SITES F,SITES S WHERE F-STATION-9000 = F.STATION AND S - STATION S.STATION A N D F.PLATE pacific AND S.PLATE = north american AND F-STATION IN (SELECT S-STATION FROM BASE L INE78-SLRGSFC ) AND S-STATION IN (SELECT S-STATION FROM BASELINE78-SLRGSFC) SELECT F . S T A T I O N , F . C U R R _ N A M E , F . P L A T E , S . S T A T I O N , S , C U R - N A M E , S . P L A T E , BASELINE,CHORD,GEODESIC FROM BASELINE78-SLRGSFC.SITES F,SITES S WHERE F-STATION = F-STATION AND S-STATION-9000 = S.STATION AND F.PLATE = pacific AND S.PLATE = north american AND F-STATION IN (SELECT S-STATION FROM BASELINE83-SLRGSFC) AND S-STATION IN (SELECT S-STATION FROM B A S E L INE83-SLRGSFC ) SELECT F.STATION,F.CURR_NAME,F.PLATE,S.STATION,S.CUR~~NAME,S.PLATE, BASBLINB,CHORD,GEODESIC FROM BASELINE78_SLRGSFC,SITES F,SITES S WHERE F-STATION = F.STATION AND S-STATION-9OQO S.STATION A N D F.PLATE pacific AND S.PLATE = north american AND F-STATION IN (SELECT S-STATION FROM BASELINE83-SLRGSFC) AND S--STATIONIN (SELECT S-STATION FROM BASELINE83-SLRGSFC) m. I I 1 A-6

Original page 44

APPENDIX B

Original page 45

APPENDIX 8 : CRUDDBS LISTING OF S E G M E N T 1 (NOTE: this represents 19 out of 200 rules) / * <m.l> crudds.sg1 CRUSTAL DYNAMICS DATABASE EXPERT SYSTEM FIRST PROTOTYPE JANUARY, 1986 Segment # l O F 8 This segment primarily deals wtih USER RESOLUTION AND PLATE TECTONICS (NOT including Whole Plate Motion between specific regions). */ initialdata = ['consultation over s e g 1 ' 1 . / * "Initialdata" is what the system is searching for. What this m e a n s is that a session will be over when the system has found the value of the initialdata to be true. In this case i t is "consultation over s e g 1". * / / $ The following allows for easy modification o f dynamic parameters in the system (i.e. file names that change) because t h e entire system has been divided into eight (8) segments. any change to this requires a similar NOTE: Since this is a generic module, change in all other segments. */ segment-number = 1. nocache(fi1e-number-N). whenfound('disp1ay shown') = do(set segment-number = 1). noautoaaticquestion(objects-N). file-name-1 = 'VSCRUD.SG1'. 6-1

Original page 46

. file-name-2 = 'VSCRUD.SG2'. file-name-3 = 'V3CRUD.SG3'. file-name-4 'VSCRUD.SG4'. f i le--name-5 = ' V3CRUD. SG5' . file-name-6 = 'V3CRUD.SUB'. file-name-7 = 'V3CRUD.SQL'. cache-name-1 'initdis.che'. cache-name-2 = 'arvw.thm'. DISPLAY MODULE*SS********************f/ /**************************INITIAL / * This ar,ea displays the Crustal Dynamics header for this system. * / nocache(initia1-display-N). rule-al: if cache-name-1 = NAME and * do(1oadcache NAME) and initial-display-l= DESCRIP and initial-display-2= DESCRIPZ and initial-display-3= DESCRIP3 and display(DESCR1P) and display(DESCRIP2) and display(DESCRIP3) then 'display shown'. / * This rule loads the external file initdis.che into cache. But d u e to the fact that the three descriptive sections in the file have been "nocached", the information will be displayed without expending cache. */ rule-a2: if 'display shown' and not(reso1ution = uncertain) then applications-view. explanation(ru1e-a2) = [nl,'The database has two basic types of scientific information',nl, 'which can be accessed by the user, which is either Plate techtonics',nl, 'or earth rotation information. I f the user is unsure o f what he wants',nl, 'then an "uncertain response" will invoke t h e presentation o f an',nl, 'architectural view of the database which c a n be used to identify',nl, 8-2

Original page 47

’and determine what information might be of i n t e r e s t ’ , n l , n l J . rule-a3: if ’display shown’ and resolution = uncertain then architecture-view. explanation(rule-a3) = [nl,’This rule is used to control the selection o f a view o f the’,nl,nl, ’database that represents a logical taxonomy o f architectural design’,nl,nl, ’which can be used t o understand, identify and select database infomrmation’]. legalvals(reso1ution) = [pt, er, uncertain]. I rule-a5: if applications-view and resolution = pt then ’tectonics option’. / * !!!!!COMMENT!!!!!!: this rule is used to select the plate tectonics application option */ rule-a6: if ’tectonics option’ and select_plates-option = r then ’regional deformation’. 6-3

Original page 48

/--------------- THIS SECTION IS NOT COMPLETED YET -------------------------/ / * ! ! ! ! !COMMENT ! ! ! ! : N O T E : a search kb subroutine is coded to keep facts from cluttering up the cache or main memory. It must search through best-site and best-station file. subroutine name = CRUDDS.SUB. * / rule-a7: if 'regional deformation' and select-reference-plate = PLATE and select-reference-region-from-PLATE = REGION then chosen-region-reference-plate = REGION. rule-a8: if chosen-region-reference-plate = REGION and file-name-6 = NAME and do(1oad NAME) and do(set subroutine-iteration-flag = 1) and 'subroutine done' tiien 'sub called from reg def'. rule-a9: if 'sub called from reg def' and chosen-reference-station = STATION and display(['this is a test to determine the correct', ' station number--station = ',STATION,nl]) then objects-1 = s o r r y ~ - n o t - , ~ c o n p l e t e d - y e t . rule-al0: if 'regional deformation' then fields-1 = bye-bye. rule-al2: if 'plate stabilization' and select-reference-plate = REF then select-moving-plate = REF. rule-a13: if 'plate stabilization' and select-moving-plate = REF and low-time = LOW and high-time = HI and exper-type = TYPE then ref-plates-known. 8-4

Original page 49

select-plates-option = w then 'whole plate motion'. explanation(ru1e-al4) = [nl,'Within the plate techtonics application area there are three general',nl, 'areas of information: the motion of whole Earth plates relative to one',nl, deformation of a single Earth plate',nl, 'another (whole plate motion), the '(regional deformation), and the vertical motion of a plate as i t floates',nl, 'on the mantle (plate stability).',nl,nl]. rule-al5: if 'whole plate motion' and select--p1ates-mo t ion-type = e then 'entire plate motion'. rule-el6: if 'whole plate motion' and select-plates-motion-type = p and file-name-2 = N A M E and do(1oad N A M E ) and 'consultation over seg 2 ' then 'consultation over seg 1'. rule-al8: if ref-plates-known or both-plates-known then objects-1 = 'parms determined'. rule-al9: if ref-plates-known or - both-plates-known then fields-1 = 'parms determined'. 8-5

Original page 50

question(se1ect-plates-option) = ’ D o you want information related to: r ) regional deformation p) plate stability w ) whole plate motion’. l e g a l v a l s ( s e l e c t - . p l a t e s _ o p t i o ~ )= [ r , p, w, unknown]. question(se1ect-plates-motion-type) = [ ’ We support two applications areas related to whole plate motion.’,nl, ’We can supply you with information either for the motions between’,nl. ’two regions on the respective plates o r for t h e motions between entire’,nl, ’plates relative to each other. The latter choice will supply information’,nl, ‘needed to implement a least square method ,using all baselines, f o r the’,nl, ’rates of change between the entire plates.’,nl,nl, ‘ D o you want:’,nl, ’ p ) plate motions between regions’,nl, ’ e) entire motion between plates’,nl]. l e g a l v a l e ( s e l e c t - p l a t e s _ m o t i o n _ t y p e ) = [p, e, uncertain]. question(se1ect-reference-plate) = [’Choose two plates from this list:’,nl, ’ p) pacific n ) nasca na) north american c) carribean*S’,nl, ’ sa) south american e) eurasian a) australian af) african**’ ,nl,nl, ’**no data from these plates, yet.’,nl,nl, ’What is the letter of the reference or ‘*fixed” plate?’]. legalvals(se1ect-reference-plate) = [ p , s a , n , n a , e , a , c , a f J . question(se1ect-moving-plate) = ’What is the letter of the “moving“ plate? ’. legalvals(se1ect-moving-plate) = [p,sa,n,na,e,a]. question(1ow-time) = ‘ - > e n t e r in the first year for your baseline measuring time (78 to 83).’. legalvals(1ow-time) = integer(78’83). question(high-tine) = ’ - > enter in the final year for the time range (78 to 83)’ . legalvals(high-time) = integer(78’83). B-6

Original page 51

noautomaticquestion(plate(P)). plate(p) = ’pacific’. plate(sa) = ‘south american’. plate(n) = ’nasca’. plate(na) = ‘north arerican’. plate(e) = ’eurasian’. plate(a) = ’australian’. plate(c) = ‘carribean’. plate(af) = ’african’. question(se1ect-OBJECT-region-from-na) = (’Which region do you want from the north anerican ”OBJECT,’ plate:’,nl, ’ ca) california’,nl, , all alaska’,nl, ’ na) north america’,nl, ’ pa) pacific’ ,nl, ’ at) atlantic’,nl]. question(se1ect-OBJECT-region-from-sa) = [’Which region do you want from the south american ”OBJECT,’ plate:’,nl, 9 sa) south america’,nl, 9 pa) pacific’,nl, I at) atlantic’,al]. question(se1ect-OBJECT-region-from-p) = (’Which region do you want from the pacific ‘,OBJECT,’ plate:’,nl, ’ pa) pacific’,nl, 1 I ca) california’,nl, ’ na) north america’,nl]. 8-7

Original page 52

/ * NOTE: nasca plate has one region*/ select-OBJECT-region-from-n = pa. question(se1ect-OBJECT-region-from-e) = [’Which region do you want from the eurasian ’,OBJECT,’ plate:’,nl, 9 eu) europe’ ,n 1, # pa) pacific’,nl, 9 me) mediterranean’,nl, 9 as) asia’ ,nl]. question(se1ect-OBJECT-region-from-a) [’Which region do you want from the australian-indian ’,OBJECT,’ plgte: ’,nl, , austral i a ’,n 1 , a) , as) asia’ ,nl]. legalvals(se,lect-OBJECT-region-from-na) = [ca, al, na, pa, at]. legalvals(se1ect-OBJECT-region-from-sa) = [sa, pa, at]. legalvals(se1ect-OBJECT-region-from-p) = [pa, ca, na]. whenfound(exper-type = slr) = do(set process-location = gsfc). whenfound(exper-type = slr) do(set proc-loc-needed no). / * !!!!!COMMENT!!!!!!: The next meta proposition allows for experiment analysis location to be defaulted to gsfc when user doesn’t care about process location. */ whenfound(station.-type-needed = no) = do(set station.-type = fixed). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . question(satel1ite) = ’From which satellite do you want the data (lageos,bec, or starlette)?’. legalvals(aatel1ite) = [lageos,bec,atarlette,unknown]. 8-8

Original page 53

question(exper-type) = [nl,’ Do you want data acquired through t h e satellite laser ranging (slr)’,nl, ’method or through the very long baseline interferometry ( v l b i ) method?’,nl,nl, ’Type s l r or vlbi.’]. legalvals(exper-type) = [slr, vlbi, uncertain]. question(time) = ’From which year do you want the data (77-81)?’. timelegvals: legalvals(tiee) = integer(76, 85). question(station_type-needed) = ’Does i t matter if you choose fixed o r mobile stations? ( y e s o r n o ) ’ . / * !!!!!COMMENT!!!!!!: This sections handles the variability in t h e time ranges for the satellites catalogues. This is a generic module used i n all the segments. */ whenfound(satel1ite = lageos) = do(add timelegvals: legalvals(time)=integer(76,85)). whenfound(satel1ite = bec) = do(add timeleglvals: legalvals(time)=integer(76,81)). whenfound(satel1ite = starlette) = do(add tiaeleglvals: legalvals(time)=integer(76,81)). whenfound(exper-type = slr) do(add timelegvals: legalvals(tine) = integer(78’83)). noautomaticquestion(disp1ay-flag). / * !!!!!COMMENT!!!!!!: the system to switch between segments These nocachc meta-facts allow several times. This must be present in every segment. */ B-9

Original page 54

nocache(’consu1tation over seg 1’). nocache(’consu1tation over seg 2’). nocache(’consu1tation over seg 3’). nocache(’consu1tation over seg 4’). rule-a20: if segment-number = N and objects-# is known and fields-N is known and file-name-7 = NAME and do(1oad NAME) and ’subroutine done’ then ’consultation over seg 1’. explanation(ru1e-a20) = [nl,’You dummy. You ought to know better than to ask why.’,nl,nl]. , / $ $ * S f * $ * f S * S * * * * * * f * S E G M E N T SWITCHING C O N T R O L MODULES*$****************$/ / * !!!!!COMMENT!!!!!!: NOTE: architecture-view is a logical break rather than a physical one as in ‘consultation over seg 2’. NOTE: the segment switches t o a specific segment for a logical reason. */ rule-a21: if architecture-view and display([nl,’wait a second w h i l e I load in some more’, ’ knowledge. ..‘,nl]> and do(set applications-view = unknown) and file-name-4 = NAME and do(1oad N A M E ) and ’consultation over s e g 4’ then ‘consultation over s e g 1’. I B-10

Original page 55

rule-a22: if objects-1 is sought and fields-1 is sought and display([nl,'wait a second while I load in some more', ' knowledge ...',nl]) and applications-view = unknown) and do(set file-name-4 = N A M E and do(1oad N A M E ) and 'consultation over seg 4' then 'consultation over seg 1'. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . quest ion(user_satisf ied) = [nl, 'NOTE: remember t o type "log off" if you logged printer earlier!!',nl,nl, 'Are you satisfied with the results? I . legalvals(user_satisfied) = [yes, no The following are some of the M.l functions used in this system: nocache(EXPRESS1ON) : Values of nocache expressions will not be stored permanently in the cache. When such expressions are evaluated, the results are temporarily cached and the proposition that depends on the results is tested. Then, before proceeding, M.l removes the facts from the cache. I f the value o f a nocache expression is needed later i n a consultation or session, M.l seeks it again. whenfound(EXPRESSI0N) L I S T or whenfound(EXPRESSI0N VALUE) = LIST : A whenfound knowledge base entry allows y o u to modify the M.l inference process by designating what M.l should do whenever a value for the EXPRESSION is found. n o a u t o m a t i c x s t i o n ( E X P R E S S I 0 N ) : This prevents an automatic question from being generated f o r t h e expression even if there are no other knowledge base entries for the expression. If the expression is a variable, then it turns off t h e automatic question facility for all expressions. explanation(LABEL) = TEXT : Explanation displays the string TEXT in response t o "why" queries regarding a knowledge base entry whose label matches L A B E L . The text must be either an atom or a list whose elements are atoms and formatting commands("n1" and "tab"). This meta-fact enables knowledge engineers to substitute customized explanations or to offer acceptable explanation8 about a path o f reasoning that contains proprietary information. L A B E L can be any expression and may contain variables. B-11

Original page 56

Ordinarily, rules, presuppositions, whenfounds, and initialdata are the entries used with the "explanation" meta-fact. question(BXPRESSI0N) = TEXT : The given text is used to ask the end-user for the value of the expression. The text must be either a string or else a list of strings, variables, and special formatting commands. The answer provided will be checked against the "legalvals" for the expression, if any have been provided b y the engineer. legalvals(EXPRESSI0N) = integer :- M.l will only allow the end-user to answer with integers for the value of this expression. legalvels(EXPRBSSI0N) = integer(LOW,--HIGH) : A n integer between LOW and H I G H inclusive is a suitable response as a value for this expression. legalvals(EXPR5SSION) = LIST : The elements of the list are acceptable values for the expression. M.l will attempt "auto completion" (meaning that the answer must be one of a set of fixed responses and only sufficient letters to unambiguously distinguish the response need be typed or M.l will repeat the question) on responses to identify an element from this list. legalvals(EXPRESS1ON) = number : Any number is an acceptable value for EXPRESSION. legalvels(5XPRESSION) = number(L0W. H I G H ) : T4e real or integer numbers given as responses must lie within t h e range LOW t o H I G H , inclusive. legalvgla(EXPRBSSI0N) = real : Any real (floating point) number is a suitable response. A real number must include a decimal one digit on either side, unless an point with at least exponent is used. Either fixed or floating point notation is acceptable. leRalvals(EXPRESSI0N) = real(L0W. H I G H ) : The real number given as a response must lie within the range o f real numbers, LOW to H I G H , inclusive. *

Original page 57

1 . Report No. 2. Government Accession No. 3. Recipient's Catalog No. NASA TM-8782 1 7. Authork) William J . Campbell, Larry H . Roelofs, and Nicholas M. Short, J r . 9. Performing Organization Name and Address Goddard Space F1 i q h t Center Greenbelt, Maryland 20771 2. Sponsoring Agency Name and Address June 1987 6. Performing Organization Code 634 8 . Performing Organization Report No. 8780266 10. Work Unit No. 11. Contract or Grant No. 13. Type of Report and Period Covered Technical Memorandum Nat iona 1 Aeronaut ics and Space Admi n is t r a t i o n 14. Sponsoring Agency Code Washington, D. C . 20546-0001 15. Supplementary Notes William J. Campbell: Goddard Space Flight Center, Greenbelt, Maryland. Larry H. Roelofs: Computer Technology Associates, McLean, Virginia. Nicholas M. S h o r t , J r . : Science Application Research, Inc., Lanham, Maryland. 17. Key Words (Suggested by Author(s)) 18. Distribution Statement I n t e l l i g e n t D a t a Management, Conceptual Unclassified - Unlimited Views, E x p e r t Systems, N a t u r a l Language User I n t e r f a c e , A r t i f i c i a l I n t e l l i g e n c e , L I S P , Symbol i c Processing. Metadata I S u b j e c t Cateqory 61 19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No. of pages 22. Price U n c l a s s i f i e d U n c l a s s i f i e d 48 w= For sale by the Kational Technical Information Service, Springfield, Virginia 22161-2171 NASA-Langley,1987