Review of Information Completeness in As-Built Building Information Models for Project Delivery

Abstract

The As-built Building Information Model (BIM) serves as a carrier of lifecycle information for the physical building and is a critical component of project handover. Despite the issuance of numerous delivery standards globally, efficient methods for reviewing information completeness remain insufficient, hindering the timely and effective delivery of project information. To address this gap, this research employs ontology technology as its core to develop a method for reviewing information completeness in as-built architectural engineering BIMs. An ontological model is constructed using Protégé, Semantic Web Rule Language (SWRL) rules for Completeness Review are defined, and a Revit data extraction add-in is developed to store model data in a database and map it to an ontological knowledge base. An integrated review system for As-built BIM information completeness is subsequently built. This system automates the entire review workflow, encompassing data import, semantic conversion, rule-based reasoning, and result output. Validated through a teaching building case study, the system successfully and accurately identified missing attributes and documents within the model, demonstrating high accuracy and review efficiency. The proposed method and its accompanying review system provide a scalable, rule-driven solution for ensuring BIM integrity, effectively supporting digital delivery in the architecture, engineering, and construction (AEC) industry.

1. Introduction

Building Information Modeling (BIM), as a holistic digital mapping and integrated representation of the physical building entity, has become a core driver for the digital transformation of the construction industry, enabling lifecycle information collaboration and management enhancement. BIM is not only integral to the design, construction, and operation phases but also plays a pivotal role as a bridge, transforming construction outcomes into operational assets during the handover phase. As the industry’s digitalization accelerates, BIM application has progressed from design visualization to construction management, completion acceptance, and facility management, among other areas. Particularly driven by national strategies such as Digital Twin and Smart City, high-quality, complete As-built BIMs form the essential foundation for building digital asset accumulation and continuous value addition.

The as-built delivery phase represents a critical transition point in the building lifecycle. Its core value lies in transforming the BIM from a construction process carrier into an operational data asset and an urban information substrate. This unique and irreplaceable characteristic necessitates its focus for BIM review. Functionally, as-built delivery is the key link connecting construction with operation management and urban information integration. While design-phase BIMs focus on schematic representation and code compliance, and construction-phase models emphasize process control and collaborative work, As-built BIMs must integrate data from the entire process: design intent, construction changes, site acceptance, product warranties, and operational attributes, forming a comprehensive digital archive of the building entity. From an industry practice perspective, the As-built BIM is crucial for overcoming the implementation bottleneck of physical-to-model consistency. Current industry research on consistency often focuses on geometric alignment, overlooking that information consistency is the prerequisite and core of physical-to-model alignment. If the as-built model lacks complete component attributes, acceptance documentation, and product information, even perfect geometric alignment renders it incapable of fully representing the physical building or supporting subsequent intelligent applications. Review during as-built delivery ensures model information completeness, providing the informational foundation for physical-to-model consistency, enabling the digital model to truly replace traditional paper archives and support practical applications.

In current practice, incomplete information in As-built BIMs has become a major bottleneck limiting the value realization of BIM technology. Due to the multitude of disciplines, diverse participants, and vast data volume in construction projects, information at project completion is often scattered across design drawings, construction logs, acceptance reports, product manuals, and other media. The lack of unified integration standards and automated tools leads to common issues such as geometrically complete but informationally deficient models and disconnection between models and documentation. The direct consequence is that As-built BIMs fail to meet application needs: handover requires supplementing with extensive paper documentation due to missing information; operation and maintenance are hindered by a lack of key data; and City Information Model (CIM) integration is affected, impairing platform functionality. Moreover, the complexity and interconnectedness of as-built model information make manual review inadequate for comprehensively identifying missing data. Manually checking attributes and documents for tens or hundreds of thousands of components is highly inefficient and error-prone. Furthermore, logical relationships between information items are difficult to ascertain manually, resulting in ineffective review.

Over the past two decades, research on BIM-based automated review has developed rapidly—from Singapore’s computerized 2D drawing review in 1995 [1] and the IFC-based CORENET system in 1998 [2], to the SMART Codes project in the United States in 2006 which proposed methods for converting standards into machine-executable rules [1], and the establishment of quality inspection systems in Norway and Finland [3,4]. Eastman et al. proposed a four-stage framework for rule checking [5], Pauwels et al. explored semantic rule-checking environments [6], Nawari et al. investigated automated code compliance checking using SMART Codes [7,8], and Beach and Malsane et al. proposed semantic rule-based methods for regulatory compliance [9,10]. In recent years, Pauwels further explored RDF-based semantic quality checking [11], Guo et al. proposed an NLP plus spatial reasoning framework for fire code checking [12], and Lee et al. developed a design support system integrating automatic rule checking with case-based reasoning [13]. However, these studies predominantly focus on design-phase compliance checking and geometric properties of model components, failing to effectively address the information completeness requirements of the as-built delivery phase.

While the Level of Development (LOD) concept pioneered in the United States has provided important theoretical groundwork for information delivery [14], and researchers have explored LOD applications for enhancing Life Cycle Assessment [15], bridging Integrated Project Delivery with BIM [16], refining geometric descriptions [17], and manufacturers have explored BIM standard application through Information Delivery Manuals [18], these studies primarily address design delivery and lack focus on as-built information completeness.

Therefore, conducting Information Completeness Reviews for As-built BIMs is not an added burden but an essential response to industry pain points, crucial for advancing BIM implementation. Systematic, automated review methods ensure that as-built models contain all key information and relationships required for subsequent applications. This prevents as-built models from becoming merely formal deliverables, unlocking their core value in archive management, operational support, and urban integration, thereby providing a solid data foundation for the industry’s digital transformation.

To address gaps in the theoretical framework for As-built BIM Information Completeness Review, this study aims to propose an ontology-based method for reviewing information completeness in architectural engineering As-built BIMs, tackling issues of unclear and incomplete information during delivery. The research involves an in-depth investigation into ontology-based review methods for as-built delivery. It systematically constructs a review requirement system and review ontology; develops automated information extraction and semantic conversion technologies to integrate and standardize multi-source heterogeneous data; and builds an intelligent review system to ensure information completeness and relational integrity of As-built BIMs. This research provides methodological support for quality control and efficient reuse of As-built BIMs, promoting the industry’s shift towards truly data-driven, lifecycle digital management.

2. Literature Review

2.1. Current Research on BIM-Based Automated Review

Computer-aided design rule checking has developed rapidly, with early exploration in developed countries. Singapore utilized computer code for 2D drawing review as early as 1995 [1]. In 1998, the CORENET system began processing IFC-based building model reviews, leading to the Corenet E-Plan Checker platform [2]. In 2006, the United States initiated the SMART Codes project, a collaborative effort by the International Code Council (ICC), AEC3, and Digital Alchemy, representing a process-oriented methodology for converting standards into machine-executable rules [1]. SMART Codes also saw development in South Korea and Australia, including studies for accessibility verification and fire safety code compliance [2]. Norway established a quality inspection system based on its national standards within the Standardized Computable Rules framework in 2009, greatly facilitating the work of designers and reviewers [3]. In the same year, Finland’s Solibri company published the Spatial Coordination White Paper, advancing the concept of comprehensive coordination quality checking [4]. With further advancements in computer technology, a more sophisticated inspection method emerged—rule checking based on logical operations. This method, involving the translation of standards into computer code and corresponding rules, is now widely used in developed countries within electronic plan review systems, offering new approaches for efficient project workflow management.

In 2009, Eastman et al., after analyzing various rule-checking systems for design evaluation, proposed that such systems primarily function through four stages: rule interpretation, building model preparation, rule execution, and report generation, providing a foundational framework for research in this area [5]. With the evolution of BIM technology, Pauwels P compared the IFC standard with Semantic Web language capabilities, proposing a specific implementation method for a semantic rule-checking environment in architectural design and construction [6]. In 2012, Nawari et al. utilized SMART Codes to establish rule sets for automatically checking building components in BIMs against code requirements [7]. In 2013, Nawari identified two key factors for automated code checking: the sufficiency of information content and the level of detail in the BIM, and the accurate translation of design standards into computer-executable rules [8]. In 2015, Beach et al. proposed a semantic rule-based method using three semantic constructs to better understand building regulations and reduce their complexity [9]. Also in 2015, Malsane et al. viewed buildings and codes from an object-oriented perspective, creating an object model based on parts of UK building regulations [10]. In 2017, Pieter Pauwels explored using the logical foundation of RDF to implement semantic quality checking, applying strategies and methods for translating construction industry rules semantically [11].

In 2019, Lee et al. proposed a system supporting design rule checking, using automated review to verify design compliance and providing suggestions regarding compliance system ontologies and semantics through a case study [13]. In 2021, Guo et al. further extended cross-technological boundaries by proposing an NLP plus spatial reasoning framework for fire code checking [12]. By using Natural Language Processing (NLP) to extract spatial relationship terms from fire safety codes and combining them with SPARQL queries on BIM geometric and topological data, they achieved automatic verification of fire egress connectivity.

2.2. Current Research on BIM-Based Information Delivery

The concept of Level of Development (LOD), pioneered in the United States, holds foundational significance in BIM research, providing important theoretical groundwork for subsequent studies. In design delivery, Aryani’s research on BIM-enabled design projects found that appropriate application of LOD allows project stakeholders to precisely obtain necessary information at specific stages, which is also seen as a key indicator of BIM competency and understanding [14]. Nilsen, recognizing standardization gaps in early BIM development, innovatively applied LOD as a tool to enhance Life Cycle Assessment (LCA) effectiveness, systematically dividing the design process into five levels and introducing LOD 350 [15]. Wei, based on a coordinated design model for industrialized housing systems, successfully bridged Integrated Project Delivery (IPD) and BIM application [16]. Data analysis indicated that IPD provides a favorable environment for BIM implementation, addressing shortcomings of traditional delivery methods. Biljecki and Filip, addressing limitations in existing LOD classifications, proposed a refined system with 16 criteria [17]. This system does not replace existing specifications but refines geometric descriptions and clarifies boundaries between criteria, enhancing the precision and application accuracy of BIM information. In the UK, manufacturers actively explore BIM standard application. Gigante-Barrera and Ángel proposed creating LOD specifications for model element product data [18]. Using Information Delivery Manuals (IDMs), manufacturers can create and maintain product data at different LOD levels, enabling effective information exchange with clients and integration into BIM systems. This expands BIM application depth in manufacturing, supporting its digital transformation. In Japan, Hirano and Hikari noted the absence of a unified national LOD standard [19]. Investigating LOD standardization, they reviewed the BIM Forum LOD Specification to clarify theoretical concepts and surveyed domestic corporate LOD applications. They found direct adoption could cause compatibility issues, suggesting that while leveraging BIM benefits, parallel efforts should standardize LOD specifications and adapt architectural design processes.

