Towards a lazy, evolutionary common building model

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 res...

Full description

Saved in:
Bibliographic Details
Published inBuilding and environment Vol. 30; no. 1; pp. 99 - 114
Main Authors Mugridge, W.B., Hosking, J.G.
Format Journal Article
LanguageEnglish
Published Elsevier Ltd 1995
Online AccessGet full text

Cover

Loading…
More Information
Summary: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.
Bibliography:ObjectType-Article-2
SourceType-Scholarly Journals-1
ObjectType-Feature-1
content type line 23
ISSN:0360-1323
1873-684X
DOI:10.1016/0360-1323(93)E0010-B