Method and system for checking compliance of BIM (Building Information Model)

Through NLP technology, key information is extracted from building specifications and mapped to ifcOWL ontology, SHACL constraints are built, and data extraction and alignment problems in automatic compliance inspection of BIM model are solved, achieving efficient and detailed compliance verification.

CN120277904APending Publication Date: 2025-07-08SHANDONG NORMAL UNIV
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510426046.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-07
Publication Date
2025-07-08

AI Technical Summary

Technical Problem

The existing automatic compliance inspection system of BIM in building information model lacks flexibility and scalability in data extraction and alignment technology, and the uneven building code data quality has led to the limited application of automated compliance inspection tools.

Method used

Natural language processing (NLP) technology is used to automatically extract key information from building specification texts and map it to ifcOWL ontology to build SHACL constraints, and verify the compliance of the BIM model through SPARQL query.

Benefits of technology

It realizes efficient and detailed compliance inspection of the BIM model, improves the accuracy and flexibility of automated inspections, and generates detailed verification reports.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120277904A_ABST
    Figure CN120277904A_ABST
Patent Text Reader

Abstract

The invention discloses a compliance inspection method and system for a BIM (Building Information Model), and the method comprises the steps: obtaining the text data of laws and regulations in the building industry; key information is identified and extracted from the building industry regulation specification text data; the key information comprises entities, attributes, attribute values and rules; establishing a mapping relationship between the key information and the ifcOWL ontology, and mapping the key information to the ifcOWL ontology according to the mapping relationship; on the basis of the mapped ifcOWL ontology, an SHACL constraint is constructed; obtaining a to-be-checked building information model BIM; and the BIM to be checked is converted into an ifcOWL instance diagram, the ifcOWL instance diagram is input into the SHACL constraint, and a compliance check report of the BIM is generated.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of building information technology, and particularly to a compliance checking method and system for Building Information Modeling (BIM). Background Art

[0002] Under the rapid development trend of the construction industry, modern buildings exhibit the remarkable characteristics of diversity, complexity, and large scale, which pose severe challenges to traditional manual compliance checking methods. The traditional method relying on manual review is not only inefficient, consuming a large amount of human and time costs, but also difficult to ensure the consistency and accuracy of inspection results due to the subjective cognitive differences of reviewers. At the same time, building codes are constantly updated, and the timely mastery and application of compliance knowledge have become a major problem for industry practitioners. With the rapid development of Building Information Modeling (BIM) technology and artificial intelligence, the building design and construction processes are gradually transforming towards digitalization and intelligentization. In this context, researchers and practitioners in the architecture, engineering, and construction industries are actively exploring ways to combine BIM with artificial intelligence and semantic web technology, hoping to improve the efficiency and accuracy of compliance checking, and enhance the effectiveness of BIM models in automated building code checking by leveraging the powerful functions of the semantic web in data integration, query processing, and complex logical reasoning.

[0003] Although Automated Compliance Checking (ACC) shows broad application prospects, it encounters many obstacles in the actual implementation process. On the one hand, the information extraction and alignment technologies of most ACC systems are still based on manual or semi-automatic processes, resulting in the lack of flexibility, scalability, and high automation of the systems. On the other hand, the data sets collected and created during the building planning stage, such as data related to building codes and regulations, are not mature, complex, and comprehensive enough. And highly efficient and accurate automated compliance checking tools highly rely on reliable and complete data sets. The problems of uneven data quality and data islands existing in the current construction industry seriously restrict the widespread application of ACC.

[0004] Semantic web technology is a concept proposed by the World Wide Web Consortium (W3C) aiming to enhance the semantic level of Internet data, enabling machines to understand and process network information more effectively. This technology has greatly promoted the effective integration, linking, and sharing of knowledge between different systems and applications. In addition, it provides powerful tools for integrating data from multiple heterogeneous sources and supports complex cross-domain search queries and logical reasoning. The semantic web is formally modeled through ontologies, which usually use the Web Ontology Language (OWL) to define concepts, properties, and relationships. Therefore, using ontologies to enhance the semantic clarity of Industry Foundation Classes (IFC) is regarded as an effective means to enhance IFC interoperability. The BuildingSMART organization has released the widely used IFC ontology, namely ifcOWL, which is based on the research results of Pauwels et al. and summarizes the conversion patterns from EXPRESS to OWL.

[0005] In recent years, many studies have attempted to use the ifcOWL ontology to achieve automatic compliance checking of BIM models. Li et al. proposed a method for constructing a railway specification ontology based on ifcOWL, using the Simple Protocol and RDF Query Language (SPARQL) to query and the Semantic Web Rule Language (SWRL) for reasoning to verify the compliance of BIM model information; Zhong et al. described building knowledge through ontologies, converted regulatory clauses into SPARQL queries to achieve monitoring and compliance checking in the BIM environment; Bus et al. proposed a semantic topology query method, converting regulatory texts into SPARQL queries to achieve compliance checking of French building regulations; Peng et al. developed a compliance checking system combining BIM and knowledge graphs, using Natural Language Processing (NLP) to convert construction specifications into knowledge graphs, and implementing rule mapping and checking through SPARQL queries and external technologies; Zheng et al. proposed an improved ACC knowledge framework, using ifcOWL to construct a fire protection ontology, improving the rule interpretation process and generating SPARQL queries; Jiang et al. proposed a method for checking building code compliance combining BIM and ontologies, using SPARQL to retrieve results; Guo et al. used NLP to extract rule terms and their logic, mapped them to the ifcOWL ontology and automatically generated SPARQL queries.

[0006] This type of research converts IFC files into ifcOWL instance graphs, stores and represents BIM data in triple form, and manages BIM data with the help of semantic Web-related technologies and tools. The ACC system built based on the ifcOWL ontology can utilize semantic web technologies to achieve efficient retrieval and rule reasoning of building data, and automatically identify areas in the BIM model that do not conform to building codes. In this process, SPARQL and SWRL play key roles. SPARQL performs complex queries on the ifcOWL instance graph to determine whether design elements meet specific code requirements; SWRL, with the help of predefined ontologies and rules, deeply analyzes and reasons about building design data through a logical reasoner. However, SPARQL is only used to query Resource Description Framework (RDF) data, lacks data structure and integrity verification functions, cannot provide detailed error reports, and is not conducive to quickly locating and solving problems; SWRL, as an extension of the Web Ontology Language Description Logic Profile (OWL-DL), although enhancing the ontology expression ability, reduces the ontology decidability. In large-scale application scenarios, the increase in the number of rules will cause the reasoning process to be extremely slow, affecting the user experience, and the reasoner depends on the detailed and precise definition of the canonical ontology, and the construction process is complex, time-consuming and error-prone.

