Shaken: a knowledge Base Authoring Environment for Subject Matter Experts1



Download 229.41 Kb.
Page1/6
Date conversion19.04.2017
Size229.41 Kb.
  1   2   3   4   5   6

SHAKEN: A Knowledge Base Authoring Environment for Subject Matter Experts1

Design Document


SRI International
September 15, 2000


Vinay Chaudhri

Tom Garvey

Srinivas Narayanan

Mark Stickel

Jerome Thomere

Mabry Tyson

SRI International
Bruce Porter

Ken Barker

Art Souther

James Junmin Fan

Peter Zei-Chan Yeh

Dan Tecuci

Charlie Benton

University of Texas at Austin


Peter Clark

John Thompson

Boeing
Yolanda Gil

Jihie Kim

Jim Blythe

University of Southern California


Information Sciences Institute
Pat Hayes

Thomas Reichherzer

University of West Florida

Ken Forbus

Ron Ferguson

Jeff Usher

Shawn Nicholson

Cara Meverden

Northwestern University
John McCarthy

Eyal Amir

Aarati Parmar

Stanford University


Formal Reasoning Group
Boris Katz

Gary Borchardt

Massachusetts Institute of Technology
Paul Cohen

University of Massachusetts at Amherst


Steve McKay

Jill Jermano

Pacific Sierra Research
Richard Fikes

Deborah L. McGuinness

Stanford University
Knowledge Systems Laboratory
Mala Mehrotra

Pragati Systems



TABLE OF CONTENTS



SHAKEN: A Knowledge Base Authoring Environment for Subject Matter Experts 1

I Introduction 1

II End-to-end design 2

.II.A Functional Design 2

.II.B An Example Scenario 4

.II.C An Example Knowledge Entry Session 5

III Component Designs 17



.III.A Knowledge Base 17

.III.A.1 Determining Scope of KB Content 17

.III.A.2 Spatial Representations 18

.III.A.3 Representing Domain-independent Events 20

.III.A.4 Representing Conventional Analogies 21

.III.A.5 Domain Specific Content 25



.III.B Graphical Interface for Knowledge Entry 26

.III.B.1 Visualizing a Component as a Graph 26

.III.B.2 Mapping from Graph Operations Back to Logic 27

.III.B.3 Additional Issues 29



.III.C Question Asking 30

.III.C.1 Parameterized Questions 30

.III.C.2 Similarity Search 31

.III.C.3 Explanation 31

.III.C.4 Testing 34

.III.D Interaction Manager 35

.III.D.1 Natural Language Input 36

.III.D.2 Mixed Initiative 36

.III.D.3 Mixed Initiative: Knowledge Analysis 36

.III.D.4 Mixed Initiative: Structure Mapping 39

.III.D.5 Topic Tracking 39

.III.D.6 Grounding 40


.III.E Knowledge Server 41

.III.E.1 Reasoning Architecture 41

.III.E.2 Extracting Content from IKB 42

.III.E.3 Dealing with Representation Syntax Issues 43

.III.E.4 Dealing with Different Representations 44

IV Evaluating system components 50



.IV.A Evaluating Component Approach to KBs 50

.IV.B Evaluating Knowledge Entry by Analogy 51

.IV.C Evaluating Knowledge Entry by NL Input 52

.IV.D Approach to Metric Collection 54

V Software integration issues 56



.V.A System Operation and Requirements 56

.V.B Application Program Interfaces (APIs) 57

V.B.1 Interaction Manager – Browser Windows API 57

.V.B.1 Concept Maps – Interaction Manager API 57

.V.B.2 Question Asking – Interaction Manager API 58

.V.B.3 Knowledge Analysis – Interaction Manager API 58

.V.B.4 API to SME/MACFAC 60

.V.B.5 Knowledge Server API 60

.V.B.6 SNARK-KM API 61


.V.C Software Delivery and Version Control 62

VI Development Schedule 63

VII Input to Evaluation 64

VIII Summary 65

IX REFERENCES 66




IIntroduction


Knowledge bases (KBs) are expensive to develop and difficult to deploy. Enabling subject matter experts (SMEs) to directly enter their knowledge is central to both improving the knowledge acquisition rates and making it practical to put KBs into operational use.

