knowledge engineering i - utrecht university · maintenance iterate, ... knowledge engineering...
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)