Knowledge Model Basics
Challenges in knowledge modeling
Basic knowledge-modeling constructs
Comparison to general software analysis
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
person
ageincome
loan
amount interest
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 INFORMATION
KNOWLEDGE
has loan
Structuring a knowledge base
Rule 1: IF ... THEN ...
Rule 2: IF ... THEN ...
Rule 3: IF ... THEN ...
Rule 12: IF ... THEN ...
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 ...
<plus many others>
single flat knowledge base
multiple rule sets containing rules with similar structure
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
Disease (type) Symptom
(type) Test
(type) hypothesize
(inference) verify (inference)
DIAGNOSIS (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
of
engine behavior
does not start engine behavior
stops
gas in engine
false blownfuse
fuse inspection
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-TYPE dial-value;
VALUE-LIST: {zero, low, normal};
TYPE: ORDINAL;
END VALUE-TYPE dial-value;
CONCEPT gas dial;
ATTRIBUTES:
value: dial-value;
END CONCEPT gas-dial; CONCEPT fuel-tank;
ATTRIBUTES
status: {full, almost-empty, empty};
END CONCEPT 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 Smith:
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,
of} 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
residence
house
square-meters: natural
CONCEPT house;
DESCRIPTION:
"a residence with its own territory";
SUB-TYPE-OF: residence;
ATTRIBUTES:
square-meters: NATURAL;
END CONCEPT house;
CONCEPT apartment;
DESCRIPTION:
"part of of a larger estate";
SUB-TYPE-OF: residence;
ATTRIBUTES:
entrance-floor: NATURAL;
lift-available: BOOLEAN;
END CONCEPT 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 person
car person
ownership
ownership a)
b) car person
owned-by
c)
0+ 0-1
N-ary relation
agent nameposition
observation value
datetime
observable type
location department hospital
patient namediagnosis
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
constraintloan restricts
person.income <= 10,000 RESTRICTS
loan.amount <= 2,000
person.income > 10,000 AND person.income <= 20,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
observablecar invisible
car state
manifestation state dependency
causes
manifestationhas
1 1
1 1
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; …..
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 cover hypothesis
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 system
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
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";
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
[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
viewpointDATA
FUNCTION viewpoint Object-Oriented Analysis
(OMT, Booch, ....)
Structured Analysis (Yourdon) CommonKADS:
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
