Towards Better Co-Design with Disciplinary Ontologies: Review and Evaluation of Data Interoperability in the AEC Industry

Abstract

In the building industry, disciplines have specific requirements for capturing, storing and representing information. As a result, one physical object yields several disciplinary representations, allowing designers to describe design options discipline-specifically and thus explore design differently. In a co-design approach, data from disciplines must be integrated and interoperable. But in current practice, interoperability problems between different software often hinders data integration. This paper presents a review and evaluation of interoperability paradigms in centralized, decentralized, and federated data, and it gives AEC application examples for each approach. It discusses data schemas (e.g. IFC) and interoperability tools (e.g. Speckle, BHoM). It also relates the interoperability tools to semantic web standards that are used to share information. It argues the advantages of federated data interoperability and suggests using design tools that employ such a mechanism. Furthermore, this paper suggests developing modular disciplinary ontologies to support collaborative design tools. Such federated interoperability, supported by modular disciplinary ontologies, can provide a solid ground to share and exchange data flexibly.

Keywords

• 1 Interoperability
• Co-Design
• Knowledge representation
• Ontologies
• Building Information Modelling (BIM)
• Data mapping and alignment

1. Introduction

Architecture, Engineering, and Construction (AEC) projects need multidisciplinary solutions, where each discipline has specific requirements for capturing, storing and representing information [ 1 ]. While a structural engineer would represent a building as a whole of columns, beams and slabs, which can be further simplified as linear elements during structural analysis, an architect would view columns and beams as solid three-dimensional objects and would instead idealise a building as an aggregation of spaces [ 2 ]. Similarly, other disciplines also have specific requirements for capturing, storing, and presenting relevant information [ 3 ]. Such disciplinary representations of buildings and building elements also allow a disciplinary exploration of design options. Analysis of each model representation’s properties and data attributes will enable us to identify significant disciplinary model issues [ 4 ].

However it is a widely known fact that the most critical decisions in building design are taken in the conceptual design phase. They influence not only construction costs [ 5 ], but also subsequent building energy use [ 6 ]. Thus an integrative approach that considers design and analysis methods, manufacturing and construction processes, as well as material and building systems simultaneously, such as ‘CoDesign’ [ 7 ], must integrate data from multiple disciplines starting from the early phases of design. In practice, this integration is often hindered by interoperability problems between different software. Combining multiple knowledge representations is still a significant challenge that has not been entirely solved so far [ 3 ].

The proposed paper presents a review and evaluation of interoperability paradigms in centralized, decentralized, and federated data. It gives AEC examples of each approach. It discusses the Industry Foundation Classes (IFC) data schema, alongside tools that allow interoperability such as the webbased open-source data platform Speckle (Speckle, nd), and the open-source Building Habitat object Model (BHoM) collaborative platform (BHoM, 2018). This paper relates interoperability tools to academic research on the semantic web by the Linked Building Data (LBD) community. Semantic web technologies augment the value of building data by enabling data integration and complex search queries across several data sources [ 8 ]. The proposed paper argues how the largely geometric information of tools such as Speckle or BHoM can be independently connected to semantic information using ontologies. It discusses how ontologies can support collaborative design tools, and it suggests developing modular disciplinary ontologies to support co-design processes.

2. Review of key approaches to the interoperability problem

Interoperability refers to the possibility of communication, data exchange and use, between different software [ 9 ]. In industry and academia, different frameworks and data schemas are developed and being used to tackle the interoperability problem of a co-design process. The current section describes the IFC data schema, Speckle [ 10 ], and BHoM [ 11 ]. 2.1.

Data schemas and frameworks for interoperability

IFC is a standardized data schema for the AEC industry based on the EXPRESS data model. IFC data can be encoded in XML, JSON, or STEP file formats. IFC files are used to exchange data between BIM software. They are used to store information used and exchanged throughout the lifecycle of a built structure [ 12 ]. IFC was developed along with a set of building product models by the International Alliance for Interoperability (IAI) (former name of buildingSMART) to represent and exchange data in the AEC industry [ 13 ]. The industry standard for exchanging building information models is defined by the IFC [ 14 ].

