Knowledge Model Basics Challenges in knowledge modeling Basic knowledge-modeling constructs Comparison to general software analysis

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


Relation to other models

organization modeltask model

agent model

knowledge-intensive

task

communicationmodel

knowledgemodel

designmodel

requirementsspecification

for interaction functions

requirementsspecification

for reasoning functions

task selected in feasibility studyand 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

amountinterest

J ohn has a loan of $1,750Harry has a loan of $2,500

A person with a loan should be at least 18 years oldA person with an income up to $10,000 can get a maximum loan of $2,000A 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 8: IF ... THEN ...Rule 9: IF ... THEN ...Rule 10: IF ... THEN ...Rule 11: IF ... THEN ...

<plus many others>

single flat knowledge base

multiple rule setscontaining 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 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: apple concept

apple

color: {yellow, yellow-green, green}rusty-surface: booleangreasy-surface: booleanform: {flat, high}

Granny Smith:apple class

Golden Delicious:apple class

Grey Reinet:apple class

Present of England:apple class

apple classhas class


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


Example: house sub-types

apartment

entrance-floor: naturallift-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

purchase date: date;

a)

b) car personowned-by

c)

0+ 0-1


N-ary relation

agent

nameposition

observation

valuedatetime

observable

type

location

departmenthospital

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

loanconstraint

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+


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


Example: car inferences

complaint

cover

predict compare

obtain

expectedfinding

actualfinding

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

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


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

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:

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

obtain compare

[no more solutionsof cover]

[new solutionof cover]

[result = equal]

[result = not equal]

solution found

no solution found

startdiagnosisthrough

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

DATAviewpoint

FUNCTIONviewpoint

Object-Oriented Analysis(OMT, Booch, ....)

Structured Analysis(Yourdon)

CommonKADS:function-data decoupling

functional decomposition is starting pointdata types are derived from DFDs

static information structure is starting pointfunctions are grouped with the data

reuse of data/function groups ("objects")

parallel function/data descriptionreusable functional decompositions

reusable data/knowledge types

Documents

Knowledge Model Basics Challenges in knowledge modeling Basic knowledge-modeling constructs Comparison to general software analysis