# An Inspection of IFC Models from Practice
## 5 Results
### Use of Semantics  
From the analysis of the semantics we can see that few models could be considered 100% consistent, although the information was stored with quite good care in many models. In Figure 4 the scores about consistency of entities, use of _IfcBuildingElementProxy_, storage of _IfcMaterials_ and attributes are shown, according to the criteria explained in the methodology (Section 4.3.1). The numbers showed how very few models (only 3a, 3b, 7b, 8b) presented a sufficient score (higher than 0.6, red line in the graph) for all the aspects. Only those four had the higher chance to be successfully used within automatic processing. Moreover, when looking at Figure 5, we saw that a high percentage of the IFC entities represented in the models presented high consistency, although the wrong use of _IfcBuildingElementProxy_ even for only some objects could prevent a successful use of the model within automated tools. Figure 4: Graph representing the scores assigned to the considered four semantics aspects. The red line indicates the 0.6 score, minimum requirement. In some cases, the entities were generally good, but a few elements presented serious errors, such as storing a slab within _IfcWall_, which would give serious problems to use the model by means of automatic tools and their quality was therefore considered not good. In another case, _IfcBuildingElementPart_ was used to store many elements, which was not incorrect, but the high level of abstraction made the models difficult to automatically interpret for many use cases. The use of materials and attributes was hard to assess, since there are many different ways to store this in IFC: attributes are stored in the entity definition itself; also additional properties are defined within the standards, and a variable number of custom properties and attributes can be added. _IfcMaterial_ only had the attribute \"Name\" to be filled with _IfcLabel_. Therefore, no internationally shared classification was foreseen or recommended by IFC. This flexibility could be good to serve the needs of several users and contexts, but it went at the expense of interoperability for automatic use of such information. In addition, many software tools could fill attributes and materials with default values. Therefore, it was very difficult to assess the reliability of such information, and it was only possible to give an approximated evaluation. For example we saw that _IfcMaterial_ and related entities were filled somehow in most of the inspected models (33 out of 57 models), while they appeared as very inaccurate in 11 out of 57 models. For example, only the general name of the material was present (e.g., \"concrete\") instead of the code of the material or a more extended description, which would make the information more useful. In only two models this information is not present at all. Moreover, in one model, _IfcMaterial_ entities were wrongly used to attach semantics, instead of storing objects by means of the correct entities. Similarly, attributes could only be assessed subjectively based on their number: sometimes many attributes were there to describe entities and sometimes there were not. However, few cases used attributes from the IFC standard and therefore only few were completely consistent with IFC. In many cases, the national languages, and sometimes national codelists, were used to identify and describe entities, especially concerning materials and attributes, but also to name or describe some classes. This is understandable due to efficiency reasons by practice (professionals needing easily understandable representations to support their tasks, which are often still quite manual). However, it is equally apparent how automatic processes from internationally shared tools could be hindered. The use of national language versions of codelists and terms should be improved, supported by tools and promoted among practitioners to use them directly within models and tools.