commonkads knowledge modelling basics
DESCRIPTION
Ch. 5 of the CommonKADS textbookTRANSCRIPT
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
Knowledge-modelling basics 3
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
Knowledge-modelling basics 4
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 5
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
Knowledge-modelling basics 6
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-modelling basics 7
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-modelling basics 8
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
Knowledge-modelling basics 9
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
Knowledge-modelling basics 10
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 11
Constructs for domain schema
■ Concept ➤ cf. object class (without operations)
■ Relation ➤ cf. association
■ Attribute ➤ primitive value
■ Rule type ➤ introduces expressions => no SE equivalent
Knowledge-modelling basics 12
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 13
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}
Knowledge-modelling basics 14
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
Knowledge-modelling basics 15
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
Knowledge-modelling basics 16
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;
Knowledge-modelling basics 17
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 18
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
Knowledge-modelling basics 19
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
Knowledge-modelling basics 20
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 21
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 22
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+
Knowledge-modelling basics 23
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 24
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-modelling basics 25
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 26
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 27
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 28
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
Knowledge-modelling basics 29
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-modelling basics 30
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 31
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 32
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 33
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 34
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 35
Types of transfer functions
obtain receive
present provide
s ys teminitiative
externalinitiative
externalinformation
internalinformation
Knowledge-modelling basics 36
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 37
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
Knowledge-modelling basics 38
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 39
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
Knowledge-modelling basics 40
Reusing inferences
■ Standard set of inferences?! ➤ difficult subject
■ See catalog in Ch. 13 ■ Use as much as possible standard names
Knowledge-modelling basics 41
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 42
Task decomposition for car diagnosis
diagnosis
diagnosis through
generate-and-test
obtain cover
predict
task
task method
compare
decomposition
inferences transfer function
Knowledge-modelling basics 43
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 44
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 45
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 46
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 47
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 48
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
Knowledge-modelling basics 49
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
Knowledge-modelling basics 50
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 51
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 52
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
Knowledge-modelling basics 53
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