IJDC, Associate Editor, AI, Column, May 1998
I'm Scruffy and at the Knowledge Level
David C. Brown
AI in Design Research Group,
Computer Science Dept.,
WPI, Worcester, MA 01609, USA.
It's good to be Scruffy and at the Knowledge Level! Don't let anyone tell you otherwise!
I mean ``Scruffy'' in the sense introduced in AI in the early 1980's: Neat versus Scruffy approaches to Artificial Intelligence (AI) [Roedel 1987] [Minsky 1990].
Minsky states:
There is no one best way to represent knowledge, or to solve problems, and limitations of present-day machine intelligence stem largely from seeking "unified theories," or trying to repair the deficiencies of theoretically neat, but conceptually impoverished ideological positions. Our purely numerical connectionist networks are inherently deficient in abilities to reason well; our purely symbolic logical systems are inherently deficient in abilities to represent the all-important "heuristic connections" between things -- the uncertain, approximate, and analogical linkages that we need for making new hypotheses. The versatility that we need can be found only in larger-scale architectures that can exploit and manage the advantages of several types of representations at the same time.While the Neats concentrate on mostly pure ``theoretically neat'' approaches, thus gaining detail and precision, the Scruffies deliberately seek a mixture of different methods and representations, allowing for (as Chandrasekaran says) ``extra-logical and even on occasion illogical'' [Roedel 1987] reasoning and representation.
My personal bias, is that the Neats tend to be seduced by the representation itself, and be distracted from the larger and more creative ideas: as Minsky suggests, ``conceptually impoverished''.
That kind of seduction was visible too on the edge of the Scruffy world, when everyone fell in love with rules as a knowledge representation. Many theses and papers proposed schemes to encode extra information in the rules, ways to index and partition them, and ways to influence their use by encoding control information. However, apart from some beneficial results (e.g., the RETE approach to efficient rule activation, and the OPS5 ``contexts'' used effectively in R1/XCON to focus rules on configuration subtasks [McDermott 1982]), most of this activity was concerned with twiddling the representation: the rules themselves became the focus.
In reaction to this, several people started, in different ways, to focus on the ``Knowledge Level'' [Steels & McDermott 1994]. This term, coined by Newell [1982], emphasizes that when we are studying expert tasks, and building expert knowledge-based systems, we should be focusing on what knowledge and what types of knowledge they require, instead of viewing it in implementation terms, such as the representation (e.g., rules) or the programming language (e.g., LISP).
One approach to this challenge was the development of a set of ``Generic Tasks'' (GT) [Chandrasekaran & Johnson 1993] that were task-oriented but domain independent approaches to building knowledge-based systems. Descriptions of both the knowledge needed as well as the characteristic reasoning strategies were provided for tasks including Classification, Hypothesis Assessment and Routine Design [Brown & Chandrasekaran 1989]).
Various people have worked on descriptions of Design under the influence of the Knowledge Level (e.g., [Gero 1990] [Bernaras 1994] [Brazier et al 1994] [Smithers 1998] ). These approaches -- Neat approaches -- only describe the possible types of knowledge involved and their relationships. They attempt to provide a knowledge-level description that, as much as possible, removes explicit reference to the Design process, believing, I suppose, that such references to process refer to the ``implementation''.
But, to me, Design seems to be inherently Scruffy. Describing designing without talking about a mixture of several types of reasoning is too pure -- like describing how to make dinner by only describing the ingredients. I believe that one can and must characterize types of reasoning, and do so at an appropriate level of abstraction, in such a way that the Knowledge Level philosophy can be preserved.
It's good to mention boiling, frying, braising and roasting!
ReferencesA. Bernaras, Problem-Oriented and Task-Oriented Models of Design in the CommonKADS framework, Artificial Intelligence in Design '94, (Eds.) J. S. Gero & F. Sudweeks, Kluwer, 1994, pp. 499-516.
F. Brazier, P. van Langen, P. van Ruttkay & J. Truer, On Formal Specification of Design Tasks, Artificial Intelligence in Design '94, (Eds.) J. S. Gero & F. Sudweeks, Kluwer, 1994, pp. 535-552.
D. C. Brown & B. Chandrasekaran, Design Problem Solving: Knowledge Structures and Control Strategies, Research Notes in Artificial Intelligence Series, Pitman Publishing, Ltd., London, England, 1989.
B. Chandrasekaran & T. Johnson, Generic Tasks and Task Structures: History, Critique and New Directions, Second Generation Expert Systems, (Eds.) J-M. David, J-P. Krivine & R. Simmons, Springer-Verlag, 1993, pp. 232-272.
J. McDermott, R1: A Rule-based Configurer of Computer Systems, Artificial Intelligence, Vol. 19, North-Holland, 1982, pp. 39-88
J. S. Gero, Design Prototypes: A Knowledge Representation Schema for Design, AI Magazine, Special issue on AI based design systems, (Eds.) M. L. Maher & J. S. Gero, AAAI, Vol. 11, No. 4, Winter 1990, pp. 26-36.
M. Minsky, Logical vs. Analogical or Symbolic vs. Connectionist or Neat vs. Scruffy, in Artificial Intelligence at MIT, Expanding Frontiers, (Ed.) Patrick H. Winston, Vol. 1, MIT Press, 1990. Reprinted in AI Magazine, 1991.
A. Newell, The Knowledge Level, Artificial Intelligence, Vol. 18, pp. 87-127.
J. Roedel, The Virtue of Scruffiness, Alumni Magazine, Ohio State University, Columbus, Ohio, USA, March 1987.
T. Smithers, Towards a Knowledge Level Theory of Design Process, Artificial Intelligence in Design '98, (Eds.) J. S. Gero & F. Sudweeks, Kluwer Academic Publishers, 1998.
L. Steels & D. McDermott (Eds.), The Knowledge Level in Expert Systems: conversations and commentary, Academic Press, 1994.
Version: Wed Apr 29 17:41:46 EDT 1998