Expert system shell

Who is considered an Expert?

The person who is considered an expert is someone who has a high level of knowledge, skill,
or experience in a particular field or subject matter. They possess a deep understanding and
expertise in their area of specialization, allowing them to provide valuable insights, guidance,
and solutions related to that field. Experts are typically recognized for their expertise through
their achievements, qualifications, publications, or contributions to their respective fields.
Their opinions and recommendations are highly regarded and trusted by others in the field.
However, it's important to note that expertise can vary across different domains, and individuals
may be considered experts in specific areas rather than being universally knowledgeable in all
subjects.

Features of an Expert
Knowledge and expertise: Experts possess a deep and extensive knowledge base in their field
of expertise. They have spent a significant amount of time studying, researching, and gaining
practical experience in their area of specialization. Their knowledge goes beyond surface-level
understanding and encompasses the nuances and complexities of their domain.
Experience: Experts have hands-on experience in applying their knowledge and skills to real-
world situations. They have encountered a wide range of challenges, problems, and scenarios
within their field, which has contributed to their expertise. Through their experience, they have
developed a deeper understanding of their subject matter and have honed their problem-solving
abilities.
Continuous learning: Experts are committed to ongoing learning and staying up-to-date with
the latest advancements and developments in their field. They actively seek out new
information, research, and insights to expand their knowledge and adapt to evolving trends and
technologies. They understand that expertise is a journey of lifelong learning.
Problem-solving skills: Experts excel in analyzing complex problems and finding effective
solutions. They can break down problems into their constituent parts, identify patterns, and
apply their knowledge and experience to generate innovative solutions. They often possess a
deep understanding of the underlying principles and theories that inform their problem-solving
approaches.
Ability to communicate complex ideas: Experts have the skill to communicate their knowledge
and expertise effectively to others, even if the subject matter is complex or specialized. They
can explain concepts, theories, and methodologies clearly and understandably, adapting their
communication style to suit the audience they are addressing. This enables them to share their
expertise and contribute to the growth and development of their field.
Recognized credibility: Experts are typically recognized and respected by their peers,
colleagues, and the wider community in their field. They may have earned credentials,
certifications, or degrees that validate their expertise. They might also have a track record of
significant contributions, publications, or achievements within their area of specialization.

What then is an expert system

An expert system is a computer-based system that emulates the problem-solving capabilities
of a human expert in a specific domain. It is a branch of artificial intelligence (AI) that uses
knowledge and inference rules to provide expert-level advice and solutions to complex
problems.

The core idea behind an expert system is to capture the knowledge and expertise of human
experts and encode it into a computer program. This knowledge is represented in the form of
rules, facts, and heuristics that the system uses to reason, make decisions, and solve problems.

Here are some key components and characteristics of an expert system:

Knowledge base: The knowledge base is the repository that stores domain-specific knowledge
and expertise. It contains facts, rules, and other information that the expert system uses to
reason and make inferences.

Inference engine: The inference engine is the reasoning component of the expert system. It
applies the rules and logic encoded in the knowledge base to conclude, make decisions, and
provide solutions to problems based on the available information.

User interface: The user interface allows interaction between the expert system and the user. It
can be in the form of a text-based interface, a graphical interface, or even a natural language
interface that enables users to input queries, provide information, and receive advice or
solutions from the system.

Explanation facility: An expert system often includes an explanation facility that provides
explanations for its conclusions or recommendations. This helps users understand the reasoning
behind the system's decisions and builds trust in its advice.

Knowledge acquisition: Knowledge acquisition is the process of gathering and incorporating

knowledge from human experts into the expert system. It involves interviewing experts,
observing their decision-making processes, and transforming their knowledge into a format
that can be understood and utilized by the system.

Expert systems have been successfully applied in various domains, including medicine,
finance, engineering, and troubleshooting complex systems. They can provide consistent,
reliable, and fast decision-making capabilities, enabling users to access expert-level knowledge
and solutions even in the absence of a human expert.

Expert system shell