IFC data schema consists of four layers: domain layer, interoperability layer, the core layer, and resource layer [ 14 ], where each individual schema is assigned to one conceptual layer. The schema represents building elements including semantic information such as attributes or relationships, as well as abstract concepts or processes. The latest IFC version, IFC4x2 has 407 types and 816 entities [ 15 ]. All these data is represented in a monolithic approach [ 14 ], meaning that data is stored and manipulated from a single, centralized data store. While the intention of modularizing the schema was originally there, the IFC schema resulted in multiple dependencies between concepts and modules in the opposite direction [ 15 ]. IFC is powerful in representing geometric data, element classification and product properties, but it falls short when it comes to representing dynamic data [ 16 ].

Speckle is an AEC data communication web-based platform, allows real-time collaboration, data management, versioning and automation [ 10 ]. It offers a neutral schema for the specification and creation of basic geometry types [ 17 ]. It was initially developed in academia by D. Stefanescu at UCL, as part of the InnoChain project, an H2020 Marie Curie European Training Network [ 13 ]. In Speckle, data can be articulated and shared at various levels of abstraction in real-time between many AEC software (Revit, Rhino, Grasshopper3D, AutoCAD, etc.). Such flow is possible due to SpeckleAbstract type and Speckle Core Converter class functionalities that allow for serialization standard .NET classes [ 18 ]. The base class for all Speckle object definitions provides unified hashing, type extraction and serialization [ 10 ]. Currently, a Speckle Kit consists of Core Geometry, Elements and Structural. Core Geometry is to represent geometrical objects; Elements correspond to BIM elements (mainly Revit centric) and Structural Kit is a structural specific kit focused on structural elements [ 10 ]. Speckle has a limited library with around 150 object models [ 10 ]. It provides a web viewer of building elements with a limited library, but indeed, it mainly focuses on connecting software rather than representing building elements.

BHoM is a collaborative open-source framework initially developed by Buro Happold. It integrates a large number of concepts across existing languages and platforms [ 17 ], by allowing disciplinary representation of design options [ 11 ]. BHoM's data structure and manipulation strategy are directly compatible with visual flow-based programming and text-based imperative code [ 13 ]. BHoM consists of (1) object models, (2) engines that operate on data, (3) adapters that map and translate data among different software and (4) user interfaces for software where its functionality is exposed. The object models (oM) defines data we manipulate by providing a set of properties. All oMs are primary group in specific namespaces, e.g. Architectural Namespace, Structural Namespace, and they can exist in different forms in different namespaces. E.g a panel exists in the Physical Namespace as well as in the Acoustic, or Structural Namespace, and in each of them it is represented differently. Currently, there are 1251 BHoM oM types [ 11 ]. Any oM contains a basic data structure with a GUID [ 19 ], where data is semantically rich based on the discipline/namespace it lives in. BHoM allows data dictionary extension dynamically. The Engine presents a structured collection of components/methods such as algorithms and tools to manipulate data. Similarly with oMs, Engine methods are also grouped in specific BHoM namespaces. Adapters refer to the connectors between the BHoM and AEC software; they allow BHoM objects to be translated to and from their proprietary representation used in disciplinary software. We can access BHoMs functionally through its Grasshopper, Dynamo and Excel interfaces. While Rhino3D and Grasshopper3D might not be focused on the architectural industry or any specific industry [ 20 ], BHoM adds this layer by permitting users to scale and process building data, including semantic information. 2.2.

Linked data and ontologies

