lsevier.com/locate/autcon

Automation in Constructio

Multidisciplinary collaborative design in virtual environments

M.A. Rosenman a,*, G. Smith a, M.L. Maher a,1, L. Ding b, D. Marchant c

a Key Centre of Design and Cognition, University of Sydney, NSW 2006, Australiab CMIT, Commonwealth Scientific and Industrial Research Organisation, P.O. Box 310, North Ryde, NSW 1670, Australia

c Woods Bagot Pty Ltd, Level 10, 11-31 York St., Sydney, NSW 2000, Australia

Abstract

Design projects in the AEC domain involve collaboration among a number of design disciplines, usually in separate locations. There has been

an increase in the interest in synchronous collaborative virtual environments as an alternative or extension to collaborating using CAD systems.

This paper puts forward a 3D virtual world environment which provides real-time multi-user collaboration for designers in different locations and

allows for the different design disciplines to model their view of a building as different representations. This 3D world is extended to provide a

more complete collaborative environment. Relationships between the objects in the different models are seen as central to the maintenance of

consistency and control while changing the design. Agent technology is used to manage the different views, the creation and modification of

objects in the 3D virtual world and the necessary relationships with the database(s) belonging to each discipline.

D 2005 Elsevier B.V. All rights reserved.

Keywords: Collaboration; Multiviews; Virtual worlds; Agents; CAD

1. Introduction

Large design projects, such as those in the AEC domain,

involve collaboration among a large number of participants

from various design disciplines. With the increase in CAD

usage in design offices, there has been an increase in the

interest in collaboration using the electronic medium [1–6],

together with the advance in electronic representation and

standardization of design information [7,8]. Collaboration

among different participants in the design of a building

involves both synchronous and asynchronous communication.

It involves the ability of the different participants to work on

their part of the project using their own particular ways of

working yet being able to communicate with the other

participants to bring about a common objective, the design of

the building. Digital collaboration raises new issues (not

otherwise apparent when each designer works within their

own environment and communicates through document ex-

0926-5805/$ - see front matter D 2005 Elsevier B.V. All rights reserved.

doi:10.1016/j.autcon.2005.10.007

* Corresponding author. Tel.: +61 2 9351 5933; fax: +61 2 9351 3031.

E-mail addresses: mike@arch.usyd.edu.au (M.A. Rosenman),

g_smith@arch.usyd.edu.au (G. Smith), mary@arch.usyd.edu.au (M.L. Maher),

Lan.Ding@csiro.au (L. Ding), david.marchant@woodsbagot.com.au

(D. Marchant).1 Tel.: +61 2 9351 4108; fax: +61 2 9351 3031.

change) such as keeping track of versions, ownership or control

of the design of various elements and ensuring that decisions

made are recorded and transmitted to the necessary partici-

pants. Shared data models have been put forward for over 20

years as the answer to many of these problems [9–15].

Traditionally, the representation of designs has been effected

by each discipline producing its own set of drawings (either

manually or through CAD) and presenting that set to other

designers for checking and comment. Each such set of

drawings is that discipline’s representation (or model) of their

view of the building. The various sets coexist, may share some

commonalities, but are separate representations. The use of a

single shared database, as usually proposed, does not take into

account these different representations required by each

discipline nor does it allow for synchronous real-time multi-

user collaboration through electronic collaboration as the

amount of information present makes such communication

impractical. The maintenance of each discipline’s own view

and model is essential in any environment for collaboration.

This paper presents a collaborative virtual environment for

multidisciplinary design based on the need for extending the

shared database to take into account the needs of the various

views. It focuses on the extensions of a shared model required

to address the following issues: different decomposition

schema of the model among the collaborators; relationships

n 16 (2007) 37 – 44

www.e

Fig. 1. The Active Worlds virtual world.

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37–4438

within and across the different schema; multiple representa-

tions and versioning of elements; ownership and access to

elements and properties of elements and shared visual

representation in a 3D virtual world.

2. Collaborative virtual environments and collaborative

designing

In addition to CAD and shared databases, there are virtual

environments that allow real-time multi-user collaboration by

designers in different physical locations. With the focus on a

shared model being object oriented and following standards for

representation of the properties and relationships of the objects,

