financial informatics –vii: knowledge acquisition

1

Financial Informatics –VII:Knowledge Acquisition

1

Khurshid Ahmad, Professor of Computer Science,

Department of Computer Science

Trinity College,Dublin-2, IRELAND

November 17th, 2008.https://www.cs.tcd.ie/Khurshid.Ahmad/Teaching.html

2

Knowledge Acquisition INTRODUCTION & BACKGROUND

• The important characteristics of knowledge are that it is experiential, descriptive, qualitative, largely undocumented and constantly changing.

• There are certain domains where all these properties are found and some

where there are only a few. • The lack of documentation and the fact that experts carry a lot of

information in their heads, make it difficult to gain access to their knowledge for developing information systems in general and expert systems in particular.

• Therefore, knowledge engineers have devised specialised techniques to

extract and document this information in an efficient and expedient

manner: Knowledge Acquisition.

3


• Currently knowledge bases for knowledge based systems are crafted by hand, this is a severe limitation on the rapid deployment of such systems.

• The automation of knowledge acquisition (from text) would greatly ease this problem.

• There is considerable interest in developing software tools which would allow the automatic construction of knowledge bases from textual information.

• This will provide the opportunity to rapidly build knowledge bases thus increasing, for example, the rate at which knowledge based systems can be developed and deployed

4


• Knowledge acquisition can be regarded as a method by which a knowledge engineer obtains information from experts, text books, and other authoritative sources for ultimate translation into a machine language and knowledge base.

• The person undertaking the knowledge acquisition must convert the acquired knowledge into a form that a computer program can use.

5


In the process of Knowledge Acquisition for an Expert System Project, the knowledge engineer basically performs four major tasks in sequence:

First, the engineer ensures that he or she understands the aims and objectives of the proposed expert system to get a feeling for the potential scope of the project.

Second, he or she develops a working knowledge of the problem domain by mastering it's terminology by looking up technical dictionaries and terminology data bases. For this task the key sources of knowledge are identified: textbooks, papers, technical reports, manuals, codes of practice, and domain experts. The engineer establishes the ontological commitment of the domain specialists.

Third, the knowledge engineer interacts with experts via meetings or interviews to acquire, verify and validate their knowledge.

Fourth, the knowledge engineer produces a "paper knowledge base"; a document or group of documents which form an intermediate stage in the translation of knowledge from source to computer program. This comprises the interview transcripts, the analysis of the information they contain and a full description of the major domain entities (e.g. tasks, rules and objects).

6


Knowledge engineers interview experts in a specialist domain about how he or she solves a given problem. Before interviewing the experts, the knowledge engineers have to formulate their questions, and after the interview the answers to the questions have to be analyzed.

The knowledge engineer has to familiarize himself or herself with the terminology of the specialist domain; he or she has to consult technical manuals, and in some cases learned papers, to see how the experts’ knowledge is applied; the knowledge engineers sometimes consults textbooks or encyclopedic texts for understanding the conceptual structure of the experts’ domain. In many different ways the knowledge engineer literally has to come to terms with the language used by the expert and that used in the other texts mentioned above. The knowledge engineer should become conversant in the specialist language of his or her application domain.

7

Knowledge Acquisition Acquiring Problem-Solving Knowledge

The knowledge essential for solving problems of a given domain can be structured in a (problem-solving) task-oriented fashion. Each task is executed sequentially which in turn involves the use of IF . . . THEN type constructs - rules and rules of thumb. These rules test and manipulate a number of abstract and physical entities of the domain which are referred to as domain objects.

Problem-Solving Tasks

Task number 1 2 3 4 5

Rule number 1 3 4 5 987

Objects 1 2 3

62

1 2 3 4 5 6

8

Knowledge Acquisition Methods and Techniques

TerminologySystematically organised collection of terms and their elaborations, including definitions, grammatical categories, and related term.

The system used is usually a conceptual one. The conceptual basis is that of the discipline and its potential application. For example, physicists organise their subject discipline in terms of forces, energy and mass; chemists focus on atoms and molecules; biologists organise their subject in terms of kingdoms, families and species.

9


TerminologyThe rules in a knowledge based system are essentially a conjunction of terms:Typical MYCIN 'rule'IF: the stain of the organism is gramneg, &

the morphology of the organism is rod, &the aerobicity of the organism is aerobic

THEN there is strongly suggestive evidence (0.8) that the class of organism is enterobacteriaceae

Typical XCON 'rule'IF: The most current active context is assigning a power supply &