2.3. Current Research on Ontology Application in Engineering

In the current digital era, ontology technology, as a key method for knowledge representation, management, sharing, and reuse, demonstrates significant value across multiple fields and plays a unique role in various stages of architectural engineering, injecting new vitality into its development. The core strength of ontology lies in its structured knowledge representation capability. Languages like the Web Ontology Language (OWL) can clearly and accurately express conceptual hierarchies, providing a unified semantic foundation for computers. This effectively addresses interoperability issues of heterogeneous data, promoting efficient information integration and precise knowledge retrieval, which lays a solid foundation for its broad application in construction engineering.

In knowledge modeling and knowledge base construction, numerous scholars have conducted active exploration and practice. Wu et al. introduced a Concrete Bridge Rehabilitation Project Management Ontology (CBRPMO), significantly improving information integration and constraint management [20]; Cao et al. used an ontology-based method to connect design and manufacturing knowledge, analyzing manufacturability by combining multiple modeling approaches [21]; Qi et al. proposed a BIM and ontology-based Design for Manufacture and Assembly (DfMA) framework for prefabricated and modular components, effectively addressing conflict detection and resolution among design, manufacturing, and assembly requirements [22]; Karim et al. developed a construction site (cSite) ontology to automate production and control processes on site [23]; Jia et al. developed an ontology for construction process information modeling and management [24]; Lu et al. developed a Carbon Emission Management Ontology (CEMO) to facilitate carbon emission data collection, monitoring, and evaluation [25]. These studies showcase the potential of ontology technology in knowledge modeling and management across various construction engineering sub-domains. By building domain ontologies, they achieve systematic knowledge integration and effective utilization, providing strong support for optimizing different project phases.

Ontology technology also plays a key role in the evaluation and decision-making stages of construction projects. Xu et al. developed an ontology-based building seismic risk assessment system (OntoBSRA) for predicting seismic risk of buildings with different uses and damage states [26]; Cui et al. employed a Monte Carlo simulation method combined with a knowledge base and Semantic Web rules to establish an ontology-based seismic risk assessment model for subway stations [27]; Zhao et al. proposed a BIM and ontology-based method for optimizing building exit locations [28]; Jiang et al. proposed an intelligent control scheme for Building Fire Protection (BFP) systems using Digital Twin (DT) and Semantic Web technologies, supporting retrieval, reuse, and decision-making [29]. Thus, ontology technology can integrate multi-source data and knowledge, providing rich, accurate information for scientific evaluation and rational decision-making in early project stages, helping optimize project plans, reduce potential risks, and improve project feasibility and sustainability.

In safety risk identification and management, Doukari et al. developed an ontology for representing and identifying hazards in building renovation projects, effectively reducing accident and injury risks [30]; Mohamed et al. proposed an ontology and ontology-based method for identifying risks in onshore wind farm construction projects [31]; Lee et al. proposed combining AI-based image recognition with ontology to automatically identify hazardous situations and infer safety conditions from images [32]; Zhou et al. established a domain ontology for dam safety monitoring systems, enabling dam safety monitoring management through SPARQL queries [33]; Wu et al. combined computer vision and ontology to infer hazards and mitigation measures [34]; Shen et al., based on ontology and Revit secondary development, established a safety risk management system for prefabricated building construction in a BIM environment [35]. These practices show that ontology technology can integrate various safety-related information, build a comprehensive risk knowledge system, and enable automatic risk identification and warning through rule-based reasoning, enhancing the intelligence of construction safety management, ensuring smooth project progress and personnel safety.

In summary, leveraging its powerful capabilities in knowledge representation, reasoning, and integration, ontology technology has achieved fruitful results in construction engineering knowledge modeling and management, project evaluation and decision-making, and safety risk identification and management. It provides strong support for the refined and intelligent development of various construction project phases. Applying ontology technology to organize and integrate as-built acceptance and delivery standards can build more comprehensive and accurate information models, providing reliable data sources and clear semantic frameworks for Information Completeness Review, ensuring review accuracy and efficiency, and promoting higher-level digital transformation in construction engineering.

2.4. Summary of Research Status

(1)

Focus on Design Deliverable Review—Insufficient Research on As-Built Delivery Review

Current research on BIM technology application in construction engineering predominantly focuses on optimizing and refining design-phase deliverables. At this stage, efforts concentrate on leveraging BIMs for precise visualization, comprehensive clash detection, and preliminary compliance checking. The primary goal is to ensure the scientific feasibility of design schemes to meet pre-construction requirements. In contrast, research targeting the as-built delivery phase remains relatively scarce.

The as-built acceptance phase encompasses rich and complex real-world engineering information. This includes construction change details, actual material usage, detailed equipment parameters and operational status, system commissioning data crucial for intelligent operation, operation and maintenance plans, and corporate data assets such as cost accounting details and resource consumption statistics. The completeness and accuracy of this information are indispensable for precisely assessing the final quality, performance, and potential value of a construction project.

Unfortunately, only a limited number of studies attempt to address As-built BIM creation, and significant room for improvement remains regarding information completeness, accuracy, and alignment with actual construction. This situation directly hinders the full utilization of BIM technology’s advantages during as-built acceptance, preventing comprehensive, efficient, and accurate review processes. It risks overlooking potential critical issues, negatively impacting project handover quality and constraining subsequent use and long-term development.

(2)

Insufficient Research on BIM Information Completeness Review

Current BIM review efforts primarily focus on compliance checking. This involves comparing design elements in the model against existing building codes, standards, and regulations to ensure adherence. However, this review mode carries a subtle but significant underlying assumption: that the model information is complete.

In practice, BIMs face numerous challenges regarding information completeness. Common issues include missing information, such as unrecorded key attributes for certain components; inconsistent information, like mismatched interface data between different discipline models, which can cause errors during data exchange and integration; and information redundancy, where excessive irrelevant data occupies storage space and complicates model management and review. Although BIM theoretically serves as a unified repository for information generated across all project lifecycle phases, facilitating information exchange and sharing among stakeholders, systematic, efficient, and automated methods for reviewing the information completeness of delivered models are still lacking. Existing BIM delivery standards, from national to local to enterprise levels, specify model element object types, object properties, naming conventions, and modeling depth for delivered model files. However, their potential value has not been fully realized in practice; they have not been effectively transformed into actionable tools for Information Completeness Review, and struggle to adapt to the dynamic updates and variations in delivery standards.

(3)

Comparative Analysis with Existing Semantic BIM Review Systems

To clearly position this study within the existing research landscape,

Table 1. Comparative analysis of semantic/rule-based BIM review systems.

System/Approach	Review Focus	Rule Representation	Data Processing	Key Limitations	This Study’s Differentiation
Eastman et al. (2009) [5]	Design code compliance	Hard-coded logic	Manual model preparation	Design-phase only; no semantic reasoning	As-built focus; ontology-based semantic reasoning
Pauwels et al. (2011, 2017) [6,11]	Building performance	SWRL rules on IFC/RDF	IFC to RDF conversion	Performance-oriented; limited completeness checking	Information completeness; full project + component levels
Beach et al. (2015) [9]	Regulatory compliance	Semantic rules with three constructs	Manual rule authoring	Limited to specific regulations	Comprehensive delivery knowledge base
Guo et al. (2021) [12]	Fire code compliance	NLP + SPARQL	Geometric/topological data extraction	Fire safety only; no document integration	Multi-discipline coverage; document association
Solibri Model Checker	Design coordination, code checking	Predefined/custom rules	Direct IFC import	Limited to geometric/spatial rules	Information completeness + semantic associations
This Study	As-built information completeness	SWRL rules + ontology axioms	Revit add-in → Database → OWL (full automation)	Manual rule authoring; limited document content analysis	First systematic approach for as-built information completeness with full-chain automation

presents a comparative analysis of representative semantic and rule-based BIM review systems against the proposed approach. This comparison highlights the unique contributions of this study, particularly its focus on as-built delivery information completeness and full-chain automation.

As shown in Table 1, existing systems predominantly focus on design-phase compliance checking, geometric validation, or specific domain regulations. In contrast, this study addresses the underexplored area of as-built delivery information completeness, integrating project-level and component-level information with acceptance documentation through a fully automated data processing pipeline.

3. Methodology

3.1. Overall Framework for Information Completeness Checking

The core methodology of this study centers on ontology technology, aiming to address the inefficiency of manual review and the lack of systematic tools for information completeness checking of As-built BIMs. This approach starts with constructing an ontological model using Protégé, which defines key concepts and their semantic relationships to form a structured review knowledge base. Simultaneously, Semantic Web Rule Language (SWRL) rules are developed to encode Completeness Review logics, such as verifying mandatory attributes for components and project-level documents. To connect raw BIM data with the ontological knowledge base, a Revit add-in is designed for automated extraction of project and component-level data, which is then stored in a structured database and mapped to the ontological knowledge base via predefined rules.

This technical roadmap culminates in an integrated review system that automates the entire workflow: data import (from CSV files generated by the Revit add-in), semantic conversion of database data into OWL-formatted ontology instances, rule-based reasoning using the Drools inference engine to detect missing information, and final output of structured review results. The system enables end-to-end automation without manual intervention, and its effectiveness is validated through a teaching building case study, where it accurately identifies missing attributes and documents in the As-built BIM. The technical roadmap for the proposed methodology is shown in Figure 1.

3.2. Construction of Ontology-Based Rules for As-Built BIM Information Completeness Review

3.2.1. Building the As-Built BIM Delivery Review Knowledge Base

