Semiautomatic Generation of Code Ontology Using ifcOWL in Compliance Checking

Code compliance checking is a very important step in engineering construction, but most of code compliance checking relies on manual review at present. With the development of semantic web technology, ontology can be used to represent code information and check the code automatically. However, code ontology is established manually by researchers who have suﬃcient domain knowledge, in which it is easy to cause poor hierarchical structure of classes. It is also possible for code ontology not being suitable for compliance check. This paper proposes a semiautomatic construction method of railway code ontology based on ifcOWL. The railway code ontology is developed by converting ifcOWL which extends semantic information of railway code. This method can ensure the completeness of the hierarchical relationship of the classes in code ontology with good scalability, which makes use of taxonomy in ifcOWL. The establishment of ontology is divided into two processes with low coupling, namely, extension and conversion, which reduces the domain knowledge requirements of the researchers. Finally, a practical speciﬁcation is selected to generate a code ontology that achieves some clauses checking.


Introduction
Compliance checking is a very important content in the process of engineering design. e traditional method relies on manually consulting the design model and matching the results with the code, which is not only inefficient but also prone to errors [1]. Over the recent years, the usage of semantic web technologies has notably increased in the domains of architecture, engineering, and construction. Specification rules are represented by semantic web for automatic compliance checking [2,3]. Semantic web technology is an ideal approach to merge heterogeneous information from various sources and to explicit information by formal standardized knowledge representations. As a critical element of the semantic web, ontology plays a significant role in its application, which provides a framework that can be employed to model knowledge and translate the knowledge into a form that can be interpreted by both computers and humans [4]. Ontology can be applicated on the checking of fire code compliance [5], building evacuation code [6], and so on. On the one hand, code ontology is often used as the representation model of specification semantics in compliance checking. e common way of checking is to establish SPARQL (SPARQL Protocol and RDF Query Language) statements or SWRL (Semantic Web Rule Language) rules on the code ontology to check the model information. On the other hand, the information integrity of the model should be considered before compliance checking; that is, we need to check whether these models have the attributes that need to be checked [7]. It is easy to cause ambiguity of results when there is a lack of required checking information in the actual compliance checking work. e semantic integrity of building information model is a necessary condition to ensure the application in a specific field [8]. Code ontology is composed of the concepts in the code and relationship between them, which can provide complete semantic information for integrity checking. Whether it is compliance checking or integrity checking, code ontology is an important prerequisite.
However, the establishment of ontology is a difficult work, which needs a lot of investigations from experts in the field [9]. Since ontology is a concept that was put forward very early, there are many methods for ontology modeling [10,11]. ere is no unified method for all ontologies, and different methods are needed in different situations. [12] In the process of ontology establishment, ontology reuse is a very important method [13]. Other available ontologies can provide basic content to save a lot of work for ontology establishment. IfcOWL is one of the few ontologies in the field of building information model which is transformed from IFC (Industry Foundation Classes) and is also the only ontology recommended by BuildingSMART [14]. ifcOWL and IFC have the same limits of information representation which can represent the semantics of many concepts in the field of architecture. However, ifcOWL is mainly aimed at the architecture engineering field, and there is still a lack of necessary concept description for other fields [15]. In addition, a part of content is missing in the process of ifcOWL conversion from IFC. erefore, this paper proposes a semiautomatic generation method for rail engineering code ontology based on ifcOWL. e concept semantic in rail engineering code is supplemented by extending ifcOWL and then extended ifcOWL is converted to code ontology.
is method can reduce the work of concept hierarchy in ontology modeling and reduce the requirement of domain knowledge level of ontology creator. e code ontology has strong extensibility because the concepts are converted from ifcOWL.

