Knowledge Modelling: Foundations, Techniques and Applications

1
Knowledge ModellingFoundations, Techniques and
Applications

• Enrico MottaKnowledge Media InstituteThe Open
  UniversityUnited Kingdom

2
Goals of the Tutorial (1)

• To characterize the knowledge modelling research
  paradigm
• Origins
• Main Tenets
• To explain its relevance to several application
  areas
• Knowledge management
• Knowledge acquisition
• Knowledge-based system development

3
Goals of the Tutorial (2)

• To present key methodologies, technologies, tools
  and modelling languages related to this paradigm
• Ontologies
• Problem Solving Methods
• To illustrate practical applications of the
  paradigm to concrete application domains
• Engineering Design
• KBS Application Development
• Electronic News Publishing
• Knowledge Management

4
Structure of the Talk

• The Knowledge Modelling Paradigm
• Knowledge-level Architectures for Sharing and
  Reuse
• Libraries of Reusable Knowledge Components
• Ontologies Reusable Conceptualizations
• Sample Area Design
• Design Problem Solving
• Library of design components
• Task Models
• Problem Solving Methods
• Applications
• Knowledge Modelling for Knowledge Management
• Conclusions

5
The Knowledge Modelling Paradigm

• Its origins in the knowledge-based system
  research area

6
What is knowledge modelling?
Newell, AI Journal, 18, 1982

• Knowledge Modelling Knowledge-level Modelling

A description of an agent which focuses on its
competence and abstracts from implementation
details
Classical Example Mycin, a diagnostic medical
system Knowledge-level behaviour Heuristic
Classification Symbol-level behaviour
Rule-based backward-chaining
7
First Generation KBS Architecture
Inference Engine
User Interface
Rule-based Backward-chaining
Domain Knowledge Base
Set of Domain rules
8
Problems

• Focus on implementation-level aspects (backward
  chaining) rather than knowledge-level
  functionalities (medical diagnosis)
• Poor explanation capabilities
• Difficult to assess competence
• Low-level reuse support
• Rules tend to be application specific

9
Heuristic Classification Model
Clancey, AI Journal, 27, 1985
Data Abstractions
Solutions Abstractions
Heuristic Match
Abstraction
Refinement
Solutions
Data
10
Medical Diagnosis
Gram-negative Infection
Data Abstractions
Solutions Abstractions
Heuristic Match
Immunosuppressed
Refinement
Abstraction
Solutions
Data
E-coli Infection
Low white blood count
11
Book Selection
Intelligent Book
Data Abstractions
Solutions Abstractions
Heuristic Match
Educated Person Stereotype
Refinement
Abstraction
Solutions
Data
Watches no TV
Anna Karenina
12
So What? (Competence vs Performance)

• Knowledge-level analysis shows what system
  actually does, not how it does it
• The interesting aspect about Mycin is its
  classification behaviour, not its depth-first
  control regime
• Separation of competence from performance (or
  specification from implementation)
• Important for both analysis and design of
  knowledge-intensive systems

13
So What? (Levels of system analysis)

• There exist different levels at which a system
  can be described
• knowledge-level (tasks and problem solving
  methods)
• Symbol-level (backward-chaining)
• Sub-symbol level (registers)
• Shift in the level of analysis
• Wrong question Can a problem be solved by means
  of a rule-based system?
• Right questions What type of knowledge-intensive
  task are we tackling? What are the appropriate
  problem solving methods?

14
So What? (Reuse)

• Knowledge-level analysis uncovers generic
  reasoning patterns in problem solving agents
• E.g., heuristic classification
• Shift from rule-based reuse to knowledge-level
  reuse
• Focus on high-level reusable task models and
  reasoning patterns
• Classes of tasks
• Design, diagnosis, classification, etc.
• Problem solving methods
• Design methods, classification methods, etc.

15
So What? (Research Development)

• Model-based knowledge acquisition
• From acquiring rules to instantiating task models
• Robust KBS development by reuse
• KBS as a structured development process
• Robustness and economy
• Importance of libraries
• KBS development not necessarily an art!
• Towards a practical theory of knowledge-based
  systems
• What are the classes of tasks/problem solving
  methods?
• How do we identify/model them?
• When are methods appropriate?

16
Knowledge-level Architecturesfor Sharing and
Reuse

• Application of the modelling paradigm to the
  specification and use of libraries of reusable
  components for knowledge systems

17
Modelling Frameworks (1)

• A modelling framework identifies the generic
  types of knowledge which occur in knowledge
  systems, thus providing a generic epistemological
  organization for knowledge systems
• Several exist
• KADS/Common KADS - Un.of Amsterdam
• Components of Expertise - Steels
• Generic Tasks - Chandrasekaran
• Role-limiting Methods - McDermott
• Protégé - Musen, Stanford
• TMDA - Motta
• Ibrow - Fensel, Motta et al.

18
Modelling Frameworks (2)

