Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


4. FOCUSED APPROACHES

Doing away with the claim that they cover all aspects of the KBS development process, the approaches in this class limit themselves to one or a few activities and try to support them in depth. The focus chosen most frequently is the long-standing problem, identified first by Buchanan et al. (1983), of the knowledge acquisition bottleneck. Extracting the knowledge from the expert was seen to be the major time and effort consuming activity, quite unlike what was the case in conventional systems development5. Additionally, there was the concern for the maintainability of the KBS, as it became clear that large unstructured rule bases were extremely difficult to modify.


5It is difficult to establish whether this observation was ever really true. To people like DeMarco (1982) requirements analysis and correct specification, if done well, just as important and time consuming in conventional systems development as knowledge acquisition is in KBS development.

Broadly spoken, the knowledge acquisition bottleneck problem was attacked in three ways:

  • Trying to model the expertise using knowledge acquisition (KA) methods and techniques like protocol analysis, interviewing, case reviewing, concept sorting/laddering, etc., employing a knowledge engineer.
  • Transfer of the knowledge from the expert directly into a KBS using appropriate expertise transfer methods and techniques.
  • Providing a domain tailored environment, which is applicable to a well-defined and limited area of expertise or is bound to a specific method.

The first path has been taken mainly in Europe. One of the earliest automated support tools in this area was the KEATS system (Motta, et al., 1988). Later, two ESPRIT Projects [ACKnowledge and VITAL (Shadbolt et al., 1993)] were active in this area. Also, the KADS-I project was mainly concerned with knowledge acquisition, though some initial work was done for broader coverage. Both ACKnowledge and VITAL produced a coherent set of knowledge acquisition methods and techniques, including repertory grids, protocol analysis methods, laddering, sorting, etc., as well as libraries of generic templates of expertise models (mostly derived from KADS-I). Both VITAL and ACKnowledge have contributed to the PC-PACK® tool marketed by ISL in the U.K. KADS-I fed into KADSTool® marketed by ILOG in France. Though precise numbers are hard to come by, there seems at least to be a modest market for tools of this type.

The second path is most visible in the work of John Boose on the Expertise Transfer System and the AQUINAS environment (Boose et al., 1989). This approach strives to eliminate the knowledge engineer as the intermediary between expert and coding. The idea is that the expert can directly enter his expertise in a kind of "workbench" that relies heavily on repertory grid and cluster algorithms for translating expertise into executable code. The main difference between this approach and the one described above, is the lack of an explicit modeling effort. One could argue that the format prescribed by the repertory grid is a kind of model, or at least a structure that facilitates knowledge acquisition. It seems that most experience with this approach has been gained in the U.S. and Boeing in particular. Spread to Europe has been hindered by the prevailing preference for the modeling approach. Work in this area has not progressed much since the early 1990s. It could be eclipsed somewhat by the growing popularity of machine learning techniques since the early 1990s. As these techniques follow the same strategy as AQUINAS, bypass the knowledge engineer and modeling, they are in obviously in competition in particular when a case base is available.

The third and last path is based on the idea that knowledge acquisition works best when it stays as close as possible to a specific domain. The SALT system (Marcus and McDermott, 1989) relied on a specific problem solving method (propose and revise) and could be used for all domains in which this method is implicitly or explicitly employed by experts. The sequel to this work is the PROTÉGÉ-II system (Musen, 1989), which instead focuses on task-specific tools that enable the experts to communicate in their familiar domain-specific terms and concepts. Work on this approach is still progressing, though the major thrust is in the academic community (see Rothenfluh et al., 1996).

A fairly complete overview of the work and the results in this area can be found in a special issue of the International Journal of Human-Computer Studies (1996).

Before moving to the next section, a word about KBS development environments like ART, KEE, AionDS, etc. Sellers of these tools would probably hold that they also have at least a methodological flavor because they provide tools and techniques for building KBSs. Though this may be true, the author still sees them primarily as programming languages, albeit sophisticated ones. To make a comparison: in methodologies for conventional information systems building, this would be equivalent to calling PASCAL, SMALLTALK, DELPHI, or any other programming language a "methodology," though they certainly are tools. One could even argue that the sense of having a methodology at all lies in keeping analysis, specification, and design as much as possible apart from a commitment to a particular programming language. No existing methodology (e.g., Yourdon, Martin, SDM, or JSD) has ever made such a commitment.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.