Introduction

Navigating the complexities of exchanging project management information of construction projects presents several challenges that impede seamless collaboration and hinder the full potential of automation. Presently, schedule exchange is mainly based on XML or spreadsheet-based files. These files result from export functionalities of project management software tools. However, this translation process from proprietary data formats to open formats often leads to loss and misinterpretation of the exchanged information [1,2]. One significant challenge arises from the diverse scheduling practices adopted by different construction companies. Each company applies its unique scheduling methodologies, leading to a lack of standardization across the industry. This diversity is fueled by a multitude of factors, including software preferences, organizational structures, project-specific considerations, varying levels of detail, used language, and the use of company-specific naming conventions [3,4]. Consequently, the absence of an established standard for schedule exchange limits the potential for automation in the Architecture, Engineering, Construction, and Operation (AECO) industry.

While there are existing data schemata designed for schedule description, such as Industry Foundation Classes (IFC), Digital Construction Ontologies (DiCon), Digital Twin Construction Ontology (DTC), Construction Tasks Ontology (CTO), and Internet of Construction Ontology (IOC), they exhibit limitations that hinder their effectiveness [5,6,7,8,9]. Notably, these schemata lack the representation of detailed process dependencies and struggle with hierarchical structures suitable for automated interpretation. To address these shortcomings, there is a pressing need for explicitly representing semantic information about process decomposition criteria. This additional layer of information is crucial for comprehending the intricate hierarchical structures inherent in construction processes.

To fill this gap, the present paper will introduce a minimal ontology for representing processes of construction schedules. A case study is presented that uses the new process representation for automated schedule interpretation and the linking with a corresponding IFC model to demonstrate the ontology's suitability and usefulness. This is only one of many possible applications for the ontology. Another advantage of using the ontology is that it facilitates coordination between contractors and subcontractors through structured schedule exchange. Due to the enhanced semantic information, the schedule can be interpreted automatically, reducing the need for extensive manual efforts, streamlining digital processes and improving the overall efficiency. Also, the semantic information about the processes can be used to check the schedule for consistency and completeness.

This research is structured as follows. Section 2 provides background information and elaborates on the identified research gap by introducing existing process-related schemata. Subsequently, in Section 3, the developed process ontology covering process dependencies and decomposition criteria is introduced. One possible application of the ontology is demonstrated in the case study in Section 4. The paper closes with a discussion and conclusion in Sections 5 and 6.

Background and state-of-the-art

Work breakdown structures

Planning complex construction projects involves addressing challenges such as long project duration, a multitude of stakeholders, and the unique nature of each project [10]. To navigate these complexities, professionals commonly employ Work Breakdown Structures (WBSs) to systematically deconstruct a construction project into smaller, more manageable pieces. The foundational high-level work packages, which form the core of the WBS, encompass all project-related tasks and are progressively dissected into finer-grained packages. Each decomposition must ensure comprehensive coverage of the parent task to maintain a holistic project perspective. WBSs typically adopt a product-oriented approach, allowing for distinct decomposition levels tailored to different project components. The optimal level of detail is achieved when further granularity cannot improve aspects like cost estimation accuracy or projected execution timelines. This occurs when the level of detail surpasses the scope of possible uncertainties [11,12].

The WBS often reflects the organizational structure of the construction company. It should always be ensured that every work package can be assigned to a single responsible person. An essential principle here is to avoid consolidating tasks executed by multiple parties into a single work package, fostering unambiguous responsibility allocation. In this way, the WBS is influenced by the part of the subcontracted work and the company's hierarchical structure. Additionally, the WBS forms the basis for other breakdown structures, including resource, cost, and product breakdown structures, providing a comprehensive foundation for project management [13,14,15].

The WBS is an essential starting point for creating the construction schedule [11]. Here, the decomposition criteria are relevant to understanding the meaning of the resulting subtasks. Figure 1 provides an example of a WBS with explicit definition of the applied decomposition criteria. Being able to interpret the semantic meaning of the WBS will also significantly help interpret the derived construction schedule since it follows the same hierarchical structure.

Classification systems in construction

