Transcript Download presentation source

Knowledge Patterns
Peter Clark, John Thompson
(Boeing)
Bruce Porter
(University of Texas at Austin)
Motivation
• Our goal:
– Construction of large KBs
• Requires:
– finding ways to achieve knowledge reuse
• This presentation:
– Limitations of inheritance as method for reuse
– “Knowledge Patterns”: an additional method
Inheritance as a Method for Reuse
• Concepts organized into a generalization hierarchy
• When writing axioms about concept X, ask
– do they apply to a more general class of concepts?
– if so, encode them for that class
Production
Conversion
superclasses
Photosynthesis
• Ideally:
– few axioms explicitly about X
– X acquires most of its axioms from its generalizations
But limitations when:
• A general theory can be applied in more than one way
• Not all the general theory’s axioms are applicable
For Example:
Container
superclass
Computer
instance-of
MyPC
Axioms
• Capacity = occupied space + free space
c,o,f,x instance-of(c,Container) 
occupied-space(c,o) 
free-space(c,f) 
capacity(c,x)  x = o + f
• ...etc...
10110101
01101110
01110110
...
(contains memory)
capacity(MyPC,128).
For Example:
Axioms
• Capacity = occupied space + free space
• ...etc...
• Container wall impermeable to contents
Container
superclass
Computer
instance-of
MyPC
?
?
10110101
01101110
01110110
...
(contains memory)
capacity(MyPC,128).
(contains expansion cards)
capacity(MyPC,4).
?
What are the Problems?
• The general theory applies in more than one way
– but: inheritance fails to keep these ways distinct
• Some objects/relations in the general theory have no
specific counterpart
– but: inheritance cannot “mask out” those
objects/relations
A Pseudo-Solution
Could patch the general theory with parameters:
c,o,f,x,type instance-of(c,Container) 
occupied-space(c,type,o) 
free-space(c,type,f) 
capacity(c,type,x)
x=o+f
capacity(MyComputer, RAM, 128).
capacity(MyComputer,Expansion-Slot,4).
BUT: - we are losing the simplicity of the general theory
- there are more parameters!
- still can’t hide irrelevant parts of the general theory
Root of the Problem
• Really want to say
– “X can be modeled as a Y in this way”
– not “X isa Y”.
• Inability to say this  endless ontology debates...
BKB
CYC
Spatially
Extended
Entity
Thing
Functional
Object
?
Physical object
Individual
Product
Connector
MIKROKOSMOS
Place
?
?
Knowledge Patterns
• Make the general theory explicit, but separate from KB
• Import it through symbol renaming (morphism)
(an axiom from...)
The “Container” Pattern:
c,o,f,x
Theory in KB:
c,o,f,x
instance-of(c,Computer)
instance-of(c,Container) 
 occupied-ram(c,o) 
occupied-space(c,o) 
available-ram(c,f) 
free-space(c,f) 
ram-size(c,x)
capacity(c,x)
Morphism:
x=o+f
x=o+f
Container  Computer
capacity  ram-size
free-space  available-ram
occupied-space  occupied-ram
isa  isa
Knowledge Patterns
• Make the general theory explicit, but separate from KB
• Import it through symbol renaming (morphism):
(an axiom from...)
The “Container” Pattern:
c,o,f,x
Another Theory in KB:
c,o,f,x
instance-of(c,Computer)
instance-of(c,Container) 
occupied-space(c,o) 
 used-slots(c,o) 
free-space(c,f) 
free-slots(c,f) 
A Second
capacity(c,x)
expansion-slots(c,x)
Morphism:
x=o+f
x=o+f
Container  Computer
capacity  expansion-slots
free-space  free-slots
occupied-space  used-slots
isa  isa
Hiding Irrelevant Symbols in a Pattern
• For pattern symbols with no counterpart:
– User: doesn’t specify it in morphism
– System: maps it to a new, unique symbol
The “Container” Pattern:
Theory in KB:
c,o,f,x container-wall(...
c,o,f,x g23(...
Morphism:
Container -> Computer
capacity -> ram-size
container-wall -> g23
….
• The pattern’s “clockwork” is unchanged
• But that symbol does not interfere with rest of KB
Modeling a Space Experiment:
Using Patterns for Building a KB
Laser
source
Computer
One Model of PHaSE
Electrical Circuit
Battery
Laser
source
..(etc)
Switch
Light
Computer
Laser
source
Computer
• Carries electricity
• If closed path from
Battery to Appliance,
then Appliance is
powered
• …
The Underlying Pattern in that Model
The “DistributionNetwork”
Pattern
P
Electrical Circuit
Battery
P
..(etc)
Switch
I
C
I
C
• Carries transport-element
• If unblocked path from
Producer to Consumer,
then Consumer is
supplied.
• connects is transitive
• ….
Light
Laser
source
Computer
• Carries electricity
• If open path from
Battery to Appliance,
then Appliance is
powered
• …
The Model Defined Using the Pattern
The “DistributionNetwork”
Pattern
P
Electrical Circuit
Battery
P
..(etc)
Switch
I
C
Light
Laser
source
I
C
Computer
Morphism:
Transport-Element  Electricity
Producer  Battery
Intermediary  Switch
Consumer  Appliance
Blocked  Open
Unblocked  Closed
Supplied  Powered
The Pattern itself can be Abstracted
The “DistributionNetwork”
Pattern
Blockable-DAG
N1
N2
P
N3
N4
P
I
N5
Include in:
N6
• Nodes can connect with
other nodes.
• X reaches Y if X connects
with Y.
• X reaches Z if X connects
with Y and Y reaches Z
C
I
C
• Carries transport-element
• If unblocked path from
Producer to Consumer,
then Consumer is
supplied.
• connects is transitive
• ….
Another Model of PHaSE
Information Flow
Laser
Laser
source
Sample
Camera
Computer
Amplifier
Disk
• Signal transports
information through
network
• …
The Model Defined using a Pattern
The “Processing Network”
Pattern
Information Flow
Laser
P
Sample
I
Camera
C
Amplifier
I
C
• Carries transportelement
• Intermediaries
transform the
transport element
• ...
Morphism:
Disk
Producer  Laser
Consumer  Disk
Blocked  Open
Unblocked  Closed
Transport-Element  Signal
PHaSE KB Architecture
DAG
Blockable
DAG
Discrete Event
Model
Processing
Network
Distribution
Network
Two-state
Object
Information
Flow
Electrical
Circuits
Machines
PHaSE KB
Ground facts (circuit diagram,
optics diagram, physical assy, ...)
Spatial
Relations
Discussion
• What are the strengths and limitations of patterns?
• When should we use patterns vs. inheritance?
• Do patterns really provide benefit through reuse?
• How general should the patterns be?
Related Work
• Software Specification / Category Theory
• Problem-Solving Methods
• Component-based KBs
• Object-Oriented Design Patterns
• Analogy
• Microtheories / Contexts
Summary
• Inheritance has limits when:
– A general theory can be applied in multiple ways
– Some of its objects/relations are not applicable
• Knowledge Patterns:
– Make recurring axiom schemata explicit
– Use them via symbol renaming (morphing)
• They allow us to
– Separate the “clockwork” of a theory from the
phenomenon it models
– Better modularize a KB