a collaborative virtual environment should provide 3D visua-

lisation, walkthroughs and rendering to allow communication

of the various views of the design as modelled by the different

disciplines. This is of special importance at the conceptual

stage of the design since much of the early collaborative

decision-making is carried out at this stage. At the early

conceptual stage, concepts are most fluid and amenable to

change and collaboration is essential. A virtual world environ-

ment based on an underlying object-oriented representation of

the design is put forward here as a collaborative virtual

environment for synchronous communication in the design of

buildings, as shown in Fig. 1. This is in contrast to the decision

made by Lee et al. [16] to use a commercial CAD system or

visualisation. One of the main advantages of a virtual world

environment is that it allows users to be immersed in the

Flat3

Flat1Storey1

Storey2Flat4

Flat2

a) The design

Fig. 2. The architect

environment, allowing for real-time walkthroughs and collab-

oration [17,18]. Moreover, CAD models contain a great deal of

detail which makes real-time interaction extremely difficult. In

our collaborative virtual world, agent technology is used to

facilitate communication between the users, the virtual world

views, and the object-oriented models.

Fig. 1 shows the Active Worlds virtual world environment

[19]. In this world, two avatars representing designers are

aware of each other as well as of the various 3D structures that

have been constructed. The designers can build their design

collaboratively, using 3D objects in real-time and explore the

consequences of these designs in various 3D views. In active

worlds they can communicate through a text-based chat

window. We have extended the Active Worlds platform to

allow for multiviews and richer communication media, such as

video and sketching.

2.1. Example problem

This section presents a simple example scenario to illustrate

the issues involved in early conceptual design involving

architects and structural engineers working both asynchronous-

ly and synchronously. Notification of changes or proposed

changes can be made through an entry in a bulletin board or via

email or both.

The architects create their initial conceptual spatial design

(model) of the building in their own CAD space or in the virtual

world, depending on whether they are working asynchronously

or synchronously, as shown in Fig. 2a. The architects’ model

contains a building object as an aggregate of two storey objects

each composed of two space (flats) objects. A notification is

made that the architects have proposed a design.

The structural engineers view the architects model and,

based on their understanding, create their initial conceptual

structural system design (model) of the building in their own

CAD space or in the virtual world environment, as shown in

Fig. 3. The engineers’ model contains a building object as a

composition of three slabs and three shear walls.

The structural engineers add in relationships between their

elements and architects’ elements, namely that the walls and

slabs bound the storeys and flats. Fig. 4 shows some (for

clarity) of the bounds relationships between the walls and slabs

and the flats and storeys. In addition there is a correspondsTo

relationship showing that an object in one model is the same

:Bldg1

:Storey2

:Flat1 :Flat2 :Flat3 :Flat4

:Storey1

b) UML representation of composition

s’ initial design.

Slab1

Slab2Sw1

Slab3

Sw3

Sw2

:Sw1 :Sw2 :Sw3

:Slab2

:Bldg1

:Slab1 :Slab3

a) The design b) UML representation of composition

Fig. 3. The structural engineers’ initial design.

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37–44 39

physical object as that in another model. In this case it is the

building object, Bldg1. A notification is made that the

structural engineers have proposed a design with relationships

between their model and that of the architects.

Subsequently, the architects wish to increase the width of

Flat 3 and decrease the width of Flat 4 such that a change in the

structural engineers’ Sw2 would occur. This results in a

notification (alert) to the architects of existing relationships

between Flats 3 and 4 and walls and slabs in the engineers’

model. If the architects have been working asynchronously,

they can examine the relationships by viewing the structural

engineers’ model and see that they must confer with the

structural engineers. The architects call a meeting with

engineers (email message or posting on bulletin board). In

the synchronous mode, the alert allows a discussion to take

place to resolve the matter. Both views can be discussed in the

virtual world and the ramification of the changes to the

structural system is discussed. An agreement is reached to

proceed with the modification and permission is granted to go

ahead with changes.

The architects’ version is committed to the database model,

by the agents. Notification is made to all participants of the

changes. The engineers make changes to their model (either in

the virtual world or in their CAD system) and update the

relationships between their model and the architects’ model.

Again notification is made.

The above example gives an indication of the objects and

