Collecting Knowledge for Rule-Based Applications | 2

Collecting Knowledge for Rule-Based Applications

Interviewing Strategies

Cultivating a good relationship with the people you interview is important. This sounds so simple, you might not think it needs to be said-but it does. Computer people have a culture all their own, and it's different enough from mainstream culture that programmers can be perceived as rude. If you're a computer programmer working as a knowledge engineer, you may have to alter your accustomed behavior when you're interviewing nonprogrammers. Here are a few things to watch out for:

Speak their language. It can be difficult for a programmer to remember that stacks, loops, shifts, and pointers are not part of the everyday vocabulary of most nonprogrammers. Don't use programming terms if you can avoid it. You'll also want to avoid geek words like grok, kludge, and lossage, which will only distance you from the interviewee. Instead, work hard to learn the technical jargon of the problem domain, and use it properly. Show respect. No matter how trivial the domain may seem, the interviewee knows more about it than you, so don't look down on people just because they don't have the same education you do. Your knowledge of programming is not more important than their knowledge of inventory procedures. Your time is not more valuable than theirs. They're doing you a favor by talking to you, so be grateful. Be interested. Make eye contact when you talk to the interviewee. Ask follow-up questions to show that you're listening. Take notes so you don't ask the same question twice (unless, of course, you didn't understand the answer the first time). Generally look as though you're happy to be talking to the person-or they won't talk to you again. Dress for the occasion. Gone are the days when all white-collar workers wore white collars (and ties). But if you're interviewing someone older than you, she might remember those days quite clearly. If you're going to interview a client at a bank, don't show up in sandals and a T-shirt. Dressing appropriately will help your interviewee relate to you. Be reassuring. Often the interviewee is not the customer. A manager may be asking you to capture knowledge from an employee, and that employee may be afraid of being replaced by the proposed new system. Reassure the employee that he's smarter than any computer, and explain that although the system may take over routine tasks, it will free the employee's time to work on more important things. You don't want anyone to perceive you, or the system you're building, as an enemy.

Customers

The customers are the people who are paying you to build the system. Sometimes they know a lot about the problem, and other times they just want the problem solved. If the customer is also a domain expert, then your job is easy, because the customer can direct you to all the information you need. If the customer doesn't know much about the problem domain, then the hardest part of your job may be identifying someone who is.

For the forms advisor application, the customer may be the postal service. No one at the post office will be able to supply much domain knowledge, but they will be able to describe the problem well enough. Luckily, it's obvious in this case who the domain expert should be: a tax accountant. An accountant knows better than anyone else which tax forms people need under various circumstances. The customer should be willing to pay for some of an accountant's time, or perhaps provide access to their own accountants.

Users

The users are the people who will interact with the system on a day-to-day basis. Like the customers, the users may or may not know much about the domain in which the system works. A particular category of user, the expert user, knows the domain very well. Expert users are people who will use your system to automate tasks they already know how to do. They are often the best kind of interviewee to work with, because they understand the problem and simultaneously know how they want the system to react.

The users for the forms advisor are not expert users-they are just people who wander in to the post office to pick up tax forms. This kind of user isn't particularly useful to interview for knowledge-engineering purposes; however, it can be useful to talk to
naïve users about things like user interface issues.

Experts

A domain expert is someone who has technical knowledge in the relevant problem area for your system. A good domain expert is worth her weight in gold, so it is important to seek one out and develop a good working relationship. Most of knowledge engineering consists of extracting information from domain experts.

For the Tax Forms Advisor application, potential experts include accountants and Internal Revenue Service (IRS) workers. An accountant can tell you what forms are required most often by her clients, whereas an IRS employee may have statistics on form usage by the whole U.S. population. Both can help you understand the tax rules.

Desk Research

Not all of your information should come from people. When possible, you should instead collect basic or rote knowledge from written materials, so as not to waste other people's time. Of course, you can't believe everything you read-make sure the experts you talk to would trust the resources you use.

Books and Journals

You might use two broad categories of written material: paper publications and electronic ones. With the explosion of the World Wide Web during the last decade, the amount of electronic research material available has mushroomed. Still, scholarly books and periodicals have a significant advantage over most electronic publications: They are usually peer reviewed. In the peer review process, material destined for publication is read and critiqued by impartial experts. This process improves the accuracy and trustworthiness of the information.

In many scientific and engineering fields, college textbooks are an excellent way to get an overview of a domain. Introductory textbooks are often aimed at a general audience, so you can read them without a specialized background. The best textbooks have gone through several editions, honing their language and presentation. Monographs on specific topics can also be useful; these are used as texts for advanced college and graduate-level courses. They are sometimes less well written and aimed at an audience with specific technical background. University and technical libraries are a good source for textbooks and monographs.

Professional and scholarly journals are published several times each year, and they are an excellent way to keep up with advances in a particular field. They can be very expensive, so you'll want to find them in a library as well.

Newsletters, circulars, and other publications aren't usually peer-reviewed, but they can provide useful information. In particular,
many government publications are an invaluable way to learn about laws, regulations, and practices; they combine and distill information from various laws, orders, legal decisions, and policies to produce practical guides.

Web Sites and Electronic Media

You can often find hundreds or even thousands of references by typing a few key words describing your domain into an Internet search engine. There are online encyclopedias of every description, guides to technical fields, troves of engineering data, and countless other valuable resources.

Although the Internet is full of information, it is important to realize that not all of it is correct or unbiased. In particular, many
search engines either accept payment for highly placed listings or use a ranking system that is easily fooled into placing a particular page at the top of your search results. Before using a general search engine, learn a little about how it is implemented and operated. Select one that, to the extent possible, ranks results only on their relevance to your search topic. You should also scrutinize individual web pages; check for the source of the information, and try to verify it against another reference.

Sometimes, published electronic reference works on CD-ROM are useful, although they are often simply expensive alternatives to (or worse, a repackaging of) material already available on the Web. Again, you can often find and use these references in libraries.

Summary

In this article, you've learned one approach to collection knowledge for rule-based applications. Knowledge engineering is not entirely unlike requirements gathering for other types of software development, but it has its own unique and challenging aspects. Rule-based systems development is an exciting and powerful way to approach a range of important problems; I hope this brief introduction to the early phases of the development process inspires you to continue on and learn more about rule-based programming.

[previous]

Created: March 27, 2003
Revised: August 6, 2003

URL: URL: http://webreference.com/programming/rule/1