• Much in common
• Emphasis on reusable models
• Typology of generic tasks
• Constructivist paradigm
• Some differences
• Different degrees of coupling between
  domain-specific and domain-independent knowledge
• Different degrees of flexibility
• Different typologies of knowledge categories

19
A Constructive Approach...

• Lets define our own framework...

20
Generic Tasks

• Informal definition
• A generic class of applications - e.g., planning,
  design, diagnosis, scheduling, etc..
• More precise definition
• A knowledge-level, application-independent
  description of the goal to be attained by a
  problem solver.
• Several typologies exist
• e.g., Breuker, 1994
• Viewpoints over applications
• No natural categories
• Different viewpoints can be imposed on a
  particular application

21
Example Parametric Design

• Generic Task Parametric Design
• Inputs Parameters, Constraints, Requirements,
  Cost-Function, Preferences
• Output Design-Model
• Goal To produce a complete and consistent
  design model, which satisfies the given
  requirements
• Preconditions At least one requirement and
  one parameter are provided

22
Example Classification

• Generic Task Classification Inputs Candidate-cla
  sses Observables
• Output Best-Matching-Classes
• Preconditions At least one candidate class
  exists
• Goal To find the class that best explains
  the observables

23
Generic Component 2 Reusable PSMs

• A domain-independent, knowledge-level
  specification of problem solving behaviour, which
  can be used to solve a class of tasks.
• PSM specifications may be partial
• PSM can be task-specific
• E.g., heuristic classification
• PSM can be task-independent
• E.g., search methods, such as hill-climbing, A,
  etc.....

24
Functional Specification of a PSM

• Problem solving method search
• ontology
• import
• state-space-terminology
• competence
• roles
• input input State
• output output State
• preconditions
• input ? 0
• postconditions
• solution_state (output)
• assumptions
• ?s . solution_state (?s) successor
  (input, ?s)

25
Operational Description

• Begin
• states one x. initialize (input input)
• repeat
• state one x . select _state (states states)
• if solution_state (state)
• then return state
• else
• succ_states one x. derive_successor_states
  (state state)
• states one x. update_state_space (input1
  states input2 succ_states)
• end if
• end repeat
• end

26
Task-Method Structures
Problem Type
Primitive PSM
27
Multi-Functional Domain Models

• Domain-specific models, which are not committed
  to a specific PSM or task.
• Examples
• A database of cars
• The CYC knowledge base, etc..

28
Picture so far..
Application Model
Problem Solving Method
Generic Task
Simple Classifier
Classification
Multi-Functional Domain
Lunar rocks
29
Issue

• How to link different reusable components?

Application Model
Classification
Simple Classifier
Problem Solving Method
Generic Task
Multi-Functional Domain
Lunar rocks
30
Solution Mappings

• Mappings model explicitly the relationship
  between different components in an application
  model

Application Model
Classification
Simple Classifier
Task-PSMMapping
Problem Solving Method
Generic Task
PSM-DomainMapping
Task-DomainMapping
Multi-Functional Domain
Lunar rocks
31
Example

• Scenario Office Allocation Application
• Generic Task Parametric Design
• Domain KB about employees and offices

Task Level
Parameter
Design Model
Domain Level
Pairs ltEmployee, Roomgt
Employee
32
Application-specific knowledge

• Mappings are an example of application-specific
  knowledge. Are there others?

Yes Application-specific heuristic problem
solving knowledge
33
Elevator Design Example

• A configuration designer only considers two
  positions for the counterweight
• Half way between platform and U-bracket
• A position such that the distance between the
  counterweight and the platform is at least 0.75
  inches

34
Complete Picture
Application Model
Generic Task
Problem Solving Method
Mapping Knowledge
Application-specific Problem-Solving Knowledge
Application Configuration
Multi-Functional Domain
35
Formal Libraries of Reusable Components with a
Clear Theoretical Basis
36
Generic Typologies are not enough...

• Need for clear theoretical basis
• What are the principles underlying the
  construction of a library?
• How do components get selected?
• Need to go beyond mere component gathering.
• Need for formal specifications of competences
• Beyond informal descriptions of tasks, methods
  and domains
• What service do components provide?
• How do components relate to each other?
• e.g., tasks to other tasks and methods to tasks

37
Approach

• Use formal ontologies to support reusable
  component specifications
• Ground problem solving components on a theory of
  knowledge-based systems

38
Ontologies Reusable Conceptualizations

• Definition, examples, design principles

39
Reusable Specifications as Ontologies

• An ontology is a partial specification of a
  conceptual vocabulary to be used for formulating
  knowledge-level theories about a domain of
  discourse. The fundamental role of an ontology
  is to support knowledge sharing and reuse.

Example Ontology Simple-TimeDefines classes,
relations and axioms to support the modelling
of time-dependent activities
40
Class Specification