An expert system shell, also known as a knowledge engineering environment or development
environment, is a software tool or framework that provides a set of tools and resources for
building and deploying expert systems. By providing a framework and set of tools, expert
system shells aim to simplify the development process of expert systems, allowing knowledge
engineers or domain experts to focus on the specific knowledge and rules of the target domain
rather than building the entire system from scratch. They help streamline the knowledge
engineering process, improve efficiency, and promote the reusability of components across
different expert system applications.

It serves as a foundation for developing customized expert systems in specific domains by

providing a structure and set of functionalities that facilitate the creation, management, and
execution of knowledge-based applications. This is to say that an expert system shell provides
the framework that is used in the development of an expert system. In other words, it merely
provides the framework that supports the building of an expert system. This then means that
ES Shell in itself lacks the knowledge base component of a typical expert system, therefore, it
needs to be inserted into it. As the knowledge base is being built, it is important to call in mind
that the expert system is domain specific. Being domain-specific means that since the expert
system sits on the seat of a professional to perform the roles of a professional, professionalism
is related to a particular field, so should the expert system be. Therefore, the user of the ES
shell has to build his/her knowledge base that conforms to the domain where the expert system
will be utilised. This then implies that there is nothing like a general knowledge base as far as
an expert system is concerned. ES shell can as well be seen as a ready-made expert system
without a knowledge base because the knowledge base has to be familiar with the problem it
is meant to solve.

Some key features and components typically found in an expert system shell :

Knowledge representation: The shell provides a mechanism for representing and organizing
domain-specific knowledge within the expert system. This can include various knowledge
representation techniques such as production rules, frames, semantic networks, or ontologies.

Fundamentally, knowledge representation is seen as a model of the real world. Any model is
only a surrogate for reality and, thus, should be treated as such. A model will always be
incomplete, and the participants of an expert system development project should acknowledge
this fact. The problem can be defined as creating an incomplete model that supplements the
mental model of the users so that the total model (computer plus human) is nearly complete—
complete in the sense of being able to solve problems correctly and effectively in the actual
problem area.

Another fundamental issue when choosing a representation paradigm is to make an

"ontological commitment," or rather accept that "behind" different schemes for representing
knowledge are different perceptions of the world. For instance, when working with systems
based on neural net technology, one has implicitly approved that the actual knowledge domain
can be modelled according to the basic theories of neurology: that "knowledge" is a flow of
neurons in the brain. The commitment made here is the traditional paradigm of AI—that
knowledge is best modelled using psychology, that is, that knowledge is processed in symbols.
These symbols are transferred to knowledge representation schemes such as objects.
When taking a practical approach to expert systems, deep consideration of ontological matters
is not necessary, but, as in any other discipline, a basic understanding of the fundamental ideas
is beneficial.
Knowledge Representation Schemes
Over time, a variety of schemes have been suggested by AI researchers. Pragmatically
speaking, many of these can be regarded as variations of the same basic themes. For example,
the generic term "object," which in our understanding holds object knowledge, can be
represented by an object (as in object-oriented programming), a concept, a frame, a script, etc.
These different schemes share the same basic approach to organizing knowledge and can
pragmatically be regarded as belonging to the same class of schemes, namely, schemes made
primarily to hold and structure knowledge about static or passive elements/facts.

Frames (proposed by Minsky) have been used as the main scheme in many expert systems for
building design because this paradigm suits the purpose well. A frame is a structure in which
a (more or less) generic "object" can be described in a rather straightforward and natural way.
A frame represents our anticipation about a certain "object." For instance, when we think about
a wall, we have a more or less clear picture of how a default wall looks, including an idea of
the typical features of a wall. We know that a wall in a house is made to divide spaces, we
expect it to consist of a physical material that cannot be penetrated, we might think it protects
us against the weather, it has an opening somewhere, and so forth. Humans carry symbols of
things and concepts they know about-and a frame is a structure offering the possibilities of
representing such a symbol.

A frame can be illustrated as follows:

Name (ID): Building
Attributes Values Methods
Location City Area
Colour Gray
Heating Natural gas
Age 36 Condition
No of storeys 4
Main Structure