This section constructs the framework of the As-built BIM Delivery Review Knowledge Base according to seven aspects: As-built BIM, Project Information, Model Components, Project-Level Delivery Information, Component-Level Delivery Information, Information Completeness Review, and Completeness Evaluation. The logical framework is shown in Figure 2.

The analysis begins with the As-built BIM of a specific construction project. Since review at the as-built delivery stage involves not only component model unit information and related acceptance documentation but also project-level and unit engineering acceptance data, the model composition (i.e., the review objects) is divided into Project Information and Model Components for convenience in subsequent rule construction. Model Components are further classified into eight categories based on divisional and subdivisional works: Foundation and Substructure, Main Structure, Architectural Finishes, Building Envelope and Roofing, Plumbing and Heating, Ventilation and Air Conditioning, Electrical, and Intelligent Building Systems, encompassing over 250 component types. An As-built BIM’s Project Information must contain explicit and complete Project-Level Delivery Information, namely Project-Level Model Unit Information and Project-Level Acceptance Data and Materials. Similarly, its Model Components must contain explicit and complete Component-Level Delivery Information, namely Component-Level Model Unit Information and Component-Level Acceptance Data and Materials. Information Completeness Review is conducted based on the specific Project-Level and Component-Level Delivery Information contained within the Project Information and Model Components, respectively, leading to a Completeness Evaluation result.

Following the underlying logic of ontology construction, the knowledge base building process can be detailed into progressive steps: first, defining the conceptual boundaries of core domain classes and establishing hierarchical inheritance and relational constraints to build the logical skeleton; second, defining semantic rules and constraints for inter-class associations through object properties, strengthening interaction logic; third, precisely characterizing quantitative features of classes through data properties, enhancing knowledge granularity; finally, mapping classes to specific instances, transforming the conceptual framework into an applied entity, constructing a knowledge system with both theoretical rigor and practical guidance.

(1)

Class Definition and Inter-Class Relationship Establishment

Class is the basic element in the conceptual model of the As-built BIM Delivery Review Knowledge Base. Classes are defined based on seven fundamental concepts: As-built BIM, Project Information, Model Components, Project-Level Delivery Information, Component-Level Delivery Information, Information Completeness Review, and Completeness Evaluation. Among these, Project-Level Delivery Information includes two core concepts: Project-Level Model Unit Information and Project-Level Acceptance Data and Materials. Component-Level Delivery Information includes Component-Level Model Unit Information and Component-Level Acceptance Data and Materials. Definitions and relationships are detailed in

Table 2. Framework of the As-built BIM Delivery Review Knowledge Base.

Class		Abbreviation	Description
As-built BIM		As-built BIM	The As-built BIM of a specific project.
Project Information		Project Information	Project-level related information contained in a specific project.
Model Components		Model Components	Model components are the basic elements constituting the As-built BIM.
Project-Level Delivery Information	Project-Level Model Unit Information	PMUI	Includes project identification, construction description, building category/grade, technical-economic indicators, participant information, etc.
	Project-Level Acceptance Data and Materials	PADM	Refers to the as-built acceptance documents to be delivered, including project as-built acceptance data/materials and unit engineering BIM data/materials.
Component-Level Delivery Information	Component-Level Model Unit Information	CMUI	Includes identity, technical, production, maintenance information, etc.
	Component-Level Acceptance Data and Materials	CADM	Refers to divisional work BIM data/materials, required to be linked to model components upon delivery.
Information Completeness Review		Integrity Checking	Reviewing the completeness of PMUI, PADM, CMUI, and CADM in the As-built BIM according to certain rules.
Completeness Evaluation		Integrity Evaluation	Evaluating completeness from Project Information and Model Components to the entire As-built BIM.

.

(2)

Object Properties

Object properties primarily describe and establish relationships between classes in the knowledge base that are not subclass or hierarchical relationships. Definitions are listed in

Table 3. Categories and settings of object properties.

Object Property	Domain	Range	Description
Is_Comprisedof	As-built BIM	Project Information, Model Components	Defines the relationship that an As-built BIM consists of Project Information and Model Components.
Has_PMUI	Project Information	Project-Level Model Unit Information	Defines whether Project Information has PMUI.
Has_PADM	Project Information	Project-Level Acceptance Data and Materials	Defines whether Project Information has PADM.
Has_CMUI	Model Components	Component-Level Model Unit Information	Defines whether a Model Component has CMUI.
Has_CADM	Model Components	Component-Level Acceptance Data and Materials	Defines whether a Model Component has CADM.
Conduct_P_Checking	Project-Level Delivery Information	Project-Level Information Completeness Review	Indicates that Project Information requires Information Completeness Review.
Conduct_C_Checking	Component-Level Delivery Information	Component-Level Information Completeness Review	Indicates that a Model Component requires Information Completeness Review.
Conduct_Evaluation	Project-Level/Component-Level Information Completeness Review Result	Completeness Evaluation	After review, it determines the completeness of Project-Level and Component-Level Delivery Information, leading to the overall model completeness evaluation.

.

Here, Is_Comprisedof indicates that an As-built BIM is composed of Project Information and Model Components. Has_PMUI and Has_PADM indicate that Project Information contains PMUI and PADM, respectively. Has_CMUI and Has_CADM indicate that a Model Component contains CMUI and CADM, respectively. Conduct_P_Checking and Conduct_C_Checking represent conducting Completeness Reviews on Project-Level and Component-Level Delivery Information, respectively. Conduct_Evaluation represents evaluating the overall information completeness of the As-built BIM delivery model. The Domain and Range of each property define the start and end points of the relationships, establishing inter-class property connections.

(3)

Data Properties

Data properties provide detailed descriptions and analysis of the established classes, creating relationships between data and classes. Based on the framework classes (As-built BIM, Project Information, etc.), each class is elaborated through data properties. For example, As-built BIM and Project Information use data properties like project number and name. Model Components use the component ID and name. Delivery Review Information data properties include the associated model component (or project information), review information name, and attribute value. Information Completeness Review data properties describe the presence/absence of major information categories (e.g., PMUI status, PADM status for Project Information Review). The evaluation result output has the functional property characteristic, ensuring a unique mapping from the domain to the range. Partial data property definitions are shown in

Table 4. Partial list of class data properties.

Class	Data Property Setting	Value Type	Property Characteristic
As-built BIM	BIM Project Number	string	Functional
	BIM Project Name	string	Functional
Project Information	Project Number	string	Functional
	Project Name	string	Functional
Model Components	Component ID	string	Functional
	Component Name	string	Functional
Delivery Review Information	Associated Model Component (or Project Information)	string	Functional
	Review Information Name	string	Functional
	Review Information Attribute Value	string	Functional
Information Completeness Review	Associated Model Component (or Project Information)	string	Functional
	Review Attribute Name	string	Functional
	Component-Level (or Project-Level) Model Unit Information Status	string	Functional
	Component-Level (Project-Level) Acceptance Data and Materials Status	string	Functional
	Component-Level (or Project-Level) Information Completeness Review Result	string	Functional
Completeness Evaluation	Completeness Level	string	Functional

.

(4)

Instance Creation Instance

Instances are concrete manifestations of classes and properties in the conceptual model. Creating instances is the key step in transforming the abstract model into concrete entities. This significantly enhances the practical utility of the ontology and provides a basis for efficient data processing and information management. To validate and demonstrate the logical structure of the knowledge base, this study selects the As-built BIM of a teaching building project as a case. Taking the specific Component-Level Model Unit Information item Material Requirement for the structural column component as an example, the process checks whether the model component contains this attribute and outputs the result regarding its existence, as shown in Figure 3.

By creating corresponding instances for the basic classes and establishing object and data property relationships among them, connectivity is achieved among As-built BIM, Project Information, Model Components, Delivery Review Information, Delivery Information Completeness Review, and Completeness Evaluation. Instances are linked through object properties in a top-down directional manner and further elaborated through data properties. The relationships among classes, object properties, data properties, and instances are shown in Figure 4.

The connectivity within the knowledge base can be described as follows: The Teaching Building Project As-built BIM has a Model Component Structural Column. The Structural Column contains Component-Level Delivery Information Structural Engineering Component Acceptance Data and Materials. Information Completeness Review is conducted based on whether the model contains specific attributes, resulting in the finding Structural Column lacks a material requirement. Based on this result, the As-built BIM’s information completeness is evaluated as Incomplete. This forms the complete chain of relationships within the As-built BIM Delivery Review Knowledge Base.

3.2.2. Establishing Internal Rules Within the As-Built BIM Delivery Review Ontology

To enable Information Completeness Review, appropriate review rules must be established for the knowledge base content. This study primarily uses the SWRL to build a rule base, adopting a strategy that integrates the ontology with SWRL rules to perform rule-based reasoning for review. The SWRLTab plugin in the Protégé 5.6.4 editor is used for rule setting. Rules conforming to SWRL syntax are constructed to meet application requirements, and the plugin helps establish mapping relationships between rules and the conceptual model, ensuring the overall validity of the knowledge base during operation.

Based on the knowledge base framework, relationships among the basic classes are constructed. The Is_Comprisedof property links the As-built BIM to Project Information and Model Components. Project Information is linked to Project-Level Delivery Information via Has_PMUI and Has_PADM. Model Components are linked to Component-Level Delivery Information via Has_CMUI and Has_CADM. Project-Level Delivery Information is linked to its review via Conduct_P_Checking, and Component-Level Delivery Information via Conduct_C_Checking. Review results are linked to Completeness Evaluation via Conduct_Evaluation. By setting these chaining rules, a layered connection is established. SWRL rules are needed to infer implicit relationships (indicated by dashed lines in Figure 5), preparing for subsequent reasoning and completeness checking. The chaining rules are listed in

Table 5. Internal connection rules of the As-built BIM Delivery Review Knowledge Base.