an sbi module of any type has been put in a cabinet & the position it occupies in the cabinet (its nexus) is known & there is space available in the cabinet for a power supply for that nexus &there is an available power supply

THEN: put the power supply in the cabinet in the available space.

Typical PROSPECTOR 'rule'IF: The igneous rocks in the region have a fine to medium grain sizeTHEN: they have a porphyritic texture

10


Terminology+Problem Solving Heuristics=?Terminology of a specialist domain, and to some extent the details of the problem-solving heuristics and that of the meta rules, reflect the underlying structure of the domain.

This structure allows the members of the domain community to develop new ideas, to challenge existing wisdom, to disseminate and to learn from each other. In effect, the underlying structure provides a cohesive framework for the domain community to function as a whole.

The above two statements are of a philosophical nature and as such contain some speculations: the predication of the structure, that helps in the evolution, revision, propagation and application of knowledge, is one such speculation.

Some AI folk talk about ontology as an overarching term to discuss how the knowledge of a domain is organised. Ontology literally means essence of being. Once this term was used mainly in theological discussions.

11


OntologyAI experts, like Tom Gruber, suggest that ‘In the context of knowledge sharing, I use the term ontology to mean a specification of a conceptualization. That is, an ontology is a description (like a formal specification of a program) of the concepts and relationships that can exist for an agent or a community of agents. This definition is consistent with the usage of ontology as set-of-concept-definitions, but more general. And it is certainly a different sense of the word than its use in philosophy. ( Cited from ‘www-ksl.stanford.edu/kst/what-is-an-

ontology.html; site visited 20 November 2001)

12


OntologyOntologies as a specification mechanismA body of formally represented knowledge is based on a conceptualization: the objects, concepts, and other entities that are assumed to exist in some area of interest and the relationships that hold among them (Genesereth & Nilsson, 1987) . A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose. Every knowledge base, knowledge-based system, or knowledge-level agent is committed to some conceptualization, explicitly or implicitly.

13


Ontology‘An ontology is an explicit specification of a conceptualization. The term is borrowed from philosophy, where an Ontology is a systematic account of Existence. For AI systems, what "exists" is that which can be represented. When the knowledge of a domain is represented in a declarative formalism, the set of objects that can be represented is called the universe of discourse. This set of objects, and the describable relationships among them, are reflected in the representational vocabulary with which a knowledge-based program represents knowledge. Thus, in the context of AI, we can describe the ontology of a program by defining a set of representational terms. In such an ontology, definitions associate the names of entities in the universe of discourse (e.g., classes, relations, functions, or other objects) with human-readable text describing what the names mean, and formal axioms that constrain the interpretation and well-formed use of these terms. Formally, an ontology is the statement of a logical theory.’ (Gruber ‘www-ksl.stanford.edu/kst/what-is-an-

ontology.html; site visited 20 November 2001; emphasis added by Khurshid Ahmad)

14

Knowledge Acquisition Interviewing Techniques for Knowledge Acquisition

The Informal or Overview Interview To familiarise the knowledge engineer with the domain

and the particular problem which the proposed expert system is intended to solve

The Focused InterviewFocused interviews are similar to ordinary "chat show"

conversations or discussions where the interviewer is interested in a topic of which the interviewee is knowledgeable.

It is normally conducted by following a pre-determined

agenda. The interviewee is initially prompted with the first topic or question, but is given a great deal of freedom of expression thereafter.

15


The Structured InterviewStructured interviews normally occur well into the

knowledge acquisition phase. They are used when information is required in much

greater depth and detail than the other techniques can offer and is more interrogative than conversational.

'Think aloud' ProtocolsA technique used by cognitive psychologists to study

the strategies with which people solve problems. Case studies are advantageous because the end results are already known so the expert should repeat the strategy he used for that problem when describing his solution.

16


– Do’s and Dont’s

It is essential to record and transcribe all the (video- or audio-taped) interviews.

Transcripts should be clearly cross-referenced to (video- or audio-tape) recorder counter numbers.

Include all the sketches, photocopies or reproductions of diagrams, tables or the like, that were referred to during the interview(s).

Once completed a copy should be sent to the interviewee for comments, corrections and criticism. There is always the possibility of misunderstanding by the knowledge engineer when interpreting a statement or explanation.

By involving the expert in validating his or her own transcript it reduces the chance of erroneous information appearing in the prototype's knowledge base.

17

Knowledge Acquisition Tasks performed by a knowledge engineer

