knowledge engineering i - utrecht university · maintenance iterate, ... knowledge engineering...

24
1 1 1. Knowledge Engineering Overview: KS Development cycle KS Strategy KS Development KS Applicability Literature: Chapter 9 Weitzel, Kerschberg, 1989 Kim, 2003 Preece, 2001 Schreiber et al, 1994 2 13/11/08 DKS - Module 2 Knowledge Engineering

Upload: docong

Post on 27-May-2018

222 views

Category:

Documents


0 download

TRANSCRIPT

1

1

1. Knowledge Engineering

Overview: KS Development cycle KS Strategy KS Development KS Applicability

Literature:   Chapter 9   Weitzel, Kerschberg, 1989   Kim, 2003   Preece, 2001   Schreiber et al, 1994

2 13/11/08 DKS - Module 2

Knowledge Engineering

2

3 13/11/08 DKS - Module 2

Aim: Development of KS

Expert User

Knowledge system

Knowledge Base

Inference engine

Knowledge system shell

Designer Elicit knowledge Elicit requirements

Knowledge Engineering

4 13/11/08 DKS - Module 2

  Why?   What for?   Who for?   What with?

3

5 13/11/08 DKS - Module 2

Organizational choices/ knowledge strategy

Usability Integration User models

...

Characteristics Scope Users ... → solution

Models/ tools/

reasoning

KR / Elicitation / Task models /

...

HR solution KS Solution

Design Development/

Implementation

Training / selection /...

Problem analysis

Problem Identification

KS Development Cycle

Evaluation

DKS!

6 13/11/08 DKS - Module 2

Development KS

  Problem formulation

  Feasibility study

  Knowledge engineering   Sub-problems, concepts, relations, rules,…

  System modeling/design   Conceptual design, detail design

  System implementation

  Evaluation/testing   Test reasoning, test knowledge, validation

  Maintenance

 Iterate, again and again

4

7 13/11/08 DKS - Module 2

  What’s different from any other computational system?

8 13/11/08 DKS - Module 2

KE vs. system analysis

  Conventional system analysis   well-defined activity   details and duration of tasks can be documented, monitored

  Knowledge Engineering   abstract nature of knowledge: unclear requirements   goals are not clearly defined: soft goals   difficult articulation of knowledge

5

9 13/11/08 DKS - Module 2

  How to justify KS?   Linking KS to organizational/business strategy

  Knowledge Management is the link

10 13/11/08 DKS - Module 2

Knowledge Management

  Knowledge management is the process through which an organization consciously and comprehensively gathers, organizes, shares, and analyzes its knowledge in terms of resources, documents, and people skills

  KM vs. KE   Knowledge management establishes the direction the process should

take   Knowledge engineering develops means to accomplish that direction

KM

KE

6

11 13/11/08 DKS - Module 2

Difficulties with KM

  Knowledge is not information   IT cannot solve it all   People don’t change just because there are told to do so   Results take time to achieve   Failure to acknowledge value of knowledge and knowledge

sharing

12 13/11/08 DKS - Module 2

  Insufficiently available (lack of knowledge)   Available but unbalanced distributed   Available but fragmented   Available but insufficiently reachable

(not at the right place at the right time)   Available but incomprehensible

(hard to understand because of volume and complexity)

Knowledge Problems

7

13 13/11/08 DKS - Module 2

Solutions to knowledge problems

  Working in project teams   Communities of Practice   Training and recruiting   Culture change process   Management report   Make knowledge explicit (KS)

  Preserve, unify, organize, formalize…   Distribute knowledge (KS)   Make knowledge available to non-experts (KS)

14 13/11/08 DKS - Module 2

Knowledge Strategy

  Goals: what must be implemented?   Requirements: what must it achieve?   Priorities: what first?   Stakeholders: who is involved?   Enablers: what can help?   Inspiration: how to involve people?   Long-term: what in the future?

8

15 13/11/08 DKS - Module 2

RE: Requirements engineering

  RE can be defined as a systematic process of developing requirements through an iterative co-operative process of   analyzing the problem,   documenting the resulting observations in a variety of

representation formats, and   checking the accuracy of the understanding gained.