Existing efforts conducted in academia through the Linked Building Data (LBD) community group have been focusing on using semantic web standards as an open, decentralized alternative to the existing centralized approach of storing and sharing data [ 13 ]. Linked Data is a semantic web approach, where data is published and linked in a standardized way [21]. It relies on the Resource Description Framework (RDF), a standard data model of the semantic web technology stack [22]. In RDF, data entities can be related to one another, in forms of triples (subject, predicate, object). RDF Schema (RDFS) and Web Ontology Languages (OWL) can be used to restrict and specify data further. OWL is a formal language to author ontologies, and ontologies represent knowledge about things, groups of things, and relations between things [23]. In the past, a vast number of AEC ontologies have been proposed, such as ifcOWL, Building Topology Ontology (BOT), Teddy Ontology (TDY), etc. IfcOWL ontology [24] expresses entities, types and properties based on the IFC Schema. BOT [25] is a minimal ontology for describing the core topological concepts of a building. TDY Ontology [26] addresses structural analysis related attributes of building elements. All values described with the TDY ontology are saved in the respective default unit of SOFiSTiK - a structural analysis software. LDB ontologies intend to provide modular ontologies that are easy to combine with other ontologies. While LBD ontologies, e.g. BOT, are meant to be modular and easy to connect, ifcOWL is instead a larger and more “comprehensive” schema, making it harder to relate to other ontologies. 2.3.

Summary: Interoperability approaches

In the previous section, we discussed different approaches and tools that tackle the interoperability problem of a co-design process. While interoperating, there are different levels of data flow, such as (i) the data exchange format, (ii) the schema level and (iii) the data model. The data exchange format is a data format for converting from one file or database platform to another. A data schema is an organization of data, which might and/or might not be based on an ontology. It imposes domain constraints on how data can and must relate to each other, which might affect how data is represent-ed using the data model and what data can be conveyed in the data exchange format. At a data model level, data is exchanged using a format that prescribes the syntax of the data serialization. The same information can be conveyed via different formats. For instance, JSON and XML are two different syntactic formats that, although they look very different, they both can be used to convey tree-like information. Two different JSON or two different XML documents may convey exactly the same information. For example, document content may be reordered without changing the represented information itself. The abstraction from such syntactic ideosyncracies is captured in an underlying data model. For example, a graph data model can be used to represent what is exchanged with JSON and/or XML documents. There may be, however, impedance mismatches between documents and data models, which prevent the canonical understanding of document in terms of the data model.

There might be a distribution of data at various layers, resulting in different interoperability paradigms. However, in current AEC practices, we often encounter distributed interoperability across all layers where data is exchanged (Fig.1a), a centralized data schema across all disciplines (Fig. 1b), or federated interoperability where tools share an ontology that tools can relate to and refine (Fig. 1c). In the following subsections, we discuss distributed, centralized, and federated interoperability paradigms (adapted from [27]) in general, and provide an AEC application example of such interoperability.

Distributed interoperability introduces interoperability between systems with independent lifecycles [28]. Meaning that there is no single point of failure, so there is no part of such a system that, if it fails, will stop the entire system from working. In other words, there is no integrated system, but rather different authorities exchange data in a regulated or unregulated manner. If it is regulated, they may follow a joint data model, schema and format. If it is unregulated, data exchange requires mappings at several levels, i.e. between different data models, between different schemata and/or between different data formats. E.g. if data models are different, not only the schemata must be mapped, but also the data models. In AEC traditional file based data exchange employs such paradigms. However, not only file exchange is considered to apply a distributed interoperability; a piece of information exchange, objects or data exchange can also apply the paradigm. For example, Speckle data platform employs a similar mechanism to achieve interoperability where data can be articulated and shared at various levels of abstraction [ 10 ]; therefore, Speckle falls under the distributed data interoperability approach.

The centralized approach uses a common data schema over a common underlying data model. Different applications or tools that share the same data schema can be used to collaborate on the same overall project. a system that has a shared data schema has the same data exchange format as well. However in current AEC practice several platforms that rely on different format share and exchange information with a shared schema. A canonical example of such an approach is IFC, which represents data in a monolithic approach [ 15 ].