[0007] In contrast, SHACL is specifically designed for RDF data model validation, has a comprehensive constraint mechanism, can accurately verify complex requirements of building codes, and the verification results can provide detailed error reports, clearly indicating the constraints violated and the error locations, with obvious advantages in data verification compared to SPARQL and SWRL. Since SHACL became an official W3C recommendation in 2017, more and more researchers have started to introduce SHACL into the AEC field for BIM model validation, providing strong support for construction data quality and compliance. Hagedorn proposed a method using SHACL to validate building data information containers and demonstrated its effectiveness and performance advantages through a case study; Senthilvel proposed a method based on visual programming to validate linked construction data, supporting ontologies and use cases in the AEC field through SHACL; Nuyts proposed a method combining RASE annotation and SHACL technology to achieve automated compliance checking of BIM models; Kovacs et al. proposed a BIM quality control ecosystem based on requirement-linked data, using SHACL for compliance checking; Bernert et al. used "protocol analysis" technology to analyze regulatory documents, converted them into ontology models, defined reasoning rules and created SHACL shapes to achieve automated compliance checking; Kucukavci et al. developed a set of SHACL shapes to validate rules for HVAC components in BIM models.

[0008] Although the current building code compliance inspection methods have improved the inspection accuracy and efficiency to a certain extent, there is still much room for improvement in terms of automation and intelligent processing. There are a large number of professional terms, complex logical relationships, and diverse expressions in the regulatory texts, which pose great challenges to compliance verification. Currently, many studies still rely on manual or semi-automatic techniques to extract information from building codes, resulting in low efficiency and being unable to handle the diversity and complexity of regulatory texts. Summary of the Invention

[0009] To address the deficiencies of the existing technology, the present invention provides a compliance inspection method and system for Building Information Modeling (BIM); to break through these limitations and enhance the complexity of automated compliance inspection, it is urgent to study the integration of Natural Language Processing (NLP) and Shape Constraint Language (SHACL). By using NLP algorithms to analyze building code texts, in-depth understanding and parsing of semantic content can be achieved, promoting the automatic extraction of key information, converting it into SHACL constraint conditions, and then effectively conducting compliance reviews on BIM models to ensure that building design and construction strictly comply with building codes.

[0010] On the one hand, a compliance inspection method for Building Information Modeling (BIM) is provided, including:

[0011] Obtain building industry code and specification text data; identify and extract key information from the building industry code and specification text data; the key information includes: entities, attributes, attribute values, and rules;

[0012] Establish a mapping relationship between the key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship;

[0013] Based on the mapped ifcOWL ontology, construct SHACL constraints;

[0014] Obtain the Building Information Modeling (BIM) to be inspected; convert the BIM to be inspected into an ifcOWL instance graph, input the ifcOWL instance graph into the SHACL constraints, and generate a compliance inspection report for the BIM.

[0015] On the other hand, a compliance inspection system for Building Information Modeling (BIM) is provided, including:

[0016] An acquisition module, which is configured to: obtain building industry code and specification text data; identify and extract key information from the building industry code and specification text data; the key information includes: entities, attributes, attribute values, and rules;

[0017] A mapping module, which is configured to: establish a mapping relationship between the key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship;

[0018] A constraint construction module, configured to: construct SHACL constraints based on the mapped ifcOWL ontology;

[0019] A report generation module, configured to: obtain a building information model (BIM) to be inspected; convert the BIM to be inspected into an ifcOWL instance graph, input the ifcOWL instance graph into the SHACL constraints, and generate a compliance inspection report for the BIM.

[0020] In another aspect, an electronic device is also provided, including:

[0021] A memory for non-temporarily storing computer-readable instructions; and

[0022] A processor for running the computer-readable instructions,

[0023] wherein, when the computer-readable instructions are run by the processor, the method described in the first aspect above is executed.

[0024] In another aspect, a storage medium is also provided, non-temporarily storing computer-readable instructions, wherein when the non-temporary computer-readable instructions are executed by a computer, the method described in the first aspect is executed.

[0025] In another aspect, a computer program product is also provided, including a computer program, where the computer program is used to implement the method described in the first aspect above when running on one or more processors.

[0026] The above technical solutions have the following advantages or beneficial effects:

[0027] The present invention proposes an innovative framework based on Natural Language Processing (NLP) and Shapes Constraint Language (SHACL) technologies, and realizes the automatic compliance verification of building codes through the following steps: accurately identifying and extracting entities, attributes, attribute values, and other key information from text data; mapping the key information to the ifcOWL ontology; constructing SHACL constraints based on the Simple Protocol and RDF Query Language (SPARQL), and further applying them to the ifcOWL instance graph to perform compliance verification. The present invention can automatically extract key information from building codes and convert it into SHACL constraints through the Simple Protocol and RDF Query Language SPARQL query for the compliance verification of BIM models. It can not only generate detailed verification reports, but also significantly improve the flexibility and automation level of existing methods, providing a brand-new framework for the research and development of automated compliance inspection tools in the construction industry.

[0028] Using technologies such as NLP, SHACL, and the Simple Protocol and SPARQL, key information is automatically extracted from building codes and converted into SHACL constraints to achieve the compliance verification of BIM models, improving the accuracy and efficiency of automated compliance inspection in the construction industry. Brief Description of the Drawings

[0029] The accompanying drawings forming a part of the present invention are used to provide a further understanding of the present invention. The schematic embodiments and descriptions thereof of the present invention are used to explain the present invention and do not constitute an improper limitation of the present invention.

[0030] Figure 1 is the constructed compliance inspection framework. Detailed Description of the Embodiments

[0031] It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention belongs.

[0032] Embodiment 1

