CommonKADS knowledge modelling basics

Knowledge Model Basics

Challenges in knowledge modeling Basic knowledge-modeling constructs

Comparison to general software analysis

Knowledge-modelling basics 2

Knowledge model

■  specialized tool for specification of knowledge-intensive tasks

■  abstracts from communication aspects ■  real-world oriented ■  reuse is central theme


Relation to other models

organization model task model

agent model knowledge- intensive

task

communication model

knowledge model

design model

requirements specification

for interaction functions

requirements specification

for reasoning functions

task selected in feasibility study and further detailed in

Task and Agent Models


The term “knowledge”

■  “information about information” ■  example: sub-class hierarchy of object types ■  no hard borderline between information and

knowledge ➤  knowledge is “just“ semantically rich information

■  target: “knowledge-intensive” systems ➤  large bulk of meaningful information is present ➤  scope is broader than traditional KBS


Challenges in specifying knowledge

pers on

ageincome

loan

amountinteres t

J ohn ha s a loan of $1,750Ha rry ha s a loan of $2,500

A pers on with a loan s hould be a t lea s t 18 yea rs oldA pers on with an income up to $10,000 can g e t a maximum loan of $2,000A pers on with an income between $10,000 and $20,000 can g e t a maximum loan of $3,000

INFORMATION

KNOWL E DGE

ha s loan


Structuring a knowledge base

R ule 1: IF ... T HE N ...R ule 2: IF ... T HE N ...R ule 3: IF ... T HE N ...

R ule 12: IF ... T HE N ...

R ule 4: IF ... T HE N ...R ule 5: IF ... T HE N ...R ule 6: IF ... T HE N ...R ule 7: IF ... T HE N ...R ule 8: IF ... T HE N ...R ule 9: IF ... T HE N ...R ule 10: IF ... T HE N ...R ule 11: IF ... T HE N ...

<plus many others >

s ing le fla t knowledge bas e

multiple rule s etsconta ining rules

with s imila r s truc ture

rules of type A

rules of type D

rules of type B

rules of type C


Knowledge categories

■  Task knowledge ➤  goal-oriented ➤  functional decomposition

■  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


Knowledge model overview

Dis eas e(type)

S ymptom(type)

Tes t(type)

hypothes ize(inference)

verify(inference)

DIAGNOS IS(tas k)

Task knowledgetask goalstask decompos itiontask c ontrol

Inference knowledgebas ic inferencesroles

Domain knowledgedomain typesdomain rulesdomain fac ts


Example domain: car diagnosis

fue l tankempty

batterylow

battery dia lz ero

gas dia lz ero

poweroff

eng ine behav iordoes not s tart eng ine behav ior

s tops

gas in eng inefals e

fus eblow n

fus e ins pectionbroken

1

2 3

4 5

6

7 8 9


Domain knowledge

■  domain schema ➤  schematic description of knowledge and information types ➤  comparable to data model ➤  defined through domain constructs

■  knowledge base ➤  set of knowledge instances ➤  comparable to database content ➤  but; static nature


Constructs for domain schema

■  Concept ➤  cf. object class (without operations)

■  Relation ➤  cf. association

■  Attribute ➤  primitive value

■  Rule type ➤  introduces expressions => no SE equivalent


Concept & attribute

■  “Concept” describes a set of objects or instances ■  multiple concept hierarchies

➤  along distinct dimensions

■  can have any number of attributes ■  Am attribute refers to a value ■  values are atomic and are defined through a value

type ■  attribute may not refer to another concept

➤  use relation construct


Example: car concepts

VALUE -‐TY P E dial-‐value; VALUE -‐L IS T: {z ero, low, normal}; TY P E : ORDINAL ;E ND VALUE -‐TY P E dial-‐value;

CONCE P T gas dial; ATTR IBUTE S : value: dial-‐value;E ND CONCE P T gas -‐dial; CONCE P T fuel-‐tank;

ATTR IBUTE S s tatus : {full, almos t-‐empty, empty};E ND CONCE P T fuel-‐tank;

g as dial

value: dial-‐value

fuel tank

s tatus : {full, almost-‐empty , empty}


Example: apple concept

apple

color: {yellow, yellow-‐green, green}rus ty-‐s urface: booleangreas y-‐s urface: booleanform: {flat, high}

Granny S mith:apple c lass

Golden Delic ious:apple c lass

Grey Reinet:apple c lass

P resent of Eng land:apple c lass

apple c lasshas c las s


Example: car subtypes car sta te

s tatus : univers alobs ervable: boolean

invisiblecar sta te

obs ervable: {fals e}

visiblecar sta te

obs ervable: {true}

ca r observable

value: univers al

fue l tank

s tatus : {full, almos t-‐empty, empty}

battery

s tatus : {normal, low}

fuse

s tatus : {normal, blown}

gas in eng ine

s tatus : boolean

power

s tatus : {on, off}

