R1: a rule-based configurer of computer systems
TL;DR: R1 is a program that configures VAX-11/780 computer systems and uses Match as its principal problem solving method; it has sufficient knowledge of the configuration domain and of the peculiarities of the various configuration constraints that at each step in the configuration process, it simply recognizes what to do.
About: This article is published in Artificial Intelligence.The article was published on 1982-09-01. It has received 1001 citations till now. The article focuses on the topics: Configuration Management (ITSM) & Knowledge-based configuration.
Citations
More filters
01 Dec 1986
TL;DR: A critical analysis of an important part of AI, viz., knowledge-based reasoning is given, and it is proposed that a point of view based on a particular level of abstraction corresponding to t a sks has a number of advantages both in perspicuity and system design.
Abstract: Much of AI can be said to be a search for the "holy grail" of a level of abstraction at which intelligence behavior qua intelligent behavior emerges. Above this level are particulars of the task of domain, and below this level are implementation-specific matters. For example, in a rule-based system such as Mycin, everyone would agree that rules of medicine are not per se matters of AI research. That is, the content of the knowledge based itself is full of domain particulars, while the language in which the rule system is written, e.g., Lisp, is typically thought of as an implementation level. The interest Of a given expert system from an AI point of view is often a matter 1Research supported by Air Force Office of Scientific Research, grant 82-0255. National Science Foundation grant MCS-8305032, and Defense Advanced Research Projects Agency, RADC Contract F30602-85-C-0010. of the level at which it is viewed. Clearly, taking Mycin as an example, all the following points of view are correct: (i) it suggests thereapy for certain kinds of infectious diseases, (ii) it is an embodiment of a diagnostic and therapeutic strategy, and (iii) it is a decision-maker which uses backward chaining to navigate a knowledge base of rules, which connect pieces of evidence to conclusions, and given a collection of data arrives at the most reliable conclusion that can be drawn. Point of view (i) is of limited interest to an AI person (except for one who is temporarily suffering from an infection), and point of view (iii) has been the level at which the system as an AI system -that is, the claim of generality of the underlying approach -has been generally presented. All the excitement surrounding the "knowledge base/inference engine" paradigm, and the idea that knowledge acquisition and explanation can be keyed to phenomena at the rule level emphasizes that the level corresponding (iii) above has been the level of abstraction at which AI interest has been expressed and claims of progress have been made. What of the level corresponding to (ii)? We have for several years worked on the hypothesis that this was indeed an important level of abstraction from the point of view AI; and that knowledge representation, control regimes for problems solving, knowledge acquisition and explanation all can be significantly advanced by looking at phenomena at this level. The purpose of this paper is to give a critical analysis of an important part of AI, viz., knowledge-based reasoning, and to propose that a point of view based on a particular level of abstraction corresponding to t a sks has a number of advantages both in perspicuity and system design. This is not pure theoretical speculation in that researchers in our Laboratory have built many systems and tools based on this framework, but the purpose of this paper is not to describe those systems or tools. It is rather to point to this level of abstraction as a productive level for concentration and to indicate the conceptual advantage of it. Knowledge acquisition, system design, control of problem solving and generation of explanation all are facilitated at the same time, indicating that there is a naturalness to looking for generic phenomena at this. level. 3. A C r i t i q u e of t he R u l e L o g i c F r a m e Level of A b s t r a c t i o n Intuitively one thinks that there are types of knowledge and control regimes that are common to diagnostic reasoning in different domains, and similarly there would be common structures and regimes for say design as an activity, but that the structures and control regimes for diagnostic reasoning and design problem solving will be generally speaking different. However, when one looks at the formalisms (or equivalently the languages) that are commonly used in expert system design, the knowledge representation and control regimes do not typically capture these distinctions. For example, in diagnostic reasoning, one might generically wish to speak in terms of malfunction hierarchies, rule-out strategies, setting up a differential, etc., while for design, the generic terms might be device/component hierarchies~ design plans, ordering of subtasks, etc. Ideally one would like to represent diagnostic knowledge in a domain by using the vocabulary that is appropriate for the task. But typically the languages in which the expert systems have been implemented have sought uniformity across tasks, and thus have had to lose perspicuity of representation at the task level. The computational universality of representation languages such as Emycin or OPS5 -i.e., the fact that any computer program can be written in these languages, more or less naturally -often confuses the issue, since after the system is finally built it is often unclear which portions of the system represent domain expertise and which are programming devices. In addition, the control regimes that these languages come with (in rule-based systems they are typically variants of h y p o t h e s i z e a n d m a t c h , such as forward or backward chaining) do not explicitly indicate the real control structure of the system at the task level. E.g., the fact that R1 [7] performs a linear sequence of subtasks -a very special and atypically simple version of design problem solving -is not explicitly encoded: the system designer so to speak "encrypted" this control in the pattern-matching control of OPSh. These comments need not be restricted to the rule-based framework. One could represent knowledge as sentences in a logical calculus and use logical inference mechanisms to solve problems. Or one could represent it as a frame hierarchy with procedural at tachments in the slots. (It is a relatively straightforward thing, e.g, to rewrite MYCIN [8] in this manner, see [9].) In the former, the control issues would deal with choice of predicates and clauses, and in the latter, they will be at the level of which links to pursue for inheritance, e.g. None of these have any natural connection with the control issues natural to the task. The other side of the coin so to speak regarding control is the foll(~wing: because of the relatively low level of abstraction relative to the information processing task, there are control issues that are artifacts of the representation, but often in our opinion misinterpreted as issues at the "knowledgelevel." E.g., rule-based approaches often concern themselves with conflict resolution strategies. If the knowledge were viewed at the level of abstraction appropriate to the task, often there will be organizational elements which would only bring up a small set of highly relevant pieces of knowledge or rules to be considered without any conflict resolution strategies needed. Of course, these organizational constructs could be "programmed" in the rule language, but because of the status assigned to the rules and and their control as knowledge-level phenomena (as opposed to the implementation level phenomena, which they often are), knowledge acquisition is often directed towards (typically syntactic) strategies for conflict resolution, whereas the really operational expert knowledge is at the organizational level. This level problem with control structures is mirrored in the relative poverty of knowledge-level primitives for representation. E.g., the epistemology of rule systems is exhausted by data patterns (antecedents or subgoals) and partial decisions (consequents or goals), that of logic is similarly by predicates, functions, and related primitives. If one wishes to talk about types of goals or predicates in such a way that control behavior can be indexed over this typology, such a behavior can often be programmed in these systems, but there is no explicit encoding of them that is possible. E.g., Clancey [5] found in his work using Mycin to teach students that for explanation he needed to at tach to each rule in the Mycin knowledge base encodings of types of goals so that explanation of its behavior can be couched in terms of this encoding, rather than only in terms of "Because < . .> was a subgoal of ~ . . ~ . " The above is not to argue that rule representations and backward or forward chaining controls are not "na tura l" for some situations. If all that a problem solver has in the form of knowledge in a domain is a large collection of unorganized associative patterns, then data-directed or goal-directed associations may be the best that the agent can do. But that is precisely the occasion for weak methods such as h y p o t h e s i z e a n d m a t c h (of which the above associations are variants), and, typically, successful solutions cannot be expected in complex problems without combinatorial searches. Generally, however, expertise consists of much more organized collections of knowledge, with control behavior indexed by the kinds of organizations and forms of knowledge in them. Thus, there is a need for understanding the generic information processing tasks that underlie knowledge-based reasoning. Knowledge ought to be directly encoded at the appropriate level by using primitives that naturally describe the domain knowledge for a given generic task. Problem solving behavior for the task ought to be controlled by regimes that are appropriate for the task. If done correctly, this would simultaneously facilitate knowledge representation, problem solving, and explanation. At this point it will be useful to make further distinctions. Typically many tasks that we intuitively think of as generic tasks are really c o m p l e x g e n e r i c t asks . I. e., they are further decomposable into components which are more elementary in the sense that each of them has a homogeneous control regime and knowledge structure. For example, what one thinks of the diagnostic task, while it may be generic in the sense that the task may be quite similar across domains, it is not a unitary task structure. Diagnosis may involve classificatory reasoning at a certain point, reasoning from one da tum to ano
4 citations
21 Nov 2001
TL;DR: This work describes an experiment in which a legacy knowledge system called INTERACTIVE KRITIK is integrated with an ORACLE database and indicates the computational feasibility of method-specific data-to-knowledge compilation.
Abstract: Generality and scale are important but difficult issues in knowledge engineering. At the root of the difficulty lie two challenging issues: how to accumulate huge volumes of knowledge and how to support heterogeneous knowledge and processing. One approach to the first issue is to reuse legacy knowledge systems, integrate knowledge systems with legacy databases, and enable sharing of the databases by multiple knowledge systems. We present an architecture called HIPED for realizing this approach. HIPED converts the second issue above into a new form: how to convert data accessed from a legacy database into a form appropriate to the processing method used in a legacy knowledge system. One approach to this reformed issue is to use method-specific compilation of data into knowledge. We describe an experiment in which a legacy knowledge system called INTERACTIVE KRITIK is integrated with an ORACLE database. The experiment indicates the computational feasibility of method-specific data-to-knowledge compilation.
4 citations
Additional excerpts
...But it is also applicable to systems that have directly led to real applications such as R1 (McDermott, 1982), PRIDE (Mittal et al., 1986), VT (Marcus et al., 1988), CLAVIER (Hennessy and Hinkle, 1992), and ASK-JEF (Barber et al., 1992)....
[...]
01 Jan 1999
TL;DR: This paper details EXPECT’s approach to knowledge acquisition in the configuration domain using the propose-and-revise strategy as an example and examines the possible use of EXPECT as a KA tool in the complex and real world domain of computer configuration.
Abstract: Configuration systems often use large and complex knowledge bases that need to be maintained and extended over time. The explicit representation of problem-solving knowledge and factual knowledge can greatly enhance the role of a knowledge acquisition tool by deriving from the current knowledge base, the knowledge gaps that must be resolved. This paper details EXPECT’s approach to knowledge acquisition in the configuration domain using the propose-and-revise strategy as an example. EXPECT supports users in a variety of KA tasks like filling knowledge roles, making modifications to the knowledge base including entering new components, classes and even adapting problem-solving strategies for new tasks. EXPECT’s guidance changes as the knowledge base changes, providing a more flexible approach to knowledge acquisition. The paper also examines the possible use of EXPECT as a KA tool in the complex and real world domain of computer configuration.
4 citations
Cites background from "R1: a rule-based configurer of comp..."
...These would be a very useful capabilities, since product knowledge changes at a high rate (40-50%/year) is reported for configuration systems such as R1 (McDermott 82) and PROSE (Wright et al. 93)....
[...]
4 citations
01 Apr 1986
TL;DR: Some of the development behind adaptive legged locomotion in "robots" is traced and the organization of such systems for a walking vehicle is examined, briefly outlining research in progress.
Abstract: Technological progress has been made toward achieving adaptive legged locomotion in "robots." Current efforts in this area involve three phases of development; manual operation by an on-board operator, teleoperation, and semiautonomous to autonomous operation. It is the latter that presents the greatest challenge, both in terms of software design and in interfacing a human supervisor with the autonomous expert system. This paper traces some of the development behind these efforts and examines the organization of such systems for a walking vehicle, briefly outlining research in progress.
4 citations
References
More filters
TL;DR: The Rete Match Algorithm is an efficient method for comparing a large collection of patterns to a largeCollection of objects that finds all the objects that match each pattern.
2,562 citations
TL;DR: The MYCIN system has begun to exhibit a high level of performance as a consultant on the difficult task of selecting antibiotic therapy for bacteremia and issues of representation and design for the system are discussed.
619 citations
Proceedings Article•
22 Aug 1977TL;DR: Some of the issues that bear on the design of production system languages are explored and the adequacy of OPS is tried to show for its intended purpose.
Abstract: It has been claimed that production systems have several advantages over other representational schemes. These include the potential for general self-augmentation (i.e., learning of new behavior) and the ability to function in complex environments. The production system language, OPS, was implemented to test these claims. In this paper we explore some of the issues that bear on the design of production system languages and try to show the adequacy of OPS for its intended purpose.
173 citations
01 Jan 1978
TL;DR: In this article, the authors explore the role of conflict resolution in providing support for production systems designed to function and grow in environments that make large numbers of different, sometimes competing, and sometimes unexpected demands.
Abstract: Production systems designed to function and grow in environments that make large numbers of different, sometimes competing, and sometimes unexpected demands require support from their interpreters that is qualitatively different from the support required by systems that can be carefully hand crafted to function in constrained environments. In this chapter we explore the role of conflict resolution in providing such support Using criteria developed here, we evaluate both individual conflict resolution rules and strategies that make use of several rules.
102 citations
TL;DR: The role of conflict resolution in providing support for production systems designed to function and grow in environments that make large numbers of different, sometimes competing, and sometimes unexpected demands is explored.
Abstract: Production systems designed to function and grow in environments that make large numbers of different, sometimes competing, and sometimes unexpected demands require support from their interpreters that is qualitatively different from the support required by systems that can be carefully hand crafted to function in constrained environments. In this paper we explore the role of conflict resolution in providing such support. Using criteria developed in the paper, we evaluate both individual conflict resolution rules and strategies that make use of several rules.
102 citations