TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> The post below sounds more like it is talking about
> knowledge management
> systems than expert systems. I've only heard the term "knowledge engineer"
> related to knowledge management, not expert systems.
[snip]
> On the other hand, expert systems is a specific sub-branch
> of the field of
> Artificial Intelligence; it involves building computer programs
> that act as
> decision-makers, usually for a technical domain.
And Sandy answered:
> "Knowledge engineer" was a standard term in expert systems work
> in the mid-80s
> when I last looked seriously at that field, long before I heard
> business types
> start talking about "knowledge management". Of course I don't
> listen to business
> types all that much, so I may have missed something there :-)
>
> A knowledge engineer is the person who queries and observes the
> expert, then
> encodes the expert's knowledge in whatever formal system is being used.
>
What she said. To clarify, I am talking about expert systems, as Jennifer
defines them, NOT knowledge management systems (though there is a little bit
of overlap). Read my discussion at http://www.freelock.com, and the
descriptions at http://www.freelock.com/technical/expert.asp.
Sandy again:
> The role is quite a bit like that of a tech writer dealing with developers
> (though we use formal systems less) and a great deal like a linguist with
> a native speaker informant. If it is done well, the rules or docs
> that come
> out of the process often make explicit things the expert or informant has
> no conscious knowledge of.
>
This is the sort of thing I'm looking for. In my experience, the models our
team of technical writers built in practice did not make explicit things the
expert had no knowledge of. But I think the possibility is there--it just
needed more careful analysis of the problems, and more care on the part of
the experts.
The insights to be gained come from the process of building the model. It's
just like what we do as technical writers every day--synthesize our own
understanding of a system based on what the experts teach us--and asking the
simple questions can explicate assumptions the experts may have long
forgotten. The catch, with expert systems, is that if you overlook the basic
assumptions, the expert system doesn't reflect the reality very well.
Melissa added library science to the discussion:
> Admittedly, much of
> it has been forgotten by most of the library world which has been
> preoccupied
> with full-text search and visible customer service issues. Thesaurus
> building, indexing, classification theory, all of these are
> integral parts of
> creating expert systems.
These sound integral to case-based reasoning systems, but much closer to the
knowledge management systems Jennifer described.
Jennifer had a useful illustration of the difference:
> To bring the differences into focus: an end-user of a
> knowledge management
> system would be _asking_ questions of the system (e.g. "What
> report contains
> the ROI calculations for Project X?" or "Who knows the vendor contact at
> ACME Corp.?"), while an end-user of a expert system would be _answering_
> questions from the system (e.g. "Is the patient's temperature
> above 101?" or
> "Did the gram stain come back positive?").
Let me provide three examples of the expert systems I'm acquainted with:
1. Microsoft troubleshooters.
These troubleshooters use a Bayesian belief network to diagnose problems on
the user's machine. If you're running Windows 2000, you can find them in
your help system. You basically start with your problem, the troubleshooter
asks you questions about the state of your system, and recommends solutions
based on your answers to the questions. The unusual feature added by the
expert system is that you can skip questions you can't answer, and not
necessarily delay getting to your resolution.
In Windows ME, they expanded the capabilities of the troubleshooters to
actually detect some of the conditions on your machine directly, without
having to ask you to find out.
The problem is, these troubleshooters represent the efforts of a couple
years time by a team that grew to 8 full-time people and a bunch of outside
development. Most of this represents the tough learning curve of the
technology, and the lack of practical resources (most of the expert system
information is highly theoretical).
2. State machines for telecommunications management network software.
A software vendor I work with provides a framework for their customers to
develop applets that become state machines, allowing sophisticated modeling
of their network to reduce the number of messages associated with a problem
to something manageable by the network operations personnel.
However, very few of their customers have implemented them, mainly because
there are simpler alternatives.
3. Backward-chaining expert system for medical decision support.
This is a very hot area right now for expert systems, but the one I'm
acquainted with isn't getting much use. It hooks into the patient management
software, and when certain conditions are met, it runs and catches
potentially hazardous combinations of factors, notifying the doctor to help
prevent avoidable problems.
Again, the issue with this expert system is that it's labor-intensive to
analyze, program, and debug. Every single problem needs to be modeled and
programmed--not a trivial exercise.
So... aside from demonstrations and sample applications, can anybody point
me to a working expert system that has proven to be cost-effective? Can
anybody add more examples of actual implementations of expert systems
outside research departments?
Thanks to the people who have responded off list with other leads to follow.
Regarding relevance to technical writing, that's my other question. Sandy
pointed out how some of the skills related to knowledge engineering are
those of a writer--researching and interviewing the problem, and organizing
the information. But some of the skills are very different from typical
writing, as Jennifer points out--needing some background in programming,
logic, and statistics.
>From experience trying to hire knowledge engineers, it's hard to find people
that are both good at writing and good at the non-writing stuff. However,
I'm guessing that many people with all of these skills end up as technical
writers.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by SOLUTIONS, Conferences and Seminars for Communicators
Publications Management Clinic, TECH*COMM 2001 Conference, and more http://www.SolutionsEvents.com or 800-448-4230
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
