Industry Foundation Classes (IFC) is a standard open data schema for Building Information Models (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 research 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).
However, few companies currently have the ability to customize MVDs based on their own exchange requirements. Using mvdXML requires extensive knowledge of the data structure of IFC Schema and the mvdXML format, as well as the good understanding of exchange requirements See et al. (2012); Zhang et al. (2013). On the one hand, mvdXML is not a human-readable format, which involves complicated XML structures to represent the data template rules, attribute value rules, and logical operations separately. On the other hand, mvdXML highly relies on a specific version of IFC Schema (such as IFC4 or IFC2X3), and developers need to know the IFC Schema very well to edit the rules correctly. It is hard for the vast majority of domain engineers and project managers to read, write, and edit MVDs using mvdXML. Although tools like ifcDoc Chipman (2012) and BIMQ GmbH (2019) have provided graphical user interfaces for visualizing and editing mvdXML files, one still needs a good understanding of both IFC Schema and mvdXML format to use the tools.
In order to lower the knowledge threshold for MVD development, and to improve the readability of MVD rules, in this paper, MVDLite is proposed as a novel light-weight MVD language. By using natural language rather than data structure definitions to organize the rules, MVDLite has better readability than mvdXML, and the rules can be unbound with a specific IFC Schema version, i.e. the same MVDLite ruleset can be applied to both IFC2X3 and IFC4 models.
MVDLite is compatible with mvdXML, but uses a novel “rule chain” structure to unify the separated data template rules and attribute value rules in mvdXML. Based on this novel rule structure, an efficient MVD validation algorithm is proposed. By performing node set calculations on the “rule chain” structure, the MVD validation process can be several times faster than the mvdXML-based validation algorithm on large real-world models.
Our main contributions are listed as follows.
MVDLite is proposed as a novel representation for MVD rules, which uses the “rule chain” to simplify the rule structure and to increase the readability and usability (see Section 3).
A new MVD validation algorithm is proposed based on the “rule chain” structure, which is much faster than mvdXML-based MVD validation algorithm (see Section 4).
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 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 and exchange requirements, 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 the process and exchange requirements in IDM. The xPPM provides a tool to edit the process and exchange requirements, and mapping the domain entities to IFC data types. The Semantic Exchange Modules (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 exchange requirements, SEM focuses on the definition of domain concepts, and GMSD focuses on the rule constraints for partial models.
The mvdXML is proposed as an integrated format for the specification of exchange requirements, domain concepts, and rule constraints Chipman et al. (2016). It is used in an integrated IDM-MVD process for IFC data exchange recommended by buildingSMART See et al. (2012). According to this document about integrated IDM-MVD process See et al. (2012), the recommended process for MVD development is:
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).
In mvdXML, part of contents are natural language descriptions about exchange requirements and domain concepts, and the other part of contents are rules for data templates (in XML tags) and for attribute values (in mvdXML Rule Grammar statements). The rules are used to support computer applications, but with poor readability for human.
The data template rules and attribute value rules are represented separately in mvdXML. The data template rules are represented as ConceptTemplates, in which the subgraph pattern, attributes, and entity types are defined in a nested XML structure. A RuleId is assigned to each attribute, so it can be used to form the statements for attribute value rules. In the rule statements, the RuleIds are combined with five types of metrics ([Type], [Value], [Size], [Exists], [Unique]).
Since the data template rules and attribute value rules are separated in mvdXML, there are also two different types of logical operators. Usually, for one single root entity, there can be multiple subgraphs that can match a ConceptTemplate. For example, the same “IfcElement” node can link with different “IfcProperty” nodes on different subgraphs, each with different property names and property values. The logical operators between different attribute inside one subgraph are represented as keywords in the rule statements (AND, OR, XOR, NOT), while the logical operators between different subgraphs are represented in the XML structure, such as “<TemplateRules operator="or"> ... </TemplateRules>”
In mvdXML, a ConceptRoot corresponds to a sub-type of domain entity. In a ConceptRoot, there are two groups of rules: the Applicability rules and the Concept rules. Applicability rules are like “IF” conditions, which distinguishes the elements of this sub-type from all parent type elements. Concept rules are like “THEN” conditions, which defines the rule constraints of data according to the exchange requirements.
2.3 The Knowledge Threshold in 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.” MVD experts have a lot of work, binding domain concepts, understanding exchange requirements, drawing diagrams, editing mvdXML files, and writing rule constraints in the mvdXML Rule Grammar. However, since the development of MVD requires both domain knowledge (about domain concepts and exchange requirements) and data knowledge (IFC data structure and mvdXML format), the high knowledge threshold leads to few competent people. Although there are visual tools like ifcDoc Chipman (2012) and BIMQ GmbH (2019) for editing mvdXML rules, the workload of MVD development is still huge for MVD experts.
Although mvdXML has been widely accepted by the academic community, it is still hard for common domain engineers and project managers to understand the rules and logic in mvdXML, and to customize their own MVDs using mvdXML. The main reasons are as follow:
Unfamiliar with IFC Schema. It’s hard for the domain engineers to understand the data types, inheritance, and the data structure in IFC files.
Hard to read the XML structure. It’s hard for human readers to understand the rules in mvdXML since in order to understand the separated data template rules and attribute value rules, the readers need to search the full document frequently to find the references by UUIDs and RuleIds.
Hard to write the XML structure. It is hard to ensure the correct XML structures without the help of tools like ifcDoc, but it is also hard for domain engineers to use such tools since they are unfamiliar with the IFC Schema.
Misunderstand the logical operators. The non-MVD-expert readers can easily misunderstand and misuse the two different types of logical operators in mvdXML Rule Grammar statements and in TemplateRules tags.
Bound with specific IFC Schema. The exchange requirements for domain concepts and properties usually do not change according to different IFC Schema versions. However, the mvdXML rules must be bound to a specific applicable IFC Schema version. It is hard to switch the mvdXML rules from one schema to another.
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, similar to mvdXML, ontology is also a diagrammatic representation of domain concepts, which also requires expertise in IFC Schema and semantic technology. For common companies, creating the domain ontology for the first time is still time consuming and laborious. The ontology-based approach does not significantly lower the knowledge threshold and reduce the workload. The knowledge threshold is transformed from mvdXML to ontology, and the workload is transformed from ifcDoc to OWL editing tools like Protégé.
In summary, the high knowledge threshold in both domain knowledge and data knowledge leads to few of MVD experts, and the insufficient usability of mvdXML format and editing tools makes it difficult for domain engineers and project managers to understand and participate in MVD development. Therefore, it is hard for common companies to customize MVDs based on their own exchange requirements.
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), BIMserver Zhang et al. (2014), and Simplebim simplebim (2018).
In mvdXML, since the rules for data templates and for attribute values are represented separately, the current MVD validation algorithms all have similar implementations based on graph traversal:
For each rule, finding the root entity set.
Taking one root entity each time, and expanding the root entity to find all the subgraphs that match a ConceptTemplate structure.
Checking all subgraphs to find whether there exists a subgraph that satisfies the rule statement.
Usually, the IFC model of a real project typically exceeds millions of nodes, with hundreds of megabytes of data. The efficiency of graph-traversal-based MVD validation on large scale models is problematic.
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
In Section 2.3 the reason why it is hard for domain engineers and project managers to customize MVDs using mvdXML have been discussed. In this paper, MVDLite is proposed as a human-readable MVD language to lower the knowledge threshold of MVD development for non-IFC-experts.
3.1 The Grammar of MVDLite
The grammar of MVDLite is designed based on three basic ideas:
Representing the data templates, attribute values, and logical operators in a consistent and concise grammar, which makes MVDLite more readable and editable.
Using natural language rather than data structure definitions to organize the rules, which decouples the rules with specific IFC Schema version and makes MVDLite easier to use for non-IFC-experts.
Keeping MVDLite compatible with mvdXML, and supporting bidirectional 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 11 and Figure 12).
3.1.1 Rule Expression
The basic grammar structure of an MVDLite rule expression is the “rule chain”, which starts with a root concept and followed by a chain of rule segments. There are three types of rule segments in the rule chain:
Attribute Segment. The path from the root entity to a “RuleId” is represented as a chain of attribute segments. 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, and the entity type constraint “:IfcRelDefinesByType” can be omitted.
Metric Segment. 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.
Compound Segment. The compound segment is used to represent the side branches of a rule chain. One or more rule chain branches can be enclosed in parentheses, and combined with logical operators (AND, OR, XOR, NOT). In this way, the combination of branches acts as a single rule segment, which can be added to another rule chain as a segment. For example, “(->Name[Value]=’IsExternal’)” is the compound segment representing a branch of rule.
The rule chain is composed of the above three types of rule segments. There are special requirements for the position of the segments on the rule chain. A metric segment must be at the end of a chain (or a branch of the chain), while an attribute segment must be in the middle of a chain.
The MVDLite rule expression also supports some syntactic sugar to make the rules easier to write and read:
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 also be written as “(’IsExternal’)” for short.
“|” can be used to separate several optional values for the same attribute, so “-> NominalValue = 1 | 2” means “-> NominalValue( = 1 OR = 2)”.
The rule chain is designed to be compatible with the mvdXML Rule Grammar. It supports the same metrics, logical operators, and value types as the mvdXML Rule Grammar. In addition, all the ConceptTepmlate structures in mvdXML can be represented using the rule chain structure. Based on the rule chain structure, one rule expression is the combination of one or more rule chains with “AND, OR, XOR, NOT” operators, which is equivalent with the logical combination in XML tags in mvdXML. Before a set of rule expressions, the keyword “definition” or “constraint” is used to distinguish the rules. The “definition” rules are equivalent with the “Applicability” tags in mvdXML, which contains the rules for distinguishing the entities out of all the parent type entities. The “constraint” rules are equivalent with the “Concepts” tags in mvdXML, which contains the rule constraints of data for the exchange requirements. In this way, every mvdXML rule can be represented using MVDLite rule expressions.
The rule chain structure in MVDLite is able to represent the data templates, attribute values, and logical operators in a united rule structure, which makes MVDLite readable and editable. In addition, based on the rule chain structure, a more efficient MVD validation algorithm can be proposed, which is introduced in Section 4.
3.1.2 Concept Expression and Abbreviation Expression
The concept expressions and abbreviation expressions are the auxiliary structures in the MVDLite grammar. By replacing the data structure definitions with natural language terms, the concept expressions and abbreviation expressions make MVDLite ruleset easier to read and understand.
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. Compared with mvdXML, the concept expression supports multi-level inheritance. A subtype satisfies all the “definition” conditions of the supertype and inherits all the “constraint” rules from the supertype. Any concept must originate from an IFC entity type.
The abbreviation expression is used to define the abbreviation of some frequently used patterns of rule segments on the rule chains. It not only shortens the rule statements, but also replaces the data structure definitions (attribute names and entity types) with natural language terms. In this way, without a deep understanding of IFC data structure, the readers can still read the rules, edit the rules, and check the correctness of rules. For example, the path to reach a type property set in IFC4 is “->IsTypeBy:IfcRelDefinesByType ->RelatingType:IfcTypeObject->HasPropertySets:IfcPropertySet”. This long rule segments can only be understood by a person with good knowledge of IFC data structures, and it is hard to be written correctly without referring to the IFC Documentation. By defining an abbreviation “typePset” for this long rule segments, the MVDLite rule become much easier to read and write.
In addition, the abbreviation expression can make the MVDLite rules unbound with a specific IFC Schema version. For example, different from IFC4, there is no “IsTypeBy” relationship in IFC2X3. However, just replacing the definition of “typePset” with the IFC2X3 representation “->IsDefinedBy: IfcRelDefinesByType->RelatingType:IfcTypeObject->HasPropertySets: IfcPropertySet”, the previous rules written with “typePset” can be also applied to IFC2X3 files. The usage of abbreviation expression improves the compatibility of MVD rules and reduces the duplicate work in converting MVDs between different IFC Schema versions.
3.2 The Conversion between MVDLite and mvdXML
MVDLite is designed to support bidirectional conversion with mvdXML to make it compatible with all currently available MVDs, so that the fast validation algorithm can also be applied to the current mvdXML rules. In Section 3.1.1, it has been introduced that MVDLite can represent all the rules in mvdXML V1.1, which means that all mvdXML rules can be converted to MVDLite. To illustrate that MVDLite can also be converted to mvdXML, it is needed to discuss another question: can mvdXML V1.1 represent all the rules in MVDLite?
By comparing the structure of the two languages, we found that there are some implicit constraints in mvdXML.
Only one ConceptTemplate can be used in an mvdXML rule. Therefore, there can be only one root entity type in a rule.
No duplicate nodes in ConceptTemplates in mvdXML. Therefore, the branch point of two paths leading to two RuleIds on the template must be at the lowest common ancestor of the two RuleIds.
The RuleIds can only be assigned to the attributes, but not the root entities. Therefore, it does not support rules like “IfcDoor[Exists]=TRUE”
According to these implicit constraints, some counterexamples can be written in MVDLite, which can not be represented in mvdXML. Therefore, in order to support bidirectional conversion, it is needed to add these constraints also on MVDLite.
The conversion from mvdXML to MVDLite can be performed in two major steps. (1) For each term in the statement, expanding the RuleId according to the ConceptTemplate to generate the rule chain. (2) For each logical operator connecting two terms, merging the two rule chains at the lowest common ancestor of the two RuleIds.
The conversion from MVDLite to mvdXML can also be performed in two major steps. (1) For each root entity type, converting the tree structures into a ConceptTemplate, and assigning RuleIds for each node. (2) Rewriting the statements using the RuleIds.
By supporting bidirectional 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.
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 4 rows, while the mvdXML rule has 94 rows. Obviously, the MVDLite rules are shorter and easier to read.
4 Efficient MVD Validation with MVDLite
In section 2.4, the current methods for mvdXML-based MVD checking has been reviewed. In mvdXML, since the data template rules and attribute value rules are represented separately, the validation algorithm that fits this rule structure is "first finding subgraphs, and then checking attribute values on the subgraphs". The current mvdXML validation tools Zhang et al. (2014); Weise et al. (2016) are mainly implemented according to this idea. However, this algorithm is with large complexity, since only one root entity is processed at each time when validating a rule. For one root entity, there are usually multiple subgraphs that can match a ConceptTemplate, and it is needed to traverse all subgraphs to confirm whether there exists a subgraph that satisfies the rule.
MVDLite represents data template rules and attribute value rules in the unified “rule chain” structure. Based on this unified representation of rules, a faster algorithm for MVD validation is proposed, which is no longer performed for each root entity separately but can be performed on the set of a certain type of root entities.
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. In the validation algorithm proposed in this paper, the rule segments and the rule chain are regarded as mappings between node sets. Instead of traversing the subgraphs of each root entity, this algorithm performs MVD validation by calculating the mappings between node sets, which is able to obtain the results of all root entities of a certain type at once.
Attribute segment. An attribute segment is a mapping from one node set to the linked node set, as shown in Figure 5. Each node set 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. shows an example attribute segment, which is represented as a mapping from an “IfcPropertySet” node set to an “IfcProperty” node set.
Metric segment. Metric segments act as filters for the node sets. 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 node set, and they act as filters for the node set itself. They are called “single metric segments”. Figure 5 shows an example single metric segment “[Value]>=0” as a filter for a IfcValue node set. 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 node set to the set itself.
The [Size], [Exists] and [Unique] metrics act as filters for the parent node set. 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 node set. It must be evaluated in combination with the attribute segment “->HasProperties” in front. The collection metric segment “[Size]>1” is a mapping from a node set to the parent node set, and the combination “(->HasProperties[Size]>1)” is a mapping from the parent node set to the parent node set itself.
Rule chain and compound segment. By linking the node mappings in the order of segments on a rule chain, the rule chain can be represented as a mapping between node sets. When a rule chain is enclosed in a compound segment, the compound segment acts as a filter for the current entity set. Similar to the single metric segment, the compound segment can be represented as a mapping from a node set to the set itself. As shown in Figure 6, a rule chain inside a compound segment can be represented as a round-trip path from the root node set to the metric segment at the end, and then back to the root node set. This round-trip path on a rule chain is equivalent to the node mapping of the corresponding compound segment.
Logical operators. The rule chains can be combined with logical operators. Since each rule chain acts as a filter of a node set, the logical combination of rule chains are equivalent to the boolean operation of filtered node sets. The logical conjunctions AND, OR, NOT correspond to the intersection, union, complement operations of sets, respectively. In mvdXML, the logical conjunctions are not only used to link the rules for the same node set, but also the rules for different node sets defined by two different RuleIds. As discussed in Section 3.2, the logical operation between two different RuleIds is equivalent to the boolean operation on the lowest common ancestor node set of the node sets corresponding to two different RuleIds
4.2 Analysis of the MVDLite Validation Algorithm
This section is about the upper limit of the efficiency of MVD validation algorithms, and the explanation of why the algorithm based on MVDLite rule structure is faster than the algorithm base on mvdXML.
The target of the MVD validation algorithms is to determine the existence of a subgraph conforming to a data template and a rule statement. In order to determine that a subgraph conforms to a rule, each node on the paths from the root entity node to the RuleId nodes must be visited at least once, while it is not needed to visit all the nodes to determine that a subgraph does not conform to a rule. Therefore, the theoretical upper limit of the efficiency of MVD validation algorithms is to visit the fewest nodes that can determine whether a subgraph conforms to a rule.
Figure 7 is a comparison of the mvdXML-based validation algorithm and the MVDLite-based validation algorithm on the same rule. The mvdXML-based algorithm lists all subgraphs that match a template structure for each root entity and then check all the listed subgraphs to obtain the result of one root entity. On the contrary, the MVDLite-based algorithm is performed on the rule chain structure, and the results of all root entities can be obtained at once. The reason why the MVDLite-based validation is faster can be explained by the fact that the algorithm can effectively reduce the repeated visit to the nodes by merging subgraphs, pruning, and caching:
(1) Merging subgraphs. In IFC data structure, one node is likely to be referenced by multiple nodes. Therefore, one node is likely to be included in multiple subgraphs expanded from one root entity or multiple root entities. The mvdXML-based validation algorithm traverses the subgraphs of each root entity, in which one node may be visited multiple times. By performing the validation algorithm on the graph merged by all subgraphs of a certain root entity type, the repeated visit to the nodes are reduced.
(2) Pruning. In mvdXML-based validation, since the data template rules are separated from the rules of attributes and values, the step of searching for all subgraphs is usually before the step of checking each subgraph. Thus pruning is difficult to take because all nodes on all subgraphs are already visited when searching for subgraphs according to the template. While in MVDLite, since the data template rules and attribute value rules are in the unified “rule chain” structure, the searching and pruning can be easily performed on the rule chain. Each node on the subgraphs conforming to a rule will be visited up to twice (going forward to the leaf nodes, and then going back to the root nodes); while on the subgraphs not conforming to a rule, all nodes below the first node that do not conform to the rule will not be visited. Compared with the mvdXML-based validation algorithms, this algorithm with pruning is much closer to the theoretical upper limit of efficiency.
(3) Caching. In the mvdXML-based algorithm, the validation of each rule on each subgraph is independent, so it is hard to reuse the calculation results. While in MVDLite-based algorithm, since each segment on the rule chain is a mapping between two node sets, the sets and the mappings can be cached and reused. For example, the segments “IfcWall->typePset (’Pset_WallCommon’)” may appear in multiple rules involving different properties in the property set named “Pset_WallCommon”. So if the same segments are involved in another rule, the cached node set can be directly obtained. In this way, not only the repeated node visits between multiple subgraphs are reduced, but also the repeated node visits between multiple rules are reduced.
5 Experiments and Applications
The parsers for the IFC files and for 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 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.2).
5.1 MVDLite Validation Experiment
(1) The compared tools. The publicly available MVD validation tool supporting mvdXML includes an xBIM-based tool xBimTeam (2016) and a BIMServer-based open source tool opensourceBIM (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.
The efficiency of the MVD validation tool is not only relevant to the validation algorithm, but also some other factors like different programming languages and different IFC parsers. In order to fairly compare the efficiency of the algorithm, an MVDLite validation tool and an MVDLite validation tool are implemented based on the same 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. This model is converted 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. This model is converted 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.2.
|file size||52 MB||193 MB||841 MB|
|mvdXML||file size||58 KB||1,308 KB||1,758 KB||6,767 KB|
|“Concept”s (has rules)||23||319||335||3,404|
|MVDlite||file size||40 KB||74 KB||85 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.
- RV.mvdxml The IFC4 Reference View mvdXML provided by buildingSMART.
- DTV.mvdxml The IFC4 Design Transfer View mvdXML provided by buildingSMART.
- 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.2. 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” and “O&M.mvdxml” are in mvdXML V1.1, and “RV.mvdxml” and “DTV.mvdxml” are in mvdXML V1.2. From mvdXML V1.1 to V1.2, a new sub-concept reference structure is added. All the tested MVD validation tools do not support this new reference structure, and such references are skipped.
(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 validation algorithm and mvdXML-based validation algorithm are implemented on the same IFC parser, in order 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, so the validation speed is 73 times faster than mvdXML.
5.2 Case Study
5.2.1 The Workflow for Developing MVDLite Rules
The workflow is designed to make domain engineers and managers work together with IT engineers 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 data structure definitions from the domain-specific rules, which is shown in Figure 9 (a).
First, the IT engineers define the abbreviation expressions in a header (see Figure 9 (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 9 (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 tested in an MVD development task for the commercial complex building. This MVD is developed to extract the partial model for operation and maintenance from the complete model, and to ensure the existence of required properties and relationships. The MVDLite ruleset is 926 KB with 8,525 rows, and the converted mvdXML ruleset is 6,767 KB with 88,905 rows. The file size of the MVDLite ruleset is much smaller, and it also has an advantage in human readability.
5.2.2 MVD Validation and Partial Model Extraction
In this case study, both the real-world IFC model and the ruleset are in large scale, which is a challenge for the efficiency of MVD validation task. 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 mvdXML-based algorithm uses 11,261 seconds to finish the validation, while the MVDLite-based algorithm uses only 154 seconds. According to the result, the proposed fast MVD validation algorithm based on MVDLite has a great advantage in speed.
The proposed fast MVD validation algorithm is able to efficiently find a set of nodes that meet certain conditions. This algorithm can be further applied in partial model extraction tasks, which is able to 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 node set.
(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 node set.
(3) Filtering relationships by rules. There are some other nodes that 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 node set.
|original model||extracted model|
|file size (MB)||841||228|
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 228 seconds to finish the partial model extraction task. The comparison of the original model and the extracted partial model are listed in Table 4, and the two models are visualized in Figure 10.
Compared with the original model of 841 MB, the extracted model is only 228 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.
Through this case study, an MVDLite-based process is implemented for enterprises to customize MVD rules and to use the MVD rules for model validation and exchange. The MVDLite ruleset is generated according to the classification standard and the exchange requirement forms. Then the model validation is efficiently performed, and the partial model for data exchange are extracted according to the MVDLite ruleset. The process is with good usability and efficiency.
6 Conclusion and future work
In this paper, MVDLite is proposed as a new representation for MVD rules, which simplifies the rules and increases the usability by using natural language terms to replace data structure definitions. The MVDLite-based workflow reduces the knowledge threshold required for MVD development. Based on the rule chain structure of MVDLite, a new MVD validation algorithm is proposed, which is several times faster in MVD validation on large real-world IFC models.
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. Cited by: §2.1.
- IfcOWL: a case of transforming express schemas into ontologies. Ai Edam 23 (1), pp. 89–101. Cited by: §2.1.
- Topological analysis of 3D building models using a spatial query language. Advanced Engineering Informatics 23 (4), pp. 370–385. Cited by: §2.1.
- 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, §2.3.
- Checking spatio-semantic consistency of building information models by means of a query language. In Proc. of theIntl Conference on Construction Applications of Virtual Reality, Cited by: §2.1.
- A rule-based methodology to extract building model views. Automation in Construction 92, pp. 214–229. Cited by: §2.3.
- Automatic rule-based checking of building designs. Automation in construction 18 (8), pp. 1011–1033. Cited by: §2.4.
- BIMQ 2019. Note: Available from: http://demo.bim-q.de (accessed May 2019) Cited by: §1, §2.3.
- IFC model view definition format. International Alliance for Interoperability, pp. 1–29. Cited by: §1, §2.1.
- A SPARQL query engine for binary-formatted IFC building models. Automation in Construction 95, pp. 46–63. 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. Cited by: §2.1.
- Modularized rule-based validation of a BIM model pertaining to model views. Automation in Construction 63, pp. 1–11. 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. Cited by: §2.3.
- Logic for ensuring the data exchange integrity of building information models. Automation in Construction 85, pp. 249–262. Cited by: §2.4.
- BIMQL – an open query language for building information models. Advanced Engineering Informatics 27 (4), pp. 444–456. Cited by: §2.1.
- mvdXMLChecker. Note: Available from: https://github.com/opensourceBIM/mvdXMLChecker (accessed May 2019) Cited by: §5.1.
- ANTLR: a predicated-LL (k) parser generator. Software: Practice and Experience 25 (7), pp. 789–810. Cited by: §5.
- SimpleBIM: from full ifcOWL graphs to simplified building graphs. In Proceedings of the 11th European Conference on Product and Process Modelling (ECPPM), pp. 11–18. 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. Osaka, Japan: ICCCBE, Osaka, Japan, 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, §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. Cited by: §2.4.
- Generic BIM queries based on the IFC object model using graph theory. In The 16th International Conference on Computing in Civil and Building Engineering, Osaka, Japan, Cited by: §2.1.
- Configurable model exchanges for the precast/pre-stressed concrete industry using semantic exchange modules (SEM). Computing in Civil Engineering, pp. 269–276. 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. 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. 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. Cited by: §2.3.
- Generalised model subset definition schema. In Proceedings of the CIB-W78 Workshop, Cited by: §2.1.
- IFC model checking based on mvdXML 1.1. In eWork and eBusiness in Architecture, Engineering and Construction: ECPPM, pp. 19. Cited by: §2.4, §4.
- 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 Proc 10th European Conference on Product and Process Modelling (ECPPM), pp. 157–64. Cited by: §2.1.
- XbimMvdXML. Note: Available from: https://github.com/xBimTeam/XbimMvdXML (accessed May 2019) Cited by: §5.1.
- Model view checking: automated validation for IFC building models. In eWork and eBusiness in Architecture, Engineering and Construction: ECPPM, pp. 123. Cited by: §1, §2.4, §4.
- Towards model view definition on semantic level: a state of the art review. In Proceedings of the 20th International Workshop: Intelligent Computing in Engineering, Cited by: §1, §1.
- BimSPARQL: domain-specific functional sparql extensions for querying RDF building data. Semantic Web (Preprint), pp. 1–27. Cited by: §2.1.
- Ontology-based partial building information model extraction. Journal of Computing in Civil Engineering 27 (6), pp. 576–584. Cited by: §2.1.