# Combined MvdXML and Semantic Technologies for Green Construction Code Checking
## 4 Methodology of Green Construction Code Checking
### MudXML Technology for Code Checking
#### 4.1.3 MvdXML Rules  
To use the mvdXML rule transformer, basic knowledge about the structure of mvdXML files is required. The <ConceptTemplate> element defines the structure that should be complied with by related concepts (see Figure 5). For instance, Concept Template is able to assign IfcPropertySingleValues to all subtypes of an IfcObject. Concept Template defines rules for the entire IfcObject based on IFC2X4. The elements between <Rules> define the path to the ApplicableEntity (i.e., IfcPropertySingleValueName). The universally unique identifier (UUID) of the Concept Template is an essential element which is generated to relate concepts to the Concept Template. For instance, Figure 6 is the mvdXML snippet that shows the definition of the \"external flag\" concept of \"external loadbearing wall\", and Figure 7 is the mvdXML snippet that shows the definition of \"applicability\". The name of ConceptRoot element can be used to search for the name of a concept [47; 48]. Three parts are relevant in the ConceptRoot definition.  
1. ApplicableRootEntity and the applicability element (see Figure 6) define all IfcWall instances that fulfill the applicability constraints.
2. The <TemplateRules> element defines the availability of the property Pset_WallCommon.IsExternal (see Figure 7).
3. The <Requirements> element (see Figure 6) defines the usage for a set of exchangeRequirements (e.g., the exchangeRequirement with the ID 00000023-0000-0000-0000-000000000352).  
This part of ConceptRoot defines the condition under which the requirement test has to be applied to an IFC instance. Some requirements are shown in Table 2. The example shown in Figure 6 defines the applicableRootEntity of IfcWall, which includes all subtypes of IfcWall. Additionally, the <Applicability> element specifies constraints of Pset_WallCommon.IsExternal and Pset_WallCommon.LoadBearing.  
Figure 4: MvdXML rule transformer.  
</ConceptTemplate> <ConceptTemplate applicationEntity=\"ToObject\" symbolicSchema=\"TIC4\" name=\"' unid=\"OTT7621-d0a-4 abe-8118-64 eadZee3 ca\"> <Rule> <AttributeAttributeName=\"IsDefinedBy\" Cardinality=\"asSchema\"> <<entityValue> <AttributeCardinality=\"asSchema\" EntityName=\"ToLineDefinesByProperties\"> <AttributeSuples <AttributeName=\"RelatingPropertyDefinition\" Cardinality=\"asSchema\"> <entityValue> <ActiveSuplesCardinality=\"asSchema\" EntityName=\"ToLineIdQuantiity\"> <AttributeNameAttributeAttributeName=\"Quantitites\" Cardinality=\"asSchema\"> <entityValue> <AttributeName=\"IsSchema\" EntityName=\"ToQuantiityVolume\"> <AttributeName=\"IsSchema\" EntityName=\"ToQuantiityVolume\"> <AttributeName=\"IsSchema\" RuleID=\"ToQuantiityVolumeName\"> <AttributeName=\"IsSchema\" RuleID=  
In Figure 8, the existence of the property Pset_WallCommon.IsExternal is checked. This example is very specific as it tests a property that is already part of the applicability test. If the exchangeRequirement is mandatory, then this test should always pass as it is already required in the applicability test (external walls are identified by this property). If the exchangeRequirement is \"excluded\", then this test should always fail.  
An mvdXML file contains a broad set of entities and types of ruleset because an mvdXML file contains multiple <ConceptTemplates>. Moreover, each <ConceptTemplate> has multiple referring concepts, which allows integrating a variety of rules and entities in an mvdXML file. After the mvdXML ruleset is completed, the mvdXML checker can check IFC model by rules.