In a federated approach, there is no common format for the tools; thus, parties accommodate on the fly [29]. There are multiple authorities and several schemata (each authority tends to define its own schema). However, a connection federates between the different databases, and that connector provides the data model and the schema that is used to query the different systems with their different schemata. Therefore, using a federated approach implies that no member sets its models (all represent data in their discipline), and corresponding tools must share an ontology to map their concepts at the semantic level [29]. The shared ontology can also be a group of modular ontologies, which would align with the intention of LBD ontologies. Such modularity would allow disciplinary ontologies to live independently as modules, and flexibly align or connect with other ontologies.

In AEC, BHoM supports such disciplinary representation building elements and a shared mapping process by using its adapters to map the data among many AEC software [ 11 ], which makes BHoM an example of the federated interoperability approach. However, BHoM lacks the shared schema based on an ontology.

3. Evaluation and Proposal

This section evaluates how the aforementioned interoperability approaches accommodate building data including their semantics and mapping processes. 3.1.

Comparison of interoperability approaches

Using decentralized (distributed or federated) data interoperability over a centralized process model may introduce redundancy and inconsistency; for example, when different workflow branches drawing on the same input converge, combining data from different but overlapping models [27]. However, a centralized interoperability paradigm contradicts the multidisciplinary nature of building industry. A centralized workflow reduces the freedom and flexibility of designers to create their workflow processes from any selection of tools, and it hinders the ability to define and explore unconventional design spaces [27]. Therefore, a common data schema, seems not applicable for co-designing buildings. Consequently, the IFC schema presents many restrictions when co-designing. Additionally, the IFC data schema, has also some limitations in representing data. IFC lacks energy-acoustics analysis and simulation properties [30], therefore it prevents us from digitally integrating acoustic data in a co-design process. BIM/IFC also faces issues in the manufacturing and prefabrication disciplines, such as: lacking support for complex products, missing data sovereignty, impaired searchability and findability, the uncertainty of desired detail, etc. [31]. Customizing data representation on the IFC data schema requires going through a change request process, which is often quite rigid and not agile because the IFC standard evolves via a committee. As a result, a common data schema based on IFC appears to be unsuitable for co-design.

While a distributed system offers data exchange seamlessly across different users and software platforms, it may introduce data redundancy when several workflow branches merge and combine data from different disciplines [27]. An ontology that others can relate to and refine could tackle this issue, converting this paradigm from a decentralized and non-federated interoperability to a federated one. Put it simply, each discipline uses its corresponding tool and represents data discipline-specific derived from their data schema, but these schemas are connected with an ontology. Such an approach opens a new way of looking and working beyond an established conventional practice, allowing diverse perspectives and thus different performance exploration [32]. Therefore, a co-design process should follow a federated data interoperability in order to allow flexibility in disciplinary data representation and as well as integrated workflow. Such data federated interoperability can be combined with tools that link disciplinary data representation built on disciplinary software. One way to go, is using the BHoM framework, which supports such disciplinary representation building elements and a shared mapping process by using its adapters to map data among many software [ 11 ]. BHoM objects can be enriched and connected to semantic information using ontologies. 3.2.

How ontologies can support collaborative design tools

In this section, we compare tools that allow interoperability, like Speckle and BHoM, and discuss how this largely geometric information can be independently connected to semantic information using ontologies.

Speckle mainly focuses on connecting software rather than representing building elements, and has a limited number of objects. Therefore the intermediate format while transferring data is represented based on the native software. For example a Speckle Column is found of the Objects.BuiltElements namespace, and a subclass of that column is the RevitColumn. Speckle, detaches element property to visualize it, as well it can create RevitColumn by some given properties [33]. The properties are dependent on how a column is represented in Revit and they are set using parameters like: level, offset, structural, rotation, family, element ID, etc.

In BHoM, there are different object models that can represent one building element. For example, a column is differently represented in a physical oM than in a structural oM. In a physical oM (Fig. 2a), a column is defined as follows: public virtual ICurve Location { get; set; } = new Polyline(); public virtual IFramingElementProperty Property { get; set; } = null; A structural oM (Fig. 2b),would represent a column as a bar, defined as: public virtual Node StartNode { get; set; } public virtual Node EndNode { get; set; } public virtual ISectionProperty SectionProperty { get; set; } = null; public virtual double OrientationAngle { get; set; } = 0; public virtual BarRelease Release { get; set; } = null; public virtual BarFEAType FEAType { get; set; } = BarFEAType.Flexural; public virtual Constraint4DOF Support { get; set; } = null; public virtual Offset Offset { get; set; } = null;