In this document, we describe the design of an end-to-end system, called SHAKEN, to enable SMEs, unassisted by AI technologists, to assemble models of mechanisms and processes. These models are both declarative and executable, so that questions about the mechanisms and processes can be answered by conventional inference methods (e.g., theorem proving and taxonomic inference) and by various task-specific methods (e.g., simulation, analogical reasoning, and problem solving). One scientific innovation, and the principal extension to Cyc and the “HPKB standard” of KBs, is the idea of declarative and executable models (DEMs) assembled from components. The declarative aspect of DEMs supports conventional inference, whereas the executable aspect supports reasoning by simulation.

The design and implementation work described here was conducted through August 31, 2000. The design effort has been driven by a scenario wherein an SME describes how a virus infects a cell. The description of the scenario and knowledge components needed to represent this scenario were created by the University of Texas at Austin (UT). The University of West Florida (UWF) is supplying a graphical interface through which SMEs can present and assemble these components. The interface makes the specific assembly method, in this case concept compositions from UT/Boeing, conventional analogies from SRI, or novel analogies from Northwestern University (NWU), transparent to the SME. Boeing is developing question-answering methods to query the knowledge being entered. UT and SRI are jointly developing an explanation system to explain the contents of the KB and to display the answers to an SME. To help an SME identify gaps in the entered knowledge, and to support system-initiated interactions, the Information Sciences Institute (ISI) at the University of Southern California is providing a knowledge analysis module. The Formal Reasoning Group (FRG) at Stanford is contributing declarative semantics and techniques for control of reasoning for representations needed for the project. The Knowledge Systems Laboratory (KSL) at Stanford has produced a detailed design for the representation of default knowledge.

The team has created a storyboard showing how an SME might interact with the system. An essential aspect of the storyboard is the way the interaction is managed by the SME and the use of natural language (NL) to enable an SME to find a starting point for entering knowledge. We aim to empower an SME by creating a situation similar to a “student/teacher” conversation by using limited forms of input in English, and through mixed-initiative interaction.

Preliminary designs of the system components described here have been sketched out. A detailed document specifying the API between concept maps and the knowledge server is available. An interface between conventional and novel analogies based on the analogy ontology has been defined. The interface and division of labor between the two reasoning systems, Knowledge Machine (KM) and SNARK, have been defined. A translator to export the KB content into MELD format has been developed. With the help of the SMEs at Pacific Sierra Research (PSR) and at SRI, our team has been active in contributing to the evaluation issues—both by giving detailed feedback on the draft of the specification and by supplying SME expertise. The University of Massachusetts at Amherst (UMASS) is defining a baseline experiment against which the performance of SHAKEN will be measured.

The design and implementation effort is now moving beyond the virus infection scenario. For example, UT has analyzed several chapters of an introductory biology textbook and identified the list of semantic roles that need to be represented in the KB. Based on the analysis of the chapters in a textbook, SRI and UWF have mined Cyc’s Integrated Knowledge Base (IKB) for reusable spatial representations and identified the new ones that need to be developed. FRG and Pragati Systems (Pragati) will process these axioms to investigate better KB organization. SRI is writing axioms for representing conventional analogies. UMASS is investigating ontological distinctions that are necessary for us to create declarative and executable models. A component experiment between Massachusetts Institute of Technology (MIT) and UWF is being defined.

In this document, we start with a functional description of the system. Then we describe a scenario on how a virus infects a cell, and show how an SME might go about entering this, using SHAKEN. We consider each of the major system components in detail. Next, we show a system diagram and describe some of the key application program interfaces (APIs) that have been defined. We conclude the document with a discussion of future tasks and an integration schedule.

Throughout this document, we will make reference to an associated World Wide Web (WWW) site containing supporting documents. The URL for the WWW site is http://www.ai.sri.com/~rkf/designdoc/. In many cases, the documents on the WWW site contain more complete version of designs that were shortened for the purpose of this document.





  1   2   3   4   5   6


The database is protected by copyright ©hestories.info 2017
send message

    Main page