From the information above, the frame holds attributes typical of a building—these attributes
could be the result of the search for performance knowledge if the proposed knowledge
acquisition technique was used. The values represent specific knowledge of a particular house
and can be regarded as the fulfilment of some of the needs for (more) knowledge.
These values can have different origins, but, on the whole, they are a product of an inference
process (e.g., when running the system) producing more facts about the object. The values are
usually not known at the time of the conceptual model creation.

The methods highlight one important feature of the frame paradigm. A method (or damon) is
usually a small procedure that "overlooks" the conditions of one attribute. The frame is, so to
speak, extended beyond static knowledge to hold local "behavioural" knowledge. In this
example, the method is: Condition is a small piece of dynamic knowledge performing an action
under given circumstances. A sample piece is: If the value of "age" exceeds 35, then check
maintenance standards immediately.

However, frames can assume other forms than the one already discussed. For example, a frame
without methods is quite close to a pure "object" representation, where the structure is solely
passive. So, whether an object or a frame is the right selection of scheme depends on the
knowledge present. In many cases in various domains, frames will be a good choice when
modelling the static model. However, it depends, as always, on the nature of the knowledge in
that domain. Basically, all the variation in the concept of "object" stems from this
observation—that is, the original schemes normally serve different purposes; reflect different
perspectives. A good example of this is the script.
The script was originally developed to represent knowledge about stories and novels. For
example, when we are reading a story about a person entering a rail station, we anticipate that
we will be told about train departures, ticket purchases, passengers entering the cars, etc.—a
range of typical episodes occurring at a rail station.
A typical script can be illustrated as follows:
Properties: station, train, ticket counter, car
Roles: passenger, conductor
Point of view: passenger
Event sequence (in chronological order):
• Entering the station building
• Purchasing ticket
• Studying schedule for departures
• Waiting for the train to arrive
• Entering car (subscript 1)

Subscript 1 can be a further detailed script for the railroad car situation: seats, windows,
conductor, other passengers, etc.

Note that this example serves only as an illustration.

Scripts represent the acts and the roles in, for example, a play, but this scheme can be very
useful in task-dominated domains, that is, where the concept of a task is the key issue. In this
type of domain, our building design-based technique to knowledge engineering seems to fall
short or at least must be adjusted as we have based the technique on the assumption of
(physical) objects as the key issue. However, going back to the original definitions of
knowledge types, object knowledge in task-oriented domains is just knowledge about tasks. A
task can be defined as a static situation, whereas carrying out the task is an event.

Within AEC design and in construction, the script approach can be successfully applied when
building expert systems, for instance, for scheduling, risk management, project management,
and so forth, all domains where the key issues are primarily process related.

Scripts are also a good approach to represent situations where the focus is on behaviour. For
example, consider the interior design of a room. When planning the interior and the shape and
size of a room, a simulation of the person's behaviour in that room is very important to optimize
the functionality of (and well-being of people) in the room. An approach like this is rather rare
when dealing with routine building design, but in situations where the room serves a special
function, a script would be a good starting point for representing knowledge in an expert system
for room design.

A sample room (simplified) script might be as follows:

Properties: equipment, doctors, nurses, patient
Place: operating room
Perspective: surgery on a patient
Event sequence:
• Receive patient
• Anesthetize patient
• Check surgery equipment (subscript 1)
• etc.

As mentioned already, frames and scripts share the same philosophy of thinking, and it is the
nature of the domain that decides which (general) scheme to select. Moreover, many variations
of the frame paradigm exist, as every software vendor in our business has refined the original
paradigms with more or less useful features.
In summary, however, the frame is a prudent choice for representing static knowledge in the
more technical disciplines of building design. In areas where the problem can be regarded as
"pure" design (generative problems), it is the components (objects) that are the key issues to
address and, as such, a task-oriented approach does not mirror the nature of the problems,
thereby excluding the script approach. This leads us back to the previous stages of knowledge
engineering: The nature of the domain must be determined so that a proper representation of
passive knowledge can be established. It should be noted that a mix of tasks
and components are likely to be the result of the acquisition of static knowledge.