However, these two concepts live independently from each other, meaning that if we use them oMs alongside each other to refer to the same column there might be inconsistencies or duplicated data. Because the polyline built in the physical oM is also built from a StartNode and EndNode like in the structural oM. Currently, what they have in a common is the way to represent it in a spatial dimensional interface so-called IElement1D. Any class that can be represented by ICurve has such a representation.So, currently the startPoint and endPoint of a structural oM and a physical oM may be considered the same or not, and it is crucial to link their data. This is where schema based on an ontology would be useful, since it would link the data, in this case the endpoints of a structural oM to those of a physical oM.

BHoM object models can be augmented with semantic information using AEC ontologies, which would provide a more comprehensive representation of buildings and building elements. For example, in BOT ontology, any product described in the context of a building, including a column, is a bot:Element, which is a constituent of a construction entity with a characteristic technical function, form or position (ISO 12006-2). In TDY Ontology, all building elements, including a column, have a teddy attribute class, a superclass for all attributes, which can be used for structural analysis. This class has sub-classes: calculation, concrete strength, continuous elastic support, result, standard [26].

Proposal: Using disciplinary ontologies with BHoM

Following the LBD modular ontology intention, we propose developing disciplinary ontologies using semantic web standards, as modular ones that can align and work with other AEC ontologies. The ontology can follow BHoM’s namespaces structure and content, and they can be further developed since BHoM objects have an open and extendable data dictionary. Alignment modules between the disciplinary ontologies should be provided, so that the disciplinary ontologies can be used simultaneously (Fig.3.). Such alignment modules would not only link concepts but also assist in propagating modifications that happen in disciplinary representations of building elements. The suggested modular ontologies can be easily used simultaneously with existing ontologies such as BOT.

Currently, BHoM allows mapping from one concept to another, using methods underlying in BHoM.Engine, which also helps to estimate data from one discipline to another. However, there is no explicit relationship between objects representing the same entity in a building and this limitations motivates the conversion of BHoM’s object model to OWL. Therefore we propose translating BHoM object models to OWL and augment the current schema with new relations. Alongside our object models, we propose to establish relationships between building elements and parameters that depend on each other using RDF and OWL vocabulary (owl:sameAs, rdf:type, owl:equivalentClass, owl:ObjectProperty, owl:DatatypeProperty, etc). Such an approach will allow disciplinary and integrated views of the design. In the case of the bar and column it would allow to relate the object to each other, such as: <bhom:Column> <owl:sameAs> <bhom:Bar>.

Further relations can be drawn at the instance level, e.g. the start point of the physical oM Column can be connected with start point of the structural oM Bar (Fig.4).

Semantic web technologies remain one of the most promising approaches to integrating different datasets. Combined with BHoM, they lay a good foundation for data interoperability in multidisciplinary co-design of buildings.

4. Conclusion

This paper reviews and evaluates data interoperability approaches in terms of centralized, distributed, and federated data interoperability. It discuss data schemas, tools and platforms that assist data interoperability in the AEC industry. It argues that centralized interoperability paradigm contradicts the multidisciplinary nature of building design. It emphasizes that centralized data schema restricts how data can be represented, thus how designs are explored. While it can be challenging to combine data from different but overlapping models using a decentralized data interoperability paradigm, we discuss the need for ontologies that disciplines can relate to and refine to solve the interoperability issue. Semantic web technologies can tackle this issue, therefore we suggest using ontologies to support data exchange and alignment.

