Integration of Industry Foundation Classes and Ontology: Data, Applications, Modes, Challenges, and Opportunities

Abstract

Industry Foundation Classes (IFCs), as the most recognized data schema for Building Information Modeling (BIM), are increasingly combined with ontology to facilitate data interoperability across the whole lifecycle in the Architecture, Engineering, Construction, and Facility Management (AEC/FM). This paper conducts a bibliometric analysis of 122 papers from the perspective of data, model, and application to summarize the modes of IFC and ontology integration (IFCOI). This paper first analyzes the data and models of the integration from IFC data formats and ontology development models to the IfcOWL data model. Next, the application status is summed up from objective and phase dimensions, and four frequent applications with maturity are identified. Based on the aforementioned multi-dimensional analysis, three integration modes are summarized, taking into account various data interoperability requirements. Accordingly, ontology behaves as the representation of domain knowledge, an enrichment tool for IFC model semantics, and a linkage between IFC data and other heterogeneous data. Finally, this paper points out the challenges and opportunities for IFCOI in the data, domain ontology, and integration process and proposes a building lifecycle management model based on IFCOI.

1. Introduction

Industry Foundation Classes (IFCs), developed and maintained by the buildingSMART International (bSI) (formerly known as the International Alliance for Interoperability, IAI), provide an open and neutral schema for storing and exchanging BIM data. They rely on the EXPRESS language and concepts for its definition [1] and are expected to describe all building components.

Globally, BIM regulations in various countries continue to highlight IFC as the preferred format for delivering design results. Over 400 software applications, including Solibri [2], Revit [3], Bentley [4], and SketchUp [5], enable the exchange of IFC data among stakeholders. Many studies have shown that IFC data can be exchanged and managed for rule checking [6] and structural design analysis [7] during the design phase, construction cost estimation [8] and progress monitoring [9] during the construction phase, and structural health monitoring [10] during the operation and maintenance (O&M) phase. In short, IFC enables the exchange of information between BIM and other IFC-compatible environments, which improves the efficiency, effectiveness, and performance of whole lifecycle management.

Nevertheless, there are still some challenges in domain information representation and heterogeneous data fusion in BIM-incompatible environments, where professional boundaries in vendor barriers limit the interoperability of BIM data. IFC provides a rich yet redundant and ambiguous schema for interoperability and the same information may have multiple data structures in the IFC data schema, which is caused by the lack of semantic clarity in mapping entities and relationships [11]. Due to data heterogeneity, information loss, omission, error, or even inaccessibility may occur in the interaction between BIM and other related data, such as cost data, professional analysis data, monitoring data, and Geographic Information System (GIS) data. Even if IFC is committed to the integration of data from different users throughout the lifecycle, additional technical means are still needed to address data heterogeneity.

Ontology is defined as a formal, explicit specification of a shared conceptualization [12]. As a Semantic Web technology, ontology can represent, exchange, and reuse domain knowledge and define relationships between concepts. In addition to powerful descriptive capability, ontology can deduce new knowledge through rule-based languages. Ontology has good adaptability and has been widely used in medicine [13], biology [14], engineering [15], agriculture [16], and other fields. In the AEC/FM field, ontology is proven to have applicative value in various tasks, such as knowledge representation [17,18], data interoperability [19,20,21], and rule-based reasoning [22,23].

Given the capacity of ontology and the challenges faced by IFC, IFCOI is dedicated to addressing data heterogeneity issues. Integrating IFC data with ontologies can be applied throughout the lifecycle, ranging from design [24] and preconstruction [25] to construction [26], operation, and maintenance [27]. Prevailing research shows that IFCOI has been used in compliance checking [28], facility management [29], cost estimation [30], and so on. With the explicit and normalized representation capability, ontology can be combined with IFC to eliminate interoperability differences across domains and phases and thus facilitate whole building lifecycle management.

There are 19 literature review articles [31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49] on IFCOI according to a preliminary literature retrieval. Among them, five literature reviews focus on the application of IFC or ontology in a specific domain [31,32,33,34,35], seven discuss the role of ontology in integrating BIM with other technologies [37,38,39,40,42,43,47,48], and six review the independent application of IFC or ontology [36,41,44,45,46,49], respectively. However, there is no comprehensive review of IFCOI. Hence, it is worthwhile and necessary to conduct a systematic multi-dimensional review, including data and applications, to unearth the integrational modes of IFC and ontology. This review intends to answer the following questions:

(1)

At the level of data and models, what are the existing categories, their distribution, and the dominant types applied in IFCOI?

(2)

At the level of applications, how many objective types and phases are covered and what are their specific applicable scenes? And how are they used?

(3)

Further, what are the existing modes of IFCOI according to the integrational mechanism and degree and their applicability and feasibility, as well as pros and cons?

(4)

What are the challenges and future opportunities of IFCOI?

Therefore, the structure of the review is as follows. Section 2 illustrates the methodology of this review and initially analyzes the sample literature base. Section 3 elaborates on the data and models of IFCOI based on the relevant theories. Section 4 analyzes the current status in terms of application objectives and application phases. Section 5 summarizes the modes of IFCOI. Section 6 discusses the current challenges and the future opportunities. Section 7 concludes this review.

2. Methodology

Web of Science Core Collection, which is widely used in literature reviews in the AEC/FM field and contains the most important and influential journals in the world, is chosen as the database for paper retrieval for high-quality papers [50,51]. To ensure a comprehensive review of IFCOI, the selection of papers is not limited to the AEC/FM field, it also considers relevant interdisciplinary fields, such as computer science. These research fields determine the corresponding categories setting of WOS in Step 1 (as shown in Figure 1). To have no omissions in paper retrieval, ‘BIM’ and ‘Semantic Web’ are also added to the search string apart from ‘IFC’ and ‘ontology’. We selected the relevant literature in recent decades to study the latest research progress of IFCOI, and the corresponding time range was set from 1 January 2011 to 30 June 2023. Keywords included, but were not limited to, ‘BIM’, ‘IFC’, ‘ontology’, and ‘semantic web’. Boolean operators were used to combine multiple keywords, and the corresponding search string is shown in Figure 1.

In Figure 1, the paper acquisition consisted of four steps: retrieving, preliminary screening, rescreening, and bibliometric analysis. In Step 1, the aforementioned topic expression is applied to get a database of 252 papers (excluding proceeding papers) after the categories setting of WOS (as of 30 June 2023). In Step 2, we excluded papers that did not integrate IFC and ontology based on title, abstract, and keywords. In total, 174 papers were retrieved. Step 3 eliminated papers that had little relevance to IFCOI after reading the full texts. After this process, the number of papers was reduced to 122, including 19 review papers. Finally, the sample literature base is preliminarily analyzed from the aspects of paper source, publication date, and keywords, and a more in-depth and comprehensive analysis is carried out in Section 3, Section 4, Section 5 and Section 6.

This research used NoteExpress v3.7.0 [52] to analyze the journal distribution of selected papers, and the result is shown in Figure 2, with Automation in Construction [53] as the top journal. The fields of these papers mainly lie in AEC/FM, computer science, and geographic information science. This result aligns with the objective of this review.

A statistical graph of the number of papers every year from 2011 to 2023 is shown in Figure 3a. There is an upward trend in the number of publications. The number has increased yearly since 2018, and the trend has become more obvious in the past two years. This trend demonstrates the steady progress of research related to IFCOI and highlights the significance of this literature review. The keyword co-occurrence temporal overlay network graph drawn by VOSviewer v1.6.19 [54] is shown in Figure 3b. In the keyword co-occurrence analysis graph, the circles’ size and color reflect the frequency and time of keyword occurrence.

