# An Inspection of IFC Models from Practice
## 2 Industry Foundation Classes
### IFC Semantics  
IFC semantics are structured in a deeply hierarchical data model, additionally organized in meronymic (part-of) trees too. Spatial composition, by means of _IfcSpatialStructureElements_ ([[https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/s](https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/s)]([https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/s](https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD1/HTML/s)) schema/ifcproducxtension/lexical/ifcspatialstructureelement.htm, accessed on 1 March 2021) (Site/Building/Storey/Space/Zone) is one more kind of aggregation, different from the element (meronymical) composition one (e.g., a stair and the assembled elements in it). _IfcSpatialStructureElement_ is used to define a spatial units structure, by means of which the building project is organized. In addition, various forms of semantic information can be associated to the elements, such as materials, properties (key-value pairs) and even scheduling. Elements are also related to one another, for example for wall connectivity and space boundaries. Moreover, it is often possible to store the same kind of object by means of several entities. For example, the layers within a compound wall object can be represented by means of an associated IfcMaterialLayerSet, but also as a more generic decomposition where every wall layer is modelled as a distinct IfcBuildingElementPart. Many attributes can be provided for elements, as foreseen by class specifications that can be inherited from their parents. In addition, property sets (already in the standard or added as extension) can be used. This semantic complexity is intended to represent faithfully the buildings as functional to the designed scope. However, the implementation and use of such theoretically precise models is difficult and can result in inaccuracies or the underuse of the most complex features, besides hindering interoperability by providing a very high degree of freedom to fill in the information in different ways and by choosing one of the many possible kinds of representations that can be used [23]. In order to define subsets of the IFC models to be implemented, the Information Delivery Manual (IDM) is added as part of the buildingSMART standard. It defines the workflow and the information exchange specifications and requirements for needed use cases. From each IDM, a set of Model View Definitions (MVDs) can be defined for identifying the portion of the IFC model which is needed for the information exchange described in the IDM to be fulfilled. The documentation of an MVD allows the exchange to be repeated, providing consistency and predictability across a variety of projects and software platforms. MVDs are provided as part of the IFC releases and mostly implemented by software are the 'Coordination view' for IFC 2x3 and the 'Design Transfer view' and 'Reference view' for IFC 4. These different views differentiate whether a model is intended as a static reference (IFC4 ReferenceView) or as a parametric model to transfer the design intent (IFC4 DesignTransferView). In the first case, geometrical definitions are much simpler and explicit, whereas in the latter case, it will require the application of much more geometric processing (such as Boolean set operations and sweeps) to come to an evaluation of the geometrical form of the model. The concepts represented in IFC are organized in four conceptual layers, as represented in Figure 1.  
Figure 1: The four layers in which the Industry Foundation Classes are organized. Source: IFC4.1 specification. The core layer contains the classes which are central and most general in the data model.