Rule Name	SWRL Rule Setting	Rule Purpose
Rule-A	As-built BIM(?a) ^ Is_Comprisedof(?a, ?b) ^ Project Information(?b) ^ Has_PMUI(?b, ?c) ^ Project-Level Delivery Information(?c) ^ Conduct_P_Checking(?c,?d) ^ Project-Level Information Completeness Review(?d) ^ Is_Comprisedof(?a, ?e) ^ Model Components(?e) ^ Has_CMUI(?e, ?f) ^ Component-Level Delivery Information(?f) ^ Conduct_C_Checking(?f, ?g) ^ Component-Level Information Completeness Review(?g) ^ Conduct_Evaluation(?d, ?h) ^ Conduct_Evaluation(?g, ?h) ^ Completeness Evaluation(?h) -> Has_PMUI(?a, ?c) ^ Conduct_P_Checking(?a, ?d) ^ Conduct_Evaluation(?a, ?h) ^ Has_CMUI(?a, ?f) ^ Conduct_C_Checking(?a, ?g) ^ Conduct_Evaluation(?a, ?h)	Chain internal rules connecting the As-built BIM and the overall model completeness evaluation.
Rule-B	Project Information(?a) ^ Has_PMUI(?a, ?b) ^ Project-Level Delivery Information(?b) ^ Conduct_P_Checking(?b,?c) ^ Project-Level Information Completeness Review(?c) ^ Conduct_Evaluation(?c, ?d) ^ Completeness Evaluation(?d) -> Conduct_P_Checking(?a, ?c) ^ Conduct_Evaluation(?a, ?d)	Chain internal rules connecting Project Information and Project-Level Delivery Information completeness.
Rule-C	Project-Level Delivery Information(?a) ^ Conduct_P_Checking(?a,?b) ^ Project-Level Information Completeness Review(?b) ^ Conduct_Evaluation(?b, ?c) ^ Completeness Evaluation(?c) -> Conduct_Evaluation(?a, ?c)	Chain internal rules connecting Project-Level Delivery Information and Project-Level Information completeness.
Rule-D	Model Components(?a) ^ Has_CMUI(?a, ?b) ^ Component-Level Delivery Information(?b) ^ Conduct_C_Checking(?b,?c) ^ Component-Level Information Completeness Review(?c) ^ Conduct_Evaluation(?c, ?d) ^ Completeness Evaluation(?d) -> Conduct_C_Checking(?a, ?c) ^ Conduct_Evaluation(?a, ?d)	Chain internal rules connecting Model Components and Component-Level Delivery Information completeness.
Rule-E	Component-Level Delivery Information(?a) ^ Conduct_C_Checking(?a,?b) ^ Component-Level Information Completeness Review(?b) ^ Conduct_Evaluation(?b, ?c) ^ Completeness Evaluation(?c) -> Conduct_Evaluation(?a, ?c)	Chain internal rules connecting Component-Level Delivery Information and Information completeness.

.

3.2.3. Constructing Instance Checking Rules for As-Built BIM Delivery Review

The primary purpose of constructing instance checking rules is to review the information completeness of Project Information or specific Model Components within an As-built BIM to ensure they meet delivery requirements. To ensure completeness, attributes like PMUI and PADM in Project Information, and CMUI and CADM in Model Components need to be reviewed stepwise. Constructing these rules prepares for Drools-based reasoning and Information Completeness Review, ensuring the effective operation of the ontology. The logic for Project Information and Model Component review rules is similar. Using the Structural Column component as an example, corresponding rules are established in

Table 6. Construction of Information Completeness Review rules for As-built BIM delivery.

Rule Name	SWRL Rule Setting	Rule Purpose
Check-A	Structural Column(?a) ^ Component-Level Delivery Information(?b) ^ Component-Level Model Unit Information(?c) ^ Has_CMUI(?a, ?c) -> Conduct_C_Checking(?a, Component-Level Information Exists)	Checks for the presence of CMUI for the Structural Column component.
Check-B	Structural Column(?a) ^ Component-Level Delivery Information(?b) ^ Component-Level Acceptance Data and Materials(?c) ^ Has_CADM(?a, ?c) -> Conduct_C_Checking(?a, Component-Level Information Exists)	Checks for the presence of CADM for the Structural Column component.
Check-C	Structural Column(?a) ^ Component-Level Delivery Information(?b) ^ Component-Level Model Unit Information(?c) ^ Component-Level Acceptance Data and Materials(?d) ^ Has_CMUI(?a, ?c) ^ Has_CADM(?a, ?d) -> Conduct_Evaluation(?a, Complete)	Checks whether the Component-Level Delivery Information for the Structural Column component is complete.

.

The decision logic for completeness evaluation follows a hierarchical rule: Any missing mandatory field → Component-Level Delivery Information Incomplete → Project-Level Delivery Information Incomplete (if applicable) → Overall As-built BIM Incomplete. All mandatory fields are treated equally; the absence of any single required attribute renders the corresponding information category incomplete. For example, if a structural column lacks “Concrete Strength Grade” (a mandatory CMUI field), its Component-Level Delivery Information is marked incomplete, which contributes to the overall model incompleteness. Thresholds are binary (complete/incomplete) at the information item level, with no partial credit or weighting applied in this study.

3.2.4. Drools-Based Reasoning for As-Built BIM Delivery Information Completeness Review

After inputting the rules constructed for Structural Column into the knowledge base, this section focuses on obtaining the specific attribute status of components based on the conversion and simplification of instances from the As-built BIM. According to the set SWRL review rules applied via Drools reasoning, the review results are derived.

The Protégé 5.6.4 editor integrates the Drools inference engine. The basic principle involves the Drools engine using Drools facts and rules to perform reasoning. Applied here, it means providing the As-built BIM Delivery Review Knowledge Base with instances for checking and checking rules. The Drools inference engine converts ontology instances into Drools instances and SWRL rules into Drools checking rules, then performs reasoning to derive new knowledge, i.e., the checking results. The Drools reasoning workflow based on the knowledge base is shown in Figure 6.

3.3. Information Extraction and Semantic Conversion of As-Built BIMs

3.3.1. As-Built BIM Data Extraction Based on Revit Secondary Development

To efficiently, accurately, and structurally extract project-level and component-level information required for as-built delivery from Revit, this study designed and developed a dedicated As-built BIM Delivery Information Extraction add-in. Developed based on the .NET framework and Revit API, this add-in addresses the fragmentation and closed nature of Revit’s native functionalities for as-built information management. Through automated traversal, parameter parsing, and data export, it provides a standardized, high-quality data source for subsequent database storage, semantic conversion, and automated review. The add-in follows principles of modular functionality, user-friendly interface, and standardized output, ensuring usability, stability, and extensibility.

(1)

Design Workflow of the As-built BIM Delivery Information Extraction Add-in

The overall design follows a linear logic from model initiation to data export, ensuring clarity and traceability. The core workflow is shown in Figure 7.

The workflow begins with foundation development in Visual Studio 2022, creating a project and referencing core Revit API libraries (RevitAPI.dll, RevitAPIUI.dll). Using C# and the .NET framework, code is written to intelligently open and parse specified Revit model files, accurately identify component instances within the review scope from numerous model elements, systematically read multi-dimensional parameters (identity, technical, production, maintenance) for each component, and extract linked acceptance document information. The code incorporates comprehensive exception handling for stability. After debugging, an independent Dynamic Link Library (.dll) file is compiled. This file, the add-in itself, is loaded into the running Revit environment using tools like Add-In Manager, adding a new functional tab or command button to the Revit interface.

When a user opens the target as-built model in Revit and triggers the add-in command, the preset data extraction program runs automatically. It performs background operations: filtering components, iterating through instances, extracting and classifying parameter information, and retrieving linked file paths. Finally, all collected structured information is written to a CSV file in a format strictly corresponding to the backend database table schema. The CSV file, with its cross-platform compatibility and ease of processing, serves as an ideal data medium connecting BIM design software with the information review system. Thus, information originally confined and unstructured within the proprietary software is transformed into open, organized, and computer-processable data, laying the data foundation for subsequent database storage, semantic conversion, and final intelligent review.

(2)

Logic of As-built BIM Delivery Information Extraction

The technical implementation logic covers the entire chain from development environment setup to final data output, as detailed in Figure 8.

The extraction logic starts with platform setup. Microsoft Visual Studio 2022 is used as the Integrated Development Environment (IDE), programming in C# based on .NET Framework 4.8. By referencing Autodesk’s core assemblies, interaction with Revit 2020 and above is established. Within this environment, core extraction code is written according to the extended parameter system for as-built information. Code modules primarily implement: project information access interfaces, component filters, parameter value reading and type conversion, file path validation, and CSV file stream writing. The coding process emphasizes exception handling and performance optimization, e.g., using caching to reduce repeated API calls and transactions to ensure data consistency.

After compilation, an independent .dll file is generated. Loading this .dll into Revit via an add-in management tool activates the add-in’s functionality tab. In practice, the user opens the target As-built BIM in Revit and triggers the extraction task via the add-in interface. The add-in accesses the model database according to preset logic, performing traversal, reading, validation, conversion, and other operations, ultimately generating a CSV data file containing all as-built delivery information. This file, as raw BIM data, is standardized and complete, ready for direct import into the subsequent database.

3.3.2. As-Built BIM Database Design

To achieve persistent storage, efficient management, and semantic conversion of the extracted as-built delivery information, this section designs and constructs a relational database based on MySQL 8.0. Serving as the core data hub connecting As-built BIM information with the intelligent review system, this database must accommodate massive, multi-source, heterogeneous as-built information while supporting efficient querying, flexible structural expansion, and seamless mapping with the upper-level ontology knowledge base. The design adopts an overall approach of a Three-Level Core Architecture plus a Mapping Support Layer, combining normalized table structures with the extensible Entity–Attribute–Value (EAV) model to ensure the database meets current review needs while maintaining good maintainability and extensibility.

(1)

Overall Database Architecture Design

The database architecture closely aligns with the hierarchical nature of as-built delivery information and the data flow requirements of the review process. The overall architecture, shown in Figure 9, follows the logical hierarchy of Project–Component–Parameter, with an independent mapping rule layer added to support semantic conversion.

The architecture consists of a Data Storage Layer and a Semantic Conversion Support Layer.

• Three-Level Core Architecture (Data Storage Layer)

This layer is the main body of the database, responsible for structurally storing all entity data. It is divided into three hierarchical levels.