After classifying the keywords, the words and phrases ‘interoperability’, ‘linked data’, and ‘information extraction’ indicate that IFCOI addresses the issues of data interoperability and information integration. Therefore, it is necessary to analyze the integrated data and integrated tools (i.e., ontology). The words and phrases ‘operation and maintenance’, ‘smart city’, ‘automatic compliance checking’, ‘hbim’, and ‘gis’ indicate that IFCOI has various functions for different objects and at different stages. Additionally, ‘Automated compliance checking’ and ‘operation and maintenance’ are shown to be hot issues and are popular in the latest research. These results provide a reference for the determination of the following research dimensions.

3. Data and Model

Based on the results of the above bibliometrics analysis, this section analyzes the integrated data and integration tools (i.e., ontology) from the dimensions of data and model. First, the integrated data and their characteristics are clarified. Second, we shed light on ontology models that link various heterogeneous data, focusing on the choice of ontology description languages and development methods. Additionally, IfcOWL is an important attempt to use ontology in BIM to address the data interoperability issue [55]. Based on IfcOWL, BIM data are converted to ontology data. On the one hand, the IfcOWL data schema is as close to the IFC standard as possible and contains all the data in the IFC document [56]. On the other hand, the form of ontology data transformed from BIM data is conducive to data mining, analysis, and query. Many studies have used IfcOWL or the ontology extended from it to transform IFC data into ontology data to achieve data integration. Therefore, in Section 3.4, we specifically elaborate on IfcOWL, which plays an important role in promoting data interoperability in IFCOI.

3.1. IFC Data

As the most recognized data schema for BIM, IFC can provide convenience for information communication between BIM environments and other IFC-compliant environments [57]. It is intended to facilitate data management through the whole lifecycle, and its applicability extends across many other areas involving industrial data modeling, including design, construction, simulation, and evaluation [58]. The IFC schema is divided into four layers from bottom to top [59]: Resource Layer, Core Layer, Interoperability Layer, and Domain Layer. Each conceptual layer contains several sub-modules, and each sub-module contains many entities, types, functions, and rules. Each level can only refer to the information resources of the same and lower levels, but not those of the upper level, to ensure the stability of the information description. IFC could define new classes as subclasses of existing classes from which the new classes inherit their properties [60].

The IFC standard defines, in detail, the representation of basic information, geometric information, and attribute information. In the IFC data schema, each entity describes its own information through attributes. For example, Figure 4 shows the inheritance relationships of IfcBeam. IfcElement in the figure has 13 attributes, some of which we omitted. There are six layers of inheritance from IfcRoot to IfcBeam. The attributes of entities in IFC files are mainly obtained through inheritance relationships. In addition to its own attribute, IfcBeam has all attributes derived from the parent entity through inheritance. Therefore, through the IFC data schema, the required BIM data can be quickly acquired.

In order to facilitate the integration and query of IFC data using an ontology, there are three main formats to directly or indirectly obtain the data acceptable to ontology when exporting IFC files. A total of 51 papers discussed the IFC data format, as shown in Figure 5a. The first is to export the default file format directly and then convert it to RDF format using the IFC-to-RDF converter. IFC generally uses the STEP Physical File (SPF) [61] for clear text representation of EXPRESS data models. Considering maximum compatibility and minimum file size, SPF is the most widely used format in IFC. The second is the ifcXML format, which is based on the ISO standard for representing STEP data in Extensible Markup Language (XML) format [62]. The XML format is more readable and is suitable for more software, but its size is larger than the SPF format. Lastly, export to the Terse RDF Triple Language (Turtle) format or Resource Description Framework (RDF/XML) format [62] based on IfcOWL (discussed in Section 3.4), which are two ways of RDF data serialization. They are more flexible in data description but have very large file sizes.

Both researchers and buildingSMART have made a lot of efforts to fully explore the semantics in IFC, and the continuous enrichment of supported file formats also reflects the feasibility and trend of using ontology to enrich BIM semantics. The characteristics of the three IFC data formats are shown in

Table 1. IFC data formats and their characteristics.

Format	Extension	Characteristic/Advantage	Disadvantage	Reference	Number
SPF	.ifc	The most widely used and compact format	Later format conversion	[26,56,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86]	27
XML	.ifcXML	Enhanced readability; applicability to more software	113% file size	[25,30,57,87,88,89,90,91,92,93,94,95,96,97,98]	15
Turtle RDF/XML	.ttl based on IfcOWL .rdf based on IfcOWL	Great flexibility in data description	1372% file size 816% file size	[27,29,69,76,87,90,99,100,101]	9

. We found that the SPF format was used the most. Even if the SPF format needs to be converted into a data format acceptable to ontology later, the SPF file size is small and it’s easy for researchers to preprocess IFC data.

3.2. Other Heterogeneous Data

With the rapid development of the Internet of Things (IoT), enormous amounts of data from multiple sources are collected, which may have different structures, formats, semantics, and uses. The heterogeneity of these data is manifested in the following:

• Source diversity. Data can come from different fields, e.g., construction and the geographic information industry;
• Structural differences. Data can be structured, semi-structured, or unstructured, e.g., tabular data, text, and images;
• Format Diversity. Data can be in different formats and encodings, e.g., XML, SPF, and JPEG;
• Semantic difference. The semantics of the data can vary depending on the source and structure of the data, and it is necessary to mine semantic information in practical applications;
• Usage Diversity. Data can be applied to different domains and for different purposes.

In the retrieved articles, heterogeneous data (mainly unstructured data) involved in different application fields are diverse, including but not limited to specification text [28], GIS data [92], schedule [102], sensor data [27], laser scanning data [72], real-time monitoring information [103], and equipment status information [104]. A big difference between structured and unstructured data is the ease of analysis. Unstructured data have no predefined data model and are technically more difficult to standardize and understand than structured data due to their large volume and diverse formats. It is important for the ontology to describe and represent these data in a structured way to exploit their rich semantics.

These multi-source heterogeneous data can provide more comprehensive and in-depth information, and the integration of IFC and these data through ontology can expand the data interoperability and application scope of BIM. For structured and semi-structured data, ontology can map the concepts and their relationships to achieve integration. For unstructured data, the ontology needs to express the data in a structured way to ensure that the semantics can be obtained, and then establish the mapping relationship.

3.3. Ontology Description Language and Development Methods

With its ability to describe information in an explicit and unified way, ontology is an essential bridge to integrate IFC data and other data. The different ontology description languages and development methods will affect the specific applications of IFCOI.

3.3.1. Ontology Description Language

Ontology languages have different expression and reasoning mechanisms, so it is necessary to choose an appropriate language for their representation and description during ontology development. With the rapid development and broad application of web technologies, web-based ontology description languages have gradually become mainstream. In this review, the main ontology description languages are web-based RDF and OWL and object-oriented UML (see Figure 5b). To some extent, this reflects the concentration of these description languages in the IFC data model association.

Resource Description Framework (RDF), developed by the W3C, is a framework for representing information on the web [105], which is essentially a data model. RDF (S) commonly refers to a combination of RDF and Resource Description Framework Schema (RDF Schema, RDFS) [106]. The RDF data model consists of an RDF graph and an RDF dataset. The RDF graph contains a series of logical statements about concepts and their relationships. These statements are often referred to as ‘RDF triples’ (see Figure 6), which are directional and consist of a subject, predicate, and object. In addition, each concept and relationship has a Unique Resource Identifier (URI) so that RDF graphs can be explicitly labeled. The RDF dataset is used for a collection of RDF graphs.

Web Ontology Language (OWL) aims to describe the classes and their relations that are inherent in web documents and applications [107]. OWL can be categorized into three sub-languages: OWL Lite, OWL DL, and OWL Full [108]. OWL, as an extension of RDF(S), provides more expressive elements for ontology description. Thus, OWL has stronger reasoning capabilities. However, the RDF(S) and OWL support only a basic level of inference, and the complexity of inference is limited. More complex reasoning and retrieval should be performed using more specialized rule languages. Semantic Web Rule Language (SWRL) [109] and SPARQL Query Language for RDF (SPARQL) [110] are two commonly used rule languages for deductive inference and query, respectively.

