Knowledge Model Basics Challenges in knowledge modeling Basic - - PowerPoint PPT Presentation

knowledge model basics
SMART_READER_LITE
LIVE PREVIEW

Knowledge Model Basics Challenges in knowledge modeling Basic - - PowerPoint PPT Presentation

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


slide-1
SLIDE 1

Knowledge Model Basics

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

slide-2
SLIDE 2

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

slide-3
SLIDE 3

Knowledge-modelling basics 3

Relation to other models

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

slide-4
SLIDE 4

Knowledge-modelling basics 4

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

slide-5
SLIDE 5

Knowledge-modelling basics 5

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

slide-6
SLIDE 6

Knowledge-modelling basics 6

Example domain: car diagnosis

fuel tank

empty

battery

low

battery dial

zero

gas dial

zero

power

  • ff

engine behavior

does not start

engine behavior

stops

gas in engine

false

fuse

blown

fuse inspection

broken

1 2 3 4 5 6 7 8 9

slide-7
SLIDE 7

Knowledge-modelling basics 7

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

slide-8
SLIDE 8

Knowledge-modelling basics 8

Constructs for domain schema

Concept

  • cf. object class (without operations)

Relation

  • cf. association

Attribute

primitive value

Rule type

introduces expressions => no SE equivalent

slide-9
SLIDE 9

Knowledge-modelling basics 9

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

slide-10
SLIDE 10

Knowledge-modelling basics 10

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}

slide-11
SLIDE 11

Knowledge-modelling basics 11

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

slide-12
SLIDE 12

Knowledge-modelling basics 12

Example: car subtypes

car state status: universal

  • bservable: boolean

invisible car state

  • bservable: {false}

visible car state

  • bservable: {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,

  • ff}

engine behavior status: {normal, does-not-start, stops} fuse inspection value: {normal, broken} gas dial value: dial value battery dial value: dial-value

slide-13
SLIDE 13

Knowledge-modelling basics 13

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;

slide-14
SLIDE 14

Knowledge-modelling basics 14

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

slide-15
SLIDE 15

Knowledge-modelling basics 15

Example: car relation

car person car person

  • wnership
  • wnership

purchase date: date;

a) b) car person

  • wned-by

c) 0+ 0-1

slide-16
SLIDE 16

Knowledge-modelling basics 16

N-ary relation

agent name position

  • bservation

value date time

  • bservable

type location department hospital patient name diagnosis

slide-17
SLIDE 17

Knowledge-modelling basics 17

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

slide-18
SLIDE 18

Knowledge-modelling basics 18

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

slide-19
SLIDE 19

Knowledge-modelling basics 19

Example rule type

loan constraint 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: string income: integer loan amount: integer interest-rate: number 1+

slide-20
SLIDE 20

Knowledge-modelling basics 20

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

slide-21
SLIDE 21

Knowledge-modelling basics 21

Rule types for car diagnosis

invisible car state car state car

  • bservable

invisible car state manifestation rule state dependency causes has manifestation 1 1 1 1

slide-22
SLIDE 22

Knowledge-modelling basics 22

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)

slide-23
SLIDE 23

Knowledge-modelling basics 23

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;

slide-24
SLIDE 24

Knowledge-modelling basics 24

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

slide-25
SLIDE 25

Knowledge-modelling basics 25

Example inference: cover

complaint hypothesis cover 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

slide-26
SLIDE 26

Knowledge-modelling basics 26

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”

slide-27
SLIDE 27

Knowledge-modelling basics 27

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 base
slide-28
SLIDE 28

Knowledge-modelling basics 28

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;

slide-29
SLIDE 29

Knowledge-modelling basics 29

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;

slide-30
SLIDE 30

Knowledge-modelling basics 30

Example static knowledge role

KNOWLEDGE-ROLE causal-model; TYPE: STATIC; DOMAIN-MAPPING: state-dependency FROM car-network; END KNOWLEDGE-ROLE causal-model;

slide-31
SLIDE 31

Knowledge-modelling basics 31

Transfer functions

transfers an information item between the reasoning

agent and another agent

from the knowledge-model point of view black box:

  • nly its name and I/O

detailed specification of transfer functions is part of

communication model

standard names

slide-32
SLIDE 32

Knowledge-modelling basics 32

Types of transfer functions

  • btain

receive present provide system initiative external initiative external information internal information

slide-33
SLIDE 33

Knowledge-modelling basics 33

Inference structure

combined set of inferences specifies the basic

inference capability of the target system

graphical representation: inference structure provides constraints for control flow

slide-34
SLIDE 34

Knowledge-modelling basics 34

Example: car inferences

complaint cover predict compare

  • btain

expected finding actual finding result causal model manifestation model hypothesis

slide-35
SLIDE 35

Knowledge-modelling basics 35

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

slide-36
SLIDE 36

Knowledge-modelling basics 36

Annotated inference structure

complaint cover predict compare

  • btain

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

slide-37
SLIDE 37

Knowledge-modelling basics 37

Task knowledge

describes goals

assess a mortgage application in order to minimize the risk

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

slide-38
SLIDE 38

Knowledge-modelling basics 38

Task decomposition for car diagnosis

diagnosis diagnosis through generate-and-test

  • btain

cover

predict task task method compare decomposition inferences transfer function

slide-39
SLIDE 39

Knowledge-modelling basics 39

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;

slide-40
SLIDE 40

Knowledge-modelling basics 40

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

slide-41
SLIDE 41

Knowledge-modelling basics 41

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

slide-42
SLIDE 42

Knowledge-modelling basics 42

Example method control

CONTROL-STRUCTURE: REPEAT cover(complaint -> hypothesis); predict(hypothesis -> expected-finding);

  • btain(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

slide-43
SLIDE 43

Knowledge-modelling basics 43

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

slide-44
SLIDE 44

Knowledge-modelling basics 44

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