The domain expert is the person with the expertise the expert system is trying to capture.

10.5.1.1 Collect the knowledge domain

The knowledge domain pertaining to high school solid geometry is collected from books [7]. The collected knowledge is classified as follows:

Conceptual knowledge: In this application, some concepts of this domain are considered, such as point, segment, line, plane, triangle, quadrilateral, parallelogram, square, triangular pyramid, and quadrilateral pyramid. Each concept has a structure and behaviors in itself.

Relational knowledge between concepts: Some relations in this knowledge domain are as Table 10.1.

Table 10.1. Relations between concepts of solid geometry.

Functional knowledge: There are some functions for this knowledge domain as Table 10.2.

Table 10.2. Some functions of solid geometry.

Rules of the knowledge domain: Some of the collection rules of the knowledge domain are given as follows:

Rule 1: If a line is perpendicular to a plane, then that line is perpendicular to all lines on that plane.

{ a,b:Linea⊥Plane(P)b⊂Plane(P)⇒a⊥b

Rule 2: If a line a does not belong to a plane (P) and it is also parallel to another line in (P), then line a is parallel to the plane (P).

{a,b:Linea⊄Plane(P)b⊂Plane(P)a//b⇒a//Plane(P)

Rule 3: If a point belongs to two planes, then it belongs to the intersection line of those planes.

{K:PointK∈Plane(P) K∈Plane(Q)⇒K∈Plane( P)∩Plane(Q)

Rules of the knowledge domain: Some of the collection rules of the knowledge domain are given as follows:

Some of rules for generating new objects:

  Rule 4: Properties of the intersection line between two planes.

{M∈Plane(P)∩Plane(Q)a⊂Plane(P )b⊂Plane(Q)a//b⇒{Letd=IntersectLine(P,Q):d//a,d//b

  Rule 5: In a triangle ABC, a point M belongs to AB, a point N belongs to BC. A new point P is generated with P=CM intersect AN, which means P belongs to CM and P belongs to AN.

{Triangle(ABC)M,N:PointM∈ABN∈BC⇒{LetP:Point, andP=IntersectPoint(CM,AN):P∈ CM,P∈AN

Some kinds of exercises from high school solid geometry in Ref. [7] are considered. Those kinds are:

Prove a relation between two objects.

Compute the value of a function related to objects.

Functions return a value;

Functions return an object.

5.4 Knowledge Acquisition

Knowledge acquisition refers to the process of extracting, structuring, and organizing domain knowledge from domain experts into a program. A knowledge engineer is an expert in AI language and knowledge representation who investigates a particular problem domain, determines important concepts, and creates correct and efficient representations of the objects and relations in the domain.

Capturing domain knowledge of a problem domain is the first step in building an expert system. In general, the knowledge acquisition process through a knowledge engineer can be divided into four phases:

Planning: The goal is to understand the problem domain, identify domain experts, analyze various knowledge acquisition techniques, and design proper procedures.

Knowledge extraction: The goal is to extract knowledge from experts by applying various knowledge acquisition techniques.

Knowledge analysis: The outputs from the knowledge extraction phase, such as concepts and heuristics, are analyzed and represented in formal forms, including heuristic rules, frames, objects and relations, semantic networks, classification schemes, neural networks, and fuzzy logic sets. These representations are used in implementing a prototype expert system.

Knowledge verification: The prototype expert system containing the formal representation of the heuristics and concepts is verified by the experts. If the knowledge base is incomplete or insufficient to solve the problem, alternative knowledge acquisition techniques may be applied, and additional knowledge acquisition process may be conducted.

Many knowledge acquisition techniques and tools have been developed with various strengths and limitations. Commonly used techniques include interviewing, protocol analysis, repertory grid analysis, and observation.

Interviewing is a technique used for eliciting knowledge from domain experts and design requirements. The basic form involves free-form or unstructured question–answer sessions between the domain expert and the knowledge engineer. The major problem of this approach results from the inability of domain experts to explicitly describe their reasoning process and the biases involved in human reasoning. A more effective form of interviewing is called structured interviewing, which is goal-oriented and directed by a series of clearly stated goals. Here, experts either fill out a set of carefully designed questionnaire cards or answer questions carefully designed based on an established domain model of the problem-solving process. This technique reduces the interpretation problem inherent in the unstructured interviewing as well as the distortion caused by domain expert subjectivity.

As an example, let's look at the interviewing process used in constructing GTE's COMPASS system (Prerau, 1990). COMPASS is an expert system that examines error messages derived from a telephone switch's self-test routines and suggests running of additional tests or replacing a particular component. The interviewing process in building COMPASS has an elicit–document–test cycle as follows:

Elicit knowledge from an expert.

Document the elicited knowledge in rules and procedures.

Test the new knowledge using a set of data:

Have the expert analyze a new set of data.

Analyze the same set of data using the documented knowledge.

Compare the two results.

If the results differ, find the rules or procedures that lead to the discrepancy and return to step 1 to elicit more knowledge to resolve the problem.

Protocol analysis is another technique of data analysis originated in clinical psychology. In this approach, an expert is asked to talk about his or her thinking process while solving a given problem. The difference from interviewing is that experts find it much easier to talk about specific problem instances than to talk in abstract terms. The problem-solving process being described is then analyzed to produce a structured model of the expert's knowledge, including objects of significance, important attributes of the objects, relationships among the objects, and inferences drawn from the relationships. The advantage of protocol analysis is the accurate description of the specific actions and rationales as the expert solves the problem.

Repertory grid analysis investigates the expert's mental model of the problem domain. First, the expert is asked to identify the objects in the problem domain and the traits that differentiate them. Then, a rating grid is formed by rating the objects according to the traits.

Observation involves observing how an expert solves a problem. It enables the expert to continuously work on a problem without being interrupted while the knowledge is obtained. A major limitation of this technique is that the underlying reasoning process of an expert may not be revealed in his or her actions.

Knowledge acquisition is a difficult and time-consuming task that often becomes the bottleneck in expert system development (Hayes-Roth et al., 1983). Various techniques have been developed to automate the process by using domaintailored environments containing well-defined domain knowledge and specific problem-solving methods (Rothenfluh et al., 1996). For example, OPAL is a program that expedites knowledge elicitation for the expert system ONCOCIN (Shortliffe et al., 1981) that constructs treatment plans for cancer patients. OPAL uses a model of the cancer domain to acquire knowledge directly from an expert. OPAL's domain model has four main aspects: entities and relationships, domain actions, domain predicate, and procedural knowledge. Based on its domain knowledge, OPAL can acquire more knowledge from a human expert and translate it into executable code, such as production rules and finite state tables. Following OPAL, more general-purpose systems called PROTEGE and PROTEGE-II were developed (Musen, 1989). PROTEGE-II contains tools for creating domain ontology and generating OPAL-like knowledge acquisition programs for particular applications PROTEGE-II is a general tool developed by abstraction from a successful application, similar to the process from MYCIN to EMYCIN.

Another example of automated knowledge acquisition is the SALT system (Marcus and McDermott, 1989) associated with an expert system called Vertical Transportation (VT) for designing custom-design elevator systems. SALT assumes a propose-and-revise strategy in the knowledge acquisition process. Domain knowledge is seen as performing one of three roles: (1) proposing an extension to the current design, (2) identifying constraints upon design extension, and (3) repairing constraint violation. SALT automatically acquires these kinds of knowledge by interacting with an expert and then compiles the knowledge into production rules to generate a domain-specific knowledge base. SALT retains the original knowledge in a declarative form as a dependency network, which can be updated and recompiled as necessary.

To build a knowledge base, the knowledge can be either captured through knowledge engineers or be generated automatically by machine learning techniques. For example, rules in rule-based expert systems may be obtained through a knowledge acquisition process involving domain experts and knowledge engineers or may be generated automatically from examples using decision-tree learning algorithms. Casebased reasoning is another example of automated knowledge extraction in which the expert system searches its collection of past cases, finds the ones that are similar to the new problem, and applies the corresponding solutions to the new one. The whole process is fully automatic. An expert system of this type can be built quickly and maintained easily by adding and deleting cases. Automatic knowledge generation is especially good when a large set of examples exist or when no domain expert exists.

In addition to generating knowledge automatically, machine learning methods have also been used to improve the performance of the inference engines by learning the importance of individual rules and better control in reasoning.

Mid-Term Goals

•

Incorporating Domain Knowledge into the Requirements Capabilities

Simple models of frequently used domains will be developed. The first model will be for a fairly narrow domain or application (e.g., simple classification programs). The models will supply the knowledge base that will be used for domain-specific support of the requirements capabilities.

As domain models are added, the requirements capabilities will be augmented to take advantage of the new knowledge. For example, domain knowledge will be used by the intelligent editor/manager to retrieve application-specific, previously described, or generic requirements descriptions from the knowledge base that match the user's current needs. These descriptions will serve as useful models to be compared to the specified requirements to check consistency and completeness. By employing more sophisticated techniques such as symbolic evaluation of the requirements language and some inductive inference, more application-specific inconsistencies can be inferred.

An Automated Structured Walk-Through System for Requirements Engineering

Many of the capabilities described above will be combined in a script (process description) and applied with a form of symbolic interpretation. For example, a structured walk-through tool based on a fault model representation and on a requirements language will aid an expert systems analyst to keep track of loose ends and problem areas. It accepts requirements as input, together with other management information (e.g., who should approve it, who heads up the prime user groups, who heads the implementor group). Such a tool will be able to perform some useful background analysis for missing or incompatible requirements.

Requirements Transformation and Refinement

At this stage, techniques from knowledge-based program synthesis could be extended to allow transformations of requirements. For example, if a program is set up for monthly reports, and weekly reports are required, the knowledge base could supply descriptions of the necesary changes to make. Depending on the level of difficulty, the facet might either suggest and remind the user of the kinds of changes, or actually carry out the transformations automatically. Requirements refinement is the other type of transformation. In this case the requirements are brought through successively more detailed stages until they reach the level of executability. This type of decomposition and filling in of detail is exactly what happens in program refinement discussed in the development facet (Section 3.3.3), but higher-level knowledge is needed here. The facet suggests alternative refinements and decompositions. The transformations may be manual, interactive, or automated as fits the situation.

A Requirements Tutor

Tutoring capabilities at the requirements level will help new members of the software design team to start contributing sooner. For example, tutoring will help them learn to use the software assistant's capabilities. It also will help them to understand the current configuration of requirements specifications and the previous decisions that provide the context for new requirements decisions.

2.3 What is knowledge work?

The term knowledge work is generally attributed to Peter Drucker in his 1959 book “Landmarks of Tomorrow.” It typically refers to work done by professionals and experts who are said to “think for a living.” Knowledge work is part of virtually every organization of any size. Fig. 2.1 shows examples of knowledge work domains. In many organizations, the need for knowledge work is core to the mission: a medical practice depends on doctors and nurses and an electronics company relies on engineers, scientists, and technical salespeople. In others, such as a distribution business, even if knowledge work is not at the core, it's a necessary support—management and accounting are two professions that are seen in most organizations.

Most of us think about domain knowledge (or expertise) as the central requirement for knowledge work: med school for doctors, law school for attorneys, and university training for most other professions. Domain knowledge is certainly a requirement for knowledge work. These skills are specific to the domain in which they are practiced. They are difficult to acquire—expensive, time-consuming, and requiring high cognitive skills. And the initial acquisition is only the start. Domain knowledge takes years of experience to master (Fig. 2.2). Malcom Gladwell famously marked the time to acquire expertise at 10,000 hours of working in the core of the field, something that takes at least a decade for most people [35].

It has become a kind of truism in the study of creativity that you can’t be creating anything with less than 10 years of technical-knowledge immersion in a particular field. Whether it's mathematics or music, it takes that long.

Mihaly Csikszentmihalyi [36]

Start by assuming that people are not the problem

Approach every problem assuming knowledge staff are able and willing to do the right thing. Why? These people have worked hard to get where they are. For example, engineers got through university where the dropout rate is about 50% [37], compared to Marine Corp boot camp training with a dropout rate under 15% [38]. The above assumption is almost always right and demands leaders evaluate themselves honestly rather than blaming others. So, hold the assumption that the system is the problem until the facts demand another conclusion.

Even though domains vary, knowledge work of all stripes shares common skills, especially when the work is done in a team. Five of the most common shared skills, shown in Fig. 2.3, are as follows:

Experimental thinking: being able to create open-minded hypotheses and measure outcomes to identify good alternatives.

Teamwork and collaboration: the social skills to work with colleagues to accomplish a shared goal.

Problem solving: diligently understand problems, find root causes, and create effective solutions.

Critical thinking: evaluate a chain of logic to validate sound reasoning. Prized in management reviews where leaders, people of high general acumen, evaluate the work of a domain expert against a broad range of characteristics.

Creating and inventing: developing novel viewpoints or solutions.

2.2.3 Energy Semantic Network

It is essential to provide domain knowledge structure with rule-based reasoning to be able to support decisions related to design and operation of the underlying energy production chain. For example, for given equipment, what are the energy sources used with respect to operation and/or behavior. This is essential to link process models with system models. There are several knowledge tools that are available and can support knowledge structuring and management.

A dynamic knowledge structure is established, which is called ESN [3]. ESN is an essential methodology to design an efficient SEG. ESN encodes the knowledge of a wide spectrum of expertise to be available for energy designer. For a complex building with complicated energy demands, the energy conservation measures and sources and loads design parameters are a challenge to identify.

ESN should be open, dynamic, and minimal. Open means its standard structure allows the incorporation of new components. Dynamic means its ability to include new properties of existent components. Minimal is to reduce the computational burden during the simulation and evaluation process. ESN aggregates metadata (structural and descriptive) and data (profile, measured, and statistical) regarding both thermal technologies of building envelope materials and the energy sources technologies, and arranges them in knowledge layers. Moreover, inference mechanism is used to extract decisions and conclusions by navigating through knowledge layers based on the supplied desired requirement.

ESN is the mapping tool between the problem domain and the design domain as shown in Fig. 4. The inputs to ESN are the characters of the site to implement the SEG (type, size, capabilities, activities, governmental constrains, environmental constrains, and customer and stockholder constrains). The output of ESN is the possible scenarios of energy design and energy conservation measures, in addition to a list of KPIs with high potential to be affected by the design structure. The structure of ESN is a collection of nodes representing the classes of both the problem domain instants, objects to the design domain instants, and objects with relation links encode the relation between the classes and objects. To improve the presentation of ESN, a fuzzy inference mechanism will be added for better presentation of uncertainty about both analytic and black-box models. An example of ESN for buildings is shown in Fig. 5.

12.1.2.1 The case-based reasoning process

CBR can be considered as a machine, which reads a new unsolved case, matches it with the many solved cases that have been stored in the machine memory, and retrieves the most similar solved case. Therefore, the output of the machine is a proposed solution to the new unsolved case. A simple schematic for the CBR process is shown in Fig. 12.2.

Cases are used to represent the domain knowledge of a case-based system. A case refers to specific experience or to knowledge tied to specific situation that is worth remembering for future use. So cases in the knowledge base represent a collection of specific experienced, captured, and learned situations for the application domain (Aamodt and Plaza, 1994; Kolodner, 1993). Each case consists of three main parts (Leake, 1996):

Description of the situation/problem: This describes the specific circumstances, conditions of a situation, and state of the environment when this particular case is recorded.

Solution: This provides knowledge of how the problem in the description was solved or treated in a particular instance.

Outcome: This describes the final result or consequence, and feedback gained from following the proposed solution.

12.10.3 Keep it simple

The solving team, typically those with high domain knowledge, creates transparency when they lay out their approach to solving the problem. Of course, it is difficult to explain new insights to those with less domain knowledge: it's hard to make something complicated easy to understand. It's hard, but valuable, something like when a doctor explains a malady to a nonmedically trained patient. The doctor may need to read 30 pages from a medical textbook, but the patient needs only enough information to be confident the diagnosis is accurate and make treatment decisions. As I frequently say to domain experts, “You’re the doctor; think of your coworkers with less domain knowledge as the patients.”

Summary

Let us now review the basic theme of this paper, overstating slightly for the sake of clarity:

The primary conclusion of our initial studies is that domain knowledge plays a critical role in the programming process. This role is so important that automatic programming systems without considerable domain knowledge will be neither usable by non-computer scientists nor feasible for non-trivial domains. Therefore, a primary goal of automatic programming research should be to develop models of programming which characterize the interaction of domain knowledge and programming knowledge. The best way to achieve this goal is to develop models of programming for specific non-trivial domains, and to test these models by building systems for real users who want real programs that can be run on real data. If these models clearly separate and characterize the roles played by domain and programming knowledge, then we will have the foundation for developing broader models of programming.

3.3 Similaristic reasoning

More often than not there is no sufficient domain knowledge available to understand and manage a particular clinical problem, e.g. a patient's suffering. In such circumstances knowledge of another type is needed. For example, the data at hand may indicate similarities between the current problem and some previous cases that have already been successfully resolved in the past. Using such similarities to reason about, and manage, a present problem by utilizing previous experiences we will refer to as similaristic reasoning.

Similaristic reasoning is a salient characteristic of natural human problem solving. It has been known as casuistry in the history of ethics and theology, and as casuistics in the history of medicine. A sophisticated type of these similaristic methods, the so-called case-based reasoning, was born in the early 1980s. It has been attracting research interests in computer science and artificial intelligence since then. This approach will be briefly outlined in the present section to inquire into its diagnostic applicability. To this end we need some terminology, especially a concept of similarity, to be introduced first.

Goal #2: Enable Users to Exploit Domain Knowledge

New systems should enable users to capitalize on their domain knowledge and should not require large amounts of new system experience, extraneous skills, or special characteristics to perform a task. The computer system should be a tool that extends the task-relevant skill of users, rather than an obstacle that requires a special set of characteristics to master.

For some systems, enabling users to exploit domain knowledge may be a matter of removing requirements for technical aptitude or specialized skills. An accountant might have difficulty learning Pascal in order to automate routine accounting tasks, but might be able to use an electronic spreadsheet for the same purpose. Some executives will continue to resist systems that require typing skill, but they may use systems having good speech interfaces. Much of the public will avoid using library retrieval systems that require boolean logic, but may find other sorts of interfaces more acceptable. In all these cases, removing a requirement for technical aptitude or a specialized skill enables more users to exercise their domain knowledge with a system.

Other systems may enable users to exploit domain knowledge by changing the nature of the task to be accomplished. A computer need not simply automate a former way of doing things, but instead might make available to users a greater range of data and procedures than were possible formerly. Hypertext systems, for example, may allow a much richer kind of information search than is possible with ordinary books or catalogues. Computer simulations and games may lead students to acquire different knowledge in different ways compared to frame-based, text-oriented computer assisted instruction. A new programming language can lead to different solutions to problems and can cause different types of problems to be more or less easily solved. Indeed, some systems may alter tasks so dramatically that we may begin to question the essence of domain relevant knowledge for a particular task.