The Protg project has come a long way since Mark Musen first built the Protg metatool for knowledge-based systems in 1987. The original tool was a small application, aimed at building knowledge-acquisition tools for a few specialized programs in medical planning. From this initial tool, the Protg system has evolved into a durable, extensible platform for knowledge-based systems development and research. The current version, Protg-2000, can be run on a variety of platforms, supports customized user-interface extensions, incorporates the Open Knowledge Base Connectivity (OKBC) knowledge model, interacts with standard storage formats such as relational databases, XML, and RDF, and has been used by hundreds of individuals and research groups. In this paper, we follow the evolution of the Protg project through 3 distinct re-implementations. We describe our overall methodology, our design decisions, and the lessons we have learned over the duration of the project.. We believe that our success is one of infrastructure: Protg is a flexible, well-supported, and robust development environment. Using Protg, developers and domain experts can easily build effective knowledge-based systems, and researchers can explore ideas in a variety of knowledge-based domains.

A new domain-independent knowledge-based inference structure is presented, specific to the task of abstracting higher-level concepts from time-stamped data. The framework includes a model of time, parameters, events, and contexts. A formal specification of a domains temporal-abstraction knowledge supports acquisition, maintenance, reuse, and sharing of that knowledge.

Problem-solving methods for knowledge-based systems establish the behavior of such systems by defining the roles in which domain knowledge is used and the ordering of inferences. Developers can compose problem-solving methods that accomplish complex application tasks from primitive, reusable methods. The key steps in this development approach are task analysis, method selection "from a library", and method configuration.

In their paper on "Using Explicit Ontologies in KBS Development", van Heijst and colleagues seem to take for granted Bylander and Chandrasekaran 's hypothesis on the strong dependence of knowledge represesentation on the nature and the inference strategy of the problem at hand, the socalled interaction problem: Representing knowledge for the purpose of solving some problem is strongly affected by the nature of the problem and the inference strategy to be applied to the problem. [Bylander and Chandrasekaran 1988] The fact that the van Heijst and colleagues don't attempt to explore in detail the arguments sustaining this hypothesis is particularly puzzling, since they admit that it contradicts one of the main assumptions of their well-known KADS approach [Schreiber et al. 1993], namely the separation between domain knowledge and problem-solving knowledge. They report two reasons brought by Bylande

Problem solving methods (PSMs) are domain-independent reasoning components, which specify patterns of behavior which can be reused across applications. While the availability of extensive PSM libraries and the emerging consensus on PSM specification languages indicate the maturity of the field, a number of important research issues are still open. In particular, very little progress has been achieved on foundational and methodological issues. Existing libraries of PSMs lack a clear theoretical basis and only provide weak support for the method development process, usually in the form of informal guidelines. In this paper we will address these issues by illustrating a framework which characterizes PSMs in terms of problem commitments, problem-solving paradigms and domain assumptions. This framework provides i) a theoretical foundation for situating PSM research and individual PSMs, as well as ii) an organization which allows us to characterize method development and selection as a process of navigating through a three-dimensional space (defined by the three components of our framework). Individual moves through this space are specified by means of adapters. In the paper we will illustrate these ideas in detail, with examples taken from parametric design problem solving. 1.

The use of predefined models of problem-solving methods is receiving considerable attention from researchers in the area of knowledge acquisition. Using these models, developers of knowledge-acquisition tools are able to prescribe the roles in which knowledge is used in completing a given task. A number of method-oriented architectures based on a single problem-solving method have been developed by various research groups. Because the methods are domain-independent, method-oriented architectures are limited by the fact that knowledge roles that depend on domain-specific considerations cannot be represented using the model of problem solving. In addition, the interface between the knowledge-acquisition tool and the application expert cannot adequately convey the role of each knowledge type in the task model. PROTG-II is a knowledge-acquisition shell that we are building to generate knowledge-acquisition tools automatically without presupposing a specific model of problem-solving. The shell manages a library of mechanisms---procedures of grain size smaller than that of problem-solving methods. Mechanisms can be combined in PROTG-II to construct problem-solving methods and to define the roles of knowledge that depend on domain considerations. Furthermore, PROTG-II utilizes the concept of adaptation in interfaces to allow the knowledge engineer to produce interfaces that are task- and domain-specific. In this paper, we present the PROTG-II shell and examine the components of its architecture. We also demonstrate the use of PROTG-II with a running example, and discuss the design techniques used to overcome the limitations of method-specific architectures.