Unified Modeling Language (UML) is a modeling language for object-oriented analysis and design with strict syntactic and semantic specifications. The metamodel provides a consistent, common definitional description for all elements of UML, eliminating the effects of differences in expression methods.

In summary, RDFS is essentially an extension of the RDF vocabulary, while OWL adds predefined vocabulary and provides faster and more flexible data modeling capabilities. Both OWL and UML support modular structure. The difference is that UML graphical modeling is more intuitive and easier to communicate and understand, while OWL has a stronger logical foundation for efficient reasoning.

Table 2. Ontology description languages and their characteristics and applications.

Language	RDF(S)	OWL	UML
Characteristics	Limited expression capacity	Stronger expression capacity	More intuitive and understandable graphical modeling
	common data format	inference capability
Reference	[30,66,70,89,97,111,112,113,114]	[11,25,27,29,56,58,61,63,64,65,69,71,72,73,77,78,85,86,88,94,96,101,102,104,115,116,117,118,119,120,121,122,123]	[67,124]
Application	Compliance checking, HBIM, cost estimation, etc.; buildings and infrastructure; whole lifecycle		Infrastructure; O&M

shows the ontology description languages and their characteristics and applications. We found that most researchers choose OWL as an ontology development language due to the requirement of reasoning ability. The second is RDF, considering that it is a common uniform data format. In addition, rule languages, such as SWRL and SPARQL, are also used for more complex reasoning.

3.3.2. Ontology Development Methods

Ontology development should adhere to the following principles: clarity, coherence, extendibility, minimal encoding bias, and minimal ontological commitment. The development and refinement of the ontology is an iterative process of back-and-forth and additions. There is no uniform method for ontology construction, so choosing the appropriate method according to different requirements is necessary.

The main ontology development methods are IDEF5 [125], Toronto Virtual Enterprise (TOVE) [126], Seven-Step method [127], KATUCS [128], Skeletal method [129], METHONTOLOGY [130], etc.

Table 3. Ontology development methods and their characteristics.

Method	Characteristics/Advantages	Disadvantages	Reference
IDEF5	A general approach that all ontology development methods should follow	Too abstract	[125]
TOVE	A method for developing a task ontology; solving a specific problem; enterprise modeling	No iterative process for the generated ontology	[126]
Seven-Step method	Building domain ontologies; high maturity	Lack of inspection and evaluation	[61,85,116,117,120,121,132]
KATUCS	Based on the existing ontology or applied knowledge base emphasizing knowledge reuse	Few details of the method	[128]
Skeletal method	Describing specific terms between enterprises; ontology validation required during development	Ambiguous ontology evolution	[129]
METHONTOLOGY	Emphasizing ontology reuse; suitable for developing large ontologies	Failing to reflect iterative evolution	[67,74,78,81,133]
Multi-step iterative methodology	Guiding ontology development through competency questions allowing for ontology evaluation	-	[26]
Neon Methodology	A scenario-based methodology emphasizing the reuse, reconfiguration, and merging of resources	No guidance on key aspects of engineering processes	[27,98]

‘-’ Indicates that no related literature is found.

shows the functions and characteristics of these methods. The methods involved in the retrieved articles are the Seven-Step method, METHONTOLOGY, multi-step iterative methodology [126], and Neon Methodology [131]. The Seven-Step method [127] (also known as Ontology Development 101) was developed by Stanford University and consists of seven steps. This method is more specific and detailed and is widely cited by researchers in various fields. METHONTOLOGY [130], proposed by the Artificial Intelligence Lab at the Technical University of Madrid, typically involves six segments: specification, knowledge acquisition, conceptualization, integration, implementation, and evaluation. It is a generalized approach to ontology development. The multi-step iterative methodology [126] is a method proposed by Grüninger and Fox to build ontologies and allows a more precise evaluation of an ontology. The Neon Methodology [131] proposes multiple ways to develop ontologies and identifies nine scenarios that cover common situations. This method emphasizes the reuse of knowledge resources. The characteristics of these two methods are also shown in Table 3.

In addition, ontology reuse [83,131] is a very important approach during ontology development. Some basic information can be provided by other available ontologies, thus saving a lot of work in ontology building.

3.4. IfcOWL

IfcOWL ontology is a common choice for ontology reuse. It was obtained by transforming the EXPRESS schema of IFC into an OWL ontology [134]. IfcOWL ontology allows the representation of building data in terms of Semantic Web and Linked Data. Semantic Web technology can connect IFC data to other data, including material data, sensor data, GIS data, etc., through RDF graphs. These data form a web of building data that facilitates data management in different domains.

It is more accessible and targeted to meet the needs of different applications by developing new ontologies based on IfcOWL ontology or extending IfcOWL ontology. Ma et al. [71] built a domain ontology on the BIM-R platform based on IfcOWL to facilitate the use of ontology data in RDF files converted from BIM data. Soman et al. [135] used IfcOWL to capture model information and construct LinkOnt to introduce classes missing from IfcOWL but needed for constraint checking. Romero et al. [64] extended the IfcOWL and ifcRDF models with fuzzy information. The extended fuzzy ontology avoids the cumbersome details of the underlying theoretical framework while supporting imprecise queries. Combined with Semantic Web, IfcOWL ontology can also link non-geometric data with multiple geometric representations, allowing the mapping of IFC data to geospatial data [136].

IfcOWL ontology is derived from the EXPRESS schema and is obtained through the EXPRESS-to-OWL converter. In practice, there are still some challenges in the applications that require complex reasoning because of the redundancy in mapping from EXPRESS to OWL and the large size of IfcOWL ontology. Nonetheless, what is certain is that IfcOWL and ontologies extended from IfcOWL can facilitate data exchange and sharing. To a certain extent, the proposal and application of IfcOWL also reflect the necessity and trend of IFCOI.

4. Applications of IFCOI

4.1. Application Objectives

Through the analysis of the papers with explicit application targets, we found that the number of applications targeting buildings and infrastructures accounted for 72% and 24%, respectively (as shown in Figure 7). The building-oriented IFCOI applications mainly focus on Historic/Heritage Building Information Modeling (HBIM), green building, and facility Management (FM). Infrastructure-oriented applications are mainly for roads, railways, and tunnels. There are also some applications at the urban level, which are placed in the category of buildings according to the research focus.

4.1.1. Buildings

In the building-oriented papers, the proportion of applications in HBIM, prefabricated building, green building, and facility management is shown in Figure 7. In this subsection, these applications are discussed in turn.

HBIM

In the field of cultural heritage, Historic/Heritage Building Information Modeling (HBIM) is formed after the investigation and collection of historical data. Due to complex geometry and various data types, HBIM faces some challenges in data integration. Ontology is used to facilitate the sharing, integration, and storage of heritage data.

The focus of IFCOI in HBIM is to integrate BIM with the knowledge base developed through ontology to enhance knowledge representation and management in built heritage processes. Mattia et al. [137] developed an ontology-based vaults database to effectively combine heterogeneous data and thereby reconstruct a rich history of European building technology and skilled labor. de Oliveira et al. [138] introduced an improved workflow for converting traditional BIM models into semantic models, which can improve knowledge sharing and reuse among different stakeholders of historic building projects. Ontologies developed for HBIM have different focuses, such as mesh-to-HBIM modeling [113], generating parametric structured models from point clouds [74], and developing an ontology-based vault database [137].

A few studies evaluated the interoperability of cultural heritage information ontology. Andrej et al. [139] followed the ontology-evaluation framework OQuaRE and proposed externes, composability, and aggregability indicators to evaluate the interoperability of CIDOC CRM ontologies.

However, in the process of transmission, data loss typically occurs. On the other hand, the construction of the knowledge base and mapping file is mainly carried out manually, resulting in an increase in time cost.

Prefabricated Buildings