Ontology Application in Code Compliance Checking.
e code checking in construction engineering can be automatically executed by computer, whose premise is that the specification should be capable of being correctly "understood" and interpreted by the machine. Ontology can represent concepts and relationships, and the content to be checked in the specification can be represented by rules supported by semantic web for semantic reasoning directly instead of syntax matching. ere are many researches that improve the problem of code compliance checking through ontology. Zhong et al. [16] proposed a CQIEOntology to check the compliance of construction quality, in which SWRL rules are established to infer the inspection results. CQIEOntology is constructed according to part of Java inspection framework, which includes inspection objects and inspection tasks. Xu and Cai [17] checked the spatial compliance of underground utilities through four related ontologies: utility product ontology (UPO), transportation object ontology (TOO), geometry Ontology (GEO), and utility spatial rule ontology (USRO). Four different ontologies involve different contents, UPO and TOO provide the conceptualization of urban infrastructure products, in which the main concepts/classes in the domain of interest were identified based on a review of relevant open standards and textual documents. e compliance checking results are obtained through SPARQL. Lu et al. [18] created CSC ontology to check the construction safety specifications. Domain experts understand the knowledge from the construction solution database and define the concept classification of structural safety inspection. e establishment of ontology in these studies is more or less dependent on the existing classification of some concepts.

Ontology Building Method.
Since the concept of ontology was put forward in 1993 [19], there have been many different models for ontology construction; ENTERPRISE ontology [20] and TOVE (Toronto Virtual Enterprise) [21] are considered to be the earliest ontology building method guidelines. en, many ontology building methods based on the characteristics of different fields are proposed, such as KACTUS [22] in manufacturing and engineering domains, IDEF5 (Integrated definition for Ontology Description Capture Method) [23] in Software engineering domain, METHONTOLOGY [24] in chemistry domain, On-To-Knowledge method [25] in knowledge management system domain, and Ontology Development 101 method [26]. In practical engineering applications, Ren [27] established a complete BrM ontology for bridge maintenance knowledge management through the Ontology Development 101 method from concept definition to rule establishment, and the established rules can evaluate the technical condition of the bridge. Abanda [28] established the cost estimation ontology through METHONTOLOGY method and the construction of the ontology is decomposed to different small tasks. Concepts, attributes, and relationships were obtained from UKNRM1 ontology, and then concept classification was established by top-down method.
Building specification is a highly professional field, which contains many and complex semantic knowledge [29]. e complexity of specification makes the establishment of specification ontology more challenging. Both Ontology Development 101 and METHONTOLOGY methods mentioned that a very important step is to consider ontology reuse. If existing ontologies can be reused or extended, it is easier to define taxonomy and attribute relationship [30].

IFC and ifcOWL.
IFC, an important information conceptual model in the field of AEC (architecture, engineering, and construction), has been developed as a data model to describe the data of construction industry and registered as ISO 16739 : 2013. IFC defines an entity relationship model, which is composed of hundreds of entities organized into an object-based inheritance hierarchy. In order to support the semantic web application of data interoperability, flexible data exchange, distributed data management, and Buil-dingSMART subsequently released ifcOWL which is represented by an agreed Web Ontology Language (OWL) ontology for IFC. erefore, IFC or ifcOWL can be used to improve their domain-specific ontology. Liu et al. [31] constructed an ontology that can be used for engineering quantity calculation. e ontology not only includes the description of basic components in IFC but also creates new concepts such as studs and plates for engineering quantity calculation. Zhong et al. [32] simplified classes and object properties in IFCOWL, and a building information ontology suitable for building environment compliance checking is established. Borrmann et al. [33] mentioned that the shield tunnel model ontology is established according to the spatial concept in IFC. A part of the ifcOWL is reused in these studies. However, ifcOWL does not contain the many features of IFC, such as some attribute mapping [34,35]. Moreover, the IFC standard has too few concepts to describe specific-domain components [36]. erefore, this paper extends ifcOWL to represent the concept in the code through understanding the rail engineering code. A conversion method is proposed which can semiautomatically convert the ifcOWL into a part of the rail engineering code ontology. is method can save some labor resources, and code ontology has strong extensibility because it is converted by ifcOWL.

ifcOWL Extension Method
Code ontology should contain a complete description of the concepts in the code. e concepts which are not contained in ifcOWL need to be extended. IfcOWL is extended with three different ways, namely, attribute value extension, entity extension, and property extension, respectively.