eng ine behavior

s tatus : {normal, does -‐not-‐s tart, s tops }

fuse inspec tion

value: {normal, broken}

gas dia l

value: dial value

battery dia l

value: dial-‐value


Example: house sub-types

apartment

entrance-‐floor: naturallift-‐available: boolean

res idence

hous e

s quare-‐meters : natural

CONCE P T hous e; DE S C R IP TION: "a res idence with its own territory"; S UB -‐TY P E -‐OF : res idence; ATTR IBUTE S : s quare-‐meters : NATURAL ;E ND CONCE P T hous e;

CONCE P T apartment; DE S C R IP TION: "part of of a larger es tate"; S UB -‐TY P E -‐OF : res idence; ATTR IBUTE S : entrance-‐floor: NATURAL ; lift-‐available: BOOLE AN;E ND CONCE P T apartment;


Relation

■  typically between concepts, any arity ■  cardinality specification ■  special construct for binary relations ■  relations can have subtypes as well as attributes ■  reification of a relation is allowed

➤  relation functions as a concept ➤  cf. Association class in UML ➤  a form of higher order relations


Example: car relation

c ar pers on

car pers on

ownership

owners hippurchas e date: date;

a)

b) c ar pers onowned-‐by

c )

0+ 0-‐1


N-ary relation

agent

namepos ition

obs erv ation

va lueda tetime

obs erv able

type

loca tion

depa rtmenthos pita l

patient

namedia gnos is


Modelling rules

■  “rules” are a common form for symbolic knowledge ■  do not need to be formal ■  knowledge analysis is focused on finding rules with a

common structure ➤  a rule as an instance of a rule type


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

■  dependency is usually not strictly logical (= implication) ➤  specify connection symbol


Example rule type

loanconstra int

restricts

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

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

person

name: stringincome: integer

loan

amount: integerinterest-‐rate: number

1+


Rule type structure

■  <antecedent> <connection-symbol> <consequent> ■  example rule:

fuel-supply.status = blocked

CAUSES

gas-in-engine.status = false;

■  flexible use for almost any type of dependency ➤  multiple types for antecedent and consequent


Rule types for car diagnosis

inv is iblecar s ta te car s ta te

car observable

inv is iblecar s ta te

manifes ta t ionrule

s ta tedependency

caus es

ha smanifes ta tion

1 1

11


Knowledge base

■  = conceptual knowledge-base partition ■  contains instances of knowledge types ■  rule-type instances = “rules” ■  structure:

➤  USES: <types used> from <schema> ➤  EXPRESSIONS: <instances>

■  instance representation: ➤  intuitive natural language

–  connection symbol ➤  formal expression language (appendix of book)


Example knowledge base

KNOWLEDGE-BASE car-network; USES: state-dependency FROM car-diagnosis-schema,

manifestation-rule FROM car-diagnosis-schema; EXPRESSIONS:

/* state dependencies */ fuse.status = blown CAUSES power.status = off;

battery.status = low CAUSES power.status = off; ….

/* manifestation rules */ fuse.status = blown HAS-MANIFESTATION fuse-inspection.value = broken; battery.status = low HAS-MANIFESTATION battery-dial.value = zero; …..

END KNOWLEDGE-BASE car-network;


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

complaint hypothes iscover

caus almodel

my car does not s tartfuel tank is empty

fuel tank is empty leads to lack of gas in engineif there is no gas in the engine, then the car does not s tart

dynamic input role dynamic output role

sta tic role

inference


Inference

■  fully described through a declarative specification of properties of its I/O

■  internal process of the inference is a black box ➤  not of interest for knowledge modeling.

■  I/O described using “role names” ➤  functional names, not part of the domain knowledge

schema / data model

■  guideline to stop decomposition: explanation


Knowledge role

■  Functional name for data/knowledge elements ■  Name captures the “role” of the element in the

reasoning process ■  Explicit mapping onto domain types ■  Dynamic role: variant input/output ■  Static role: invariant input

➤  cf. a knowledge basel


Example inference

INFERENCE cover; ROLES: INPUT: complaint; OUTPUT: hypothesis; STATIC: causal-model;

SPECIFICATION: "Each time this inference is invoked, it generates a candidate

solution that could have caused the complaint. The output thus should be an initial state in the state dependency network which causally ``covers'' the input complaint.";

END INFERENCE cover;


Example dynamic knowledge roles

KNOWLEDGE-ROLE complaint; TYPE: DYNAMIC; DOMAIN-MAPPING: visible-state;

END KNOWLEDGE-ROLE complaint; KNOWLEDGE-ROLE hypothesis;

TYPE: DYNAMIC; DOMAIN-MAPPING: invisible-state;

END KNOWLEDGE-ROLE hypothesis;


Example static knowledge role

KNOWLEDGE-ROLE causal-model;

TYPE: STATIC; DOMAIN-MAPPING: state-dependency FROM car-network;