To gain a comprehensive understanding of potential decomposition criteria, existing classification systems within the construction field offer an extensive overview of construction-related concepts. They divide construction concepts into different categories to create a common structure and comparability across projects. There are many nationally and internationally applied classification systems which are similar but yet different from each other. Some national classifications are, e.g., MasterFormat, Uniformat, OmniClass, and CoClass, while ISO 12006-2 and ISO 81346-12 are international examples [12]. Looking only at the topmost classification level, ISO 12006-2 for example is divided into twelve categories: construction information, construction products, construction agents, construction aids, management, construction process, construction complexes, construction entities, built spaces, construction elements, work results, and construction properties [16]. While these classification systems are commonly used for creating Cost Breakdown Structures (CBSs), they can also be applied for WBSs since, in many cases, it does not make a conceptual difference if a construction project is decomposed into cost or process-related items. As an example, a work package could be divided into subtasks by differentiating between different construction elements according to ISO 12006-2. While the range of subtasks that can be created with a single decomposition may seem limited, a sequence of divisions as present in a WBS allows representing a wide range of processes, chaining the breakdown into gradually increasing detail. An overview of several classification systems compiled by Cerezo-Narváez et al. [12] is given Table 1. It takes ISO 12006-2 as the starting point and compares its categories with categories from other classification systems.

State-of-the-art data schemata

Several existing data schemata allow for representing construction processes. Some of them are introduced and discussed here to present their suitability for schedule exchange and automated schedule interpretation.

The Industry Foundation Classes (IFC), maintained by buildingSMART International [5], are an internationally recognised standard for the storage and exchange of construction-related data. Encompassing diverse concepts across all stages of a building's life cycle, it is renowned for its extensive list of geometric representations, such as boundary representations and procedural descriptions. Despite its emphasis on spatial and structural elements in building design, IFC also addresses semantic aspects and incorporates processes-related classes.

Construction processes can be represented with the class IfcTask. To form hierarchical structures of processes which are relevant for describing a complete construction schedule, IfcTasks can be nested infinitely. Moreover, process dependencies can be described through IfcRelSequence, which defines several types of sequence types like start-to-start and end-to-start. An example of using these entities in combination is shown in Figure 2. Finally, the internal sequence of a task can be described by using IfcProcedure and IfcEvent [5]. Since they do not allow for specifying concrete time intervals, their usefulness in the context of construction schedules is very limited. Several aspects hinder the use of IFC as a means to schedule exchange and automated interpretation. The Model View Definition (MVD) concept is supposed to reduce the number of entities to be supported by the implementing software vendor according to a well-defined use case. However, MVDs do not yet exist for pure process models or combined BIM-process models (4D models). This creates a large overhead for an implementer who aims only at the process-related entities [17]. Furthermore, the process part of IFC is barely supported by existing software tools. While BIM authoring tools that support IFC are fully focused on the building structure, dedicated project management software is used for scheduling-related tasks, which do not support IFC. Lastly, the use of IfcTask makes an automated interpretation of processes very difficult since high-level processes like the complete frame erection phase and a very detailed process like pouring concrete for a specific column are all represented in the same way [5]. Additional information is required to convey the meaning of a particular process, which cannot be adequately represented in IFC.

The Digital Construction Ontologies (DiCon) are a set of interrelated ontologies developed by Zheng et al. [6]. They are covering the management and execution aspects of construction projects. DiCon describes construction processes from a flow perspective. All processes can be assigned with several input or output flows. This covers, e.g. the required input material or equipment and the results like building elements that emerge from the conversion process. Similar to IFC, DiCon also defines only a single type of process, which is called activity. However, the relationship dice:hasSubActivity can be used to define process hierarchies (see Figure 3). This relationship is the parent relationship of three additional relationships: hasLocationPhase, hasObjectPhase, and hasProcessPhase. It allows differentiating between location, object, or process step-specific sub-activities [6]. While this allows for the definition of additional semantics related to the work breakdown structure, it does not provide a complete list of possible decomposition criteria. For example, the decomposition of indoor works by trade, like plumbing and painting, cannot be represented with DiCon. Moreover, DiCon is missing different types of process dependencies, like start-to-start and end-to-start. The activity class inherits from the occurrent class of the Basic Formal Ontology (BFO), which only allows defining processes predecessors without specifying additional information. These dependencies are an essential aspect of construction schedules; e.g., they are clearly defined in conventional Gantt charts. The Construction Tasks Ontology (CTO) has similar limitations. CTO is a minimal ontology that describes various construction tasks, including installation, modification, removal, inspection, and reparation. These tasks are linked to their target entity through the relationship cto:isSubjectOfTask. While the ontology was mainly designed for the maintenance of historical buildings, it is still applicable to other construction-related scenarios. Like DiCon, however, CTO can only define task successors with the relationship cto:afterFinishedTask, which does not consider different types of process sequences [9].