relationships required as well as the notifications that would

have to be made when working asynchronously. Some

:Bldg1

:Storey1

:Flat1 :Flat2

:Storey2

:Flat3 :Flat4

:Bldg1

:Sw1 :Sw2 :Sw3:Slab2:Slab1 :Slab3

boundsbounds

corr

espo

ndsT

o

Fig. 4. Some of the relationships between the two models.

relationships may exist either as intra-discipline relationships

and/or inter-discipline relationships, whereas others may be just

inter-disciplinary. The correspondsTo(a, b) relationship, shown

in Fig. 4 is such an inter-disciplinary relationship. A one-to-

many/many-to-one correspondsTo relationship would also be

required when the architects may have several wall objects

above each other on different floors and the structural engineers

would have only one wall object. Little attention has been paid

to inter-discipline relationships in modelling. For example, the

IFC schema [8] does not have such relationships. Since inter-

discipline relationships are an essential part of multidisciplin-

ary collaboration, such relationships need to be explored and

included in IFC standards.

3. Multidisciplinary modelling

The views and, hence, models of different design disciplines

are founded on the functional concerns of those disciplines. In

a design context, the view that a person takes depends on the

functional concerns of that person. A building may be viewed

as a set of activities that take place in it; as a set of spaces; as

sculptural form; as an environment modifier or shelter

provider; as a set of force resisting elements; as a configuration

of physical elements; etc. A building is all of these, and more.

A model of an object is a representation of that object resulting

from a particular view taken. For each different view of a

building there will be a corresponding model, as illustrated in

Fig. 5 [20].

Depending on the view taken, certain objects and their

properties become relevant. The sound insulating properties of

a wall are not relevant to a structural engineer. Lightweight

walls are not relevant to the structural engineer since they do

not provide a load of concern. For the architects, floors, walls,

doors and windows are associated with spatial and environ-

mental functions, whereas structural engineers see the walls

and floors as elements capable of providing or bearing loads

and resisting forces and moments. Both models must coexist

since the two designers will have different uses for their

models. According to Bucciarelli [21], ‘‘there is one object of

design, but different object worlds’’ and ‘‘no participant has a

Fgod’s eye view_ of the design.’’

There exists considerable work using a single shared model

from which multiple interpretations are derived [22–25].

However, a single model approach to representing a design

object is insufficient for modelling multiple views taken by

objectview1

model3

view3

spatialconcerns stability

concerns

model1 2model

climateconcerns

view2

Fig. 5. Multiple views and models.

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37–4440

the different viewers [26,27]. Each viewer may represent an

object with different elements and different composition

hierarchies. While architects may model walls on different

floors as separate elements, the structural engineers may

model only a single shear wall. Each discipline model must,

however, be consistent vis-a-vis the objects described. While

Nederveen and Tolman [28], Nederveen [29], Pierra [30],

Sardet et al. [31] and Naja [32] use the concept of common

models to communicate between the discipline models, it is

never quite clear who creates the common models and

maintains the relationships between them and the discipline

models. In this project, this consistency will be provided by

interrelationships between the various objects in different

disciplines modelled by explicit (bidirectional) links from one

object to another. Fig. 6 shows an example of this approach,

with each discipline labelling its objects according to its need.

The correspondsTo relationship is used to relate objects that

are essentially the same physical object. Transitivity ensures

that the architect’s Wall6, the HVAc engineer’s Wall3 and the

structural engineer’s Wall 1 objects correspond to each other.

While this approach may have the disadvantage of replicating

some information, it saves the complexities of creating the

common concepts and allows each discipline great flexibility

in creating its model. The discipline models allow each

discipline to work according to its own concepts and

representations. The whole model may be seen as the union

of the different models.

HVAC Eng's C

W...

HVAC Eng's

Wa...

ato = a_typeaio = an_inst

correspondsTo

Architect's Concepts

Wall...

InternalWall...

Architect's Model

Wall6...

ato

aioco

Fig. 6. Discipline model

Two issues of concern, in any collaborative environment,

are those of keeping multiple versions of a model and who

controls what. In this work, ownership is defined by assigning

purpose and functional properties to objects. Thus, an object

with both spatial and structural functions, is Fowned_ by both

