Gerry's Home Page Preliminary Materials Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Bibliography Appendix

Sec 7.2

7.2.    Perspectives for Deliberation

An adequately expressive system of knowledge representation for supporting interpretation in design requires (among other things) a perspectives mechanism. This is a conclusion that can be drawn from many of the related systems considered in this chapter. The general need to mix tacit and explicit support means that the perspectives must be easy (natural, transparent, tacit) for designers to select, change, create, and merge, while providing an explicit structure (e.g., a browsable hierarchy of well-defined inheritance relationships) for organizing alternative versions of domain knowledge.

The systems reviewed suggest three ways in which alternative versions of domain knowledge must be distinguished in order to support design:

*    Domain knowledge is different in different times and conditions. For instance, kitchen design is different on the Earth, on the moon, and on a space station due to gravity and atmospheric conditions. Each of these can be captured in a design tradition. Domain knowledge also changes as technology develops and as new ideas come along. Design traditions can evolve along multiple branches, creating a tree of alternative versions of knowledge.

*    In their work, designers view various aspects of their task or their partially designed artifact. There are, for instance, various technical aspects of a design (plumbing, electrical, structural, aesthetic), as well as a wealth of different theoretical or argumentative aspects from which to interpret the task. Each of these aspects brings different domain knowledge into play.

*    In collaborative design, several people each elaborate their own personal viewpoints. The individual viewpoints incorporate shared knowledge and also contribute to a shared group viewpoint. Much of the detailed work of a design team is done by individuals working within their own viewpoints. The deliberative processes of groups then consider ideas from the individual viewpoints and create a shared viewpoint that modifies those individual viewpoints to provide a basis for continued work.

Systems for design that do not support interpretation by providing a perspectives mechanism in effect proclaim that there is a single body of domain knowledge. That is, they make an implicit choice of a tradition, an aspect, and a viewpoint from which design is to be carried out. Of course, they may include alternative choices in an issue-base or in a catalog of design suggestions, but they do not support the designer in making a decision about what tradition or aspect to view things from. More importantly, they do not allow the designer to build an individual viewpoint and to select what other viewpoints to share knowledge from. A perspectives mechanism provides the means with which to build alternative versions of the knowledge base corresponding to traditions, aspects, and viewpoints. A number of perspectives mechanisms to support traditions, aspects, and viewpoints have been proposed in the literature. The three classes of perspectives are considered one at a time in this section.

Perspectives for traditions. Recent work on design environments indicates a strong need for support of alternative traditions. The end-user modification capability of Janus (Girgensohn, 1992) allows designers to add new kitchen appliances to the palette and to define new critic rules. This allows for a cumulative growth in the represented domain knowledge. But, suppose that different designers want different definitions of the same critic rule. For instance, they may think that the work triangle should be different for residential kitchens, kitchens for disabled people, and commercial or industrial kitchens. To support these variations simultaneously without causing a proliferation of alternatives that the designer must cope with explicitly, a perspectives mechanism would be useful. Such a mechanism would allow the development of various traditions of kitchen design, like “disabled”, “commercial”, etc. Then all the palette items, catalog examples, issue-base entries, domain distinctions, and critic rules relevant to a given tradition would be grouped together in their own perspective. Section 9.1 presents a scenario showing how lunar habitat designers can use Hermes to work with information in multiple perspectives for traditions.

A perspectives mechanism for traditions would facilitate the evolution of the knowledge base. Developers of design environments have proposed a model of evolutionary growth that mixes tacit and explicit development by means of alternating phases of system usage and reseeding (Fischer, et al. 1993c). (See Figure 7-3.) They think of the use phases as periods in which knowledge is entered in predominantly informal formats (e.g., natural language text). Then, during a phase of reseeding of the knowledge base, knowledge engineers would help to formalize this new knowledge, explicating and operationalizing it in, for instance, formal (computer interpretable) critic rules. (Shipman, 1993). A perspectives mechanism would allow new knowledge to be organized into alternative traditions by defining perspectives in which to group related information. To some extent, the use of perspectives for these traditions would allow users to add their informal knowledge within the appropriate perspectives in which they were working, so that the organization would take place naturally. Section 9.3 describes mechanisms in Hermes for supporting knowledge evolution by creating and merging perspectives.

 

Figure 7-3. Growth in total and formalized information.

From Fischer, et al. (1993c, p.5).