Attribute Value Extension.
Attribute value extension mainly aims at more specific description of generalized entities, such as fire door or mechanical ventilation system. ese concepts are equivalent to generalized concepts in IFC added a restriction, such as concept: Door + feature: Fire Protection � Fire Door. e type of entity is represented through its own attributes, such as PredefinedType. However, all types cannot be included in IFC. In the above example, it can be understood that Fire Protection is a characteristic of Door. But in other concepts, its restriction is not the same as semantic relationship between Door and Fire Protection, such as Concrete is a kind of Material. Different types are required to represent different entities. Generally, the attribute which define entity types is selected to extend more types. Object-Type attribute is selected for IfcObject entity and the Category attribute is selected for IfcMaterial. e extension method is shown in Figure 1. A class is added as a subclass of the attribute value type which needs to be extended, of which the instances are extended value of attribute; it is shown in the red part of Figure 1. e restriction of corresponding class is modified in ifcOWL. e approach is similar to extending the enumeration value of PredefinedType attribute. Different entities will require different extension classes, even if they are extended by same attribute. When extending new content in the future, it is easy to find extension class. It is also convenient to query extended content.

Entity Extension.
Although the content of IFC is continually updated, the concepts of track domain, road, and bridge domain have been added in the version of IFC4x3_RC1. More professional concept in the code is often not expressed in IFC. Entity extension is aimed at some concepts that are not represented in IFC. ifcOWL is generated by EXPRESS format conversion of IFC. e method of entity extension is to extend the new concept with EX-PRESS format to ifcOWL. e concept description in the code can refer to IfcRail bSI SPEC standard [37], which is submitted by China Railway BIM alliance and certified by BuildingSMART. e shared spatial structure of IfcRail standard is shown in Figure 2.
e spatial structure of the IFC4x3 standard is shown in Figure 3. It can be seen from the figure that IfcRail standard can be regarded as an extension of IFC standard. IfcRail standard is submitted in 2016, some content that is the same as IFC in old version has changed. For example, IfcFacility that is superclass of IfcBuilding is the latest addition. erefore, the EXPRESS structure of extended concepts is corresponding to the latest IFC and then extended to ifcOWL.

Property Extension.
Most entities of IFC description document have a property set templates which contain the properties that entity should have and property value type. For instance, the property set of IfcTransportElement is shown in Figure 4, when PredefinedType is ELEVATOR. Obviously, these attributes are not complete and not mapped in ifcOWL. e properties of concepts are indispensable for integrity checking. e property association mode in IFC is that entity is connected to property set (IfcPropertySet) through the relationship (IfcRelDefinesByProperties) and property set is associated with multiple properties through attribute HasProperties. Properties can be described by six types of entities, namely, IfcPropertySingleValue, IfcPropertyTa-bleValue, IfcPropertyEnumeratedValue, IfcPropertyList Value, IfcPropertyReferenceValue, and IfcPropertyBounded Value, which, respectively, represent different type of property. In order to fully express the semantics and reduce the complexity of extension, IfcPropertySingleValue is selected as the type of extended property. As can be seen from Figure 4, each property defines not only the type but also the value type. For example, the ClearWidth property defines the property value type as IfcPositiveLengthMeasure inherited from Ifc-MeasureValue. ere are more basic measure types in the It indicates the distance from the inner surfaces of the elevator car le and right from the elevator door. e shape information is provided in addition to the shape representation and the geometric parameters used within. In cases of inconsistency between the geometric parameters and the shape properties, provided in the attached property, the geometric parameters take precedence. ClearDepth (P_SINGLEVALUE/IfcPositiveLengthMeasure): clear depth of the object (elevator). It indicates the distance from the inner surface of the elevator door to the opposite surface of the elevator car. e shape information is provided in addition to the shape representation and the geometric parameters used within. In cases of inconsistency between the geometric parameters and the shape properties, provided in the attached property, the geometric parameters take precedence. ClearHeight (P_SINGLEVALUE/IfcPositiveLengthMeasure): clear height of the object (elevator). e shape information is provided in addition to the shape representation and the geometric parameters used within. In cases of inconsistency between the geometric parameters and the shape properties, provided in the attached property, the geometric parameters take precedence. subclass of IfcMeasureValue, which come from the definition in ISO 10303-41. e unit of value is specified indirectly by basic measure types (international unit by default). Unit and value type of the property are defined by the type of the NominalValue attribute. e method is shown in Figure 5. e first step of property extension is to extend the property definition and define value type of NominalValue. e second step is to extend the property set definition. New relationship entity is extended to relate entity finally. As shown in Figure 5, the extended content is red. A new attribute IsDefinedBy is extended which should have been defined in ifcOWL, but IsDefinedBy is not defined because the range of Relate-dObjects attribute of IfcRelDefinesByProperties is different from domain of IsDefinedBy.