the architect and engineer. There is one Flegal_ approved

version of the total model (i.e. of each discipline), and any

modifications to this model require approval by all the

Fowners_ of the objects which are the subject of modification.

Versions are the property of disciplines and thus any Fwhat if_scenario can be carried out and presented for discussion in the

collaborative environment. If approved, the modifications can

be committed to the Flegal_ version.

4. The system architecture and prototype implementation

The system is comprised of a virtual world platform with

extensions to augment communication, an agent society, an

internal database maintained by the agents in response to

changes made in the virtual world, and external database using

IFCs for communication with a CAD system. The system

architecture is shown in Fig. 7.

4.1. The database and internal model

The designers may enter their design through their own

CAD systems, thus populating the (external) database with

oncepts

all

Model

ll3aio

_of ance_of

Struct Eng's Model

Wall1...

Strct Eng's Concepts

Wall...

ShearWall...

ato

aiorrespondsTto

s and relationships.

CAD CAD

ENGINEER

view agent

data collection

agent

AGENT SOCIETY

model agent

mediator agent

INTERNAL MODEL

engineers' model

Obj1 Objparchitects' modelObj1 Objm

relationshipsRel11 Reln

VW

DATABASE (EDM)

IFC Objects

ARCHITECT VIRTUAL MODEL

VIRTUAL MODEL

Fig. 7. System architecture.

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37–44 41

information about the objects and their properties. Notwith-

standing the shortcomings of IFC schemas at present, this

project uses IFCs [8] as the standard format allowing

interoperability between representations. The IFC objects are

stored in an EDM database for persistence. Since the virtual

world models do not require all the IFC detailed information,

this information is converted into a simpler form and stored in

an internal relational database. The models in the internal

database are interpreted and modified by the agents to support

communication and visualisation among designers in the

virtual world.

When users request a view in the virtual world, the

appropriate agent will query the internal database to extract

the necessary objects to display. The one-to-one and one-to-

many relationships are stored in the internal model. To date the

following relationships are recognized by the internal model:

Aggregates, Composes, CorrespondsTo, Connects, Bounds and

Loads.

Alternatively, the designers may create or modify some

objects in the virtual world during a collaborative session.

Agents will create the respective objects in the internal

database. When committed, the new or modified objects will

be translated and transferred to the IFC/EDM database and thus

be available to the various CAD systems. Versions of the model

reside in the external database. The internal model always

holds the current working model.

4.2. The agent society

The primary role of the agents is to construct and maintain

multiple views of 3D objects instantiated in a virtual world.

Agents also provide an interface between the 3D objects from

which the 3D virtual worlds are constructed and the database

objects that comprise the multiple-views model. Mediator

agents associate 3D objects with designers and their 3D world

avatars, handle text chat from designers to agents, handle

communication between servers and agents, and control the

work flow between agents. Data collector agents provide for

logging and data collection for later cognitive and data mining

analysis or simply as a record of important collaborative

sessions.

The internal model shown in Fig. 7 contains a set of instances

of Component and Association classes, which are instantiated

either from a CADmodel (via the external database and IFCs) or

from the virtual world by an agent. The Component class is

specialised by classes Wall, Slab, Beam, Column, Storey and

Space. Each Component can also have associations with other

Components. The Association class is specialised by classes

CorrespondsTo, Bounds, Aggregate, and Loads. Components

belong to a project, are owned by a citizen (a designer) with a

personality (architect, engineer, etc.), and are declared to be of

one or more functional categories (spatial, structural, aesthetic,

etc.). Component and Association objects encapsulate tables in a

relational database. This relational database both provides

persistence for the agents as well as reducing the coupling

between the agents and the external database.

The external database contains CAD models from different

disciplines and the internal model is populated with Compo-

nent and Associations accordingly. Maintaining the internal

model with respect to changes in the virtual world or changes

in the external (EDM) database is the role of the model agent.

Views in the virtual world are constructed and reconstructed by

view agents through queries on the internal model according to

specified personalities, component owners, categories and so

on. According to the view required, selected by clicking on a

designer view in the web page builder (see Section 4.3), the

view agent decides which objects are relevant and converts

these into AW objects. Because the geometry of the virtual

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37–4442

