Knowledge Model Basics

1
Knowledge Model Basics

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

2
Knowledge model

• specialized tool for specification of
  knowledge-intensive tasks
• abstracts from communication aspects
• real-world oriented
• reuse is central theme

3
Relation to other models
requirements
task selected in feasibility study
communication
specification
and further detailed in
model
for interaction functions
Task and Agent Models
organization model
knowledge-
task model
design
intensive
agent model
model
task
requirements
specification
knowledge
for reasoning functions
model
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

5
Challenges in specifying knowledge
6
Structuring a knowledge base
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

8
Knowledge model overview
9
Example domain car diagnosis
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

11
Constructs for domain schema

• Concept
• cf. object class (without operations)
• Relation
• cf. association
• Attribute
• primitive value
• Rule type
• introduces expressions gt no SE equivalent

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

13
Example car concepts
14
Example apple concept
15
Example car subtypes
16
Example house sub-types
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

18
Example car relation
19
N-ary relation
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

21
Rule type

• models a relation between expressions about
  feature values (e.g. attribute values)
• gas-dial.value zero -gt fuel-tank.status empty
• models set of real-world rules with a similar
  structure
• dependency is usually not strictly logical (
  implication)
• specify connection symbol

22
Example rule type
23
Rule type structure

• ltantecedentgt ltconnection-symbolgt ltconsequentgt
• 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

24
Rule types for car diagnosis
25
Knowledge base

• conceptual knowledge-base partition
• contains instances of knowledge types
• rule-type instances rules
• structure
• USES lttypes usedgt from ltschemagt
• EXPRESSIONS ltinstancesgt
• instance representation
• intuitive natural language
• connection symbol
• formal expression language (appendix of book)

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

27
Inference knowledge

• describes the lowest level of functional
  decomposition
• basic information-processing units
• inference gt reasoning
• transfer function gt communication with other
  agents
• why special status?
• indirectly related to domain knowledge
• enables reuse of inference

28
Example inference cover
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

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

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

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

33
Example static knowledge role

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

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

35
Types of transfer functions
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

37
Example car inferences
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

39
Annotated inference structure
40
Reusing inferences

• Standard set of inferences?!
• difficult subject
• See catalog in Ch. 13
• Use as much as possible standard names

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

42
Task decomposition for car diagnosis
diagnosis
task
diagnosis
through
task method
generate-and-test
decomposition
obtain
cover
predict
compare
transfer function
inferences
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

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

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

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"

47
Example method control

• CONTROL-STRUCTURE
• REPEAT
• cover(complaint -gt hypothesis)
  predict(hypothesis -gt expected-finding)
  obtain(expected-finding -gt actual-finding)
  evidence evidence ADD actual-finding
  compare(expected-finding actual-finding -gt
  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

48
UML activity diagram for method control
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

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

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)

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

53
The data-function debate