The application of IFCOI in prefabricated buildings mainly focuses on design optimization and construction safety. Xu et al. [140] used BIM to achieve the forward design of prefabricated assembly buildings and combined it with ontology for knowledge visualization and expression, thus solving the problems of data heterogeneity and lack of semantic expression. Shen et al. [85] proposed an automated ontology- and BIM-based risk identification and response method so as to provide timely information and knowledge for safety risk decision making in prefabricated building construction. It can be seen that the application of IFCOI in this field is mainly in the expression of ontology knowledge based on BIM models.

Green Building

Traditional green building evaluations rely on subjective feedback and are less efficient and reliable. Integrating the green building evaluation process with BIM allows for extracting the building information for assessment. However, the information obtained from BIM is very limited, and the consistent representation of the assessment knowledge is the main challenge. Semantic-based domain ontologies can provide a shared and consistent model to express the fragmented assessment information in a regularized way, so the green building evaluation work can be carried out with the help of ontology based on IFC data.

Jiang et al. [118] constructed a Green Building Evaluation Ontology (GBEOntology) to represent knowledge and promoted the green building evaluation process based on BIM and the constructed domain ontology. To facilitate interoperability with building energy simulation tools, Costa et al. [87] represented the BIM model using IFC and Semantic Web technologies and converted the BIM into energy-building simulation models through two query languages.

We can see that BIM acts as a data provider of the evaluated building, and ontology is used to structurally represent the information in the specifications, thus facilitating the green building evaluation process. In a word, the application of IFC with ontology in this field is mainly manifested in the expression of ontology knowledge and rule reasoning based on BIM models.

Facility Management

Facility management (FM) is intended to manage the planning, preparation, and maintenance of the human living environment with the latest technology. FM information has the longest duration in the whole lifecycle of a building and is tightly linked to the BIM model in the preceding phase. It also has to be embedded with massive real-time growing O&M data. Therefore, stronger data interoperability is required. In order to increase the accessibility of object-oriented BIM data, ontology is considered in the FM information management work.

Kim et al. [29] effectively managed BIM-based FM information by linking BIM-based building elements and FM work information in the FM system database, which enhanced the interoperability and accessibility of FM data. Colucci et al. [141] proposed a methodology for mapping BIM data to domain-specific sets of concepts, which can be used for managing and maintaining facilities and infrastructure. Dibley et al. [98] developed and implemented a software system utilizing various techniques, such as IFC and ontology, to generate useful working knowledge for FM.

Research on the application of IFCOI in this field focuses on establishing the association between BIM models and FM information through ontologies. The phenomenon may be due to the diversity, complexity, and large volume of data in the O&M phase, and ontologies are better suited to play the role of information medium in this scenario.

In summary, IFCOI applications are in high demand and have a good performance in building-oriented applications.

Table 4. Integration application methods and data information.

Type	Integration Application Method	Data Information	Reference
Historical Building	Enhancing semantic representation, knowledge representation, and management	3D building models; built heritage information	[40,72,74,113,122,137,138,139,141,142]
Prefabricated Building	Heterogeneous data fusion; access to richer knowledge and information	Design models; construction models; assembly and fabrication knowledge	[85,140]
Green Building	Structured representation of knowledge; rule-based reasoning	BIM; specification text	[32,73,87,89,96,98,118,123,143]
Facility Management	Linking BIM and FM data; access and use of BIM-based facility information	Building models; historical working records of facilities	[29,78,80,90,93,98,101,114]

demonstrates the integration application methods and data information of the above applications. Through the above analysis, we found that the multi-source heterogeneity of data is the main challenge for applying IFC on buildings. Through ontologies, various types of data (including unstructured text) can be integrated and associated with IFC data, which can improve the data interoperability of BIM in other domains.

4.1.2. Infrastructure

Compared with buildings, infrastructure involves more complex information. Infrastructure data have high heterogeneity and complex spatiotemporal relationships. Management throughout the lifecycle requires a high degree of expertise. Therefore, the application of IFCOI in infrastructure management focuses on the fusion of heterogeneous data from different times and spaces. Hagedorn et al. [79] developed a web-based platform in which transportation infrastructure data are provided or exchanged in the form of information containers.

We summarized the infrastructure-oriented application of IFCOI from infrastructure types, data types, ontology models, functions, and application phases, as shown in

Table 5. IFCOI data types and applications in terms of different infrastructure types.

Infrastructure Type	Data Type	Ontology Model	Function	Application Phase
Tunnel	IFC data; facility information	TDO	Defect Diagnosis [116]	O&M
	Tunnel model; map data; cadastral map; city model	srt-ontology	Spatial Reasoning of Alignments [145]	Conception and Planning
	IFC data; status information; activity information	—	E-maintenance [103]	O&M
	IFC data; collected data	OntModel	Surface Subsidence Risk Warning [104]	O&M
Road	IFC data; equipment data; digital terrain model	IFCInfra4OM	O&M Management [124,146]	O&M
Railway	IFC data; railway code	IfcOWL	Compliance Checking [147]	Design
Airport	IFC data; facility information	IfcOWL; Airm-mono	Facility Management [101]	O&M

. We found that the O&M phase is where IFCOI is most used for infrastructure and determined that many studies tended to reuse public and existing ontologies, such as IfcOWL and srt-ontology [144]. In addition to the IFC data of the infrastructure, the status and operational data of facilities are the main data types. Hu et al. [116] evaluated the proposed TDDS method and found that the automatic data acquisition rate reached 86.7%, the defect detection accuracy rate reached 99.5%, the false positive rate was 0.5%, and the false negative rate was 0%.

In practice, IFC has insufficient modeling ability for infrastructure, so it is necessary to extend IFC to meet the requirements of infrastructure semantic expression. In order to build a BIM model of a multi-component roadbed, Pu et al. [148] mapped the newly added entities and attributes with RSSDO by extending new entities. To ensure a complete description of the concepts in the code ontology, Li et al. [147] extended attribute values, entities, and properties.

For multiple interdependent infrastructure systems, the integration of information from multiple systems is essential for infrastructure resilience decisions. This requires integrating heterogeneous data, acquiring knowledge in multiple domains, and deriving valuable information from the integrated data. Dao et al. [132] built ontologies for drainage, traffic, building, and flood systems, respectively, and used SPARQL and SWRL rules to provide automated decision support.

IFCOI is suitable for infrastructure such as roads, railways, and tunnels based on the aforementioned case analysis. However, there are still challenges in the real-time acquisition, real-time use, and automatic update of data.

4.2. Application Phases

The building lifecycle refers to the entire cycle from conception and planning, design and development, construction, operation, and maintenance to demolition or decommissioning. Based on the preliminary analysis of the sample literature base, the application of IFCOI in this review lies in the design phase, preconstruction phase, construction phase, and operation and maintenance phase.

4.2.1. Design Phase

The design phase is one of the most critical phases in the project process. At the design phase, the necessary information for project implementation is identified, and decisions can be made to avoid negative impact and rework in the project [149]. When used during the design phase of a construction project, BIM can facilitate an effective design process and improve design deliverable quality [150]. In the sample literature base, IFCOI in the design phase focuses on compliance checking and model optimization of BIM models through ontologies.

Compliance Checking

The compliance checking system based on IFCOI generally consists of three subsystems: the BIM data system, the knowledge base system, and the rule reasoning system. The BIM data system is responsible for the extraction and storage of review data. Structured specification knowledge and review rules are stored in the knowledge base system. The rule reasoning system is used to compare the consistency of building information and code information. Zhong et al. [114] developed four specific ontologies for representing and integrating various information to support building environment monitoring and compliance checking.

Compliance checking is generally divided into four steps: ontology modeling, building model preparation, rule construction, and inspection execution.

Table 6. Some studies on specific steps of compliance checking to improve the efficiency and accuracy of the checking.