ifcOWL Conversion Method
e concepts in the specification information are represented by extending ifcOWL, and the hierarchical structure between concepts can be obtained by converting extended ifcOWL. e conversion method is proposed in this section, which can convert the extended content to code ontology. e method is divided into three categories, entity conversion, attribute value conversion, and entity property conversion, which are corresponding to different extension methods.

Entity Conversion.
Entity conversion is to convert the corresponding concept to code ontology according to the structural form in ifcOWL. e prefix of IFC entity is omitted in code ontology; for example, IfcDoor is converted to Door. Entity conversion does not focus on the attributes of the entity and the class hierarchy in ifcOWL is only retained, whose purpose is to improve the concept classification in the code with the help of the hierarchical structure in ifcOWL.
Two criteria are defined in entity conversion: (1) If the converted entity is a subclass of IfcObject, all the parent classes of the entity up to IfcObject need to be converted (2) Only the entity involved in the specification information is converted e first criterion is to preserve the relationship between the concepts. e second criterion can avoid entity conversion that does not appear in the code. e conversion process is shown in Figure 6. Entities with * are entities that need to be converted and entity conversion retains the hierarchical relationship between IfcObject and its subclasses.

Attribute Value Conversion.
e purpose of attribute value extension is to describe generalized concepts with certain characteristics. e generalized concepts can be regarded as the parent class of concepts with certain characteristics in code ontology, such that doors are the parent classes of fire doors. e conversion method is shown in Figure 7. Entities are converted into classes in the code ontology according to the entity conversion method. Characteristic class is characteristic description of concept in the code ontology. e attributes of the extended attribute value are converted to the subclasses of Characteristic.
ere is a hasCharacteristic relationship between the entity class and the characteristic class, which means that the entity class has certain characteristics. e extended types in ifcOWL are converted to ExtendedType.
e extended attribute values are, respectively, converted into the subclass of the characteristic class and the subclass of the converted entity and there is a hasCharacteristic relationship between them. e understandable description of attribute value conversion is to take the extended attribute value as a subclass of the entity and consider attribute values as a certain characteristic of the entity, which is a representation mode of the characteristic class and entity class in code ontology. e subclasses of Characteristic class are used to distinguish the attributes of different extended attribute, which can also be understood as distinguishing different characteristic types.

Property Conversion.
A new representation mode of property is defined in code ontology. Property is regarded as a new class in code ontology. e relationship hasProperty is set between the entity class and the property class, which indicates that the entity has properties. Units class is defined in code ontology, and the relationship Unit between Property class and Units means the unit of the property. Data property Value is defined to represent value type of the property. Property class in code ontology is converted from extended properties in ifcOWL. e conversion method is shown in Figure 8.
Entities are converted into classes in code ontology according to the entity conversion method. e extended properties are converted into subclasses of Property class in code ontology. According to the value type of NominalValue of the extended proper, Units class in code ontology is mapped and Unit relationship is set between properties and units. e mapping relationship between data type in OWL, the value type of NominalValue, and unit is shown in Table 1.
e value type of Value is defined according to mapping relationship.