world will be different to that in the external database, view

agents maintain a separate set of objects. An opposite process,

whereby objects are created in the AW environment, has the

agents producing internal model objects which in turn create

IFC objects in the EDM database. The Components in the

relational database of the internal model can therefore be seen

as providing a data model for the agents, reducing the coupling

between the agents and the external database, and a simplified

intermediate geometry that is accessible from both the external

database and the virtual world.

Modifications, such as architects wishing to move a wall,

are to be sent via the mediator agent to the model agent who

will check whether the modification is permitted. This will be

done by checking whether any relationships exist between the

object and objects in other disciplines, i.e. whether the object is

Fowned_ by other disciplines. The model agent may then send

back a notification to the mediator agent that this is not

permitted and the architects will be notified that they must

discuss this with, e.g. the structural engineers. Together with

the owner association of a component, there will be a list of

those permitted to make modifications to related objects.

Granting permission will mean adding a discipline with the

permission to manipulate the objects even though they are

owned by another discipline. Alternatively, if no such

relationship exists, the model agent will permit the request,

update the model accordingly and the view agent will update

the view. A discipline may create any number of versions of its

own model, since versions are not Flegal_ and may make any

Fig. 8. The 3D virtual world c

modifications to its objects within that version model. This

version model may be presented in the virtual world for

discussion. If agreement is reached, the version may then be

committed as the Flegal_ version. Related changes to other

discipline models must be made by the discipline concerned.

4.3. The virtual collaborative environment

Fig. 8 shows the CRC Collaborative Designer (CCD). CCD

is a prototype environment that supports collaboration by

augmenting the inherently multi user Active Worlds (AW)

platform with additional collaboration tools. Designers interact

with a virtual world, other designers and agents via the

different browser panels. The large 3D panel shows the 3D

world, including artefacts being built and the avatars of

designers. The panel below the 3D view panel facilitates chat.

While streaming audio is also used by CCD, text chat provides

persistence and encourages brainstorming-like interaction. The

narrow panel at the far left provides for navigation between

worlds, teleports, telegrams, contacts, and help pages. The

large panel at the far right shows dynamically served web

pages that provide more information about the design and runs

interactive applications. These applications include a BUILD-

ER (which will be discussed later), a webcam and streaming

audio, a distributed sketchpad, and a logging facility for use by

cognitive experimenters.

The ActiveWorlds (AW) platform has been used as a basis for

development. This is because the AW server provides a platform

ollaborative environment.

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37–44 43

for distributed collaboration upon which one can create new

objects, and because the virtual world is rendered in real time as

the avatars move around and make changes to the design. The

collaborative experience is enhanced by driving the web panel

from the server side off an Apache Tomcat HTTP server. This

serves Java Server Pages and Java Servlets from designer actions

on the web panel. One reason for choosing Tomcat as the HTTP

server is because the agents are implemented in Java, and so

agents communicate with the HTTP server using Java Remote

Method Invocation. The agents also use a Java Native Interface

to the AW software development kit, enabling agents both to

sense the world and to effect changes to it.

Two designers are shown, both as webcam views and as

their avatars in the 3D world. The engineer’s view has been

selected and the view in the virtual world is that of the

structural engineer, namely the building as a composition of

slabs and walls. In addition, the BUILDER toolkit shows the

engineer palette allowing the engineer to construct elements

relevant to the engineer and locate them in the virtual world. If

FArchitect_ was selected; then the view shown would be rebuilt

by an agent such that only objects declared to be of interest to

architects would be shown and the BUILDER toolkit would

change to that of the architect.

To create objects in the world, the BUILDER button is

selected. A Flist box_ appears. This listbox is used to select the

personalities of interest and insert objects accordingly. For

example a column may be selected from the FEngineers palette_.Both the list of objects and the palettes are queried from the

internal model. To add new objects to the world, the designer

moves to a desired location and clicks on the FINSERT_ button.This results in a message being sent to the agents, and a new

object being inserted in the world.

5. Conclusion and future work

This paper has presented a framework for multidisciplinary

collaborative design based on a virtual world platform and a

model for representing the same design from the perspectives

of different disciplines. We propose that the views of the

various disciplines are modelled in separate hierarchies and the

