Introduction
4 likes4,110 views
The document provides an introduction to knowledge engineering. It discusses what knowledge engineering is, its history and terminology. Key aspects covered include the process of eliciting, structuring and formalizing domain knowledge to build programs to perform difficult tasks. Challenges include dealing with complex, ambiguous knowledge from multiple sources. The importance of proper knowledge engineering is emphasized to avoid errors and support maintenance. Common approaches and models used in knowledge engineering projects are outlined, including the roles of various participants.
Introduction
- 1. Introduction to Knowledge Engineering What is Knowledge Engineering? History & Terminology
- 2. 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
- 3. 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
- 4. 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
- 5. 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
- 6. Introduction 6 A Short History of Knowledge Systems 1965 19851975 1995 general-‐purpos e s earch engines (GPS ) firs t-‐generation rule-‐bas ed s ys tems (MYC IN, XC ON) emergence of s tructured methods (early K ADS ) mature methodologies (C ommonK ADS ) => from art to discipline =>
- 7. Introduction 7 First generation “Expert” Systems ■ shallow knowledge base ■ single reasoning principle ■ uniform representation ■ limited explanation capabilities reas oning control knowledge bas e operates on
- 8. 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
- 9. 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
- 10. 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
- 11. Introduction 11 Methodological pyramid world view theory methods tools use feedback case studies application projects C AS E tools implementation environments life-‐cycle model, process model, guidelines, elicitation techniques graphical/textual notations work sheets, document structure model-‐based k nowledge engineering reuse of k nowledge patterns
- 12. 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.
- 13. 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.
- 14. 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.
- 15. Introduction 15 CommonKADS Model Set Organization Model Task Model Agent Model Knowledge Model Communication Model Design Model Context Concept Artefact
- 16. 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).
- 17. 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.
- 18. 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.
- 19. 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
- 20. 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
- 21. 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
- 22. 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
- 23. Introduction 23 Knowledge engineer ■ specific kind of system analyst ■ should avoid becoming an "expert" ■ plays a liaison function between application domain and system
- 24. 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
- 25. 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
- 26. 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
- 27. 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
- 28. Introduction 28 Roles in knowledge-system development knowledge provider/ specialist project manager knowledge system developer knowledge engineer/ analyst knowledge manager knowledge user K S manages manages uses designs & implements validates elicits knowledge from elicits requirements from delivers analysis models to defines knowledge strategy initiates knowledge development projects facilitates knowledge distribution
- 29. 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
- 30. 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
- 31. 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.