The construction industry is a collaborative environment with the involvement of multiple disciplines and activities throughout the Building Lifecycle Stages. The collaboration requires the iterative and coordinated exchange of information for significant improvement of the building design, construction and management. The successful representation of these information refinements enables the identification of the required level of detail (LOD) for data sharing parameters between the multiple disciplines. Since the last decade, LOD is a promising approach for efficient representation of semantically rich BIM data in different levels. Despite the improvement, there is a lack of efficient implementation in building lifecycle functionalities, because of their fundamental heterogeneity, versatility and adaptability. The proposed approach enables the representation of LOD-sensitive BIM data through the formal definition of ontologies. The paper validates this approach based on the concept of competency questions and their respective SPARQL queries. With the demonstration and validation, the paper provides the conceptual proof for the practical application of the developed approach. The proposed solution can also be easily adaptable and applicable to the present BIM process since the representation of BIM data in different ontologies (BOT, ifcOWL, etc.) are within reach.
The Architecture, Engineering, Construction, and Operation (AECO) industry is a
collaborative environment and requires the iterative and cooperated exchange of
information between multiple disciplines at different stages of the building lifecycle
process. The collaboration enables the efficient and economical design of the building
and its management [
Building Information Modelling (BIM) is an emerging approach in the
construction industry to describe and digitally represent information [
There are different standards of publications to represent the building object’s
geometry and attribute information in different LOD levels. The publications from USA
UK, Italy, Netherlands, Denmark, etc. are introduced similar concepts for LOD in
terms of Level of Development, Level of Detail, Level of Geometry, Level of
Information, Level of Completeness, Level of Reliability, etc. It is true that no such LOD
levels define a set of pre-requirements about the data within the level but provide a
language to define these requirements based on the project, location and organization.
However, despite the improvements, there is a lack of successful implementation and
management of LOD functionalities within the existing BIM solutions [
Moreover, the uncertainty in the defined data requirements for each LOD level
may also severely affect the collaboration in AECO projects. The versatility of data
requirements needed for a specific process is also not allowed to specify a specific
LOD level for a BIM model. Although different LOD systems are available for
required data representation, these complexities brought a need in the AECO industry to
define a solution that provides common model deliveries [
The development of the LOD framework is majorly based on the linked data and
ontology concepts, which brings flexibility, compliance and alignment capabilities
through logical reasoning and knowledge inferencing. Furthermore, the structured
representation of building data in ontologies (triples or graphs) enables the
stakeholders to semantically interpret (update, extract or delete data using queries) data for
various domain-specific operations with minimal human interventions [
The LOD levels of BIM data should be generally defined for different stages of projects when data sharing takes place. This is a pragmatic approach to indicate the granularity of the BIM data and data refinements throughout the project progression over multiple stages of the building. Furthermore, this would allow stakeholders to verify that project information in detailed enough to meet their requirements, and enabling them to decide whether to proceed to the next project stages or not.
Different countries have developed dedicated LOD standards generating a complex
situation at an international level (Table 1). The abbreviation “LOD” is used in
various meanings in different countries, such as the USA - BIMForum Specification [
According to the UK standards, LOD has the general meaning of Level of Definition, which includes the two distinct parts of the Level of Detail and Level of Information. The level of detail represents the description of the graphic contents at each stage, while the level of information represents the description of non-geometric contents. Simultaneously, the Italian norm UNI 11337:2017 defines the LOD as the Level of Development of the objects and is further divided into LOG, Level of development of objects – Geometric Attributes, and LOI, Level of development of the object – Informational Attributes. 2.2
In the area of information management, the support for LODs centres around the challenge to represent (1) various LOD systems, (2) multiple versions of information about the same objects and (3) the connections of LOD-specific data to processes over the building lifecycle. A proper representation not only allows the users to access and work inside one specific LOD but enable various cross-LOD functions: to access the history of values, to utilize the links, annotations, and other enrichments of previous LOD objects with those in subsequent LODs, to check the consistency and possible deviations between objects at different LODs, and to determine what kinds of adjustments to previous LOD models would be needed. Moreover, it helps to connect LODs to other aspects of building information: to keep track of the origin of information and to maintain the rules for validating it against the requirements of subsequent activities. This analysis of LOD requirements suggests at least the following areas where ontology definitions are needed to properly support LODs. For more clear applicability and understanding a set of Competency Questions (CQ) are defined based on the requirements for each area. 1. LOD frameworks: The representation of various levels, their relations, and the links to associated definitions.
i. CQ1 - What is the relation between the LOD sub-type to the LOD scale? ii. CQ2 – How do LOD levels (LOD scale) are related to each other? iii. CQ3 - How do LOD scales are defined based on the LOD system? 2. LOD sensitive BIM data: The representation of versioned properties of objects to capture the data at multiple different levels in an organized manner.
i. CQ4 - What is the value for the object properties in previous levels? 3. Connection of LOD framework to processes: The representation of LOD-specific data by activities along with the sources.
i. CQ5 - From which source the value of “Wall width” is extracted? ii. CQ6 - What level of properties are required for a specific activity? 3 3.1
The development of an ontology framework for LOD representation is progressed towards providing all the answers for the above-identified requirements. From the general analysis of different LOD systems, a methodological ontology schema is developed and illustrated in Fig. 1. Since different construction projects can adopt different LOD systems, the developed ontological structure for the LOD framework can accommodate the different standards of representations detailed in Table 1. The methodological idea is to represent LOD systems and their levels as classes, which can then be instantiated on a project-to-project basis. The class dicl1:LODFramework can be instantiated with the frameworks called USA BIMForum, UK LOD, Italian LOD, etc. (refer to Table 1). Similarly, the levels in different frameworks are added as instances to the class dicl:LODLevel. Later on, the link between the framework and its respective levels are generated using the object property dicl:hasLevel and its inverse property dicl:isLevelOf. Furthermore, relationships between the levels of a framework are indicated using the transitive object properties dicl:hasNextLevel, dicl:hasSubLevel and their inverse properties dicl:hasPreviousLevel, dicl:hasSuperLevel respectively. A sub-property chain axiom is assigned to the object properties dicl:hasLevel to define semantic interpretation between the LOD levels and LOD subtypes. An exemplary demonstration is presented in the below subsection to elaborate on the functionalities of the developed ontology framework. 3.2
For the demonstration, the BIMForum LOD framework (see in Table 1) is considered and align to the developed ontological schema. As represented in Fig. 2, the instances inst:AsDesigned and inst:AsBuilt are assigned as levels for the instance inst:USA_BIMForum using dicl:hasLevel object property. Since this object property’s (dicl:hasLevel) domain and range are fixed to the classes dicl:LODFramework and dicl:LODLevel respectively, the inferencing engine automatically inference the new knowledge by saying the instance inst:USA_BIMForum belongs to the class dicl:LODFramework and the other instances are belonging to the class dicl:LODLevel. This inferenced knowledge is illustrated in Fig. 2 and Fig. 3 using the grey dashed lines and the defined relationships are represented with solid black lines.
Similarly, the same representational concepts can also be used for the remaining LOD systems mentioned in Table 1. Moreover, the relationship between the instances inst:AsDesigned and inst:AsBuilt is assigned using dicl:hasNextLevel transitive object property. As defined in the ontology framework, the dicl:hasNextLevel object property has assigned an inverse relationship with dicl:hasPreviousLevel. Which substantially generates the new knowledge between these instances concerning the previous stage relationship. The inferenced knowledge from the inverse relationships is represented by using yellow dashed lines in Fig. 2 and Fig. 3. Furthermore, the LOD scale information (LOD levels) regarding each LOD subtype is defined by using dicl:hasSubLevel transverse object property and its inverse property dicl:hasSuperLevel. Because of the transverse property nature of these object properties, any further sub-levels of a LOD scale is also considered as a LOD level. Similarly, due to the defined axiom to dicl:hasLevel property, all these LOD scales are inferred as Levels to the dicl:LODFramework (inst:USA_BIMForum). Also, the relationship between the LOD levels is developed by using dicl:hasNextLevel object property. Along with this defined information, a new relationships are generated between LOD levels, for example, between inst:LOD350 and inst:LOD500, which is clearly represented with blue dashed lines in Fig. 3. These generated relationships are because of the transitive property characteristic of the object properties dicl:hasNextstage and dicl:hasPreviousStage. 4 4.1
The representation of BIM data in a LOD-sensitive manner is based on the ideology that (1) Identifiers of objects are not LOD sensitive, but (2) All properties of objects can be LOD sensitive. That means, objects are not associated with a specific LOD level but their property values can be. It is not possible to ask which LOD an object belongs to because the object can simultaneously have properties belonging to many different LODs. The developed ontological schema in Fig. 4 express the same ideology and establish relationships between BIM object data and its respective LOD levels. In the developed ontology framework, a class dice2:BuildingObject represents the building elements. Similarly, the class dicv3:Property in the ontology framework make it possible to add an ultimate number of properties to building objects using the object property dicv:hasProperty. Also, the class dicv:PropertyState is defined to indicate the growth of these properties accuracy throughout the project life-cycle. The framework also supports defining meta-data attributes for each object (e.g. label and ID), property (e.g. label, value, unit, and source) and property state (e.g. label, source, timestamp, value, etc.). The class dicl:LODlevel is connected to dicv:PropertyState to indicate its level of growth by representing a specific LOD level. The object property dicl:hasLODLevel is used to develop this relationship between dicv:ProperyState and dicl:LODLevel. A sample BIM data representation is illustrated in Fig. 5 according to the developed ontology framework. LOD data by activities. The connections of LODs to processes happen through the information objects created in activities and/or their requirement to execute activities. Different activities require different object properties at a specific level of detail. In this ontological framework, an explicit mapping methodology is specified to represent these requirements. The framework enumerates the information interms of (1) Object type (e.g. wall, slab, etc.), (2) Property name (e.g. a single property or grouping of properties), (3) Nature of data needed (e.g. a LOD level or other specification) for each activity. Based on the adopted methodology, the class dice:BuildingObject is further interrelated to the Activities (dicp4:Activity) in the project using the object property dicl:hasObject. As illustrated in Fig. 4, the adopted ontology framework is
completely fulfilling these connection requirements between LOD levels and the activities within the project.
Sources of LOD data. The possible sources of LOD data are different kinds of information objects. These are primarily BIM models but can also include drawings, documents, messages and events/notifications. In some cases also the information contained in various information management systems can be relevant. Each information object – explicitly or implicitly – provides information at certain LOD levels, and therefore the data should primarily be converted in a LOD sensitive manner. According to the developed framework, the sources of information can represent by using the class dici5:InformationContainer. The connection of each property in the LOD sensitive representation to the source of data can be attained with an object property dicl:isDerivedFrom (Fig. 4). 5
The validation of the developed framework is performed by running the SPARQL queries based on the competency questions listed and used for the framework development. As represented in Fig. 2 and Fig. 3, the information related to instances and relations (solid black lines) is developed to the main default framework ontology. Similarly, an example BIM data (in Fig. 5) is populated to the developed framework to verify the BIM data management process using LOD’s. After the population of instances, a reasoner called Pellet has used to inference the new knowledge and to check the consistency, correctness of the developed ontology. Thereafter performed several queries to extract the generated information to check the consistency and quality by comparing it with the original information from the standards (see Table 1). Some of the developed query profiles and their results are presented in Table 2.
Query 3:- What is the relationship between the USA LOD system and LOD Scale?
Where{ USA_BIMForum dicl:hasLevel LOD200 ?System dicl:hasLevel ?Sub_type. USA_BIMForum dicl:hasLevel LOD300 ??SSuysbt_etmyp?eredaicltli:ohnasshSiupb?LSecvaelle?.Scale . USA_BIMForum dicl:hasLevel LOD350 FILTER(?System=:USA_BIMForum)} USA_BIMForum dicl:hasLevel LOD400
USA_BIMForum dicl:hasLevel LOD500 Query 4:- What is the value of “Wall width” in different LOD levels? SELECT ?Wall ?Width ?Level Wall Width Where{ ?Object dice:hasLabel ?Wall. ?Object BasicWall:500+.. 352 dicv:hasProperty/dicv:hasPropertyState ?PS. ?PS dicv:hasValue ?Width . BasicWall:500+.. 348 ?PS dicl:hasLODLevel ?Level .}
Level LOD300 LOD350 6
The paper explains the developed ontological framework for the effective representation of various LOD systems and their corresponding levels through the demonstration example. The development process is carried out based on the analysed requirements (CQ), which should be fulfilled by a LOD framework. With the defined and inherited knowledge capabilities of the developed ontology framework represents its applicability and functionalities in terms of representing the BIM data in different LOD levels. The ontological representation of the LOD systems brings flexibility, compliance and alignment capabilities through logical reasoning and knowledge inferencing. The paper also explains the framework capabilities corresponding to the BIM data management in terms of LOD sensitive data representation and its connection to processes. The developed ontological framework is also easily adaptable and applicable to the present BIM process since the representation of BIM data in different ontologies (BOT, ifcOWL, etc.) are within reach. Finally, the validation and evaluation of the developed LOD framework are performed based on the SPARQL queries, which represents the framework requirements.
As represented in the paper, the developed methodological framework is only addressing the attribute information about the object but not the geometrical information. The further possible extension of the methodology is corresponding to the representation and management of building object’s geometrical data. The research in this paper is limited to the representation of LOD-sensitive BIM data. The future focus of this research is on the validation of existing BIM data in the context of different LOD levels using SHACL constraints.
This research is part of the EU project entitled “BIM4EEB – BIM-based fast toolkit for the Efficient rEnovation in Buildings” which has received funding from European Union’s H2020 research and innovation program under grant agreement No 820660. The authors gratefully acknowledge the support and funding from the European Union. The content of this publication reflects the author view only and the Commission is not responsible for any use that may be made of the information it contains. 8