Researcher	Main Work	Step	Recall	Precision
Peng et al. [100]	Using the NLPIR Chinese word separation system to extract information from unstructured and semi-structured data.	Ontology modeling	-	>96%
Zhang et al. [28]	Using Deep NLP to capture ACC-specific knowledge, AEC domain knowledge, and linguistic knowledge.	Ontology modeling	98.7%	87.6%
Zheng et al. [151]	Strengthening the interpretation of rules based on the NLP approach.	Rule construction	82.2%	94.2%
Zhou et al. [152]	Using deep learning techniques to measure semantic similarity to select matching instances.	Rule construction	93.4%	94.7%
Shi et al. [84]	Designing the NSGA-II optimization algorithm to minimize initial construction costs and seismic loss expectations.	Inspection execution	-	-
Lee et al. [24]	Using the AHP-TOPSIS method to provide design suggestion rank.	Inspection execution	-	-

shows some studies that can improve the efficiency and accuracy of compliance checking in specific steps. We found that machine learning, deep learning, and multi-objective decision-making methods have been combined with IFCOI, and these methods have further improved the efficiency and accuracy of compliance checking.

However, current automated methods of information transformation are generally tested on limited specification clauses. Further adjustments are needed to expand the scope of automatic rule interpretation and to accept different types of documents. In addition, since the model data are transformed and mapped in the form of IFC files, errors and omissions are inevitable during data transmission.

Model Optimization

Ontology-based model optimization can enrich the semantics of BIM models and integrate different heterogeneous data, thus improving the interoperability of BIM data. Jeong [97] converted the information defined from the user’s perspective into an ontology and processed the BIM data into linked semantic data from the perspective of building information management, which realized greater interoperability and extensibility than the general model. We can see that the application of IFCOI in this field is mainly in ontology-based BIM data extraction and mapping to obtain semantically rich BIM models.

Several researchers have explored the performance of existing data mapping approaches. Costa and Sicilia [87] identified fourteen different data mapping patterns and three cases of data transformation and reviewed the two best alternatives (SPARQL Construct and SPARQL-generate) for data transformation. They comprehensively evaluated the data transformation process between BIM and other software tools with ontology in terms of the complexity of query generation, format dependency, and performance.

4.2.2. Preconstruction Phase

As its name implies, the preconstruction phase is the stage prior to construction and is critical to the success of a construction project. Different from the design phase, preconstruction activities, including preconstruction planning, cost estimation, and design analysis, can provide the benefits of the early analysis of materials, cost, techniques, and schedules.

Cost Estimation

The bidding process is directly related to the project’s quality, schedule, cost, and economic efficiency during the operation period. Typically, significant cost differences occur in the bidding process [153], and an accurate cost estimation can effectively avoid potential project risks. Cost estimation in the tendering phase requires the work item’s component categorization, quantity takeoff, and unit cost allocation. Work items and unit costs must be prepared strictly with local specifications and are mostly performed manually, which requires the estimator to have an in-depth knowledge of the standards and regulations. As a result, estimation at this phase remains a hazy and inaccurate process [154], and the accuracy and efficiency of cost estimation are significantly affected by the proficiency of estimators. Ma and Liu [71] utilized bill of quantities (BOQ) for bidding cost estimation on the ontology- and freeware-based BIM-R platform by establishing a mechanism to transform BIM data into ontology data. Abanda et al. [25] developed an ontology based on New Rules of Measurement (NRM) for cost estimation in the tendering phase, and the use of IFC facilitated the abstraction of house components for quantity takeoffs and, hence, cost estimation. In this schema, a standardized IDM specified the information exchange, and ontology represented a logically consistent semantic structure of related information items. As we can see, in the cost estimation of the preconstruction phase, the ontology is used to represent the specification text and infer the work item and unit costs based on the BIM data.

Preconstruction Planning

Additionally, it is possible to extend the interoperability of BIM to preconstruction planning activities with ontologies. BIM and GIS data can be integrated with a set of standardized construction operations ontologies, which can offer substantial benefits to managing the planning process during the design and preconstruction phases [92].

4.2.3. Construction Phase

BIM can help construction organizations improve project quality and collaboration efficiency and reduce construction period and expenditure. However, due to the information constantly generated during construction, BIM lacks sufficient flexibility in integrating various information.

IFCOI in the construction phase is mainly applied to monitor and manage quality, schedule, cost (mainly for quantity extraction [66,70]), and safety.

Table 7. Some examples of IFCOI applications during the construction phase.

Researcher	Work	Aspect
Jiang et al. [89]	Combined mvdXML and semantic technology to organize and reuse green construction knowledge	Green construction
Han et al. [26]	Supporting inference and detailed report of progress status when data are incomplete, WBS is at a high level, or BIM is not detailed	Schedule
Soman et al. [135]	Using Linked Data-based constraint checking to define and check complex dynamic construction scheduling constraints	Schedule
Guo and Goh [133]	Developing an ontology for Active Fall Protection System (AFPS-Onto) to facilitate knowledge reuse and sharing	Safety

shows some examples of IFCOI applications during the construction phase. In essence, the performance of IFCOI in the construction phase is to use ontology to test the consistency of IFC data and constraints in the construction process.

4.2.4. Operation and Maintenance Phase

IFCOI in the operation and maintenance phase is mainly applied in defects detection, urban facility management [93], building energy consumption performance assessment [123], historical building maintenance [74], etc. In energy consumption performance assessment, the semantic requirements can be met by ontology-based building object recognition and semantic information addition, which is conducive to improving the interoperability between BIM and assessment systems.

Defect Detection

For the rapid assessment and defect diagnosis, ontology is utilized to establish mapping rules for heterogeneous data integration, and semantically enriched BIM is applied to object recognition in non-contact defect detection. Hu et al. [116] developed a Tunnel Defects Diagnosis System (TDDS) based on IFC and Semantic Web technology, through which spatiotemporal relations and expert knowledge are applied to automatic diagnosis and cause detection of tunnel defects. Zhong et al. [114] presented an ontology-based framework to support environmental monitoring and compliance checking in buildings, focusing on knowledge sharing and interoperability between different information systems through integrating BIM and sensors. Kim et al. [29] semantically linked BIM data to related historical work records and proposed a method to manage BIM-based FM information effectively. They associated building elements and FM information into the FM system database to improve the quality of information search. Ait-Lamallam et al. [124] proposed the IFCInfra4OM ontology, which could integrate O&M information into the road information model and standardize the use of BIM for road infrastructure operation and maintenance. These studies show that the application of IFC and ontology in this domain is mainly characterized by ontology-mediated data integration and correlation.

Urban Management

In urban management, it is necessary to take account of the building itself and its surroundings, and geospatial data cannot be ignored in various applications. BIM models can provide designers and managers with detailed information and visual models but lack spatial analysis capability. While GIS has powerful spatial analysis ability, it lacks detailed information on building components. Researchers naturally think of integrating BIM and GIS. IFC is the standard data format for BIM, and CityGML is a GIS standard developed by Special Interest Group 3D (SIG3D) [155].

Table 8. Differences between IFC and CityGML in modeling language, geometric representation, application scenarios, and level of detail (LoD).

	IFC	CityXML
Modeling Language	EXPRESS	XML
Geometric Representation	B-rep; Constructive Solid Geometry (CSG)	B-rep
Application Scenario	Building details	Urban semantic information
LoD Level	LoD 100–500	LoD 0–4

compares IFC and CityGML in terms of modeling language, geometric representation, application scenario, and level of detail (LoD). In the table, we can find that differences in data schema and LoD level are major barriers to integrating BIM and GIS. Deng et al. [67] generated the mapping rules between IFC and CityGML through an instance-based approach and gave a clear definition of each LoD in CityGML. In this way, the constructed transformation framework between LoDs realized the automatic data mapping between IFC and CityGML in different LoDs.