[0033] This embodiment provides a method for compliance inspection of Building Information Modeling (BIM);

[0034] As Figure 1 shown, the method for compliance inspection of Building Information Modeling (BIM) includes:

[0035] S101: Obtain the text data of building industry regulations and specifications; identify and extract key information from the text data of building industry regulations and specifications; the key information includes: entities, attributes, attribute values, and rules.

[0036] S102: Establish a mapping relationship between the key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship.

[0037] S103: Construct SHACL constraints based on the mapped ifcOWL ontology.

[0038] S104: Obtain the building information model (BIM) to be inspected; convert the BIM to be inspected into an ifcOWL instance graph, and input the ifcOWL instance graph into the SHACL constraints to generate a compliance inspection report for the BIM.

[0039] Furthermore, for the S101: Obtain the text data of building industry regulations and specifications, the text data of building industry regulations and specifications includes:

[0040] "General Code for Building Water Supply, Drainage and Water Saving", "Unified Standard for Civil Building Design", "General Code for Civil Buildings", "General Code for Building Fire Protection", "General Code for Barrier-Free of Building and Municipal Engineering (with Annotations)".

[0041] Through manual screening, 1,600 core regulatory clauses were extracted from the documents for information extraction and link research. The above-mentioned regulatory texts are divided into the following six types:

[0042] Material specifications: including regulations on the selection, application, and performance standards of building materials in building design and construction.

[0043] Numeric specifications: including various specific numeric standards that must be complied with in building design and construction, such as dimensions, capacity, strength, durability, and energy efficiency.

[0044] Existence specifications: guiding elements that must be provided or avoided in building design and construction, such as the configuration of safety exits.

[0045] Measure specifications: involving specific measures and procedures to be taken in building design and construction, such as waterproofing and sound insulation measures.

[0046] Geometric specifications: regulations on the spatial layout and dimensional ratios of building elements in design and construction.

[0047] Reference specifications: including tables, charts, and relevant management regulations cited in building codes.

[0048] Further, identify and extract key information from the text data of building industry regulations and specifications; the key information includes: entities, attributes, attribute values, and rules.

[0049] Further, entities are used to define basic building concepts, attributes are used to identify and distinguish multiple attributes of entities, and attribute values are used to express the quantitative or qualitative descriptions of attributes.

[0050] Further, the entities include: building type labels, building element labels, functional area labels, building facility labels, building material labels, and component part labels;

[0051] The attributes include: numerical attributes and non-numerical attributes;

[0052] The attribute values include: numerical attribute values and non-numerical attribute values.

[0053] To comprehensively capture the main information categories in building regulations texts, three types of semantic labels are designed: entities, attributes, and attribute values, as shown in Table 1. Entities are used to define basic building concepts, such as building categories and constituent elements. Attributes are responsible for identifying and distinguishing multiple characteristics of entities, covering measurement dimensions such as length and area. Attribute values, on the other hand, are used to express the specific quantitative or qualitative descriptions of these attributes, such as a specific dimension of "200mm" or a numerical value like "25". To optimize the subsequent processing flow of various regulatory texts, attributes and attribute values are further divided into numerical and non-numerical types, aiming to improve the accuracy of the model in processing quantitative data and string information.

[0054] Table 1: Classification of Semantic Labels

[0055]

[0056] The following is information extraction, accurately identifying and extracting entities, attributes, attribute values, and other key information from text data.

[0057] In the information extraction phase, the main task is to accurately identify and extract key elements such as entities, attributes, and attribute values from text data. Based on the characteristics of attribute values, the information extraction of building regulations can be roughly divided into numerical standards and non-numerical standards. Among them, numerical standards are applicable to specifications with quantifiable attribute values, while non-numerical standards are for specifications with qualitative attribute values.

[0058] Further, the identification and extraction of key information from the text data of building industry regulations and specifications include: using the named entity recognition model CNN - BiLSTM - CRF to extract entities, attributes, and attribute values from the text data of building industry regulations and specifications.

[0059] The named entity recognition model CNN-BiLSTM-CRF includes: a fusion convolutional neural network (CNN), a bidirectional long short-term memory network (BiLSTM), and a conditional random field (CRF) connected in sequence.

[0060] It should be understood that a named entity recognition model using a fusion convolutional neural network (CNN), a bidirectional long short-term memory network (BiLSTM), and a conditional random field (CRF), namely the CNN-BiLSTM-CRF model, is used to accurately identify and extract key information such as entities, attributes, and attribute values in text data. In this model, ALBERT is used as a pre-trained model to convert text data into word vector representations. The CNN processes these embeddings to extract local features, the BiLSTM captures context information and long-distance dependencies, and the CRF improves the extraction accuracy through a global optimization method.

[0061] Using 1600 text data entries from the construction field, they are divided into a training set, a test set, and a validation set in a ratio of 6:2:2. The experimental results show that the model achieves high accuracy and effectiveness on the construction field dataset, with an accuracy of 79.61%, a recall rate of 81.43%, and an F1 value of 80.50%. After subsequent experimental verification, increasing the dataset size can significantly improve these values.

[0062] Furthermore, the identification and extraction of key information from the text data of construction industry regulations and specifications also includes: extracting rule information, where the rule information includes: terms and instruction expressions for quantitative comparison, and terms with negative expressions;

[0063] Using regular expressions, extract terms for quantitative comparison, where the terms for quantitative comparison include: greater than, less than, or not exceeding.

[0064] Using regular expressions, extract instruction expressions, where the instruction expressions include: "should", "should adopt", or "should not use".

[0065] Using regular expressions, extract terms with negative expressions, where the terms with negative expressions are words in the text that have semantic meanings such as negation, restriction, and prohibition, thus changing the original positive or neutral semantic direction of the sentence. Such terms are crucial for correctly understanding and accurately implementing construction regulations and specifications. The terms with negative expressions include: "not", "prohibit", "avoid", etc.

[0066] It should be understood that for non-numerical regulations, the focus is on extracting directive expressions that require or restrict the application of attribute values, such as "should", "should adopt", "should not use", etc., and