A mechanism for supporting perspectives for traditions was proposed by Mittal, et al. (1986) as part of the Pride design environment. They called their technique “virtual copying of networks.” They noted that in many systems knowledge is represented by networks of inter-connected sets of objects. Closely related alternative versions of these networks can be created efficiently by using the original network as a prototype and defining alternatives by pointers to this original where there are no changes. Only differences have to be represented by new data in memory. This “copy-on-write” strategy is a standard approach in many versioning systems, CAD graphics, and even operating systems (Fitzgerald & Rashid, 1986). In Pride, domain knowledge is represented in a design net, from which alternative virtual copies (of different traditions) are made. Design work can then proceed in different versions of the knowledge base:

Specific designs are created by making a virtual copy of this design net. . . . Alternative designs can be explored by making a number of virtual copies of a partially completed design, and continuing operations in the virtual copies. Versioning in this way allows comparison of alternative designs, something not supported by all versioning systems. (Mittal, et al., 1986, p.164)

Most versioning mechanisms are file based. They can save the historical state of a design at a given time to a file on disk for later reference. In contrast, a perspective mechanism must maintain alternative versions of a knowledge base or of a particular design within the design environment, so designers can move from one tradition to another. This is achieved by the virtual copying technique. Unfortunately, the mechanism described by Mittal, et al. is specific to the Loops programming language and involves modifying the implementation of this language. McCall (1991/92) proposed a technique for implementing this approach to virtual copying of issue-base networks in hypermedia to support perspectives for traditions. This proposal has been worked out in the Hermes substrate (see Chapter 9).

Perspectives for aspects. Rittel argued that people bring different interests to bear on design tasks and view the problems under these different aspects (see Section 2.2). Deliberation requires the confrontation of arguments made by people with these different interests. So Rittel’s Ibis and its subsequent versions have put the conflicting arguments into one structure where they can be compared. But this makes it hard to see which arguments belong together within a common perspective. If one wants to suspend deliberation for a while and work within a commitment to a given perspective, that is not supported by Ibis. The Ibis structure also does not represent relationships among perspectives as such (since the perspectives are not themselves represented, but only their elementary arguments). Thus, one cannot determine if one perspective incorporates others or modifies only particular arguments of another perspective. In Hermes, perspectives can be defined to organize any collection of knowledge in the system. Inheritance relations can be established among perspectives so that information is virtually copied from one to another.

The discussion of design in Part I repeatedly stressed the importance of viewing aspects of a design problem. In Chapter 2, Schön particularly emphasized that designers continually move from focusing on one aspect of a design artifact to another. In Chapter 3, the aspect of habitability and privacy became determinant of the designing—the problem with the NASA knowledge base was that it largely ignored this aspect. In Chapter 4, the idea of interpretive perspectives is key to Heidegger’s analysis of interpretation; all interpretation, according to this analysis, takes place focused on a certain aspect of that which is interpreted.

It has been experimentally demonstrated that it is often helpful to consider one aspect of a problem at a time. Redmiles (1992) showed the usefulness of this for the interpretation of examples in computer programming problems. His Explainer system allows a user to switch between several alternative aspects of problem explanations: graphical, mathematical, programming language representations, etc. The system uses a perspectives mechanism for viewing the knowledge base under a given aspect. While the user can select which of several perspectives to view, the choice is limited to a fixed set of perspectives. The mechanism here does not allow users to create new perspectives as versions of existing ones and modify them in line with their interests.

Krl (Boborow & Winograd, 1977)—a sophisticated computer language for representing knowledge—provides a more flexible perspectives mechanism. Krl is based on the following principles (among others):

*    A knowledge representation language must provide a flexible set of underlying tools, rather than embody specific commitments about either processing strategies or the representation of specific areas of knowledge.

*    Reasoning is dominated by a process of recognition in which new objects and events are compared to stored sets of expected prototypes.

*    A description must be able to represent partial knowledge about an entity and accommodate multiple descriptors that can describe the associated entity from different viewpoints.

Krl provides a syntax for describing things in terms of prototypes having default characteristics (slot values). For instance, a lunar habitat ward room could be described as a public area, a meeting space, or a large room. In each of these descriptions, different characteristics would be specified. Users of Krl can define new aspects of things by defining prototypes. This does offer a flexible, extensible system for describing things from aspects. However, it is too fine-grained to provide a mechanism for organizing systems of perspectives. It allows users to view different aspects of a given object, but does not support the defining of perspectives which apply to many or all objects, as in Hermes.

