CHAPTER TWO
LITERATURE REVIEW
2.1. An Overview of Knowledge Based Systems
2.1.1. Introduction
Conceptualizing the basic ideas of knowledge based system is essential to understand sufficiently
the notion of KBS. So this chapter attempts to give some over view of knowledge based systems,
its merits, applicability, architecture and development phases are included. In addition in this
chapter history of coffee, its economic importance, its constraints (most important disease and
pests) are discussed.
2.1.2. Definition of knowledge base system
Knowledge based systems are a branch of artificial intelligence, which is a computer program
that attempts to replicate the reasoning processes of a human expert and it can make decisions
and recommendations and perform tasks based on user input. Artificial Intelligence is all about
how to make the system think, or act like human. The expert`s knowledge is available when the
human expert might not be and so that the knowledge can be available at all times and in many
places, as necessary. Expert systems derive their input for decision making from prompts at the
user interface, or from data files stored on the computer (Abu-Naser et al., 2008).
The primary intent of expert system technology is to realize the integration of human expertise
into computer processes. This integration not only helps to preserve the human expertise but also
allows humans to be freed from performing the more routine activities that might be associated
with interactions with a computer-based system. There exist a number of different definitions for
a knowledge based system, but in this study the definition discussed by (Brown and Pomykalski,
1995) reviewed and presented as follow because it seems more detail and create the overall
understanding of KBS definition.
An expert/knowledge based system is a computer program that is designed to mimic the decision
making ability of the decision makers/experts in a particular narrow domain of expertise. In
order to fully understand and appreciate the meaning and nature of this definition, four major
component pieces are highlighted in detail as follow.
Knowledge based system is a computer program: A computer program is a piece of software,
written by a “programmer” as a solution to some particular problem or client need. Because
knowledge based systems are software products they inherit all of the problems associated with
any piece of computer software.
Knowledge based system is designed to mimic the decision making ability: The specific task of a
knowledge based system is to be an alternative source of decision making ability for
organizations to use; instead of relying on the expertise of just one or a handful of people
qualified to make a particular decision. KBS attempts to capture the reasoning of a particular
person for a specific problem. Usually this system is designed and developed to capture the
scarce, but critical decision making that occurs in many organizations. It is often feared to be
replacements for decision makers, however, in many organizations; these systems are used to
free up the decision maker to address more complex and important issues facing the
organization.
Knowledge based system uses decision makers (experts): Webster’s dictionary
(MerriamWebster Collegiate Dictionary, 10th Edition, 1943) defines an expert as “One with the
special skill or mastery of a particular subject.” The focal point in the development of KBS is to
acquire and represent the knowledge and experience of a person(s) who have been identified as
possessing the special skill or mastery.
Knowledge based system is created to solve problems in a particular narrow domain of
expertise: Some of the most successful development efforts of KBS have been in domains that
are well scoped and have clear boundaries.
2.1.3. History of knowledge based systems
Next the history of KBS will be briefly discussed. In this discussion, its historical place within
the Artificial Intelligence area and highlight some of the early, significant of expert system
development are included. In the late 1960's to early 1970's, expert systems began to emerge as a
branch of Artificial Intelligence. The intellectual roots of expert systems can be found in the
ambitions of Artificial Intelligence to develop “thinking computers”. Domain specific knowledge
was used as a basis for the development of the first intelligent systems in various domains.
In order to discuss the history of this system a brief history of the Artificial Intelligence field is
necessary. Knowledge-based systems were the first major successful application technology to
evolve from Artificial Intelligence research. The foundations of the field of Artificial Intelligence
can be traced from many different disciplines including philosophy, mathematics, psychology,
computer engineering, and linguistics (Russell and Norvig, 1995).
The first cited work in the area of Artificial Intelligence dates back to McCulloch and Pitts
(McCulloch and Pitts, 1943) in 1943. They proposed a model of artificial neurons that mimic the
structure of the human brain; this area later became the connectionist paradigm. In the summer of
1956, McCarthy organized a two month workshop at Dartmouth and 10 leading U.S. researchers
interested in automata theory, neural networks, and the study of intelligence were invited. Two
researchers from Carnegie Tech (now known as Carnegie Mellon University), Newell and Simon
were the focus of the workshop due to their reasoning program known as the Logic Theorist
(LT). Simon claimed “we have invented a computer program capable of thinking none
numerically, and thereby solved the venerable mind body problem.” An interesting note is that a
paper on the use of LT to prove the theorems was rejected by The Journal of Symbolic Logic.
The Dartmouth workshop accomplished two major outcomes. First, it served as a forum to
introduce the leading researchers to each other; for the next twenty years, the field of AI would
be dominated by these ten individuals, their students, and colleagues at MIT, CMU, Stanford,
and IBM. The second major accomplishment of the workshop and a more lasting one was an
agreement to adopt McCarthy’s new name for the field: Artificial Intelligence (Russell and
Norvig, 1995).
The work of Newell and Simon is the first documented work using the symbolic programming
paradigm of AI. Their work on LT led them to develop another program known as general
Problem Solver (GPS). The success of GPS was not as widely heralded however because of the
limited class of problems that it could solve. GPS was designed from the start to imitate human
problem solving protocols regardless of the information contained in the domain.
Researchers then took the opposite approach in the development of the DENDRAL program
(Lindsay et al., 1980). They applied the knowledge of analytical chemists to infer the molecular
structure from the information provided by a mass spectrometer. DENDRAL holds a significant
place in the history of expert/knowledge based systems because it was the first system to use the
expertise of human problem solvers and translate that knowledge into a large numbers of special
purpose rules, known as a rule based system (Pomykalski et al., 1999).
2.1.4. Early significant of expert system
The work on DENDRAL leads to many others successful applications of this new technology
known as expert systems. Feigenbaum and others at Stanford began the Heuristic Programming
Project (HPP) to investigate other problem domains that could benefit from this new technology.
The next major effort was in the area of medical diagnosis. Buchanan and Shortlife developed
MYCIN to diagnose blood infections (Shortliffe, 1976; Buchanan and Shortliffe, 1985). Using
about 450 rules, MYCIN was able to perform as well as some experts, and considerably better
than some junior doctors were. MYCIN is one of the most widely known of all expert system
applications developed. However, MYCIN is significant to the history of expert/knowledgebased
systems for two particular reasons. First, unlike DENDRAL, which used a model of a particular
molecule as the basis for its reasoning, MYCIN was constructed from interviews with various
doctors in the particular domain. Therefore, MYCIN contains a number of heuristic rules that are
used by physicians in the identification of certain infections. The second major contribution of
MYCIN was the later development of EMYCIN (Empty MYCIN). EMYCIN was the first
expert/knowledge-based system shell. It took approximately 20 years to develop the MYCIN
program. The researchers realized that if expert systems were to become a viable problem
solving technique this development time must be cut. In an effort to do reduce the time to
develop an expert system the researchers developed EMYCIN by taking all of the rules out of
17 the system and leaving just an empty “shell” in which other developers in other domains
could then just “plug-in” their new knowledge base (Pomykalski et al., 1999).
There were other significant expert system applications that were also developed in the early
days of expert systems. These systems include PUFF, which used EMYCIN in the domain of
pulmonary disorders, DELTA/CATS, which was developed at General Electric Company to
assist railroad personnel in the maintenance of GE’s diesel electric locomotives (Ignizio, 1991).
Also at this time, researchers at CMU developed the first truly successful commercial application
of expert systems. The system, developed for Digital Equipment Corporation (DEC), was used
for computer configuration and known as XCON (R1). XCON, originally titled R1, was
developed by John McDermott at CMU for aiding in the configuration of VAX and PDP-11
computer systems at DEC. There exist an enormous number of configurations for VAX and
PDP-11 computer system DEC attempts to configure each system to meet specific customer
needs. XCON was originally developed as a 500-rule prototype that examined the specific needs
of the customer and decided the exact configuration of components necessary to meet the
customer requirements. In particular, XCON’s function was to select and arrange the
components of a computer systems including: the CPU, the memory, the terminals, the tape and
disk drives, and any other peripherals attached to the system. XCON works with a large database
of computer components and its rules determine what makes a complete order (Pomykalski et al.,
1999).
2.1.5. Components of a knowledge base system
The three major components of Expert system are: Knowledge base , inference engine , and user
interface. For better interaction with users an ES should preferably contain an explanation
subsystem component or justifier. The knowledge engineer converts experts’ knowledge into a
form that can be manipulated by computer software. This knowledge is then stored in a
knowledge base. The user provides information about a specific problem via a user interface.
The inference engine uses the knowledge provided to come to some conclusions and/or give
advice about the specific problem (Warren, 1999).
[Link]. The knowledge base
The knowledge base is the core component of any expert system. It contains knowledge acquired
from the domain expert (Khan et al., 2008). In rule based expert systems the knowledge base is
18 modeled to include two components: rule base of heuristic rules that are used to solve specific
problems in a particular domain, and facts. A rule is a conditional statement that links given
conditions to actions or outcomes. A knowledge base can combine the knowledge of multiple
human experts (Abraham, 2005). It represents the repository of knowledge for specific and
narrow domain for the knowledge based system. So, the most important part of knowledge based
system is the knowledge base and the power of any knowledge based system and Expert System
inherently in the adequate and integration of knowledge representation forms used for the
particular domain. In this sense, the most important phase, in building knowledge based system,
is the building of the knowledge base; this process is part of knowledge engineering which is an
important field at present century (Owaied and Moh’d Qasem, 2010).
[Link]. The inference engine
The inference engine is the component that provides a methodology for reasoning and
formulating conclusions. The inference engine provides directions about how to use the system’s
knowledge to solve problems (Ayman Al Ahmar, 2010). The purpose of the inference engine is
to seek information and relationships from the knowledge base and to provide answers,
predictions, and suggestions in the way a human expert would. The inference engine must find
the right facts, interpretations, and rules and assembles them correctly. There are two broad kinds
of inference engines used in rule-based systems: forward chaining and backward chaining
systems. A rule-based system consists of if-then rules, a bunch of facts, and an interpreter
controlling the application of the rules, given the facts. These if-then rule statements are used to
formulate the conditional statements that comprise the complete knowledge base. A single ifthen
rule assumes the form ‘if x is A then y is B’ and the if-part of the rule ‘x is A ’is called the
antecedent or premise, while the then-part of the rule ‘y is B’ is called the consequent or
conclusion.
Forward chaining starts with the facts and works forward to the conclusions. In a forward
chaining system, the initial facts are processed first, and keep using the rules to draw new
conclusions given those facts.
Backward chaining is the process of starting with conclusions and working backward to the
supporting facts. In a backward chaining system, the hypothesis (or solution/goal) we are trying
to reach is processed first, and keep looking for rules that would allow concluding that
hypothesis. As the processing progresses, new sub-goals are also set for validation. Forward
chaining systems are primarily data driven, while backward chaining systems are goal-driven
(Abraham, 2005).
To arrive at conclusions about a problem, the inference engine must search for a solution in an
efficient and effective manner. Forward chaining allows the knowledge engineer to use rules to
develop information from a limited set of initial data. Backward chaining starts with a goal and
works backward to check data and constraints to determine if the goal is feasible. In backward
chaining, the inference engine identifies one or more hypotheses and begins searching for rules
that contain the hypothesis as a consequent (i.e., concluding that the hypothesis is correct). For
any such rule found, the inference engine tests the truth of the predicates (the if-clauses) of the
rule. If the predicates are true, then the hypothesis is confirmed, and the inference engine moves
on to the next hypothesis. If the truth of a predicate is unknown, the hypothesis that the unknown
predicate is true is added to the inference engine’s list of hypotheses to check. This initiates a
search for rules with the new hypotheses as a consequent. This process forms a chain, linking
rule predicates backward to consequents. This strategy is often used in selection or classification
applications in which one item is to be selected from a fixed set of items (Abraham, 2005).
Both strategies will ultimately lead to a conclusion, but the efficiency of the search is dependent
on the nature of the problem faced. A problem with few premises and many conclusions would
generally be better off with a forward chaining strategy whereas a problem with many premises
and few conclusions would normally do better with a backward chaining strategy. There are
instances in which it would be wise to employ a combination of the two strategies (Ignizio,
1991). To determine when and where this is necessary, it is useful to structure the knowledge
engineering process by diagramming system interdependencies, flow, and function (Plant and
Stone, 1991 and Warren, 1999).
[Link]. The explanation facility
Explanation subsystem helps in justification of ES conclusions by tracing conclusions to their
sources and showing how was a certain conclusion reached. One of the key characteristics of an
expert system is the explanation facility. With this capability, an expert system can explain how
it arrives at its conclusions. The user can ask questions dealing with the what, how, and why
aspects of a problem. The expert system will then provide the user with a trace of the
consultation process, pointing out the key reasoning paths followed during the consultation.
Sometimes an expert system is required to solve other problems, possibly not directly related to
the specific problem at hand, but whose solution will have an impact on the total problem
solving process. The explanation facility helps the expert system to clarify and justify why such a
digression might be needed. (Ayman Al Ahmar, 2010). The explanation facility allows a user to
understand how the expert system arrived at certain results (Abraham, 2005).
[Link]. The user interface
The User Interface is one of the major components of an expert system which allows
bidirectional communication between system and user is considered to be a critical part of the
success of an expert system. The user interface consists of all screens of interaction between the
user and the ES (Ayman Al Ahmar, 2010). The purpose of the user interface is to ease use of the
expert system for developers, users, and administrators (Abraham, 2005).
The input/output interface defines the way in which the expert system interacts with the user and
other systems. Interfaces are usually graphical with screen displays, windowing, and mouse
control. They receive input from the user and display output to the user. Some systems use
natural language front ends that accept English-like responses but most use a graphical user
interface (GUI) with a mouse device to allow the user to choose from selections in dialog boxes
and menu bars (Warren, 1999). All these components come together and form knowledge base
system architecture. The following figure, taken from Angeli (2010), displays the architecture
commonly associated with knowledge based system.
2.1.6. Knowledge base system development procedures
Steps in the expert systems development process include determining the actual requirements,
knowledge acquisition, constructing expert system components, implementing results, and
maintenance. In order to develop an expert system the knowledge has to be extracted from
domain expert. This knowledge is then converted into a computer program. Knowledge Engineer
performs the task of extracting the knowledge from the domain expert. Rule based expert
systems are the most commonly known type of knowledge based systems. The knowledge of the
expert(s) is stored in his/her mind in a very abstract way. Also every expert may not be familiar
with knowledge-based systems terminology and the way to develop an intelligent system. The
Knowledge Engineer (KE) is responsible person to acquire, transfer and represent the experts’
knowledge in form of computer system. People, Experts, Teachers, Students and Testers are the
main users’ groups of knowledge based systems (Sajja and Akerkar, 2010).
[Link]. Knowledge acquisition
The first task in the development of knowledge base is knowledge acquisition. Knowledge
acquisition is considered as one of the most important phases in the expert system development
life cycle. Knowledge acquisition is to obtain facts and rules from the domain expert so that the
system can draw expert level conclusions. The process of knowledge acquisition is difficult
especially in case if the knowledge engineer is unfamiliar with the domain. Knowledge
acquisition is crucial for the success of an expert system and regarded as a bottleneck in the
development of an expert system. The main reason for this bottleneck is communication
difficulties between the knowledge engineer and the domain expert.
There exist several methods to extract human knowledge; some commonly used approaches of
knowledge acquisition include interviews, questionnaires, record reviews and observation to
acquire factual and explicit knowledge (Sajja and Akerkar, 2010). Knowledge acquisition is
comprised of two tasks: knowledge elicitation and knowledge representation. In knowledge
elicitation, domain knowledge is obtained through various means including interviews with
experts and book and journal references. In knowledge representation, the elicited knowledge is
converted to a form for efficient computer manipulation (Nikolopoulos, 1997).
Knowledge in its primary form can be obtained from four sources: literature, human specialists,
existing models, and examples (Sell, 1985). Methods of collecting, organizing, and formalizing
knowledge are many and vary widely depending on the source. When knowledge is extracted
from human specialists, the acquisition process is often called knowledge elicitation. The job of
knowledge elicitation from human experts can be very difficult due to the inexplicit nature of
human knowledge (Schmoldt and Rauscher, 1996). There is no universal agreement on which
knowledge elicitation technique to use when. It is most common to start with interviews and then
use other methods when considered useful. The knowledge engineer must be versatile and
willing to weigh the various methods in order to please the experts and elicit the most
information (Hart, 1992).
Acquisition methods or techniques are often incorporated into knowledge acquisition strategies.
These strategies usually fall into one of two categories: manual or automated. Automated
methods are driven by computer programs and may include machine learning or automated
interviews. Manual methods may include fast prototyping, evolutionary acquisition, ad hoc
methods, and expert driven strategies. Selection of a strategy by the knowledge engineer will
probably depend on human and financial resources, time availability, project complexity, and
familiarity with available methods (Warren, 1999).
[Link].1. Knowledge acquisition tools
Many techniques have been developed to help elicit knowledge from an expert. These are
referred to as knowledge elicitation or knowledge acquisition (KA) techniques. The knowledge
acquisition phase requires a significant degree of interaction between the knowledge engineer
and the specialist. During this phase, the knowledge engineer uses techniques and tools to elicit
tacit knowledge from discipline specialists. A diversity of knowledge acquisition tools is
presented in the Knowledge Acquisition Matrix (Emberey et al., 2007). The following list gives
a brief introduction to the types of techniques used for acquiring, analyzing and modeling
knowledge:
Interview is the most commonly used form of knowledge acquisition. It involves a direct dialog
between the expert and the knowledge engineer. Information is collected with the aid of
conventional instruments (e.g., tape recorders, questionnaires) and is subsequently transcribed,
analyzed, and coded. The success of an interview session is dependent on the questions asked (it
is difficult to know which questions should be asked, particularly if the interviewer is not
familiar with the domain) and the ability of the expert to articulate their knowledge. The expert
may not remember exactly how they perform a task, especially if it is one that they perform
automatically". Some interview methods are used to build a particular type of model of the task.
The model is built by the knowledge engineer based on information obtained during the
interview and then reviewed with the domain expert. In some cases, the models can be built
interactively with the expert, especially if there are software tools available for model creation.
Interviews can be unstructured, semi-structured, or structured (Hudlicka, 1997).
A structured interview is a systematic, goal oriented process. It forces organized communication
between the knowledge engineer and the expert. The structure reduces the interpretation
problems inherent in unstructured interviews and allows the knowledge engineer to prevent the
distortion caused by the subjectivity of the domain expert. Because every interview is different in
very specific ways, it is difficult to provide comprehensive guidelines for the entire interview
process. Therefore, interpersonal communication and analytic skills are important. However,
several guidelines, check-lists, and instruments are available that are fairly generic in nature
(McGraw and Harbison-Briggs, 1989).
Unstructured Interviews: Many knowledge acquisition interview sessions are conducted
informally, usually as a starting point. Starting informally saves time; it helps to move quickly to
the basic structure of the domain. Usually, it is followed by a formal technique. Unstructured
interviewing seldom provides complete or well-organized descriptions of cognitive processes.
There are several reasons for this: The domains are generally complex; the experts usually find it
very difficult to express some of the most important elements of their knowledge; domain
experts may interpret the lack of structure as implying that they need not prepare for the
interview; data acquired from an unstructured interview are often unrelated, exist at varying
levels of complexity, and are difficult for the knowledge engineer to review, interpret, and
integrate; and few knowledge engineers have the training and experience to efficiently conduct
an unstructured interview (Geiwitz, et al., 1990).
Interviews are sometimes replaced by tracking methods. Alternatively, they can be used to
supplement tracking or other knowledge acquisition methods. It is recommended that before
interviewing the main experts, the knowledge engineer should interview a less knowledgeable or
minor expert, using the interviewing approaches just described. This may help the knowledge
engineer learn about the problem, its significance, the experts, and the users. The interviewer will
also be able to better understand the basic terminology and (if he or she is a novice in the area)
identify archived sources about the problem first. The knowledge engineer should next read
about the problem. Then the main experts can be interviewed much more effectively.
Observations: Sometimes it is possible to observe an expert at work. In many ways, this is the
most obvious and straightforward approach to knowledge acquisition. However, the difficulties
involved should not be underestimated. For example, most experts advise several people and
may work in several domains simultaneously. In this case, the knowledge engineer’s
observations will cover all the other activities as well. Therefore, large quantities of knowledge
are being collected, of which only a little is useful. In particular, if recordings or videotapes are
made, the cost of transcribing large amounts of knowledge should be carefully considered.
Observations, which can be viewed as a special case of protocols, are of two types: motor
movements and eye movements (Cordingley, 1989).
Protocols: Protocol analysis involves asking the expert to perform a task while "thinking aloud."
The intent is to capture both the actions performed and the mental process used to determine
these actions. As with all the direct methods, the success of the protocol analysis depends on the
ability of the expert to describe why they are making their decision. In some cases, the expert
may not remember why they do things a certain way. In many cases, the verbalized thoughts will
only be a subset of the actual knowledge used to perform the task. For this method, the
knowledge engineer interrupts the expert at critical points in the task to ask questions about why
they performed a particular action.
For design, protocol analysis would involve asking the expert to perform the design task. This
may or not be possible depending on what is being designed or the length of time normally
required performing a design task. Interruption analysis would be useful in determining why
subtasks are performed in a particular order (Ericsson and Simon, 1984). If time and resources
were available, it would be interesting to perform protocol analysis of the same task using
multiple experts noting any differences in ordering. This could obtain both alternative orderings
and, after questioning the expert, the rationale for their decisions (Owen et al., 2006).
Prototyping: In Prototyping, the expert is asked to evaluate a prototype of the proposed system
being developed. This is usually done iteratively as the system is refined (Diaper, 1989).
Teach back: In Teach back, the knowledge engineer attempts to teach the information back to
the expert, who then provides corrections and fills in gaps (Geiwitz, et al., 1990)
Document Analysis: Document analysis involves gathering information from existing
documentation. May or may not involve interaction with a human expert to confirm or add to
this information (Cordingley, 1989).
[Link]. Conceptual knowledge modeling
During the knowledge modeling phase, the specialist’s knowledge (elicited by various
techniques) is represented in a knowledge model. A knowledge model is a structured
representation of knowledge using symbols to represent pieces of knowledge and the
relationships between them. Knowledge models include symbolic character-based languages
such as logic, diagrammatic representations such as networks and ladders, tabular representation
such as matrices and structured text such as hypertext. The generation and modification cycle of
a knowledge model is an essential part of the knowledge modeling phase. The model helps to
ensure that all stakeholders in a project understand the language and terminology being used and
quickly conveys information for validation and modification where necessary. The knowledge
models are also of great value during cross-validation with other specialists (Emberey et al.,
2007). Models are used to capture the essential features of real systems by breaking them down
into more manageable parts that are easy to understand and to manipulate. Models are very much
associated with the domain they represent (Savolainen et al., 1995). That domain will define
their practicing communities, modeling languages and the associated tools used. “A model is a
simplification of reality” (Booch et al., 1999). Real systems are large entities consisting of
interrelated components working together in a complex manner. Models help people to
appreciate and understand such complexity by enabling them to look at each particular area of
the system in turn. Models are used in systems development activities to draw the blueprints of
the system and to facilitate communication between different people in the team at different
levels of abstraction. People have different views of the system and models can help them
understand these views in a unified manner.
The modeling process constructs conceptual models of knowledge intensive activities (Schreiber
et al., 1999). During the knowledge acquisition stage, most of the knowledge is unstructured and
often in tacit form. The knowledge engineer will try to understand both the tacit and the explicit
part of the knowledge and then use simple visual diagrams to stimulate discussion amongst users
and knowledge experts. This discussion process generates ideas and insights as to how the
knowledge is used, how decisions are made, and the factors that motivate and so on. The
knowledge engineer then has to construct the conceptual model from what has been discussed
during the knowledge acquisition stage. This communicates the knowledge to the information
specialist who will transform the model into workable computer programs or codes. This
approach is similar to that of software engineering where models are used to represent user
requirements. The main difference here is that in knowledge engineering it is the modeling of
knowledge and its related flows whereas software engineering models the information and
process flow. The importance of knowledge modeling in knowledge management has been
discussed by (Wielinga et al., 1997). They argue that models are important for understanding the
working mechanisms within a knowledge based system, such as: the tasks, methods, how
knowledge is inferred, the domain knowledge and its schemas. Conceptual modeling is central to
knowledge engineering (Schreiber et al., 1999). Modeling contributes to the understanding of the
source of knowledge, the inputs and outputs, the flow of knowledge and the identification of
other variables such as the impact that management action has on the organizational knowledge
(Davenport and Prusak, 2000).
As the paradigm has shifted from the transfer approach to the modeling approach, knowledge
modeling has become an important aspect in the process of building knowledge base systems.
With the modeling approach, systems development can be faster and more efficient through the
reuse of existing models for different areas of the same domain. Therefore, understanding and
selecting the modeling technique that is appropriate for different domains of knowledge will
ensure the success of the knowledge base system being designed.
[Link]. Knowledge representation
The acquired knowledge should be immediately documented in a knowledge representation
scheme. In knowledge representation, the elicited knowledge is converted to a form for efficient
computer manipulation. At this initial stage, the selected knowledge representation strategy
might not be permanent. However documented knowledge will lead the knowledge engineer/
developer to better understanding of the system and provides guidelines to proceed further.
Production Rules, frames, and semantic network are the typical examples of knowledge
representation scheme. Some of them are described as follow:
a. Production Rules- Production rules are the most popular form of knowledge representation
for ES and automated decision support (ADS) systems. Knowledge is represented in the form of
condition/action pairs: IF this condition (or premise or antecedent) occurs, THEN some action
(or result or conclusion or consequence) will (or should) occur. Each production rule in a
knowledge base implements an autonomous chunk of expertise that can be developed and
modified independently of other rules. When combined and fed to the inference engine, the set of
rules behaves synergistically, yielding better results than the sum of the results of the individual
rules (Sasikumar et al., 2007).
If-then rules are one of the most common forms of knowledge representation used in expert
systems. Systems employing such rules as the major representation paradigm are called rule
based systems. One of the first popular computational uses of rule based systems was the work
by Newell and Simon on the General Problem Solver (Newell and Simon, 1972). A typical rule
based system consists of three components (the working memory the rule base, and the inference
engine), as presented in figure 2.3 below.
The rule base and the working memory are the data structures which the system uses and the
inference engine is the basic program which is used. The advantage of this framework is that
there is a clear separation between the data (the knowledge about the domain) and the control
(how the knowledge is to be used)