The Digital Twin Construction Ontology (DTC) is an ontology developed in the frame of the EU Horizon 2020 project BIM2TWIN1 . It focuses on describing a digital twin of the construction phase. The representation of process dependencies is handled similarly to IFC with the so-called ProcessPrecondition. All four types of sequences are defined as individuals of this class. Regarding the representation of decomposition criteria, three different types of processes are defined. These are WorkPackage, Activity, and Task (see Figure 4). They resemble the decomposition by production method, construction step and building element and must be applied in this specific order [8]. While many schedules can be converted to this structure, it limits its flexibility and may struggle to represent some types of schedules. For example, a schedule can contain more than three hierarchical levels. To represent such a schedule, the most abstract levels would not be represented explicitly anymore. Another example would be a schedule that applies the process decomposition in a different order, which again creates additional effort in adapting the schedule to the structure defined by the ontology. Finally, the Internet of Construction Process Ontology (IOC) is a recent and still ongoing development.

It is dedicated to the definition of construction processes with a wide range of involved objects and persons. Furthermore, it defines various types of process states [7]. Like IFC, it also lacks a definition of the decomposition criteria of processes and detailed process dependencies.

All of the introduced schemata for process description are ontologies that can be used in the context of the Semantic Web, initiated by Berners-Lee et al. [18]. While IFC is primarily specified by means of the STEP schema language EXPRESS, Beetz et al. [19] created a Resource Description Framework (RDF)compliant version called ifcOWL. Ontologies have the advantage that they can be flexibly combined to create a more complex and complete data schema for a given use case. Furthermore, developers can use a wide range of freely available RDF tools for validation, querying, analysis and many other purposes. Moreover, ontologies can be easily combined with other existing ontologies. This allows focusing on small, concise ontologies that can reuse other ontologies for more complex use cases [20]. This is why the Semantic Web approach was chosen to tackle the semantic description and exchange of construction processes.

Advanced schedule representation

Based on the research gap presented in Section 2.3, an ontology for the representation of construction schedules was developed. Particular focus is dedicated to different types of process decomposition criteria that are commonly used. For this, the process hierarchies of schedules of various construction projects are analysed. While in this paper, a new ontology for schedule representation is proposed, an alternative option would be to integrate the newly defined classes for process preconditions and decomposition into existing ontologies. Considering the FAIR data-sharing principles, integration into existing ontologies is favoured [21]. However, it is not clear if some required changes to existing ontologies align with the creators' intentions. For this reason, a new ontology is presented here with the intention of future integration.

It is important to note that in the frame of this paper, only processes related to the construction execution are considered. The schedule of the planning phase is out of scope.

Process decomposition criteria

Process decomposition criteria play a crucial role in understanding the process hierarchy and dependencies between processes. They describe how the parent process is divided into smaller parts and give insights into the relationship between the different child processes. For example, a division of a process by storey creates a spatial dependency of the processes and, therefore, might also imply an order in which the child processes need to be executed. For this reason, explicitly describing these decomposition criteria provides knowledge essential for automated interpretation of the process meaning.