Project Layer: The highest organizational unit, corresponding to a complete construction project. This layer includes the projects table (project model unit information) and the project_acceptance_docs table. All data is associated with a specific project via project_id, addressing the ownership and integration of as-built information at the project level. This layer stores project-level model unit information and project acceptance data, providing global context for the entire database.

Component Layer: The bridge connecting the macro project with micro property parameters, corresponding to instance component instances in the BIM. The core table is components, storing components classified into eight engineering categories. It stores only core identification and positioning information for components, linking to the Project Layer via project_id and to the detailed Parameter Layer via its own component_id. This design avoids storing numerous dynamic attributes redundantly in the component table, keeping the table structure clean and efficient.

Parameter Layer: The granular level storing specific attribute values and materials, corresponding to each component’s model unit information and acceptance data. The component_params table uses the EAV model to store dynamic component attributes. Since the attributes requiring review vary greatly across different engineering categories and even different components within the same category, a fixed table structure is inadequate. The EAV model, through the form (component_id, param_name, param_value), can store and manage these varying attributes, enhancing system extensibility. The component_acceptance_docs table stores acceptance document information directly linked to each component, precisely bound via component_id, ensuring traceability between documents and the physical model.

2.

Mapping Support Layer (Semantic Conversion Layer)

To support the subsequent Database-Ontology Mapping step, a dedicated mapping_rules table is designed. This table operates independently from the core Data Storage Layer. Its core function is to define how to automatically convert structured data from the relational database into OWL ontology instance data for the Semantic Web. It records conversion rules from database tables and fields to ontology classes and properties, forming the basis for automated semantic conversion.

3.3.3. Importing As-Built BIM Delivery Information

After designing the database schema, the CSV data extracted by the add-in must be imported efficiently and accurately into the MySQL database for persistent storage and centralized management. This study designs and implements an automated data import program based on Python 3.13, aiming to establish a stable, repeatable data pipeline ensuring smooth information flow from BIM design tools to the relational database. The program strictly follows the Extract–Transform–Load (ETL) paradigm, with core steps as follows.

①

Database Connection and Environment Setup: The program starts by establishing a secure connection to the MySQL 8.0 database using the pymysql library, reading configuration files for the target database address, schema, and credentials. It pre-validates if the database table structure matches the designed schema.

②

CSV Source File Reading and Parsing: The program traverses the directory containing CSV files generated by the extraction add-in. Using the pandas library’s read_csv function, it reads project information, component lists, and detailed parameter data based on agreed file name patterns. All files are read with utf-8-sig encoding to avoid Chinese character corruption.

③

Data Cleaning and Structural Transformation: This stage standardizes raw data for import.

Null Value Standardization: Converts missing values (NaN) in CSV to empty strings or NULL values, ensuring compliance with database field constraints.

Data Type Validation: Converts numerical fields to floats; unifies date formats; ensures data compatibility with target field types.

Data Association Mapping Establishment: Since component parameters and acceptance documents need association via component_id, the program builds an in-memory mapping dictionary from component unique_id (extracted from CSV) to database component_id, providing the basis for subsequent foreign key relationships.

④

Transactional Batch Data Writing: The entire write process is encapsulated within a database transaction to ensure atomicity. Writing follows a strict table dependency order.

Write project model unit information to the projects table, obtaining the database-generated project_id.

Read and write project acceptance data to the project_acceptance_documents table using the obtained project_id.

Read component CSV files by engineering category, write to the components table using project_id, and record the mapping between each component’s unique_id and the system-generated component_id.

Read the corresponding component model unit information CSV, convert unique_id to component_id using the mapping, and batch insert into component_parameters.

Read component acceptance data CSV, similarly use the mapping, and batch insert into component_acceptance_documents.

⑤

Integrity Verification and Logging: The program includes integrity checks, verifying if record counts in each table match CSV data volumes. All operations are logged in detail, including start time, processing steps, success/failure counts, and any exceptions. If an error occurs, the program rolls back the current transaction, ensuring database state consistency, and outputs a clear error report.

3.3.4. Database-Ontology Mapping Framework and Implementation

The design of the mapping framework must fundamentally address the representational differences between the relational model and the ontological model. The relational model organizes data using two-dimensional tables, rows, columns, and foreign key constraints, emphasizing data structure and consistency. The ontological model expresses domain knowledge using classes, data properties, object properties, and instances, emphasizing concept semantics and logical relationships. Therefore, the core task of the mapping framework is to establish clear rules specifying how entities, attributes, and associations in the database are accurately mapped to corresponding elements in the ontological model.

The mapping framework designed in this study follows the principles of semantics-oriented, clear hierarchy, and flexibility/extensibility. Its overall architecture is shown in Figure 10. The architecture can be divided into three logical layers from bottom to top.

Source Data Layer: This layer corresponds to the MySQL As-built BIM Database. Data is stored in discrete tables, e.g., projects: stores project model unit information; components: stores component instances; and component_parameters: stores component model unit information in EAV mode. Tables are linked via primary/foreign keys (e.g., project_id, component_id), forming a complete but semantically implicit structured dataset.

Mapping Rule Layer: This is the core of the framework, responsible for carrying and executing conversion logic. Its center is the Mapping Rule Base, physically stored in the mapping_rules table, systematically recording conversion instructions from the database schema to ontological concepts. Each rule clearly specifies: the conversion type (creating class instances, assigning data properties, or establishing object properties between instances); source data location (which database table and field, with optional filter conditions source_condition for precise targeting); target semantic location (which ontology class the resulting instance should belong to, or which property it should have, specified as a URI); and conversion priority (for resolving conflicts when multiple rules apply to the same data item, ensuring deterministic results). This layer also contains a rule engine and converter, responsible for reading the rule base, traversing source data, and driving specific conversion operations based on the rules, dynamically building an RDF graph model.

Target Knowledge Layer: This layer is the output of the mapping, i.e., an OWL instance knowledge base conforming to the As-built BIM Delivery Review Ontology constructed in Section 3.2. Through mapping, records in the database are transformed into specific instances in the ontology, field values become data property assertions, and foreign key associations between tables become semantically rich object property assertions. Ultimately, all generated instances and their relationships form a semantic network. This network can be directly imported into ontology tools like Protégé or loaded by semantic engines like Jena or OWL API, providing directly operable knowledge objects for logic-based Completeness Review.

3.4. As-Built Architectural Engineering BIM Information Completeness Review System

To transform the aforementioned theoretical methods into operational, verifiable, practical tools, this study designed and built the As-built Architectural Engineering BIM Information Completeness Review System. The system aims to automate the entire workflow from As-built BIM import, information extraction and semantic conversion, ontology-based rule reasoning, to result output, providing an integrated solution for Information Completeness Review at the as-built delivery stage. This section first explains the system’s review principles and logical architecture, then describes in detail the design and implementation of the system framework and its functional modules, and finally validates the system’s feasibility and effectiveness through a practical case.

3.4.1. Principles of As-Built BIM Information Completeness Review

The core of the review lies in establishing an integrated theoretical system of Knowledge Support—Data Processing—Reasoning Judgment. Through systematic methodological design, comprehensive and precise verification of As-built BIM information is achieved. Its essence combines standardized review knowledge with normalized data processing workflows to construct a logical pathway from raw model data to completeness conclusions, ensuring the scientific nature of the review process and the reliability of results.

(1)

Mechanism for Data and Knowledge Integration

The deep integration of data and knowledge is the core link of the review principle. Its core logic, through standardized process design, achieves a precise connection between structured data and the ontological knowledge base, forming an integration chain of Data Loading—Semantic Enhancement—Knowledge Association, as illustrated in Figure 11.

First, standardized processing of structured data is the prerequisite for integration. Raw data extracted from the As-built BIM undergoes preprocessing such as format validation, null handling, and attribute name unification before storage in the structured database. This ensures data format consistency with the property specifications defined in the ontology, eliminating integration barriers caused by data heterogeneity. Second, semantic mapping is the key bridge for integration. Through preset mapping rules, one-to-one correspondences are established between database tables/fields/records and ontology classes/properties/instances, realizing the transformation of structured data into ontological instances and endowing data with semantic attributes. Finally, knowledge association building achieves deep binding between data and knowledge. Based on class hierarchies and object properties defined in the ontological knowledge base, semantic associations among instances are automatically established, such as the ownership relationship between a component and its project, or the linkage between a component and its corresponding acceptance documents. This integrates scattered instance data into the overall knowledge system. Through this integration mechanism, data is no longer isolated information units but becomes knowledge carriers with semantic logic, laying the foundation for subsequent rule matching and reasoning.

(2)

Logic for Completeness Judgment Based on Knowledge Reasoning

The core of completeness judgment is to perform automated judgment on information completeness through rule matching and logical reasoning based on the semantically enriched integrated data. The logical flow follows the closed loop of instance loading—rule matching—logical reasoning—conclusion generation.

First, the Reasoning Engine loads the integrated ontology instances and the preset review rule set, constructing the semantic environment required for reasoning. The review rule set covers multi-dimensional review requirements, including core information existence, semantic association integrity, format specification compliance, and hierarchical coverage comprehensiveness. Each rule corresponds to clear knowledge logic and a standard basis. Second, rule matching is executed according to a preset priority order. The Reasoning Engine validates each ontology instance against the rules one by one, identifying non-compliance, missing information, or anomaly issues.

During matching, logical reasoning and conflict resolution are performed by combining axiom constraints and class hierarchy relationships from the ontological knowledge base, ensuring consistency and accuracy of judgment results. For example, if a component instance is not associated with any acceptance documents, through the axiom constraint in the ontology that structural components must be associated with acceptance documents and the corresponding rule match, the reasoning concludes Semantic Association Missing. Finally, all matching results are classified and organized to generate completeness judgment conclusions containing information such as problem type, associated instance, triggering rule, and standard basis, providing precise guidance for subsequent rectification.

3.4.2. System Framework

Based on the above principles, this study designed and implemented the As-built Architectural Engineering BIM Information Completeness Review System. The system adopts a modular design, user-operation oriented, with data processing and reasoning at its core. Its overall framework is shown in Figure 12.

(1)

User Operation End

