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
age
income
loan
amount
interes t
J ohn
has
a
loan
of
$1,750
Harry
has
a
loan
of
$2,500
A
person
with
a
loan
should
be
at
least
18
years
old
A
person
with
an
income
up
to
$10,000
can
get
a
maximum
loan
of
$2,000
A
person
with
an
income
between
$10,000
and
$20,000
can
get
a
maximum
loan
of
$3,000
INF OR MATION
KNOW L E DGE
has
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 ingle
flat

knowledge
bas e
multiple
rule
s ets
containing
rules
with
s imilar
s tructure
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)
hypothesize
(inference)
verify
(inference)
DIAGNOS IS
(task)
Task
knowledge
task
goals
task
decomposition
task
control
Inference
knowledge
basic
inferences
roles
Domain
knowledge
domain
types
domain
rules
domain
facts

Example domain: car diagnosis
fuel
tank
empty
battery
low
battery
dial
zero
gas
dial
zero
power
off
engine
behavior
does
not
s tart engine
behavior
s tops
gas
in
engine
fals e
fus e
blow n
fus e
ins pection
broken
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 -‐LIS T:
{zero,
low,
normal};

TY P E :
ORDINAL;
E ND
VALUE -‐TY P E
dial-‐value;
CONCE P T
gas
dial;

ATTRIBUTE S :

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

ATTRIBUTE S

status:

{full,
almost-‐empty,
empty};
E ND
CONCE P T
fuel-‐tank;
gas
dial
value:
dial-‐value
fuel
tank
status:
{full,

almost-‐empty,

empty}

Example: apple concept
apple
color:
{yellow,
yellow-‐green,
green}
rusty-‐surface:
boolean
greasy-‐surface:
boolean
form:
{flat,
high}
Granny
S mith:
apple
class
Golden
Delicious:
apple
class
Grey
Reinet:
apple
class
Present
of
England:
apple
class
apple
class
has
class

Example: car subtypes
car
state
status:
universal
observable:
boolean
invisible
car
state
observable:
{false}
visible
car
state
observable:
{true}
car
observable
value:
universal
fuel
tank
status:
{full,

almost-‐empty,

empty}
battery
status:
{normal,

low}
fuse
status:
{normal,

blown}
gas
in
engine
status:
boolean
power
status:
{on,

off}
engine
behavior
status:
{normal,

does-‐not-‐start,

stops}
fuse

inspection
value:
{normal,

broken}
gas
dial
value:
dial
value
battery
dial
value:
dial-‐value

Example: house sub-types
apartment
entrance-‐floor:
natural
lift-‐available:
boolean
res idence
hous e
square-‐meters:
natural
CONCE P T
house;

DE S CRIP TION:

"a
residence
with
its
own
territory";

S UB-‐TY P E -‐OF:
residence;

ATTRIBUTE S :

square-‐meters:
NATURAL;
E ND
CONCE P T
house;
CONCE P T
apartment;

DE S CRIP TION:

"part
of
of
a
larger
estate";

S UB-‐TY P E -‐OF:
residence;

ATTRIBUTE 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
car pers on
car pers on
ownership
owners hip
purchase
date:
date;
a)
b) car pers on
owned-‐by
c)
0+ 0-‐1

N-ary relation
agent
name
position
obs ervation
value
date
time
obs ervable
type
location
department
hospital
patient
name
diagnosis

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
loan
constraint

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:
string
income:
integer
loan
amount:
integer
interest-‐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
invisible
car
state
car
state
car

observable
invisible
car
state
manifestation
rule
state
dependency

causes

has
manifestation
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 hypothesiscover
causal
model
my
car
does
not
start
fuel
tank
is
empty
fuel
tank
is
empty
leads
to
lack
of
gas
in
engine
if
there
is
no
gas
in
the
engine,
then
the
car
does
not
start
dynamic
input
role dynamic
output
role
static
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 tem
initiative
external
initiative
external
information
internal
information

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
complaint

cover
predict compare
obtain
expected
finding
actual
finding
result
causal

model
manifestation

model
hypothesis

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
complaint

cover
predict compare
obtain
expected
finding
actual
finding
result
causal

model
manifestation

model
hypothesis
engine
does
not
start
state
dependency
rules
empty
fuel
tank
gas
dial
=
zero/low
gas
dial
=
normal
not
equal
manifestation
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
predict
obtain compare
[no
more
solutions
of
cover]
[new
solution
of
cover]
[result
=
equal]
[result
=
not
equal]
solution
found
no
solution
found
start
diagnosis
through
generate-‐and-‐test

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
DATA
viewpoint
FUNC TION
viewpoint
Object-‐Oriented
Analysis
(OMT,
Booch,
....)
S tructured
Analysis
(Y ourdon)
CommonK ADS :
function-‐data
decoupling
functional
decomposition
is
starting
point
data
types
are
derived
from
DFDs
static
information
structure
is
starting
point
functions
are
grouped
with
the
data
reuse
of
data/function
groups
("objects")
parallel
function/data
description
reusable
functional
decompositions
reusable
data/knowledge
types

CommonKADS knowledge modelling basics

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (6)

Plus de Guus Schreiber

Plus de Guus Schreiber (20)

Dernier

Dernier (20)

CommonKADS knowledge modelling basics