• (Define-Class Time-Point (?t)
• "A time-point is a point in real, historical
  time (on earth). Is independent of observer and
  context. The time-points at which events occur
  can be known with various degrees of precision
  and approximation, but conceptually time-points
  are point-like and not interval-like. That is, it
  doesn't make sense to talk about what happens
  during a time-point, or how long the time-point
  lasts."
• def (individual ?t)
• axiom-def
• (and (domain-of time-point Day-of)
• (domain-of time-point Minutes-of)
• (domain-of time-point Month-of)
• (domain-of time-point Seconds-of)
• (domain-of time-point Year-of)))

41
Classes and Relations in Simple Time

• Classes
• Day-Name
• Day-Number
• Duration
• Hour-Number
• Minute-Number
• Month-Name
• Month-Number
• Second-Number
• Time-Point
• Calendar-Date
• Calendar-Year
• Universal-Time-Spec
• Time-Range
• Year-Number

• Relations
• lt
• gt
• After
• After
• Before
• Before
• Disjoint-Time-Ranges
• During
• During
• Equals
• Finishes
• Finishes
• Meets
• Overlaps
• Overlaps
• Start
• Starts

42
Sample Relation Specification

• (define-relation DURING (?time-range-1
  ?time-range-2)
• "a time range, ?time-range-1, is properly
  included in a time range, ?time-range-2."
• iff-def (and (gt (START-TIME-OF ?time-range-1)
• (START-TIME-OF ?time-range-2))
• (lt (end-time-of ?time-range-1)
• (end-time-of ?time-range-2))))

43
Ontology for medical guidelines

• What is a medical guideline?
• A specification (often partial) of a protocol of
  care
• Aims to define best practice
• Examples
• Protocols for treating AIDS patients
• Protocols for the prevention of bed sores
• The Ontology
• Defines classes, relations and axioms to support
  the specification of medical guidelines
• Builds on a generic medical ontology
• Supports both guideline design and execution.

44
Class Hierarchy for Medical Guidelines
Ontology Simple-time
Temporal-thing
Planning Ontology
Plan
Medical-Guidelines Ontology
Medical-Guideline
Therapeutic-Guideline
Preventive-Guideline
Diagnostic-Guideline
45
Class Medical-Guideline

• (def-class medical-guideline (plan) "Each
  guideline is associated with a medical
  condition. It also targets a particular
  population" ((outcome-measure type string)
  (target-population type population-specification)
  (full-name type string)
  (associated-medical-condition type
  medical-condition) (temporal-constraints type
  string) (location-constraints type
  guideline-application-location)
  (associated-documents type document-reference)
  (has-guideline-user-type type
  guideline-user-type)))

46
Advantages of Ontologies

• Make it possible to formalise a shared viewpoint
  over a certain universe of discourse
• E.g., agreement on how to model time
• Can support communication and cooperation between
  systems developed at different sites
• The ontological commitments made by a system are
  made explicit
• E.g., diagnostic and therapy-control medical
  systems may share the same underlying generic
  medical ontology
• e.,g., notion of pathological state, therapeutic
  procedure

47
Advantages of Ontologies (2) Reuse
base-ontology
simple-time
common-concepts
generic-events
bibliographic-data
generic-technologies
organization-ontology
medical-ontology
medical-guidelines
48
Advantages of Ontologies (3)

• Model-based knowledge acquisition
• E.g., use the medical guideline ontology to
  acquire knowledge about particular medical
  guidelines in a structured way
• Knowledge-level validation and verification
• E.g., use the medical guideline ontology to check
  guideline documents

49
Sample Knowledge Acquisition Form
50
Languages for Ontology Specification

• Ontolingua (Gruber, 1993)
• Formal basis on set theory
• Almost a standard
• Big library available on-line
• Translators to some executable languages
• LOOM, CLIPS, etc.
• Not operational
• Batch model does not really work

51
Languages for Ontology Specification (2)

• UPML (Fensel et al., IJCAI 99)
• Formal language, based on algebraic
  specifications
• Community Effort
• European and American universities involved in
  language specification
• State of the art modelling framework
• Supports for task, PSM and mapping specification
• No support for operationality
• Still being defined
• No library available

52
Languages for Ontology Specification (3)

• OCML (Motta, 1995 1999)
• Operational Conceptual Modelling Language
• Supports modelling and prototyping
• Both operational and non-operational constructs
• Library available on line
• Advanced Web-based development tools(Web-Onto)
• Supports much of the Ontolingua specification
• State of the art modelling framework
• Support for task, PSM and mapping specification
• Lack of translators to other languages

53
Criteria for Ontology Design
(Gruber, 1995)

• Clarity
• User-centred definitions
• Documentation
• Alternative choices
• Coherence
• Logical consistency
• Coherent Style (e.g., naming conventions)
• Minimal ontological commitments
• Do not impede extensibility by making unnecessary
  knowledge-level commitments
• Minimal encoding bias
• Do not pre-judge reuse by making symbol-level
  commitments

54
Example of definition with bias
Physical Quantity ltUnit, Magnitudegt Example
ltsecond, 5gt