First, construction schedules of eight finished or ongoing construction projects were analyzed regarding the hierarchical structure of the processes and the used decomposition criteria. These sites were pilot sites of the EU Horizon 2020 project BIM2TWIN or active projects of the members of Innovations Management Bau GmbH, an industry partner of the authors. Five different construction companies in four countries (Germany, Spain, Finland, and France) are covered. For all of them, a schedule was available in PDF or Excel format, created by the export functionalities of the scheduling software used by the construction company.

All construction processes in the schedules that were divided into sub-processes were manually analyzed regarding the applied criteria for decomposition. The criteria were sorted according to the classification categories presented in Table 1. On the one hand side, some of these categories, like CAD and Information, do not make sense as a process decomposition criterion considering only the construction processes and not the planning phase and were therefore never used in any schedule. On the other hand side, the processes category was divided into production methods and construction steps for more detailed differentiation. In total, nine decomposition criteria were used in the analyzed schedules. Table 2 gives a complete list with examples for every criterion and the percentage of schedules in which this criterion was used. While eight construction schedules are insufficient to provide a comprehensive list of all criteria for decomposing processes into sub-processes, the authors are confident that the most common ones are covered since the high-level categories of construction classification systems were taken as guidance. All categories identified as meaningful in the context of process decomposition were encountered in at least one of the available schedules. While many process decompositions can clearly be assigned to a single criterion, some are fitting more than one criterion. As an example, dividing the process that summarizes the indoor works into separate sub-processes, e.g., plumbing, electrical work, painting, and so on, can be seen as a sequence of construction steps or a division of the indoor works by discipline. This depends on the primary intention of the scheduler. While there is no correct and incorrect option, the focus of the decomposition is slightly shifted, in the given example, to the worker crews belonging to different domains or to the general sequence in which the processes need to be performed.

Construction Scheduling Ontology

A new ontology for process representation was developed based on the identified shortcomings of existing process schemata. This Construction Scheduling Ontology is a minimal ontology that describes construction processes with their hierarchical structure, process dependencies, and related concepts. First, a UML diagram of the schema was developed, which was manually converted into an OWL ontology using Protégé [22]. The UML diagram of the Construction Scheduling Ontology (CSO) is shown in Figure 5. The primary element of the ontology is the process class. Every construction schedule is seen as a list of processes containing basic information like start and end time. The class process decomposition is used to describe the hierarchical structure of processes. This is modelled as a separate class to be able to attach additional information like the criterion for process decomposition. The relationship hasParentProcess and hasChildProcess connect the process decomposition with parent processes and its sub-processes. The decomposition criterion class is used to define the criterion which is used for the decomposition. The ontology defines nine individuals for this class: phase, production method, construction step, location, element, discipline, equipment, material, and property. In this context, the individuals can be understood as an enumeration for the decomposition criterion class. The nine classes correspond with the criteria presented in Table 2. However, these individuals are not represented in the UML in Figure 5. Since it is not allowed to point an object property to a class or a datatype property (source), the name property of the decomposition criterion is used to specify which exact class or property is used to divide a process into several subprocesses. As an example, building elements can be grouped according to their subclass of bot:Element, creating separate processes for walls, columns, slabs, and so on. Another example would be grouping elements according to the value of a specific attribute, e.g., separating load-bearing and non load-bearing walls.

With the class precondition, the dependencies between processes are represented. Four types of process sequences are defined: start-end, start-start, end-start, and end-end. Moreover, the resource class summarizes different types of resources that are required for a particular process. This can include construction workers, equipment, materials, and temporary installations like formwork and guardrails. Since existing ontologies already define these resource sub-classes in close detail, only the resource class without sub-classes is defined in CSO, which shall be used as a connection point to other ontologies.

For the representation of building elements and their spatial distribution within specific buildings, storeys, and rooms, the Building Topology Ontology (BOT) [23] and the GeoSPARQL Ontology [24] are reused. Construction schedules often define work sections that are not represented in the BIM model. Nevertheless, to automatically filter elements by their corresponding zones, the spatial extent of these zones needs to be known. For the case study presented in this paper, GeoSPARQL and the Well-Known-Text (WKT) format are used to assign geometric information to zones [24]. However, this is not a mandatory choice and can be replaced by other geometric representations.

