Introduction
-
Upload
guus-schreiber -
Category
Technology
-
view
307 -
download
0
description
Transcript of Introduction
![Page 1: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/1.jpg)
Introduction to Knowledge Engineering
What is Knowledge Engineering? History & Terminology
![Page 2: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/2.jpg)
Introduction 2
Data, information & knowledge
■ Data ➤ “raw signals”
. . . - - - . . .
■ Information ➤ meaning attached to data
S O S
■ Knowledge ➤ attach purpose and competence to information ➤ potential to generate action
emergency alert → start rescue operation
![Page 3: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/3.jpg)
Introduction 3
Knowledge engineering
process of ➤ eliciting, ➤ structuring, ➤ formalizing, ➤ operationalizing
information and knowledge involved in a knowledge-intensive problem domain,
in order to construct a program that can perform a difficult task adequately
![Page 4: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/4.jpg)
Introduction 4
Problems in knowledge engineering
■ complex information and knowledge is difficult to observe
■ experts and other sources differ ■ multiple representations:
➤ textbooks ➤ graphical representations ➤ heuristics ➤ skills
![Page 5: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/5.jpg)
Introduction 5
Importance of proper knowledge engineering
■ Knowledge is valuable and often outlives a particular implementation ➤ knowledge management
■ Errors in a knowledge-base can cause serious problems
■ Heavy demands on extendibility and maintenance ➤ changes over time
![Page 6: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/6.jpg)
Introduction 6
A Short History of Knowledge Systems
1965 19851975 1995
g eneral-‐purpos e s earch eng ines
(GP S )
firs t-‐g eneration rule-‐bas ed s ys tems
(MYC IN, XC ON)
emerg ence of s truc tured methods
(early K ADS )
mature methodolog ies(C ommonK ADS )
=> from art to dis c ipline =>
![Page 7: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/7.jpg)
Introduction 7
First generation “Expert” Systems
■ shallow knowledge base ■ single reasoning principle ■ uniform representation ■ limited explanation
capabilities
reas oningc ontrol
knowledg ebas e
operateson
![Page 8: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/8.jpg)
Introduction 8
Transfer View of KE
■ Extracting knowledge from a human expert ➤ “mining the jewels in the expert’s head”’
■ Transferring this knowledge into KS. ➤ expert is asked what rules are applicable ➤ translation of natural language into rule format
![Page 9: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/9.jpg)
Introduction 9
Problems with transfer view
The knowledge providers, the knowledge engineer and the knowledge-system developer should share ➤ a common view on the problem solving process and ➤ a common vocabulary
in order to make knowledge transfer a viable way of knowledge engineering
![Page 10: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/10.jpg)
Introduction 10
Rapid Prototyping
■ Positive ➤ focuses elicitation and interpretation ➤ motivates the expert ➤ (convinces management)
■ Negative ➤ large gap between verbal data and implementation ➤ architecture constrains the analysis hence: distorted model ➤ difficult to throw away
![Page 11: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/11.jpg)
Introduction 11
Methodological pyramid
world view
theory
methods
tools
use feedbackcas e s tudies
application projec ts
C AS E toolsimplementation environments
life-‐c yc le model, proces s model,guidelines , elic itation techniques
graphical/textual notationswork s heets , document s truc ture
model-‐bas ed k nowledge engineeringreus e of k nowledge patterns
![Page 12: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/12.jpg)
Introduction 12
World view: Model-Based KE
■ The knowledge-engineering space of choices and tools can to some extent be controlled by the introduction of a number of models
■ Each model emphasizes certain aspects of the system to be built and abstracts from others.
■ Models provide a decomposition of knowledge-engineering tasks: while building one model, the knowledge engineer can temporarily neglect certain other aspects.
![Page 13: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/13.jpg)
Introduction 13
CommonKADS principles
■ Knowledge engineering is not some kind of `mining from the expert's head', but consists of constructing different aspect models of human knowledge
■ The knowledge-level principle: in knowledge modeling, first concentrate on the conceptual structure of knowledge, and leave the programming details for later
■ Knowledge has a stable internal structure that is analyzable by distinguishing specific knowledge types and roles.
![Page 14: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/14.jpg)
Introduction 14
CommonKADS theory
■ KBS construction entails the construction of a number of models that together constitute part of the product delivered by the project.
■ Supplies the KBS developer with a set of model templates.
■ This template structure can be configured, refined and filled during project work.
■ The number and level of elaboration of models depends on the specific project context.
![Page 15: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/15.jpg)
Introduction 15
CommonKADS Model Set
Organization Model
Task Model
Agent Model
Knowledge Model
Communication Model
Design Model
Context
Concept
Artefact
![Page 16: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/16.jpg)
Introduction 16
Model Set Overview (1)
■ Organization model ➤ supports analysis of an organization, ➤ Goal: discover problems, opportunities and possible
impacts of KBS development.
■ Task model ➤ describes tasks that are performed or will be performed in
the organizational environment
■ Agent model ➤ describes capabilities, norms, preferences and permissions
of agents (agent = executor of task).
![Page 17: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/17.jpg)
Introduction 17
Model Set Overview (2)
■ Knowledge model ➤ gives an implementation-independent description of
knowledge involved in a task.
■ Communication model ➤ models the communicative transactions between agents.
■ Design model ➤ describes the structure of the system that needs to be
constructed.
![Page 18: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/18.jpg)
Introduction 18
Principles of the Model Set
■ Divide and conquer. ■ Configuration of an adequate model set for a specific
application. ■ Models evolve through well defined states. ■ The model set supports project management. ■ Model development is driven by project objectives and risk. ■ Models can be developed in parallel.
![Page 19: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/19.jpg)
Introduction 19
Models exist in various forms
■ Model template ➤ predefined, fixed structure, can be configured
■ Model instance ➤ objects manipulated during a project.
■ Model versions ➤ versions of a model instance can exist.
■ Multiple model instances ➤ separate instances can be developed ➤ example: ''current'' and ''future'' organization
![Page 20: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/20.jpg)
Introduction 20
The Product
■ Instantiated models ➤ represent the important aspects of the environment and the
delivered knowledge based system.
■ Additional documentation ➤ information not represented in the filled model templates
(e.g. project management information)
■ Software
![Page 21: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/21.jpg)
Introduction 21
Roles in knowledge-system development
■ knowledge provider ■ knowledge engineer/analyst ■ knowledge system developer ■ knowledge user ■ project manager ■ knowledge manager N.B. many-to-many relations between roles and people
![Page 22: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/22.jpg)
Introduction 22
Knowledge provider/specialist
■ “traditional” expert ■ person with extensive experience in an application
domain ■ can provide also plan for domain familiarization
➤ “where would you advise a beginner to start?”
■ inter-provider differences are common ■ need to assure cooperatio
![Page 23: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/23.jpg)
Introduction 23
Knowledge engineer
■ specific kind of system analyst ■ should avoid becoming an "expert" ■ plays a liaison function between application domain
and system
![Page 24: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/24.jpg)
Introduction 24
Knowledge-system developer
■ person that implements a knowledge system on a particular target platform
■ needs to have general design/implementation expertise
■ needs to understand knowledge analysis ➤ but only on the “use”-level
■ role is often played by knowledge engineer
![Page 25: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/25.jpg)
Introduction 25
Knowledge user
■ Primary users ➤ interact with the prospective system
■ Secondary users ➤ are affected indirectly by the system
■ Level of skill/knowledge is important factor ■ May need extensive interacting facilities
➤ explanation ■ His/her work is often affected by the system
➤ consider attitude / active tole
![Page 26: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/26.jpg)
Introduction 26
Project manager
■ responsible for planning, scheduling and monitoring development work
■ liaises with client ■ typically medium-size projects (4-6 people) ■ profits from structured approach
![Page 27: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/27.jpg)
Introduction 27
Knowledge manager
■ background role ■ monitors organizational purpose of
➤ system(s) developed in a project ➤ knowledge assets developed/refined
■ initiates (follow-up) projects ■ should play key role in reuse ■ may help in setting up the right project team
![Page 28: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/28.jpg)
Introduction 28
Roles in knowledge-system development
knowledgeprovider/spec ia list
projec tmanager
knowledgesystem deve loper
knowledgeeng ineer/ana lyst
knowledgemanager
knowledgeuser
K S
manages
managesus es
des igns &implements
validates
elic its knowledgefrom
elic itsrequirements
from
deliversanalys is models
to
defines knowledge s trategyinitiates knowledge development projectsfac ilitates knowledge dis tribution
![Page 29: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/29.jpg)
Introduction 29
Terminology
■ Domain ➤ some area of interest
banking, food industry, photocopiers, car manufacturing
■ Task ➤ something that needs to be done by an agent
monitor a process; create a plan; analyze deviant behavior
■ Agent ➤ the executor of a task in a domain
typically either a human or some software system
![Page 30: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/30.jpg)
Introduction 30
Terminology
■ Application ➤ The context provided by the combination of a task and a
domain in which this task is carried out by agents
■ Application domain ➤ The particular area of interest involved in an application
■ Application task ➤ The (top-level) task that needs to be performed in a certain
application
![Page 31: Introduction](https://reader034.fdocuments.net/reader034/viewer/2022051515/5578f5ead8b42a675b8b471d/html5/thumbnails/31.jpg)
Introduction 31
Terminology
■ knowledge system (KS) ➤ system that solves a real-life problem using knowledge
about the application domain and the application task
■ expert system ➤ knowledge system that solves a problem which requires a
considerable amount of expertise, when solved by humans.