Experimental Results
e code for design of Metro (GB50157-2013) [38] is one of the important codes in the metro construction domain in China, which covers at least 14 specialties. e code for design of Metro contains not only the provisions of the elements in the metro station, but also the specifications for trains, subgrades, lines, and other nonconstruction fields. e purpose of this paper is to create a code ontology that can be used for compliance checking in the construction engineering field. erefore, the following types of specifications have been removed during the experiment: (1) e first specification is abstraction limitation of information. For example, in clause 9.4.6, the room Advances in Civil Engineering with noise source should take sound insulation and absorption measures. ese measures are abstract and need to be described more specific by experts.
Like vehicle field, this part limits the requirements for trains in metro engineering. (3) ird, we have regulations of the construction process. For example, the construction methods of underground station structure under specific conditions are specified in clause 11.4. Nowadays, most of the compliance checking is to check the rationality of the design results, and the representation of the design process is unclear.
e mandatory clauses of different field are selected under the above premise. 10 clauses are selected to correspond to 10 specialties, which convert to code ontology used different methods. e code clauses are shown in Table 2, in which the concepts are similar to other clauses.
A concept mapping table is generated manually to map the corresponding concepts and extension contents. e table is divided into three mapping tables corresponding to three extension methods, which are shown in Tables 3-5   When the rated speed of elevator is 0.5 m/s and the lifting height is not more than 6 m, the number of upper and lower horizontal steps shall not be less than 2; when the rated speed is 0.5 m/s and the lifting height is greater than 6 m, the number of upper and lower horizontal steps shall not be less than 3; when the rated speed is greater than 0.65 m/s, the number of upper and lower horizontal steps shall not be less than 3.

Advances in Civil Engineering
Passenger transport equipment Property extension

28.2.5
Two fire compartments should be separated by a firewall with a fire resistance rating of not less than 3 h and a class A fire door. When the firewall is equipped with an observation window, a class a fire window should be used. e slab in the fire compartment should have a fire resistance rating of not less than 1.5 h.
Disaster prevention Attribute value and property extension  respectively. e restriction is added in Table 5 because the properties is related to the concepts that the entity is restricted. Jena package in the Java environment is used to deal with OWL in experiment.

Entity Extension and Conversion.
In entity extension, Table 3 is imported to obtain the EXPRESS structure of entities corresponding to entities in IfcRail. e extended entity is added in child hierarchy of its parent class corresponding class in ifcOWL. e extended entities are shown in Figure 9, which is displayed by Protege's OntoGraf.
e concepts in ifcOWL are converted according to entity conversion method. e prefix "Ifc" is omitted and the root concept of structure is IfcObject. e converted class structure is shown in Figure 10.

Attribute Value Extension and Conversion.
In attribute value extension, Table 4 is imported. A new class is created for each entity with extended attribute value and each attribute to be extended, which is a subclass of the extended attribute value type. e attribute value is extended as an instance of the class. e extended class structure is shown in Figure 11.  ere are four steps to complete conversion from ifcOWL to code ontology according to the conversion method: (1) Create a new class Characteristic and object property hasCharacteristic in code ontology. (2) e entity with the extended attribute value is converted into classes in code ontology through entity conversion and the extended value is converted to a subclass of corresponding entity class. (3) e extended attribute is converted into a subclass of Characteristic class, which is named after entity name + attribute name. e extended attribute value is a subclass of the class, whose name is prefixed with Char. (4) e object property hasCharacteristic associates entity class and characteristic class.
e class structure of code ontology after conversion is shown in Figure 12.

Property Extension and Conversion.
In property extension, Table 5 is imported. New property set class, named Pset + entity, is created. New relationship entity class is named after IfcRel + entity name. New property class is