One way to integrate BIM and GIS is to build an intermediate platform where BIM and GIS are coupled in the same environment. Karan and Irizarry [92] converted building elements and GIS data into RDFD data and used a set of standardized ontologies for preconstruction operations to integrate and query the heterogeneous spatiotemporal data in RDF format. In order to manage geographic elements, Mignard and Nicolle [93] extended an existing facility management system that manages data with semantic BIM. This approach can manage data from both BIM and GIS worlds in the same structure and with the same tools.

Another way to integrate BIM and GIS is to convert BIM data into ontology data and then connect it to the GIS environment. McGlinn et al. [75] developed a national geospatial identifier infrastructure based on OSi building ontology. This infrastructure supports the capture of OSi building data using RDF.

Delgado et al. [156] selected four ontologies from building information and geospatial web domains to evaluate different ontological matching techniques in terms of compliance and performance. They found string-based techniques to be the most appropriate way for CityGML-IFC alignment. It was also found that due to the more complex ontologies of CityGML and IFC, CityGML-IFC alignment takes more time and memory to compute.

In practice, however, semantic alignment is mostly created manually. Additionally, the transformed RDF data are too large to output. The storage method of RDF triples can improve this situation, and further optimization of triples is needed in the future.

4.2.5. Discussion

In this subsection, we discussed the applications of IFCOI in different domains and their involved building data and non-building data (e.g., specification text, record text, monitoring data) from the dimension of the application phase. The applications and their data information in different phases are shown in

Table 9. The applications of IFCOI and their data information in different phases.

Phase	Application Function	Data information	Reference
Design phase	Compliance checking; model optimization	IFC file; BIM model; design specification	[24,28,32,40,57,68,76,77,83,84,85,86,87,92,94,97,100,115,117,118,120,140,147,151,152,157]
Preconstruction phase	Cost estimation; preconstruction planning	IFC file; valuation standard; GIS data	[25,30,66,71,90]
Construction phase	Monitoring and management of quality, schedule, cost, and safety	IFC data; construction specification; on-site records	[26,57,70,73,81,85,89,95,112,133,135,158,159,160]
Operation and maintenance phase	Building energy management, culture heritage maintenance, defect detection, etc.	IFC data; BIM model; historical work records; real-time monitoring data	[27,29,32,35,60,74,78,79,80,82,101,103,104,113,116,123,124,137,146]
Data principal	(1) Direct or indirect association with IFC data; (2) Being expressive; (3) Being associated through ontology.

. Based on the analysis of IFCOI applications, we find that data from different phases and domains enjoy some common principles. (1) The integrated data directly or indirectly relate to certain entities or attributes in IFC files. In short, these non-building data are necessary in the applications of BIM. When some entities or attributes do not exist, an IFC extension can be a solution. (2) Unstructured data can be expressed structurally by ontologies. (3) In IFCOI applications, IFC data and other heterogeneous data can be semantically related through ontologies. For example, SWRL rules can be used to establish a semantic mapping relationship between ontologies describing building information and specification knowledge, respectively.

4.3. Application Framework of IFCOI

In the analysis of application objectives and phases, we explored the implied integration motivations and broke down the application domains and the corresponding data models and ontology functions. Based on this, the characteristics of the application modes are further identified, and hence, the IFCOI application framework is constructed (Figure 8).

The heterogeneity between IFC data and others is the main reason for the lack of interoperability between different systems. The information from different domains and phases brings more challenges for data interaction. Based on the above analysis, three motivations of IFCOI are revealed.

• Knowledge representation. Many IFC-incompatible fragmented data are involved in BIM applications. Ontology can represent information in a structured way to facilitate the storage, sharing, and reuse of IFC-related knowledge.
• Semantic enrichment. External data or knowledge can be linked to IFC through ontologies, enabling IFC to acquire more BIM-incompatible semantic information.
• Data interoperability. Ontology can eliminate the information barriers between IFC and other systems with a common representation method and promote the linking and sharing of heterogeneous data at the semantic level.

Through the decomposition of IFCOI applications in different phases, we also found that IFCOI applications have their own integration mechanisms for compliance checking, cost estimation, HBIM, and BIM-GIS integration. As shown in Figure 8, the IFCOI application in compliance checking and cost estimation is reflected in the construction of the domain ontology and the querying of IFC documents. In Refs. [66,147], the railroad code ontology and construction-oriented product ontology were constructed, respectively, and the rules written according to the specifications or guidelines were executed to query IFC data. In cultural heritage management, the semantic association between IFC and related historical information is established with ontology to obtain semantically enriched and continuously updatable HBIM models. In Ref. [72], the BIM environment is integrated with the knowledge base created through information ontologies, enhancing semantic representation capabilities of architectural heritage processes. In BIM-GIS integration, the semantic mapping of IFC to CityGML is realized through the alignment rules created by the ontology, on the basis of which IFC data can be further queried. In Ref. [145], BIM and GIS were merged at the data level with the ontology database, and the relevant information required for decision making was derived by querying. The underlying IFCOI modes, possibly implied in this IFCOI application framework, will be discussed in Section 5.

5. Modes of IFCOI

Through the analysis of IFCOI from the dimensions of data, models, application objectives, and application phases, collectively, IFC is mainly linked with other data by ontology to obtain semantically enriched models [72] or only provide building data [118], and ontology is used for knowledge representation [89] or as a medium between IFC and other data schemas [93]. According to the purpose of data integration and the semantics and structure of the integrated data, three integration modes of IFCOI are identified (as shown in

Table 10. The division of IFCOI modes from the dimensions of data integration purpose, semantics, and structure of integrated data.

	Mode 1	Mode 2	Mode 3
Data integration purpose	BIM information query	Semantically enriched BIM models	Data interaction at the semantic level
Semantics of integrated data	Being related to entities or attributes in IFC	Potential existence of entities or properties not in IFC files	Data schema different from IFC
Structure of integrated data	Unstructured, but can be represented in a structure similar to IFC		Structured, but different from IFC schema
Application	Rule checking; green building evaluation; cost estimation	HBIM; defect detection; infrastructure management	BIM and GIS integration

), which also implies the increasing degree of data integration, i.e., (1) ontology is used for knowledge representation and rule reasoning without changes in IFC. (2) Ontology embeds domain information into IFC to obtain semantically rich IFC models. (3) Ontology links IFC and other data to facilitate interoperability between BIM and other platforms. The three modes and their integration mechanisms are shown in Figure 9 and are elaborated below.

• Mode 1: Ontology is used for knowledge representation and rule reasoning without changes in IFC.

In the papers related to compliance checking, green building evaluation, and cost estimation, ontology is used for structured representation of knowledge and IFC-based rule reasoning, while there is no change in the IFC document. Various unstructured information is a common feature of these application fields. In fact, cross-domain unstructured information, especially textual information, cannot be entirely understood by computers, thus limiting BIM’s interaction with other platforms. As a formal specification description, ontology can represent semantic knowledge in a structure similar to the IFC schema, so it is suitable for applications that verify the consistency of domain knowledge and IFC information, such as compliance checking and building energy consumption analysis.

In this mode, the IFC file provides building information, the domain ontology represents knowledge, and the reasoning mechanism in the ontology helps to query information from the IFC file. Eastman et al. [161] broadly structured rule checking into four stages. In fact, the process for Mode 1 is very similar to rule checking and is also applicable to green building evaluation and cost estimation. Drawing on the four stages proposed by Eastman, the process of Mode 1 includes (1) rule interpretation: construct domain ontologies based on design, green building, and cost-related regulation text, and rule languages (e.g., SWRL, SPARQL) are used to regularize specification provisions; (2) building model preparation; (3) rule execution: align the prepared building model with the rules and execute the rule statement; and (4) rule check reporting. Throughout the process, we can find that IFC only provides building data, which are not altered or embedded.

In this mode, the knowledge base constructed through the domain ontology could represent and store knowledge, facilitating the expression of complex semantics and the sharing, maintaining, and reusing of knowledge. Additionally, the built domain ontology enables the retrieval of knowledge and the reasoning of new facts, which provides decision-making guidance for the application of BIM in specific domains.