The best technique, in this case, is to determine with experts what exactly the dominating issue
is or else pursue an expert system with two knowledge bases. This is a difficult approach which
can be overcome by applying different, more advanced techniques such as, for example, the
blackboard.

What is knowledge
 • is a theoretical or practical understanding of a subject or a domain.
• is also the sim of what is currently known, and knowledge is power. Those who possess
knowledge are called experts.
• Anyone can be considered a domain expert if he or she has deep knowledge and strong
practical experience in a particular domain.
• The human mental process is internal, and it is too complex to be represented as an
algorithm
• However, most experts are capable of expressing their knowledge in the form of rules
for problem-solving.

IF the ‘traffic light’ is ‘green’

THEN the action is go

IF the ‘traffic light’ is ‘red’

THEN the action is stop

Knowledge Types
Object knowledge: Knowledge about “things” and concepts of the domain. Object knowledge
refers to ‘‘objects”-in building design-typically physical objects like building components:
doors, windows, beams and so on. The experienced designer possesses a large amount of
domain-relevant object knowledge, which forms a basic framework (vocabulary) for
expressing statements of knowledge, like for example a description of a situation: the roof was
made up of tile bricks and a timber structure.

Performance knowledge is closely related to object

knowledge as it describes the abilities-potential behaviours of an object. Examples of
performance knowledge are the ability of an aircraft to fly, the strength of a beam, and so forth.

Event knowledge refers to a situation we recognise if we are given certain facts, or in other
words if a certain combination of object knowledge and performance knowledge occurs. Events
can be considered as instances of performance-for example the event flying requires the ability
to fly. One way to differentiate between performance knowledge and
event knowledge is the occurrence of time in the knowledge-events is always related to time,
even if it is only implicitly given in a specific chunk of knowledge, whereas performance in
principle is a concept independent of time. Another criterion for event knowledge is that it is
dynamic in nature-it usually describes a situation where something happens (or has happened
will happen): it rains, the ship arrived, the beam collapsed and so on.

Meta knowledge is basically knowledge about knowledge. In problem-solving, a type of meta-

knowledge is referred to as control knowledge: meta-knowledge of global, non-domain specific
factors which influence a given process. An important kind of meta-knowledge is knowledge
about where to locate knowledge. Knowing where to look for travel books in a library is an
example of meta-knowledge.

The basic structure of an Expert System Shell

Inference engine: The shell includes an inference engine that executes the reasoning and
inference processes of the expert system. It provides mechanisms for rule matching, forward
or backward chaining, and other reasoning techniques to draw conclusions and make decisions
based on the knowledge in the system.

The inference engine is the reasoning component of an expert system, and it is a rule interpreter.
The inference engine is a computer program that produces the reasoning for a rule. This engine
can generate new information from the knowledge contained in the rule base and data to be
processed. The brain of the rules system is an inference engine. The inference engine matches
facts and data against the production rules — also called productions or just rules — to infer
conclusions that result in actions. When the IF (condition) part of the rule matches with a fact,
then the rule is said to be fired, and its THEN (action) part is executed. This matching produces
inference chains. The inference chain specifies how to apply the rules to reach a conclusion.

Inference occurs when one or more rules are "fired" (activated).

EXAMPLE 1. Consider a system with three rules:

Rule 1. If A, then B [if A is true (exists), then B is true].

Rule 2. If B, then C.

Rule 3. If Q, then R

We know that A is true (this is a "fact" in the knowledge base). Then rule 1 is fired, concluding
B. This will cause rule 2 to be fired, concluding C. Then we have inferred that A implies C.
Rule 3 will not be fired in this case. It should be noted that the order of the rules to be fired
depends on the search strategy applied

In our example, we have a rule chain consisting of rules 1 and 2. A domain-specific example
might be as follows:

PROBLEM. Water supply

Rule 1: If main valve is open,

Then check status of interior stop valve.

Rule 2: If interior stop valve is open,

Then water is on.

