Census data, site descriptions, transportation statistics, activity constraints, economic criteria, and material specifications are all part of the bulky dossier of design information necessary for any urban design project. The information burden is fantastic. What usually happens in most design procedures is that a handful of criteria are chosen and thoroughly developed; all the remaining information relationships are expected to fall into place, or else residual issues are crammed into unsuspecting receptacles. Or in a gesture of design fatalism, accepting the unfeasibility of it all, a group of parallelepipeds are contrived and refined to accommodate as well as possible the internal demands of some institution. The problem and the result are commonplace—look at your own city.
An architect’s role in urban design requires a complex information supply with characteristics of retrieval, labeling, and interassociation. But machines are good at this. Though there are technical problems and real computer-programming issues, machines can respond to and have access to millions of billions of bits of information. It is estimated (Servan-Schreiber, 1967) that the number of all letters in all words in all books in all libraries in the world exceeds one thousand trillion (1,000,000,000,000,000). J. W. Senders (1963) estimates that the current growth rate of this store is about four hundred thousand letters per second. Even a modest architect might assume that he needs some of this store.
In the human nervous system, information genuinely constitutes authority (McCulloch, 1965). In design, however, abundant data can confer prestige on mediocre designs, especially when facts arrive from the unequivocating computer. Data can be prepared to support any design if the selection of evidence is limited to that which favors the cause. “Poor data and good reasoning give poor results. Good data and poor reasoning give poor results, poor data and poor reasoning give rotten results” (Edmund Berkeley, 1967).
A machine could store relevant information in many ways. Relational and associative data structures, for example, store classes of items by properties of similarity and retrieve them by querying for that which has “this and that, but not those.” Another structure uses lists of attributes that point “fingers” at members that have the same attributes, thus tying threads among the various members of the data structure. Still another (and simpler) method is a matrix organization where rows and columns of entries are entered and looked up by addressing a two-, three-, four-, or n-dimensional table.
But in architecture, most information has a natural disposition—the positional relationship—which can help to organize the proliferation of data. Design manipulations invariably wield locational data expressed in terms of position, distance, area, or volume. This natural geometrical referencing suggests a data structure where each physical location (solid or void, building or open space), to as small a grain as possible, would describe itself in an autonomous fashion (even the voids!). This has strong implications, especially the Euclidean and redundant nature of geometrically related data.
Information search, by either designer or machine, would occur for the most part in a localized fashion, investigating by proximity (by neighborhood, by street, or by immediate adjacency). The thrust of this sort of data-structure argument is that information is treated locally, by positions, and less globally, by attributes. Thus, design information is retrieved by geometric (topical) search rather than by intersecting generalities.
Such a position-oriented storage vehicle may be unique in the physical design problems of the urban environment. In a library reference system, this type of information structure is ridiculous; books are not categorized by their position on the shelf, books are redundantly classified by name, author, subject, publisher, and so forth. Unfortunately, good library data structures are all too often foisted onto design problems.
One particular design information system—DISCOURSE—warrants mention, as it exemplifies a flexible data structure that combines the assets of associative and matrix organizations, attribute and geometric searches. This research team (Fleischer et al., 1969, and Porter et al., 1969) uses the M.I.T. time-sharing facilities to interact (no dialogue) with data files and print the results in tabular or map format. It is a problem-oriented language that derives flexibility from (1) providing multiple data structures for both local and global interrogation, and (2) providing a “meta-language” that allows the designer to create his own search techniques. The reader must understand, however, that DISCOURSE is not computer-aided design within our definition. It is an excellent computer system that manipulates bits of design information, that is, information that has been explicitly given to the machine by the user.
Another example is MEMORY, an information storage and retrieval system that is being studied within M.I.T.’s Urban Systems Laboratory. MEMORY’S dominant feature is its “forgetting convenience.” It is a way of storing events in neural nets that are highly redundant and, at first, rather random. Over time and through repetition or the lack of it, events become, by the strength of traces left in memory, either stronger remembrances or fainter recollections. At the onset of such a system, for any given input the output will be mostly garbage. Overtime, the responses should gain meaning with respect to both the input and the relevancy (defined by time) of the input. The reason that this experimental work is important to an architecture machine is that the design process is an evolution of (1) the product, the form; (2) the process, the algorithms; (3) the criteria, the information. MEMORY addresses itself to item number three.