• Mode 2: Ontology embeds domain information into IFC to obtain semantically rich IFC models.

In complex application environments, only the IFC’s semantic information is insufficient to cover the full range of domain information, such as geographic information, historical records, etc. It is the existence of these multi-source heterogeneous data that limits information storage and management [74]. Through ontology, a large number of BIM-independent semantics are embedded into IFC to obtain semantically rich IFC models. This enables domain knowledge to be represented and managed in a unified data environment. The analysis in Section 4 shows that this mode is mainly applied to HBIM, defect detection, and infrastructure management. In the related papers, the ontology performs semantic modeling of raw data outside of BIM, such as social information and environmental resources, and the IFC-based BIM model provides building information and data environment.

This mode focuses on attaching heterogeneous knowledge to BIM. In contrast to Mode 1, this mode emphasizes the establishment of the correspondence between IFC and other semantics in the BIM environment. The knowledge is structurally modeled, and the obtained knowledge base can be combined with BIM to enrich the semantic information of BIM. Using HBIM as an example, in order to fully represent and understand the historical building heritage, IFCOI should contain both BIM information and historical records [137]. A semantically rich model of a historic building requires a BIM model based on the IFC standard and a knowledge base developed based on an ontology. The objects and properties in the ontology knowledge base are embedded into the IFC schema, resulting in an HBIM with extended knowledge representation capability. In addition, IFC needs to be extended to enhance its expression when there are entities or properties (e.g., spatial distances) not present in IFC.

In this mode, the ontology-based knowledge base facilitates the sharing, reuse, and management of domain-specific semantic knowledge, which is conducive to the BIM model’s updating. Additionally, the semantically enriched IFC model offers a complete data foundation for the applications of BIM in a specific domain.

• Mode 3: Ontology links IFC and other data schema to facilitate interoperability between BIM and other systems.

Influenced by heterogeneous data, BIM suffers from loss of information when interacting with some domains (e.g., geography), and even other systems cannot access semantic knowledge in IFC files. This limits the interoperability of BIM with other systems and restricts the application of BIM in other domains. Ontology allows for the representation and process of heterogeneous data in a unified language, such as RDF. Thus, it can be used as the medium for BIM data and other data to facilitate interoperability between BIM and other systems.

This mode is commonly used in the integration of BIM and GIS systems within urban facility management and supply chain management. This mode aims to achieve interoperability between BIM and other systems at the semantic level. In this mode, ontology mapping is used to link similar concepts and relationships between IFC and other data standards (e.g., CityGML). Then, BIM and other source data are transformed into Semantic Web standards (e.g., RDF) for semantic-level interoperability. Each object and property is assigned a unique Uniform Resource Identifier (URI), which can be used to find the corresponding object [92]. Heterogeneous information can then be queried with the rule language.

This mode is the highest level of data integration among the three modes. In this mode, ontology and Semantic Web technology acts as a medium for sharing, understanding, and processing heterogeneous data. Semantic mapping can break down the barriers between BIM data and other data. Additionally, semantic-level data exchange and integration greatly facilitate the BIM applications in various fields.

However, the performance of this mode is not very satisfactory in improving interoperability at the semantic level. Taking BIM and GIS integration as an example, IFC and CityGML have different organizations, different patterns, different geometric models, and different semantics [162]. IFC contains more affluent attribute categories but lacks information related to geographic location, so there are inevitable omissions in the data conversion from BIM to GIS. Meanwhile, the difference in the level of detail between BIM and GIS also needs to be considered [75]. It is necessary to carry out research related to the enhancement of semantic mapping in the future to improve interoperability at the semantic level.

6. Discussion

Through the analysis of literature data and typical cases, the authors identify the challenges of IFCOI and further derive possible research opportunities. If these challenges can be addressed, IFCOI can better enhance the interoperability of BIM.

6.1. Challenges

6.1.1. Consideration of Data

After ontology represents various domain information in the same or similar structure, rules need to be used to align the semantics of these data before data query. At this point, the complexity of data and the expression capability of rules can directly affect the compatibility of data and the flexibility and scalability of integration.

IFC files have complex data structures and often contain too much redundant information. Their characteristics contribute to the difficulty of data mapping and even lead to the failure of mapping. Meanwhile, ontology needs to align different data structures and semantics when representing various domain information in the unified data format. Converting files and models to RDF datasets significantly increases data size. For example, when an IFC file is exported to the RDF/XML format, the file size becomes 816% of the default format, and when exported to Turtle, the file size becomes 1372% [62]. Costa and Sicilia [87] mentioned that the transformation and representation of RDF data evolve at a slow pace, and the extraction of mapping is not always easy. When the data amount is larger and the structure is more complex, the mapping rules will also be longer and more difficult to fully represent. As a result, it takes more processing time to map more data to ontology or even fails to do so successfully, which reduces the flexibility and scalability of ontology mapping.

There is also a lack of flexibility in data queries. The diversity of the data and the limited expressiveness of reasoning rules can cause inefficiency in data querying. Due to the additional information converted to RDF or embedded in IFC files, the amount of mapped data is tremendous. Both data processing and querying can be highly computationally intensive and time consuming. A great deal of data can result in the slow loading of ontology models and very large query-generated files. Even some ontologies (expression ontology and fuzzy ontology [64]) take significant time to solve simple queries. In addition, it is difficult to write and run rules when querying data with complex relationships, even resulting in query failures. To overcome this limitation, distributed RDF storage [27] and adding supplementary indexes [163] can be considered to simplify the information contained in ontologies. When the same RDF triple store is used for different levels of detail, complex SPARQL queries need to be written to select the triples associated with particular building information. If more semantics are added to the generated triples, the query is simplified by the required level of detail.

6.1.2. Consideration of Domain Ontology

Given that Semantic Web technology is still evolving, fully acknowledged ontologies applicable to specific domains are not yet accessible. As a result, researchers within the same domain develop their ontologies independently, which limits the exchange of information between different users.

Due to BIM’s multidisciplinary and multi-stakeholder characteristics, IFC-related ontologies alone are insufficient to comprehensively address a specific domain. Sometimes, only a small portion of the IFC file is selected to validate the feasibility of the proposed approach [63], leaving the ontology not fully meeting the BIM needs in the specific domain. Liu et al. [164] mentioned that a single IFC4 document cannot fully cover the product retrieval needs in the AEC domain. Kim et al. [96] mentioned that the ontology domain should be expanded to include more than the building materials in the default library. Combining IFC-related ontologies with other AEC resources is desirable to cover a broader range of BIM resources. Furthermore, establishing a management process for ontologies and knowledge bases is essential to ensure the continuous and consistent implementation of the proposed methodology.

6.1.3. Consideration of Integration Process

The implementation of IFCOI is not entirely automated, and substantial manual effort is required at various stages of the integration process. First, current ontology development tools primarily consist of manual development tools (e.g., Protégé [165]) and semi-automated development tools (e.g., Jena [166]), and most of the papers adopt manual development methods. Secondly, mapping IFC files to ontology requires a certain amount of manual work. Sometimes, the alignment needs to be specified manually by domain experts using predefined functions/languages. In addition, refining the rule language is a manual task. This challenge might be overcome by developing fully automated converters, IFC data parsers, and conversion engines to automate the transformation between BIM and other data formats.

6.2. Opportunities

6.2.1. Automated Information Extraction and Representation

In order to minimize manual errors in the process, many studies have emphasized the automatic extraction and representation of information in IFCOI. More advanced techniques can be applied to facilitate the performance of automated interactions.

Future algorithms can focus on representing and delivering semantic information to clearly identify the connections between BIM and other systems. Natural language processing and other techniques can be applied to automatically generate query rules [28] to improve the accuracy of data queries. New rules are considered to detect inconsistencies or ambiguities in the ontology and enable automatic updating of the rule set in response to changes in the IFC standard. Efforts should be directed towards developing a fully automated converter or an IFC data parser and conversion engine using a programming language to achieve automatic conversion between different data formats.

