Several assessment methodologies have been proposed to measure the environmental impact of buildings. However, these methodologies require processing data which is often not available or requires a high integration efort. In this paper, we propose an ontology to describe the use and reuse of prefabricated components in buildings. This ontology describes the relation between the physical object, the building component, with the digital object that represents the element in the building information model. We show that this ontology can be used to answer questions like which building components have been reused and which activities were involved in the life cycle of a building.
The high environmental impact of buildings has led to increasing eforts to improve their
environmental performance [
Ontologies can facilitate the data integration task. In the study case of this paper, we need to integrate data generated by the tracking systems of the building components, the building placements for these components, the history of the components, the material of the components, the logistics required to replace a component, the manufacturing process of the components, and other information required for the environmental assessment associated to these building components. To integrate such diverse data sources, we need to consider the concepts and relations that describe each data source. To avoid reinventing the wheel, existing ontologies can be reused. The integration problem can be then reduced to align existing ontologies, finding relations between concepts and relations that can be defined with diferent levels of generality, and filling the gap for the data that is not covered by the existing ontologies. The experience gained by this research can positively contribute to the development of ontologies for similar and related challenges.
The decentralized development of ontologies has led to the generation of multiple overlapping ontologies. Ontology integration has been investigated for two decades, but it remains a challenging task. In the BIM industry, two distinct initiatives stand out as the principal endeavors in defining ontologies. The first, developed by buildingSMART, is called Industry Foundation Classes (IFC) [10]. The IFC is a schema describing building information, with an EXPRESS entity-relationship data model which consists of several hundred entities organized on an object-based inheritance hierarchy. The second, the Building Topology Ontology (BOT) [11], was developed by the Linked Building Data Community Group (LDB). Unlike the IFC standard, the BOT ontology is developed primarily with Semantic Web technologies and defines a minimal set of classes and relations to describe the core topological concepts of buildings. Hence, the integration of these ontologies requires identifying concept correspondences (e.g., ifc:Wall is a subclass of bot:Element).
Recent research on the reuse of concrete has mostly focused on cast-in-place concrete, through cutting and extraction towards piecewise reuse [12]. Additionally, Jung et al. [13] proposed a conceptual semantic model focusing on robot-assisted deconstruction of cast-inplace concrete buildings. However, their study excludes the deconstruction of other types of concrete structures, such as prefabricated or modular buildings, also excluding the needs of architects and engineers for the reusability assessment or a life cycle perspective through material passports and traceability of components.
In this paper, we study how existing ontologies can be integrated and extended for the reuse of prefabricated concrete components of buildings (eg. walls, slabs, columns, beams, etc), also in consideration of tracking the physical elements and their linking to digital models. To this end, we explore several ontologies that cover domains that should be considered to record the data generated in this use case. These domains include BIM, products, logistics, materials, manufacturing, and sustainability.
Paper structure. This paper is organized as follows. Section 2 provides a general description of the domain for which we will propose an ontology, and presents the competency questions to be considered in the ontology design. Section 3 presents our proposed ontology. Section 4 evaluates our ontology against the competency questions. Section 5 compares our proposed ontology with the related work. Finally, Section 6 concludes this paper.
A prefabricated building component is a physical building block that is first fabricated and then located in a building to perform a function in a building. For example, walls and columns can be fabricated and then moved to specific buildings to perform a function (e.g., separating two spaces or supporting a beam). In some cases, building components are fabricated to perform specific functions for a specific building. In other cases, a component is fabricated without a particular building in mind. The component can then be used either without a modification, or after adapting it to the specific requirements of a building. A building that is deconstructed can be a source of building components that can be used in new buildings or buildings that require maintenance. To know which components can be used in which buildings we need information on building components such as their geometries, materials (e.g., concrete), and physical properties (e.g., it has a load-bearing function only in a vertical position) [6].
The ideal starting point of the reuse process is before deconstruction, such as through a pre-demolition audit, gathering of relevant information, as well as scanning of the existing building, or even through a BIM-supported deconstruction process. The logistics of this process require the identification of building components, visual inspection, making an inventory of elements, tracking movement and location of elements, and finally supporting the reassembly process [9]. As may be expected, these information flows are fragmented, involving diferent stakeholders (designers, demolition companies, construction companies). The identification, also referred to as labeling or tagging of components, is a crucial point in linking physical objects with digital information or their digital model/twin. Identification and tagging would facilitate the logistic handling for reuse, but more generally can support the decision-making steps when designing for reuse and support the circular construction process. Competency questions. We next present the competency questions based on the problem and challenges definition in the introduction section.
Q1 Where was located a prefabricated building component in a given time interval?
Q4 What are all the activities involved concerning the components of a building? The goal of question Q1 is to guarantee that we can retrieve the component locations from the inventory. The goal of question Q2 is to show that we can asses the reuse of components in a building. The goal of question Q3 is to verify that the tracking information is consistent with the inventory data. The goal of question Q4 is to show that the ontology can be used to retrieve all the involved activities and thus asses the environmental impact of them.
Notice that we do not introduce a questions asking for the environmental impacts because the answer to such questions would require to consider details that are beyond the level of generality of the ontology proposed, and it would require considering an specific methodology to assess the environmental impact of a building.
This section describes our proposed ontology. To denote the concepts and roles of our proposal, we use the empty prefix (e.g., :Component), whereas for existing concepts and roles, we use the usual prefixes (e.g., bot:Element). We next describe the concepts and roles of our proposed ontology, and how they relate to existing ontologies. The OWL specification of the proposed ontology is available on [14].
The main concept of our proposed ontology is the prefabricated building component, :Component, and the main goal of the ontology is tracking the use of a :Component. In the inventory, a building component should have a history indicating when and where it was used or stored, and how it was translated, for example, from the fabric to a warehouse, from a warehouse to a building, or from a building to a warehouse.
To represent component changes and the states on the history of a component, we use the classes :Component and :ComponentLocation. To record the changes of the individuals of these classes, we assume that these classes are subclasses of the class prov:Entity from to the PROV-O ontology [15]. Figure 1 depicts an example of the representation of the history of a building component.
As Figure 1 depicts, a :Component can have multiple :ComponentLocations, which are linked by the activities that modify them. An activity is an instance of class prov:Activity which represents, for example, the movement of a component from one building to another building, or from a storage to a building. The predicate :location is used to indicate where a component is during a time interval defined between the time values of the predicates :startedAtTime and :endedAtTime. We assume that the value of property :startedAtTime of the activity that generates a :ComponentLocation is the time when the component was moved to this location. Similarly, the value of property :endedAtTime of the activity that invalidates a :ComponentLocation is the time when the component was moved to another location.
So far, we have described that when a :Component is moved from one place to another the respective :ComponentLocations are associated with diferent :Locations. We envision a class :Location that can be used in a wider variety of locations, like a warehouse, a ship which is moving, or a building where it is used. To describe components that are located on a building we use the BOT ontology [11]. Figure 1 shows how in the inventory of component c1, it was moved from storage1 to be used as a wall1.
Observe that when a component is stored, then its location is a bot:Zone, and when it is used, then the location is a bot:Element. Since these two classes are disjoint, we can distinguish between when a component is stored and when is stored. Figure 2 shows how a bot:Element can be contained in a bot:Zone, and how a bot:Zone is located on a bot:Site. We can use these topological relations to retrieve the information of all components in a given bot:Zone, or in a given bot:Site.
Alternatively, in this example, we could have used a more narrow class like ifc:Wall (and assume that ifc:Wall is a subclass of bot:Element). We did not use narrower classes for the sake of generality.
Various tracking systems use diferent technologies to identify components (e.g., QR codes, active and passive RFID tags, BLE tags). For instance, an operator using an RFID tag reader detects only which RFID tags are around, and associates them to a location of the tagged building component. The operator can introduce this location by selecting it from a menu on the device screen, or the device can automatically introduce the location using GPS. This tracking operation results in a set of records that can include the operator, the location, the time when the record was created, and the component RFID tag. In our ontology, tracking records are instances of the class :TrackingRecord. Figure 3 shows a tracking record r1, and its corresponding properties, which are encoded using the Dublin Core Metadata Terms [16], dct:creator, dct:created, dct:spatial, and dct:subject.
Information from tracking devices are two complementary ways to represent the locations of components, and can be used for diferent purposes. Tracking devices provide raw information that can be captured by operators, whereas inventory information can be either inferred from operational software or introduced manually. These two sources of data involve redundancy and can lead to inconsistencies. In Figure 2 there is no inconsistency because the spatial locations overlap, and the creation of the record is after the positioning of the tag on the component and the positioning of the component on the building.
We evaluate the proposed ontology by showing that we can retrieve the answers to each of the competency questions with a SPARQL query. We assume that these queries are executed over the result of extending the data with facts inferred from the ontology axioms. Q1: Where was located a prefabricated building component in a given time interval? Listing 1 shows a query that answers this competency question. Intuitively, this query finds the states of the component, filtering the component locations associated to a time interval that overlaps the given time interval. When the starting or the ending time of a concept location are missing, this query assumes that the time interval is open. 1 SELECT ?location 2 WHERE { 3 <c> a :Component . 4 ?componentLocation :component <c> . 5 OPTIONAL { ?componentLocation prov:wasGeneratedBy/prov:startedAtTime ?t1 } 6 OPTIONAL { ?componentLocation prov:wasInvalidatedBy/prov::endedAtTime ?t2 } 7 FILTER ( !bound(?t2) | ?t2 >= 2024-02-22 ) 8 FILTER ( !bound(?t1) | ?t1 <= 2024-05-01 ) 9 ?componentLocation :locatedAt ?location . 10 }
Listing 1: Where component c was located between 2024-02-22 and 2024-05-01? Q2 How many reused components are in a building site? The query in Listing 2 answers this competency question by finding the components that have being used as another element.
This also includes components that result from a adapting another used component. 1 SELECT (count(*) AS ?count) 2 WHERE { 3 <s> a bot:Site ; bot:hasZone+/bot:hasElement ?location2 . 4 ?componentLocation2 :component ?component2 ; 5 :locatedAt ?location2 ; 6 prov:wasGeneratedBy/prov:startedAtTime ?t2 . 7 ?componentLocation1 :component ?component1 ; 8 :locatedAt ?location1 ; 9 prov:wasInvalidatedBy/prov:endedAtTime ?t1 . 10 ?component2 (prov:wasGeneratedBy/^prov:wasInvalidatedBy)* ?component1 . 11 FILTER ( ?t2 > ?t1 ) 12 } 13 GROUP BY ?component2
Q3 Do the tracking data agrees with the inventory data? This question is challenging because it requires to identify when two locations overlap. If the geometric representation of the locations (e.g., zones or elements) is provided, then we could use the geographic extension for SPARQL, GeoSPARQL. In the query in Listing 3, we assume that the tracking data is consistent with the inventory data when either both locations are the same, or one contains the other.
Listing 3: Are tracking records where the location of the component does not match the information from the inventory? Q4 What are all the activities involved in the components of building? The query in Listing 4 answers this competency question by finding the activities involved with the components used by the building elements. 1 SELECT ?activity 2 WHERE { 3 <s> a bot:Site ; bot:hasZone+/bot:hasElement ?location . 4 ?componentLocation :component ?component ; 5 :locatedAt ?location ; 6 prov:wasGeneratedBy ?activity . 7 }
BIM Ontologies. The Industry Foundation Classes (IFC) is an open, international standard (ISO 16739-1:2018) data schema for the Architecture Engineering and Construction (AEC) industry. This data schema provides an extensive set of concepts and properties that can describe RDF resources with the ifcOWL ontology [10]. Although, this ontology introduces many concepts to describe builds and their life cycle, it does not provide the concepts needed to address the problem described in this paper.
The Building Topology Ontology (BOT) is a core ontology developed by the W3C Linked Building Data Group to facilitate interoperability and data integration for the AEC industry [11]. It provides a high-level description of the topology of buildings, including stories, spaces, building elements, and their 3D models. However, the bot ontology provides a concept to describe the digital elements of a building (e.g., bot:Element) but not the physical components that instantiate them. Our ontology provides this physical counterpart via the class :Component.
Brick schema: defines an ontology for sensors, subsystems, and their relationships, enabling portable applications. The ontology captures the relationships between entities in a building, such as location, equipment connections, equipment composition, point connections, and monitoring [17]. However, does not cover the description of prefabricated components.
The Building and Habitats object Model ontology (bhOWL) is an ontology generated automatically from objects of multiple AEC software tools [18]. However, it does not define concepts for the tracking of prefabricated building components.
Product Ontologies. The Product Life Cycle (PLC) ontologies is a suite of modular ontologies developed for the manufacturing industry to represent the various phases of the product life cycle, from design to end of life [19]. This suite extends from the Common Core Ontologies (CCO) and the Basic Formal Ontology (BFO). The PLC ontologies do not provide specific properties to describe the usage of products in buildings. However, by aligning the PLC ontologies with our ontology, by assuming a :Component is a product, we can bring all concepts that can be used to assess the environmental impact of products to the AEC industry.
Logistic Ontologies. There are multiple ontologies to describe logistics [20, 21, 22]. No one of these ontologies can describe the use of prefabricated components in building. However, to assess the ecological impact of buildings, these ontologies could be integrated with ours. Material Ontologies. The Web Ontology for Design-Oriented Material Selection is designed to formalize knowledge about material properties, material processing [23]. Atta et al. [24] introduce a framework for handling material passports, which covers various materials, including building components like doors, flooring, and structures, as well as concepts such as deconstructability, recovery, and environmental scores. These material ontology does not address the problem our ontology addressed, but can be integrated with ours to facilitate the logistics of component reuse (for example, building elements can require components with some specific materials), and the assessment of the environmental impact (e.g., diferent materials have diferent fabrication processes).
Sustainability Ontologies. Regarding the sustainability, the ontology includes concepts related to environmental management and life cycle assessment, aligning with industry standards such as ISO14040:2006 and ISO18629–1:2004. The ONTO-PDM is a product-centric ontology that describes products, processes, and resources, and associates them with functions and sustainable manufacturing knowledge [25]. These ontologies do not include specific information for building components, but can be integrated with our ontology to facilitate the assessment of the environmental impact of buildings.
In this paper, we presented an ontology for the reuse of prefabricated building components which addresses four competency questions related to the possibility to know where is a prefabricated building component, which elements of a building have been reused, and which activities are involved in the building components. We showed that the ontology can be used to answer these competency questions. However, the queries we used in this evaluation seem complex and error-prone. A future work is to add axioms to the ontology that can be automatically be used to extend the data with inferred relations that simplify these queries.
While the proposed ontology covers concepts for the reuse of prefabricated building components, it can be extended and aligned with existing ontologies mentioned in section 5, such as the BIM, product, logistics, material, or sustainability ontologies.
The proposed ontology does not describe the data needed to assess the environmental impact of a building, but provides concepts that allow to access the activities that can have an environmental impact. By integrating this ontology with ontologies that can encode such information, we will be able to query the data to assess the environmental building impact. A future work is thus this integration, and the use of the ontology to assess the impact of a real project. This integration with other ontologies is not a minor task due to the diversity and multiplicity of these ontologies.
This work was partially funded by the European Union’s Horizon 2020 research and innovation program, GA 958200 (ReCreate project); the Deutsche Forschungsgemeinschaft (DFG): Germany’s Excellence Strategy – EXC 2120/1, GA 390831618 (RP20); and the DFG: SPP 1921, GA 318363223 (COFFEE project STA 572_15-2). [5] A. Dervishaj, K. Gudmundsson, From lca to circular design: A comparative study of digital tools for the built environment, Resources, Conservation and Recycling 200 (2024) 107291. doi:10.1016/j.resconrec.2023.107291. [6] A. Dervishaj, A. Fonsati, J. Hernández Vargas, K. Gudmundsson, Modelling precast concrete for a circular economy in the built environment: Level of information need guidelines for digital design and collaboration, in: eCAADe 2023: Digital Design Reconsidered, Proceedings of the 41st eCAADe conference, 20-22 September 2023, Graz University of Technology Graz, Austria. Education and research in Computer Aided Architectural Design in Europe, and Graz, volume 2 of eCAADe proceedings, 2023, pp. 177–186. doi:10.52842/ conf.ecaade.2023.2.177. [7] A. Dervishaj, From sustainability to regeneration: a digital framework with bim and computational design methods, Architecture, Structures and Construction 3 (2023) 315– 336. doi:10.1007/s44150-023-00094-9. [8] S. Banihashemi, S. Meskin, M. Sheikhkhoshkar, S. R. Mohandes, A. Hajirasouli, K. LeNguyen, Circular economy in construction: The digital transformation perspective, Cleaner Engineering and Technology 18 (2024) 100715. doi:10.1016/j.clet.2023. 100715. [9] A. Dervishaj, J. Hernández Vargas, K. Gudmundsson, Enabling reuse of prefabricated concrete components through multiple tracking technologies and digital twins, in: 2023 European Conference on Computing in Construction and the 40th International CIB W78 Conference, European Council for Computing in Construction, 2023, pp. 1–8. doi:10. 35490/EC3.2023.220. [10] P. Pauwels, W. Terkaj, Express to owl for construction industry: Towards a recommendable and usable ifcowl ontology, Automation in Construction 63 (2016) 100–133. doi:https: //doi.org/10.1016/j.autcon.2015.12.003. [11] M. H. Rasmussen, M. Lefrançois, G. Schneider, P. Pauwels, Bot: the building topology ontology of the w3c linked building data group, Semantic Web (2020). doi:10.3233/ SW-200385. [12] C. Küpfer, M. Bastien-Masse, C. Fivet, Reuse of concrete components in new construction projects: Critical review of 77 circular precedents, Journal of Cleaner Production 383 (2023) 135235. doi:10.1016/j.jclepro.2022.135235. [13] V. Jung, C. Heuer, S. Brell-Cokcan, A first approach to a semantic process model for enabling an information flow for reuse of building materials, in: Construction Logistics, Equipment, and Robotics, Springer Nature Switzerland, Cham, 2024, pp. 23–32. [14] D. Elshani, A. Dervishaj, D. Hernandez, K. Gudmundsson, S. Staab, T. Wortmann, RTBC: Reuse and Tracking of Building Components Ontology, 2024. doi:10.18419/ darus-4098. [15] T. Lebo, S. Sahoo, D. McGuinness, K. Belhajjame, J. Cheney, D. Corsar, D. Garijo, S. SoilandReyes, S. Zednik, J. Zhao, PROV-O: The PROV Ontology, 2013. URL: https://www.w3.org/ TR/prov-o/, W3C Recommendation. [16] D. U. Board, DCMI Metadata Terms, 2020. URL: http://dublincore.org/specifications/ dublin-core/dcmi-terms/2020-01-20/, DCMI Recommendation. [17] B. Balaji, A. Bhattacharya, G. Fierro, J. Gao, J. Gluck, D. Hong, A. Johansen, J. Koh, J. Ploennigs, Y. Agarwal, M. Bergés, D. Culler, R. K. Gupta, M. B. Kjaergaard, M. Srivastava,