Many tools can be used to build a disciplinary representation of building elements; however, we suggest the BHoM framework because it already allows multiple discrete representations of building elements and a shared mapping process. We emphasize the need for ontologies in order to share a common understanding of information among disciplines. Therefore this paper suggests a federated system, using modular disciplinary ontologies as a promising solution to the interoperability problem in the AEC industry. We suggest developing these ontologies alongside the BHoM framework due to its rich semantics and extendable data dictionary, which would allow customizing the ontologies. Future work will consider the development of disciplinary ontologies with BHoM object models, as modules that can be easy connected and aligned with other AEC ontologies. Future work will also investigate methods to convert BHoM’s data model to OWL, to bring it on board with semantic web technologies.

We expect that federated interoperability, supported by modular disciplinary ontologies can provide a solid ground to share and exchange data in a flexible manner, without data redundancy or information loss.

5. Acknowledgements

Supported by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany's Excellence Strategy - EXC 2120/1 - 390831618. 6. References [21] S. Fuchs and R. J. Scherer, “Multimodels — Instant nD-modeling using original data,” Autom.

Constr., vol. 75, pp. 22–32, Mar. 2017, doi: 10.1016/j.autcon.2016.11.013. [22] T. Berners-Lee, J. Hendler, and O. Lassila, “The Semantic Web,” Sci. Am., vol. 1, May 2001. [23] P. Hitzler, M. Krötzsch, B. Parsia, P. F. Patel-Schneider, and S. Rudolph, “OWL 2 Web Ontology Language Primer (Second Edition),” W3C Recommendation, 2021. https://www.w3.org/TR/owl2-primer/ [24] P. Pauwels and W. Terkaj, “EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology,” Autom. Constr., vol. 63, pp. 100–133, Mar. 2016, doi: 10.1016/j.autcon.2015.12.003. [25] M. H. Rasmussen, P. Pauwels, M. Lefrançois, G. Schneider, C. Hviid, and J. Karlshøj, Recent changes in the Building Topology Ontology. 2017. doi: 10.13140/RG.2.2.32365.28647. [26] Huyeng et al., “Interlinking geometric and semantic information for an automated structural analysis of buildings using semantic web,” in ECPPM 2021 – eWork and eBusiness in Architecture, Engineering and Construction, 1st Edition., 2021, p. 7. [27] B. Toth, P. Janssen, R. Stouffs, A. Chaszar, and S. Boeykens, “Custom digital workflows: a new framework for design analysis integration,” Int. J. Archit. Comput., vol. 10, pp. 481–500, Dec. 2012. [28] J. Delgado, “Interoperability Frameworks for Distributed Systems,” 2019, pp. 1248–1261. doi: 10.4018/978-1-5225-7598-6.ch092. [29] D. Chen, G. Doumeingts, and F. Vernadat, “Architectures for enterprise integration and interoperability: Past, present and future,” Enterp. Integr. Interoperability Manuf. Syst., vol. 59, no. 7, pp. 647–659, Sep. 2008, doi: 10.1016/j.compind.2007.12.016. [30] C. C. Mastino, “The Building Information Model and the IFC Standard: Analysis of the

Characteristics Necessary for the Acoustic and Energy Simulation of Buildings,” 2018. [31] A. Wagner, “Linked Building Data - Describing Multi-Functional and Parametric Building

Products using Semantic Web Technologies,” 2020. [32] A. Batara, B. Dave, and I. Bishop, “Multiple representations in an integrated design environment,” URBAN Des. Int., vol. 9, no. 4, pp. 208–221, Dec. 2004, doi: 10.1057/palgrave.udi.9000127. [33] “Speckle-sharp,” specklesystems Github. https://github.com/specklesystems/specklesharp/blob/ca31096d045131d35b120b84fa672b56b284b78a/Objects/Objects/BuiltElements/Co lumn.cs

References

[1] J. R. Haymaker and C. K. M. Fischer , “ A methodology to plan, communicate and control multidisciplinary design processes ,” 2005 .

[2] N. Kodagoda , “Multidisciplinary Product Models for Buildings,” 2005 .

