In the field of Knowledge Engineering, dissatisfaction with the rapid-prototyping approach has led to a number of more principled methodologies for the construction of knowledgebased systems. Instead of immediately implementing the gathered and interpreted knowledge in a given implementation formalism according to the rapid-prototyping approach, many such methodologies centre around the notion of a conceptual model: an abstract, implementation independent description of the relevant problem solving expertise. A conceptual model should describe the task which is solved by the system and the knowledge which is required by it. Although such conceptual models have often been formulated in an informal way, recent years have seen the advent of formal and operational languages to describe such conceptual models more precisely, and operationally as a means for model evaluation. In this paper, we study a number of such formal and operational languages for specifying conceptual mode...

During the last years, a number of formal specification languages for knowledge-based systems (kbs) have been developed. Characteristics of such systems are a complex knowledge base and an inference engine which uses this knowledge to solve a given problem. Languages for kbs have to cover both these aspects. They have to provide a means to specify a complex and large amount of knowledge and they have to provide a means to specify the dynamic reasoning behavior of a kbs. Nevertheless, kbs are just a specific type of software system. Therefore it seems quite natural to compare formal languages for specifying kbs with formal languages which were developed by the software engineering community for specifying software systems. That is the subject of this paper. Introduction Over the last few years a number of semiformal, formal, and executable specification languages 1 have been developed for describing knowledge-based systems (kbs). These specification languages can be used to ...

View on Propose-and-Revise At an abstract level, the chosen problem-solving method for the configuration of elevator systems can be depicted in an inference structure as shown in figure 10. The circles in the figure denote inference actions, i.e. problem-solving steps. The inference actions propose and revise in figure 10 are subject to further decomposition (indicated by shaded bubbles), i.e. they are an abstraction of more detailed levels of inference structures (see the following subsections). Boxes indicate roles which supply input to inference actions or collect their output as indicated by arrows. KARL distinguishes three types of roles: Views (a box supplemented with a small triangle pointing upwards) are used to deliver knowledge from the domain layer for the reasoning process. Terminators (a box supplemented with a small triangle pointing downwards) are used to write results of the problem-solving process back to the domain layer. They are used to rephrase the generic terms ...

In this paper we will present a proposal for a process model for MoMo. The term "MoMo" stands here for the development methodology that has been (implicitly) behind the language MoMo [WVL + 92]. The methodology is implicit in the sense that there are some ideas, commonly accepted by the MoMo development team members (confer MoMo's design rationale) but there exists until now no explicitly specified process model (aside from a sketch in [VV93]. After an introduction into the graphical notation (Data Flow Diagrams DFDs), we specify a series of diagrams as a model for MoMo's knowledge engineering process and discuss them in detail. The process model is strongly reuse-oriented, i.e., it uses repositories of Interpretation Models IMs, Domain Models DMs, and implemetational mechanisms to a large extent. Finally, we give a short comparison with related process models and identify in a summary the process steps where reuse of knowledge and code (which are assumed to be available in repositor...

ions In many domains, human experts employ data abstraction as a technique for reducing a large data set. Data abstraction is a powerful method that limits the search space and also reduces the size of the differential. Introducing finding abstraction in the generate-and-test model requires the specification of one additional function abstract which takes as input a set of findings and produces a new, more abstract, finding (see Fig. 8.6). From the taskknowledge point of view, abstraction typically has a recursive structure. An abstracted finding can be the input for another invocation of the abstraction knowledge source. finding hypothesis observable set of observables associate specify-1 obtain select-1 conjectured finding specify-2 solution select-2 finding select-3 finding abstract new hypotheis test observable new evidence abstract finding focus trigger specific finding FIGURE 8.6: Introducing finding abstractions Clancey describes three types of abst...

In this paper, we characterize the relationship between abstract problem-solving methods and the domain-oriented knowledge bases that they use. We argue that, to reuse methods and knowledge bases, we must isolate, as much as possible, method knowledge from domain knowledge. To connect methods and domains, we define declarative mapping relations, and enumerate the classes of mappings. We illustrate our approach to reuse with the PROTG-II architecture and a pair of configuration tasks. Our goal is to show that the use of mapping relations leads to reuse with high payoff of saved effort.

Abstract. The sheer complexity and number of functionalities embedded in many everyday devices already exceed the ability of most users to learn how to use them effectively. An approach to tackle this problem is to introduce ‘smart ’ capabilities in technical products, to enable them to proactively assist and co-operate with humans and other products. In this paper we provide an overview of our approach to realizing networks of proactive and co-operating smart products, starting from the requirements imposed by real-world scenarios. In particular, we present an ontology-based approach to modeling proactive problem solving, which builds on and extends earlier work in the knowledge acquisition community on problem solving methods. We then move on to the technical design aspects of our work and illustrate the solutions, to do with semantic data management and co-operative problem solving, which are needed to realize our functional architecture for proactive problem solving in concrete networks of physical and resource-constrained devices. Finally, we evaluate our solution by showing that it satisfies the quality attributes and architectural design patterns, which are desirable in collaborative multi-agents systems.