As the direct interaction interface between the system and the user, it carries core functions for initiating operations, selecting configurations, and providing decision feedback. Corresponding modules include CSV File Import, Delivery Requirement Selection, and Review Standard Selection. The CSV File Import module supports uploading structured data files exported by the extraction add-in, containing core information like project, components, parameters, and acceptance documents. The Delivery Requirement Selection module provides options for information depth at the as-built delivery stage, directly linked to the ontology information dimensions defined earlier, ensuring the review scope matches project delivery needs. The Review Standard Selection module has built-in BIM delivery standards from multiple regions and industries; users can select as needed, and the system automatically associates the corresponding ontological knowledge base and Review Rule Base. The Permission Management module supports role-based access control, ensuring compliant data access and review decisions. The Review Result Export module provides functionality to export review reports, enabling visual management of results. The Save Operation Information module automatically records user actions like standard selection, data import, and decision results, forming a traceable operation log for process auditing. The user login and operation interfaces are shown in Figure 13.

(2)

Business Logic End

This is the central nervous system of the system, receiving instructions and data from the User Operation End, calling support resources from the Data Resource End, and completing the core processing for automated review. It contains the Data Storage Module, Semantic Conversion Module, Ontology Knowledge Base Module, and Reasoning Engine Module.

The Data Storage Module receives CSV files uploaded from the User Operation End, performs data cleaning, format validation, and batch storage according to the designed database schema, building a standardized, structured data model for As-built BIM, providing a stable data source for subsequent semantic conversion.

The Semantic Conversion Module reads structured data from the Data Storage Module and, based on the defined Database-Ontology Mapping rules, converts relational data into OWL instances conforming to the As-built BIM Delivery Review Ontology, automatically establishing semantic associations among instances, achieving the semantic leap from data to knowledge.

The Ontology Knowledge Base Module loads the As-built BIM Delivery Review Ontology file constructed earlier, providing the unified framework of classes, properties, and semantic constraints for semantic conversion and the Reasoning Engine, serving as the knowledge benchmark for review logic.

The Reasoning Engine Module loads the SWRL Review Rule Base defined earlier, receives OWL instances generated by the Semantic Conversion Module, performs rule matching and logical reasoning through the Drools inference engine, automatically identifies issues like missing information and broken associations, and outputs preliminary reasoning conclusions.

(3)

Data Resource End

This is the foundational support layer for system operation, storing core data and knowledge resources required for review. Corresponding modules include the As-built BIM Library, Ontology Knowledge Base, and Review Rule Base. The As-built BIM Library stores user-uploaded CSV files and project data structured by the Data Storage Module, serving as the raw data carrier for review. The Ontology Knowledge Base stores the multi-version As-built BIM Delivery Review Ontology, supporting dynamic invocation based on project type and delivery standard. The Review Rule Base stores the SWRL review rule set corresponding to the ontology, covering multi-dimensional review logic like core information existence and semantic association integrity, consistent with the earlier rule system.

(4)

Result Presentation End

This layer presents the review outcomes in a user-readable professional format. It first organizes reasoning results, classifying and aggregating the preliminary conclusions from the Reasoning Engine, statistics problem distribution by engineering category, component type, and problem severity to form a structured result dataset. It also generates warning prompts for critical issues like core information missing or key documents unlinked, helping users quickly locate major rectification items. Finally, it integrates statistical results with detailed problem lists, supporting export in Excel format.

3.4.3. Design of Core System Modules

The system’s functional modules cover user interaction, data processing, knowledge support, and result presentation. However, the Business Logic End constitutes the core component of the entire review system, with other modules revolving around it. Among these, the Data Storage, Semantic Conversion, Ontology Knowledge Base, and Reasoning Engine modules run through the entire workflow of raw data reception, semantic conversion, and knowledge-driven reasoning, forming the technical hub for realizing the As-built BIM Information Completeness Review. Therefore, this section focuses on elaborating the design and implementation of these four core modules.

(1)

Data Storage Module

This module is the data center of the system. Its core functions include receiving, validating, storing, and managing structured data, providing a stable and reliable data source for subsequent semantic conversion and rule reasoning. The module needs to be compatible with CSV format data extracted from BIMs while establishing efficient data interaction mechanisms with the structured database, ensuring data integrity, consistency, and traceability.

Implementation follows the development workflow of data validation, structured storage, and data indexing. First, a data format validation interface is developed to automatically validate field types, attribute names, data formats, etc., in CSV files, supporting the identification of illegal characters, format errors, and generating validation reports for user correction. Validated data is then stored in corresponding database tables according to preset data mapping relationships, ensuring normative data storage. Second, a structured storage system is built using MySQL, designing reasonable table structures and field relationships, establishing primary and foreign key constraints for core identifiers like project_id and component_id to ensure relational integrity. Data read/write optimization mechanisms are also developed, using connection pooling to enhance database access efficiency and supporting fast storage and query of large-scale data. Finally, a data indexing mechanism is established, creating indexes for commonly queried fields to optimize query performance, ensuring the Semantic Conversion Module can quickly retrieve required data.

(2)

Semantic Conversion Module

This module is the key hub connecting data storage and rule reasoning. Its core function is to convert data from the structured database into semantically associated OWL format ontology instances, achieving semantic enhancement of data and providing a semantic data foundation for rule matching. The module must ensure the accuracy of the conversion process, making the class membership, property assignment, and relationship establishment of ontology instances consistent with the preset ontological knowledge base.

The implementation workflow includes Mapping Rule Configuration, Data Reading and Conversion, Semantic Association Building, and Conversion Result Validation. First, based on the preset ontology framework, a mapping rule base is configured, establishing Table-to-Class, Field-to-Property, and Record-to-Instance correspondences, clearly defining the relationships between database tables/fields and ontology classes/properties. The rule base supports addition, editing, and export of rules, ensuring flexibility and maintainability. Second, data reading interfaces are developed to read structured data from the database by category. Based on the mapping rule base, data type conversion and property assignment are performed automatically, transforming each database record into a corresponding ontology instance. During conversion, semantic associations between instances are simultaneously built. Based on foreign key relationships between database tables, corresponding object property relationships in the ontology are automatically added. Then, a Conversion Result Validation mechanism is developed. The generated OWL file is validated for semantic consistency through an ontology reasoner, checking for errors like incorrect instance class membership, anomalous property assignment, or missing semantic associations, and generating validation logs. Validated OWL files are stored in a designated directory as ontologies-to-be-reviewed, providing input for the Reasoning Engine Module.

(3)

Ontology Knowledge Base Module

This module is the knowledge support core of the system, containing two core components: the Ontology Framework and the Review Rule Base. The Ontology Framework defines core concepts (classes), properties (data and object properties), and semantic constraints (axioms) related to As-built BIMs, building a unified knowledge semantic system. The Review Rule Base translates standards and professional expertise into executable standardized rules, providing a specific review basis for completeness judgment.

Implementation follows the development workflow of ontology construction, rule authoring, knowledge base integration, and dynamic updates. First, based on As-built BIM delivery standards and professional knowledge, the ontology framework is constructed using the Protégé tool. Core class hierarchies for Project, Component, Parameter, Acceptance Document, etc., are defined; mandatory and optional data properties for each type of instance are specified; object property associations between instances are established; necessary axiom constraints are added; and an OWL format ontology file is generated. Second, based on the ontology framework and standards, review rules are authored using SWRL, covering multi-dimensional review requirements like core information existence and semantic association integrity. Each rule clearly defines preconditions and conclusions, ensuring executability. Authored rules are organized by review dimension and standard source to build the Review Rule Base, supporting categorized retrieval and batch loading. Then, knowledge base integration interfaces are developed to integrate the ontology file and rule base, supporting loading into the Reasoning Engine to provide knowledge support for rule matching. Finally, a dynamic update mechanism is designed, allowing users to extend ontology classes/properties and add/modify review rules based on new standards or project needs, enhancing the knowledge base’s generality and adaptability.

(4)

Reasoning Engine Module

This module is the decision-making core of the system. Its core function is to load the ontology-to-be-reviewed and the Review Rule Base, perform automated rule matching and logical reasoning to identify completeness issues in the As-built BIM information, and generate structured review results. The module must ensure the efficiency of the reasoning process and the accuracy of results, supporting rapid processing of large-scale ontology instances and precise identification of multi-dimensional problems.

The implementation workflow includes knowledge base and instance loading, rule matching, logical reasoning, and result generation, as well as storage. First, loading interfaces are developed to support batch loading of the ontology framework, Review Rule Base from the knowledge base, and the ontology-to-be-reviewed from the Semantic Conversion Module into the Reasoning Engine. The OWL API is used to parse class membership, property information, and semantic associations of ontology instances, building a semantic network in memory. Second, rule-matching algorithms are designed. Rule matching is performed on instances in the semantic network rule by rule, following a priority order like Mandatory Standard Rules, Core Information Rules, Association and Format Rules. Parallel computing techniques are employed to support simultaneous matching of multiple rules and instances, improving reasoning efficiency. During matching, a conflict resolution mechanism is developed to resolve logical conflicts in rule matching based on ontology axioms, ensuring reasoning consistency. Then, based on rule matching results, logical reasoning is performed, adding associated information for each problem, including problem instance ID, triggering rule ID, associated standard clause, problem severity, etc., generating structured review results. Finally, result storage and output interfaces are developed, storing review results categorized in the database, supporting fast query and statistical analysis. Review results are also formatted to provide standardized result data for the Presentation Layer, ensuring users can intuitively view and export results.

The overall system runtime workflow is illustrated in Figure 14.

4. Case Study

To validate the feasibility and effectiveness of the proposed ontology-based method and related tools/systems for As-built BIM Information Completeness Review, the As-built BIM of a university teaching building project was selected as an empirical case. The validation strictly follows the proposed full workflow of information extraction, semantic conversion, rule reasoning, and result output, aiming to demonstrate that the theoretical method can be implemented as an operational review practice and effectively identify information completeness issues in the as-built model.

4.1. Overview of the BIM