• (defrelation PHYSICAL-QUANTITY (ltgt
  (PHYSICAL-QUANTITY ?q) (and (defined
  (quantity.magnitude ?q))
  (double-float (quantity.magnitude ?q))
  (defined (quantity.unit ?q)) (member
  (quantity.unit ?q) (setof
  meter second kilogram
  ampere kelvin mole candela)))

55
Example of definition with bias
Physical Quantity ltUnit, Magnitudegt Example
ltsecond, 5gt

• (defrelation PHYSICAL-QUANTITY (ltgt
  (PHYSICAL-QUANTITY ?q) (and (defined
  (quantity.magnitude ?q))
  (double-float (quantity.magnitude ?q))
  (defined (quantity.unit ?q)) (member
  (quantity.unit ?q) (setof
  meter second kilogram
  ampere kelvin mole candela)))

Encoding Bias
Unnecessary Ontological Commitment
56
Back to the modelling framework.....
57
Complete Picture
Application Model
Generic Task
Problem Solving Method
Task Ontology
Method Ontology
Mapping Knowledge
Application-specific Problem-Solving Knowledge
Ontology
Mapping Ontology
Application Configuration
Multi-Functional Domain
Domain Ontology
58
Recap

• What have we got?
• Architecture for reuse
• TMDA modelling framework
• Technology for reusable specifications
• Heterogeneous ontologies
• What next?
• Foundations of PSMs
• Example of library development
• Area design problem solving

59
Design Problem Solving

• A quick overview

60
Design Problem Solving

• Design Problem Solving Constructive problem
  solving
• Solutions are not selected by constructed from
  pre-existing templates
• Normally more difficult than analytical problem
  solving
• Important application area for AI
• Knowledge-intensive
• Complex combinatorics
• Industrial relevance
• Different types
• Creative Design, Configuration Design,
  Parametric Design

61
Generic Characterization
Requirements
Constraints
Design
Building Blocks
Desires
62
Design Problem Solving

• Not all building blocks are given
• No solution template

?
63
Configuration Design Problem Solving

• Building blocks are given
• No solution template

?
64
Parametric Design Problem Solving

• Building blocks are given
• Parametrized solution template exists

65
A library of reusable components for (mainly
parametric) design problem solving
66
Generic Design Tasks
67
Structure of Generic Task Models
Generic Design Terminology
Design Preferences
Design Solution
Optimal Design
Design
Ontology
Parametric Design Terminology
Generic Task
Legend
Parametric Design
Optimal Parametric Design
68
Generic Design Terminology

• Minimalist ontology for design tasks.
• Defines a terminology, not a class of tasks.
• A design model is defined as a set of design
  elements.
• The relations between these are not modelled in
  this ontology. but are a matter either for
  specialised design ontologies, or for domain
  models.
• Generalises from requirements and constraints
  (design statements)
• Supports the modelling of relative preferences
  between design models.

69
Ontology Signature (in UPML)

• ontology generic-design-terminology
• signature
• elementary sorts
• Design_Element, Design_Statement
• constructed sorts
• Design_Model set_of Design_Element
• Constraint subset_of Design_Statement
• Requirement subset_of Design_Statement
• Constraints set_of Constraint
• Requirements set_of Requirement
• Design_Statements set_of Design_Statement
• functions
• violated_statements Design_Model ?
  Design_Statements
• satisfied_statements Design_Model ?
  Design_Statements
• predicates
• applicable Design_Statement x Design_Model
• holds Design_Statement x Design_Model
• preferred_design Design_Model x Design_Model

70
Ontology Axioms

• / Only applicable statements can be violated or
  satisfied /
• (?s ? violated_statements (?d) ? ?s ?
  satisfied_statements (?d)) ? applicable (?s, ?d)
• / A statement is satisfied or violated in a
  design model iff it holds or does not hold for
  the design model/
• ?s ? violated_statements (?d) ?
• applicable (?s, ?d) ? ? holds (?s, ?d)
• ?s ? satisfied_statements (?d) ? holds (?s, ?d)
• / The relation preferred_design introduces a
  partial order on design models. /
• ? preferred_design (?d, ?d)
• preferred_design (?d1, ?d2) ? preferred_design
  (?d2, ?d3)
• ? preferred_design (?d1, ?d3)

71
Ontology Design-Solution

• ontology design-solution
• pragmatics
• Defines the predicates and axioms needed to
  describe solutions to design tasks
• end pragmatics
• import
• generic-design-terminology
• signature
• predicates
• admissible_solution Design_Model x
  Constraints x Requirements
• consistent Design_Model x Constraints
• suitable Design_Model x Requirements
• variables
• ?d Design_Model
• ?r, ?r1, ?r2 Requirement
• ?c Constraint
• ?rs Requirements
• ?cs Constraints

72
Axioms in Design-Solution

• / A design model is an admissible solution iff
  it is consistent with respect to the problem's
  constraints and it is suitable with respect to
  the problem's requirements. /
• admissible_solution (?d, ?cs, ?rs) ?
• consistent (?d, ?cs) ? suitable (?d, ?rs)
• / A design model is consistent with respect to a
  set of constraints iff none of them is violated.
  /
• consistent (?d, ?cs) ? ? ?c (?c ? ?cs ? ?c ?
  violated_statements (?d))
• / A design model is suitable with respect to a
  set of requirements iff all the requirements are
  satisfied. /
• suitable (?d, ?rs) ? " ?r (?r ? ?rs ? ?r ?
  satisfied_statements (?d))

73
Task Design

• task design
• pragmatics
• A simple class of design tasks, with no
  preference- related knowledge.
• end pragmatics
• ontology import design-solution
• specification
• roles
• input
• reqs Requirements constrs Constraints
• output
• design Design_Model
• goal
• admissible_solution (design, constrs, reqs)
• preconditions
• ?r (?r ? reqs)

74
Task Optimal-Design - I/O Spec.

• task optimal-design
• pragmatics
• Augments the definition of task design by
  requiring that the solution has to be
  consistent with the global preference order
  specified by preference knowledge.
• end pragmatics
• ontology
• import
• design-preferences, design-solution
• specification
• roles
• input
• reqs Requirements constrs Constraints
• prefs Preferences
• output
• design Design_Model
• end roles

75
Preconditions, Goal and Assumptions

• goal
• optimal_solution (design, constrs, reqs, prefs)
• preconditions
• / Like in the case of the simple design problem,
  the only precondition is that there should be at
  least one requirement /
• ?r (?r ? reqs)
• assumptions
• / An important assumption is that the
  preferences must be mutually consistent, to
  guarantee the correctness of the task
  specification/
• " ?pr1, ?pr2 (?pr1 ? prefs ? ?pr2 ? prefs) ? ?
  ?d1, ?d2 (preference_applies(?pr1 ?d1, ?d2) ?
  preference_applies(?pr2, ?d2, ?d1)))

76
Definition of optimal solution

• / An optimal solution is one which is not
  bettered by another solution. /
• optimal_solution (?d, ?cs, ?rs, ?prs) ?
  (admissible_solution (?d, ?cs, ?rs) ? ? ?d1
  . (admissible_solution (?d1, ?cs, ?rs) ?
  ?pr . (?pr ? ?prs ? preference_applies(
  ?pr, ?d1, ?d))))

77
Task Parametric Design - I/O Spec.

• task parametric-design
• Ontology
• import parametric-design-terminology
• specification
• roles
• input
• reqs Requirements
• constrs Constraints
• params Parameters
• value_ranges Value_Ranges
• output
• design Parametric_Design_Model
• end roles

78
Preconditions and Goals

• preconditions
• / In contrast with the case of design, there is
  no requirement on a non-empty requirement set. A
  meaningful input can be defined simply by
  providing a set of value ranges./
• / The parameter set should not be empty /
• ?p (?p ? params)
• / Each parameter should be associated to a value
  range/ " ?p (?p ? params ? ?vr (?vr ?
  value_ranges ? ?vr lt?p, ?vsgt))