[0067] It should be understood that for non - numerical regulations, the directive expressions that emphasize the extraction requirements or restrict the application of attribute values should be extracted, such as "should", "should adopt", "should not be used", etc., and it is necessary to check whether there are negative terms, such as "not", "prohibited", "avoid", etc., to ensure the compliance of relevant attribute values. During specific inspections, after extracting the attributes and their values, regular expressions are used to match and search the text between the two. Once the above - mentioned negative terms are found, they are recorded. For example, in the sentence "Ordinary glass should not be used for window glass", the text is scanned with regular expressions to identify the negative term "should not", and then the restrictive requirements for the attribute value of window glass are clarified to ensure that the extracted information complies with the regulations. These methods are simple and effective and can help accurately extract and understand the regulatory requirements from the text.

[0068] For building codes, the generated SHACL constraints are verified on the ifcOWL instance graph after the BIM model is converted on the TopBraid Composer platform, and a detailed inspection report is given.

[0069] Since quantitative terms usually follow a fixed expression pattern, the present invention uses regular expressions to simply and efficiently extract this information from the text. During the information extraction stage, once the attributes and their corresponding values are identified, the next step is to deeply analyze the text content between the two.

[0070] For numerical regulations, regular expressions are used to identify potential comparison terms in the text, which are crucial for revealing the comparison relationships in the text.

[0071] For non - numerical regulations, regular expressions are used to identify the directive terms in the text. In addition, it is necessary to further check whether there are negative words in the text, such as "not", "prohibited", "avoid", etc., because these words may change the original meaning of the sentence and are crucial for correctly understanding and accurately implementing the regulations.

[0072] Taking "The step height of the stairs in residential buildings should not exceed 175 mm" as an example, the process of information extraction is to identify "residential buildings" as the "Building Type" entity, and then classify "stairs" as the "Building Element". "Step height" is defined as the "Numeric Attribute", and "175 mm" is identified as the "Numeric Value" of this attribute. At the same time, the crucial comparison criterion "should not exceed" also needs to be effectively extracted to provide the necessary constraints for the construction of subsequent verification rules.

[0073] For non-numeric building codes, such as "Doors must have Class A fire resistance rating", the extraction process is the same. "Door" is clearly identified as a "Building Element" entity, "Fire resistance rating" is defined as a "Non-Numeric Attribute", and "Class A" is used as the "Qualitative Value" of this attribute.

[0074] The extraction of the term "must" is also crucial because it clearly stipulates that the "Fire resistance rating" attribute must use "Class A" as its value, which reflects the mandatory requirements of the code.

[0075] Through the above process, it is ensured that all key information is comprehensively and accurately extracted from the code text, thus providing accurate data support for the generation of SHACL constraints.

[0076] Furthermore, in step S102: Establish a mapping relationship between the key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship. Among them, the mapping relationship between the key information and the ifcOWL ontology includes:

[0077] Establish a mapping relationship between the entities in the key information and the corresponding Chinese terms in the ifcOWL ontology;

[0078] Establish a mapping relationship between the attributes in the key information and the corresponding Chinese terms in the ifcOWL ontology;

[0079] Establish a mapping relationship between the terms for quantitative comparison in the key information and the corresponding comparison operators in the ifcOWL ontology;

[0080] Establish a mapping relationship between the terms with negative expressions in the key information and the corresponding comparison operators in the ifcOWL ontology;

[0081] Establish a mapping relationship between the instruction expression "shall be" in the key information and the SPARQL function CONTAINS in the ifcOWL ontology;

[0082] Establish a mapping relationship between the negative term "shall not be" in the key information and the logical operator "!CONTAINS" in the ifcOWL ontology;

[0083] Establish a mapping relationship between the non-numeric attribute value "Class A" in the key information and the hexadecimal Unicode string "75327EA7" in the ifcOWL ontology.

[0084] Furthermore, mapping the key information to the ifcOWL ontology according to the mapping relationship includes:

[0085] Map numerical building codes to the ifcOWL ontology, illustrated by "The riser height of each flight of stairs should not be greater than 175 mm and should not be less than 100 mm".

[0086] The building element entities "stair" and "flight of stairs" correspond to the entities IfcStair and IfcStairFlight in the IFC model respectively. Once the IFC model is converted into the ifcOWL ontology, these two IFC entities are represented by the OWL classes ifc:IfcStair and ifc:IfcStairFlight. Therefore, after the information linking process, the entities "stair" and "flight of stairs" should be linked to the OWL classes ifc:IfcStair and ifc:IfcStairFlight in the ifcOWL ontology.

[0087] For the numerical attribute "riser height" extracted from the rule, in the IFC model, this attribute corresponds to the attribute RiserHeight in the property set Pset_StairFlightCommon of the entity IfcStairFlight, where the property set is defined by the entity IfcPropertySet and the property is defined by the entity IfcPropertySingleValue.

[0088] The representation of the "RiserHeight" attribute of an instance of the IFC entity IfcStairFlight. Among them, the property set Pset_StairFlightCommon is modeled as an instance named IfcPropertySet_90853 of the OWL class ifc:IfcPropertySet, which is associated with an instance of the OWL class ifc:IfcLabel named IfcLabel_284474 through the object property name_IfcRoot to indicate the name of this property set. The instance IfcLabel_284474 is associated with the name of the property set "Pset_StairFlightCommon" through the data type property express:hasString. Then, the RiserHeight property is converted into an instance named IfcPropertySingleValue_90848 of the OWL class ifc:IfcPropertySingleValue, and the instance IfcPropertySet_90853 is connected to this instance through the object property hasProperties_IfcPropertySet.

[0089] In addition, the instance IfcPropertySingleValue_90848 is linked to the instance IfcIdentifier_284464 of the OWL class ifc:IfcIdentifier and the instance IfcLengthMeasure_284506 of the OWL class ifc:IfcLengthMeasure through the object properties name_IfcProperty and nominalValue_IfcPropertySingleValue, respectively. These two instances are connected to the property name RiserHeight and the specific value of the RiserHeight property "173.076923076923" through the data type properties express:hasString and express:hasDouble, respectively.

[0090] The quantitative comparison terms "should not exceed" and "should not be less than" obtained in the information extraction stage should be converted into SPARQL comparison operators "<=" and ">=".

[0091] Furthermore, mapping the key information to the ifcOWL ontology according to the mapping relationship further includes:

[0092] The non-numerical building specifications are mapped to the ifcOWL ontology. For non-numerical building specifications, the building specification "the fire protection grade of the door should be Class A" is used for description.

[0093] In the IFC model, the building element "door" corresponds to the IfcDoor entity, which is represented by the OWL class ifc:IfcDoor in the ifcOWL ontology. Therefore, the building element "door" is associated with the OWL class ifc:IfcDoor.

[0094] Regarding the non-numeric attribute "fire rating", in the IFC model, this attribute corresponds to the FireRating attribute in the Pset_DoorCommon attribute set of the IfcDoor entity. The depiction of this attribute set and attributes in the ifcOWL instance diagram is the same as the attribute set and attributes in the numeric specification. However, unlike the numeric specification, the value of the FireRating attribute is encoded as "\X2\75327EA7\X0", where "\X2" and "\X0" are delimiters of Unicode characters and "75327EA7" represents the hexadecimal equivalent of one or more Unicode characters. After conversion, the sequence "\X2\75327EA7\X0" corresponds to the Chinese string "甲级".

[0095] In addition, the directive word "shall be" is mapped to the SPARQL function CONTAINS. This function is mainly used to verify whether one string contains another string.

[0096] After mapping the non - numerical attribute value "Grade A" to the string "75327EA7", the CONTAINS function is used in the SPARQL query to check whether the value of the FireRating attribute in the ifcOWL ontology contains the string "75327EA7" converted from "Grade A".

[0097] It should be understood that in the information linking stage, the key lies in precisely pairing the building element entities and their attributes identified in the information extraction stage with the corresponding elements in the ifcOWL ontology. This stage also covers converting other core information in the text, such as terms related to quantitative assessment, into appropriate SPARQL query statements, thus laying a solid foundation for subsequent SHACL rule formulation.

[0098] It should be understood that after determining the corresponding mapping relationships between the building element entities and their related attributes and the ifcOWL ontology elements, considering that there are often fixed corresponding elements for these entities and attributes in the ifcOWL ontology. For example, "door" is usually only mapped to ifc:IfcDoor, a lexical linking method is adopted in the information linking stage. Specifically, a comprehensive dictionary is constructed to match the Chinese terms that appear in the building codes and correspond to the ifcOWL ontology with the building element entities and attributes. For example, both "window opening" and "window" are mapped to ifc:IfcWindow. This method effectively associates the entities and attributes obtained in the information extraction stage with the ifcOWL ontology elements, ensuring both the intuitiveness of the operation and the improvement of the linking efficiency.

[0099] It should be understood that for the terms or phrases extracted by regular expressions for quantitative assessment and guidance, given their clear classification and standardized format, they are directly converted according to the preset mapping rules. When dealing with numerical specifications, quantitative comparison terms such as "greater than" and "exceed" are directly mapped to the corresponding comparison operators (such as ">"); if a negative expression like "shall not exceed" is encountered, the comparison operator is reversed accordingly to accurately reflect the comparison intention.

[0100] It should be understood that in terms of non - numerical specifications, the key is to ensure that the non - numerical attribute values of building element entities in the ifcOWL ontology are consistent with the attribute values identified in the text. Therefore, extracted directive phrases such as "shall be" are mapped to the SPARQL function CONTAINS for querying the inclusion relationship between strings. In addition, if negative terms such as "shall not be" are identified during the information extraction phase, a logical operation like "!CONTAINS" is used to meet the actual requirements.

[0101] Furthermore, step S103: Based on the mapped ifcOWL ontology, construct SHACL constraints, including:

[0102] (1 - 1) Construct a SHACL constraint template;

[0103] (1 - 2) Fill the key information and the mapped ifcOWL ontology into the SHACL constraint template to obtain the SHACL constraints.

[0104] The SHACL constraint template is a rule framework formulated based on information related to building elements, including: the SHACL constraint template for numerical building specifications and the SHACL constraint template for non - numerical building specifications.

[0105] The SHACL constraint template for numerical building specifications includes: building element entities, the number of numerical attributes, and specifications of numerical attribute values (such as upper and lower limits, exact values, etc.); the SHACL constraint template for numerical building specifications is used to verify the rationality of numerical attributes of building elements in the IFC model;

[0106] The SHACL constraint template for non - numerical building specifications includes: building element entities, the number of non - numerical attributes, and attribute value specifications (requiring or prohibiting certain values); the SHACL constraint template for non - numerical building specifications is used to verify the compliance of non - numerical attributes of building elements in the IFC model.

[0107] The SHACL constraints are specific rules generated by filling the key information (such as building element entities, attributes, attribute values, etc.) extracted from the building specification text and the mapped ifcOWL ontology into the SHACL constraint template, including: the SHACL constraints for numerical building specifications and the SHACL constraints for non - numerical building specifications.

[0108] These rules can be used to perform compliance verification on BIM models on relevant platforms (such as the TopBraid Composer platform). For example, for the specification that "the riser height of each flight of stairs should not be greater than 175 mm and should not be less than 100 mm", by filling in the key information and the ifcOWL ontology into the corresponding template, the rule generated with specific query and verification conditions is the SHACL constraint, which is used to check whether the riser height of the stairs in the BIM model complies with the regulations.

[0109] Furthermore, the SHACL constraint template includes: SHACL constraints for numerical building codes and SHACL constraints for non-numerical building codes.

[0110] Furthermore, the SHACL constraint for the numerical building code is illustrated by the building code that "the riser height of each flight of stairs should not exceed 175 mm and should not be less than 100 mm":

[0111] After information extraction and link processing, the building element entities "stair" and "flight of stairs" in the text are respectively mapped to the OWL classes ifc:IfcStair and ifc:IfcStairFlight in the ifcOWL ontology;

[0112] The numerical attribute "riser height" corresponds to the RiserHeight attribute in the property set Pset_StairFlightCommon of IfcStairFlight;

[0113] Based on this, the numerical attribute values "175 mm" and "100 mm" are extracted to verify all instances of the OWL class ifc:IfcStairFlight, ensuring that the values related to the RiserHeight attribute meet the conditions of not exceeding 175 mm and not being less than 100 mm.

