Knowledge Model Basics
Challenges in knowledge modeling
Basic knowledge-modeling constructs
Comparison to general software analysis
Knowledge model




specialized tool for specification of knowledgeintensive tasks
abstracts from communication aspects
real-world oriented
reuse is central theme
Knowledge-modelling basics
2
Relation to other models
task selected in feasibility study
and further detailed in
Task and Agent Models
organization model
task model
agent model
communication
model
knowledgeintensive
task
design
model
knowledge
model
Knowledge-modelling basics
requirements
specification
for interaction functions
requirements
specification
for reasoning functions
3
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
Knowledge-modelling basics
4
Challenges in specifying
knowledge
person
age
income
has loan
loan
amount
interest
INFORMATION
John has a loan of $1,750
Harry has a loan of $2,500
KNOW LEDGE
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
Knowledge-modelling basics
5
Structuring a knowledge base
Rule 1: IF ... THEN ...
Rule 2: IF ... THEN ...
Rule 3: IF ... THEN ...
rules of type A
rules of type B
rules of type C
rules of type D
Rule 4: IF ... THEN ...
Rule 5: IF ... THEN ...
Rule 6: IF ... THEN ...
Rule 7: IF ... THEN ...
Rule 8: IF ... THEN ...
Rule 9: IF ... THEN ...
Rule 10: IF ... THEN ...
Rule 11: IF ... THEN ...
Rule 12: IF ... THEN ...
<plus many others>
single flat
knowledge base
Knowledge-modelling basics
multiple rule sets
containing rules
with similar structure
6
Knowledge categories

Task knowledge



Domain knowledge



goal-oriented
functional decomposition
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-modelling basics
7
Knowledge model overview
Task knowledge
task goals
task decomposition
task control
DIAGNOSIS
(task)
Inference knowledge
basic inferences
roles
hypothesize
(inference)
verify
(inference)
Domain knowledge
domain types
domain rules
domain facts
Knowledge-modelling basics
Symptom
(type)
Disease
(type)
Test
(type)
8
Example domain: car diagnosis
fuse
battery
fuel tank
blow n
low
empty
1
4
2
5
3
fuse inspection
battery dial
gas dial
broken
zero
zero
6
gas in engine
false
power
off
7
engine behavior
does not start
Knowledge-modelling basics
8
9
engine behavior
stops
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
Knowledge-modelling basics
10
Constructs for domain schema

Concept


Relation


cf. association
Attribute


cf. object class (without operations)
primitive value
Rule type

introduces expressions => no SE equivalent
Knowledge-modelling basics
11
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
Knowledge-modelling basics
12
Example: car concepts
gas dial
fuel tank
value: dial-value
status: {full,
almost-empty,
empty}
CONCEPT gas dial;
ATTRIBUTES:
value: dial-value;
END CONCEPT gas-dial;
CONCEPT fuel-tank;
ATTRIBUTES
status: {full, almost-empty, empty};
END CONCEPT fuel-tank;
VALUE-TYPE dial-value;
VALUE-LIST: {zero, low, normal};
TYPE: ORDINAL;
END VALUE-TYPE dial-value;
Knowledge-modelling basics
13
Example: apple concept
apple
color: {yellow, yellow-green, green}
rusty-surface: boolean
greasy-surface: boolean
form: {flat, high}
has class
Granny Smith:
apple class
Grey Reinet:
apple class
Knowledge-modelling basics
apple class
Golden Delicious:
apple class
Present of England:
apple class
14
Example: car subtypes
car observable
car state
value: universal
status: universal
observable: boolean
invisible
car state
observable: {false}
gas dial
battery dial
fuse
value: dial value
value: dial-value
status: {normal,
blown}
fuse
inspection
value: {normal,
broken}
Knowledge-modelling basics
observable: {true}
power
battery
status: {normal,
low}
visible
car state
status: {on,
off}
fuel tank
gas in engine
status: {full,
almost-empty,
empty}
status: boolean
engine behavior
status: {normal,
does-not-start,
stops}
15
Example: house sub-types
residence
CONCEPT house;
DESCRIPTION:
"a residence with its own territory";
SUB-TYPE-OF: residence;
ATTRIBUTES:
square-meters: NATURAL;
END CONCEPT house;
Knowledge-modelling basics
house
square-meters: natural
apartment
entrance-floor: natural
lift-available: boolean
CONCEPT apartment;
DESCRIPTION:
"part of of a larger estate";
SUB-TYPE-OF: residence;
ATTRIBUTES:
entrance-floor: NATURAL;
lift-available: BOOLEAN;
END CONCEPT apartment;
16
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
Knowledge-modelling basics
17
Example: car relation
a)
car
b)
car
c)
car
0+
ownership
owned-by
0-1
person
person
person
ownership
purchase date: date;
Knowledge-modelling basics
18
N-ary relation
agent
name
position
patient
name
diagnosis
location
observable
department
hospital
type
observation
value
date
time
Knowledge-modelling basics
19
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
Knowledge-modelling basics
20
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
Knowledge-modelling basics
21
Example rule type
person
loan
1+
restricts
name: string
income: integer
amount: integer
interest-rate: number
loan
const raint
person.income < = 10,000
RESTRICTS
loan.amount < = 2,000
person.income > 10,000 AND person.income < = 20,000
RESTRICTS
loan.amount < = 3,000
Knowledge-modelling basics
22
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
Knowledge-modelling basics
23
Rule types for car diagnosis
invisible
car st at e
1
causes
1
car st at e
st at e
dependency
invisible
car st at e
1
has
manifestation
1
car
observable
manifest at ion
rule
Knowledge-modelling basics
24
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)
Knowledge-modelling basics
25
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;
Knowledge-modelling basics
26
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
Knowledge-modelling basics
27
Example inference: cover
dynamic input role
complaint
inference
dynamic output role
cover
hypothesis
my car does not start
fuel tank is empty
causal
model
static role
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
Knowledge-modelling basics
28
Inference