The As-built BIM for this case study was created in Autodesk Revit 2022, with geometric precision at G3 level and information depth at N4. It contains a total of 38,620 components across eight engineering categories. The model has undergone extension, entry, and extraction of project-level and component-level as-built delivery information using the developed Revit data extraction add-in. The project is a multi-story public building with a reinforced concrete frame structure, a total floor area of 14,062 m², covering five disciplines: architecture, structure, plumbing, HVAC, and electrical. The model has been finalized for the as-built stage according to the local delivery standard DB11/T1069-2024 [36], meeting the technical requirements set for this study. System review of this model validates the practicality and accuracy of the proposed method. The Revit model is shown in Figure 15, with core information in

Table 7. Core Information of the Empirical Project BIM.

Related Information	Content
Project Name	A Teaching Building Construction Project
Structure Type	Reinforced Concrete Frame Structure
Floor Area	14,062 m2
Number of Floors	6 Above Ground, 1 Basement
Modeling Software	Autodesk Revit 2022
Level of Development	Geometric Precision G3, Information Depth N4
Total Components	38,620
Covered Disciplines	Architecture, Structure, Plumbing, HVAC, Electrical
Applied Delivery Standard	DB11/T1069-2024

.

4.2. Import and Conversion of BIM Information

Considering system development workload, this review focused on the project’s Project-Level Delivery Information and the Component-Level Delivery Information for the Main Structure engineering category. Since the core logic for reviewing information completeness is consistent across component types, reviewing Main Structure components suffices to validate the feasibility and effectiveness of the proposed methodological system.

After preprocessing, the project’s BIM information was exported as structured CSV data files via the add-in. The project-level data includes seven categories with 34 parameters (e.g., construction description, technical-economic indicators) and is associated with 27 project-level acceptance documents. For the Main Structure category (concrete slabs, structural columns, beams, etc.), 1194 components were exported. Each has component-level information, including five categories with 20 parameters (identity, technical info, etc.), totaling 23,880 parameters, and is associated with 7164 acceptance documents. The CSV files were imported into the review system, as shown in Figure 16.

At the system frontend, review task parameters need configuration. As shown in Figure 17, the local standard DB11/T 1069-2024 was selected as the review basis; the system automatically loads the corresponding review ontology and SWRL rule base (as shown in

Table A1. SWRL rule base.

Component Type	Rule ID	Rule Description	SWRL Rule (Simplified)
Structural Column	COL-CMUI-01	Check for Concrete Strength Grade	StructuralColumn(?c) ^ hasCMUI(?c, ?cmui) ^ hasParamName(?cmui, “ConcreteStrengthGrade”) -> hasCMUIStatus(?c, “Present”)
Structural Column	COL-CADM-01	Check for Material Test Report	StructuralColumn(?c) ^ hasCADM(?c, ?cadm) ^ hasDocType(?cadm, “MaterialTestReport”) -> hasCADMStatus(?c, “Present”)
Structural Beam	BEM-CMUI-01	Check for Reinforcement Details	StructuralBeam(?c) ^ hasCMUI(?c, ?cmui) ^ hasParamName(?cmui, “ReinforcementDetails”) -> hasCMUIStatus(?c, “Present”)
Structural Beam	BEM-CADM-01	Check for Flexural Strength Test Report	StructuralBeam(?c) ^ hasCADM(?c, ?cadm) ^ hasDocType(?cadm, “FlexuralStrengthTestReport”) -> hasCADMStatus(?c, “Present”)
Concrete Slab	SLB-CMUI-01	Check for Thickness Parameter	ConcreteSlab(?c) ^ hasCMUI(?c, ?cmui) ^ hasParamName(?cmui, “Thickness”) -> hasCMUIStatus(?c, “Present”)
Concrete Slab	SLB-CADM-01	Check for Compressive Strength Test Report	ConcreteSlab(?c) ^ hasCADM(?c, ?cadm) ^ hasDocType(?cadm, “CompressiveStrengthTestReport”) -> hasCADMStatus(?c, “Present”)
Structural Stair	STR-CMUI-01	Check for Tread Width	StructuralStair(?c) ^ hasCMUI(?c, ?cmui) ^ hasParamName(?cmui, “TreadWidth”) -> hasCMUIStatus(?c, “Present”)
Project Level	PRJ-PMUI-01	Check for Project Name	Project(?p) ^ hasPMUI(?p, ?pmui) ^ hasParamName(?pmui, “ProjectName”) -> hasPMUIStatus(?p, “Present”)
Project Level	PRJ-PADM-01	Check for As-built Drawing Set	Project(?p) ^ hasPADM(?p, ?padm) ^ hasDocType(?padm, “AsBuiltDrawingSet”) -> hasPADMStatus(?p, “Present”)

Note: The actual SWRL syntax includes additional axioms for class hierarchies and property chains. These simplified representations capture the essential logic for completeness checking. The complete rule set (186 rules) is available from the corresponding author upon reasonable request.

).

Simultaneously, as shown in Figure 18, delivery requirements are set based on the project: geometric precision G3, information depth N4, with the review scope covering Project-Level Delivery Information and Main Structure Component Delivery Information. After parameter configuration, the review task is initiated. The system backend first automatically validates the compatibility among the review ontology, the rule base, and the data to be reviewed. After confirming logical correctness, it proceeds to the automated analysis process.

4.3. Information Completeness Review and Result Output

Performance testing was conducted on a workstation with an Intel Core i9-13900HX CPU, 32 GB RAM, and Windows 11 operating system. The ontology contained 47 classes, 28 object properties, 56 data properties, and 186 SWRL rules. The review process completes automatically without manual intervention, taking 19 s in total, averaging 63 component instances processed per second. The review results are shown in Figure 19. The overall information completeness compliance rate was 95.42%. Specifically, 61 Project-Level Delivery Information items were reviewed, with 58 complete and 3 missing. For the 1194 components reviewed, covering 31,044 Component-Level Delivery Information items, 29,623 were complete and 1421 were incomplete.

Classifying the identified problems provides clearer insight into the distribution of missing information, as shown in

Table 8. Statistics of review problems by category.

Engineering Category	Component Type	Problem Type	Problem Count	Proportion
Main Structure	Structural Column	Component-Level Model Unit Information Missing	622	43.77%
Main Structure	Structural Column	Component-Level Acceptance Data and Materials Missing	125	8.80%
Main Structure	Structural Beam	Component-Level Model Unit Information Missing	334	23.50%
Main Structure	Structural Beam	Component-Level Acceptance Data and Materials Missing	101	7.11%
Main Structure	Concrete Slab	Component-Level Model Unit Information Missing	157	11.05%
Main Structure	Concrete Slab	Component-Level Acceptance Data and Materials Missing	53	3.73%
Main Structure	Structural Stair	Component-Level Model Unit Information Missing	21	1.48%
Main Structure	Structural Stair	Component-Level Acceptance Data and Materials Missing	8	0.56%

. Statistics show that Component-Level Model Unit Information Missing is the primary issue type, accounting for 79.80% of all problems, with structural columns and beams being most prominent. This reflects that entering non-geometric attributes like production and maintenance information remains a weak point in actual modeling. Component-Level Acceptance Data and Materials Missing accounts for 19.20%, indicating that linking models with construction process documentation needs strengthening.

The system also generated a detailed component-level review result list; a partial excerpt is shown in

Table 9. Component-level delivery information review results (partial).

Component ID	Eng. Category	Component Type	Family Name	Review Result	Problem Type	Missing Information
339134	Main Structure	Structural Column	Concrete-Rectangular-Column 500 × 500 mm	Information Incomplete	Component-Level Model Unit Information Missing	Concrete Strength Grade
342760	Main Structure	Structural Column	Concrete-Rectangular-Column 600 × 500 mm	Information Incomplete	Component-Level Acceptance Data and Materials Missing	Construction Method Statement
344045	Main Structure	Structural Beam	Concrete-Rectangular-Beam 600 × 500 mm	Information Incomplete	Component-Level Model Unit Information Missing	Product Execution Standard
344023	Main Structure	Structural Beam	Concrete-Rectangular-Beam 600 × 500 mm	Information Incomplete	Component-Level Acceptance Data and Materials Missing	Test Report for Flexural Strength of Concrete Specimens Cured Under Same Conditions
344149	Main Structure	Concrete Slab	Concrete-Slab 200 mm thick	Information Incomplete	Component-Level Model Unit Information Missing	Maintenance Plan
344516	Main Structure	Concrete Slab	Concrete-Slab 150 mm thick	Information Incomplete	Component-Level Acceptance Data and Materials Missing	Test Report for Compressive Strength of Concrete Specimens Cured Under Same Conditions
346622	Main Structure	Structural Stair	Concrete-Slab Stair 280 mm tread width	Information Incomplete	Component-Level Model Unit Information Missing	Inspection Point Location Information

. The list precisely indicates the specific missing information items for each incomplete component, such as Concrete Strength Grade, Construction Method Statement, Product Execution Standard, etc., providing clear, actionable guidance for targeted rectification by the project team.

This case study demonstrates the full workflow from raw BIM import, automated information extraction and conversion, ontology rule-based intelligent reasoning, to structured report generation. The system reviewed tens of thousands of information points within a short time and precisely located various types of missing information, validating the feasibility, efficiency, and practicality of the proposed methodological system and prototype. The review results not only reflect common completeness issues in current As-built BIMs but also provide an effective technical tool for rapid quality assessment and targeted improvement, significantly outperforming traditional, inefficient manual review modes.

4.4. Validation of Review Results

To verify the accuracy of the system’s output, manual validation was performed by the authors on the team who have professional experience in BIM inspection and delivery review. A stratified random sample of 500 components (approximately 42% of the reviewed components) was selected, covering all problem types identified by the system. The experts manually checked the presence/absence of the required information items in the original Revit model and associated documentation.

The validation results showed the following: Precision: 98.2% of the system-identified missing items were confirmed as truly missing by the experts. Recall: 96.7% of actually missing items (as identified by experts) were correctly detected by the system. Inter-reviewer agreement (Fleiss’ Kappa): 0.89, indicating excellent agreement among the three experts.

The minor discrepancies (1.8% false positives) were primarily due to ambiguities in the delivery standard interpretation, where certain attributes could be represented in alternative ways not captured by the current rule set. This validation confirms that the system’s 95.42% completeness compliance rate accurately reflects the model’s information status relative to the standard requirements.

