Indexing Evaluations of Buildings to Aid Conceptual Design

Abstract

The cognitive model underlying Case-Based Reasoning (CBR) has implications for human performance on many tasks, and the technology developed in CBR research can be turned to enhancing performance. For all case-based systems, effective memory retrieval depends on a successful assault on the indexing problem. But demands on indexes may be different, and in some ways, more stringent, for aiding systems than for autonomous probleln-solving systems. This paper report, s on the evolution of an indexing scheme intended to retrieve lessons for architects working on conceptual design of buildings. It illustrates, by example, the process of designing indexing systems, and the demands peculiar to indexes for aiding systems. Finding Experiences for Experts It is the norm for expert performance in cognitively challenging tasks to depend on extensive experience. Researchers in the AI paradigm of Case-Based Rea.soning (CBR) have been building computational models that account for this fact, and have aimed to produce systems that perform effectively by relying on records of past experiences [Hammond, 1989; tlinrichs, 1992; Koton, 1988; Mark, 1989]. More recently, insights gleaned from a decade of CBR research have been turned towards the problem *Many people have worked on the development and conception of the system described in this paper. Janet Kolodnet and Craig Zimring have shaped this project from the start. Richard Billington, our research programmer, has been a constant collaborator throughout. The Archie-II team also includes Kadayam Vijaya, Ali MMkawi, Ellen Do, and David Brogan. Interviews with architects have been invaluable; the architects included Lane Duncan, RuNs Hughes, Michel Lincolt, and Von Rivers. This work has been supported in part by the Defense Advanced Research Projects Agency, monitored by ONR under contract N00014-91-J-4092. All views expressed are those of the authors. of building systems that aid humans in performance of real-world tasks [Schank el al., 19891; Ferguson et al., 199i]. At Georgia Tech, we have been focusing on design ¢asks such as architecture, engineering, and lesson planning [Domeshek and Kolodner, 1992b; Domeshek and Kolodner, 1992a; Chandler and Kolodnet, 1993]. We are attempting to produce what we call Case-Based Design Aids (CBDAs) systems that help human designers by making available to them a broad range of critiqued designs that can serve to highlight important design issues, to explicate abstract design guidelines, and to provide suggestions or warnings about possible design solutions. Any system that bases its performance on the selective use of items from a large memory must find some way to organize that memory so that the right items can be found at the right time. In CBR, this problem of how to ensure effective selective retrieval goes by the name of ~he indexing problem, and has long been recognized as one of the key issues in the field [Schank, 1982; Hammond, 1989; Domeshek, 1992]. Research has provided some insight into how this challenge must be addressed, and has produced a sampling of exemplary indexing systems for particular domains and tasks. This paper reports on the development of an indexing system for one of our CBDAs Archie-II an aid for conceptual design in architecture. The story we have to tell of the evolution of this indexing system is interesting for several reasons. First of all, there has been relatively little work in the CBR community on indexing systems for physical artifact design tasks. Secondly, because we have been designing indexes for an aiding system we have had the burden and the opportunity to grapple with cases of far greater complexity than is possible when working on autonomous reasoners; the domains in which it is practical to build autonomous systems are necessarily much less complex than those in which humans routinely engage (and in which humans are likely to need aid). Finally, it is an interesting question to what extent the demands of indexing for autonomous and aiding systems may differ; the information available in situation descriptions (which is thus information easily available for indexing 26 From: AAAI Technical Report WS-93-01. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved. to past experiences), may be different when a system is engaged in problem solving than when it is responding to a user’s queries. 1 In the context of an aiding system, the indexing problem shades into an HCI or interface problem, and in the face of a usefully complex domain such as conceptual design of buildings, tile usability problem is exacerbated. What is required to succeed here is an understanding of the processes used by our users: how do architects think about their task during the early stages of design? Indexes to Design Lessons The first thing to note when considering how to index design cases for architects is that buildings are probably not the right units of storage and retrieval. Buildings are too big and complex to be designed as one piece; instead there ave many small decisions that go into a building design, and what would best serve an architect are lessons about which issues are importa.nt, how to address these ilnportant problems, and what outcomes are likely. Thus, the primary unit of mernory in Archle-II is the lesson-bearing story. As an exampie, consider the following story [Building Diagnostics, 1988]: The location of the main lobby iT~formation desk in the Bristol County Courthouse is inconvenient and makes it difficult for people to find their way. The desk is located in the telephone office, which is off to the left of the main lobby entry. There is a .small sign on the telephone office indicating that it is also the i~formation desk, but on first entering the courthouse there is no immediate indication where to go for information. ~ Since the items being indexed are stories that teach lessons about design issues, it is appropriate that indexes to these stories center on design issues. But issues vary from one part of a building to another, and even pervasive issues, such as efficient circulation may vary significantly in their implications throughout the building. Accordingly, our stories tend to focus on how an issue plays out in some part of a building, and thus our indexes must also specify the relevant parts. Issues also tend to arise at different times during the life of a building: some are important during construction, others during use or renovation. Likewise, not all issues affect all of the stakeholdcrs in a building: some are of most importance to the owners, others to long term residents, and still others to occasional visitors. 1An aiding system looking over a user’s shoulder, and trying to explain aspects of the user’s problem solving process, likely results in still ditferent sorts of information being easily available for indexing. 2Note that Archie-II’s stories are always shown with a presentation (usually graphic) of the artifact being discussed, and are generally accompanied by an illustration that amplifies the point being made in the text. With one final distinction, this analysis of features that differentiate issues provides an outline for our indexes. We recognize two different ways of slicing a building into p~rts: spatially and functionally. Spaces are physically localized building chunks such as floors, wings, or offices. Functional systems such as the electrical and plumbing systems may be distributed throughout a building and are defined in terms of their purpose. So we recognize five primary dimensions as relevant to describing the point of a story with a simple lesson: ̄ Issue: Goal to be achieved by the artifact’s design ̄ Space: Part of designed artifact defined spatially ̄ System: Part of designed artifact defined functionally ̄ Stakeholder: Role with respect to artifact defining a point of view on the issue ̄ Life Cycle: Part of artifact’s history when the issue matters A combination of some subset of these descriptors is sufficient to identify a single point that might characterize the lesson of one of our stories (thus serving as a memory label), or might express a user’s browsing interests (thus serving as a retrieval probe). But often, a story is interesting because of what it says about the interaction between issues. In one courthouse, the prisoner holding area was located far from the courtrooms, which led to a desirable lack of noise in the court, but also contributed to security problems when the prisoners were being transferred through the building. Stories that address the interaction between issues are best indexed by a pair of the five-featured structures above. The index outline just sketched, whether used singly or in pairs, does not say much about what sorts of issues, spaces, systems and so forth we will have to represent. It is essentially a road map to the work required for a fully specified indexing system. To give a sense for the how such a system is developed, this paper will concentrate on just one of these dimensions: spaces. Designing an Indexing Vocabulary Designing an indexing vocabulary is an exercise in exploring the possible descriptions of objects, concepts, and relationships in the domain, and settling on a system that meets several criteria [Kolodner, 1993]: 1. Relevance: Index vocabulary must capture those aspects of situations that indicate when one is relevant to another (with respect to a task or tasks). This is just a baseline, common sense guide to help decide what sorts of features ought to be included in an indexing vocabulary. 2. Extent: Index vocabulary must be sufficiently extensive to describe an existing or expected corpus of

Extracted Key Phrases

Cite this paper

@inproceedings{Zacherl2002IndexingEO, title={Indexing Evaluations of Buildings to Aid Conceptual Design}, author={Anna L. Zacherl and Eric A. Domeshek}, year={2002} }