Domain Terminology

Salient domain features

ReviseLearn

Scope of the problem

Knowledge SourcesOutline Constrain

Problem-solving tasks

Domain objectsSpecify Verify

Paper Knowledge Base

Rules and HeuristicsProduce Validate

Overview Interview

Focussed Interviews Literature Review

Structured Interview

Rule Animation

Objectives Revision PhaseDiscovery Phase Technique Used

Consult Textbooks

18

Knowledge Acquisition PLAIM – A Case Study in Interview-based KA

Background Project PLAIM (Platform Lifetime Assessment through Analysis,

Inspection and Maintenance) was sponsored by the European Union during 1988-89. The project had two major objectives: first to collate, analyze and archive the inspection and maintenance related data. And, the second aim is to establish a computer program which will

(a) allow access, indeed guide the user to the appropriate data (or data files); (b) provide an 'intelligent' interface to mathematical models, industry-standard

simulation programs and empirical equations: (this intelligence will help a (novice) end-user to run simulation programs and interpret output provided by the programs); and

(c) acquire, formalise and disseminate the experiential and hitherto undocumented

knowledge of inspecting and maintaining off-shore structures.Ahmad, K., Langdon, A. & Frieze, P. (1991). An Expert System for Offshore Inspection and Maintenance. Computers and Structures, Volume 49, pp.143-159.

19


Interviews A total of three knowledge elicitation interviews

were conducted lasting over 5 hours and covering a broad range of topics relevant to the target problem

The first interview provided the overviewThe second being much more focused on domain

description and terminology. The third interview was the only formally

conducted, structured interview.

Ahmad, K., Langdon, A. & Frieze, P. (1991). An Expert System for Offshore Inspection and Maintenance. Computers and Structures, Volume 49, pp.143-159.

20


Interviews Regular prototype revision meetings were

conducted in a similar interrogative style inspired by a demonstration of the prototype and review of the current knowledge base.

All but one of the interviews were recorded using a video-cassette recorder; all were transcribed and, where considered useful, the transcripts were sent to or discussed with the interviewee.

21


InterviewsInterviewee Subjects Covered Interview

TechniqueDepartmental Manager, AME Ltd

Overview and explanation of idea behind PLAIM

Overview Interview

How an expert system is expected to fit in and what it was expected to do.

(followed by structured interviews at prototype demonstrations)

Departmental Manager, AME Ltd.

General introduction to terminology, design practice;

Focused

design for fatigue, classification of members, nodes, joint types, construction, practice, welding and fabrication.

Think aloud

Senior Structural Engineer, UK Offshore Operator

Current inspection, repair and maintenance. Assessment of AME proposed approach to IRM; Opinion of where expert systems would be useful generally and specifically to the operator practice - .

Structured

22


Overview Interview As indicated above, the overview

interview requires the preparation of a well targeted set of questions. The interviewee, the PLAIM project manager, was video taped and a transcript of his interview was produced. The interview began with a discussion of a 'flow chart' for conducting fatigue analysis of offshore structures.

23


Overview Interview The interviewer, who already had access to a variety of

contract documents related to PLAIM, asked the expert to explain the 'flow chart'. This led to the following set of well focused questions:

Please outline algorithms, data input and output, data requirementsWhat sort of knowledge and expertise is expected to be included in this prototype?Please give your view on judgments on accuracy and calibration with real data?How do you tell from residual strength and reliability index the lifetime of the structure or cracked joint? i.e. how long before the crack causes failure? In relation to the flow diagram, what is current practice and who currently carries out each of the jobs?What is the expertise involved? Who would be the target user of the prototype?What changes in data, apart from the loading conditions, should the user be interrogated or the system should look for? Please suggest further information sources.

24


Overview Interview The result of the overview interview led to

the identification of the broad scope of the project and in cataloguing important technical documentation as textual knowledge sources. The preparation of the questionnaire for the interview helped the knowledge engineer to learn much about the expert's impression of the problem and his understanding of how an expert system could be applied. Some key phrases of the domain terminology were also introduced and explained.

25


Overview Interview A number of knowledge

sources were identified by the domain experts ranging from research papers in learned journals to textbooks and repair and maintenance manual.

26


