# A Systematic Review of the Trends and Advances in IFC Schema Extensions for BIM Interoperability
## 4 Limitations and Extension Approaches for the IFC Schema  
### Limitations of the IFC Schema  
Despite its evolution and upgraded implementation approaches throughout the years, the IFC still manifests limitations that hamper its active adoption in practice today. The following section summarizes the limitations mentioned in the collected papers as well as those documented in the research related to BIM interoperability and semantic enrichment. (1) Limited coverage:  
The IFC schema has been progressively enriched by adding new entities via continuous version updates. However, its support scope remains confined to selected domains. For instance, since the original versions of IFC development started with the architecture domain, it was unable to support entities of other domains (e.g., infrastructure), nor specialized elements related to state-of-the-art technology, and information particular to regional or specific projects. Before the introduction of IFC 4.3, representing bridge elements in IPCs involved either selecting and temporarily using architecture domain IFC entities that resembled bridge elements (e.g., _IfcSlab_) or extensively utilizing _IfcBuildingElementProxy_ elements, which represent nominal physical elements. These approaches provided a makeshift way to represent bridge elements in IPCs, but failed to represent the semantics sufficiently and exclusively for bridge element properties and their interrelationships. Such limitations created the potential for creating errors and omissions when exporting IPCs between bridge-specific BIM applications, ultimately failing to provide data interoperability in the infrastructure domain [30; 31]. (2) Lagging behind regional practices and evolving technologies:  
The IFC schema, as distributed by bSI, is conceptualized as a'standard' schema designed for general applicability. Consequently, it lacks the flexibility to account for the diverse laws, regulations, and standards that vary across different countries and regions. Moreover, the content and scope of support for each new iteration of the IFC schema are subject to elaborate discussion and voting by the bSI Standards Committee. This rigorous  
Figure 5: BIM data transaction using IDM and MVD. vetting process often results in considerable time lags before the official release, making it challenging to promptly integrate emerging technologies from the AEC/FM industry into the schema [17]. Conversely, depending on their local conditions and BIM maturity rates, the speed of adoption for new IFC releases typically varies across countries. Those parties or institutions that do not have the resources to upgrade local software and processes find it difficult to keep up with the latest updates, which can also lead to asynchronous use of the IFC standard. Selective implementation of the schema in IFC-compliant software:  
The major BIM authoring tools available today have different levels of support for MVDs. That is, these tools provide the most widely used MVDs (e.g., coordination view, design transfer view), but often do not provide the required export functions for the more specialized views [32]. Such restrictions make exporting IFCs inconsistent. The problem is compounded as these tools may incorporate different STEP functions for an IFC translation: Digital Project and Bentley Architecture have both adopted ST-Developer software as their underlying STEP toolkit for developing their IFC translators. Revit Building uses EURO-STEP, and ArchiCAD uses express data manager (EDM) from EPM Technology [33]. These varied implementations can result in different structures and entities used for the same type of information. Moreover, even entities officially released and correctly used may not manifest in receiving software that is IFC-compliant. For instance, the entity _IfcClassification_ is the official entity recommended to represent standard classification systems, such as UniClass and MasterFormat. However, several IFC viewers, such as the FZK Viewer and Open IFC Viewer, do not support the importation of the entity.