[0114] In addition, through regular expressions and mapping rules, the text between the attribute "riser height" and the attribute values "175 mm" and "100 mm" is converted into comparison operators "≤" and "≥".

[0115] Since two comparison operators are identified in this process, the above mapping results are filled into the SHACL shape template containing the numerical upper and lower limit specifications, which is used to query and verify whether there are IfcStairFlight instances in the ifcOWL instance graph with a riser height exceeding 175 mm or less than 100 mm. The template filling stage integrates the obtained key information into the corresponding positions, thereby generating the SHACL constraint.

[0116] In the defined SHACL statements, lines 1 - 2 establish a SHACL node shape whose name is based on the RiserHeight property obtained in the information linking phase and the IfcStairFlight entity. Line 9 uses sh:targetClass to specify the target OWL class of this shape as ifc:IfcStairFlight. Line 11 utilizes sh:message to define the error or warning message that the system should display when an instance of the OWL class ifc:IfcStairFlight violates the constraint conditions, and the specific content is filled in by the original building code text. Lines 12 - 27 of the SHACL statements contain a SPARQL query for defining the constraints to be verified. Specifically, lines 15 - 18 query all instances of ifc:IfcStairFlight and further utilize the IfcRelAggregates relationship entity to identify the staircase instances associated with each flight of stairs. Lines 19 - 20 query all property sets linked to each instance of the OWL class ifc:IfcStairFlight. Lines 21 - 23 retrieve all properties in each property set and obtain the property named "RiserHeight", while lines 24 - 26 query the property values of this property and apply FILTER NOTEXISTS to exclude instances with property values between 100mm and 175mm. If instances that do not meet the regulatory requirements are found during the verification process, these instances will be detailedly recorded in the verification report, which will clearly state the specific reasons why the instances do not meet the standards for further analysis and correction.

[0117] Furthermore, the SHACL constraints for non - numerical building codes include:

[0118] For non - numerical codes, to construct a SHACL constraint template, it is necessary to first identify the number of building element entities to clarify the scope of building elements involved; then determine non - numerical properties, such as the fire - resistance rating of doors, the color type of glass, etc.; and at the same time clarify the specific requirements for these property values, including allowed or prohibited specific values, such as stipulating that the fire - resistance rating of doors must be Class A, prohibiting the use of specific types of glass, etc. The template constructed by integrating this information is the SHACL constraint template. It provides a standard framework for generating specific SHACL constraints and can quickly and accurately check whether non - numerical property values meet the code requirements during the BIM model compliance verification.

[0119] Taking "the fire - resistance rating of doors should be Class A" as an example, through information extraction and association, the building element "door" in the text is associated with the OWL class ifc:IfcDoor in the ifcOWL ontology.

[0120] The non - numerical attribute "Fire Rating" corresponds to the FireRating attribute in the property set Pset_DoorCommon of IfcDoor.

[0121] Extract the attribute value "Class A" from the text and convert it to the hexadecimal Unicode encoding "75327EA7" for validating all instances of the ifc:IfcDoor class to ensure that the value of the FireRating attribute contains this encoding.

[0122] Subsequently, using regular expressions and mapping rules, convert the indicative expression "shall have" between the attribute "Fire Rating" and the attribute value "Class A" into the SPARQL function "CONTAINS".

[0123] The above mapping results are integrated into a SHACL shape template, which is used to query and verify whether there are IfcDoor instances with a fire rating other than "Class A" in the ifcOWL instance graph.

[0124] In the defined SHACL statement, lines 1 - 2 define a SHACL node shape whose name is the combination of the FireRating attribute and the IfcDoor entity obtained in the information linking phase. Line 9 uses sh:targetClass to define the target OWL class of this shape as ifc:IfcDoor. Lines 12 - 24 of the SHACL statement use a SPARQL query to define the constraints that need to be verified, which are used to filter and verify whether the attribute values meet specific conditions. It should be noted that after querying the value of the single attribute FireRating in lines 22 - 23, FILTER NOT EXISTS is used, filling in the SPARQL function "CONTAINS" corresponding to the directive phrase "shall be", and the hexadecimal Unicode string "75327EA7" corresponding to the attribute value "Class A". Therefore, the final verification result will display the instances whose attribute values do not contain "Class A" and point out the specific reasons why these instances do not meet the standards for further analysis and correction.

[0125] Match the building element entities and attributes identified in the information extraction phase with the corresponding elements in the ifcOWL ontology, and map other key information to SPARQL statements. Establish mapping relationships for numerical and non - numerical specifications respectively, and use the dictionary linking method to improve the linking efficiency. For numerical specifications, the building element entities and attributes are accurately linked to the corresponding elements in the ifcOWL ontology, and the quantitative comparison terms are converted to SPARQL comparison operators; for non - numerical specifications, the building element entities and attributes are mapped, the non - numerical attribute values are converted to a specific format, the directive phrases are mapped to SPARQL functions, and if there are negative words, the corresponding logical operations are used.

[0126] Further, S104: Obtain the Building Information Model (BIM) to be inspected; convert the BIM to be inspected into an ifcOWL instance graph, input the ifcOWL instance graph into SHACL constraints, and generate a compliance inspection report for the BIM, including:

[0127] To verify the effectiveness of the generated SHACL rules, the riser height of a flight of stairs in the BIM model was adjusted to approximately 181 mm. Then, a conversion tool was used to convert the BIM model into an ifcOWL instance graph, and this instance graph and the generated SHACL rules were imported into the TopBraid Composer platform for verification.

[0128] From the verification results, it can be seen that the individual IfcStairFlight_924 does not conform to the rule that "the riser height of each flight of stairs should not be greater than 175 mm and should not be less than 100 mm". To further verify the accuracy of the verification results, this study queried the RiserHeight attribute values of all instances of the OWL class ifc:IfcStairFlight, and the entity IfcStairFlight_924 with a step height value of 181.666666666667 mm did violate this constraint. This verification process fully demonstrates the practical application value of SHACL constraints in the compliance inspection of BIM models.

[0129] Use the TopBraid Composer platform for SHACL constraint verification. After converting the BIM model into an ifcOWL instance graph, import it into this platform together with the generated SHACL rules. Through adjusting the riser height of the stairs in the BIM model for verification tests, if there are individuals in the model that do not conform to the specifications, the platform will clearly display them in the verification results, and relevant attribute values can be queried for further confirmation, thus demonstrating the practical application value of SHACL constraints in the compliance inspection of BIM models.

