2 Pages: 12

Intelligent Systems



  1. Motivation
  2. Technical solution, illustrations and extensions
    1. Overview of CommonKADS
    2. Knowledge model components
    3. Template knowledge models
    4. Knowledge model construction
    5. Knowledge elicitation techniques
  3. Example
  4. Summary
  5. References
    All slides are based on the book: Guus Schreiber, Hans Akkermans, Anjo Anjewierden, Robert de Hoog, Nigel Shadbolt, Walter Van de Velde and Bob Wielinga. Knowledge Engineering and Management: The CommonKADS Methodology , MIT Press, ISBN 0262193000. 2000.
    And slides are partly based on the CommonKads Course http://www.commonkads.uva.nl


Knowledge engineering

  • Process of
    • eliciting,
    • structuring,
    • formalizing,
    • operationalizing
  • information and knowledge involved in a knowledge-intensive problem domain,
  • in order to construct a program that can perform a difficult task adequately

Knowledge engineering problems

  • Complex information and knowledge is difficult to observe
  • Experts and other sources differ
  • Multiple representations:
    • textbooks
    • graphical representations
    • skills

Importance of proper knowledge engineering

  • Knowledge is valuable and often outlives a particular implementation
    • knowledge management

  • Errors in a knowledge-base can cause serious problems

  • Heavy demands on extendibility and maintenance
    • changes over time


    Overview of CommonKADS