Focused InterviewThis purpose of this interview was to cover two broad topics. Firstly, to describe a typical oil production platform and secondly to outline fatigue damage design, analysis and repair practices. The help of a second domain expert, who has hands-on experience of designing such structures, was enlisted His reply comprised the following topics (The numbers on the right are video-recorder counters:

000 Major Components of a Typical Platform (Example 1)063 Example 2 - A Barge Launched Jacket125 Fatigue Problem Areas140 Pile Sleeves 157 Nodes170 Importance of Various Members in a Jacket222 Scour problems254 Anodes and Corrosion Protection273 Defects313 Fatigue Analysis: Procedure and Calculations357 Wave Data

27


Focused Interview- Fragment of the Tape000 Major components of a Typical rig (Example 1)

The diagram shows the topside, consisting of the cellar deck to support the drilling rig, accommodation module, helideck etc. Also shown are the flare boom and other crane booms. The jacket supports the topside fixing it securely to the sea-bed above the level of the highest waves likely to be encountered in the North Sea. Piles are driven through guides in the legs of the jacket into the bed rock to ensure the rig position is solid. As the jacket structure is a group of frames made up of tubular steel sections and linked together by other frames, a method of identifying individual members and nodes at which groups of members coincide is required. The convention used on engineering drawings to identify the frame structure in plan view at each level or staging is shown below. This particular jacket was lifted into place using a crane.

1 2 3

B

A

Topside

Jacket

Cellar Deck

Sea bed

Sea level

Piles

GRID SYSTEM

Rows

Faces

28


Focused Interview- Fragment of the Tape015 The isometric view (below) of the same jacket shows in more detail aspects of the frame structure the type of loading experienced and typical trouble spots. The increasing diameter of the leg is so that it is strong enough to be able to take the increasing axial load at the lower levels. When a wave hits the platform it causes an overturning moment which in turn causes an axial load in the leg. This is resisted by the piles, but in this example the eccentricity of the load due to the leg shape causes flexure in the short stubby diagonal braces and causes fatigue problems in their corresponding node joints. Other crossed-diagonal members also experience fatigue due to this sort of flexure but not to the same degree.

increasing leg diameter

conductor frame

WAVE

Short stubby members

29


Focused Interview- Fragment of the Tape – Domain Objects

OBJECT ATTRIBUTES

rig or platform topsides

part of platform

cellar_deck part of platform

jacket part of platform

sea-bed piles part of jacketattached_to (leg 1,2,3,4) ...number_of_guidessleeve_type.

member part of jacketpart of level frametype of (leg,brace,diagonal,horizontal ...)

30


Focused Interview- Fragment of the Tape – Domain Objects

The domain objects shown above encompass:1. Names of entities;2. Classes of entities;3. Functions that return values of the

attributes of the entities;4. Predicates that show relationship between

entities.

31


Focused Interview- Fragment of the Tape – Rules from the tape fragments –Counter #000

rule 1if: jacket is barge launchedthen: jacket will have extra structural members included purely for transportation and launching which become redundant once it is placed on the sea bed.rule 2if: a wave strikes the jacketthen: the diagonal members will take the load/shear force.rule 3if: a jacket has sloping legsthen: any crossed diagonal members at the lowest level will flex and cause fatigue in their corresponding node joints.

32


Focused Interview- Fragment of the Tape – Rules and explanations from the tape fragments –

Counter #000rule 1if: jacket is barge launchedthen: jacket will have extra structural members included purely for transportation and launching which become redundant once it is placed on the sea bed.because:it is a big structure and two different types of

loading conditions need to be designed for if it is not going to fail under either.rule 2if: a wave strikes the jacketthen: the diagonal members will take the load/shear force.because:the wave causes an overturning moment which will effectively tension one side of the jacket and compress the other side. In resisting this movement the diagonals take much of the load.

33


Focused Interview- Correction to the tape transcriptCorrections to the transcript

The interview transcript was sent to the expert for comments and criticism and was duly returned with corrections. It is not easy to classify the comments, except that the expert imposed constraints on his statements or expanded on others. Some examples below are presented to highlight the point we have just made. The amendments are shown in italics: 000 Major components of a Typical rig (Example 1)The diagram shows the topsides, consisting of the cellar deck to support the drilling rig, accommodation module, helideck etc. Also shown is the flare boom and other crane booms. The jacket supports the topsides fixing it securely to the sea-bed above the level of the highest waves likely to be encountered in the North Sea at the site. Piles are driven through guides attached to the legs of the jacket into the sea be to ensure the rig position is

34


A knowledge engineer must be

1. Familiar with the applications domain, its terminology and conceptual structure (or ontology)

2. Able to map the domain knowledge onto a representation schema

3. Map the representation onto a suitable inference strategy.