Modeling tasks with mechanisms

Abstract

All of the buildings and all of the cars were once just a dream in somebody's head -Peter Gabriel, "Mercy Street," 1986Building a problem solver and acquiring the knowledge needed to operate it are the two central goals of knowledge engineering. To achieve these goals, knowledge engineers construct models of the domain and of the task of interest. The various approaches used for modeling, however, have so far failed to define methods and techniques that can be applied across domains and tasks, and to produce models that can be reused in future applications. In this article, we propose that both of these objectives can be achieved by the use of building blocks called mechanisms. We examine the composition of mechanisms and also show how these mechanisms can be manipulated to construct problemsolving methods. We present PROT~GC-II, a knowledge-acquisition shell that uses problem-solving methods to drive the modeling of tasks, the automatic generation of knowledge-acquisition tools, and the control flow of the problem solver. The modeling of tasks, within the context of P R O T !~G~-I I , is illustrated with two examples: one from the game domain and another from the medical-therapy domain. In addition, we introduce the conceptual basis for a library of mechanisms that serves as a repository of reusable knowledge components.

Reusable Knowledge-Based Components for Building Software Applications: A Knowledge Modelling Approach

“…These proposals include mechanisms (knowledge-based components implementing a basic problem-solving method that carries out a generic task) used in the PROTÉGÉ-II software tool [23], the application kit with solution methods (LISP code fragments implementing basic functions) that is used in the KREST software tool [18], and also the type of components that we propose in this article (called primitives of representation), used within the KSM software tool [8,9]. This type of components presents two main differences with the type of components used in software engineering: (1) they include an internal knowledge-based architecture, with a local knowledge base with a rich declarative representation which increases the flexibility for their adaptation, and (2) they present an important analogy with the descriptive entities used during the formalisation of knowledge models.…”

Towards the Unification of Inference Structures in Medical Diagnostic Tasks

“…As a first consequence of this distinction between levels of computation (knowledge, symbol, and physical) and domains of description (00 and EOO) it is now generally accepted [7,8] that the acquisition of knowledge is not a task of transferring "something" from the human expert's head into the computer program but a constructive modeling task at the knowledge level and in the EOO, together with a corresponding reduction process, from the knowledge level to the symbol level.…”

Generation of knowledge-acquisition tools from domain ontologies

“…The output of dash is a declarative specication of the target tool that can be executed by a run-time system, or, alternatively, compiled into C code. Dash is part of the prot eg e-ii environment, which supports development o f k n o wledgebased systems from reusable problem-solving methods (Puerta et al, 1992;Puerta, Tu & Musen, 1993). Also, the prot eg e-ii architecture includes support for dening and editing domain ontologies.…”