16 13/11/08 DKS - Module 2

Requirements elicitation

  Global: organizational needs and constraints   Functional: results and interfaces   Stakeholder: personal needs and constraints   Technological: software and hardware

9

17 13/11/08 DKS - Module 2

Requirement Specification

  Results in a document which:   Describes the problem   Sets goals   Addresses needs, desires, and concerns of the end users   Addresses issues of verification and validation

18 13/11/08 DKS - Module 2

From Strategy to Design

  KS is not always the optimal or only solution: often combinations are needed

  Other technological possibilities   Document management

•  repositories; task-related search   Discussion forums/CSCW/virtual communities

•  Socialization; dissemination; training

  Capability management •  Know who knows what; Yellow pages

  Lessons learned •  Reuse experience; often CBR

10

19 13/11/08 DKS - Module 2

Relation to KM Activities

  Creation   Organization   Share   Use

availability vs. innovation uniformity vs. localized repository vs. collaboration just-in-time vs. made-to-fit

Knowledge systems

CSCW, HR solutions

20 13/11/08 DKS - Module 2

KS Development

  Design   Develop prototype   Validate and verify   Test and deploy   Maintain

  Requires continuous dialogue between engineer and expert   iterative development   feedback loop   springboard for discussion

11

21 13/11/08 DKS - Module 2

KS Development Steps

Initial analysis and definition of problem domain

Select subset and build initial prototype

Test system

Expand domain; further KA and extend system

Good solution?

Deliver system

yes

no almost

22 13/11/08 DKS - Module 2

Knowledge Design

  Knowledge Acquisition   Knowledge Representation

12

23 13/11/08 DKS - Module 2

