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: [email protected] (M.A. Rosenman),
[email protected] (G. Smith), [email protected] (M.L. Maher),
[email protected] (L. Ding), [email protected]
(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.