While this paper presents a new ontology for construction processes, the classes about process decomposition and dependencies could alternatively be integrated into already existing ontologies. Integration into ifcOWL does not seem suitable due to the significant overhead and missing integration in project management software. However, DiCon, CTO, and IOC are assessed to be suitable to be extended with the missing concepts with relatively little effort. For example, the classes cso:Process and cto:Task and cso:hasTargetElement and cto:isSubjectOfTask can be considered equivalent and form a good starting point for an alignment.

Workflow of IFC-to-schedule linking

The proposed process model has multiple potential applications. In the context of this study, a methodology for semi-automated linking of building elements defined in an IFC file with individual processes outlined in the construction schedule is introduced. This linkage is facilitated through explicitly defined decomposition criteria, allowing for a predominantly automatic interpretation of the schedule.

Manual linking these elements is highly time-consuming, given that BIM models often comprise several hundreds or even thousands of building elements. Nonetheless, the connection of processes and elements proves valuable, offering benefits such as enhancing the schedule based on precise quantities extracted from the BIM model and facilitating 4D simulation of the construction process.

To implement the proposed workflow, the construction schedule must be available in an open format like CSV, enriched with additional information about the employed process decomposition criteria. A boolean flag indicating whether the building elements corresponding to the processes are modeled in the IFC model is also required, currently added manually to the schedule. Additionally, the BIM model is required to have access to detailed information about the building elements. Depending on the schedule and the exact use case, information regarding resource assignments might also be needed.

Initiating the workflow involves converting both the IFC model and the schedule into RDF. For the IFC model, two commonly used converters exist. The IFCtoRDF converter translates the IFC file into an RDF graph using the ifcOWL ontology. This is suitable when detailed information on the geometry and attributes of building elements is needed [25]. The IFCtoLBD converter is a lightweight alternative. It uses BOT and BEO to represent the spatial structure of the building in the RDF graph without considering geometric information [26,23,27]. The construction scheduling ontology is proposed to represent the construction schedule in RDF. Subsequently, these separate RDF graphs must be injected into an RDF database.

The final step involves linking the processes with their corresponding building elements in the RDF graph through the object property cso:hasTargetElement. This is accomplished by an algorithm that traverses each process in the construction schedule according to its hierarchical structure. If the target elements are not represented in the IFC file, the process is skipped, and no element is assigned to it. Conversely, if the target elements are present, the building elements linked to the process's parent serve as a starting point. Depending on the process decomposition criterion, the algorithm filters out all elements that do not fulfill the criterion, and the remaining elements are then connected to the current process in the RDF graph. In order to match a sub-process with the exact filtering condition, the process name is searched for specific keywords. As an example, when a process decomposition by element type is applied it is searched for words like wall, column, and window to know which process should be assigned with which element type. This is, however, a limitation of this implementation. Table 3 provides an overview of how the linking algorithm handles various types of decomposition criteria. To implement the linking algorithm detailed in Section 3.3, the C# programming language was employed. Commencing with the IFC file, the preexisting IFCtoLBD converter was utilized [26]. This converter transforms IFC files into RDF representation, using the ontologies BOT, BEO, and PROPS. The resulting RDF graph was then stored in the GraphDB [28] RDF database. To facilitate interaction with the SPARQL endpoint of the database in the C# programming environment, the dotNetRDF [29] library was incorporated. Given that the IFCtoLBD converter does not include geometric information, furthermore, the xBIM [30] library was employed to extract additional details from the IFC file for the linking process. Regarding the construction schedule, a dedicated converter was developed. This converter reads the process information from the Excel file and transforms it into the corresponding RDF representation. Subsequently, this information is transmitted to the GraphDB SPARQL endpoint to update the database.