6.2.2. Ontology Extension and Management to Cover a Broader Scope

Developing a new ontology has the advantage of meeting the user/developer requirements for concepts and properties as best as possible. However, when a large number of ontologies are developed, it is difficult to manage them, and even the interoperability of these ontologies cannot be achieved. Considering consistency, reusability, interoperability, and efficiency, the extension of existing ontologies is a way to break through the limitations of existing ontologies when applied. Before developing new ontologies, researchers should assess existing ontologies and determine whether reusing them is beneficial to the application. Some studies have taken this approach and developed new ontologies based on existing ones (e.g., IfcOWL [64,135] and NRM [25]).

Table 11. Some existing ontologies suitable for reuse in the AEC/FM domain.

Name	Prefix	Domain
IFC Ontology	IfcOWL	https://standards.buildingsmart.org/IFC/DEV/IFC4/ADD2_TC1/OWL, accessed on 13 March 2024
Building Topology Ontology	bot	https://w3c-lbd-cg.github.io/bot/, accessed on 13 March 2024
Building Product Ontology	bpo	https://www.projekt-scope.de/ontologies/bpo/, accessed on 13 March 2024
Digital Construction	dic	https://digitalconstruction.github.io/v/0.3/index.html, accessed on 13 March 2024
Data Catalog Vocabulary	DCAT	https://www.w3.org/TR/vocab-dcat-2/#UML_DCAT_All_Attr, accessed on 13 March 2024
Time Ontology	Time	https://www.w3.org/TR/owl-time/, accessed on 13 March 2024
Semantic Sensor Network Ontology	ssn	https://www.w3.org/TR/vocab-ssn/, accessed on 13 March 2024
Organization Ontology	Org	https://www.w3.org/TR/vocab-org/, accessed on 13 March 2024

presents some ontologies that can be considered for reuse in the AEC/FM domain.

A comprehensive domain ontology needs to be compatible with various heterogeneous data types and fully consider different participating subjects. Due to the limitations of the storage and data processing capability of a single ontology, the involvement of multiple ontologies becomes a good alternative [91] and the management of these ontologies is the other way to broaden the scope of application. Compared with large ontologies (e.g., IfcOWL), smaller and modular ontologies can be developed, which are simple in structure and can meet the needs of specific applications. These smaller modular ontologies are more conducive to extension and data mapping. In the future, we can try to develop an ontology search engine to integrate more AEC ontologies so that users can query and obtain existing ontologies faster and more conveniently. In addition, there is a need to develop open, shared, and recognized ontologies. Alongside their publication, detailed documentation of the concepts and relationships should be made available to reduce the current trend of continuously creating new ontologies [167].

6.2.3. Further Semantic Transformation

In order to meet the needs of applications in different domains at different phases, the accuracy and depth of data integration must be ensured. The understanding and transformation of semantic information is the focus of integration. An approach worth considering is the combination of IFCOI with machine learning [104], Natural Language Processing (NLP) [151], and deep learning [152] methods to ensure that IFC information is semantically consistent with other domain information. Researchers have now begun to use these methods to process semantic data and optimize rule interpretation. Yin et al. [99] proposed a graph neural network (GNN)-based semantic parsing method, which can transform natural language queries (NLQs) into SPARQL queries but poses heavy computation costs. McGlinn et al. [123] used an Artificial Neural Network (ANN), a Genetic Algorithm (GA), to intelligently generate and optimize rules. Attempts can be made to develop tools that realize the automatic generation of semantic data models from IFC models, and the results can be queried and represented based on ontologies.

6.3. Building Lifecycle Management (BLM) Based on IFC and Ontology

Building Lifecycle Management (BLM) encompasses planning, design, construction, and O&M, forming an integrated management platform that connects all phases. The BLM information platform allows for the creation, management, and sharing of consistent and comprehensive building information, which reduces the loss of information between phases and between participants. Unfortunately, there are several barriers to BLM implementation, such as information silos, low data interoperability, and poor cross-party co-ordination [168,169]. Ontologies offer a structured description of domain-specific knowledge and facilitate mapping IFC data to integrate information from BIM and other domains. It is an effective way to solve the data interoperability problem faced by BLM. Therefore, we are considering constructing a BLM model based on IFC and ontology to make BLM more digital, integrated, and visualized.

As shown in Figure 10, the BLM model based on IFC and ontology comprises four layers: data, model, object, stage, and application. In addition to IFC data, the data layer includes building-related data and environmental data collected to fulfill specific application needs. The model layer is used to store various distributed ontologies and generate mapping rules and query rules. Ontologies include IfcOWL, geographic information ontology, multi-model visualization ontology, and various domain ontologies (e.g., CCO for compliance checking, WIO and WCO for cost estimation, GBEO for green building evaluation). Various ontologies developed can structurally represent data and realize integration and interaction, improving interoperability in different stages and different fields. This model supports both BLM for buildings and BLM for building facilities. Various domain ontologies in the model layer can be used in different stages to meet various management needs. At the same time, data generated during and after an application can support application management in subsequent stages. In the BLM process based on IFC and ontology, the participation of technologies, such as BIM, GIS, IoT, database, and cloud computing, is required.

7. Conclusions

This paper is the first systematic review of IFCOI in the AEC/FM field and presents a scientific bibliometric analysis of 122 articles in terms of data, models and integration applications. Based on these, we summarize three integration modes and further discuss the current challenges and opportunities. The following conclusions are drawn from this literature review.

(1)

We first conduct a bibliometric analysis from the perspective of data and models. In order to expand the interoperability of BIM, ontology plays a critical role in integrating IFC data with other data. IFC files can be exported in SPF, XML, and RDF formats, and other unstructured data can be mined through ontology for their semantics and linked to IFC. Researchers can select appropriate ontology description languages and development methods to construct ontologies. In addition, IfcOWL, as a current model of IFCOI, is applied to different scenarios, directly or after extension, yet causes complexity in data mapping. Nevertheless, this can be solved by simplifying IfcOWL and ontologies based on IfcOWL.

(2)

We perform a statistical analysis of integration applications across various objectives and phases (design, preconstruction, construction, and O&M) dimensions. Buildings are the primary objective of the research. Nevertheless, IFCOI is also very suitable for infrastructure because of the large amount of spatiotemporal data involved. Drawing from bibliometrics and discussions in Section 4, IFCOI demonstrates a broad spectrum of applications throughout its lifecycle. Among them, it is applied more in the design phase and O&M phase, with good performance in compliance checking, HIBM, and cost estimation. Additionally, we discussed the motivations for the integration and constructed a framework diagram for IFCOI application.

(3)

We carry out an in-depth analysis of the roles played by IFC and ontology in IFCOI. Given the different integration purposes, semantics, and structures of data, the modes of IFCOI vary accordingly. Based on this, three modes of IFCOI are summarized (see Section 5). Among them, Mode 1 and Mode 2 perform well in different applications. Mode 3 is mainly utilized for BIM and GIS integration. Unfortunately, the performance of Mode 3 is not entirely satisfactory due to differences in data models and levels of detail. In the future, efforts should continue to be made to seek breakthroughs in this area.

(4)

Despite the advantages, IFCOI mainly faces the following challenges: low flexibility and scalability in data, limited coverage of domain ontology, and incomplete automation of the process. To address these challenges, we suggest possible corresponding solutions as references for future research. In addition, IFCOI has the potential for building lifecycle management, so we propose a BLM model based on IFC and ontology, which could significantly contribute to the digitalization, integration, and intelligence of management processes.

There are some limitations to this review. Since this review only considers the WOS database in the selection of papers, there is a possibility of omissions. Furthermore, the review primarily concentrates on the data, models, applications, and modes of IFCOI, with relatively less emphasis on technique aspects of data mapping and new knowledge reasoning through rules.