Marc Linster’s scientific contributions

After a short overview of knowledge acquisition highlights, we review experiences that we had in our knowledge acquisition project. We conclude that automated knowledge acquisition does not work without a documentation of the purpose that the knowledge will fulfill once it is acquired. This can be done for example through a description of a method of problem-solving. The remainder of the paper gives a more detailed account of the motives (outside the actual experiences with KRITON) that lead to these conclusions. After outlining several requirements, we delineate the role of cognitive science research in our current approach.

We view knowledge engineering as a constructive activity that encompasses both model building to make sense and model building to implement systems. We list four properties that we feel are important for environments that support this view on modeling and that exploit the symbiosis of both facets: epistemological modeling primitives, reusable templates, multifaceted modeling, and formal languages. We use the framework of these requirements to introduce the operational modeling language OMOS and to show how it copes with them. Finally, we compare OMOS to two important current developments: PROTG-II and SBF (Spark, Burn, Firefighter). This allows us to situate our work and put it into the context of current research.

MoMo is a language for operationalizing KADS-type models of expertise. It is embedded in Common Lisp such that systems described in MoMo can be developed and run in the Lisp environment. MoMo relies on the Common Lisp Object System (CLOS) and its integration into the Common Lisp type system to describe problem solving methods in a domain-independent way. To connect such a problem-solving method to a particular domain,the abstract types and their generic operations have to be mapped to concrete ones. The semantics of inference structures was to some extent influenced by ideas from colored Petri nets [ Jensen, 1987 ] . This report contains a larger example, the syntax, its interpretation, and the design rationale for MoMo. Contents 1 Background 3 2 A short glimpse on MoMo 3 3 An example: Diagnosis of home stereo equipment 5 3.1 The domain knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Knowledge about inferences . . . . . . . . . . . . . . . . . . . . . . ...

In recent years there has been a shift from traditional expert systems to cooperative systems for workgroups. This shift stems from the realization that designers must consider the workplace's contextual information if they are to create successful applications, rather than developing applications to perform a task in isolation. The traditional expert systems development methods are insufficient to create effective cooperative systems. This special issue focuses on some of the central problems that arise when building cooperative expert systems.

The SBF (Spark, Burn, Firefighter) project began five years ago. Its goal was to develop a framework for making it easier to evolve effective application programs. Its approach was to provide an integrated set of tools to help developers create applications by configuring and customizing reusable software components, called mechanisms. SBF aimed to be usable by both programmers and non-programmers. SBF has undergone major changes several times, motivated by user feedback and data collected in usability studies. The emphasis has shifted from understanding how applications can be built to understanding what assistance is needed in a workplace and how some automation might best be introduced into an integrated workplace. This paper describes how SBF has evolved over the years, and, more importantly, what motivated the major changes.

We describe the Spark, Burn, FireFighter solution to the office allocation problem as defined for the Sisyphus task. The Spark, Burn, FireFighter framework assists a development team with building application programs. The framework pays particular attention to the problems that arise from the nature of real-world tasks: they are messy, filled with details, and change continuously. To overcome these problems, the Spark, Burn, FireFighter approach exploits a problem description of a real-world workplace. This workplace description is at the heart of our approach and integrates all of the development team's activities. It is exploited to assist a development team with extending the description of a workplace, managing the activities in the workplace, describing programming constructs, finding programming constructs that automate some activities in the workplace, customizing those programming constructs, and doing the work.

We summarize the papers submitted for the methods-of-problem-solving part of Sisyphus in 1991 and 1992. We describe a three-dimensional framework to situate and compare the different approaches that were used to solve the office assignment problem. We analyze the approaches by highlighting the building blocks they provide to the model creator, their focus (i.e., conceptualisation or implementation), and the support they provide for special activities in the development cycle for knowledge-based systems.

The paper describes the transition from a first generation knowledge acquisition approach towards a second generation, model-based one. Firstly, we depict the first generation knowledge acquisition tool KRITON with its components interview, protocol, and text analysis and we render the underlying assumptions of the tool. Then, we make a point for second generation, model-based knowledge acquisition took and discuss their architecture. We focus on the role of explicit models of problem-solving methods in automated knowledge acquisition tools and on the guidance that models of methods can provide. We give a short description of the KADS-oriented knowledge-modeling language OMOS that we developed, among others, to analyze the facet of guidance. We combine aspects of the KRITON-based development with features of the modeling language OMOS, thus obtaining a second generation view on knowledge engineering, supported by a special architecture for computer supported model-based knowledge acquisition. Finally, we highlight future developments that exploit the guidance of the method models for automated knowledge acquisition.

We argue that it is important for the development of large knowledge models to integrate conceptual and operational modeling. We show that conceptual models can be operationalized by continuous refinement, without the need for a separate manual and structure-transforming implementation phase. Moreover, we show that such a continuity can be the basis for a fruitful integration of both kinds of modeling in a spiral development cycle. This allows us to integrate the best of both worlds: (1) the sloppiness required by conceptual modeling in order to develop structures unhampered by the constraints of an operational language; and (2) the feedback that an operational language provides for the ongoing model development process by allowing for testing, validating, and analysing the formalized structures of the model. To support our claims, we show how a large conceptual model of cancer-chemotherapy administration benefits from this integrating view on modeling.