Jess Information

Jess Home
Jess 7 Features
Download Now!
Online Demo

Documentation
FAQ
Manual
Mailing List
Jess Wiki

More information Related Web Sites
User Contributions
JSR94 Info
Developer's Log
About This Site

JESS ®, the Rule Engine for the JavaTM Platform

Jess Wiki: Identify Domain Expert

Presumably, the customer is the one who originally defined the problem to be solved and is paying to solve it. You may assume that this is also your DomainExpert. Sometimes it is, but surprisingly often it isnít. The people who know the problem domain, i.e. the people who work every day in the field, arenít usually the ones funding the projects. Upper management funds them. While these upper managers sometimes know a great deal about the problem domain, the real experts are more often the grunt workers doing the task youíre trying to automate with an expert system. Your first task in developing an expert system should be identifying who these experts are and establishing a working relationship with them. Their input and support will be critical to the success of the project.

Unfortunately, you will sometimes run into the problem of a hostile, or uncooperative, domain expert. A HostileDomainExpert is one that, for whatever reason, is willing to let the expert system fail. There are many reasons they may feel this way. One of the most common is that they fear for their own job security. If you build a system that automatically does what they do on a daily basis, there is a very real possibility that the company may terminate their position. Sometimes, the domain experts simply donít want to spend the time out of their already busy schedule to talk to you. The KnowledgeEngineeringProcess? can be very time consuming for domain experts. You can often counteract this by reminding them that, in the long run, your system will make their jobs easier.

Occasionally, a domain expert may not be available. In this situation, there are only two paths to success. First, someone may have meticulously documented the business logic that needs to be encoded. In this case, your job is simply to translate this logic into the language of the expert system. The second possibility is that you become the expert. I wouldnít recommend this for a large, complex business process, but you should be able to see how it might work out for something like game playing. You can easily learn how to play the game and come up with good strategies that can be encoded into rules.

If youíre unable to locate a cooperative and knowledgeable domain expert, you may be better off saying that the project canít be done and stop its development early, rather than continuing on with a doomed project and suffering the consequences later.

To sum up, you canít develop an expert system without expert knowledge!

Submitted by:
GeorgeWilliamson
Union Pacific Railroad
gawillia@up.com



DevelopmentStrategies


Front Page | Sandbox | Recent Changes | Powered by Friki | Last Edited: 18 August 2006