Roles of design knowledge in knowledge-based systems

  • Published on
    15-Jun-2016

  • View
    215

  • Download
    1

Embed Size (px)

Transcript

  • Int . J . Human Computer Studies (1996) 44 , 689 721

    Roles of design knowledge in knowledge-based systems

    M ICHEL B ENAROCH

    School of Management , Syracuse Uni y ersity , Syracuse , NY 1 3 2 4 4 , USA . email : mbenaroc mailbox .syr .edu

    ( Recei y ed 1 February 1 9 9 5 and accepted in re y ised form 2 8 No y ember 1 9 9 5 )

    Recent research suggests that the abilities of a knowledge-based system (KBS) depend in part on the amount of explicit knowledge it has about the way it is designed . This knowledge is often called design knowledge because it reflects design decisions that a KBS developer makes regarding what ontologies to embody in the system , what solution strategies to apply , what system architecture to use , etc . This paper examines one type of design knowledge pertaining to the structure underlying the solutions a KBS produces . (For example , in medical diagnosis , the output might be just a disease name , but the solution is actually a causal argument that the system implicitly constructs to find out how the disease came about . ) We define this type of design knowledge , show how it can be represented , and explain how it can be used in problem solving to make the structure underlying solutions explicit . Subsequently , we also present and illustrate new avenues that the availability and use of the design knowledge discussed open with respect to the ability to build KBSs that possess strong explanation capabilities , are easier to maintain , support knowledge reuse , and of fer more robustness in problem solving . 1996 Academic Press Limited

    1 . Introduction

    Knowledge-based system (KBS) designers are usually concerned with producing systems that meet certain design goals . These goals include providing KBSs with the ability to generate good explanations , to be robust (i . e . avoid brittleness and exhibit novelty) in problem solving , and to capture knowledge in a way that simplifies its maintenance and facilitates its reuse .

    Recent research suggests that , the more a KBS knows about the way it is designed , the better it can meet these design goals . For instance , Falkenhainer & Forbus (1991) show how a KBS can address novel problems when it knows what assumptions underlie the domain models its uses and how the knowledge base (KB) organizes these models in relation to the assumptions . Likewise , Swartout , Paris & Moore (1991) illustrate the way a KBS can generate explanation dialogues that address follow-up questions of the user , provided that the system knows what its explanation capabilities are designed to say and how .

    Knowledge pertaining to the way a system is designed is generally referred to as design knowledge . Chandrasekaran & Swartout (1991) explain the intuition behind design knowledge as follows . In the KBS design process , a designer brings to bear substantial amounts of knowledge about the subject matter of the application task , the nature of the task , how its parts work together to accomplish its goal , the range of solution strategies applicable , plausible KBS architectures , etc . KBS design is thus viewed as the process of making specific design decisions that produce the KBS

    689

    1071-5819 / 96 / 050689 1 33$18 . 00 / 0 1996 Academic Press Limited

  • M . BENAROCH 690

    sought (e . g . how to represent needed knowledge and what solution strategies to use) , and design knowledge is simply a documentation of these decision in the form of diagrams , narrative descriptions , and the like . These authors recognize that design knowledge is open-ended and cannot be all represented explicitly .

    We propose in this paper that a good starting point for attempts to capture design knowledge has to do with Clanceys (1992) recent realization , namely : the output of KBSs is normally a rational argument that explains their solution , not just a solution . For example , in diagnosis the output is typically a causal argument having the structure of a proof , and in design it is a logical argument having the structure of a plan . In this respect , Clancey observed two things . The structure of the explanatory arguments a KBS implicitly or explicitly constructs depends on the application task being addressed . Moreover , whether a KBS makes these explanatory arguments and their underlying structure explicit depends on the way the KBS is designed . In light of these observations , it is intuitively appealing to try to document design decisions pertaining to a specific KBS in relation to the structure of explanatory arguments which that KBS seeks to construct . In other words , if the general goal of a KBS is to construct explanatory arguments having a specific structure , the KBS design endeavor can be viewed as a goal-driven process involving design decisions concerning how to represent the explanatory arguments sought , how to represent domain knowledge needed to construct them , what strategies to use to control their construction process , and so on .

    This paper hence focuses on the representation of design knowledge pertaining to the structure underlying the explanatory arguments KBSs construct , and the roles that this design knowledge can play with respect to the ability of KBSs to meet the above design goals . Most of the examples we use are from the domain of medical diagnosis , and in particular NEOMYCIN (Clancey , 1988) , simply because this domain has been studied extensively in the KBS literature . The paper proceeds as follows . Section 2 identifies specific design decision which determine the structure underlying the explanatory arguments a KBS seeks to construct for its task . It also explains how design knowledge reflecting these decisions can be represented . Section 3 presents a task-independent KBS architecture that uses this design knowledge to drive the construction process of explicit explanatory arguments . Section 4 presents avenues that the availability and use of the design knowledge discussed open with respect to the aforementioned design goals . It illustrates these avenues by looking at how several recently build KBSs work in terms of the way they capture and utilize design knowledge . Section 5 discusses the way our work relates to previous work . Section 6 provides some concluding remarks and discusses several future research questions .

    2 . Design knowledge and situation-specific models

    This section explains how design knowledge relating to the structure underlying the explanatory arguments KBSs construct can be represented . It starts with an example that illustrates how such explanatory arguments typically look like . Upon examining the structure underlying these arguments , it identifies specific design decisions that determine this structure . Finally , it explains how design knowledge reflecting these decisions can be represented .

  • ROLES OF DESIGN KNOWLEDGE IN KBSs 691

    2 . 1 . SITUATION-SPECIFIC MODELS

    For any given problem situation , most KBSs implicitly or explicitly create a rational argument which explains their solution for that situation . Since this explanatory argument is a model that captures what a KBS knows about the specific situation addressed , it is often referred to as a situation - specific model ( SSM ) . Thus , while the KB of a system contains knowledge that applies to all problem situations the system is set to address , an SSM contains knowledge that was derived based on the KB and applies only to a specific problem situation .

    For example , consider a medical diagnosis task that seeks to identify the disease causing certain patient symptoms as well as find out how this disease came about . Figure 1 respectively shows part of the SSM NEOMYCIN constructs for one specific diagnosis situation , some of the domain knowledge it uses for this purpose , and a trace of how this SSM is constructed . This sample SSM is in fact a directed graph linking diseases , symptoms , pathological bodily structures , etc . Once complete , this SSM would essentially constitute a causal argument which shows that a certain organism (e . g . E .coli ) has entered the body (e . g ., during some surgical procedure) , migrated to a specific organ system (e . g . Meninges of the brains) where it proliferated because the normal immune system is suppressed , inducing a disease (e . g . Bacterial-Meningitis) that causes the pathological bodily structures and symptoms (e . g . durable headaches) observed in the patient .

    Believing that a KBS such as NEOMYCIN uses a rational reasoning process to construct SSMs like the one in Figure 1 raises questions regarding the form of these SSMs . Specifically : are all these SSMs directed graphs? if so , do they have a common underlying structure? if so , how does this structure relate to the nature of domain knowledge and / or application task? is this structure determined by design decisions that a system developer makes in the KBS design process? and , if so , what are these design decisions and how can we represent them? The rest of this section answers these questions , in relation to the type of design knowledge discussed in this paper .

    2 . 2 . DESIGN DECISIONS AND THE STRUCTURE OF SITUATION-SPECIFIC MODELS

    KBS builders make various design decisions during the KBS design process . Some of these decisions are closely related to conceptual aspects having to do with the way the universe of discourse is modeled , while others are closely related to technical aspects of the prospective KBS (e . g . what knowledge representation formalism to use) . The former design decisions are known to be more critical to the abilities that the KBS will possess ; they usually ought to precede the more technically oriented design decisions (Newell , 1982) .

    In relation to the structure underlying SSMs , we focus on conceptual design decisions pertaining to choices that a KBS designer makes with respect to the four conceptual levels presented in Figure 2 epistemology , ontology , perspecti y e and instance (Brachman , 1979 ; Davis , Shorbe & Szolovits , 1993) . Epistemology choices relate to the way knowledge pertaining to the phenomena of interest is expressed , e . g . using relational networks or neutral networks . As can be seen from the domain knowledge presented in Figure 1 , NEOMYCIN s designers chose to express knowledge as taxonomic relational networks that classify and link agents , diseases , symptoms , etc .

  • M . BENAROCH 692

    Situation-Specific Modelinduce relationsubsumption relationsubtype relationcausal relationdisease

    finding/symptompathological bodilystructure and/or findingagent (e.g. organism)inducing a disease

    E.coli Acute-Bacterial-Menegitis

    High grade fever

    CNS (headache) duration

    Acute-Meningitis

    12 hours headaches

    stiff neck on flexation

    5 67

    ...

    9

    1

    2

    4

    3...

    Intracranial-Mass-Lesion

    Intracranial-Tumor

    Increased-Intracranial-Pressure

    Seizure

    Infectious Disease

    Domain KnowledgeSurgery

    subsumesNeurosurgery Cardiosurgery

    Recent-Neurosurgery

    Ventricular-Ureteral-Shunt

    Bacteriasubtype

    Gram-Neg-Rod Gram-Pos-Rod

    E.coli Klebsiella-Pnumonaie

    induces

    Disease

    Congenial Infectious

    Meningitis

    Acute Chronic

    bacterial viral

    ... ...

    causes

    subtypeFinding/Symptom

    subsumesfever headaches

    high grade CNS duration

    10

    ...

    Meningitis

    8

    fever

    ...

    ...

    ...

    ...

    ...

    ...

    Partial Trace of the Construction Process

    1 The 12 hours headaches initial patient symptom is mapped to the more abstract CNS headache duration finding .

    2 The 12 hours headaches suggests that the disorder might be Meningitis . 3 Meningitis can be hypothesized if the patient experiences a stif f neck on flexion .

    This triggers the question : Does the patient have a stif f neck on flexion? . The users answer is YES .

    4 Refinement , or specialization of the Meningitis hypothesis generates the more spec- ific hypothesis Acute-Meningitis .

    5 Similar refinement of Acute-Meningitis generates the more refined hypothesis Acute-Bacterial-Meningitis .

    6 Support for Acute-Bacterial-Meningitis using known symptoms is found as the CNS duration finding .

    7 An attempt to further support Acute-Bacterial-Meningitis triggers the question : Does the patient have a high-grade fever? The answer is 105 . 8 Farenhit , which is categorized as the more abstract high-grade fever finding .

    8 A dif ferent attempt is made to support Meningitis by looking for categorical evid- ence for a more general hypothesis . The attempt identifies Infectious-Disease as a plausible hypothesis .

    9 Infectious-Disease implies the presence of certain findings , which may be already known . The high-grade fever is thus found to be subsumed by fever , provid- ing support to the presence of the needed fever symptom .

    10 Infectious-Disease is hypothesized , calling for the search for additional findings that may be consistent with the diagnosis so far .

    11 . . .

    F IGURE 1 . Part of a situation-specific model (SSM) constructed by NEOMYCIN , some of the domain knowledge used to construct that SSM , and partial trace of the construction process .

  • ROLES OF DESIGN KNOWLEDGE IN KBSs 693

    Ways to express knowledge about the "world"

    Relational Networks Neural Networks Symbolic Networks Natural Language

    Taxonomic Compositional Transitional

    Process Structure Function Structure Causal Discourse-state

    Normal Abnormal process(e.g. disease)

    Chronological process(e.g., staged failure)

    Abnormal Interactive-Historic process

    Actor(e.g., organism)

    Spatial(e.g., organ system)

    Temporal Malfunction(e.g., disease)

    Manifestation(e.g., symptom)

    overload(e.g., Psychogenic)

    infectious(e.g., Bacteria)

    invalid input orenvironment(e. g., Toxic)

    developmental(e.g., Congenital)

    infection

    Meneigitis

    Viral

    Acute Chronic

    Bacterial

    Design Choices

    Epistemology

    Ontology

    Perspective

    Instancecancer

    F IGURE 2 . Design choices (epistemic , ontological , perspective and instance choices) that the designer of a KBS makes .

    Ontology choices determine the specific ontological entities and relations used to model the phenomena of interest . In NEOMYCIN , the ontology of choice is labeled Abnormal Interactive-Historic process in Figure 2 . Using this ontology , diseases are modeled as malfunctions , which are the result of abnormal processes involving certain generic ontological entities (actor , location , manifestation , etc . ) that follow particular causal scripts and produce specific interaction histories with the body . Depending on the application task , these generic entities might represent dif ferent things . For example , in medical diagnosis an actor may be an organism , while in the diagnosis of electronic devices it may be an electric serge . Hence , for reasons of clarity , a KBS designer might choose to associate generic ontological entities with task-specific synonyms and descriptors . For example ,...

Recommended

View more >