• goal
• parametric_solution (design, constrs, reqs,
  params, value_ranges)

79
Recap

• (Good) modelling languages support the
  specification of generic task models
• Specifications rely on ontologies
• Task Models can be developed through
  specializations
• Task Models can be used to support knowledge
  acquisition

80
Organizing a library of problem solving methods
81
A clear theoretical basis for PSMs

• Task Models organized through typologies of
  generic tasks
• How can we organize a library of problem solving
  methods?

Answer Use theory of knowledge-based systems to
provide problem solving foundations
82
Definition of Knowledge System

• A knowledge system is a computer system that
  represents and uses knowledge to carry out a
  task
  Mark Stefik
• Knowledge is whatever can be ascribed to an
  agent, such that its behaviour can be computed
  according to the principle of rationality
  Allen
  Newell

83
Principle of Rationality

• If an agent has knowledge that one of its
  actions will lead to one of its goals, then
  the agent will select that action
  Allen Newell

84
Uhmnot much progress.
85
Key is the type of knowledge...

• Problem-solving knowledge is knowledge which is
  brought to bear during a problem solving process,
  when a system is faced with uncertainty in
  choosing among a number of alternatives
• Uncertainty gt system has to search
• Uncertainty gt system can fail
• Uncertainty gt system may have to backtrack

86
Search Model of Problem Solving
Initial State
Goal States
87
Knowledge vs Conventional Systems

• Conventional Systems
• Systems which use direct, algorithmic methods
• Knowledge Systems
• Decision-making systems which use problem solving
  knowledge when taking decisions under uncertain
  conditions. Their search-centred behaviour is an
  inevitable consequence of this existential
  predicament

88
Knowledge-intensive tasks

• Uncertainty is a consequence of the complexity of
  KBS tasks
• Even simple tasks such as classification are
  NP-hard
• No direct methods can exist for such tasks
• Alternative Use problem-solving knowledge

89
(No Transcript)
90
The role of knowledge acquisition

• Problem-solving knowledge tends to be
  experiential and has to be acquired