We have for several years been working on an approach to knowledge system building that argues for the existence of a close connection between the tasks which the knowledge system is intended to solve, the methods chosen for them and the vocabulary in which knowledge is to be modeled and represented. We trace the historical origins of the idea that we have called Generic Tasks, and outline their evolution and accomplishments based on them. We then critique their original implementations from the perspective of flexible integration. We follow this with an outline of our current generalization of the view in the form of a theory of task structures. We describe the architectural implications of this view and outline some research directions.

PROTG-II is a suite of tools and a methodology for building knowledge-based systems and domain-specific knowledge-acquisition tools. In this paper, we show how PROTG-II can be applied to the task of providing protocol-based decision support in the domain of treating HIVinfected patients. For this task, we use a problem-solving method called episodic skeletal-plan refinement. This method is decomposable; we construct it from a set of reusable components. In addition, we build an application ontology that consists of the terms and relations in the domain, plus terms that supply method-specific knowledge requirements. From this ontology, we automatically generate a domain-specific knowledge-acquisition tool. The general goal of the PROTG-II approach is to produce systems and components that are easily maintained and reusable. This is the rationale for constructing a problem-solving method from a set of smaller-grained methods and mechanisms. This is also why our knowledge-acquisition tools are domain-specific and generated automatically from ontologies. Although our evaluation is still preliminary, for the application task of providing protocol-based decision support, we show that these goals of reusability and easy maintenance can be achieved. We discuss design decisions and the tradeoffs that have to be made in the development of the system. Keywords. Decision support; expert systems; knowledge acquisition.

Role-limiting approaches support knowledge acquisition (KA) by centering knowledge base construction on common types of tasks or domain-independent problem-solving strategies. Within a particular problem-solving strategy, domain-dependent knowledge plays speci c roles. A KA tool then helps a user to ll these roles. Although role-limiting approaches are useful for guiding KA, they are limited because they only support users in lling knowledge roles that have been built in by the designers of the KA system. EXPECT takes a di erent approach toKAby representing problem-solving knowledge explicitly, and deriving from the current knowledge base the knowledge gaps that must be resolved by the user during KA. This paper contrasts role-limiting approaches and EXPECT's approach, using the propose-and-revise strategy as an example. EXPECT not only supports users in lling knowledge roles, but also provides support in 1) adapting the problemsolving strategy, 2) changing the types of information to be acquired about a knowledge role, 3) adding new knowledge roles, and 4) acquiring additional background information about the domain needed by the knowledge-based system. EXPECT's guidance changes as the knowledge base changes, providing a more exible approach toknowledge acquisition. This work provides

A knowledge acquisition tool should provide a user with maximum guidance in extending and debugging a knowledge base, by preventing inconsistencies and knowledge gaps that may arise inadvertently. Most current acquisition tools are not very exible in that they are built for a predetermined inference structure or problem-solving mechanism, and the guidance they provide is specific to that inference structure and hard-coded by their designer. This paper focuses on expect, a reflective architecture that supports knowledge acquisition based on an explicit analysis of the structure of a knowledge-based system, rather than on a fixed set of acquisition guidelines. expect's problem solver is tightly integrated with loom, a state-of-the-art knowledge representation system. Domain facts and goals are represented declaratively, and the problem solver keeps records of their functionality within the task domain. When the user corrects the system's knowledge, expect tracks any possible implications of this change in the overall system and cooperates with the user to correct any potential problems that may arise. The key to the exibility of this knowledge acquisition tool is that it adapts its guidance as the knowledge bases evolve in response to changes