Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
Introduction to Knowledge Engineering and Knowledge Modelling
Excerpt from 6 presentations on CommonKADS course
University of Amsterdam
@ Universiteit van Amsterdam Introduction 2
Data, information & knowledge
� Data� “raw signals”
. . . - - - . . .
� Information� meaning attached to data
S O S
� Knowledge� attach purpose and competence to information� potential to generate action
emergency alert → start rescue operation
@ Universiteit van Amsterdam Introduction 3
Knowledge engineering
process of� eliciting,� structuring,� formalizing,� operationalizing
information and knowledge involved in a knowledge-intensive problem domain,
in order to construct a program that can perform a difficult task adequately
@ Universiteit van Amsterdam Introduction 4
Problems in knowledge engineering
� complex information and knowledge is difficult to observe
� experts and other sources differ� multiple representations:
� textbooks� graphical representations� heuristics� skills
@ Universiteit van Amsterdam Introduction 5
Importance of proper knowledge engineering
� Knowledge is valuable and often outlives a particular implementation� knowledge management
� Errors in a knowledge-base can cause serious problems
� Heavy demands on extendibility and maintenance� changes over time
@ Universiteit van Amsterdam Introduction 6
A Short History of Knowledge Systems
1965 19851975 1995
general-purpose search engines
(GPS)
first-generation rule-based systems
(MYCIN, XCON)
emergence of structured methods
(early KADS)
mature methodologies
(CommonKADS)
=> from art to discipline =>
@ Universiteit van Amsterdam Introduction 7
First generation “Expert” Systems
� shallow knowledge base� single reasoning principle� uniform representation� limited explanation
capabilities
reasoningcontrol
knowledgebase
operateson
@ Universiteit van Amsterdam Introduction 8
Transfer View of KE
� Extracting knowledge from a human expert� “mining the jewels in the expert’s head”’
� Transferring this knowledge into KS. � expert is asked what rules are applicable � translation of natural language into rule format
@ Universiteit van Amsterdam Introduction 9
Problems with transfer view
The knowledge providers, the knowledge engineer and the knowledge-system developer should share � a common view on the problem solving process and � a common vocabulary
in order to make knowledge transfer a viable way of knowledge engineering
@ Universiteit van Amsterdam Introduction 10
Rapid Prototyping
� Positive� focuses elicitation and interpretation� motivates the expert� (convinces management)
� Negative� large gap between verbal data and implementation� architecture constrains the analysis hence: distorted model� difficult to throw away
@ Universiteit van Amsterdam Introduction 11
Model-Based KE
� The knowledge-engineering space of choices and tools can to some extent be controlled by the introduction of a number of models
� Each model emphasizes certain aspects of the system to be built and abstracts from others.
� Models provide a decomposition of knowledge-engineering tasks: while building one model, the knowledge engineer can temporarily neglect certain other aspects.
@ Universiteit van Amsterdam Introduction 12
CommonKADS principles
� Knowledge engineering is not some kind of `mining from the expert's head', but consists of constructing different aspect models of human knowledge
� The knowledge-level principle: in knowledge modeling, first concentrate on the conceptual structure of knowledge, and leave the programming details for later
� Knowledge has a stable internal structure that is analyzable by distinguishing specific knowledge types and roles.
@ Universiteit van Amsterdam Introduction 13
CommonKADS theory
� KBS construction entails the construction of a number of models that together constitute part of the product delivered by the project.
� Supplies the KBS developer with a set of model templates.
� This template structure can be configured, refined and filled during project work.
� The number and level of elaboration of models depends on the specific project context.
@ Universiteit van Amsterdam Introduction 14
CommonKADS Model Set
OrganizationModel
TaskModel
AgentModel
KnowledgeModel
CommunicationModel
DesignModel
Context
Concept
Artefact
@ Universiteit van Amsterdam Introduction 15
Model Set Overview (1)
� Organization model� supports analysis of an organization, � Goal: discover problems, opportunities and possible
impacts of KBS development.
� Task model� describes tasks that are performed or will be performed in
the organizational environment
� Agent model� describes capabilities, norms, preferences and permissions
of agents (agent = executor of task).
@ Universiteit van Amsterdam Introduction 16
Model Set Overview (2)
� Knowledge model� gives an implementation-independent description of
knowledge involved in a task.
� Communication model� models the communicative transactions between agents.
� Design model� describes the structure of the system that needs to be
constructed.
@ Universiteit van Amsterdam Introduction 17
Roles in knowledge-system development
� knowledge provider� knowledge engineer/analyst� knowledge system developer� knowledge user� project manager� knowledge manager
N.B. many-to-many relations between roles and people
@ Universiteit van Amsterdam Introduction 18
Roles in knowledge-system development
knowledgeprovider/specialist
projectmanager
knowledgesystem developer
knowledgeengineer/analyst
knowledgemanager
knowledgeuser
KS
manages
managesuses
designs &implements
validates
elicits knowledgefrom
elicitsrequirements
from
deliversanalysis models
to
defines knowledge strategyinitiates knowledge development projectsfacilitates knowledge distribution
@ Universiteit van Amsterdam Introduction 19
Knowledge model
� specialized tool for specification of knowledge-intensive tasks
� abstracts from communication aspects� real-world oriented� reuse is central theme
@ Universiteit van Amsterdam Introduction 20
Relation to other models
organization modeltask model
agent modelknowledge-
intensivetask
communicationmodel
knowledgemodel
designmodel
requirementsspecification
for interaction functions
requirementsspecification
for reasoning functions
task selected in feasibility studyand further detailed in
Task and Agent Models
@ Universiteit van Amsterdam Introduction 21
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
@ Universiteit van Amsterdam Introduction 22
Knowledge model overview
Disease(type)
Symptom(type)
Test(type)
hypothesize(inference)
verify(inference)
DIAGNOSIS(task)
Task knowledgetask goalstask decompositiontask control
Inference knowledgebasic inferencesroles
Domain knowledgedomain typesdomain rulesdomain facts
@ Universiteit van Amsterdam Introduction 23
Example domain: car diagnosis
fuel tankempty
batterylow
battery dialzero
gas dialzero
poweroff
engine behaviordoes not start engine behavior
stops
gas in enginefalse
fuseblown
fuse inspectionbroken
1
2 3
4 5
6
7 8 9
@ Universiteit van Amsterdam Introduction 24
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
@ Universiteit van Amsterdam Introduction 25
Constructs for domain schema
� Concept� cf. object class (without operations)
� Relation� cf. association
� Attribute� primitive value
� Rule type� introduces expressions => no SE equivalent
@ Universiteit van Amsterdam Introduction 26
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
@ Universiteit van Amsterdam Introduction 27
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}
@ Universiteit van Amsterdam Introduction 28
Example: car subtypes
car state
status: universalobservable: boolean
invisiblecar state
observable: {false}
visiblecar 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
@ Universiteit van Amsterdam Introduction 29
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
@ Universiteit van Amsterdam Introduction 30
Example: car relation
car person
car person
ownership
ownershippurchase date: date;
a)
b) car personowned-by
c)
0+ 0-1
@ Universiteit van Amsterdam Introduction 31
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
@ Universiteit van Amsterdam Introduction 32
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
@ Universiteit van Amsterdam Introduction 33
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
@ Universiteit van Amsterdam Introduction 34
Rule types for car diagnosis
invisiblecar state car state
car observable
invisiblecar state
manifestationrule
statedependency
causes
hasmanifestation
1 1
11
@ Universiteit van Amsterdam Introduction 35
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)
@ Universiteit van Amsterdam Introduction 36
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;
@ Universiteit van Amsterdam Introduction 37
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
@ Universiteit van Amsterdam Introduction 38
Example inference: cover
complaint hypothesiscover
causalmodel
my car does not startfuel 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 start
dynamic input role dynamic output role
static role
inference
@ Universiteit van Amsterdam Introduction 39
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
@ Universiteit van Amsterdam Introduction 40
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
@ Universiteit van Amsterdam Introduction 41
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;
@ Universiteit van Amsterdam Introduction 42
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;
@ Universiteit van Amsterdam Introduction 43
Example static knowledge role
KNOWLEDGE-ROLE causal-model; TYPE: STATIC; DOMAIN-MAPPING: state-dependency FROM car-network;
END KNOWLEDGE-ROLE causal-model;
@ Universiteit van Amsterdam Introduction 44
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
@ Universiteit van Amsterdam Introduction 45
Types of transfer functions
obtain receive
present provide
systeminitiative
externalinitiative
externalinformation
internalinformation
@ Universiteit van Amsterdam Introduction 46
Inference structure
� combined set of inferences specifies the basic inference capability of the target system
� graphical representation: inference structure� provides constraints for control flow
@ Universiteit van Amsterdam Introduction 47
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
@ Universiteit van Amsterdam Introduction 48
Annotated inference structure
complaint
cover
predict compare
obtain
expectedfinding
actualfinding
result
causal model
manifestation model
hypothesis
engine doesnot start
state dependencyrules
empty fuel tank gas dial = zero/low
gas dial = normal
not equalmanifestation
rules
@ Universiteit van Amsterdam Introduction 49
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:
@ Universiteit van Amsterdam Introduction 50
Task decomposition for car diagnosis
diagnosis
diagnosis through
generate-and-test
obtaincover
predict
task
task method
compare
decomposition
inferences
transfer function
@ Universiteit van Amsterdam Introduction 51
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”
@ Universiteit van Amsterdam Introduction 52
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;
@ Universiteit van Amsterdam Introduction 53
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
@ Universiteit van Amsterdam Introduction 54
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";
@ Universiteit van Amsterdam Introduction 55
Example method control
CONTROL-STRUCTURE:
REPEATcover(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 REPEATIF result == equal
THEN fault-category := hypothesis;ELSE "no solution found";
END IF
@ Universiteit van Amsterdam Introduction 56
UML activity diagram for method control
cover
predict
obtain compare
[no more solutionsof cover]
[new solutionof cover]
[result = equal]
[result = not equal]
solution found
no solution found
startdiagnosisthrough
generate-and-test
@ Universiteit van Amsterdam Introduction 57
Lessons
� Knowledge models partially reused in new applications
� Type of task = main guide for reuse� Catalog of task templates
� small set in this book� see also other repositories
@ Universiteit van Amsterdam Introduction 58
Task template
� reusable combination of model elements� (provisional) inference structure� typical control structure� typical domain schema from task point-of-view
� specific for a task type� supports top-down knowledge modeling
@ Universiteit van Amsterdam Introduction 59
Analytic versus synthetic tasks
� analytic tasks� system pre-exists
– it is typically not completely "known"
� input: some data about the system,� output: some characterization of the system
� synthetic tasks� system does not yet exist� input: requirements about system to be constructed� output: constructed system description
@ Universiteit van Amsterdam Introduction 60
Task hierarchyknowledge-intensive
task
analytictask
classification
synthetictask
assessment
diagnosis
configurationdesign
planning
scheduling
assignment
modelling
prediction
monitoring
design
@ Universiteit van Amsterdam Introduction 61
Classification
� establish correct class for an object� object should be available for inspection
� "natural" objects
� examples: rock classification, apple classification
� terminology: object, class, attribute, feature
� one of the simplest analytic tasks; many methods� other analytic tasks: sometimes reduced to
classification problem especially diagnosis
@ Universiteit van Amsterdam Introduction 62
Classification: pruning method
� generate all classes to which the object may belong� specify an object attribute� obtain the value of the attribute � remove all classes that are inconsistent with this
value
@ Universiteit van Amsterdam Introduction 63
Classification:inference structure
object
class
attribute
feature
truthvalue
generate
specify
match
obtain
@ Universiteit van Amsterdam Introduction 64
Classification: method control
while new-solution generate(object -> candidate) docandidate-classes := candidate union candidate-classes;
while new-solution specify(candidate-classes -> attribute)and length candidate-classes > 1 do
obtain(attribute -> new-feature);current-feature-set := new-feature union current-feature-set;for-each candidate in candidate-classes do
match(candidate + current-feature-set -> truth-value);if truth-value = false;then candidate-classes := candidate-classes subtract candidate;
@ Universiteit van Amsterdam Introduction 65
Classification: method variations
� Limited candidate generation� Different forms of attribute selection
� decision tree� information theory� user control
� Hierarchical search through class structure
@ Universiteit van Amsterdam Introduction 66
Classification: domain schema
object type
attribute
value: universal
object class
classconstraint
requires
has-attributeclass-of
2+ 1+
@ Universiteit van Amsterdam Introduction 67
Diagnosis
� find fault that causes system to malfunction� example: diagnosis of a copier
� terminology: � complaint/symptom, hypothesis, differential, finding(s)/evidence,
fault� nature of fault varies
� state, chain, component� should have some model of system behavior
� default method: simple causal model� sometimes reduced to classification task
� direct associations between symptoms and faults� automation feasible in technical domains
@ Universiteit van Amsterdam Introduction 68
Diagnosis: causal covering method
� Find candidate causes (hypotheses) for the complaint using a causal network
� Select a hypothesis� Specify an observable for this hypothesis and obtain
its value� Verify each hypothesis to see whether it is consistent
with the new finding� Continue this process until a single hypothesis is left
or no more observables are available
@ Universiteit van Amsterdam Introduction 69
Diagnosis:inference structure
complaint
cover
specify
select obtain
hypothesis
observable
finding
hypothesis
verify
result
@ Universiteit van Amsterdam Introduction 70
Diagnosis: method control
while new-solution cover(complaint -> hypothesis) dodifferential := hypothesis add differential;
end whilerepeat
select(differential -> hypothesis);specify(hypothesis -> observable);obtain(observable -> finding);evidence := finding add evidence;foreach hypothesis in differential do
verify(hypothesis + evidence -> result);if result = false then differential := differential subtract hypothesis
until length differential =< 1 or “no observables left”
faults := hypothesis;
@ Universiteit van Amsterdam Introduction 71
Diagnosis: method variations
� inclusion of abstractions� simulation methods� see literature on model-based diagnosis
� library of Benjamins
@ Universiteit van Amsterdam Introduction 72
Diagnosis: domain schema
systemfeature
systemobservable
value: universal
systemstate
status: universal
fault
prevalence: number[0..1]
systemstate
systemfeature can cause
causaldependency