Perspectives for viewpoints. In the first versions of Janus, the issue-base component was named “Viewpoints”. By this, the developers recognized the need to support perspectives for aspects. However, Janus has never had a mechanism for distinguishing or organizing different people’s viewpoints. While the Phidias project recognized the need for supporting perspectives for traditions, neither Janus nor Phidias have considered supporting the perspectives of individuals or design teams. As seen in Chapter 9, this is an important use of perspectives in Hermes.

 It is clear that collaborative work in innovative areas involves dynamics among individual and group perspectives. The Spider system (Boland, et al., 1992) is a software environment for enriching communication within “learning organizations”, i.e., less hierarchical, more network-like organizations able to cope with changing tasks, technologies, and environments. The developers of this system argue for the importance of mechanisms to support the sharing of perspectives:

The impromptu, ad hoc nature of the understandings the decision makers wish to represent requires flexibility in both the representational structures made available and in the ways these structures can be created, shared, and modified. In creating an environment to foster richness of communication through the sharing of perspectives, there are two primary representational issues to be addressed: 1. What are the structures to be used in the formation of a perspective? 2. In what ways and through which tools should users be able to present their perspective for their own introspection and for the use of others? (p.309)

They claim that structured decision aid systems like Ibis and Drl, which provide powerful representational tools, “orient the user to a mathematical modeling paradigm that is neither conducive to flexible, impromptu thinking nor amenable to the rich communication between colleagues” (p.310). Rather, what they think is needed is a set of mechanisms that allow the user to easily build and modify a layered understanding of the situation. Spider provides a set of tools to do this within the domain of organizational management, producing linked networks of spreadsheets, graphical browsers, and textual annotations. These networks are considered perspectives. The contribution of Spider is to emphasize the need for some kind of perspectives mechanism and to stress the importance of making its interface easy enough to support tacit thinking rather than just explicit, mathematical modeling. Unfortunately, Spider is not in the domain of design.

Perhaps the most concerted effort to represent design alternatives was that of the Pie system (Goldstein & Boborow, 1980). Focusing on design in the domain of software programming, the authors of Pie call for a “contexts” mechanism to support the flexible examination of alternative designs:

All designers create alternative solutions, develop them to various degrees, compare their properties, then choose among them. Yet most software environments do not allow alternative definitions of procedures and data structures to exist simultaneously; nor do they provide a representation for the evolution of a particular set of definitions across time. It is our hypothesis that a context-structured database can substantially improve the programmer’s ability to manage the evolution of his software designs. (p.19)

The context mechanism in Pie is complicated in two ways. (1) Contexts (which support perspectives for viewpoints) are sequences of layers, where layers are saved states (versions). (2) Layers can be saved by the user or by the system. Once saved, a layer cannot change, although contexts can evolve by adding new layers. The contexts and the layers are nodes in the knowledge representation network itself, rather than separate files, so they can be accessed during the retrieval of information.

Pie supports personal viewpoints through the convention that different designers place their contributions in separate layers. Shared viewpoints can be created through the merging of two designs in a new layer. The designers of Pie do not claim that such a merger is trivial for complex designs. Pie does not eliminate the complexity and the need for extensive user intervention, but “it does provide a more finely grained descriptive structure than files in which to manipulate the pieces of the design. Layers created by a merger have associated descriptions in the network specifying the contexts participating in the merger and the basis for the merger” (p.5).

The context mechanism of Pie provides support for perspectives, but at the cost of increased cognitive overhead, i.e., a demand for more explicit understanding of relationships among contexts. The developers tried a number of responses to this problem through interface features: (1) a way for a user to view two contexts simultaneously, with differences highlighted; (2) the use of a metadescription to specify default selections of contexts for saving and retrieving information; (3) the option to turn off the context mechanism. They conclude that “all three of these strategies have proved useful in some circumstances, but it remains an important research goal to make the context machinery available to the user in a convenient fashion” (p.15). This is similar to the approach in Hermes, except that Hermes perspectives are less complicated and rigid than the Pie layers. Also, a number of system methods have been defined for supporting the merger of information from multiple perspectives (see Section 9.2).

Systems like Pride, Spider, and Pie have responded to the need to develop mechanisms to support perspectives. In each case, they provide a formalism that raises and addresses certain important issues of functionality. They also point to the difficulty of making it easy (i.e., natural, transparent, tacit) to take advantage of the perspectives mechanism. None of these systems has solved the problem of how to support perspectival interpretation in cooperative, innovative design within a domain like lunar habitat design. However, all of them have contributed ideas for the perspectives mechanism in Hermes (Chapter 9).

Go to top of this page

Return to Gerry Stahl's Home Page

Send email to Gerry.Stahl@drexel.edu

This page last modified on January 05, 2004