Knowledge Modelling: Foundations, Techniques and Applications - PowerPoint PPT Presentation

Loading...

PPT – Knowledge Modelling: Foundations, Techniques and Applications PowerPoint presentation | free to download - id: d17b7-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Knowledge Modelling: Foundations, Techniques and Applications

Description:

To present key methodologies, technologies, ... A database of cars. The CYC knowledge base, etc.. Picture so far.. Problem Solving ... Elevator Design Example ... – PowerPoint PPT presentation

Number of Views:63
Avg rating:3.0/5.0
Slides: 142
Provided by: Enrico50
Learn more at: http://people.kmi.open.ac.uk
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com