• Importance of knowledge acquisition
• KBS field as a whole tends to be defined by the
  predominant approach to knowledge acquisition
• KA as mining vs. KA as modelling

91
KA as Mining
Representation Formalism Rules, frames Knowledge
Categories Facts and heuristic problem solving
rules KA Methodology Direct encoding of elicited
knowledge in rule-based system Levels of
Descriptions Only one, in terms of the
rule-based representation KA Paradigm Transfer
of expertise Cognitive Paradigm Production
systems as general problem solving
architectures for intelligence Reuse Inference
engine
92
KA as Modelling
Representation Formalism Level-dependent Knowledg
e Categories Differentiation is driven by
generic knowledge roles KA Methodology Model-ba
sed Levels of Descriptions Multiple (e.g.
knowledge vs. symbol level) KA Paradigm Model
construction Cognitive Paradigm Functional
view of knowledge Reuse Generic task, generic
problem solving model, generic domain model
93
Back to the library..
94
Structure of Library of PSMs
State Space Terminology
Generic Design Terminology
Search
Design as Search
Design Solution
Gen-Design-PSM
Parametric Design Terminology
Ontology
Gen-Parametric Design-PSM
Generic PSM
Legend
95
Search PSM Specification

• Problem solving method search
• ontology
• import
• state-space-terminology
• competence
• roles
• input input State
• output output State
• preconditions
• input ? 0
• postconditions
• solution_state (output)
• assumptions
• ?s . solution_state (?s) successor
  (input, ?s)

96
Search PSM Operational Description

• Begin
• states one x. initialize (input input)
• repeat
• state one x . select _state (states states)
• if solution_state (state)
• then return state
• else
• succ_states one x. derive_successor_states
  (state state)
• states one x. update_state_space (input1
  states input2 succ_states)
• end if
• end repeat
• end

97
Integrating search and design

• ontology basic-design-as-search
• pragmatics
• This ontology integrates the terminology
  associated with search problem solving with the
  basic design one. The aim is to produce the
  modelling support for defining design problem
  solvers which subscribe to the search paradigm.
• import generic-design-terminology,
  state-space-terminology
• signature
• predicates
• computable Design_Element x Design_Model
• variables
• ?s, ?s1, ?s2 State
• ?el Design_Element
• end signature

98
Axioms for Basic-Design-as-Search

• / The states we consider are characterised in
  terms of design models /
• " ?s (?s ? State) ( ?s ? Design_Model )
• / A design element, say ?el, is computable in a
  design model, ?dm, if there is a transition which
  adds ?el to a successor design model of ?dm /
• computable (?el, ?s1) ? ?el ? ?s1 Ù
  ? ?s2. state_transition(?s1, ?s2)
  Ù ?el ? ?s2)

99
From Search to a Generic Design PSM

• PSM refiner search ? gen-design-psm
• pragmatics
• This refiner specialises the generic search PSM
  for design tasks. It refines the generic input
  to a search PSM to be a set of requirements and
  constraints it replaces the generic initialize
  task with the specific initialize_design_model
  and adds an axiom linking solution_state to
  the design-specific predicate admissible_solution.
  
• ontology basic-design-as-search,
  design_solution
• competence
• refined roles
• input reqs, constraints
• refined preconditions
• reqs ¹ ?
• refined-subtasks
• initialize ? initialize_design_model
• axioms
• " ?s solution_state (?s) ? admissible_solution
  (?s, reqs, constraints)

100
From Design to Parametric Design

• PSM refiner gen-design-psm ? genparametric-design
  -psm
• ontology basic-design-as-search,
  parametric-design-terminology
• refined roles
• input reqs, constraints, params, vrs
• output design_model
• refined preconditions
• params ¹ ?
• refined-subtasks
• initialize_design_model ? initialize_parametric
  _design_model
• derive_successor_states ? derive_next_parametri
  c_design_models
• axioms
• / We link the generic notion of solution
  state to the parametric-design-specific
  notion of parametric solution /
• " ?s . solution_state (?s) ?
  parametric_solution (?s, constraints, reqs,
  params, vrs)

101
Parametric Design PSM

• Provides the most generic PSM for parametric
  design
• defines the typical tasks and methods required
  by PSMs for parametric design
• Specific PSMs for parametric design as
  specializations of this generic model
• Formulated as a Task-Method Structure, comprising
  52 definitions.
• Based on search model, task models and problem
  solving abstractions
• design focus, design context and design operator

102
Main Problem Solving Components

• Generic Design Control
• Design from State
• New Design State
• Initialize Design Space
• Generate Successor State
• Select Design State
• Evaluate Design State
• Evaluate feasibility
• Evaluate cost
• Evaluate consistency
• Evaluate completeness

• Extend design
• Collect state foci
• Design from context
• Select design focus
• Design from focus
• Collect focus operators
• Order focus operators
• Select design operator
• Try design operator
• Apply design operator
• Reflect Design State

103
Main Types of Knowledge

