Roles of design knowledge in knowledge-based systems

  • Published on

  • View

  • Download

Embed Size (px)


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

    Roles of design knowledge in knowledge-based systems


    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


    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 .



    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 .


    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


    12 hours headaches

    stiff neck on flexation

    5 67











    Infectious Disease

    Domain KnowledgeSurgery

    subsumesNeurosurgery Cardiosurgery




    Gram-Neg-Rod Gram-Pos-Rod

    E.coli Klebsiella-Pnumonaie



    Congenial Infectious


    Acute Chronic

    bacterial viral

    ... ...



    subsumesfever headaches

    high grade CNS duration












    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 .


    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)




    Acute Chronic


    Design Choices





    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 ,...


View more >