5. Discussion

5.1. Research Background and Core Objectives

The core value of Building Information Modeling (BIM) at the as-built delivery stage lies in transforming construction outcomes into operational assets, with information completeness being the key prerequisite. During the current digital transformation in construction, As-built BIMs commonly suffer from issues like geometrically complete but informationally deficient models and disconnection between models and documentation. Existing review research predominantly focuses on design-phase compliance checking, neglecting information completeness needs at the as-built stage, while manual review is inefficient and error-prone. This study aims to fill this gap by proposing an ontology-based automated review method and system. Core objectives include: (1) constructing a review knowledge system covering project and component levels; (2) opening up the data flow channel from BIMs to the review knowledge base; (3) realizing a fully automated workflow for Information Completeness Review.

5.2. Core Research Findings and Innovations

5.2.1. Constructed a Semantic Review Knowledge System, Breaking Through Traditional Review Limitations

This study is the first to comprehensively apply ontology technology to Information Completeness Review of As-built BIMs, constructing an ontological framework encompassing seven major classes with multiple properties and instances. It clarifies review dimensions and semantic associations for project-level and component-level delivery information. Unlike existing research focusing on design compliance checking, this study establishes the review core as the as-built information model equals the building information model plus acceptance documentation. By formalizing review knowledge through SWRL rules, it addresses the issue of scattered, non-computer-executable knowledge in traditional review. For instance, by defining object properties like Has_CADM and instance rules like structural column must include Concrete Strength Grade, the review logic extends from geometric compliance to information completeness plus semantic association. Compared to the semantic rule-checking framework proposed by Pauwels et al., this approach is more aligned with the practical needs of as-built delivery, covering information dimensions unique to this stage, such as construction changes, product warranties, and operational attributes.

5.2.2. Proposed Full-Chain Automated Data Processing Technology, Overcoming Data Flow Bottlenecks

Addressing industry pain points like fragmented As-built BIM information extraction, heterogeneous storage, and difficult semantic conversion, this study proposes a full-chain technical solution: Revit add-in extraction—database storage—semantic mapping conversion. The developed Revit secondary development add-in achieves batch, standardized extraction of project-level and component-level information, solving the issue of Revit’s native functions struggling to integrate multi-source data. The designed MySQL database employs a Three-Level Core Architecture plus EAV model, balancing efficient storage of structured data with flexible adaptation to heterogeneous component parameters, superior to traditional single-table structure designs. The innovative Database-Ontology Mapping framework achieves automated conversion of relational data into semantic instances, overcoming interoperability challenges of heterogeneous data. Compared to the collaborative design data model proposed by Wei et al., this solution is more focused on the as-built delivery scenario, realizing seamless transformation from data to knowledge, providing high-quality data sources for automated review.

5.2.3. Developed an Integrated Review System, Achieving Dual Improvement in Review Efficiency and Accuracy

The integrated review system built in this study automates the entire workflow from data import to result output, performing rule matching and logical reasoning via the Drools inference engine. The case validation shows the system reviewed 1194 Main Structure components and 31,044 information items within 19 s, significantly outperforming traditional manual review. The system not only precisely locates missing information but also generates structured review reports, providing a clear basis for rectification. Compared to the fire code checking framework proposed by Guo et al., this system has more comprehensive review dimensions, is more focused on as-built delivery, and possesses stronger extensibility.

5.3. Research Advantages

(1)

Structured and Semantic Knowledge Representation: Applying ontology technology endows review knowledge with clear conceptual hierarchies and semantic associations, avoiding logical confusion in traditional rule bases and supporting flexible extension and reuse of review rules.

(2)

Automated and Standardized Data Processing: Full-chain automation from Revit data extraction to semantic conversion reduces errors from manual intervention, ensuring data consistency and integrity.

(3)

Precise and Visualized Review Results: The system accurately identifies specific types of missing information and associated components. The generated statistical reports and detailed lists facilitate quick problem localization and rectification.

5.4. Research Limitations

(1)

Dependence on Manual Rule Configuration: Current review rules require manual authoring and configuration based on standards. For massive, dynamically updated industry standards, the efficiency of building and maintaining the rule base needs improvement.

(2)

Limitations in Review Dimensions: Primarily focuses on the Completeness Review regarding the presence or absence of information, not yet addressing the reasonableness and accuracy of information content.

(3)

Insufficient System Integration: The current system is a standalone tool, not yet deeply integrated with full lifecycle management platforms for design, construction, and operation. Review results are difficult to directly feed back into the model correction and process control.

(4)

Limited Capability in Processing Unstructured Documents: Document links in the current system are created through manual file path associations in the Revit model or via naming conventions during data extraction. The system uses metadata such as document title, file type, and associated component ID to establish these links. However, only association review (whether a document link exists) is implemented, not semantic analysis of document content or key information extraction. Errors such as incorrect document content, outdated versions, or mismatched specifications remain undetectable under the current approach.

5.5. Implications for the Industry

The proposed method and system provide important technical support for digital delivery in the AEC industry:

(1)

Enhancing As-built BIM Quality: Automated review ensures models contain full-process information required for operation and CIM integration, preventing as-built models from becoming mere formal deliverables, and extending physical-to-model consistency from geometry to information.

(2)

Reducing Review Costs and Risks: Significantly improves review efficiency, reduces omissions and errors in manual review, and provides a high-quality data foundation for archive handover, operation management, and urban integration.

(3)

Promoting Implementation of Standards and Codes: Transforms abstract BIM delivery standards into executable review rules, facilitating standardized application and dynamic updates of standards, aiding the standardized development of industry digital transformation.

(4)

Extensible Technical Architecture: The system architecture supports adaptation to different project types and delivery standards by extending ontology classes, properties, and rules, though empirical validation across multiple standards remains for future work.

5.6. Future Research Directions

(1)

Intelligent Review Paradigm Integrating Artificial Intelligence and Knowledge Graphs: Future work should explore utilizing Large Language Models (LLMs) to automatically interpret industry standard texts, extract review rules, and update the rule base, reducing manual rule authoring effort. Constructing a hybrid knowledge base of ontology—knowledge graph—vector database could enhance semantic retrieval and rule matching capabilities, particularly for unstructured documents.

(2)

Expanding Review Dimensions and Context-Adaptive Capabilities: Incorporating machine learning algorithms to add review of information content reasonableness and accuracy, moving beyond simple presence/absence checking. Developing context-adaptive mechanisms to dynamically adjust review focus and rule thresholds based on project type, building function, and operational needs would enable personalized, risk-based review.

(3)

Enhancing Unstructured Document Processing: Developing NLP-based semantic analysis capabilities to extract and validate key information from acceptance reports, product manuals, and other unstructured documents. This would enable verification of document content consistency with model requirements and detection of errors beyond simple association.

(4)

Promoting Full Lifecycle Integrated Application: Integrating the review system with design platforms, construction management systems, facility management (FM) platforms, and City Information Model (CIM) platforms to achieve real-time feedback of review results and automated model correction. This would enable a closed-loop information transfer chain from design to construction to as-built to operation.

(5)

Broadening Empirical Validation: Conducting extensive case studies across multiple project types (residential, commercial, healthcare, infrastructure), all engineering disciplines, and various delivery standards to comprehensively validate the system’s generalizability and identify context-specific adaptations.

6. Conclusions

Addressing the core need for Information Completeness Review of as-built architectural engineering BIMs, this study systematically conducted theoretical, methodological, and technical research. The main conclusions are as follows.

(1)

Constructed an ontology-based knowledge system and reasoning mechanism for As-built BIM Information Completeness Review. Established the ontological framework of As-built BIM Model—Project Information—Model Components—Delivery Information—Review Evaluation, defined inter-class semantic associations and data properties, and formalized the decision logic where any missing mandatory field leads to component-level incompleteness and ultimately overall model incompleteness. Through SWRL rule bases and the Drools inference engine, automated judgment of issues like missing information and broken associations was achieved. This breaks through the limitation of traditional review focusing on design compliance, providing theoretical and methodological support for Information Completeness Review at the as-built stage.

(2)

Proposed a full-process automated data processing technical pathway. Developed a Revit data extraction add-in for batch extraction of project-level and component-level information; designed a three-level architecture MySQL database adapted to massive heterogeneous data storage; constructed a Database-Ontology Mapping framework, completing automated conversion of structured data into semantic instances and overcoming data flow bottlenecks from BIMs to the review knowledge base.

(3)

Developed and validated an integrated review system as a proof of concept. Constructed a four-layer system framework of User Operation–Business Logic–Data Resource–Result Presentation, realizing full-process automation from data import, semantic conversion, rule reasoning, to result output. Case validation on a teaching building project’s Main Structure category demonstrated that the system can efficiently identify information completeness problems, with a 95.42% completeness compliance rate against the DB11/T1069-2024 standard. Manual validation confirmed high precision (98.2%) and recall (96.7%) for missing information detection, significantly improving review efficiency compared to manual methods. It provides a feasible technical tool for quality control of As-built BIMs.

However, as a proof of concept, this study has several limitations that should be acknowledged. First, the current review rules require manual authoring and configuration, which is labor-intensive and may introduce inconsistencies when adapting to new standards. Second, the review is restricted to the presence/absence checking of information items and does not yet address the reasonableness, consistency, or accuracy of information content. Third, the system operates as a standalone tool with weak integration into full lifecycle management platforms, limiting real-time feedback and automated model correction. Fourth, for unstructured documents such as acceptance reports and product manuals, only document association (whether a link exists) is checked, not semantic analysis of document content; errors such as incorrect content, outdated versions, or mismatched specifications remain undetectable.

The theories, methods, and systems constructed in this study address the industry challenge of insufficient automation in the As-built BIM Information Completeness Review. They provide crucial support for digital delivery in the AEC industry, promoting the essential transformation of As-built BIMs from geometric models to digital assets. As a proof of concept, this work establishes a foundation for future research. Subsequent efforts integrating artificial intelligence and knowledge graphs to automate rule generation, expanding review dimensions beyond presence/absence checking, enhancing unstructured document processing, and enabling full lifecycle platform integration will further improve the system’s intelligence level, practical value, and generalizability.