Test environment running 7.6.6

Cultural advice

The Australian National University acknowledges, celebrates and pays our respects to the Ngunnawal and Ngambri people of the Canberra region and to all First Nations Australians on whose traditional lands we meet and work, and whose cultures are among the oldest continuing cultures in human history.

Aboriginal and Torres Strait Islander peoples are advised that ANU Library collections may include images, names, voices, and other representations of deceased persons.

Material in the collection may contain terms, language or views that reflect the period in which the item was created and may be considered inappropriate today.

Towards a lazy, evolutionary common building model

Loading...
Thumbnail Image

Date

Journal Title

Journal ISSN

Volume Title

Publisher

Abstract

A lack of suitable standards for the transfer of building data from application to application has led to the need for a common building model. Such a model would enable a variety of design tools to access a common repository of building design information and thus avoid redundant data entry and resultant inconsistency. Much research work assumes that the data modelling for a common building model should be completed before systems are built. We instead take an evolutionary approach to developing a common building model, accepting that any such model will need to continue to evolve. It also means that we can begin to address some of the practical issues in providing a common building repository. In addition, it is usually assumed that the repository is (mostly) filled with data before it is used. We instead assume that data in the repository will be accumulated in a lazy fashion; i.e. it is entered by the user (as necessary) in the process of using design tools. As a case study, we describe the development of a model of a building that integrates the data needs of two design tools, ThermalDesigner and WallBrace. In integrating the (object-oriented) schemas, various transformations are required to create a common schema. The inverse of each transformation is then defined as a mapping from the common schema to the application schemas. This is in order to minimise the impact on applications due to both the initial integration and the continuing evolution of the common schema. We also consider the dynamic aspects of the integration of applications, beginning with the user interface requirements.

Description

Keywords

Citation

Source

Building and Environment

Book Title

Entity type

Access Statement

License Rights

Restricted until