[3] S. Esser and A. Borrmann , A system architecture ensuring consistency among distributed, heterogeneous information models for civil infrastructure projects . 2021 .

[4] S. M. Pietsch , “ Computer Visualisation in the Design Control of Urban Environments: A Literature Review,” Environ. Plan. B Plan. Des ., vol. 27 , no. 4 , pp. 521 - 536 , Aug. 2000 , doi: 10.1068/b2634.

[5] B. C. Paulson , “ Designing to Reduce Construction Costs,” J. Constr . Div., vol. 102 , no. 4 , pp. 587 - 592 , Dec. 1976 , doi: 10.1061/JCCEAZ.0000639.

[6] M. Levine et al., “IPCC Fourth Assessment Report: Climate Change 2007 ( AR4) Residential and Commercial Buildings . Chapter 6.4.1 .7.,” 2007 .

[7] J. Knippers , C. Kropp , A. Menges , O. Sawodny , and D. Weiskopf , “ Integrative computational design and construction: Rethinking architecture digitally ,” Civ. Eng. Des., vol. 3 , no. 4 , pp. 123 - 135 , Sep. 2021 , doi: 10.1002/cend.202100027.

[8] P. Pauwels , S. Zhang , and Y.-C. Lee , “ Semantic web technologies in AEC industry: A literature overview ,” Autom. Constr., vol. 73 , pp. 145 - 165 , Jan. 2017 , doi: 10.1016/j.autcon. 2016 . 10 .003.

[9] R. Rezaei , T. K. Chiew , S. P. Lee , and Z. Shams Aliee , “ Interoperability evaluation models: A systematic review , ” Comput. Ind. , vol. 65 , no. 1 , pp. 1 - 23 , Jan. 2014 , doi: 10.1016/j.compind. 2013 . 09 .001.

[10] “Speckle Systems,” n.d. https://speckle.systems/

[11] “BHoM. The Buildings and Habitats object Model,” https://bhom.xyz/, n.d.

[12] International Organization for Standardization (ISO), “ISO 16739: Industry foundation classes (IFC) for data sharing in the construction and facility management industries”

[13] P. Poinet , D. Stefanescu , and E. Papadonikolaki, “ Collaborative Workflows and Version Control Through Open-Source and Distributed Common Data Environment,” in Proceedings of the 18th International Conference on Computing in Civil and Building Engineering , vol. 98 , E. Toledo Santos and S. Scheer, Eds. Cham: Springer International Publishing, 2021 , pp. 228 - 247 . doi: 10 .1007/978-3- 030 -51295-8_ 18 .

[14] buildingSMART, “ Industry Foundation Classes . bSI Standards,” n.d. http://www.buildingsmart.com

[15] P. Bourreau , N. Charbel , J. Werbrouck , M. Senthilvel , P. Pauwels , and J. Beetz , “ Multiple inheritance for a modular BIM ,” May 2020 .

[16] P. Pauwels , A. Costin , and M. H. Rasmussen , “ Knowledge Graphs and Linked Data for the Built Environment,” in Industry 4.0 for the Built Environment , vol. 20 , M. Bolpagni , R. Gavina , and D. Ribeiro, Eds. Cham: Springer International Publishing, 2022 , pp. 157 - 183 . doi: 10 .1007/978- 3- 030 -82430- 3 _ 7 .

[17] P. Poinet and A. Fisher, “Computational Extensibility and Mass Participation in Design,” 2020 , pp. 40 - 47 . doi: 10 .2307/j. ctv13xprf6.9.

[18] D. Stefanescu , “Schemas and Standards,” 2017 . https://speckle.systems/blog/schemas/ (accessed Oct. 10 , 2021 ).

[19] M. Dengusiak and F. Greenroyd , Session 3.1 and 3.2 Let's Speak Opensource -BHoM, LadybugTools, etc . using SAM Revit . 2019 .

[20] J. Mirtschin , “ Engaging generative BIM workflows , Collaborative Design of Lightweight Structures - LSAA 2011 ,” Sydney, 2011 , pp. 1 - 8 .