• Design Operator
• Design Extension Operator
• Design Space
• Design State
• Success State
• Deadend State
• Incomplete State
• Inconsistent State

• Search Control Record
• Mapping Knowledge
• Design Context
• Design Focus
• Focus Selection Knowledge
• Operator Selection Knowledge
• Available Parameter Values

104
Generic Control

• Loop with State_Space Initial_Design_Statewit
  h Design_State Initial_Design_Stateuntil
  Solution (Design_State)do Flag
  Evaluate_Design_State (Design_State) Context
  Select_Design_Context (Design_State, Flag)
  Focus Select_Design_Focus (Design_State,
  Context) Operator Select_Design_Operator
  (Design_State,
  Context, Focus) Design_Model
  Apply_Design_Operator (Design_State)
  State_Space Add_Design_State (State_Space,
  
  Design_Model) Design_State Select_Design_State
  (State_Space)

105
So What?

• Library based on a clear theoretical basis
• Generic PSM model provides several advantages
• An analytical framework for analysing existing
  PSMs
• A high-level method template for constructing
  specific PSMs for parametric design

106
Constructing New PSMs

• Generic Tasks used as high-level building blocks
  for defining PSMs for parametric design problems
• ProposeBacktrack (0 definitions)
• ProposeRevise (10 definitions)
• A for parametric design (6 definitions)
• ProposeImprove (9 definitions)
• Hill-climbing for parametric design (4
  definitions)
• On average only 10 extra definitions required
  to add a PSM to the library

107
Knowledge-level Analysis Template

• Problem Solving Knowledge
• Constraint Types
• Additional Subtasks
• Control Regime
• Contexts
• Focus Types
• Focus Selection Policy
• Design Operator Types
• Design Operator Order Policy
• Available Design Space
• State Selection Policy
• Completeness
• Optimality

108
Analysis of Existing PSMs

• Approach

Consistency Centred
Completion Centred
Cost Centred
Methods
Gen-design-psmProposeBacktrackHc-designPropose
Improve
A-Design
ProposeRevise
State Selection Policy
1) Constraints Min2) Design Model Max3) Cost
Min
1) Design Model Max 2) Constraints Min3) Cost
Min
1) Constraints Min2) Cost Min 3) Design
Model Max
109
Applications

• Office allocation
• Benchmarking problem (sisyphus-I)
• Real-World (my department moved)
• Elevator design
• Benchmarking problem (sisyphus-II)
• Initial Truck Design
• Real-world application
• Huge improvement in design time
• Sliding Bearing Design
• Real-world application
• Tackled by means of ProposeRevise problem solver

110
Here is the truck.....
111
Modelling an Office Allocation Problem

• Scenario Room Allocation Application
• Generic Task Parametric Design
• Domain KB about employees and offices

Task Level
Parameter
Design Model
Domain Level
Pairs ltEmployee, Roomgt
Employee
112
(No Transcript)
113
Sample Constraint

• (def-domain-instance head-of-group-close-to-secs
  yqt-constraint
• ((applicable-to-parameters
• '(map meta-reference
• (setofall ?x (or (head-of-group ?x)
• (secretary ?x)))))
• (has-expression
• (kappa (?p ?r)
• (or (and (head-of-group
  (domain-reference ?p))
• (not
• (exists ?sec
• (and (secretary
  ?sec)
• (in-room ?sec
  ?r2)
• (gt
  (compute-distance ?r ?r2) 2)))))
• (and (secretary (domain-reference
  ?p))
• (not
• (exists ?m
• (and (head-of-group
  ?m)
• (in-room ?m
  ?r2)
• (gt
  (compute-distance ?r ?r2) 2))))))))))

114
Sample Operator