END KNOWLEDGE-ROLE causal-model;


Transfer functions

■  transfers an information item between the reasoning agent and another agent

■  from the knowledge-model point of view black box: only its name and I/O

■  detailed specification of transfer functions is part of communication model

■  standard names


Types of transfer functions

obtain receive

present provide

s ys teminitiative

externalinitiative

externalinformation

internalinformation


Inference structure

■  combined set of inferences specifies the basic inference capability of the target system

■  graphical representation: inference structure ■  provides constraints for control flow


Example: car inferences

compla int

cover

predict compare

obta in

expectedfinding

actua lfinding

res ult

caus a l model

manifes ta tion model

hypothes is


Using inference structures

■  Important communication vehicle during development process

■  Often provisional inference structures ■  Can be difficult to understand because of “vague” (non domain-specific terms)

■  Often useful to annotate with domain-specific examples


Annotated inference structure

compla int

cover

predict compare

obta in

expectedfinding

actua lfinding

res ult

caus a l model

manifes ta tion model

hypothes is

engine doesnot s tart

s tate dependencyrules

empty fuel tank gas dial = z ero/low

gas dial = normal

not equalmanifes tation

rules


Reusing inferences

■  Standard set of inferences?! ➤  difficult subject

■  See catalog in Ch. 13 ■  Use as much as possible standard names


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:


Task decomposition for car diagnosis

diagnosis

diagnosis through

generate-and-test

obtain cover

predict

task

task method

compare

decomposition

inferences transfer function


Task

■  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”


Example task

TASK car-fault-category; GOAL: "Find a likely cause for the complaint of the user";

ROLES: INPUT: complaint: "Complaint about the behavior of the car";

OUTPUT: fault-category: "A hypothesis explained by the

evidence"; evidence: "Set of observations obtained during the

diagnostic process"; SPEC: "Find an initial state that explains the complaint and is consistent with the evidence obtained";

END TASK car-diagnosis;


Task method

■  describes how a task is realized through a decomposition into sub-functions

■  sub-functions: another task, inference, transfer function

■  core part of a method: “control structure” ➤  describes ordering of sub-functions small program,

captured reasoning strategy

■  additional task roles ➤  to store intermediate reasoning results


Example task method

TASK-METHOD diagnosis-through-generate-and-test; DECOMPOSITION: INFERENCES: cover, predict, compare; TRANSFER-FUNCTIONS: obtain; ROLES: INTERMEDIATE: expected-finding: "The finding predicted, in case the hypothesis is true"; actual-finding: "The finding actually observed";


Example method control

CONTROL-STRUCTURE: REPEAT cover(complaint -> hypothesis);

predict(hypothesis -> expected-finding); obtain(expected-finding -> actual-finding); evidence := evidence ADD actual-finding; compare(expected-finding + actual-finding -> result); UNTIL "result = equal or no more solutions of over";

END REPEAT IF result == equal

THEN fault-category := hypothesis; ELSE "no solution found"; END IF


UML activity diagram for method control

cover

predic t

obtain compare

[no more s olutionsof cover]

[new s olutionof cover]

[res ult = equal]

[res ult = not equal]

s olution found

no s olution found

s tartdiagnos isthrough

generate-‐and-‐tes t


Control structure elements

■  “procedure” calls: ➤  tasks, transfer functions, inferences

■  role operations ➤  assign, add/append, delete/subtract, retrieve, ..

■  control primitives ➤  repeat-until, while-do, foreach-do, if-then-else


Control structures (cont.)

Conditions: ■  logical expressions about roles:

➤  until differential = empty

■  two special conditions ➤  has-solution

–  invocation of inference that can fail ➤  new solution

–  invocation of inference that can succeed multiple times, e.g. the cover inference in the car-diagnosis model


Inference or task?

■  “If the internal behavior of a function are important for explaining the behavior of the system as a whole, then one needs to define this function as a task”

■  During development: provisional inference structures ■  Function = task or inference (or transfer function)


Knowledge model vs. SE analysis model

■  “Data model” contains “data about data” ➤  = knowledge

■  Functions are described data-model independent ➤  enables reuse of reasoning functions

■  Emphasis on “internal control” ➤  strategy of reasoning process

■  Knowledge model abstracts from communication aspects


The data-function debate

DATAviewpoint

FUNC TIONviewpoint

Object-‐Oriented Analys is(OMT, B ooch, ....)

S tructured Analys is(Y ourdon)

C ommonK ADS :function-‐data decoupling

func tional decompos ition is s tarting pointdata types are derived from DFDs

s tatic information s truc ture is s tarting pointfunc tions are grouped with the data

reus e of data/func tion groups ("objec ts ")

parallel func tion/data des c riptionreus able func tional decompos itionsreus able data/k nowledge types

CommonKADS knowledge modelling basics

Technology

Transcript of CommonKADS knowledge modelling basics