fully described through a declarative specification of
properties of its I/O
internal process of the inference is a black box


I/O described using “role names”


not of interest for knowledge modeling.
functional names, not part of the domain knowledge schema
/ data model
guideline to stop decomposition: explanation
Knowledge-modelling basics
29
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
Knowledge-modelling basics
30
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;
Knowledge-modelling basics
31
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;
Knowledge-modelling basics
32
Example static knowledge role
KNOWLEDGE-ROLE causal-model;
TYPE: STATIC;
DOMAIN-MAPPING: state-dependency FROM car-network;
END KNOWLEDGE-ROLE causal-model;
Knowledge-modelling basics
33
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
Knowledge-modelling basics
34
Types of transfer functions
system
initiative
external
initiative
external
information
obtain
receive
internal
information
present
provide
Knowledge-modelling basics
35
Inference structure



combined set of inferences specifies the basic
inference capability of the target system
graphical representation: inference structure
provides constraints for control flow
Knowledge-modelling basics
36
Example: car inferences
complaint
cover
hypothesis
causal
model
predict
manifestation
model
Knowledge-modelling basics
obtain
actual
finding
expected
finding
compare
result
37
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
Knowledge-modelling basics
38
Annotated inference structure
complaint
engine does
not start
state dependency
rules
causal
model
cover
hypothesis
predict
gas dial = normal
obtain
actual
finding
expected
finding
compare
gas dial = zero/low
empty fuel tank
manifestation
rules
Knowledge-modelling basics
manifestation
model
not equal
result
39
Reusing inferences

Standard set of inferences?!



difficult subject
See catalog in Ch. 13
Use as much as possible standard names
Knowledge-modelling basics
40
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:
Knowledge-modelling basics
41
Task decomposition for
car diagnosis
task
task method
diagnosis
diagnosis
through
generate-and-test
decomposition
obtain
cover
predict
compare
transfer function
inferences
Knowledge-modelling basics
42
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”
Knowledge-modelling basics
43
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;
Knowledge-modelling basics
44
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
Knowledge-modelling basics
45
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";
Knowledge-modelling basics
46
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
Knowledge-modelling basics
47
UML activity diagram for
method control
cover
[result = not equal]
start
diagnosis
through
generate-and-test
[no more solutions
of cover]
no solution found
[new solution
of cover]
[result = equal]
solution found
predict
obtain
Knowledge-modelling basics
compare
48
Control structure elements

“procedure” calls:


role operations


tasks, transfer functions, inferences
assign, add/append, delete/subtract, retrieve, ..
control primitives

repeat-until, while-do, foreach-do, if-then-else
Knowledge-modelling basics
49
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
Knowledge-modelling basics
50
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-modelling basics
51
Knowledge model vs.
SE analysis model

“Data model” contains “data about data”


Functions are described data-model independent


enables reuse of reasoning functions
Emphasis on “internal control”


= knowledge
strategy of reasoning process
Knowledge model abstracts from communication
aspects
Knowledge-modelling basics
52
The data-function debate
Object-Oriented Analysis
(OMT, Booch, ....)
DATA
viewpoint
parallel function/data description
reusable functional decompositions
reusable data/k nowledge types
CommonKADS:
function-data decoupling
Structured Analysis
(Yourdon)
Knowledge-modelling basics
static information structure is starting point
functions are grouped with the data
reuse of data/function groups ("objects")
FUNCTION
viewpoint
functional decomposition is starting point
data types are derived from DFDs
53