domain knowledge from the application experts. Our explicit goal in the PROT?G?-II project[29] is to develop a framework for automating the generation of KA tools based on the knowledge roles defined by the problem-solving methods that are assembled and configured from reusable components [26]. We have built an environment for custom-tailoring problem-solving methods from a library of methods and method subcomponents (called mechanisms), and from a library of domain ontologies that define terms and relations commonly used in application domains. To assemble an application, a developer analyzes the requirements of the problem to be solved, selects the method and mechanisms for the task and subtasks of the problem, custom-tailors a domain ontology into an application ontology that incorporates the representation requirements of the selected methods, and defines mapping relations that specify the correspondence between the knowledge roles of the configured problem-solving method and elements of the application ontology (Figure?1).

To generate a KA tool for acquiring application-specific knowledge for a task that will be automated using a problem-solving method that is constructed from small-grained mechanisms, the developer must find some way of integrating the disparate knowledge requirements of the selected mechanisms. In recent years, we have been exploring the use of the application ontology as the basis of generating the KA tool. In this approach, the problem of assembling a coherent KA tool from the configured problem-solving method is transformed into the more manageable problems of (1) mapping the knowledge roles of the mechanisms that make up the configured method to the ontology of an application, and (2) defining a dialogue structure based on that application ontology.

We have developed a tool set to support this methodology of knowledge-based system development and KA tool generation. The tool set allows us to edit ontologies, create specifications of KA tools, and automatically generate domain-specific KA tools. Using this tool set, we have applied successfully this methodology to several applications where the problem-solving methods are unitary [11] [31] . In this paper, we describe how we have extended the methodology by applying it to the domain of protocol-based therapy planning, where the problem solver is comprised a configuration of multiple methods and mechanisms. The resulting problem solver forms the decision-support component of the THERAPY-HELPER (T-HELPER) system [27] .

In this paper, we review the PROT?G?-II conception of knowledge-based application development and the roles that ontology definitions, problem-solving methods, and mapping relations play in it (Section 2). Then we discuss the PROT?G?-II library of problem-solving methods, and illustrate the process of method configuration, showing how the ESPR problem-solving method can be configured from underlying mechanisms (Section 3). Finally, we describe how a KA tool and run-time system are generated from the configured method and application ontology (Sections 4 and 5).

2. Ontologies, Problem-Solving Methods, and Mapping Relations

In the PROT?G?-II development environment, we presuppose that the developer, probably working with one or more application experts, has analyzed the requirements on the application and the role it is to play in an organization. She has identified the producers and consumers of the application's inputs and outputs and the structure of available domain knowledge. PROT?G?-II does not provide a tool that supports the analysis of the task to be automated and how it is to be situated in the workplace; instead, the PROT?G?-II environment provides tools for formalizing the domain knowledge, for representing the tasks to be solved by the application, and for selecting and configuring methods for solving the tasks (Figure?1).

In the PROT?G?-II environment, the basic assumption is that the expertise necessary to solve the problem can be divided into three classes: (1) procedural problem-solving knowledge, (2) domain ontology, defined as the schema of domain knowledge describing entities and relations in the domain [16], and (3) the detailed domain knowledge that instantiates the schema of the domain ontology [25]. In PROT?G?-II, we hypothesize that the procedural problem-solving knowledge can be formulated as a collection of domain-independent methods and mechanisms that are potentially reusable, and that parts of domain ontologies and detailed content knowledge similarly can be reused