Knowledge Acquisition

  Knowledge acquisition is the extraction of knowledge from sources of expertise and its transfer to the knowledge base and sometimes to the inference engine

  Sources   Documented (books, manuals, etc.)   Undocumented (in people's minds)   From people, machines, databases, via the internet

elicitation

24 13/11/08 DKS - Module 2

Knowledge Elicitation

  Manual   Interviewing

•  Structured, •  Semi-structured, •  Unstructured

  Observing & Tracking the Reasoning Process

  Semi-automatic   Support Experts Directly

  Automatic   Computer Aided   Expert’s and/or engineer’s

roles are minimized

13

25 13/11/08 DKS - Module 2

Difficulties in Knowledge Acquisition

  Expressing the Knowledge   expert’s “rules” are often difficult to articulate   not available to conscious introspection   knowledge engineer’s domain “knowledge”

  Transfer to a Machine   Number of Participants   Structuring the Knowledge

26 13/11/08 DKS - Module 2

Overcoming the Difficulties

  Knowledge engineer   The ability and personality of the knowledge engineer   Relationship with the expert

  Knowledge acquisition tools   Computer-aided   Support for Knowledge Engineer, Expert, End user   Able to decrease the mismatch between the human expert and

the program (“learning by being told”)   Natural language processor to translate knowledge to a

specific representation

14

27 13/11/08 DKS - Module 2

Knowledge Representation

  Possible representations:   (production) rules,   semantic nets, frames, ontologies   Probabilistic methods   Other: logic, fuzzy systems, neural nets

  efficiency and effectiveness criteria   incorporation into KS development software

28 13/11/08 DKS - Module 2

Knowledge Representation: Desirable features

  Completeness   support the acquisition of all aspects of knowledge

  Conciseness   efficient acquisition, easy storage and access

  Computational Efficiency   Transparency

  enable understanding of behavior and conclusions   Scalable in details

15

29 13/11/08 DKS - Module 2

Choosing a KR type

  Rule based?   Classification?   Uncertainty?

30 13/11/08 DKS - Module 2

Knowledge Rules

  Consequents: describe possible solution   actions to follow when rule is

applicable

if condition(s) then action(s)

  Antecedents: describe a problem solving situation   rule is applicable when

antecedents are true

16

31 13/11/08 DKS - Module 2

Advantages of Rules

  Easy to understand (natural form of knowledge)   Easy to derive inference and explanations   Easy to modify and maintain   Easy to combine with uncertainty   Rules are frequently independent

32 13/11/08 DKS - Module 2

Drawbacks of Rules

  Have to embed all context into antecedent   No distinction of different types   Combined effects can be opaque   Not appropriate for all types of problem solving or

expertise: e.g. medical histories   Unable to learn, because rules cannot modify themselves

17

33 13/11/08 DKS - Module 2

Classification: Ontologies

  An ontology is a formal explicit description of concepts in a domain of discourse   Classes (or concepts) have

•  Slots: attributes of the concept •  Facets: restrictions on slots •  Instances

  Hierarchical relations   based on the frame concept

  focus on structural properties of classes

34 13/11/08 DKS - Module 2

Classification: example

ANIMAL

DOG HUMAN WHALE

Long john

Reproduce: Yes Life-Form: Yes

Scales: Yes Warmblooded: No

Warmblooded: Yes Spinal Cord: Yes

Legs: 2

Legs: 1

Legs: 0 Fins: Yes

Legs: 2 Wings: Yes Feathers: Yes

MAMMAL REPTILE BIRD FISH

slot

is-a hierarchy

default value

instance

Legs: 4 Bark: yes Weight Height Food-intake: x=fi(height, weight)

procedural slot

18

35 13/11/08 DKS - Module 2

Advantages of Ontologies

  (limited) inference support   inheritance

  enables grouping   facilitates update

  easy to understand: graphical representation   claim: good model of memory organization

36 13/11/08 DKS - Module 2

Disadvantages of Ontologies

  restricted to declarative knowledge   cannot represent procedural knowledge

  quickly becomes unwieldy   Limited inferencing power   Difficult to deal with uncertain knowledge

19

37 13/11/08 DKS - Module 2

Uncertainty

  Assumptions are not always true or false   Handling uncertainty:   Numerical or probabilistic methods (Bayes)

  Quantification of uncertainty by subjective weights   Precise, based on mathematical probability

  Logical methods (fuzzy logic)   Reasoning about uncertainty, not with uncertainty   Precise, but difficult to implement in practical systems

38 13/11/08 DKS - Module 2

Bayesian inference

  derive the probability of cause given symptom   Ex: Given fever, what is the probability of flu?

  inverse or a posteriori probability   inverse to conditional probability of an earlier event given that

a later one occurred   If P(Fever|Flu) and P(Fever), how to calculate P(Flu|Fever)?

20

39 13/11/08 DKS - Module 2

Advantages of Bayesian Reasoning

  sound theoretical foundation   well-defined semantics for decision making   Enable representation of human ‘intuition’, not just right or wrong answers

40 13/11/08 DKS - Module 2

Problems of Bayesian Reasoning

  requires large amounts of probability data   subjective evidence may not always be reliable   independence of evidences assumption often not valid   relationship between hypothesis and evidence is reduced

to a number   explanations for the user difficult   high computational overhead

21

41 13/11/08 DKS - Module 2

Fuzzy Logic

  Boolean logic uses sharp distinctions   Fuzzy logic reflects vagueness of real world

42 13/11/08 DKS - Module 2

Advantages of Fuzzy Logic

  general theory of uncertainty   wide applicability, many practical applications   natural use of vague and imprecise concepts

  helpful for commonsense reasoning, explanation

22

43 13/11/08 DKS - Module 2

Problems of Fuzzy Logic

  membership functions can be difficult to find   multiple ways for combining evidence   problems with long inference chains

44 13/11/08 DKS - Module 2

Criteria for choosing a Representation Scheme

  Support acquisition, retrieval, and reasoning   Natural, uniformity, and comprehensibility   Degree of explicitness   Modularity and flexibility of the knowledge base   Efficiency of knowledge retrieval   Heuristic power

23

45 13/11/08 DKS - Module 2

KR: applicability

  Rules:   representation of rules of thumb expertise   Logical background

  Ontologies:   Classification, taxonomy representation   structured knowledge on objects and relations

  Uncertainty:   Representation of unknown, uncertain values   Probabilistic knowledge / vague knowledge

46 13/11/08 DKS - Module 2

Next lecture:

Introduction to Logic (18 november 2007)

24

47 13/11/08 DKS - Module 2