10
Advances in Civil Engineering created whose name is P + property name.
e property value type is restricted by property value type column in Table 5. Finally, the restriction of class is added to relate the content of extension.
A restriction column is added in Table 5 to indicate that the extended property is related to the restricted entity. When the value of PredefinedType attribute of Ifc-TransportElement is ESCALATOR, it means that it is an  escalator, and the extended property Height is semantically related to the escalator. erefore, if there is restriction, it need to be added in class. e restriction of RelatedObject in the extended relationship entity IfcRelEscalator of Ifc-TransportElement is shown in Figure 13, namely,∀ Relate-dObject (IfcTransportElement and (PredefinedType {ESCALATOR})), which means that RelatedObject must relate IfcTransportElement whose value of PredefinedType is ESCALATOR.
e extended class structure in ifcOWL is shown in Figure 14.
ere are four steps to convert ifcOWL into code ontology: (1) Create a new class Property, unit class Units, object property hasProperty and object property Unit. e range of hasProperty is Property. e domain of Unit is Property, and the range of Unit is Units. (2) Entities with extended properties are converted into class in code ontology through entity conversion method. (3) e extended property set converted into subclass of Property, which is named after entity name-+ PropertySet. e extended properties are converted into subclasses of property set class in code ontology. e class restriction is created to relate entity class and property class through hasProperty. (4) e value type of NominalValue of the extended property is converted into Units class by mapping Table 1. e class restriction is created to relate property class and unit class through Unit.  e code ontology class structure is shown in Figure 15. e conversion of restricted entities is similar to attribute value conversion. Property class in code ontology is related to class which are converted from restricted entities. If restricted entities are new concept for code ontology, an additional step of attribute value extension is executed in Step 2.
Code ontology is generated as OWL and imported to Protege 4.0. Hermit1.4.3 inference engine included in protege is used to check the consistency of code ontology, and there is no problem.

Integrity Checking.
Integrity checking is to check whether the model has sufficient attributes to meet the requirements of specification compliance checking. e code ontology is a knowledge model of various relationships between concepts in the specification, which includes the definition of various attributes. erefore, some relationships between the attributes and components in the ontology are converted to SPARQL statements, which are used to query the model information to check the missing information.
A real metro station model is selected for testing, whose data format is IFC. e model is shown in Figure 16 and display tool is BIM Vision [39]. In previous experiment, "Escalator" should have a "hasProperty" relationship with properties: Height, RatedVelocity, and StepNumber in code ontology.
ese definitions are converted to SPARQL statements. e model information is mapped to the ontology instance. Escalators A and B in Figure 17 correspond to instances A and B, respectively. Integrity checking is executed by SPARQL query module on Protege and the results are shown in Figure 18, where CPEscalator indicates that the information is complete. e properties of escalator A is complete in Figure 17 and the "StepNumber" of escalator B is missing, which is the same as the checking result.

Compliance Checking.
Compliance checking is to check whether the information of the model meets the specification requirements. e provisions of the specification can be converted into SWRL rules which are used to reason checking results in the code ontology. e experimental model is the same as previous model in Figure 16. ere are new result classes in ontology to represent the checking results. Compliance class indicates the inspection object is in compliance with the specification. e model information is mapped to the ontology instance and SWRL rules are reasoned through SWRL Tab in Protege; it is found that Track B is an instance of Compliance class as shown in Figure 19, which indicates that Track B conforms to the specification.
e results correspond to IFC model in Figure 20, and the property of track A is displayed as 50, while the DesignedLifetime of track B is 100.

Advances in Civil Engineering 15
ifcOWL is extended and converted to code ontology in the experiment, and then the code checking is implemented successfully by the code ontology. e feasibility of obtaining code ontology is proved by experiment. However, it is still necessary to manually mark the information in code as object in IFC in the preliminary work. At present, ontology construction cannot avoid the process of manual processing. It is necessary to map the model information to the code ontology in code checking, which can be relatively easy because the code ontology is converted by ifcOWL.