The filtering algorithm, as outlined in Section 3.3, has been successfully implemented, featuring distinct functions tailored to handle the different decomposition criteria, as detailed in Table 3. To align a specific sub-process with the precise filtering condition, the process name undergoes analysis for specific keywords. For instance, in the case of process decomposition by element type, the algorithm scans for keywords such as "wall, " "column, " and "window" to determine the appropriate assignment of processes to element types. However, it is crucial to acknowledge a limitation inherent in this implementation. For the processes related to walls, manual intervention was necessary to point the filtering algorithm to the location where the relevant information could be found within the IFC file. In the given case, load-bearing walls had to be distinguished from walls designed for interior partitions. However, in the IFC file, some load-bearing walls were missing the load-bearing property. For this reason, it could not be used to separate the two different types of walls correctly. Manual analysis identified that load-bearing walls were assigned a different IfcMaterial than the interior partitions. Manually defining that the filtering algorithm should use the material as a distinguishing factor between load-bearing walls and interior partitions for this specific process was sufficient to fix the issue. Furthermore, the use of abbreviations in process names poses a challenge for accurate linking. In the frame of the case study, this was resolved by manually replacing abbreviations in the schedule with the complete word.

The outcomes of the linking algorithm are depicted in Figure 8, where building elements linked to the same process share a common color. To enhance clarity, only the leaf processes were considered, preventing elements from being assigned the color of multiple processes. Additionally, the building is separated into the four storeys for visualization purposes.

Discussion

The availability of additional information about the schedule regarding process decomposition proved beneficial in interpreting the process hierarchy. This supplementary information facilitates a largely automated process interpretation, aiding in identifying relevant processes for specific use cases. For instance, the ability to filter out irrelevant parts of the schedule for a particular simulation based on decomposition criteria streamlines the overall analysis and narrows the focus to pertinent subsections. In the present research, the process interpretation was used for semi-automated linking between processes and building elements. Even though minor manual intervention was required because of cases where it is not immediately clear if certain information is specified in the name, a property or the assigned material of an entity in the IFC file, significant time savings could be achieved.

Several limitations deserve acknowledgment in our study. The effectiveness of the linking processes is strongly dependent on the quality of the IFC model. Instances of modeling errors, such as elements erroneously assigned to the wrong storey or lacking material definitions, negatively influence the accuracy of the results. Furthermore, a certain level of correlation between the schedule and the IFC model is required. Shared attribute and class names facilitate the linking process, and without such consistency, full automation becomes challenging. Another limitation involves the granularity of processes and the BIM model, where disparities may arise. For example, an element described in the schedule as having multiple parts might be modeled as a single element in the IFC file. While an algorithm developed by Tulke [31] addresses such cases by dividing elements to match the granularity of the construction schedule, it was not applied in the present paper. Finally, inconsistencies within the schedule also pose challenges. Instances where multiple decomposition criteria are simultaneously applied to a single process decomposition can lead to misinterpretation. It is suggested to divide such decompositions into distinct processes. Although this results in more processes, it enhances comprehension.

Conclusion

In addressing the challenges surrounding the exchange of project management information within the construction industry, emphasising construction schedules, this research has introduced a novel approach to enhance automation and efficiency. The prevalent reliance on XML or spreadsheet-based files for schedule exchange has been identified as a source of information loss and misinterpretation within commonly used project management software. Diverse scheduling practices across construction companies intensify the issue by contributing to a lack of standardisation.

To bridge this gap, the paper proposed a minimal ontology specifically designed to represent construction schedules' processes, addressing the limitations of existing data schemata. It relies on analysing process decomposition criteria used in eight construction schedules. A small-scale case study showcased the ontology's application in automated schedule interpretation, highlighting its potential for linking between schedules and corresponding BIM models. This approach reduces manual efforts but also significantly enhances overall efficiency in project management processes. The broader implications of the introduced ontology extend beyond the immediate scope of schedule exchange. The ontology's versatility offers opportunities for consistency checks, completeness assessments, and streamlined coordination between contractors and subcontractors.

Future improvements should revolve around the application of natural language processing techniques to improve the interpretation of process names and identify their filtering criteria fully automated. Furthermore, the developed ontology should be fully integrated into existing ontologies after consultation with the corresponding ontology creators to follow the FAIR data principles and ensure that others can apply the developed concepts more quickly. While this study only considered the topmost level of construction classification systems for process decomposition criteria, it should be investigated how considering the complete classification hierarchy could improve automated schedule interpretation.