|
By Jesse Monroy, Jr.
Traditionally, ES (Expert Systems) are shrouded in mystery and
considered a black art. Communications with so-called ES specialists
are tenuous at best. As such, many so-called ES explanations are
poor. Much of the literature is equally poor – revolving around
"shells" and "knowledge bases".
ES provides programming benefits that include smart modes,
intelligent agents and heuristic reasoning.
In these articles, we'll investigate
- Daily Uses of ES
- Traditional Meanings within ES
- Common Questions When Creating ES
- Mechanisms for User Interfaces
- Querying Issues in Creating User Interfaces
In next article, we'll investigate Methods for Mapping User
Interfaces to Expert Systems.
Daily Uses of ES
To see the value of ES, we should look at some of ES’s
successes and failures.
Among the successful are:
- Plug’N’Play keeps an enumerate list of known issues, then
following a defined set of rules resolves installation issues.
- InstallShield™ keeps a list of all installed components, and
follows defined rules for installation.
- Google™ keeps a list of "authoritative" entities,
then follows a defined set of rules to ranks words and word
sets.
Among the failures are:
- Microsoft Bob is so bad, I can't find anyone to tell me what
it actually did.
- OCR (Optical Character Recognition), actually there are many
good OCR programs. The failures is that it usually requires a
person to train the OCR. Even so they are not 100% accurate.
Successful Failures
- Clippie: the intelligent assistant everyone loves to hate.
- Ask Jeeves: natural language interfaces are difficult enough;
this found new heights.
- Spell Checkers: most spell checkers work by phonetics and/or
“most often misspelled” variations. They often miss
grammatical and functional usage, and homonyms
Traditional Meanings within ES.
It Is Really a Logic Puzzle.
This took me many years to figure this out because the examples
given are greatly over simplified. In an extremely simple ES, we can
use a 'switch()/case:' or 'if/then/else' to build an ES. However,
its answers are limited to enumerated scenarios.
A simple example is
On Fridays we serve fish.
A complex example is
On Fridays, if the Catholics come in, serve them fish.
On Good Friday, if orthodox Catholics come in, serve them
water.
On Good Friday, if any Catholic comes in, don't serve them
food.
This is intentionally more complex. One way to solve this is to
put it in a matrix and sort it. This is known as a Decision Table
(Figure #1). Here is the solution:
- On Fridays, orthodox Catholics get water, any other Catholics
get fish. They can't get anything else.
- On Good Fridays, don’t serve Catholics any food.
Food Food
Serve Serve No Flat Do
Don't
Fish Water Pork Bread Serve Serve
Catholic
Friday
X
X
Catholic Good
Friday
X
Orthodox Catholic
Friday
X
X
Orthodox Catholic Good
Friday
X |
Figure #1—Decision Table
How this Example Relates to ES
As the example shows, going from complex to simple may need a
middle step. Expert systems traditionally contrive (make up) such
systems. They are called "Expert Shells". Traditionally
literature suggests you build your own, or use an existing shell. So
now the question is: How do we build a shell or bypass one?
The traditional method is to create databases with all pertinent
information. (In reality, it is just a place to store information
because no one knows a better way.) The crux is you need to store
the enumerated states and the overlapping rules somewhere. One
traditional method is to use a lightweight database engine, like
Berkeley dbm (Berkeley Database Manager). Dbm can store data as
b-trees, hashes, or lists. We'll see how that works in an other
article.
Traditionally, an ES is built with two or three databases,
depending on the design. In a three database design, there are:
Decision/Action Database
- Knowledge Database (keywords/syntactic description)
- Mapping of Knowledge to Decision/Action Database
Caveat: Knowledge base and Knowledge Database are not the same
thing.
In a three database design, a Decision/Action Database is a list
of all actions that can be made. A Knowledge Database is a list of
keywords or syntactic description. This database, in many cases, can
be considered the vocabulary of the system; that is, the vocabulary
for which the ES is being built. The last database (Mapping of
Knowledge) is tricky to create, difficult to maintain, and the magic
in the potion. Creating *any* of these databases is difficult, and
time consuming.
In a two database design, the "Mapping" becomes part of
the "Expert Shell". However, the Mapping of Knowledge to
Decision/Action Database is, in many cases, an optimization --
similar to the previous example. Expert shells help by walking the
user and/or the expert through a series of questions, or by using
heuristics (or "rules of thumbs") as short-cuts.
In both designs, the expert blazes the trail. That is, the
short-cuts are based on the expert's knowledge, or feeling, about a
subject. There are other methods. We will explore them later.
Lastly, as part of the process, a feedback loop is required for
most modern expert systems. The “feedback” is nothing more that
a final request from the end-user about the value of the system.
Most useful ES systems with CF (Certain Factors) have some form of
end-user “feedback”.
Common Questions In Creating ES
Some common questions when building expert systems are:
- Is an expert needed?
- Does the author/programmer/writer need to be an expert?
- Should a novice be consulted?
In each of these questions one needs to evaluate the end goal. ES
run best when part of the initial design.
When trivial or mundane tasks need to be accomplished, experts
don't need to be consulted. In some parts of the world this is known
as experience. In the same way, the author or programmer does not
need to be an expert or an expert in the ES field, if there is a
limited amount of tasks to be accomplished. This type of programming
is sometimes referred to as “great options”, "smart
modes" or "intelligent actions". In addition, this
article present several pointers whereby most “experienced”
programmers can apply known methods. The answer to all the above
questions is usually NO.
Mechanisms for User Interfaces.
Within ES, all the traditional query methods work, some better
than others. Here is a short list of query methods:
- True/False
- Multiple Choice
- Gauged Response
- Fill-in/Free form
True/False is considered the most tedious, but allows for
certainty, or “determinism”.
Multiple Choice is a good compromise. It has a multitude of
implementation methods. The most popular are:
- Radio List
- Check List
- Collapsing Lists
A radio list is a multiple choice widget that returns only one
(1) answer. Properties are:
- Precise answers
- Limited in scope
- Limited in usage
A checklist is a multiple choice widget that returns zero, one or
more answers all of which are correct. It's properties are:
- Precise/multiple answers
- More flexible than radio list or True/False
- Limited in scope
- Ignores the miscellaneous case
A collapsing lists is a widget that has only one answer, and when
that answer is chosen it interactively removes, or adds, relevant
answers (from end-user visibility). It's properties are:
- Maps well from expert to user knowledge
- More flexible than check, radio or True/False
- Usage and familiarity are by rote
- Easily misused by programmers
- Is confusing until rote takes hold
All gauged responses look alike: they are a slider, knob or
percentage meter (similar to thermometers). Their properties are:
- Useful for perceptual information
- More flexible than multiple choice or True/False
- Less precise
- Subject to temporal conditioning
Fill-in/Free form is the most difficult of all. Some advances
have been made in this area; most notably voice recognition. Natural
language interfaces are also fairly advance, but still subject to
nuances. In the area of “natural language”, dialects influence
the understanding of what is meant.
Querying Issues in Creating User Interfaces
In most cases, the end-user has one goal: Give me the answer in
the shortest amount of time possible. As such, the program creator
is left with getting the answer to the end-user without being
annoying. To this, confidence and “sets” play a major role.
The list of confidences that apply are:
- Expert Confidence
- Confidence Factors
- User Confidence
Here is a list of sets that apply:
- No Query Set
- Minimal Query Set
- Confidence Query Set
- Complete Query Set
All three confidence parameters are what they sound like. Expert
Confidence is when an expert is confident that the answers provide
correct mappings to the query. Confidence Factor, usually measured
in percentage, is a number produced by the ES that states how
confident the system is of the answer based on the query responses.
Sometime this number is set by the expert. User Confidence is a
measure of how much confidence the user has in the system. As this
is extremely difficult to measure, it is considered ambiguous.
Also, Expert Systems are built on “Expert” knowledge. There
are a few truisms. It is:
Not User Confidence.
Biased on expert’s knowledge.
A measurable factor.
No Query Set
For obvious reasons, "No Query" is the usual case. This
type of system has many options, but few decisions. Decisions, if
any, are made by an “expert”. Some programs that fall into this
category – fall into the "Expert Confidence" set. On the
Unix platform, 'cp', 'tar' and 'dhcp' may be considered "No
Query" and therefore in the “expert confidence” set.
No Query is deterministic; meaning when you do something you will
get what you expect. No Query never intentionally falls into the
"non-deterministic" situation. As such, it never uses
Confidence Factors.
Caveat: Badly designed and/or implemented programs may produce
"non-deterministic" situations.
Minimal Query Set
Minimal Queries ask just enough questions to get the job done.
Such applications are said to have “smart modes”. In truth,
these applications are usually designed for experts. A prerequisite
for these applications is "knowledge in an area".
Graphic drawing programs are examples. By this token, most web
developers will see color as RGB space, paper publishers will see it
as CMY, and video producer may see color as YUV[1]. An end-user
might get color choice, by a color wheel, or color plane or color
table.
In all cases, the end-user is has a familiar interface. Also,
direct querying is minimal because of familiarity with the
interface.
Confidence Query Set
A Confidence Query has multiple issues. But, it does provide
fairly accurate information for systems that change over time.
It uses Confidence Factors, that are stored in terms of
percentage. In many cases, this translates to 100% as being the most
confident and 0% as being the least confident.
Confidence Queries have issues are beyond the scope of this
article. However, CF may work where other methods fail; often to the
surprise of the developer.
Complete Query Set
Complete Queries asking many questions, some which may not be
directly related information to the task at hands. The medical
industry from time to time resorts to this type of system when all
other means have been exhausted. Most notably, the European medical
industry is said to use color relationships, known as the "Lümscher
Color Test"[2] to gauge medical conditions. From all this, you
might be correctly conclude all programs are some form of Expert
System.
[1] Color space FAQ
http://www.neuro.fsc.keio.ac.jp/~aly/polygon/info/color-space-faq.html
[2] The Lümscher Color Test—ISBN 671-78827-2
By Reg. Charney
Each generation needs to pay for its freedom. On September 11,
2001, we made the down payment for the gifts of freedom, tolerance,
and diversity that our forefathers passed down to us.
The challenge that we now face is different from our parents and
grandparents. Each new war is different from the last, regardless of
what our planners and politicians say. This is not a one front war,
it is not a war fought between armies, nor is it a war that will end
in some form of surrender. It is a war that will last forever. For
there will always be a small number of persons that think that
violence is the answer. We will also need to fight on two fronts: we
will need to fight terrorists, both external and internal; and we
will need to fight against loosing those freedoms, tolerance and
openness that have defined this country and helped make it great.
As I write this, we are in the “wait and see” period—the
“sitzkrieg” of the Second World War. We are waiting on our
response or for further acts of terrorists violence. In many ways,
this is also the time when we do the most damage to ourselves. In
the interests of heightened security, we will curtail individual and
net freedoms. In fear of violence, we will reduce our traveling and
buying. The uncertainty will drive down consumer confidence and
increase the severity of any economic downturn. Many writers have
also commented on this. My point is that this is a normal reaction
and we should be able to take it in our stride. That is, we shouldn’t
panic, but continue our lives as normal – my family and I are
flying back to New York for a week’s holiday there. It is
something we had planned before September 11 and intended to do
after September 11. It is one way of supporting New Yorkers and
ourselves.
Lastly, I am concerned that if we try to withdraw from the world
and abandon those outside our borders, we will plunge the remainder
of the globe into economic chaos This isolationist tendency will
only increase our long-term problems with terrorists. We will be
supplying them with more recruits and excuses for terror. We will
also leave ourselves blind to the world in which we live.
By Ali Çehreli
Get ready to hit the bottom
I condemn the terrorist acts that took place September 11, 2001
and offer my sympathy to all who has been affected.
The data that I collected three days after the terrorist attack
has strengthened my predictions about the recovery of the job
markets. However, the news regarding layoffs, mainly in the airline
industry, had not been announced at that time. It is likely that
this will affect the job market and we will have to wait for the
recovery for a little longer.
The most trendy platform continues to be Windows 2000. Like in
May '01, the number of jobs related to Win2k has been more than the
previous month: this time 5.4%. In fact, Win2k has been hovering
around its lowest point since April '01 (Figure 1). Linux, having a
positive normalized trend, has been the second after Windows 2000.

Another good news for the software engineers is the positive
demand for the languages that has been observed in the past three
months. Figure 2 shows the latest normalized language demands.

Is Java more popular than C++? This question has come up
indirectly in the follow ups to a message titled “Whether C++?”,
which was posted on comp.lang.c++.moderated.[1][2] The original
message was a preparation for an article that was later published at
byte.com.[3]
Even though the article has concluded that “C++ will remain in
a central, if no longer starring, role in development circles” and
that “there's still no substitute [for C++],” some of the follow
ups contained links to sources showing the alleged decline of C++.
One of the responses to these follow ups was a message from Francis
Glassborow; which contained an excerpt from Reg. Charney, “the
rate of growth of each language is about the same”, and a link to
the data that backs-up this observation.[4]
Indeed, C/C++ job postings has been about twice the Java postings
in the Silicon Valley for a long time. But we must be aware of one
fact that it is almost impossible to separate pure C jobs from C++
jobs. There are two main reasons for this: the limitation of the
search engines that cannot discriminate between “C” and “C++”;
and the tendency of posters using “C/C++” in the job postings
regardless of the actual language skill they are looking for.
References
[1]http://groups.google.com/groups?q=g:thl932273328d&hl=en&selm=4386490c.0108280951.3dce1ee2%40posting.google.com
(The author has apparently made a typo in the title; it should have
been "Whither C++?")
[2]http://groups.google.com/groups?hl=en&selm=4386490c.0109050620.10bd20b1%40posting.google.com
[3] http://www.byte.com/documents/s=1271/byt20010831s0001/
[4] http://groups.google.com/groups?hl=en&selm=GhLE0dBwISm7EwGB%40ntlworld.com
|