Multidisciplinary collaboration is an important aspect of modern engineering activities, arising from the growing complexity of artifacts whose design and construction require knowledge and skills that exceed the capacities of any one professional. However, current collaboration in the architecture, engineering, and construction industries often fails due to lack of shared understanding between different participants and limitations of their supporting tools. To achieve a high level of shared understanding, this study proposes a filter-mediated communication model. In the proposed model, participants retain their own data in the form most appropriate for their needs with domain-specific filters that transform the neutral representations into semantically rich ones, as needed by the participants. Conversely, the filters can translate semantically rich, domain-specific data into a neutral representation that can be accessed by other domain-specific filters. To validate the feasibility of the proposed model, we computationally implement the filter mechanism and apply it to a hypothetical test case. The result acknowledges that the filter mechanism can let the participants know ahead of time what will be the implications of their proposed actions, as seen from other participants’ points of view.
The success of collaboration depends on whether the participants achieve shared understanding [
The initial effort started with standardizing product descriptions including geometric information and constructing databases to organize them. Following the standardization of product model data, Eastman et al. [
The underlying theoretical assumption of these efforts is that a building is a product composed of heterogeneous products. This assumption has been relatively valid and even successfully realized in several related industries, such as the automotive and shipbuilding manufacturing industries. However, the building and construction industry continues to lag behind in this development [
One of the leading BIM solutions available today is the Revit platform [
Up-to-date software (e.g., Autodesk’s Architecture, GraphiSoft’s ArchiCAD, Bentley’s Microstation, Tekla’s Structures, etc.) supports input and output of IFC files toward interoperability. Software vendors advertise their products as “IFC-Compliant” to the latest version of IFCs. For instance, Revit Architecture can import IFC files from Revit Structure and vice versa. Tekla is notable in the structural engineering domain. Tekla Structures is similar to other BIM applications for structural design: instead of drawing 2D structural plans, sections, and elevations, structural engineers can create a complete digital model that simulates a real world structure and combines both the physical model and the analytical model. Since Tekla Structures is fully compliant to IFC2x3, a Tekla model can be exported as an IFC file and opened in other BIM applications, while exported IFC files from other applications can be used as reference models in Tekla Structures.
Eastman’s and other centralized data models were well defined and tractable enough to support a limited number of participants. However, the complexity of the architectural product has generated more problems than the shared data model could solve. Current BIM suffers from a number of shortcomings which are as follows [ In order to ensure as wide an agreement as possible within the industry on semantic definitions, it requires continuous and iterative review by the professionals. This is also the most time-consuming factor identified by Wix and Liebich [ Since it relies on human review, it is error-prone to integration of all domain development into a single model and to make it internally self-consistent. Semantic definitions covering possible domains are inevitably at high level, which results in lack of defining details such as detailed ontological information through the design process and the construction. Captured models work only for a short period of time. It is almost impossible to add what a participant needs for a specific purpose because of static structures of the models.
Although the IFCs contain detailed information about construction projects, only a small portion of all the important data that can exist throughout any project element is represented [
The IFCs do not have specific rules about how their elements are created and organized. This is dependent on software itself in conjunction with its user interface. In order to maintain internal model consistency, Revit implements strong rules about how building elements are created, organized, and represented, which are not compatible with the IFCs. Thus, it would be impossible to expect a seamless file exchange between BIM applications even if they are all IFC compliant, unless they follow some sort of standards on how elements are created and mapped with respect to each other [
The primary objective of any centralized data model is to build a common data structure that would include all the possible representations using abstraction, hierarchy, and relationships to represent the building information. The notions of abstraction and hierarchy are useful for structuring a building description, as they allow each domain dealing with a building to add its own descriptions to it. However, it has become clear that a single, centralized data model would not serve all the requirements of all the participants [
A new approach proposed by this research focuses on how the participants in the design process alternate between their “private” representations, which they use during their own, internal design process, and the “public” version which they “publish” for the benefit and use of the other participants. The core of this approach is a kind of “filtering” mechanism that mediates between the private (domain-specific) workspace and the shared public workspace.
The filter mechanism can be used for reflecting on the participants’ design progress and for identifying potential problems in their performance as a self-evaluating tool. The filter-mediated communication model for collaborative design is proposed to reflect the characteristics of multidisciplinary collaborative design to facilitate participant-oriented aspects and to solve real world collaboration problems by focusing on a semantically rich representation method and distributed mode of communication which is mediated by intelligent filters. A similar distributed approach is found in “the engineering framework (TEF)” [
To demonstrate the proposed model, a hypothetical case study is presented, which incorporates computational methods to support the process of knowledge creating, storing, and sharing among different professionals without sacrificing human aspects and to validate the feasibility of the model.
In order to overcome the limitations of semantic representations in the current BIM technology, we developed a “filtering” mechanism. As shown on Figure
Anatomy of filter-mediated communication.
Assume that two participants, P-A and P-B, collaborate in this setting. P-A can generate a variety of design solutions, which are unofficial, domain-specific, and semantically rich to P-A, in P-A’s private workspace. When P-A decides to publish one of the design solutions, P-A’s filter (F-A) transforms the selected design solution (privateVersion-A) into an official, domain-neutral version (publicVersion-A) and publishes it to the public workspace. Conversely, when P-A wants to review P-B’s solution published in the public workspace, F-A transforms it (publicVersion-B) to be domain-specific and semantically rich to P-A (privateVersion-B) in P-A’s private workspace. In these two contrary processes, the filter, F-A, changes modes (i.e., private or public) of design representation based on the P-A’s predefined, domain-specific ontology.
The public workspace provides the participants with object level information that includes geometric (dimension, level, grid, etc.) and nongeometric data (cost, schedule, project, etc.) and their semantic data, whereas the private workspace contains the conceptual and the mechanical levels of information. The conceptual level stores participant’s tacit knowledge, and the mechanical level consists of domain-specific ontologies and values and supporting tools. Furthermore, to enable a high-level communication among the participants, the filter serves both syntactic and semantic communication within the object level. The syntactic communication allows different applications to read the data and the semantic communication provides the ontological meanings associated with the data. The next section will describe the detailed characteristics of the filter-mediated communication.
The semantic level is the first step towards interdomain communication. The conceptual ontology adds to the object data that any one domain expert may take for granted, but which would be viewed differently by another domain expert. It thus provides a more explicit but abstract way to describe information, encapsulating both conceptual and domain-specific data models. The conceptual models may include elements such as generalization, aggregation, and cardinality constraints about the objects (e.g., a door is a kind of opening and belongs to a specific wall) (Figure
A “DOOR” ontology.
This level fulfills the most important role in the filter model: adding semantically rich information that can be interpreted correctly by different domains of knowledge. As an example, consider the design of a house. The plans produced by the architect include objects such as walls, rooms, and openings. The structural engineer must interpret the plans, retrieving the meanings of the objects it contains. However, the structural engineer’s interpretation is often different from the architect’s: he uses different vocabularies, such as “bearing walls,” “partitions,” and “frames.” The structural engineer may, therefore, begin his task by translating the objects from the architect’s representation into his own objects, creating a totally different representation of the same floor plan. The architect will have to go through a similar process when he receives the structural engineer’s drawings.
The proposed filter mechanism will automate this interpretive translation process, using the semantics associated with each object that comprises the plans. It will interpret, add, or omit data as needed by the domain expert. For example, the structural engineer’s filter will interpret architectural WALL objects as LOAD_BEARING or NON_LOAD_BEARING objects, without burdening the architect’s representation of the same data. With the addition of the suggestion-based applications, the architect may be alerted when he tries to modify a wall designated LOAD_BEARING by the structural engineer, but the data describing the wall’s specific load bearing properties will be hidden from him.
The syntax level is intended to provide a common standard for exchanging data. We propose to adopt extensible markup language (XML) as a common syntax. The main task of the syntax level, therefore, would be to tag each object using appropriate XML tagging. The tags alone will not carry meaning unless they are connected to ontological information which is stored in the semantic level.
In terms of computer networks, there are two common models of computer networking: the client-server model and the peer-to-peer model (P2P) [
Pure P2P computing (Figure
Two communication modes: (a) pure peer-to-peer and (b) hybrid peer-to-peer.
The major advantage of the P2P model over the client-server model is that we can reduce the size and complexity of the centralized data and even eliminate centralized control over the data, which is expected to overcome the problems of the data-centric approach discussed earlier. For practical purposes, we adopt the hybrid P2P model for filter communication. This is because in the pure P2P model, peers may spend much time and effort to find other peers and their resources. The shared data includes general information on peers, agreements on how to describe ontological specifications for the specific domains, and the latest version of each participant’s published data.
We regard each participant’s filter as a peer in the filter communication. When the filter obtains a connection to the server which has the shared data, it examines the consistency of its maintained published data. First, it will publish the latest detected version of each participant’s data. Second, if it detects inconsistency between the published data and the private data, it will update its published data. Since each participant’s private data is dynamically changed in the course of the design, the filter will update its own published data when it is requested to provide information by other filters.
The filter mechanism is intended to reduce ambiguity and clarify the choices made by each participant in the design process, without encumbering the participants through overprescriptiveness. Ambiguity in design process has two contradictory aspects: one is a powerful enabling force for creative design and multidisciplinary planning [
The design process is generally considered to consist of four distinctive phases before actual construction [
Typical phases in the design process.
Even though there are a plethora of tools that can support various aspects of the design process, most of them (AutoCAD, MicroStation, VectorWorks, etc.) are focused on later phases (especially “construction documents”) of the design process. The reason is that the design problem in the early phase is usually ill-defined [
Although there would be difficulty having concretized answers in this phase, this would be another opportunity to raise a variety of possible issues and problems and explore solutions before making irreversible decisions. The filter mechanism emphasizes a participant-oriented approach in that participants can enrich ontological information with their knowledge, belief, and specialized tools. Each participant can contribute his or her knowledge so that it can help other participants propose solutions and solve problems. For example, when an architect who has little knowledge about the requirement of a fire-egress door starts partial ontological information of the door, a fire marshal can contribute his or her knowledge to the door through the filter mechanism.
The proposed model is intended to support these phases, where the most important design decisions that require multidisciplinary collaboration are made, where there is enough information contributed by the participants from different disciplines to make substantive design decisions and where the design has not yet been developed so much that changes are no longer feasible (Figure
Filter mechanism in the design process.
Surprisingly enough, there are very few frameworks or systems to support these phases of the design process. One of the reasons is that “over-the-wall” practice (serial approach) is still pervasive in the AEC industry so that it is difficult for a discipline to predict the impact of its decision on another’s. However, the impact of a network-based collaborative design transforms a hierarchical/linear partitioned process into a distributed and interleaved one. Using the filter-mediated communication model, the participating professionals can affect one another bi- or multidirectionally.
Even though the proposed model is not aimed at this phase, the participants would benefit from the model in that they would better understand the necessary kinds of information and representations for actual construction.
In order to model a building ontology, we applied a semantic network [
A kitchen ontology with semantic network.
Because the semantic network has a flexible structure, unlike other building models (STEP, IFC, EDM, etc.) that have a rigid and static structure, it can contain an infinite number of descriptions of building components within the network according to participants’ ontological information [
Figure
Structure of building object ontology.
The four common ontological units (i.e., building, space, construction, and functional units) inherit the root object, “building object.” Conceptually, it is possible to define unlimited relationships, but there are only two relationships in the current model: A_KIND_OF (or AKO) and A_PART_OF (or APO). AKO means the subsumption relation and APO the assembly between two different units (or classes). Each of these four units can have many subnetworks with either AKO or APO. APO is the main relation between a Building Unit and the other three units to define assembly relationship.
SUs define architectural spaces and are defined by other physical entities such as CUs and FUs. Therefore, in the model, CUs and FUs are connected to SUs with an APO relationship. CUs are physical entities that comprise SUs. CUs are divided into two groups by their structural characteristic: load bearing and nonload bearing units. FUs include furniture and equipment that serve specific functional roles by occupying SUs.
In the filter-mediated communication, each participant has his or her domain-specific filter. During communication, the major role of the filter is to translate incoming design representations from the shared workspace and to publish outgoing representations based on the participant’s ontology. For the flexibility and efficiency of implementing the domain-specific filters, Extensible 3D (X3D) [
In order to define ontological information in X3D, we incorporated a shorthand non-XML serialization of resource description framework (RDF) [
Window ontology in X3D.
As described in the previous section, the filter mediates two different design workspaces: the private design workspace (PDW) and the shared design workspace (SDW). The PDW is an independent working environment exclusive to a specific participant. In the PDW, as a design progresses, the participant creates objects of which semantics are built with his or her domain-specific ontology. On the contrary, the SDW is a public environment open to all the participants and consists of a “shared database” and a “shared knowledge base.” The shared database contains project-dependent, ongoing design data contributed by the participants whereas the shared knowledge base contains project-independent, reusable ontology either common or domain-specific (Figure
SDW and PDWs for three participants.
To be easily processed by the filters, XML, an application-neutral format, is used to store geometric and ontological data (in X3D) and query specific data (with XPath) in the SDW. With the shared data repository in XML, the filters can query domain-specific design representations and share them with other filters.
As shown on Figure
Screenshots of PDW and SDW: (a) PDW setting UI, (b) modeling in PDW, (c) design review in SDW, and (d) X3D query sandbox.
Suppose a 3D plan of an office that has multiple SUs and CUs by the architect as shown in Figure
Filtered representations of objects.
This hypothetical case study illustrates the function and process of the filters in a multidisciplinary collaborative design environment: the core and shell design of an office building (Figure
A hypothetical setting for the office building project.
First, in order to simplify the process, the owner is assumed to specify his or her requirements that will be shared by all the participants. Interpreting the owner’s requirements and desires, the architect generates some schematic designs that roughly meet the owner’s needs. At this stage, the role of the architect would be that of a consultant who helps the owner realize their vision concretely. If the owner is satisfied with the architect’s proposed design, the architect begins developing a design. In the course of the design, the architect may encounter several issues that must be resolved in collaboration with the other participants. In a similar way, the other participants may have similar conflicts that need to be resolved.
Since they have different knowledge, representations, and their own discipline tools, the participants are subject to interpret the input data in their own unique ways. In this case study, we focus on the information flow among the participants: what information is transmitted and how each filter interacts with another collaborating participant. The basic assumptions for this case are as follows. Each participant deals with one aspect of a whole design. Each participant is responsible for creating his or her own ontological information. Each application has its own data model that cannot be directly read by other applications. The published data is written in XML, which can be processed by all the participants. Each participant is in charge of retrieving the data from the shared workspace when another participant publishes data.
The architect is in charge of creating a schematic design while considering the project program and any particular design criteria specified by the owner. The architect’s primary interest is spatial quality, and thus he might start his design with defining spaces according to the requirements, design criteria, and so on. An SU can be defined by a number of CUs as discussed.
Before creating drawings, he starts with defining his ontologies. Although he can reuse some ontologies independent of a specific project (e.g., individual products including doors, windows, etc.), he has to define particular ontologies if necessary. For example, he draws a box with dimensions (geometric information) and properties (nongeometric information) which are dependent on a specific project. Then, defining it as a “wall,” a “floor,” a “roof,” and so on, he can build a new ontology (Figure
A room with the architect’s ontology.
In order to design the structure, the structural engineer needs the architect’s models as well as structural codes and standards. Since the input does not have information on structural analysis, the structural engineer’s filter will rebuild the model based on his own ontologies. For example, when the structural engineer’s filter receives the architect’s model that was designed schematically, it tries to differentiate the model to generate proper representation for structural analysis (Figure
Enriched representation by the structural engineer’s filter.
The structural engineer’s primary concern is how the architect defines his spatial definitions and how the definitions are constructed by CUs. Although the architect might use the same labels, such as “wall” and “floor,” the structural engineer might have different definitions. Thus, the structural engineer can choose relevant ontological definitions that the architect has defined. Additionally, based on the structural engineer’s ontology, his filter ignores irrelevant information such as color, that is, not important for structural calculation. If the architect’s ontology does not have enough definitions, then the structural engineer can add his own ontological information such as “inertia” and “moment” properties to the model. Based on this information, the structural engineer will do structural analysis using his own disciplinary tools. If he is ready to publish his design, his filter will publish it to the SDW so that the other participants’ filter can access it.
The mechanical systems in this case are HVAC supply ducts. The plumbing engineer’s task is to route sanitary waste, and the electrical engineer has to deal with cable trays and conduits. The MEP engineer’s primary concern is whether the corridor ceiling spaces are deep and wide enough to contain the necessary MEP systems. Therefore, the architect’s and structural engineer’s design criteria usually act as constraints.
The filters collaborating with the MEP engineers will induce clearance and available spaces from the input geometry (Figure
Enriched representation by the MEP engineers’ filters.
Figure Dynamic interaction among participants (producers/consumers of information), Ontological information flow (knowledge representation), The role of the filter in a design process:
Intelligent filter to decode/encode the published data, Enriching input data based on ontologies of a participant, Suggestion mechanism.
The core of an office building.
The process in Table
Filter-based collaborative design process.
Design parts | Collaborative interaction | Filter operation | |
---|---|---|---|
Process 1 |
|
|
The architect’s filter translates the design and publishes it. The published data will include 3D geometric information and XML tags connected to its private data model. As additional information, the publication has the following information: |
|
|||
Process 2 |
|
|
The structural engineer’s filter retrieves the latest version of the design. Although it encounters the same terminology in the design, the filter is missing some information such as “inertia,” or “moment.” Then, it begins to break the architectural model into structural pieces. It then translates the model into the structural engineer’s own model for design review or modification. When the structural design is ready, the filter gathers necessary information (e.g., 3D geometric data, properties, etc.) and publishes the design with XML tags |
|
|||
Process 3 |
|
|
The published data created by the structural engineer includes the following information: |
|
|||
Process 4 |
|
|
The first task of the filter is to try to find available spaces where the ducts can fit in using the provided knowledge base and spatial reasoning tools as shown on the suggestion to the left |
|
|||
Process 5 |
|
|
The mechanical engineer’s filter displays who is in charge of the proposed design and semantic information (e.g., bearing or nonbearing wall). Here, because the interfering walls are nonbearing walls, the mechanical engineer decides to modify them with additional information (e.g., explanation on his proposed action). His filter will publish the proposed design with the following information: |
|
|||
Process 6 |
|
|
After the mechanical engineer’s filter publishes the proposed design, the architect’s filter takes and processes it. Consider the case that the proposed design is within the range of the tolerance specified by the architect. Still, the filter lets the architect know there is a modification by the mechanical engineer. After obtaining the architect’s confirmation, his filter publishes the accepted design to remain consistent. Likewise, the architect’s published data will be retrieved and processed by the structural engineer and the mechanical engineer’s filter |
|
|||
Process 7 |
|
|
When the plumbing engineer’s filter retrieves all the published data, which were contributed by the architect, the structural engineer, and the mechanical engineer, it begins analyzing geometries to find available spaces. Then, it suggests the spaces surrounded by the beams/columns (the structural engineer) and the ducts (the mechanical engineer) including clearance confined by the ceiling (the architect) |
|
|||
Process 8 |
|
|
After the plumbing engineer’s filter publishes the design, the other participants’ filter will be notified with the following information: |
|
|||
Process 9 |
|
|
Like the other MEP engineers’ filter, the electrical engineer’s filter suggests available space so that the engineer can design the electrical systems |
|
|||
Process 10 |
|
|
The design published by the electrical engineer’s filter contains the following information: |
|
|||
Process 11 |
|
|
Each filter supports a corresponding participant’s individual design work as well as collaborative interaction with other participants by providing filtered information and representation |
Recently, to tackle semantic issues in IFC based information exchange, “information delivery manual (IDM)” and “model view definition (MVD)” have been introduced [
As the case study is to verify the conceptual feasibility of the proposed model, there are limitations that need to be considered for practical application. First, because the ontology itself does not have a mechanism to detect any duplicity between different ontologies, to maintain ontological consistency without semantic conflicts, the participants need to agree on their ontologies in advance by, for example, sharing a glossary. Second, design dependency, which is an important aspect in design collaboration, has to be considered. Dependencies between participants’ design solutions can be managed by specifying sender and receiver data. Moreover, through design collaboration, the participants’ various design versions should be controlled in some way in order to avoid conflicts among outdated versions. One possible way is to use some popular version control system in the field of programming, such as concurrent versions system (CVS) [
In this paper, we have discussed the concept and implementation of a filter-mediated communication model for collaborative design in order to try to answer the following questions. How could knowledge be represented for collaborative design? How could it be shared (or communicated) for that purpose? How could it be queried?
To answer the first two questions, we propose the filter-mediated communication model and its process to reflect the characteristics of multidisciplinary collaborative design by focusing on a semantically rich representational method based on ontology that is mediated by intelligent filters. By fulfilling the discussed tasks, it is expected that the designers from different disciplines for an AEC project can better understand the dynamic process of collaborative design for achieving a high level of shared understanding.
We also present a computational implementation of the filter mechanism. It assumes that there are two distinctive design workspaces (i.e., the SDW and the PDW) facilitated by the filter operated by the individual participants. The model uses XML as an underlying technology that enables integrating semantics into geometries. A possible implementation is presented through off-the-shelf applications (i.e., SketchUp and its customization language). The participants benefit from the filter-mediated communication in that they can retrieve relevant representations from their SDW by creating user-definable queries (from simple filtering based on keywords to enriching representations through in- and outpublish. One participant also can see others’ perspectives by adopting their filter, which would be an answer to the third question.
Through the proposed filter-mediated communication, we expect to achieve the following benefits: (i) participant-oriented representation, (ii) distributed, (iii) interleaved communication, and semantics-aware document management. First, once the participants contribute their knowledge to the representation, the filter can make each participant see the other’s point of view. The dynamic and semantically rich representation would allow the participants to make alternatives reflecting their intents more effectively, which eventually would lead to a state of shared understanding. Second, the impact of a network-based design collaboration can transform a hierarchical, linear partitioned process into a distributed and interleaved one. As a result, the participants do not have to share a large and heavy integrated model. Rather, their intelligent filter will access the information in the object level (geometric/nongeometric information and ontologies) which resides at its own location and translate it into their own representation using user-defined ontologies. This can fill the gap between the heterogeneous representations while preserving semantics. Lastly, when an object appears in more than one data set, with different ontologies (e.g., the architect’s wall and the structural engineer’s wall), the filter can recognize this duplicity and perform consistency-management, possibly formulating queries on behalf of a participant. Through this process, the participant may reduce design errors and delivery time without sending his or her designs to other participants and achieve the design goal more efficiently.
The authors declare that there is no conflict of interests regarding the publication of this paper.
This work was supported by Grants funded by Ministry of Land, Infrastructure and Transport of Korean Government (12 High-tech Urban D13), the National Research Foundation of Korea (no. 2012R1A1A1012857), and the Korea Sanhak Foundation.