[0130] Embodiment 2

[0131] This embodiment provides a compliance inspection system for the Building Information Model (BIM), including:

[0132] An acquisition module, which is configured to: obtain building industry regulation text data; identify and extract key information from the building industry regulation text data; the key information includes: entities, attributes, attribute values, and rules;

[0133] A mapping module, which is configured to: establish a mapping relationship between the key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship;

[0134] A constraint construction module, which is configured to: construct SHACL constraints based on the mapped ifcOWL ontology;

[0135] A report generation module, which is configured to: obtain a building information model (BIM) to be inspected; convert the BIM to be inspected into an ifcOWL instance graph, input the ifcOWL instance graph into the SHACL constraints, and generate a compliance inspection report for the BIM.

[0136] It should be noted here that the above-mentioned acquisition module, mapping module, constraint construction module, and report generation module correspond to steps S101 to S104 in the first embodiment. The examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the content disclosed in the first embodiment above. It should be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.

[0137] In the above embodiments, the descriptions of each embodiment have their own focuses. For parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0138] The proposed system can be implemented in other ways. For example, the above-described system embodiments are merely illustrative. For example, the above module division is only a logical function division. In actual implementation, there can be other division methods. For example, multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0139] Embodiment III

[0140] This embodiment also provides an electronic device, including: one or more processors, one or more memories, and one or more computer programs; wherein, the processor is connected to the memory, the above one or more computer programs are stored in the memory, and when the electronic device runs, the processor executes the one or more computer programs stored in the memory, so that the electronic device executes the method described in the first embodiment above.

[0141] It should be understood that in this embodiment, the processor may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0142] The memory may include a read-only memory and a random access memory, and provide instructions and data to the processor. A part of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0143] In the implementation process, each step of the above method can be completed by the integrated logic circuit in the hardware of the processor or the instructions in the form of software.

[0144] The method in the first embodiment can be directly embodied as being executed by the hardware processor, or executed by the combination of the hardware and software modules in the processor. The software module can be located in the random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, register and other mature storage media in the art. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method. To avoid repetition, it will not be described in detail here.

[0145] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in conjunction with this embodiment can be implemented by electronic hardware or the combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but this implementation should not be considered to exceed the scope of the present invention.

[0146] Embodiment 4

[0147] This embodiment also provides a computer-readable storage medium for storing computer instructions. When the computer instructions are executed by the processor, the method described in the first embodiment is completed.

[0148] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A compliance check method for Building Information Modeling (BIM), characterized in that, Including: Obtain text data of construction industry regulations and specifications; Identify and extract key information from the text data of construction industry regulations and specifications; The key information includes: entities, attributes, attribute values, and rules; Establish a mapping relationship between the key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship; Construct SHACL constraints based on the mapped ifcOWL ontology; Obtain the building information model BIM to be inspected; convert the building information model BIM to be inspected into an ifcOWL instance graph, and input the ifcOWL instance graph into the SHACL constraints to generate a compliance inspection report for the building information model BIM.

2. The compliance check method for the Building Information Modeling (BIM) as described in claim 1, characterized in that, The identifying and extracting key information from the text data of construction industry regulations and specifications further includes: extracting rule information, and the rule information includes: terms and instruction expressions for quantitative comparison, and terms with negative expressions; Use regular expressions to extract terms for quantitative comparison, and the terms for quantitative comparison include: greater than, less than, or not exceeding; Use regular expressions to extract instruction expressions, and the instruction expressions include: "should", "should adopt", or "should not use"; Use regular expressions to extract terms with negative expressions, and the terms with negative expressions have semantic meanings of negation, restriction, and prohibition in the text.

3. The compliance check method for Building Information Modeling (BIM) as described in claim 1, characterized in that, Establish a mapping relationship between the key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship. Among them, the mapping relationship between the key information and the ifcOWL ontology includes: Establish a mapping relationship between the entities in the key information and the corresponding Chinese terms in the ifcOWL ontology; Establish a mapping relationship between the attributes in the key information and the corresponding Chinese terms in the ifcOWL ontology; Establish a mapping relationship between the terms for quantitative comparison in the key information and the corresponding comparison operators in the ifcOWL ontology; Establish a mapping relationship between the terms with negative expressions in the key information and the corresponding comparison operators in the ifcOWL ontology; Establish a mapping relationship between the instruction expression "must be" in the key information and the SPARQL function CONTAINS corresponding to the ifcOWL ontology; Establish a mapping relationship between the negative term "shall not be" in the key information and the logical operation symbol "!CONTAINS" corresponding to the ifcOWL ontology; Establish a mapping relationship between the non-numerical attribute value "Grade A" in the key information and the hexadecimal Unicode string "75327EA7" corresponding to the ifcOWL ontology.

4. The compliance checking method for Building Information Modeling (BIM) as described in claim 3, characterized in that, The mapping of the key information to the ifcOWL ontology according to the mapping relationship includes: Map the numerical building specifications to the ifcOWL ontology, as illustrated by "The step height of each flight of stairs should not be greater than 175 mm and should not be less than 100 mm". The building element entities "stair" and "flight of stairs" correspond to the entities IfcStair and IfcStairFlight in the IFC model respectively; once the IFC model is converted into the ifcOWL ontology, these two IFC entities are represented by the OWL classes ifc:IfcStair and ifc:IfcStairFlight; therefore, after the information linking process, the entities "stair" and "flight of stairs" should be linked to the OWL classes ifc:IfcStair and ifc:IfcStairFlight in the ifcOWL ontology; For the numerical property "riser height" extracted from the rules, in the IFC model, this property corresponds to the property RiserHeight in the property set Pset_StairFlightCommon of the entity IfcStairFlight, where the property set is defined by the entity IfcPropertySet and the property is defined by the entity IfcPropertySingleValue; The representation of the "RiserHeight" property of an instance of the IFC entity IfcStairFlight; among them, the property set Pset_StairFlightCommon is modeled as an instance named IfcPropertySet_90853 of the OWL class ifc:IfcPropertySet, which is associated with an instance of the OWL class ifc:IfcLabel named IfcLabel_284474 through the object property name_IfcRoot to indicate the name of this property set; the instance IfcLabel_284474 is associated with the name of the property set "Pset_StairFlightCommon" through the data type property express:hasString; then, the RiserHeight property is converted into an instance named IfcPropertySingleValue_90848 of the OWL class ifc:IfcPropertySingleValue, and the instance IfcPropertySet_90853 is connected to this instance through the object property hasProperties_IfcPropertySet; Instance IfcPropertySingleValue_90848 is linked to an instance IfcIdentifier_284464 of the OWL class ifc:IfcIdentifier and an instance IfcLengthMeasure_284506 of the OWL class ifc:IfcLengthMeasure through the object properties name_IfcProperty and nominalValue_IfcPropertySingleValue respectively; these two instances are connected to the property name RiserHeight and the specific value "173.076923076923" of the RiserHeight property through the data type properties express:hasString and express:hasDouble respectively.

