![]() |
|||
![]()
|
![]() |
![]() |
![]() |
4. FOCUSED APPROACHESDoing 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.
Broadly spoken, the knowledge acquisition bottleneck problem was attacked in three ways:
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.
|
![]() |
|
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. |