Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
5 FUTURE DIRECTIONS FOR THE INTEGRATED DATA BASE INTRODUCTION The working group on future directions for the integrated data base (IDB) reviewed the prototype IDB demonstration and concluded that, while it serves an educational mission, it does not convey the abstract, decentralized communications concepts inherent in the IDB. The group believes that the demonstration does not epitomize the essence of an IDB, nor does it validate key IDB issues. The group recommended that the Woods Hole Workshop activities conducted since 1983 should be brought to closure, and the results should be communi- cated to industry and the public sector with a view to obtaining commitments for future work. The group stressed the need to leverage the IDB work being carried out by other industries. Consequently, the group developed: A. An outline of the IDB concepts with the intent that they be developed by the Committee on Integrated Data Base Development for communication to industry and the public sector, B. An explanation of some key issues that need further work and validation prior to development of an IDB, and C. A description of some new processes that would be possible as a result of an IDB. Members of the working group were: Mary Oliverson (chair), Harold Borkin, Earl Mark, Dan Reynolds, and Si Simonsen. A. INTEGRATED DATA BASE CONCEPT System Architecture Potential users of the IDB will not have a common set of hardware or software, nor will they be willing to acquire or convert to a common system. They will be geographically dispersed, and to centralize their data bases at some distant location would mean loss of control. They may look to the IDB as a means of improving productivity, but a major conversion investment (before any benefits are realized) would be considered too high a price to pay. Therefore, the concept of a 49
50 centralized, homogeneous (one type of hardware and software) IDB is virtually impossible. Achievement of a conceptual IDB in a heterogeneous, distributed environment will place significant demands on effective communications to provide linkages between the many sources of information viewed as logical parts of the IDB. This is consistent with and evidenced by the emerging technological evolution of local and wide area networks to integrate heretofore islands of automation. This type of communica- tions will also offset much of the manual re-entry of data produced by one system into another, so that a particular phase of the building process can be accomplished more effectively. User Organization Size The IDB must offer benefits to all types and sizes of organiza- tions. Elimination of small professional firms, for example, would have a detrimental effect on the creative and competitive aspects of building design. The small architectural firm need not be precluded from participating even if its total automation capability is limited to a microcomputer or a single graphics workstation. The hetero- geneous, distributed nature of the IDB provides a means of including all interested organizations as participants and contributors. Data Base Management Facilities The IDB is based on the concept of a comprehensive set of data base management capabilities including, but not limited to: ⢠Data security--means to control access and use of data, and monitoring threats to data in the IDB by unauthorized persons; no data are lost or changed, ⢠Privacy--controlled access to data that are used to develop aggregate data, ⢠Data integrity--that quality of data, and the associated pro- cesses that ensure the consistency, reliability, accuracy, and preser- vation of data maintained by the IDB; data derived from information in the IDB may be stored or rederived, depending on the complexity of derivation and likelihood of downstream use; stored or computed data that accurately reflect the state of the project at that time, ⢠Configuration control--the set of processes that address maintenance of integrity and control of information as they evolve throughout the building process; included are currency, version control, revisions, authorization, approval reviews, and release status (the as-designed, as-planned, and as-built sequence), and ⢠Dictionary/directory--that capability that defines the "meaning" of data items and provides a means of locating needed information; it must include resolution of the thesaurus, as well as the multiple occurrence of a given name phenomena (such as homonyms and synonyms) that will occur.
51 These data base management capabilities are considered an essential part of the environment in which applications will be developed, but should not be considered part of the applications. Data Deterioration Since the IDB must exist over a long period of time, provision must be made for the fact that the quality of data deteriorates over time. This deterioration can take several forms. The most common form concerns stored data that does not reflect the current condition of the facility. For example, in a case where office partitions have been moved and space assignments have changed, the designed performance values no longer reflect the current performance of the actual building system. Another type of deterioration occurs when changes in computer hard- ware and software require input data that are not stored in or acces- sible by the IDB. Data in the IDB must be maintained by new input or by data transformation procedures to ensure more than historic value. Distribution In the heterogeneous environment envisioned by the IDB, the owner- ship of data can be independent from the distribution of the data. Such "owned" data that are distributed must contain ownership charac- teristics as an inherent part of the data. For example, the size of a structural element can be owned by the structural designer until the final structural design is completed, but the current size of the member may be transmitted to others so that they may use it without waiting for the formal structural design. In this case, the fact that the member is owned by the structural designer should be part of the data on the member. User Interface The user interface to the IDB should not impose a uniform grammar on users but should accommodate expansion and collection of interactive styles as common features. For example, commands need multiple defini- tions to reflect the popular usage. Text should be displayed and edited on a "what you see is what you get" basis. Graphic input should be used. Natural language data inquiry that reflects the user's vocab- ulary should be implemented. Application Services Applications constructed for or operating in the IDB environment should be based on a set of application services (or system facilities)
52 common to all users. These services will, in time, reduce the complexity and size of applications (as depicted in Figure 5-1) and will minimize the impact of evolutionary changes such as new operating systems, upgraded version of support libraries, new storage hardware, and revised standards. Integrator Concept The integrator, as developed at the 1985 Woods Hole Workshop, is a combination of application services and system utilities. As such, it is a logical, rather than a physical, concept. It is not a monolithic "chunk" of software or hardware that performs a set of functions for applications in the IDB. It must be adaptable to a variety of hetero- geneous environments and needs with capabilities invoked as required. As evolutionary technology changes occur, the integrator must be capable of incorporating these changes without major redesigns and conversions of user applications. In short, it is based on a set of modular capabilities with well-defined interfaces. Atomic Data Types The IDB must support high-level atomic data types. These data types and a set of operations on them represent the normal functions on CURRENT USERS IDS USERS APPLICATIONS (Energy AnalysIs) APPLICATIONS INFORMATION SYSTEM CAPABILITIES APPLICATIONS (Energy AnalysIs) APPLICATION SERVICES SYSTEM & NETWORK CAPABILITIES IDB FIGURE 5-1 Application services current and IDB users.
53 which new user views or applications can be built. Atomic data type means the lowest level of appropriate data that can be accessed as a clump. These would include, but not be limited to: geometry types, images, text, numbers, documents, operations, and rules and relation- ships. The operation on each must include input and output, and trans- formations . User Migration The IDB concept will not be implemented at one time. Even if users and their applications fully embraced the concept, the transition period will be significant. Many users already have major investments in large data bases and application software. Therefore, the IDB concept must support a productive migration to this new environment. The users must be able to recover their investments in current capabilities while initiating programs to take advantage of the IDB. Current data bases may support or become part of the IDB. Security provisions must be addressed, and accounting and networking capabilities must be upgraded. User training and retraining cannot be implemented instantaneously. Therefore, the IDB must not only offer attractive capabilities but must provide a practical migration path for its adoption. IDB Standards The IDB concept is a major undertaking with significant benefits. Each element in the heterogeneous environment will likely undergo changes. To ensure that ongoing developments will not become "dead ends," consideration should be given to the adoption and use of standards in existence or evolving throughout the industry. B. VALIDATION OF ISSUES Diverse Flexible User Interface The man-machine interfaces within a global IDB environment may consist of any number of a large assortment of hardware devices or user languages. The range of hardware interfaces, for example, can support interactive cursor control (pen, mouse, joystick), eye movement recognition, voice recognition, or gesture recognition. The range of user languages can emulate high level "natural" languages, such as English, and those languages that more closely resemble the lowest level binary instructions to a computer. The range of user skill levels can also vary widely. The development of the global IDB environment, therefore, should not impose limitations on this great variation in hardware interfaces and user languages.
54 Application Services In order for the IDB to develop, it is essential that several key application services be provided. These services include a means to provide consistently and comprehensively interchange of geometric data that is well defined, complete, and interpretable by various users. Data maintained in various data management systems must be transformed in a similar fashion while maintaining structural relationships, content, and semantics between the source and sink nodes. Data structured in the hierarchical and network methodologies must be usable in a relational form (DIP and translators will assist this process). The ISO open system environment local area network (LAN) standards provide multiple vendors the ability to plug their offerings into LANs in existence. Adoption of such standards will greatly facilitate effective integration of an organization's automation centers providing electronic mail, voice/digital messaging, calendaring, word processing, and so forth. An important service to be provided is various levels of convenient user interfaces, including voice interaction, HELP and training capabilities, menu procedures, and flexible command language services. These application services may necessitate investigation and even prototyping to ensure their availability and understanding. It is the definition of this set of application services required by the IDB and the assurance that they can be provided that must be validated. Integrator to Operate within a Heterogeneous Hardware and Software Environment The data formats, processes, and machinery of the IDB exist within a distributed computing environment. Functioning at this level, the IDB handles communications between each local computing system. However, the data format used within a local system may be closely related to a uniquely local interpretation. This may not be similar to the format and interpretation of data used within another local system. The IDB is concerned with the integrity, consistency, and translation of data between computing systems in this heterogeneous global environment. The role of the IDB in translating between local systems is, in part, like that of a data base exchange standard. A data base exchange standard acts as a common denominator in the transfer of data between dissimilar systems in a heterogeneous computing environment. In the transferring of data through a common denominator, some of the higher level interpretation may be lost. However, the IDB must also ensure that when these data arrive at the receiving computer system, it is possible to restore the highest level interpretation of their contents. In other words, there must be some mechanism within the IDB that will restore the semantic meaning of the data after they are translated to the receiving computing system.
55 The difficulty of translating data between heterogeneous systems and at the same time supporting the highest levels of local interpre- tation of those data makes a number of possible techniques for achiev- ing this seem unfeasible. For example, the approach of building a high-level translator of data for every two dissimilar components of the IDB would require an exceptionally large number of translators. It also results in the unacceptable scenario of an exponentially rising number of translators for every new computer introduced into the system. Another unacceptable approach is to attempt to gather all possible data types and incorporate them into a monolithic common data base that would serve all systems within the IDB. As an illustration of how such a large data base would be unmanageable, one workshop participant speculated that a comprehensive data base for a building would need to consist of at least three gigabytes of data types. This does not yet account for the amount of data types required to support all possible formats used by different computing systems. Alternative approaches to these monolithic schemes were identified at the 1985 Woods Hole Workshop. One approach envisions a "loose coupling of expert systems" performing the data translation between local computing systems, so as to reduce the number of translators required between the individual components of the IDB environment.1 A second, and not necessarily separate scheme, envisions a data dic- tionary existing at a level of abstraction so as to support a wide variety of multiple views (local computing system interpretations) of data.2 There is a recognition inherent in these approaches that the IDB environment must adopt and pioneer new strategies to reduce the load imposed by its data handling responsibilities. Data/Software Migration within a Heterogeneous Environment and Over Time Within a heterogeneous hardware/software network, the transmission of information from one component to another risks the separation of semantic meaning from "raw" data. For example, a cube may be repre- sented as a set of related polygons, each describing one of its faces (front, bottom, left, right, top, and rear faces). This raw geometry, however, may alternatively be used to describe either a box (a hollow container), or a block (a solid container). In general, it may be used to describe any enclosed or partially enclosed form having similar surface characteristics, but subject to different interpretation. XH. Craig Howard and Daniel Rehak, "Expert Systems and CAD Databases," Carnegie-Mellon University, a paper presented at the Woods Hole Workshop, June 1985, p. 3. 2National Research Council, A Report from the 1985 Workshop on Advanced Technology for Building Design and Engineering. National Academy Press, Washington, D.C., 1986, pp. 15-26.
56 A distributed IDB environment imposes a risk for inconsistency of semantic interpretation when data are moved from one computing system to another. A similar risk of inconsistent interpretation exists when moving data between successive generations of hardware and software separated by the date of their introduction into marketplace. This risk can exacerbate the difficulty of interpreting the original inten- tions of a set of data (such as required for "audit trails" during litigation). The question arises as to what extent it is reasonable for the IDB to support consistent interpretation of data at different places and times, and correspondingly, to what extent the end user bears this responsibility. Data Consistency Issues of data consistency and integrity offer compelling reasons for developing the IDB. That users view one representation of data for multiple purposes rather than store the multiple representations is an important component of maintaining data consistency and integrity. Rule systems for both spatial or property consistency are required if data integrity is to be enforced. The maintenance of these properties is a formidable challenge in homogeneous data base systems. The possibility of including these concepts in a heterogeneous distributed system needs to be investigated and demonstrated. Data Transformations The transformation of data in a distributed IDB must preserve the context and meaning of information. This requirement has proven to be difficult to achieve and is an important characteristic to be demon- strated. The current work on the IGES translation for drafting systems is an example of the loss of meaning when translations are made from one system to another. C. NEW PROCESSES ENABLED BY IDB Performance Validation During Warrant Period The IDB can be used to validate the performance of the facilities and support systems by monitoring the usage and actually measuring the operational performance of the individual materials, components and assemblies. The measured values can be compared with the original performance criteria. It should be noted that these validation procedures may require change in contract documents.
57 Evaluating Compliance with Expected Performance The computer model of a building's life cycle provides documen- tation on the causes and effects of building performance. A continu- ally passing chain of events is viewed within one panorama. This type of comprehensive documentation that captures the chronologically linked data stream of a building's life cycle can serve as a predictive model of building performance. These models can be used to determine if the original design criteria for a building's design have been satisfied. They also can be used to inform the formulation of new design criteria. RECOMMENDATIONS Recommendations of the working group follow. 1. It is time to take the IDB concept beyond the the Woods Hole Workshops. The four-year workshop efforts should be brought to closure. 2. The Committee on Integrated Data Base Development should report the IDB concepts and issues formally to agencies of the Federal Construction Council through a committee report. Efforts should be made to communicate beyond the construction industry to organizations working in similar areas such as computer integrated manufacturing. 3. The committee and the Building Research Board should work toward enlisting the support of multiple agencies and industry to sponsor and support IDB development. The levels of effort and resources now required for IDB development go beyond what is achievable by volunteers. 4. Further expansion of the IDB prototype demonstration is not recommended. Future prototyping must address key human and technical issues.