Conclusion and Discussion
6.1. Discussion. Compliance check is one of the necessary steps in the process of engineering construction. More and more researchers focus on new technologies such as semantic web to achieve automatic compliance check. A common method is to use the rules in the knowledge base to infer the results of compliance. Developing a code ontology that contains enough knowledge is the premise of compliance checking and a more important role is that the specification ontology can be used to check the integrity of the model. e establishment of domain ontology always is a difficult work, because it needs a lot of experts with rich knowledge to discuss and the consistency of the ontology needs to be guaranteed. IfcOWL, as one of the few ontologies in the field of building information, can provide the hierarchical structure of building information concepts and the definition of the relationship between concepts, which can provide a reference for code ontology. However, ifcOWL is actually aimed at general architectural concepts; the concepts in the code need to be extended in ifcOWL.
is paper proposes a code ontology generation method based on ifcOWL. ifcOWL is used to represent the code information in the process of extending ifcOWL and the concepts that cannot be represented by ifcOWL are extended. is part of work can reduce the domain knowledge requirements of researchers; because the code concepts have complex hierarchical classification relationships, researchers only need to consider the representation of concepts and the hierarchical classification relationship is implied in ifcOWL. Although various relationships between architectural concepts can be expressed in ifcOWL, the representation of some complex relationship may become more complex through ifcOWL, which increases the complexity of checking algorithms and affects the efficiency in the later code checking. In the process of ifcOWL conversion, the mapping patterns of attributes and classes are proposed. e domain experts' knowledge is not needed in this process and the two parts of the work of extending and converting are not related to each other. Ontology can be generated automatically after mapping is established. e method is also implemented in the metro design specification. However, it is still necessary to manually mark the information in code as object in IFC. Researchers can express the concepts in code with the help of IFC in this way instead of having a comprehensive knowledge of code information, which reduce the requirements of understanding of the code knowledge in the ontology construction. e extension of ifcOWL and the conversion of ifcOWL are separated. e extension is to express the semantics of code information through ifcOWL and the conversion is to generate code ontology with help of ifcOWL hierarchy. e separation of two parts can better reduce the coupling of work of ontology construction. Finally, the integrity and compliance of some components of the metro model are checked through the established metro design specification ontology. e integrity is checked through SPARQL querying and the compliance is checked through SWRL reasoning, which are common ontology applications. Although ifcOWL is highly extensible, if code ontology is only established by extended ifcOWL, it may cause ontology redundancy in the future and it is necessary to disambiguate in the process of ontology extension. ese issues should be taken seriously in future work.

Conclusion and Future Work.
For the absence of code ontology and the difficulty of code establishment, the ontology building method proposed in this paper which is divided into two parts. One is to extend ifcOWL to represent code information; the concepts in ifcOWL are extended with the help of other domain IFC standard for more domain concepts definition and property extension improves the semantic relationship between property and entity in the specification. e other is to convert ifcOWL into code ontology. e extended ifcOWL is converted into code ontology, where extended entity and attribute value are converted into classes. e semantic representation of Property and Unit is defined in code ontology. Finally, an experts-dependency specification that is the code for design of Metro is selected as experimental content in this paper, where several clauses in different fields are selected to prove the feasible of the method. e consistency of established ontology is verified by HermiT inference engine. e compliance and integrity of the components of a metro model are checked with the help of established ontology, which proves the effectiveness of the ontology. e coupling degree of extension and conversion is very low, which can reduce the requirements of ontology builders for code domain knowledge and also improve the efficiency of specification ontology establishment. Code ontology is easy to extend in future because it is based on ifcOWL structure.
Although this paper achieves the generation of a part of code ontology which can be used to check integrity of information based on hierarchical classification of concepts in ifcOWL. However, there are many other relationships that are not represented in code ontology, such as spatial containment relationship and setting relationship. ese relationships represent the logical relationships between different concepts in specification information and are main checkpoints in compliance check. Some of the relationships can be expressed in ifcOWL and we can add them to code ontology through the conversion of ifcOWL. Some of them cannot be expressed by ifcOWL, and we need to redefine it to conform to the established ontology. erefore, this part of the ontology needs to be further extended and improved in future work, which can improve the effect of automatic compliance checking but also play a role in other semantic application scenarios.

Data Availability
e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that they have no conflicts of interest.