5. The compliance checking method for building information model BIM according to claim 3, characterized in that The mapping of key information to the ifcOWL ontology according to the mapping relationship further includes: Mapping non-numerical building codes to the ifcOWL ontology. For non-numerical building codes, the building code "The fire resistance rating of the door shall be Class A" is used as an example for illustration. In the IFC model, the building element "door" corresponds to the IfcDoor entity, and the IfcDoor entity is represented by the OWL class ifc:IfcDoor in the ifcOWL ontology; therefore, the building element "door" is associated with the OWL class ifc:IfcDoor. Regarding the non-numerical property "fire resistance rating", in the IFC model, this property corresponds to the FireRating property in the Pset_DoorCommon property set of the IfcDoor entity; the depiction of this property set and property in the ifcOWL instance diagram is the same as the representation of the property set and property in the numerical specification. However, different from the numerical specification, the value of the FireRating property is encoded as "\X2\75327EA7\X0", where "\X2" and "\X0" are delimiters for Unicode characters, and "75327EA7" represents the hexadecimal equivalent of one or more Unicode characters; after conversion, the sequence "\X2\75327EA7\X0" corresponds to the Chinese character string "Class A". In addition, the directive word "shall be" is mapped to the SPARQL function CONTAINS. After mapping the non-numerical property value "Class A" to the string "75327EA7", the CONTAINS function is used in the SPARQL query to check whether the value of the FireRating property in the ifcOWL ontology contains the string "75327EA7" converted from "Class A".

6. The compliance checking method for building information model BIM according to claim 1, characterized in that Based on the mapped ifcOWL ontology, constructing SHACL constraints, including: (1-1)Construct an SHACL constraint template; the SHACL constraint template includes: an SHACL constraint template for numerical building codes and an SHACL constraint template for non-numerical building codes; The SHACL constraint template for numerical building codes includes: building element entities, the number of numerical attributes, and the specifications of numerical attribute values; the SHACL constraint template for numerical building codes is used to verify the rationality of the numerical attributes of building elements in the IFC model; The SHACL constraint template for non-numerical building codes includes: building element entities, the number of non-numerical attributes, and the attribute value specifications; the SHACL constraint template for non-numerical building codes is used to verify the compliance of the non-numerical attributes of building elements in the IFC model; (1-2)Fill the key information and the mapped ifcOWL ontology into the SHACL constraint template to obtain an SHACL constraint.

7. The compliance checking method of Building Information Modeling (BIM) according to claim 6, characterized in that, The SHACL constraint includes: an SHACL constraint for numerical building codes and an SHACL constraint for non-numerical building codes; The SHACL constraint for numerical building codes is illustrated by the statement in the building code that "the riser height of each flight of stairs shall not exceed 175 mm and shall not be less than 100 mm"; After information extraction and link processing, the building element entities "stair" and "flight of stairs" in the text are respectively mapped to the OWL classes ifc:IfcStair and ifc:IfcStairFlight in the ifcOWL ontology; The numerical attribute "riser height" corresponds to the RiserHeight attribute in the property set Pset_StairFlightCommon of IfcStairFlight; Based on this, the numerical attribute values "175 mm" and "100 mm" are extracted to verify all instances of the OWL class ifc:IfcStairFlight to ensure that the values related to the RiserHeight attribute meet the conditions of not exceeding 175 mm and not being less than 100 mm; In addition, through regular expressions and mapping rules, the text between the attribute "riser height" and the attribute values "175 mm" and "100 mm" is converted into comparison operators "≤" and "≥"; The SHACL constraint for non-numerical building codes includes: For non-numerical codes, when constructing an SHACL constraint template, it is necessary to first identify the number of building element entities to clarify the scope of building elements involved; then determine the non-numerical attributes, and the non-numerical attributes include: the fire rating of doors and the color type of glass; at the same time, clarify the specific requirements for attribute values, including permitted or prohibited specific values, and the permitted or prohibited specific values refer to: specifying that the fire rating of doors must be Class A and prohibiting the use of a certain type of glass.

8. A compliance checking system for Building Information Modeling (BIM), characterized in that, Include: An acquisition module, which is configured to: acquire the text data of building industry regulations and codes; Identify and extract key information from the text data of building industry regulations and codes; The key information includes: entities, attributes, attribute values, and rules; A mapping module, configured to: establish a mapping relationship between key information and the ifcOWL ontology, and map the key information to the ifcOWL ontology according to the mapping relationship; A constraint construction module, configured to: construct SHACL constraints based on the mapped ifcOWL ontology; A report generation module, configured to: obtain a building information model BIM to be inspected; convert the building information model BIM to be inspected into an ifcOWL instance graph, input the ifcOWL instance graph into the SHACL constraints, and generate a compliance inspection report for the building information model BIM.

9. An electronic device, characterized by comprising: A memory for non-temporarily storing computer-readable instructions; And A processor for running the computer-readable instructions, wherein, when the computer-readable instructions are run by the processor, the method according to any one of claims 1-7 above is executed.

10. A storage medium, characterized in that, Non-temporarily storing computer-readable instructions, wherein when the non-temporary computer-readable instructions are executed by a computer, the method according to any one of claims 1-7 is executed.