CommonKADS principles

  • CommonKADS: a comprehensive methodology for KBS development

  • Knowledge engineering is not some kind of `mining from the expert's head', but consists of constructing different aspect models of human knowledge

  • The knowledge-level principle: in knowledge modeling, first concentrate on the conceptual structure of knowledge, and leave the programming details for later

  • Knowledge has a stable internal structure that is analyzable by distinguishing specific knowledge types and roles.

CommonKADS Terminology

  • Domain
    • some area of interest
      • banking, food industry, photocopiers, car manufacturing
  • Task
    • something that needs to be done by an agent
      • monitor a process; create a plan; analyze deviant behavior
  • Agent
    • the executor of a task in a domain
      • typically either a human or some software system
  • Application
    • The context provided by the combination of a task and a domain in which this task is carried out by agents
  • Application domain
    • The particular area of interest involved in an application
  • Application task
    • The (top-level) task that needs to be performed in a certain application

CommonKADS Terminology

  • knowledge system (KS)
    • system that solves a real-life problem using knowledge about the application domain and the application task

  • expert system
    • knowledge system that solves a problem which requires a considerable amount of expertise, when solved by humans.

CommonKADS Model Set

Model Set Overview (1)

  • Organization model
    • supports analysis of an organization,
    • Goal: discover problems, opportunities and possible impacts of KBS (knowledge-based system) development.
  • Task model
    • describes tasks that are performed or will be performed in the organizational environment
  • Agent model
    • describes capabilities, norms, preferences and permissions of agents (agent = executor of task).

Model Set Overview (2)

  • Knowledge model
    • gives an implementation-independent description of knowledge involved in a task.
  • Communication model
    • models the communicative transactions between agents.
  • Design model
    • describes the structure of the system that needs to be constructed.

Models exist in various forms

  • Model template
    • predefined, fixed structure, can be configured
  • Model instance
    • objects manipulated during a project.
  • Model versions
    • versions of a model instance can exist.
  • Multiple model instances
    • separate instances can be developed
    • example: ''current'' and ''future'' organization

The Product

  • Instantiated models
    • represent the important aspects of the environment and the delivered knowledge based system.
  • Additional documentation
    • information not represented in the filled model templates (e.g. project management information)
  • Software

Roles in knowledge-system development

  • knowledge provider
  • knowledge engineer/analyst
  • knowledge system developer
  • knowledge user
  • project manager
  • knowledge manager


    many-to-many relations between roles and people

Knowledge provider/specialist

  • “traditional” expert
  • person with extensive experience in an application domain
  • can provide also plan for domain familiarization
    • “where would you advise a beginner to start?”
  • inter-provider differences are common
  • need to assure cooperation

Knowledge engineer

  • specific kind of system analyst

  • should avoid becoming an "expert"

  • plays a liaison function between application domain and system

Knowledge-system developer

  • person that implements a knowledge system on a particular target platform

  • needs to have general design/implementation expertise

  • needs to understand knowledge analysis
    • but only on the “use”-level

Knowledge user

  • interact with the prospective system or are affected indirectly by the system
  • Level of skill/knowledge is important factor
  • May need extensive interacting facilities
    • explanation
  • His/her work is often affected by the system
    • consider attitude / active role

Project manager

  • responsible for planning, scheduling and monitoring development work

  • liaises with client

  • typically medium-size projects (4-6 people)

  • profits from structured approach

Knowledge manager

  • background role
  • monitors organizational purpose of
    • system(s) developed in a project
    • knowledge assets developed/refined
  • initiates (follow-up) projects
  • should play key role in reuse
  • may help in setting up the right project team

Roles in knowledge-system development

    Knowledge model components

Knowledge model

  • specialized tool for specification of knowledge-intensive tasks
  • abstracts from communication aspects
  • real-world oriented
  • reuse is central theme

Knowledge categories

  • Domain knowledge
    • relevant domain knowledge and information
    • static
  • Inference knowledge
    • basic reasoning steps that can be made in the domain knowledge and are applied by tasks
  • Task knowledge
    • goal-oriented
    • functional decomposition

Knowledge Categories: domain knowledge

  • domain schema
    • schematic description of knowledge and information types
    • defined through domain constructs
  • knowledge base
    • set of knowledge instances

Constructs for domain schema

  • Concept
    • cf. object class (without operations)
  • Relation
    • cf. association
  • Attribute
    • primitive value
  • Rule type
    • introduces expressions

Example: car concepts

gas dial
value: gas dial
fuel tank
status: { full,
almost-empty, empty}
CONCEPT gas dial;
       value: dial-value;
END CONCEPT gas-dial;

VALUE-TYPE dial-value;
    VALUE-LIST: {zero, low, normal};
END VALUE-TYPE dial-value;
CONCEPT fuel-tank;
      status: {full, almost-empty,empyt};
END CONCEPT fuel-tank;

Modelling rules

  • knowledge analysis is focused on finding rules with a common structure
  • a rule as an instance of a rule type
  • models a relation between expressions about feature values (e.g. attribute values)
    • gas-dial.value = zero -> fuel-tank.status = empty
  • models set of real-world “rules” with a similar structure

Example rule type

        person.income <= 10,000
        loan.amount <= 2,000

        person.income > 10,000 AND person.income <= 20,000
        loan.amount <= 3,000

Rule type structure

  • <antecedent> <connection-symbol> <consequent>
  • example rule:
      • fuel-supply.status = blocked
        gas-in-engine.status = false;
  • flexible use for almost any type of dependency
    • multiple types for antecedent and consequent

Inference knowledge

  • describes the lowest level of functional decomposition
  • basic information-processing units:
    • inference ⇒ reasoning
    • transfer function ⇒ communication with other agents
  • why special status?
    • indirectly related to domain knowledge
    • enables reuse of inference

Example inference: cover

      fuel tank is empty leads to lack of gas in engine
      if there is no gas in the the engine, then the car does not start

Task knowledge

  • describes goals
    • assess a mortgage application in order to minimize the risk of losing money
    • find the cause of a malfunction of a photocopier in order to restore service.
    • design an elevator for a new building.
  • describes strategies that can be employed for realizing goals.
  • typically described in a hierarchical fashion


  • Description of the input/output

  • Main distinction with traditional functions is that the data manipulated by the task are (also) described in a domain-independent way.
    • example, the output of a medical diagnosis task would not be a “disease” but an abstract name such as “fault category”

    Template knowledge models


  • Knowledge models partially reused in new applications

  • Type of task = main guide for reuse

  • Catalog of task templates

The need for reuse

  • prevent "re-inventing the wheel"

  • cost/time efficient

  • decreases complexity

  • quality-assurance

Task template

  • reusable combination of model elements
    • (provisional) inference structure
    • typical control structure
    • typical domain schema from task point-of-view
  • specific for a task type
  • supports top-down knowledge modeling

Analytic versus synthetic tasks

  • analytic tasks
    • system pre-exists
      • it is typically not completely "known"
    • input: some data about the system,
    • output: some characterization of the system
  • synthetic tasks
    • system does not yet exist
    • input: requirements about system to be constructed
    • output: constructed system description

Task hierarchy

Structure of template description in catalog

  • General characterization
    • typical features of a task
  • Default method
    • roles, sub-functions, control structure, inference structure
  • Typical variations
    • frequently occurring refinements/changes
  • Typical domain-knowledge schema
    • assumptions about underlying domain-knowledge structure


  • establish correct class for an object
  • object should be available for inspection
    • "natural" objects
  • examples: rock classification, apple classification
  • terminology: object, class, attribute, feature
  • one of the simplest analytic tasks; many methods
  • other analytic tasks: sometimes reduced to classification problem especially diagnosis


  • find decision category for a case based on domain-specific norms.
  • typical domains: financial applications (loan application), community service
  • terminology: case, decision, norms
  • some similarities with monitoring
    • differences:
      • timing: assessment is more static
      • different output: decision versus discrepancy


  • find fault that causes system to malfunction
    • example: diagnosis of a copier
  • terminology:
    • complaint/symptom, hypothesis, differential, finding(s)/evidence, fault
  • nature of fault varies
    • state, chain, component
  • should have some model of system behavior
    • default method: simple causal model
  • sometimes reduced to classification task
    • direct associations between symptoms and faults
  • automation feasible in technical domains


  • analyze ongoing process to find out whether it behaves according to expectations
  • terminology:
    • parameter, norm, discrepancy, historical data
  • main features:
    • dynamic nature of the system
    • cyclic task execution
  • output "just" discrepancy => no explanation
  • often: coupling monitoring and diagnosis
    • output monitoring is input diagnosis


  • analytic task with some synthetic features
  • analyses current system behavior to construct description of a system state at future point in time.
  • example: weather forecasting
  • often sub-task in diagnosis
  • also found in knowledge-intensive modules of teaching systems e.g. for physics.
  • inverse: retrodiction: big-bang theory


  • Given a set of requirements, construct a system description that fulfills these requirements

“Ideal” synthesis method

  • Operationalize requirements
    • preferences and constraints
  • Generate all possible system structures
  • Select sub-set of valid system structures
    • obey constraints
  • Order valid system structures
    • based on preferences


  • synthetic task
  • system to be constructed is physical artifact
  • example: design of a car
  • can include creative design of components
  • creative design is too hard a nut to crack for current knowledge technology
  • sub-type of design which excludes creative design => configuration design

Configuration design

  • given predefined components, find assembly that satisfies requirements + obeys constraints
  • example: configuration of an elevator; or PC
  • terminology: component, parameter, constraint, preference, requirement (hard & soft)
  • form of design that is well suited for automation
  • computationally demanding


  • create mapping between two sets of objects
    • allocation of offices to employees
    • allocation of airplanes to gates
  • mapping has to satisfy requirements and be consistent with constraints
  • terminology
    • subject, resource, allocation
  • can be seen as a “degenerative” form of configuration design


  • shares many features with design
  • main difference: "system" consists of activities plus time dependencies
  • examples: travel planning; planning of building activities
  • automation only feasible, if the basic plan elements are predefined
  • consider use of the general synthesis method (e.g therapy planning) or the configuration-design method

Planning method


  • Given a set of predefined jobs, each of which consists of temporally sequenced activities called units, assign all the units to resources at time slots
    • production scheduling in plant floors
  • Terminology: job, unit, resource, schedule
  • Often done after planning (= specification of jobs)
  • Take care: use of terms “planning” and “scheduling” differs

In applications: typical task combinations

  • monitoring + diagnosis
    • Production process
  • monitoring + assessment
    • Nursing task
  • diagnosis + planning
    • Troubleshooting devices
  • classification + planning
    • Military applications

    Knowledge model construction

Process & Product

  • so far: focus on knowledge model as product
  • bottleneck for inexperienced knowledge modelers
    • how to undertake the process of model construction.
  • solution: process model
    • as prescriptive as possible
    • process elements: stage, activity, guideline, technique
  • but: modeling is constructive activity
    • no single correct solution nor an optimal path
  • support through a number of guidelines that have proven to work well in practice.
  • knowledge modeling is specialized form of requirements specification
    • general software engineering principles apply

Stages in Knowledge-Model Construction

knowledge identification
  • domain familiarization (information sources, glossary, scenarios)
  • list potential model components for reuse (task- and domain-related components)
knowledge specification
  • choose task template (provides initial task decomposition)
  • construct initial domain conceptualization (main domain information types)
  • complete knowledge-model specification (knowledge model with partial knowledge bases)
knowledge refinement
  • validate knowledge model (paper simulation, prototype of reasoning system)
  • knowledge-base refinement (complete the knowledge bases)

Stage 1: Knowledge identification

  • goal
    • survey the knowledge items
    • prepare them for specification
  • input
    • knowledge-intensive task selected
    • main knowledge items identified.
    • application task classified
      • assessment, configuration, combination of task types
  • activities
    • explore and structure the information sources
    • study the nature of the task in more detail

Exploring information sources

  • Factors
    • Nature of the sources
      • well-understood?, theoretical basis?
    • Diversity of the sources
      • no single information source (e.g. textbook or manual)
      • diverse sources may be conflicting
      • multiple experts is a risk factor.
  • Techniques
    • text marking in key information sources
    • some structured interviews to clarify perceived holes in domain
  • main problem:
    • find balance between learning about the domain without becoming a full


  • Talk to people in the organization who have to talk to experts but are not experts themselves

  • Avoid diving into detailed, complicated theories unless the usefulness is proven

  • Construct a few typical scenarios which you understand at a global level

  • Never spend too much time on this activity. Two person weeks should be maximum.

Results exploration

  • Tangible
    • Listing of domain knowledge sources, including a short characterization.
    • Summaries of selected key texts.
    • Glossary/lexicon
    • Description of scenarios developed.
  • Intangible
    • your own understanding of the domain
      • most important result

List potential components

  • goal: pave way for reusing components
  • two angles on reuse:
    • Task dimension
      • check task type assigned in Task Model
      • build a list of task templates
    • Domain dimension
      • type of the domain: e.g. technical domain
      • look for standardized descriptions

          AAT for art objects ontology libraries, reference models, product model libraries

Stage 2: Knowledge specification

  • goal: complete specification of knowledge except for contents of domain models
    • domain models need only to contain example instances
  • activities
    • Choose a task template.
    • Construct an initial domain conceptualization.
    • Specify the three knowledge categories

Choose task template

  • baseline: strong preference for a knowledge model based on an existing application.
    • efficient, quality assurance
  • selection criteria: features of application task
    • nature of the output: fault category, plan
    • nature of the inputs: kind of data available
    • nature of the system: artifact, biological system
    • constraints posed by the task environment:
      • required certainty, costs of observations.

Guidelines for template selection

  • prefer templates that have been used more than once
    • empirical evidence

  • construct annotated inference structure (and domain schema)

  • if no template fits: question the knowledge-intensity of the task


  • use as much as possible existing data models:
    • useful to use at least the same terminology basic constructs
    • makes future cooperation/exchange easier
  • limit use of the knowledge-modeling language to concepts, sub-types and relations
    • concentrate on "data"
    • similar to building initial class model
  • If no existing data models can be found, use standard SE techniques for finding concepts and relations
    • use “pruning” method
  • Constructing the initial domain conceptualization should be done in parallel with the choice of the task template
    • otherwise: fake it

Complete model specification

  • Route 1: Middle-out
    • Start with the inference knowledge
    • Preferred approach
    • Precondition: task template provides good approximation of inference structure.
  • Route 2: Middle-in
    • Start in parallel with task decomposition and domain modeling
    • More time-consuming
    • Needed if task template is too coarse-grained

Middle-in and Middle-out


  • inference structure is detailed enough, if the explanation it provides is sufficiently detailed
  • inference structure is detailed enough if it is easy to find for each inference a single type of domain knowledge that can act as a static role for this inference

Guidelines for specifying task knowledge

  • begin with the control structure
    • "heart" of the method
  • neglect details of working memory
    • design issue
  • choose role names that clearly indicate role
    • "modeling is naming"
  • do not include static knowledge roles
  • real-time applications: consider using a different representation than pseudo code
    • but: usage of "receive"

Guidelines for specifying domain knowledge

  • domain-knowledge type used as static role not required to have exactly the “right’” representation
    • design issue;
    • key point: knowledge is available.
  • scope of domain knowledge is typically broader than what is covered by inferences
    • requirements of communication, explanation

Stage 3: Knowledge Refinement

  • Validate knowledge model
  • Fill contents of knowledge bases

Fill contents of knowledge bases

  • schema contains two kinds of domain types:
    • information types that have instances that are part of a case
    • knowledge types that have instances that are part of a domain model
  • goal of this task: find (all) instances of the latter type
  • case instances are only needed for a scenario

Guidelines for filling contents

  • filling acts as a validation test of the schema
  • usually not possible to define full, correct knowledge base in the first cycle
  • knowledge bases need to be maintained
    • knowledge changes over time
  • techniques:
    • incorporate editing facilities for KB updating, trace transcripts, structured interview, automated learning, map from existing knowledge bases

Validate knowledge model

  • internally and externally
  • verification = internal validation
    • “is the model right?”
  • validation = validation against user requirements
    • "is it the right model?"

Validation techniques

  • Internal
    • structured walk-troughs
    • software tools for checking the syntax and find missing parts
  • External
    • usually more difficult and/or more comprehensive.
    • main technique: simulation
      • paper-based simulation
      • prototype system

Paper-based simulation

the user says: “the car does not start”
DIAGNOSIS: Complaint: engine- behavior.status = does-not-start
Complaint is received, for which a diagnostic task is started
a possible cause is that the fuel tank is empty
COVER: hypothesis; fuel- tank.status = empty
One of the three possible causes is produced
in that case we would expect the gas indicator to be low
PREDICT: expected-finding: gas-dial.value = zer
The expected finding provides us with a way of getting supporting evidence for hypothesis


  • model development is a cyclic process
  • models act as information repositories
    • continuously updated
  • but: makes requirements for support tools stronger
    • transformation tools

Domain Documentation Document

  • Knowledge model specification
  • list of all information sources used.
  • list of model components that we considered for reuse.
  • scenarios for solving the application problem.
  • results of the simulations undertaken during validation
  • Elicitation material (appendices)

Summary process

  • Knowledge identification
    • familiarization with the application domain
  • Knowledge specification
    • detailed knowledge analysis
    • supported by reference models
  • Knowledge refinement
    • completing the knowledge model
    • validating the knowledge model
  • Feedback loops may be required
    • simulation in third stage may lead to changes in specification
    • Knowledge bases may require looking for additional knowledge sources.
    • general rule: feedback loops occur less frequently, if the application problem is well-understood and similar problems have been tackled

    Knowledge elicitation techniques