# A Systematic Review of the Trends and Advances in IFC Schema Extensions for BIM Interoperability
## 3 Evolution, Architecture, and Implementation of the IFC Schema
### Core Architecture  
Conceptually speaking, the IFCs can be thought of as a set of agreements about the semantics, or more practically, an interface agreement to exchange data between software tools tailored for the industry. The IFCs have their roots in the Standard for the Exchange of Product (STEP) (ISO 10303-242:2022 [26]), which is a globally recognized standard for the exchange of product model data across different software applications and computer systems. The IFCs provide the standard means to represent product models specifically for the AEC industry, by representing the definitions or concepts for products, processes, or resources of various domains through a conglomeration of multiple schemas. These schemas are realized using EXPRESS, a conceptual schema language which provides for the specification of entities belonging to a defined domain, the information or attributes pertaining to those entities, and the constraints on those entities (unique, exclusive, etc.). The IFC schema is organized into four conceptual layers, i.e., domain, share/ interoperability, core, and resource layers. Their definitions, scope, and example entities (which have IFC as prefixes) are provided below:  
Domain layer:  
This is the highest layer, which includes schemas containing entity definitions that are specializations of products, processes, or resources specific to a certain discipline. Hence, this layer consists of individual domains for architecture, structure engineering, facility management, etc. It is noteworthy that each domain definition is typically utilized for intra-domain exchange and sharing of information. In other words, those entities are used exclusively for that domain. Entities within a domain that require sharing with other domains are defined in lower-level schemas. For example, the _IfcArchitectueDomain_ houses entities such as _IfcDoorStyle_ and _IfcWindowStyle_, which are both specific door qualifiers exclusive to architectural entities. Similarly, the _IfcStructuralAnalysisDomain_ defines parameters only used for structural engineering analyses, such as _IfcStructuralLoadCase_ or _IfcStructuralCurveAction_. Shared/Interoperability layer:  
This layer consists of schemas with entity definitions specific to the general product, process, or resource specializations applicable across multiple disciplines. These definitions are commonly used for inter-domain exchange and where sharing of construction information among various disciplines is expected. For example, the architectural elements require sharing between all domains and disciplines. Thus, _IfcSharedBldgElements_ includes entities such as _IfcWall_, _IfcSlab_, _IfcColumn_, and _IfcDoor_, which are elements commonly shared among multiple domains. Similarly, _IfcSharedFacilitiesElements_ includes entities such as _IfcFurniture_ and _IfcOccupant_. Core layer:  
This layer incorporates the kernel schema and core extension schemas, housing the most general entity definitions. All entities defined within the core layer or higher layers possess a globally unique ID (GUID), unique reference number used to identify objects, and may optionally include owner and history information. The schema _IfcKernel_ defines the most abstract part or core part of the specification. It captures general constructs, that are basically founded by their different semantic meaning in a common understanding of an object model, such as an object, property, and relationship. These are, respectively, represented by the entities _IfcObjectDefinition_, _IfcRelationship_, and _IfcPropertyDefinition_, which are subtypes of _IfcRoot_. Those are then specialized into non-AEC/FM specific constructs, such as a product, process, control, and resource, which form the main entry points for the next level within the schema architecture, the core extension layer. For example, the _IfcProductExtension_ includes the abstract entities to represent a building element (i.e., _IfcBuildingElement_), which is then subtyped to the shared elements layer (e.g., _IfcSlab_).