Knowledge Modelling: Foundations, Techniques and Applications

Preview:

DESCRIPTION

Knowledge Modelling: Foundations, Techniques and Applications. Enrico Motta Knowledge Media Institute The Open University United Kingdom. Basic KBS Architecture. Inference Engine. User Interface. Domain Knowledge Base. First Generation KBS Architecture. Inference Engine. User - PowerPoint PPT Presentation

Citation preview

Knowledge Modelling:Knowledge Modelling:Foundations, Techniques and Foundations, Techniques and

ApplicationsApplications

Enrico MottaKnowledge Media Institute

The Open UniversityUnited Kingdom

UserInterface

Domain Knowledge Base

InferenceEngine

Basic KBS Architecture Basic KBS Architecture

UserInterface

Domain Knowledge Base

InferenceEngine

First Generation KBS First Generation KBS Architecture Architecture

Rule-basedBackward-chaining

Set of Domain rules

UserInterface

Domain Knowledge Base

InferenceEngine

ProblemsProblems

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

Heuristic Classification ModelHeuristic Classification Model

Abstraction

Heuristic Match

Data

Refinement

Solutions

Clancey, AI Journal, 27, 1985

DataAbstractions

SolutionsAbstractions

HC in Medical DiagnosisHC in Medical Diagnosis

Abstraction

Heuristic Match

Refinement

Solutions

DataAbstractions

SolutionsAbstractions

Low white blood count

Immunosuppressed

Data

Gram-negative Infection

E-coli Infection

HC in Book SelectionHC in Book Selection

Abstraction

Heuristic Match

Refinement

Solutions

DataAbstractions

SolutionsAbstractions

Watches no TV

Educated Person Stereotype

Data

‘Intelligent Book’

Anna Karenina

So What? (Competence vs So What? (Competence vs Performance)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

So What? (Levels of system So What? (Levels of system analysis)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?

So What? (Reuse)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.

So What? (Research & So What? (Research & Development)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?

Knowledge-level ArchitecturesKnowledge-level Architecturesfor Sharing and Reusefor Sharing and Reuse

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

systems

Modelling Frameworks (1)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—UPML - Fensel & Motta

Modelling Frameworks (2)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

A Constructive Approach...A Constructive Approach...

Let’s define our own framework...

Generic TasksGeneric 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

Example: Parametric DesignExample: 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”

Example: ClassificationExample: Classification

Generic Task Classification Inputs: Candidate-classes

Observables

Output: Best-Matching-Classes

Preconditions: “At least one candidate

class exists”

Goal: “To find the class that best

explains the observables”

Generic Component 2: Reusable Generic Component 2: Reusable PSMsPSMs

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.....

Functional Specification of a PSMFunctional 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)

Operational DescriptionOperational 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

Task-Method StructuresTask-Method Structures

Problem Type

Primitive PSM

Multi-Functional Domain ModelsMulti-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..

Application Model

Picture so far..Picture so far..

Problem SolvingMethod

Classification Simple Classifier

Lunar rocks

Generic Task

Multi-Functional Domain

Problem SolvingMethod

Classification Simple Classifier

Lunar rocks

Application Model

Generic Task

Multi-Functional Domain

IssueIssue

How to link different reusable components?

Problem SolvingMethod

Classification

Task-DomainMapping

PSM-DomainMapping

Simple Classifier

Lunar rocks

Application Model

Generic Task

Multi-Functional Domain

Solution: MappingsSolution: Mappings

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

Task-PSMMapping

ExampleExample

Scenario: Office Allocation Application

Generic Task: Parametric Design

Domain: KB about employees and offices

Parameter

Employee

Design Model

Pairs<Employee, Room>

Task Level

Domain Level

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

Application-specific knowledgeApplication-specific knowledge

Yes: Application-specific heuristic problem solving knowledge

Elevator Design ExampleElevator 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

Complete PictureComplete Picture

Problem SolvingMethod

Generic Task

Multi-Functional Domain

MappingKnowledge

Application-specificProblem-Solving Knowledge

Application Configuration

Application Model

Even More Complete PictureEven More Complete Picture

Problem SolvingMethod

Generic Task

Multi-Functional Domain

MappingKnowledge

Application-specificProblem-Solving Knowledge

Application Configuration

Domain Ontology

Task Ontology Method Ontology

Mapping Ontology Ontology

Application Model

Recommended