Example 2

Rule1:

IF Y is true

AND D is true

THEN Z is true

Rule2:

IF X is true

AND B is true
AND E is true

THEN Y is true

Rule3:

IF A is true

THEN X is true

The Inference Chain

The occurrence of chained rules depends on the actual domain. If the acquisition has captured
knowledge such as in our example, then event knowledge can be represented as a chain.
Caution should be taken, however, when representing rules in (too long) chains. Assume that
we change our previous rule 3 to rule 3.1: If A, then R Chaining will lead to a conflict because
we have two solutions, C and P. If the rules can be represented as finite rules, that is, as
independent rules without chaining, we recommend doing so. In fact, most real-world rules in
technical building design are expressed as finite statements, but, if not, be careful. One way of
avoiding the chain in our valve example is by creating a combination:

If valve 1 is open and valve 2 is open.

Then water is on.

Rule chaining is usually relevant in domains with scarce object knowledge and dominating
event knowledge. As mentioned before, this is typically not the situation in building design.
Until now, we have only regarded a system with a static model representing passive knowledge
in an object-like structure

Expert systems can be built exclusively based on rules. However, this approach is not
recommended, as many of the rules in the knowledge base of a rule-based system will be a
product of not having more powerful schemes for representation available. A way of working
around this problem is to use rule sets, that is, classifying rules in sets, thereby mirroring some
sort of model. This technique is only suitable with small models containing only a few objects.
In general, a mixed (hybrid) approach as outlined herein, using more schemes matching the
nature of knowledge best, should be pursued in building and civil engineering design domains

In summary, many subdomains in building design can be represented as follows:

Object knowledge and attributes: frame-like structure

Events: methods, when local procedural events, or rules

Metaknowledge: primarily part of the problem-solving process;

see the following discussion.

Referring to our discussion about knowledge types, we can see that the following correlation
exists among sources, types, and suitable schemes:

Written Sources -> Object and Performance Knowledge -> Frame

Human Sources -> Event Knowledge -> Rules and Methods

This observation is valuable as it can provide a degree of coherency in the knowledge

engineering process.

It should be stressed that there will be areas where this pragmatic linking does not cover the
whole truth, and that, in general, frames and rules are worthwhile schemes in many domains.

Knowledge acquisition tools: Expert system shells often offer tools and utilities to facilitate the
acquisition of knowledge from human experts. These tools may include graphical interfaces
for creating and editing rules or knowledge bases, interviewing tools for gathering expert
knowledge, and validation mechanisms to ensure the accuracy and consistency of the acquired
knowledge.

User interface: Expert system shells typically provide a user interface that allows interaction
between the system and the end-users or domain experts. This interface can be text-based,
graphical, or even natural language-based, depending on the capabilities and design of the shell.

Explanation and debugging tools: Shells may include facilities for explaining the system's
reasoning and decision-making to users. These tools help users understand the system's
conclusions and provide insights into the underlying knowledge and rules used. Additionally,
debugging tools assist in identifying and resolving issues or errors within the expert system.

Integration capabilities: Expert system shells often can integrate with external data sources,
databases, or other software systems. This allows the expert system to access and utilize
relevant information from different sources to enhance its decision-making capabilities.

Knowledge Base
The knowledge base is the heart of an expert system. It contains all the knowledge of a domain
expert obtained by the knowledge engineer through knowledge acquisition techniques. It
contains expert-level knowledge on a particular subject stored in a knowledge representational
form. It has been said that knowledge may be defined as facts or skills that are obtained through
several years of experience. domain experts gather this knowledge, such as what is learned
from school and from several years of experience. A domain expert is capable of expressing
his knowledge in the form of rules for solving problems. The knowledge base contains rules
and knowledge that are expressed in rule form.

An “IF ... THEN” rule has two parts:

a) the IF part, also called the antecedent or premise (condition part)

b) the THEN part, also called the consequent part or conclusion part (action part).

Structure of a rule:

IF (Antecedent)

THEN (Consequent)

Example:

IF ... THEN Rules

Rule: Red_Light

