Industry Foundation Classes (IFC) is a standard open data schema for Building Information Model (BIM). IFC is widely used as an information exchange format in the architectural, engineering and construction (AEC) field. For supporting the exchange of various building information from various software platforms, IFC defines a general-purpose data schema with coarse-grained entity types (such as “IfcWindow” and “IfcDoor”), various geometry representations (such as “IfcExtrudedAreaSolid” and “IfcFacetedBrep”), relationships (such as “ConnectedTo” and “IsDecomposedBy”), and the data structure for properties (such as “IfcPropertySet” and “IfcPropertySingleValue” ). However, since IFC has strong compatibility for various contents, different software platforms may have various implementations in the importing and exporting of data. Without sufficient constraints for the entities, geometry representations, relationships, and property definitions, the data exchange process between different software platforms will suffer from information loss or inapplicability.
In order to ensure the interoperability of IFC in specific data exchange use cases, the Information Delivery Manual (IDM) - Model View Definition (MVD) method Wix and Karlshoej (2010); See et al. (2012); Hietanen (2006) is proposed as a recommended standard methodology to support specific data exchange requirements. IDM describes the working process and exchange requirements in the use cases. MVD defines the subsets of a specific IFC Schema, with constraints on entities, attributes, geometry representations and so on.
The mvdXML Chipman et al. (2016) is the formal representation format for MVDs recommended by buildingSMART. There are two major parts of contents in mvdXML: the natural language descriptions of domain concepts and exchange requirements, and the rules for data templates, attributes, and values. The mvdXML rules can be parsed by computers, which can be used for supporting software implementation in IFC-based data exchange, and for supporting automatic MVD validation on IFC models Zhang et al. (2014, 2013).
Currently, the developers of MVDs are primarily academic institutions and standardization organizations, such as buildingSMART and National Institute of Building Sciences (NIBS). The MVDs developed by these organizations are mainly focused on the use cases of a certain discipline (such as walls, water systems, and HVAC systems), or the information exchange requirement of a certain application (such as quantity take-off and energy simulation).
In mvdXML, the data templates are represented separately from the rule statements. The data templates are in XML tags and the rules are written in “mvdXML Rule Grammar” statements, so that the templates can be reused in multiple rule statements. Generally, professional tools like ifcDoc Chipman (2012) are needed to generate mvdXML rulesets. Some other enterprise-standard tools like BIMQ GmbH (2019) can not fully utilize the expressiveness of MVD, i.e. it is not supported to create arbitrary mvdXML rules (such as the constraints about geometry representations, colors, or various relationships). The mvdXML files are not concise enough to be edited in text editors or embedded in the forms in such applications. Besides, It could take hours to validate a large-scale model against an enterprise-level mvdXML, which makes it hard to be adopted in real projects. As a result, the application of mvdXML in flexible scenarios is still limited.
In this paper, MVDLite is proposed as a novel light-weight MVD language. MVDLite is more concise and has a more flexible rule structure, and also compatible with the current mvdXML format. It is suitable for editing in sentences in text editors or embedding in a table. It also supports faster MVD validation on large-scale models and rulesets. In addition, the MVDLite rulesets are easier switching between different IFC schema versions like IFC2X3 and IFC4.
Our main contributions are listed as follows.
A novel MVD rule grammar is proposed with a new combined structure for the data templates, attribute values, and logical operators (see Section 3).
A new MVD validation algorithm is proposed based on the novel rule structure of MVDLite, which is much faster than the mvdXML-based MVD validation algorithm (see Section 4).
A case study is provided to show the MVDLite-based workflow for customizing an enterprise-level MVD, and the applications in MVD validation and partial model extraction on large real-world models (see Section 5).
2 Related Work
2.1 Methods for MVD Representation and Development
In the IDM-MVD method, IDM is mainly about the definition of data delivery process, exchange requirements, and functional parts, and MVD is about the technical solution of IDM in the IFC data format. MVD binds the domain entities in the exchange requirements to the IFC entities and constrains the required information for geometry, attributes and relationships. The definitions and constraints in MVD intend to support meaningful IFC implementations for software developers Hietanen (2006).
There have been several studies on MVD representation and development from different aspects. The Extended Process to Product Modeling (xPPM) Lee et al. (2013) is based on the formal definition of IDM, and provides a tool for mapping the IDM functional parts to MVD. The Semantic Exchange Modules framework (SEM) Venugopal et al. (2012a) is based on the object-oriented definition of domain concepts in ontologies. SEM provides a mapping between the domain entity concepts and the data structure concepts in specific data forms. The Generalised Model Subset Definition (GMSD) Weise et al. (2003) is based on the specification of rules for selecting a subset of entities from the IFC model. In summary, xPPM focuses on the process of mapping IDM to MVD, SEM focuses on the definition of domain concepts, and GMSD focuses on the rule constraints for partial models.
Based on the previous researches about MVD, an integrated IDM-MVD process for IFC data exchange is proposed and recommended by buildingSMART See et al. (2012), which combines the strengths of the previous researches. The mvdXML format Chipman et al. (2016) is used for this integrated IDM-MVD process, which involves abundant information about exchange requirements, domain concepts, and rule constraints. The recommended IDM-MVD process mainly include:
Defining the domain concepts (entities, properties, and geometries), relationships and rule constraints in an Exchange Requirements Model (ERM) as forms and diagrams.
Binding the concept definitions in the ERM into a specific IFC Release (such as IFC4).
Writing the relationships and rule constraints into a specific IFC Release as MVD Implementation Guidance forms and diagrams.
Implement the mvdXML according to the concept bindings, forms, and diagrams.
The mvdXML format has been widely accepted and is supported by the newer versions of xPPM and SEM.
In addition to MVD, there are some other studies on the definition of IFC partial models, mainly based on domain ontologies Beetz et al. (2009); Zhang and Issa (2012); Pauwels and Roxin (2016); Krijnen and Beetz (2018) or domain-specific query languages Mazairac and Beetz (2013); Wülfing et al. (2014); Zhang et al. (2018); Tauscher et al. (2016); Borrmann and Rank (2009); Daum and Borrmann (2013); Preidel and Borrmann (2016); Amrutha and Balasubramanian (2014). MVD is currently accepted by the mainstream because it can integrate the exchange requirements and the data constraints required in software implementation.
2.2 The mvdXML Format
Currently, the most widely used version of mvdXML is V1.1 Chipman et al. (2016). In this paper, all the analyses and experimental comparisons are based on mvdXML V1.1. An example ruleset in mvdXML format is shown in Figure 2 (b).
The mvdXML format involves natural language definitions (exchange requirements and entity types) and rules (subgraph structures and value constraints). Subgraph structures are defined in the ConceptTemplate tags at the beginning of the file, and the other contents are included in ModelView tags at the body part.
A subgraph structure is defined as a ConceptTemplate, which represents the subgraph pattern, attributes, and entity types are defined in a nested XML structure. Each ConceptTemplate is with a GUID and each attribute is assigned with a RuleID. One ConceptTemplate can also be referred to in another ConceptTemplate as a subtemplate.
A exchange requirement is defined as a ExchangeRequirement tag in a ModelView tag. Each ExchangeRequirement is with a GUID.
An entity type is defined as a ConceptRoot tag, which corresponds to a subset of entities of an IFC entity type (i.e. the “applicableRootEntity”). An Applicability rule is used to distinguish this subset of entities from all root entities.
A value constraint rule is defined as a Concept tag inside a ConceptRoot. Each Applicability rule and Concept rule should refer to a ConceptTemplate with GUID, and the rules are written in “mvdXML Rule Grammar”. One Concept can also refer to several ExchangeRequirements with GUID.
One important feature of the representation of rules in mvdXML is the separation of templates and rule statements. The templates of IFC subgraph structures are defined in ConceptTemplate tags, and each rule statement should refer to a ConceptTemplate with GUID, so that the RuleIDs defined in the template can be used to compose the rule statement. The benefit of this separation is that the templates can be reused in multiple rule statements. While as a result, the “mvdXML Rule Grammar” must rely on the complete XML structure. It can not be used independently as a query language or rule language since it needs the ConceptTemplates defined in XML.
The separation of templates and rule statements leads to two corresponding different logical operators in mvdXML: the logical operators inside one statement are represented as keywords (AND, OR, XOR, NOT), while the logical operators between different statements are represented in the XML structure, such as “<TemplateRules operator=‘‘or’’> ... </TemplateRules>”. The two types of logical operators are not equivalent, and usually, they can not replace each other. The detailed difference between them is explained in Section 2.4.
2.3 The Process of Developing MVDs
In the buildingSMART document about integrated IDM-MVD process See et al. (2012), the authors acknowledge that “MVD development is much more technical work that requires expertise in software, the IFC Schema, construction industry, and data modeling … It requires in-depth knowledge of the information model(s) for which bindings will be defined, as well as a good understanding of the requirements (and industry process) described in the IDM.”
The MVD development process is a collaboration between domain engineers and MVD experts. The domain engineers are the originators of exchange requirements. They inform the MVD expert with the understandings of element types, properties and exchange requirements in natural language. An MVD expert requires both domain knowledge (about domain concepts and exchange requirements) and data knowledge (about IFC data structure and mvdXML format). The tasks of an MVD expert mainly include: understanding exchange requirements, mapping domain concepts into IFC, drawing diagrams, editing ConceptTemplates, and writing rules. The tasks are usually done in tools such as ifcDoc. Due to the knowledge threshold and workload of developing MVDs, currently, most MVDs are developed by academic institutions and standardization organizations.
Some studies consider using ontology-based process Lee et al. (2016b); Venugopal et al. (2012c, b, 2015); de Farias et al. (2018) to assist the creation of MVD. Such methods formalize the exchange requirements, domain concepts and constraints described in IDM-MVD as domain ontologies, and then generates mvdXML by means of automatic conversion. Ontology-based MVD creation is modularized and reusable. When sufficient domain concepts are represented in ontology, the efficiency of building mvdXML can be significantly improved. In addition, the rule constraints can be formally represented using rule languages such as SPARQL and SWRL. However, since the ontology-based process requires additional knowledge about ontology and ontology editing tools like Protégé Stanford University (2016), it is mainly used in academic institutions.
2.4 Automated MVD Validation
In order to realize the practical application of MVD, an important supporting application is to automatically verify the conformity of the model with MVD. Chi Zhang et al. summarized a three-step framework for automated model view checking Zhang et al. (2014), including the development of model view rule-sets, check execution, and report generation. Currently, automatic model view validation applications have been implemented on several software platforms, including Solibri Model Checker (SMC) Eastman et al. (2009), xBIM Weise et al. (2016, 2016), BIMserver opensourceBIM (2014); Zhang et al. (2014), and Simplebim simplebim (2018).
The mvdXML validation algorithm is formulated according to the way rules are organized in mvdXML, so the current MVD validation tools all have similar implementations. In mvdXML, one “rule” (in Applicability or in Concept) is composed of a root entity set, a ConceptTemplate, several “mvdXML Rule Grammar” statements, and the logical combination of the statements. Since templates and statements are separated, the validation process follows “first matching the template and then checking the statements”. The steps of getting the Boolean result of one root entity is as follow:
For one root entity, there are usually multiple subgraphs that can match the same template. For example, if one root entity has 5 properties and each property is an “IfcProperty” node, then for this root entity, there are 5 subgraphs that can match the template for this rule about properties.
For each statement, the Boolean result of one root entity is obtained according to whether there exists a subgraph that satisfies the rule statement.
The final Boolean result of one root entity is the logical combination of the Boolean results obtained from each statement.
In this validation process, two different types of logical operators are used. The logical operators inside each statement are used in step 2, which are calculated by one statement on one subgraph. While the logical operators in XML tags are used in step 3, which is the combination of Boolean results from all subgraphs and all statements. There is a common misunderstanding that “the two types of logical operators are equivalent”. While according to the mvdXML documentation and the implementation of mvdXML validation algorithms, they are not equivalent, and usually they can not replace each other.
Usually, the IFC model of a real project typically exceeds millions of nodes, with hundreds of megabytes of data. Although different strategies like caching and pruning are applied in different software implementations, the efficiency of mvdXML validation on large scale models is still a challenge.
Some other researches focused on modularized MVD validation methods. The mvdXML developer team categorized the mvdXML-based automated validation tasks Weise (2014), including the existence of attributes, the size of collections, the uniqueness of values, etc. Yong-Cheol Lee et al. also similarly categorized the rules in MVD Lee et al. (2016a, 2018); Solihin et al. (2015). Such modularized MVD validation methods implement program modules for the commonly-used MVD validation tasks (such as the value of attributes or the existence of relationships), but can not support the validation for arbitrary mvdXML rules.
3 The MVDLite Language
Currently, although mvdXML has been widely accepted by the academic community, not many companies have the ability to customize MVDs according to their own domain concept definitions and exchange requirements. For domain engineers, there is a demand to read and understand MVD rules, so that they can give feedback to the MVD experts, and edit the rules themselves if needed. However, the domain engineers may have never used XML, so it is hard for them to read mvdXML rules without the help of tools like ifcDoc Chipman (2012). In addition, for MVD experts, it is also difficult to write or edit mvdXML correctly without the help of such tools due to the strict XML format and UUID references. As a result, the application of mvdXML in flexible scenarios is limited.
In this paper, MVDLite is proposed as a novel representation of MVD rules. The main features of MVDLite are:
Light-weight: the data size of an MVDLite ruleset is smaller than its equivalent mvdXML ruleset.
Flexibility: compared with the “mvdXML Rule Grammar”, MVDLite is a stand-alone MVD rule language that combines both subgraph structures and value constraints, which is suitable to be flexibly edited without relying on the ifcDoc tool.
Faster validation: the validation algorithm based on the rule structure of MVDLite runs faster on large real-world models.
By mapping the rule segments (about IFC data structures and value constraints) into natural language terms, MVDLite is with good readability for common domain engineers. Besides, the natural language mapping makes MVDLite ruleset easier to be switched between different IFC schema versions (such as IFC2X3 and IFC4).
3.1 The Grammar of MVDLite
The grammar of MVDLite is designed based on three basic ideas:
Combining the data templates, attribute values, and logical operators in one consistent and concise grammar.
Mapping the data structure rule segments into natural language terms, and organize the rules with such natural language terms.
Keeping MVDLite compatible with mvdXML, and supporting bi-directional conversion with mvdXML rules.
There are three types of expressions in MVDLite grammar, the rule expression, concept expression, and abbreviation expression. The rule expression is the core of MVDLite, which represents the data templates, attribute values, and logic operators. The other two are used for replacing data structure definitions with natural language terms, which makes MVDLite easier to use. An example ruleset in MVDLite is shown in Figure 1. The full definition of the MVDLite grammar is included in the Appendix (see Figure 12 and Figure 13).
3.1.1 Rule Expression
The basic grammar structure of an MVDLite rule expression is the “rule chain”. A rule segment is the representation of a rule as a mapping from input nodeset to output nodeset. There are three types of rule segments (attribute segment, metric segment, and compound segment). A rule chain is a sequence of rule segments starting from a root nodeset, in which the output nodeset of the former rule segment is the input nodeset of the latter rule segment.
An attribute segment is a mapping between two nodesets which is defined by an attribute. Each attribute segment has an attribute name after a “->” symbol and the entity type constraint may be attached after “:”. For example, “->IsTypedBy:IfcRelDefinesByType” is an attribute segment, in which each input node is mapped to the linked nodes with this attribute. The attribute name is required but the entity type is optional. When the entity type is omitted, it can be automatically completed from the IFC Schema.
A metric segment is a mapping from the input nodeset to it self, which works as a filter for the nodes. The rule for metrics and values of an attribute is represented as a metric segment. Each metric segment is with a “metric” ([Type], [Value], [Size], [Exists], [Unique]), an operator (=, >, <, >=, <=, !=), and a value (string value, Boolean value, or number value). For example, “[Value]=TRUE” is a metric segment, in which the input nodes with value equals TRUE are kept in the output nodeset.
Several rule segments can be linked as a fragment of a rule chain, and several fragments can be combined with logical operators (AND, OR, XOR, NOT). A compound segment encapsulates the rule chain fragments and the logical combination of such fragments in brackets. A compound segment also acts as a mapping from the input nodeset to the output nodeset, hence it can be embedded into another rule chain. It can either represents a compound filter for a nodeset (when the inner fragments are ended with metric segments) or represents a compound path of nodeset mappings (when the inner fragments are not ended with metric segments).
Some syntactic sugar is added to the MVDLite rule expressions to make the rules easier to write and read. The syntactic sugar does not add or delete information and does not cause ambiguity.
The metric “[Value]” can be omitted by default, so “[Value]=TRUE” can be written as “=TRUE” for short.
The compound segment “(->Name[Value]=’IsExternal’)” for name constraint can be written as “(’IsExternal’)” for short.
“|” can be used to separate several optional values for the same attribute, so “-> NominalValue = 1 | 2” means “-> NominalValue([Value] = 1 OR [Value] = 2)”.
3.1.2 Concept Expression and Abbreviation Expression
The concept expressions and abbreviation expressions are the auxiliary structures in the MVDLite grammar, which are used in mapping the definitions of domain concepts and data structures into natural language terms.
The concept expression explicitly defines the fine-grained domain entity types, and the inheritance of entity types with the keyword “extends”. This idea is consistent with the domain concept definition in mvdXML, but MVDLite supports multi-level inheritance. A subtype of entity is a subset of its parent type, which satisfies all the “definition” conditions of the parent type and inherits all the “constraint” rules from the parent type. Any concept must originate from an IFC entity type.
Keywords “definition” and “constraint” can be added before a set of expressions. A “definition” part contains the name of an entity type (which is equivalent to the name of a ConceptRoot in mvdXML), the inheritance with its parent type, and the applicability rules for distinguishing the subset of entities out from the parent type. A “constraint” part contains the rule constraints for this entity type. Both applicability rules and constraint rules of the parent type are inherited by the subtypes.
The abbreviation expression is used to map some frequently used patterns of rule segments into natural language terms. For example, the path to reach a type property set in IFC4 is “->IsTypeBy:IfcRelDefinesByType ->RelatingType:IfcTypeObject->HasPropertySets:IfcPropertySet”. It can be mapped to an natural language term “typePset”, and this terms can be used to compose other rules. This makes the rule statements more concise and easier to understand by non-IFC-experts.
In addition, by using abbreviations, MVDLite is easy to be switched between different IFC versions (such as IFC2X3 and IFC4).
Between different IFC Schema versions, the changes in schema are mainly about entity types (new types, deprecated types, and change in inheritance), attributes and relationships.
For example, the representation of “the type of an element” in IFC2X3 is started with “IsDefinedBy”, but in IFC4 it changes to “IsTypedBy”.
In many cases, such changed data representation still corresponds to the same domain concept in natural language.
Based on this idea, the different representations of subgraph structures and domain concepts are mapped to natural language terms and placed in the header part of MVDLite. If the rules are organized using the natural language terms, then the ruleset can be switched to a different IFC Schema versions by just changing the mappings in the header, but without changing the contents in the body part.
For example, a term “typePset” is defined as
typePset as (IfcObject)->IsDefinedBy:IfcRelDefinesByType
in the header for IFC2X3. If the term “typePset” is used in the ruleset, then the relevant rules can be switched to IFC4 by replacing the header line as
typePset as (IfcObject)->IsTypedBy->RelatingType
3.2 The Conversion between MVDLite and mvdXML
MVDLite is designed to be compatible with mvdXML. On the one hand, any IFC subgraph structure that can be represented by a ConceptTemplate can also be represented by a rule chain. On the other hand, the metric rule segment supports the same metrics, operators and logical combinations as the mvdXML Rule Grammar. As a result, MVDLite supports bi-directional conversion with mvdXML. In this section, the conversion between MVDLite and mvdMXL V1.1 will be introduced.
3.2.1 Converting MVDLite to mvdXML
The conversion from MVDLite to mvdXML can be performed in two major steps.
(1) Parsing ConceptTemplates. One IFC entity type may be used in multiple rules, and each rule represents a subgraph structure. The union of the subgraph structures can be converted into a ConceptTemplate, in which each node is assigned with a RuleID.
(2) Generating mvdXML Rule Grammar statements. Using the RuleIDs, the metric rule segments in MVDLite can be rewritten as mvdXML Rule Grammar statements. The original metrics and logical operators are kept in the new rule statements.
3.2.2 Converting mvdXML to MVDLite
An mvdXML rule statement is the logical combination of the RuleID-metric pairs. The conversion from mvdXML to MVDLite can be performed in two major steps.
(1) Representing the RuleID-metric pairs in rule chains. For each RuleID, the path from root entity to this RuleID can be represented as a chain of attribute segments in MVDLite, and the metric of this RuleID can be represented as a metric segment linked at the end of the chain.
(2) Merging the rule chains. The rule chains are merged according to the logical operators (AND, OR, XOR, NOT) in the mvdXML rule statement. The branches of rule chains are merged at the lowest common ancestor nodeset, to make the subgraph structure in MVDLite consistent with the ConceptTemplate in mvdXML.
As introduced in Section 2.2, in addition to the logical operators in mvdXML rule statements, there is another type of logical operators in XML tags, such as “<TemplateRules operator=‘‘or’’> ... </TemplateRules>”. This type of logical operators can be represented in MVDLite as the logical combination of rule chains at the root entity nodesets.
3.2.3 The scope of mvdMXL and MVDLite rules
To illustrate the feasibility of the bi-directional conversion between mvdXML V1.1 and MVDLite, another question is to be discussed: do mvdXML and MVDLite have the same scope of rules? The comparison is made in four aspects: subgraph template structures, metrics, logical operators, and natural language tags.
Subgraph template structures. Both mvdXML ConceptTemplate and MVDLite rule chain can represent arbitrary subgraph structure. There is an implicit constraint in mvdXML that in a ConceptTemplate, one RuleID can be assigned to different attributes, but one attribute can not be duplicated and assigned with different RuleIDs. This ensures that the branch point of two RuleIDs on the ConceptTemplate is at the lowest common ancestor of the two RuleIDs. This feature is used in the mvdXML-to-MVDLite conversion.
Metrics. The metrics ([Type], [Value], [Size], [Exists], [Unique]) and operators (=, >, <, >=, <=, !=) are the same in MVDLite and mvdXML. However, the metrics and operators can not be applied to the root entities in mvdXML, since there is an implicit constraint that the RuleIDs can not be assigned to the root entities. By supporting the metrics on root entity set, the MVDLite rule can be used to check the global existence of a certain node type. For example, MVDLite supports the global existence rules like “IfcWall[Exists]=true” and “IfcProject[Size]=1”.
Logical operators. As mentioned in Section 3.2.2, both two types of mvdXML logical operators have their own equivalent representation in MVDLite.
Natural language tags. The natural language tags (such as the name of ExchangeRequirements and the “mandatory” or “recommended” tags of rules) are essential components in mvdXML structure. In MVDLite, such tags are not included in the rule grammar, but they can be attached to the ruleset in the comments. For example, in our implementation of MVDLite-to-mvdXML converter, the tags are included in a JSON string in the comments, and such tags will be added into mvdXML in the conversion task. If there lack such comments, the MVDLite rules are still feasible and can be validated. And in the conversion, some default tags and names are added to ensure that the structure of the generated mvdXML is complete.
Figure 2 shows an example mvdXML ruleset and an MVDLite ruleset that can be converted to each other. This is a simple rule for the existence of attributes. The MVDLite rule has 5 rows, while the mvdXML rule has 94 rows.
By supporting bi-directional conversion, rulesets written in MVDLite can be converted to mvdXML to support existing mvdXML-based applications; the existing mvdXML rulesets can also be converted to MVDLite for easier reading and editing, and supporting MVDLite-based efficient MVD validation and partial model extraction.
4 Efficient MVD Validation with MVDLite
Different from the separation of subgraph templates and attribute value rules in mvdXML, MVDLite represents them in the unified “rule chain” structure. Based on this, a faster MVD validation algorithm is proposed, which is no longer performed for each root entity separately but can be performed on the set of all root entities of a certain type.
4.1 The MVDLite Validation Algorithm
In Section 3.1.1, the three types of rule segments (attribute segment, metric segment, and compound segment) and the rule chain structure have been introduced. Each rule segment is a mapping from input nodeset to output nodeset, and a rule chain is a sequence of such mappings. The proposed MVD validation algorithm is performed by calculating the mappings on all rule segments. The algorithm goes a round-trip path on a rule chain: first go forward through the chain find the paths that can pass the constrains of all rule segments, and then backtrack to find the root entity set where these paths started. The detailed visualization and examples of the calculations on different rule segments are shown below.
Calculating attribute segment mappings. An attribute segment is a mapping from one nodeset to the linked nodeset, as shown in Figure 5. Each nodeset consists of nodes of the same type or the same RuleID, and each edge between the nodes corresponds to an attribute in the IFC data. In this mapping, one source node may point to multiple target nodes, and a target node may be pointed by multiple source nodes. Figure 5 shows an example attribute segment, which is represented as a mapping from an “IfcPropertySet” nodeset to an “IfcProperty” nodeset.
Calculating metric segment mappings. Metric segments act as filters for the nodesets. The five types of metrics ([Type], [Value], [Size], [Exists], [Unique]) can be divided into two groups:
The [Type] and [Value] metrics can be evaluated by each single node in the nodeset, and they act as filters for the nodeset itself. They are called “single metric segments”. Figure 5 shows an example single metric segment “[Value]>=0” as a filter for a IfcValue nodeset. In this filter, a node conforming to the rule links to itself, and the remaining nodes link to nothing. Thus a single metric segment is a mapping from a nodeset to the set itself.
The [Size], [Exists] and [Unique] metrics act as filters for the parent nodeset. These metrics can not be evaluated by a single node, but can only be evaluated by a collection of nodes. They are called “collection metric segments”. Figure 5 shows an example collection metric segment “[Size]>1” as a filter for the IfcPropertySet nodes in the parent nodeset. It must be evaluated in combination with the attribute segment “->HasProperties” in front. The collection metric segment “[Size]>1” is a mapping from a nodeset to the parent nodeset, and the combination “(->HasProperties[Size]>1)” is a mapping from the parent nodeset to the parent nodeset itself.
Rule chain and compound segment. If a rule chain is ended with a metric segment, then by going through a round-trip path on the rule chain, a subset of the root nodeset can be obtained, in which includes the root entities that have paths to pass all segments in this rule chain. A compound segment can encapsulate this round-trip in brackets, so that it works as a filter of a nodeset that can be added to another rule chain as a segment. The visualization of a compound segment as a filter is shown in Figure 6(a).
If a fragment of rule chain is not ended with a metric segment, it can be visualized as the linkage of node mappings. Such node mappings can be combined with logical operators AND, OR, NOT in a compound segment, which corresponds to the intersection, union, complement operations of output nodesets, respectively. The visualization of a compound segment as the combination of mappings is shown in Figure 6(b).
4.2 Comparison of Different MVD Validation Algorithms
The aim of MVD validation algorithms is to determine the existence of a subgraph conforming to an MVD rule. An efficient MVD validation algorithm is to visit as few nodes as possible to determine the existence of a subgraph that conforms to a rule.
As introduced in Section 2.4, due to the separation of templates and rule statements, the mvdXML validation algorithm is performed by first matching templates to find all subgraphs, and then checking attribute values to find the existence of a conforming subgraph. Figure 7 (a) shows the brief schematic diagram of mvdXML validation algorithm.
Some strategies can be used to speed up the mvdXML validation. For example, the xBIM mvdXML validation tool xBimTeam (2016); Weise et al. (2016) uses the caching strategy. For each ConceptTemplate, one root entity is expanded as a table, in which each column corresponds to a RuleID and each row corresponds to a subgraph that can match the ConceptTemplate. This table is catched and reused if the ConceptTemplate is used in multiple rules. Another strategy can be used in mvdXML validation is pruning. For each ConceptRoot, the applicability rule is evaluated first to prune out some of the root entities, hence the number of entities to be checked can be reduced.
Figure 7 (b) shows the schematic diagram of the MVDLite validation algorithm, which is performed by going through the round-trip path of a rule chain. Compared with mvdXML validation algorithm, the reason why the MVDLite-based validation is faster can be explained by that MVDLite validation algorithm can view fewer nodes to determine the existence of a subgraph that conforms to a rule:
(1) Calculating on the nodesets. Rather than the “subgraph-by-subgraph” traversal of mvdXML validation, the basic unit in MVDLite validation is a nodeset, which is composed of the root entities of the same type or the nodes with the same RuleID. One node is needed to be visited at most twice (forward and backward in a round-trip), which speeds up the calculation since one same node can usually be referenced by multiple root entities.
(2) Multi-level inheritance. Rather than the “entity-by-entity” traversal in the root nodeset in mvdXML validation, the MVDLite validation algorithm is able to get the results of all entities in the root nodeset just through one round-trip path on the rule chain. In addition, since each type of entity is a subset of its parent type, the calculation can start from the nodeset of its parent type.
(3) Pruning in the deep. Since MVDLite validation is based on the mapping between nodesets, pruning can be performed on every nodeset before mapping to the next nodeset. While in mvdXML-based validation, the pruning can only be performed on the root nodeset, since every node in a subgraph is already visited at least once in the “matching template” step.
(4) Caching in the deep. In the MVDLite validation process, each nodeset corresponds to the prefix of the rule chain from the root to this segment. The nodesets can be reused if the same prefix occurs again in other rules. This usually happens. For example, there may be multiple rules for different properties in the same property set. The nodesets are well pruned and easy to be cached by creating a mapping from the prefix strings to the nodesets. While in mvdXML, the caching can only be performed without the deep pruning, which results in larger cached data and longer query time.
The experimental comparisons of the different MVD validation algorithms are listed in Section 5.1.
5 Experiments and Applications
The parsers for the IFC files and the MVDLite statements are implemented based on ANTLR Parr and Quong (1995) in C#. Based on these two parsers, a command-line tool for MVDLite validation is implemented, which inputs the model and the ruleset, then outputs the validation reports. In this section, the performance of our MVD validation algorithm is compared with the mvdXML validation algorithm on several models and rulesets in different sizes (see Section 5.1). Then a case study is provided to show the user-friendly workflow for customizing an enterprise-level MVD, and the applications in MVD validation and partial model extraction on a large real-world model (see Section 5.3).
5.1 MVDLite Validation Experiment
and a BIMServer-based open source toolopensourceBIM (2014); Zhang et al. (2014). The BIMServer-based tool has not been updated in recent years thus does not support the mvdXML V1.1. Therefore, our MVDLite validation tool is mainly compared with the xBIM-based tool. To fairly compare the efficiency of the algorithm, an mvdXML validation tool is also implemented based on our own IFC parser. The experiments in this section compare the efficiencies of these three tools.
(2) The models. Since most of the publicly available MVD rulesets are for IFC4 Schema, in our experiments several IFC4 models in different sizes are used. The models are shown in Figure 8, and the sizes of these IFC models are listed in Table 1.
Duplex.ifc A small sample model of a duplex building provided by NIBS NIBS (2012). This model is converted and merged from two IFC2X3 models, including an architectural model and an MEP model.
Office.ifc A medium-size sample model of an office building provided by NIBS NIBS (2012). This model is converted and merged from three IFC2X3 models, including an architectural model, a structural model, and an MEP model.
B01.ifc A model of the B01 underground storey of a commercial complex building. This model is exported from Autodesk Revit, which includes building elements in architecture, structure and MEP disciplines. This model is the real-world model in the case study in Section 5.3.
|file size||52 MB||193 MB||841 MB|
|mvdXML||file size||58 KB||1,065 KB||1,453 KB||6,767 KB|
|“Concept”s (has rules)||23||319||331||3,404|
|MVDlite||file size||10 KB||231 KB||240 KB||926 KB|
(3) The rulesets. The sizes of these mvdXML rulesets and the corresponding MVDLite rulesets are listed in Table 2.
UnitTest.mvdxml A small unit test ruleset used in the xBIM mvdXML validation tool, which includes several rules about walls xBimTeam (2016).
RV.mvdxml The IFC4 Reference View V1.1 draft provided by buildingSMART buildingSMART (2018).
DTV.mvdxml The IFC4 Design Transfer View V1.1 draft provided by buildingSMART buildingSMART (2018).
O&M.mvdxml The MVD for operation and maintenance model delivery of a commercial complex building. This ruleset is the enterprise-level MVD in the case study in Section 5.3. Since this ruleset is developed according to the enterprise classification standard, it is only tested on the model “B01.ifc”.
Among the the rulesets, “UnitTest.mvdxml”, “RV.mvdxml” and “DTV.mvdxml” are slightly modified from different mvdXML versions to match the mvdXML V1.1 format, and then converted to equivalent MVDLite ruleset. “O&M.mvdxml” is originally in MVDLite and then converted to the equivalent mvdXML ruleset.
(4) Experimental results. The time usage of three MVD validation algorithms in ten tasks are listed in Table 3, in which the xBIM-based tool fail to finish the “B01-O&M” task within 12 hours. The experimental results show that the MVDLite-based validation algorithm is much faster than the mvdXML-based validation algorithms in all tasks. Both MVDLite-based and mvdXML-based validation algorithms are implemented on the same IFC parser, to eliminate the performance differences between different IFC parsers. According to this comparison, we found that the MVDLite-based validation algorithm is still several times faster in MVD validation on large IFC models. It is worth mentioning that in the ruleset “O&M”, the domain concepts have clear inheritance relationships, and MVDLite can effectively use the concept inheritance to accelerate the calculation, which results in much faster speed in validation.
(5) The effects of caching and pruning strategies. The enhanced caching and pruning strategies in the MVDLite validation algorithm have been introduced in Section 4.2. Due to the nodeset mappings and the rule chain structure, the caching and pruning can go deep into every nodeset rather than just the root entity sets. In order to verify the effects of caching and pruning strategies, an additional experiment is performed when switching off each strategy. The time usage in six tasks are listed in Table 4. The results show that both caching and pruning strategies can remarkably speed up the calculation.
|model||ruleset||Full MVDLite||Caching off||Pruning off||Both off|
5.2 Partial Model Extraction with MVDLite
The proposed fast MVD validation algorithm can efficiently find a set of nodes that meet certain conditions. This algorithm can be further applied in partial model extraction tasks, which can extract the nodes and relationships involved in the MVDLite ruleset, and meanwhile to ensure that the result is still a valid IFC file. The partial model extraction is performed in three steps:
(1) Selecting the root entity set. In an MVDLite ruleset, the involved root entities are defined as domain concepts. According to the applicability rules in the “definition” statements, the root elements can be selected as an initial extracted nodeset.
(2) Extracting dependency nodes. In an IFC model, most of the directly referenced nodes in the data list of a node are necessary dependencies. Such dependency nodes and their dependencies are iteratively added into the extracted nodeset.
(3) Filtering relationships by rules. Some other nodes are indirectly referenced by “IfcRelationship” nodes. By performing MVD validation algorithm, the referenced nodes involved in the ruleset can be selected and added to the extracted nodeset.
The partial model extraction task is performed on the model “B01.ifc” according to the ruleset “O&M.mvdlite”, which extracts the building elements, the properties and geometry representations involved in operation and maintenance. The algorithm uses 155 seconds to finish the partial model extraction task. The comparison of the original model and the extracted partial model are listed in Table 5, and the two models are visualized in Figure 9. Compared with the original model of 841 MB, the extracted model is only 214 MB in size. The building elements and properties that are involved in the operation and maintenance phase (mainly MEP elements, walls, columns, and beams) are extracted as a partial model, while the redundant elements with complicated geometries and properties but unrelated to the operation and maintenance ruleset are excluded from the partial model.
In addition to extracting a partial model from an existing ruleset, the partial models can also be extracted from some flexibly written MVDLite statements. Figure 10 shows three examples of extracting partial models from “Office.ifc” by several lines of MVDLite statements (the header part for each statement is omitted). The three partial models are for “external walls”, “elements contained in Level 2” and “loadbearing elements”, respectively.
|original model||extracted model|
|file size (MB)||841||214|
5.3 Case Study
This case study is about an MVDLite-based process for enterprises to customize MVD rules and to use the MVD rules for model validation and data exchange. A workflow for developing MVD rules is proposed to involve both domain engineers and IT engineers in in customizing enterprise-level MVDs. The domain engineers and managers are familiar with the domain concepts and exchange requirements, but they are not familiar with the IFC data format and the MVD rule structure. On the contrary, the IT engineers are familiar with the data formats of IFC and MVD, but they are not familiar with the domain-specific concepts and requirements. The workflow is implemented based on the idea of separating the domain-specific rules from the schema-specific data definitions, which is shown in Figure 11 (a).
First, the IT engineers define the abbreviation expressions in a header (see Figure 11 (b)), in which the data structures of properties and relationships involved in the ruleset are represented as abbreviation expressions. Second, an Excel template is generated to list the domain entity types according to the classification standard (see Figure 11 (c)), and then the form is handed to the domain engineers and managers to fill in the detailed requirements, including the options of whether they should be included in the partial model, the naming rules, and the requirements for properties. Next, an MVDLite ruleset is generated using the abbreviation header and the collected requirements, which is then converted to an equivalent mvdXML ruleset. Finally, the generated rulesets are validated on a sample model, and the results are fed back to the IT engineers and domain engineers. The header and the forms are edited accordingly to revision the ruleset to meet the exchange requirements.
The workflow is implemented in developing “O&M.mvdlite” for operation and maintenance model delivery of a commercial complex building. The result ruleset is used for MVD validation and partial model extraction on the model “B01.ifc”. The comparison of time usage in the validation of ruleset “O&M” on the model “B01.ifc” is shown in the last row of Table 3. The result of partial model extraction is shown in Section 5.2. In the experiments, our method shows good efficiency on large real-world IFC models and rulesets.
6 Conclusion and future work
In this paper, MVDLite is proposed as a light-weight representation for MVD rules, which extends the application of MVD in flexible scenarios. Based on the rule chain structure of MVDLite, a new MVD validation algorithm is proposed, which is remarkably faster in MVD validation on large real-world IFC models. An MVDLite-based process is proposed to customize enterprise-level MVDs model validation and data exchange.
Currently, MVDLite is compatible with the mvdXML V1.1. In a document released by the mvdXML team Weise (2014), some possible updates for mvdXML are under discussion, including some grammars that are not supported by mvdXML V1.1 yet. The current mvdXML grammar update is basically case-oriented: new features are added mainly based on the need proposed by industry. However, there is few discussion on the logic foundation and the completeness of MVD rule languages. The theoretical analysis of MVD will be our future work.
This research is sponsored in part by the NSFC Program (No. 61527812), the National Science and Technology Major Project of China (No. 2016ZX 01038101), the MIIT IT Funds of China (Research and Application of TCN Key Technologies), the National Science and Technology Support Program of China (No. 2015BAG14B01-02), the National Key R&D Program of China (No. 2016QY07X1402, 2018YFB0505400), and the Wanda Research Project (Research on Commercial Complex Building Information Model Storage Technology).
- A model independent and user-friendly querying system for indoor spaces. In Proceedings of the 20th International Conference on Management of Data, pp. 17–28. External Links: Cited by: §2.1.
- IfcOWL: a case of transforming express schemas into ontologies. Artificial Intelligence for Engineering Design, Analysis and Manufacturing 23 (1), pp. 89–101. External Links: Cited by: §2.1.
- Topological analysis of 3D building models using a spatial query language. Advanced Engineering Informatics 23 (4), pp. 370–385. External Links: Cited by: §2.1.
- IfcDoc/IfcKit/exchanges/. Note: Available from: https://github.com/buildingSMART/IfcDoc/tree/master/IfcKit/ exchanges (accessed January 2020) Cited by: item 2, item 3.
- mvdXML: specification of a standardized format to define and exchange Model View Definitions with Exchange Requirements and Validation Rules. Note: Available from: http://www.buildingsmart-tech.org/specifications/ mvd-overview/mvdxml-releases/mvdxml-1.1 (accessed October 2018) Cited by: §1, §2.1, §2.2.
- ifcDoc Tool Summary. Note: Available from: http://www.buildingsmart-tech.org/specifications/ specification-tools/ifcdoc-tool/ifcdoc-beta-summary (accessed October 2018) Cited by: §1, §3.
- Checking spatio-semantic consistency of building information models by means of a query language. In Proceedings of the International Conference on Construction Applications of Virtual Reality, Note: isbn:9780992716103 Cited by: §2.1.
- A rule-based methodology to extract building model views. Automation in Construction 92, pp. 214–229. External Links: Cited by: §2.3.
- Automatic rule-based checking of building designs. Automation in construction 18 (8), pp. 1011–1033. External Links: Cited by: §2.4.
- BIMQ 2019. Note: Available from: http://demo.bim-q.de (accessed May 2019) Cited by: §1.
- IFC model view definition format. Note: Available from: https://www.buildingsmartsingapore.org/news/news-docs/ 20060410_IFC_MVD_Format.pdf (accessed October 2018) Cited by: §1, §2.1.
- A SPARQL query engine for binary-formatted IFC building models. Automation in Construction 95, pp. 46–63. External Links: Cited by: §2.1.
- Extended process to product modeling (xPPM) for integrated and seamless IDM and MVD development. Advanced engineering informatics 27 (4), pp. 636–651. External Links: Cited by: §2.1.
- Modularized rule-based validation of a BIM model pertaining to model views. Automation in Construction 63, pp. 1–11. External Links: Cited by: §2.4.
- An ontology-based approach for developing data exchange requirements and model views of building information modeling. Advanced Engineering Informatics 30 (3), pp. 354–367. External Links: Cited by: §2.3.
- Logic for ensuring the data exchange integrity of building information models. Automation in Construction 85, pp. 249–262. External Links: Cited by: §2.4.
- BIMQL – an open query language for building information models. Advanced Engineering Informatics 27 (4), pp. 444–456. External Links: Cited by: §2.1.
- Common Building Information Model Files and Tools. Note: Available from: https://www.nibs.org/page/bsa_commonbimfiles (accessed May 2019) Cited by: item 1, item 2.
- mvdXMLChecker. Note: Available from: https://github.com/opensourceBIM/mvdXMLChecker (accessed May 2019) Cited by: §2.4, §5.1.
- ANTLR: a predicated-LL (k) parser generator. Software: Practice and Experience 25 (7), pp. 789–810. External Links: Cited by: §5.
- SimpleBIM: from full ifcOWL graphs to simplified building graphs. In eWork and eBusiness in Architecture, Engineering and Construction: ECPPM, pp. 11–18. Note: isbn:9781315386898 Cited by: §2.1.
- Integrating relational algebra into a visual code checking language for information retrieval from building information models. In Proceedings of the 16th International Conference on Computing in Civil and Building Engineering (ICCCBE), Note: isbn:9784990737122 Cited by: §2.1.
- An integrated process for delivering IFC based data exchange. Note: Available from: http://iug.buildingsmart.org/idms/methods-and-guides (accessed October 2018) Cited by: §1, §2.1, §2.3.
- Simplebim – mvdXML add-on for Simplebim 7.1. Note: Available from: http://www.datacubist.com/sdm_downloads/mvdxml- addon-simplebim-7/ (accessed October 2018) Cited by: §2.4.
- Toward robust and quantifiable automated IFC quality validation. Advanced Engineering Informatics 29 (3), pp. 739–756. External Links: Cited by: §2.4.
- Protégé. Note: Available from: https://protege.stanford.edu/ (accessed December 2019) Cited by: §2.3.
- Generic BIM queries based on the IFC object model using graph theory. In Proceedings of the 16th International Conference on Computing in Civil and Building Engineering (ICCCBE), Note: isbn:9784990737122 Cited by: §2.1.
- Configurable model exchanges for the precast/pre-stressed concrete industry using semantic exchange modules (SEM). In International Conference on Computing in Civil Engineering, External Links: Cited by: §2.1.
- Semantics of model views for information exchanges using the industry foundation class schema. Advanced engineering informatics 26 (2), pp. 411–428. External Links: Cited by: §2.3.
- An ontological approach to building information model exchanges in the precast/pre-stressed concrete industry. In Construction Research Congress 2012: Construction Challenges in a Flat World, pp. 1114–1123. External Links: Cited by: §2.3.
- An ontology-based analysis of the industry foundation class schema for building information model exchanges. Advanced Engineering Informatics 29 (4), pp. 940–957. External Links: Cited by: §2.3.
- Generalised model subset definition schema. In Proceedings of the CIB-W78 Workshop, Note: isbn:0908689713 Cited by: §2.1.
- IFC model checking based on mvdXML 1.1. In eWork and eBusiness in Architecture, Engineering and Construction: ECPPM, pp. 19. Note: isbn:9781315386898 Cited by: §2.4, §4.2, §5.1.
- mvdXML requirements and examples: review of a standardized format to define and exchange model view definitions with exchange requirements and validation rules. Note: Available from: https://github.com/BuildingSMART/mvdXML/tree/master/mvdXML1.1 (accessed October 2018) Cited by: §2.4, §6.
- Information delivery manual: guide to components and development methods. Note: Available from: http://iug.buildingsmart.org/idms/development (accessed October 2018) Cited by: §1.
- A visual BIM query language. In eWork and eBusiness in Architecture, Engineering and Construction: ECPPM, pp. 157–64. Note: isbn:9781138027107 Cited by: §2.1.
- XbimMvdXML. Note: Available from: https://github.com/xBimTeam/XbimMvdXML (accessed May 2019) Cited by: §4.2, item 1, §5.1.
- Model view checking: automated validation for IFC building models. In eWork and eBusiness in Architecture, Engineering and Construction: ECPPM, pp. 123. Note: isbn:9781315736952 Cited by: §1, §2.4, §5.1.
- Towards model view definition on semantic level: a state of the art review. In Proceedings of the 20th International Workshop: Intelligent Computing in Engineering, Note: isbn:9781634395496 Cited by: §1.
- BimSPARQL: domain-specific functional sparql extensions for querying RDF building data. Semantic Web (Preprint), pp. 1–27. External Links: Cited by: §2.1.
- Ontology-based partial building information model extraction. Journal of Computing in Civil Engineering 27 (6), pp. 576–584. External Links: Cited by: §2.1.