• (def-instance assign-head-of-group1
  yqt-design-operator
• ((applicable-to-parameters
• '(map meta-reference
• (setofall ?x (head-of-group ?x))))
• (has-body
• (lambda (?x ?rooms)
• (if (and (secretary ?y)
• (in-room ?y ?sec-room))
• (the ?r1
• (and (room ?r1 size 2 central yes
  usable yes)
• (not (member ?r1 ?rooms))
• (empty ?r1)
• (not (exists
• ?r2
• (and (room ?r2 size 2
  central yes usable yes)
• (ltgt ?r2 ?r1)
• (not (member ?r2
  ?rooms))
• (empty ?r2)

115
Cost Function

• Cost ltn1, n2, n3, n4gt, where
• n1 measures the distance between the room of the
  head of the group and that of the secretaries
• n2 the distance between the managers room and
  the rooms of the head of the group and the
  secretaries
• n3 the distance between the heads of projects and
  the head of group and the secretaries
• n4 provides a measure of the project synergy
  afforded by a solution(1 minus the ratio between
  all shared assignments which maximize synergy and
  all shared assignments)

116
Operational Mapping Specifications

• (def-upward-class-mapping yqt-member
  yqt-parameter)
• (def-relation-mapping current-design-model up
• ((current-design-model ?dm)
• if
• ( ?dm (setofall (?p . ?v)
• (and (in-room ?X ?v)
• (maps-to ?p ?x))))))
• (def-relation-mapping current-design-model (down
  add)
• (lambda (?x)
• (loop for ?pair in ?x
• do
• (if (maps-to (first ?pair) ?z)
• (tell (in-room ?z (rest ?pair)))))))
• (def-relation-mapping current-design-model (down
  remove)
• (lambda (?x) (unassert (in-room ?x ?y))))

117
Major Recap

• Modelling framework makes it possible to build
  powerful reusable models
• Clear theoretical basis provides organization for
  library
• Knowledge-level approach useful for
• Analysis and Development of problem solving
  methods and applications
• Existing libraries used in real-world applications

118
Knowledge Modelling for Knowledge Management
119
Knowledge Management

• Fuzzy concept, but a Hot Topic in organizations
• Awareness of organizational knowledge as a key
  strategic asset, to be managed to maximise its
  value to a company
• External factors
• Knowledge-based economy
• Increasing importance of intangible assets
• New communication and computing technology
• Globalization

120
Kn. Mgt Converting and Connecting
OLeary, IEEE Expert, 1998

• Converting
• Individual to Group-available Knowledge
• Knowledge elicitation, shared workspaces
• Data to Knowledge
• Data mining
• Text to Knowledge
• Information Extraction
• Connecting
• People to Knowledge
• Agents, clever search engines
• Knowledge to Knowledge
• System integration
• People to People
• Intranet
• Knowledge to People
• Push technology

121
Document-Centred Knowledge Work

• Communication and work-practices in organizations
  are document-centred
• But...
• Documents are big.
• There are lots of them.
• Knowledge retrieval is inefficient.
• They are a poor medium to support automated
  intelligent services.
• Do not normally explicitly embed the
  meta-knowledge required to interpret and use
  them.

122
Contextually-Enriched Documents

• Different forms of enrichment
• Through discussion spaces
• Through ontology-based formal models
• Underlying theoretical framework
• Reflection-in-action (linking working and
  learning)
• Domain construction (shared models)
• Perspective taking (contextual cues)
• SER (Fischer) lifecycle
• Seed/extend/restructure

123
D3E Environment
124
Where/With Whom?

• Domains
• Electronic News Publishing, Medical Guidelines,
  Engineering Design, Fault log management,
  Helpdesk support, Best Practice Repositories,
  Engineering Design, Courseware
• Users
• British Aerospace, GEC, German Coal Mining
  Industry, Siemens, UK University for Industry.

125
Example Planet-Onto

• Starting point KMi Planet, an electronic
  newsletter.
• Supports communication within KMi and publicizes
  KMI activities to external world
• Archive has 100 stories
• 480 registered readers
• Success story! Customised versions produced for
  several groups within and outside the OU.

126
KMi Planet Front Page
127
Not a Knowledge Management System...

• Information retrieval problem
• Find me stories related to knowledge management
  research
• Newsletter only part of broad range of
  information sources
• who else works on medical informatics?
• Need to integrate it with other sources, - e.g.
  web pages, mailing lists, etc.
• Text format not adequate to support additional
  services
• E.g., personalised news feeds story
  identification

128
Solution Planet-Onto

• Ontology-driven document formalisation
• Integration of newsletter with general-purpose
  lab KB
• Semantic knowledge retrieval
• Intelligent Agents

129
Ontology-driven Document Enrichment
130
Steps in Document Enrichment

• Identify Scenario From newsletter to integrated
  knowledge management system
• Select Viewpoint for Ontology Academic Life
• Develop Ontology KMI-Planet
• Populate Ontology KMi-Planet KB
• Develop Query Interface Lois-based
• Develop additional reasoning services NewsHound,
  NewsBoy

131
Architecture of Planet-Onto
Query Interface
Planet KB
NewsBoy
NewsHound
KA Tool
Planet Ontology
Modelling Language (OCML)
Story Database
Email
Web Browser
WebOnto
132
Building Blocks for Ontology

• News Stories
• Events
• Technologies
• People
• Organisations
• Projects

133
(No Transcript)
134
Document Annotation
135
Knowledge Retrieval through Lois
136
NewsHound
137
NewsBoy
138
Summary

• Knowledge management important challenge for
  organizations
• Knowledge Modelling Technology plays a key role
• Knowledge acquisition interfaces
• Ontologies
• Agents
• Integration of text with formalised knowledge
  models
• Planet-Onto is an example of applying knowledge
  modelling to knowledge management

139
Conclusions
140
Future Developments

• Ontologies for e-commerce
• Large potential
• Large-scale system integration based on shared
  ontologies
• Agents cooperating on the web
• Again, e-commerce as key area
• Sophisticated on-line reasoning services
• Currently, browsers/editors for knowledge
  modelling
• Future Specialised reasoning services, such as
  classifiers, planners, information extraction
• Intelligent Brokers
• IBROW project

141
The End