Introduction to Knowledge Engineering and Knowledge...

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


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


Problems in knowledge engineering

� complex information and knowledge is difficult to observe

� experts and other sources differ� multiple representations:

� textbooks� graphical representations� heuristics� skills


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


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 =>


First generation “Expert” Systems

� shallow knowledge base� single reasoning principle� uniform representation� limited explanation

capabilities

reasoningcontrol

knowledgebase

operateson


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


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


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


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.


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.


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.


CommonKADS Model Set

OrganizationModel

TaskModel

AgentModel

KnowledgeModel

CommunicationModel

DesignModel

Context

Concept

Artefact


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).


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.


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


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


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


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 knowledgetask goalstask decompositiontask control

Inference knowledgebasic inferencesroles

Domain knowledgedomain typesdomain rulesdomain facts


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


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: 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


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

ownershippurchase date: date;

a)

b) car personowned-by

c)

0+ 0-1


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


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

invisiblecar state car state

car observable

invisiblecar state

manifestationrule

statedependency

causes

hasmanifestation

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

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


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

systeminitiative

externalinitiative

externalinformation

internalinformation


Inference structure

� combined set of inferences specifies the basic inference capability of the target system

� graphical representation: inference structure� provides constraints for control flow


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

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


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

obtaincover

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:

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


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


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


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


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


Task hierarchyknowledge-intensive

task

analytictask

classification

synthetictask

assessment

diagnosis

configurationdesign

planning

scheduling

assignment

modelling

prediction

monitoring

design


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


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


Classification:inference structure

object

class

attribute

feature

truthvalue

generate

specify

match

obtain


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;


Classification: method variations

� Limited candidate generation� Different forms of attribute selection

� decision tree� information theory� user control

� Hierarchical search through class structure


Classification: domain schema

object type

attribute

value: universal

object class

classconstraint

requires

has-attributeclass-of

2+ 1+


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


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


Diagnosis:inference structure

complaint

cover

specify

select obtain

hypothesis

observable

finding

hypothesis

verify

result


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;


Diagnosis: method variations

� inclusion of abstractions� simulation methods� see literature on model-based diagnosis

� library of Benjamins


Diagnosis: domain schema

systemfeature

systemobservable

value: universal

systemstate

status: universal

fault

prevalence: number[0..1]

systemstate

systemfeature can cause

causaldependency

Date post:	01-Aug-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Introduction to Knowledge Engineering and Knowledge...

Documents