Multidisciplinary collaborative design in virtual environments - CiteSeerX

Automation in Construction 16 (2007) 37 – 44 www.elsevier.com/locate/autcon

Multidisciplinary collaborative design in virtual environments M.A. Rosenman a,*, G. Smith a, M.L. Maher a,1, L. Ding b, D. Marchant c b

a Key Centre of Design and Cognition, University of Sydney, NSW 2006, Australia 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-

* 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. 0926-5805/$ - see front matter D 2005 Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2005.10.007

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 participants. 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 multiuser 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

38

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

environment, allowing for real-time walkthroughs and collaboration [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.

Fig. 1. The Active Worlds virtual world.

within and across the different schema; multiple representations 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 visualisation, 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 environment 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

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 asynchronously 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

:Storey1 Storey2 Flat3

Flat4

Storey1 Flat1

Flat2

:Flat1

a) The design

:Flat2

:Storey2

:Flat3

:Flat4

b) UML representation of composition Fig. 2. The architects’ initial design.


39

:Bldg1

:Slab1

Slab3

:Slab2

:Slab3

Sw2 Sw1 Slab2

Sw3

:Sw1

:Sw2

:Sw3

Slab1

a) The design

b) UML representation of composition Fig. 3. The structural engineers’ initial design.

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

:Flat1

:Flat2

:Storey2

correspondsTo

:Storey1

:Flat3

:Flat4

:Bldg1

:Sw1

:Slab1

:Sw2

:Slab2

:Sw3

:Slab3

bounds bounds

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-tomany/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 interdiscipline relationships are an essential part of multidisciplinary 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 environmental 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

40


climate concerns

model 1

model 2

model 3

view 2

spatial concerns

stability concerns

view1

view 3

object

Fig. 5. Multiple views and models.

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. Architect's Concepts ...

Wall

...

InternalWall

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

HVAC Eng's Concepts ...

Strct Eng's Concepts

Wall

...

Wall

...

ShearWall

ato

Architect's Model aio ...

ato HVAC Eng's Model ...

correspondsTo

aio Wall3 correspondsTto

Wall6 ato = a_type_of aio = an_instance_of Fig. 6. Discipline models and relationships.

Struct Eng's Model aio ...

Wall1


41

DATABASE (EDM) IFC Objects

CAD

CAD

INTERNAL MODEL architects' model Obj1 Objm

relationships Rel11 Reln

engineers' model Obj1

Objp

AGENT SOCIETY view agent

model agent

mediator agent

data collection agent

VW ENGINEER ARCHITECT VIRTUAL MODEL VIRTUAL MODEL

Fig. 7. System architecture.

information about the objects and their properties. Notwithstanding 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-tomany 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 CAD model (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 Component 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

42


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

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 BUILDER (which will be discussed later), a webcam and streaming audio, a distributed sketchpad, and a logging facility for use by cognitive experimenters. The Active Worlds (AW) platform has been used as a basis for development. This is because the AW server provides a platform

Fig. 8. The 3D virtual world collaborative environment.


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

43

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 computermediated 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 November 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, ComputerAided 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

44

[14] [15]

[16]

[17]

[18]

[19] [20]

[21] [22]

[23]

[24]

M.A. Rosenman et al. / Automation in Construction 16 (2007) 37 – 44 First International Symposium on Building Systems Automation Integration, June 2 – 8, 1991, University of Wisconsin, Maddison, 1991, pp. 1.4-1 – 1.4-29. A. Wong, D. Sriram, Shared an information model for cooperative product development, Research in Engineering Design 5 (1993) 21 – 39. K. Krishnamurthy, K.H. Law, A data management model for collaborative design in a CAD environment, Engineering with Computers 13 (2) (1997) 65 – 86. 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. 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. G. Conti, G. Ucelli, R. De Amicis, JCAD-VR—a multi-user virtual reality design system for conceptual design, in TOPICS, Reports of the INIGraphicsNet, vol. 15, 2003pp. 7 – 9. Active Worlds, 2005, http://www.activeworlds.com. M.A. Rosenman, J.S. Gero, CAD modelling in multidisciplinary design domains, in: I. Smith (Ed.), Artificial Intelligence in Structural Engineering, Springer, Berlin, 1998, pp. 335 – 347. L.L. Bucciarelli, Designing and learning: a disjunction in contexts, Design Studies 24 (3) (2003) 295 – 311. 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. 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 Scientific, Singapore, 1993, pp. 255 – 267. M.J. Clayton, R. Fruchter, H. Krawinkler, P. Teicholz, Interpretation objects for multi-disciplinary design, in: J.S. Gero, F. Sudweeks (Eds.),

[25]

[26]

[27]

[28] [29]

[30]

[31]

[32] [33]

Artificial Intelligence in Design 9V 4, Academic Publishers, Dordrecht, Netherlands, 1994, pp. 573 – 590. B.K. MacKellar, J. Peckham, Specifying multiple representations of design objects in SORAC, in: J.S. Gero, F. Sudweeks (Eds.), Artificial Intelligence in Design 9V 4, Academic Publishers, Dordrecht, Netherlands, 1994, pp. 555 – 572. 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. 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. G.A. van Nederveen, F.P. Tolman, Modelling multiple views on buildings, Automation in Construction 1 (1992) 215 – 224. 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. 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. 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. H. Naja, Multiview databases for building modelling, Automation in Construction 8 (1999) 567 – 579. Second Life, (2005), http://secondlife.com.