# An Inspection of IFC Models from Practice
## 6 Discussion  
The results show, first of all, how models vary and do not present identical features in identical, expected ways. It would therefore be difficult to rely on the data content and structure of IFC files which is required when developing tools using the models as they are for automatic analysis and processing. This is partly due to the kind of implementation of IFC by modelling software, as it is possible to appreciate common aspects, such as default values or order of entities, in models exported from the same software. However, it also happens because of the many alternatives allowed by the IFC data model to store similar objects and to use the schema for modelling data. A further insight into this shows additional complexity: building models are conceived at a specific moment in the design and construction process and intended for a specific purpose. This can include the handover of information between stakeholders or for coordination. This purpose dictates the kind of information in the model, its level of development, but also the way it is encoded in the model. For example, for coordination, simple explicit geometries are preferred, but for exchange of design constraints more parametric procedural geometries are required. In earlier design stages walls might be schematic boxes, where in higher levels of development walls are decompositions with complex detailing at the joints. The subset of information and preferred encoding is formalized in a Model View Definition, which can be an internationally standardized one, local, or project-specific. For the purpose of this research, there are two problems with this approach. First, the definition of MVDs is not a practice that is actually embedded in day to day construction projects. This makes the actual information content in a model rather implicit. Secondly, these model subsets are actually not formalized enough to the extent that they are computable. Conceptually, given a model constructed according to MVD A and a use case that requires MVD B, one could say one computes the intersection between A and B to see if these two are actually compatible. Or when a federated BIM consists of a model according to MVD C and MVD D one can compute the union between C and D to see how the two discipline models complement each other. Such a formal approach is impeded by: (a) the somewhat weak semantics of mvdXML (the standard used to encode such subsets); (b) the fact that MVDs are easily incompatible due to the wide variety of somewhat equivalent constructs in the schema that MVD authors can select at will; and (c) the fact that in the MVD outline the model subsetting and specification of exchange requirements (a selection of property names for elements types) is interleaved. Considering those impediments and the fact that buildingSMART is transitioning away from mvdXML into a core interoperability layer of the schema with a simpler language for Information Delivery Specification, this research followed a more pragmatic approach. However, the difficulty in mastering such a complex model and managing it within tools is a task for which many designers do not have resources to invest and which, at the moment, is not really attractive to them. It often also lies outside their area of interest because it supports the use of data downstream their own application. It would be therefore necessary to act on the simplification of the IFC model, the additional definition of constraints and on the increase of knowledge and awareness of designers about IFC and the need of producing interoperable (and standard) information, as well as about the advantages this implies. It is important to note that these improvements cannot all be expected to be solved by designers and BIM software vendors alone. First, requirements that are asked to be met by designers in order to yield more consistent IFC files should be reasonable for them to comply to. In addition, software should be ready and capable to meet the requirements more easily than current practice.