relationships between the various models are specified.

Collaboration takes place in a virtual world environment

because the multi-user and immersive properties of such

environments facilitates synchronous communication and

simultaneous modification to the different discipline designs.

The paper presents a framework for collaborating in a virtual

environment including a database, based on IFCs, containing

the various models and relationships between them; a virtual

world environment for collaboration and an agent-based

society for handling the communication between the users,

the virtual world and the database. An internal database

simplifies the work of the agents and also decouples the agents

from existing (IFC/EDM) technology. If the representation

method for representing objects in CAD systems were to

change, the agent system would not need to.

The paper has highlighted the need for extending the IFCs

to include interdisciplinary relationships as well as extending

the scope of IFC objects. Future work includes finalising the

mapping from IFC objects to the internal database, including

the notification messaging and testing the system more fully.

Current work is exploring the Second Life virtual world [33]

as an alternative to the Active Worlds platform because of its

open-ended customization and its internal support for what we

have called the BUILDER. The control of elements and the

creation of versions is under development. While currently, the

focus is on the communication between the internal model and

the virtual world (and vice-versa), future work will develop the

communication between the EDM database and the internal

model. This will allow queries about objects in the virtual

world resulting in information being derived from the EDM

database and displayed. In addition, building in the virtual

world will result in the updating of the EDM database.

Acknowledgements

The research described was supported by the Australian

Cooperative Research Centre for Construction Innovation. This

work is part of the Team Collaboration in High Bandwidth

Virtual Environment project.

References

[1] J.C. Tang, S.L. Minneman, Videodraw: a video interface for collaborative

drawing, ACM SIGCHI Conference on Human Factors in Computing

Systems, ACM Press, 1990, pp. 313–320.

[2] J. Brooke, User interfaces for CSCW systems, in: D. Diaper, C. Sanger

(Eds.), Practice: An Introduction and Case Studies, Springer-Verlag,

London, 1993, pp. 23–30.

[3] T. Kvan, Fruitful exchanges: professional implications for computer-

mediated design, in: M. Tan, R. Teh (Eds.), The Global Design Studio,

Centre for Advanced Studies in Architecture, University of Singapore,

1995, pp. 24–26.

[4] M. Saad, M.L. Maher, Exploring the possibilities for computer support for

collaborative designing, in: M. Tan, R. Teh (Eds.), The Global Design

Studio, Centre for Advanced Studies in Architecture, University of

Singapore, 1995, pp. 727–738.

[5] J. Wojtowicz (Ed.), Virtual Design Studio, Hong Kong University Press,

Hong Kong, 1995.

[6] M.L. Maher, J. Rutherford, A model for collaborative design using CAD

and database management, Research in Engineering Design 9 (2) (1997)

85–98.

[7] Y. Adachi, J. Forester, J, Hyvarinen, K. Karstila, T. Liebich, and J. Wix,

Industry Foundation Classes IFC2x, 2000, http://cig.bre.co.uk/iai_uk/

documentation/Ifc_R2x_Final.

[8] IAI. Industry Foundation Classes-Release 2x, IFC Technical Guide.

http : //www.iai - international.org / iai_international/Technical_Documents/

documentation/IFC_2x_Technical_Guide.pdf; 2000, accessed 10 Novem-

ber 2004.

[9] C.M. Eastman, Database facilities for engineering design, Proceedings of

the IEEE 69 (10) (1981) 1226–1249.

[10] Y. Yasky, A consistent database for an integrated CAAD system:

fundamentals for an automated design assistant. PhD thesis. Department

of Architecture, Carnegie-Mellon University, 1981.

[11] M.L. Brodie, Association: a database abstraction for semantic modelling,

in: P.P. Chen (Ed.), Entity-Relationship Approach to Information

Modeling Analysis, 1981.

[12] B.-C. Bjørk, Basic structure of a proposed building model, Computer-

Aided Design 21 (2) (1989) 71–78.

[13] D. Sriram, A. Wong, R. Logcher, Shared workspaces in computer

aided collaborative product development, Conference Papers of the

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37–4444

First International Symposium on Building Systems Automation

Integration, June 2–8, 1991, University of Wisconsin, Maddison,