IF the light is red Antecedent

THEN stop

Rule: Green_Light
Consequent
IF the light is green

THEN go
Production Rules

the light is red ➔ stop --------→(Consequent (right hand side) upon Antecedent (left hand side))

the light is green ➔ go ----------→ (Consequent upon Antecedent)

Compound Rules

Again, a rule can have multiple antecedent parts joined using connectives like AND or OR,
and this is called compound rule.

The structure of compound rule is as follows:

(a) IF (antecedent 1)
AND (antecedent 2)
•
•
•
AND (antecedent n)
THEN (consequent)

(b) IF (antecedent 1)
OR (antecedent 2)
•
•
•
OR (antecedent n)
THEN (consequent)
It is also possible to use mathematical operators in place of AND and OR:
IF “age of the customer” < 18
AND “cash withdrawal” > 1000
THEN “signature of the parent” is required
An important point to remember is that rules in the knowledge base can represent any relation,
heuristic, suggestion, or recommendation.

• Relation
IF the “fuel tank” is empty
THEN the car is dead

• Recommendation
IF the season is autumn
AND the sky is cloudy
AND the forecast is drizzle
THEN the advice is “take an umbrella”

• Directive
IF the car is dead
AND the “fuel tank” is empty
THEN the action is “refuel the car”

• Heuristic
IF the spill is liquid
AND the “spill pH” < 6
AND the “spill smell” is vinegar
THEN the “spill material” is “acetic acid”

Rules are the most common way of representing knowledge acquired from an expert. Rules
also describe how to solve a particular problem. The knowledge represented by the production
rules (IF….THEN) is used for reasoning that is developed if the IF part of the rule is satisfied;
consequently, the THEN part can be concluded, or its problem-solving action taken. Expert
systems whose knowledge is represented in rule form are called rule-based systems. There are
other ways also of representing knowledge, like frames and scripts, which we will discuss later.

A knowledge base also contains facts and questions, but a rule expresses expertise. It is the
warehouse of the domain-specific knowledge captured from human experts through the
knowledge acquisition module. The knowledge base is used by the inference engine component
of an expert system for evaluating the rule and drawing conclusions from it.
The knowledge base of an expert system has various types of knowledge:
• Procedural Knowledge: The procedure refers to any task that is related to the performance of
some task and a processed form of information. For example, if we have step-by-step
information for solving a problem, then it is called procedural knowledge.
• Factual Knowledge: This is the knowledge about the facts of a particular task domain that are
found inside textbooks and journals. Such knowledge is shared widely.
• Heuristic Knowledge: This is the opposite of factual knowledge, as it is not widely shared but
discussed rarely and is less rigorous, largely individualistic, and more experiential. Heuristic
knowledge arises from good practice and good judgment.

Five processes are needed for building a knowledge base:

1. Knowledge acquisition
2. Knowledge analysis and representation
3. Knowledge validation
4. Inference design
5. Explanation and justification

These are not stages that have to follow each other — some of them will run concurrently.
There are several advantages to representing knowledge through rules:
1. Acquisition & Maintenance: Since domain expert knowledge is encoded in the form of
rules in the knowledge base, a domain expert can define and maintain the rule.
2. Explanation: If knowledge can be represented in rule form, then it is also possible to
explain to users about the conclusion reached. For example, consider a chain of inferences that
led to a diagnosis. We can then use these facts to explain how such a diagnosis was reached.

Since the complexity of problems has increased, we need a complex knowledge base and
sophisticated knowledge representation techniques, like the semantic net and frames.

Working Storage (Database)

The working storage contains facts that are used by the inference engine for matching facts
with the antecedent part of a rule to find a conclusion. It contains the data that is specific to the
problem being solved. It is a working store that the inference engine can use to hold data while
it is working on a problem. It holds all the data about the current task, such as
 • user answers to questions
• any data from outside sources • any intermediate result of reasoning
• any conclusions reached so far
There is a difference between the knowledge base and the database. The knowledge base
contains knowledge and is used over and over again, but a database contains data about a
particular case.