Tech Talk

Expert Systems User Interfaces

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

Editorial

By Reg. Charney

The Price of Freedom

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.

Trends

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