1991, pp. 1.4-1–1.4-29.

[14] A. Wong, D. Sriram, Shared an information model for cooperative product

development, Research in Engineering Design 5 (1993) 21–39.

[15] K. Krishnamurthy, K.H. Law, A data management model for collaborative

design in a CAD environment, Engineering with Computers 13 (2) (1997)

65–86.

[16] K. Lee, S. Chin, J. Kim, A core system for design information

management using Industry Foundation Classes, Computer-Aided Civil

and Infrastructure Engineering 18 (2003) 286–298.

[17] L. Savioja, M. Mantere, I. Olli, S. Ayravainen, M. Grohn, J. Iso-Aho,

Utilizing virtual environments in construction projects, ITCon, 8 (2003)

85–99, http://www.itcon.org/cgi-bin/papers/Show?2003_7.

[18] G. Conti, G. Ucelli, R. De Amicis, JCAD-VR—a multi-user virtual reality

design system for conceptual design, in TOPICS, Reports of the INI-

GraphicsNet, vol. 15, 2003pp. 7–9.

[19] Active Worlds, 2005, http://www.activeworlds.com.

[20] M.A. Rosenman, J.S. Gero, CAD modelling in multidisciplinary design

domains, in: I. Smith (Ed.), Artificial Intelligence in Structural Engineer-

ing, Springer, Berlin, 1998, pp. 335–347.

[21] L.L. Bucciarelli, Designing and learning: a disjunction in contexts, Design

Studies 24 (3) (2003) 295–311.

[22] H.C. Howard, J.A. Abdalla, D.H. Phan, Primitive-composite approach for

structural data modelling, Journal of Computing in Civil Engineering 6(1)

(1992), 19, 40.

[23] R.W. Amor, J.G. Hosking, Multi-disciplinary views for integrated and

concurrent design, in: K.S. Mathur, M.P. Betts, K.W. Tham (Eds.),

Management of Information Technology for Construction, World Scien-

tific, Singapore, 1993, pp. 255–267.

[24] M.J. Clayton, R. Fruchter, H. Krawinkler, P. Teicholz, Interpretation

objects for multi-disciplinary design, in: J.S. Gero, F. Sudweeks (Eds.),

Artificial Intelligence in Design V94, Academic Publishers, Dordrecht,

Netherlands, 1994, pp. 573–590.

[25] B.K. MacKellar, J. Peckham, Specifying multiple representations of

design objects in SORAC, in: J.S. Gero, F. Sudweeks (Eds.), Artificial

Intelligence in Design V94, Academic Publishers, Dordrecht, Netherlands,

1994, pp. 555–572.

[26] M.A. Rosenman, J.S. Gero, Y.-S. Hwang, Representation of multiple

concepts of a design object based on multiple functions, in: K.S. Mathur,

M.P. Betts, K.W. Tham (Eds.), Management of Information Technology

for Construction, World Scientific, Singapore, 1993, pp. 239–254.

[27] M.A. Rosenman, J.S. Gero, Modelling multiple views of design objects in

a collaborative CAD environment, CAD Special Issue on AI in Design 28

(3) (1996) 207–216.

[28] G.A. van Nederveen, F.P. Tolman, Modelling multiple views on buildings,

Automation in Construction 1 (1992) 215–224.

[29] S.V. Nederveen, View integration in building design, in: K.S. Mathur, M.P.

Betts, K.W. Tham (Eds.), Management of Information Technology for

Construction. Mathur, World Scientific, Singapore, 1993, pp. 209–221.

[30] G. Pierra, A multiple perspective object oriented model for engineering

design, in: X. Zhang (Ed.), New Advances in Computer Aided Design and

Computer Graphics, International Academic Publishers, Beijing, 1993, pp.

368–373.

[31] E. Sardet, G. Pierra, J.C. Poiter, G. Battier, J.C. Derouet, N. Willmann, A.

Mahir, Exchange of component data: the PLIB (ISO 13584) model,

standard and tools, Proceedings of the CALS EUROPEV98 Conference,

1998pp. 160–176.

[32] H. Naja, Multiview databases for building modelling, Automation in

Construction 8 (1999) 567–579.

[33] Second Life, (2005), http://secondlife.com.