See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/340658166

Application of signature-based matching for IFC model comparison

Article in International Journal of Construction Management · April 2020

DOI: 10.1080/15623599.2020.1742630

CITATIONS READS

2 234

2 authors, including:

Muhammad Tariq Shafiq

United Arab Emirates University
25 PUBLICATIONS 192 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

BIM4Safery View project

All content following this page was uploaded by Muhammad Tariq Shafiq on 06 June 2020.

The user has requested enhancement of the downloaded file.

 International Journal of Construction Management

ISSN: 1562-3599 (Print) 2331-2327 (Online) Journal homepage: https://www.tandfonline.com/loi/tjcm20

Application of signature-based matching for IFC

model comparison

Muhammad Tariq Shafiq & Stephen R. Lockley

To cite this article: Muhammad Tariq Shafiq & Stephen R. Lockley (2020): Application of
signature-based matching for IFC model comparison, International Journal of Construction
Management, DOI: 10.1080/15623599.2020.1742630

To link to this article: https://doi.org/10.1080/15623599.2020.1742630

View supplementary material

Published online: 15 Apr 2020.

Submit your article to this journal

View related articles

View Crossmark data

Full Terms & Conditions of access and use can be found at

https://www.tandfonline.com/action/journalInformation?journalCode=tjcm20
INTERNATIONAL JOURNAL OF CONSTRUCTION MANAGEMENT
https://doi.org/10.1080/15623599.2020.1742630

Application of signature-based matching for IFC model comparison

Muhammad Tariq Shafiqa and Stephen R. Lockleyb
a
Department of Architectural Engineering, UAE University, Al Ain, UAE; bDepartment of Architecture and Built Environment, Northumbria
University, Newcastle-upon-Tyne, Northumbria, UK

ABSTRACT KEYWORDS
The paper highlights the problem of Industry Foundation Classes (ISCs) model comparison in a platform- BIM; IFC; model
neutral collaboration of Building Information Models (BIMs). A critical issue in the IFC model comparison comparison; signature
is establishing the right candidates for comparison, which typically depends upon using Globally Unique matching; collaboration
Identifiers (GUIDs). GUIDs are criticised for inconstancies that result because of complex modelling opera-
tions and nature of BIM authoring tools that are used to exchange IFC data. This paper presents a signa-
ture-matching approach that advocates using dynamic object identities, calculated from the
characteristics and attributes of IFC objects, using hash keys that can create a unique signature for an
object. Exemplars of creating IFC object signatures are presented. The proposed methodologies for creat-
ing IFC object signatures are implemented in a custom-built tool, xBIM Signatures exporter, and are veri-
fied using a test case. This research is limited to discussing signatures for IfcBuildingElements and has not
considered a level of details and signature weighting of various object characteristics to formulate a
robust solution. The proposed signature matching approach can benefit model comparison functionality
for model servers and cloud-based collaboration tools.

Introduction a deep tree comparison procedure. GUID is a unique identifier

The problem of interoperable information exchanges using het-
erogeneous Building Information Modelling (BIM) application
has been well researched and has led to the development and
implementation of Industry Foundation Classes (IFC) over the
last 20 years. IFC has now become a widely accepted open and
neutral data format specification to facilitate interoperable infor-
mation exchanges using Building Information Models in the
AEC industry (Gao et al. 2017; Shi et al. 2018).
A platform-neutral BIM-enabled collaboration relies on effect-
ive management of IFC models using a Model Collaboration
System or a Model Server. A model server is a type of database
system that allows upload, download, sharing and coordination
(e.g. model comparison, and model checking) of models or com-
ponents by multiple users (Berlo et al. 2012; Cho et al. 2018;
Shafiq et al. 2018). An IFC enabled model server is expected to
facilitate the exchange of information between the applications
used throughout a building project lifecycle (Singh et al. 2011).
The workflow of such a collaboration is built around the concept
of finding changes in two versions or variants of IFC model
instances and merging them together with the shared data reposi-
tory. Thus, the issue of IFC model comparison becomes critical to
keep track of the changes during the information exchanges.
The purpose of IFC comparison process is to identify similar-
ities and differences between two IFC models. A fundamental
requirement of an effective IFC comparison process is identifying
comparable objects or identifying candidates for comparison in
the two matching IFC files. Existing IFC Comparisons mecha-
nisms are usually based on using Globally Unique Identifiers
(GUIDS) to establish candidates for comparison, in a shallow or
for object instances that follow the universally unique identifier
standard (UUID) that provides a way of uniquely identifying an
object. GUIDS are a reliable base if these are properly main-
tained during the IFC roundtripping in data exchange transac-
tions. However, GUIDS exports are not always consistent due to
the complexity of modelling operations, application imprints and
different internal data structures of BIM tools, which leads to
costly calculations, quality compromises and inaccuracies due to
inconsistent GUIDs in IFC model comparison processes (Nour
and Beucke 2008, 2010; Kang and Hong 2015). To address these
issues, this paper presents a signature-matching approach that
advocates using dynamic object identities, calculated from the
value of its properties and attributes using hash keys that can
create a unique signature for an object. In BIM collaboration
operations, a change can be in (1) an object’s position, (2) shape
and (3) properties. Therefore, an object’s position (Topology),
shape (Geometry) and properties (Semantics) can be used to for-
mulate partial, default or complete signature for an object, which
would be useful in establishing candidates for IFC comparison
process, independently from GUIDs, and would reduce the over-
all workload of the IFC compression process. Signature matching
is useful even if a complete solution is not feasible, as signature
matching can be used to eliminate a significant proportion of
elements to downsize the comparison criteria for any fur-
ther processing.
The problem of IFC model comparison
A critical issue in managing collaboration operations on a model
server is the management of iterative changes during BIM

CONTACT Muhammad Tariq Shafiq muhammad.tariq@uaeu.ac.ae

Supplemental data for this article can be accessed here.
ß 2020 Informa UK Limited, trading as Taylor & Francis Group
2 M. T. SHAFIQ AND S. R. LOCKLEY
collaboration operations. The shared data repository on the ser-
ver must be updated with any changes because of modifications
made in a check-in/check out the operation, such as new data
instances added, deleted or changed. The information in the
shared repository (i.e. Model server) is defined in terms of a
moment in time and associated versions in other moments in
time, resulting in several versions and variants of a shared
repository instance and discipline-specific information models.
Thus, the issue of IFC model comparison becomes critical to
keep track of the changes during the information
exchange workflows.
Typically, the IFC model comparison is a post-rationalisation
activity in a collaboration operation where the data management
system (i.e. model server or another comparison tool) must deal
with what has already happened on a set of data with no or lim-
ited knowledge of prerequisites about the incoming data. The
comprising IFC files may include changes, application imprints
and other data instances due to IFC round-tripping. The process
of IFC comparison will require establishing the right candidates
for comparison before a comparison algorithm can be applied to
determine similarities and differences. In post rationalization sit-
uations, establishing the right candidates (corresponding objects
in comparing versions) for comparisons becomes difficult, for
which static object identities are typically used in a shallow or
deep tree comparison of IFC models (Nour 2007). The use of
static object identities in IFC model comparison has been heavily
criticised in the literature (Weise et al. 2003; Kiviniemi et al.
2005; Nour and Beucke 2008; Hjelseth and Nisbet 2010) as it
leads to costly calculations, quality compromises and inaccuracies
due to inconsistencies in IFC data round-tripping. Moreover, dif-
ferent BIM authoring tools may have different semantic repre-
sentation for a same physical object which triggers another
concern that is how to compare models which are constructed
independently using different model authoring tools.
Furthermore, support is required from the client-side applica-
tion when submitting changes to the model server, for example,
to maintain object owner history and the consistent preservation
of object identifiers. However, the internal data storage structures
of client-side BIM applications tend to be different from each
other, with limited support for database-level change manage-
ment within proprietary BIM applications for server enabled col-
laboration. For example, if a structural engineer decides to
change the position of 4 columns, there is no predefined stand-
ard workflow for executing this change. The engineer may
change each column individually, leading to four changes in the
model; or may decide to change one, delete the other three and
then copy and paste the first one three times. This will result in
one change, three deletions and addition of three new columns
in a model, but ultimately the design change would be the same
in both cases.
Therefore, when exporting the latest version of IFC models
(or model subsets), the IFC versioning can be different, as the
two editing operations could result in different metadata for the
same model elements. Therefore, two objects can still constitute
a comparable pair even if these are assigned different object
identifiers. Most model comparison applications (e.g. Solibri,
BIMServices, or proprietary applications etc) use GUIDs to
establish candidates for comparison and therefore fail if these are
different for two comparable objects. Tracking comparable
objects across versions is a fundamental task in managing the
workflows of model server enabled collaboration on IFC Models.
Therefore, there is a need to consider other characteristics, such
as location (same bounding box), containment (same address),
geometry and other semantic characteristics, in addition to using
GUIDs for object recognition and identification in a compari-
son process.
Previous work
Several authors and research projects have addressed the general
issue of change management in IFC models and only a few stud-
ies have focused on IFC model comparison strategies. Jeong
et al. (2009) argued that traditional plain text-based comparison
tools do not consider specific data organization and representa-
tion of comparable files and therefore are not suitable for IFC
Comparison. Alternatively, GUID-based comparison strategies
were presented to compare IFC models. GUID-based strategies
consider two instances in two comparing files as same if their
GUIDS are matching and vice versa. Ma et al. (2006) developed
EVASYS (EXPRESS Evaluation System), one of the first tools
that can calculate a number of identical instances in two com-
paring IFC models under EXPRESS schema. The comparison
algorithm proposed in EVASYS was based on using GUIDs to
identify matching object pairs and then used a sequence of steps
to filter out matching and different objects by comparing object
types < instances < attribute value. The IFC model comparison
methodology of EVASYS was based on GUIDs accuracy, which
provided unreliable results and therefore the tool had limited
success. Lee et al. (2011) reported four weaknesses of EVASYS:
(1) it ignores redundant instances; (2) it does not provide any
mechanism to analyses IFC owner history; (3) it does not con-
sider if object identifiers are changed but that the property values
are maintained; and (4) it is limited to counting structural
instances in comparison, ignoring semantics. In addition, the
GUIDs of instances are often changed during the data exchange
between different systems even without a modification to the
model itself (Shi et al. 2018). Although the GUID-based com-
parison approach is simple and can provide fast results but is
error-prone and therefore cannot be relied on.
A graph-based approach was presented by Arthaud and
Lombardo (2006) which compares two oriented graphs generated
by two IFC files. They proposed converting IFC file into RFD-
RDF graph-based signature algorithms for computing differences
of IFC models. However, the matching process in graph-based
comparisons still complies with object identifiers comparison.
Another IFC comparison approach uses a tree-based compari-
son of two IFC models using the hierarchal structure of IFC to
map instances of two comparing files. This approach was pre-
sented by East et al. (2009) and implemented in an IFC compari-
son tool ‘BIMServices’. This approach uses IFC spatial and
containment hierarchies to base model comparison as the path
along model hierarchy tree will typically have incremental
changes, starting from IfcProject, across different versions of the
same IFC model. Also, the IFC spatial hierarchy (geometry) is a
relatively reliable base across BIM authoring tools and end-users,
which can help better understanding of the comparison results.
The bimServices tool provided a better way of comparing IFC
models through a sequential pass to calculate differences and
similarities by using a tree comparison. However, the identifica-
tion of comparable pairs still relies on the assumption that the
object identifiers of two instances will match in the compar-
ing models.
Most recently, Shi et al. (2018) proposed a similar tree com-
parison approach which uses data instances, instead of GUIDS,
to establish candidates for comparison to initiate the comparison
process. Their approach extracts three basic terms (i.e. instance

Table 1. Criteria for IFC model comparisons in previous studies (Extended from Lee et al. 2011).
Criterion Ma et al. (2006) Lim et al. (2008)
GUIDs Used Mentioned
Number of instances Used Not used
Number of missing or new entities Used Not used
Attribute value differences Used Optional
Owner history Not used Not used
Schema version Used Not used
Entities related to shape representation. Not used Not used
name, entity name and attribute values from each data instances)
and their referencing relationships to construct IFC file hierarchy
to perform the further comparison. This approach can reduce
the number of redundant instances and can provide fast com-
parison results without relying on the matching GUIDS.
However, various BIM tools use the different naming structure
for instances and can export two different names for the same
object in an IFC Import/Export operation. Therefore, construct-
ing the IFC tree comparison using instance or entity names may
not lead to accurate candidates for comparison to support the
rest of the comparison process. Also, this is a flattening-based
comparison approach suggests replacing all referencing with
actual values in two IFC files and then compares the flattened
data instances instead of original files. In this way, the compari-
son process becomes simplified to a string comparison as it over-
comes the differences of reference numbers included in attribute
values. However, the proposed flattening process can result in
quite long strings of data due to complex inheritance and refer-
ence of IFC instances. Therefore, the flattening-based approach
is time-consuming and may not be suitable to compare large
IFC files.
Previous authors have recognised that in order to get a more
meaningful result for IFC model comparisons an extended set of
metrics need to be considered that is not solely based on GUIDs
but also consider other physical, structural and semantic proper-
ties of the IFC models (Nour 2007). Table 1 presents a summary
of the IFC model comparison criterion proposed by vari-
ous authors.
A fundamental problem with inaccurate object identifiers (i.e.
GUIDs) is an inaccurate selection of candidates for comparison
that can lead to completely wrong results. The IfOwnerHistory
contains information about the model owner, organisation, soft-
ware used and a timestamp, but it changes every time a model is
exported/imported from a BIM tool, irrelevant of if any changes
or revisions. Therefore, Lee et al. (2011) stressed ignoring
IfcOwnerHistory in calculating model comparison results. Shi
et al.’s (2018) methodology also suggests ignoring the change in
GUIDs, IfcOwnerHistory and order of change in property sets.
Pazlar and Turk (2008) looked at the entities that constitute geo-
metric representations if these can be used to establish a candi-
date for comparison and reported that shape representations are
not consistent among BIM authoring tools. For example, some
tools use boundary representation (B-rep) and some use solids of
same shape representation. Lockley et al. (2013) tested several
BIM authoring tools and confirmed the issue of different shape
representations in BIM authoring tools. Therefore, shape repre-
sentation also cannot be used solely as a reliable base to perform
model matching or comparison.
A signature matching approach for IFC models
This paper proposes a signature-matching approach to establish
object identities in model matching and comparison processes.
INTERNATIONAL JOURNAL OF CONSTRUCTION MANAGEMENT 3
Pazlar and Turk (2008) Jeong et al. (2009) East et al. (2009) Shi et al. (2018)
Mentioned Used Used Ignored
Not used Not used Used Used
Not used Not used Not used Used
Not used Not used Used Used
Not used Not used Not used Ignored
Not used Not used Not used Not Used
Used Not used Not used Not Used
In a signature-matching approach, the identity of an object is
not static but calculated dynamically from the value of its prop-
erties and attributes creating a unique signature for an object
(Reddy and France 2005). Oliveira and Breitman (2009) defined
that ‘a signature is the collection of values assigned to a subset of
syntactic properties in the model elements’. The set of values
that can be used to determine a signature for an object is called
‘signature type’ (Reddy and France 2005). Signature types can be
divided into three categories, which are (1) a complete signature
that covers all the syntactic properties associated with a model
element; (2) a partial signature that covers a certain range of
element properties; and (3) a default signature that is only com-
posed of name properties. The selection of a signature type for
an object requires user configuration which can be defined using
a query language. A signature can be calculated using any num-
ber of properties associated with an object that can provide a
distinguisher for the object. For example, a signature for an
object can be its name, type and location or a combination of
these characteristics (e.g. wall, wall type, position coordinates).
Several characteristics can be used to generate signatures for ele-
ments, which may have different usage and weighting for their
reliability. However, in a signature-based matching scenario,
each element should be assigned at least one signature. An object
signature does not rely on precedent identity (e.g. GUIDs);
therefore, it can also be applied to the models which are created
independently of each other using different tools (i.e. as in the
case of IFC models populated from Revit or AECOsim).
However, the creation of unique object signatures needs to
define a series of functions to calculate accurate signatures for
model objects based on their signature types. Using the pre-
defined signature types, a hash value can be computed for the
relevant properties sets which are used to establish a match dur-
ing the comparison process.
For example, an IfcDoor has a geometry, a local placement,
width and height, optionally a material association, a set of other
properties (e.g. door number, colour), a few relationships and
some characterises which define it inside a database (i.e. GUID,
IfcOwnerHistory etc). In order to create a signature for a door, a
combination of these characteristics of IfcDoor can be used,
which can uniquely identify two records related to doors in com-
paring datasets. It is costly to calculate a complete signature for
IFC objects (for all the characteristics and properties), therefore,
a subset of characteristics is needed that can be used as a min-
imum to create efficient signatures for IFC building elements.
Another issue is to consider the level of details (LOD) of objects
in a BIM model to calculate effective signatures for model com-
parison. For example, in early design stages, if a designer
changes the appearance of a door but not the size and location,
it is unlikely that the other disciplines will care about this
change. But if the size of a door is changed, it may interfere with
other building systems and therefore will become a concern.
Similarly, if a door undergoes any change at the handover stage,
the only concern will be the attributes related to its maintenance
if these are changed or not. Therefore, the makeup of these
4 M. T. SHAFIQ AND S. R. LOCKLEY
Figure 1. Matching rule for RadiusBoundingSphere signatures.
signatures may be specific to the stage of development of the
building model. Signature matching is useful even if a complete
solution is not feasible, as signature matching can be used to
eliminate a significant proportion of elements to downsize the
comparison criteria for any further comparison.
Signature matching application in IFC models
This paper proposes that characteristics of IFC objects can be
used to create signatures for IFC objects, in addition to GUIDs,
to effectively identify corresponding objects in an IFC model
comparison process. This leads to a new research question:
‘What should constitute an effective signature for IFC objects?’.
It is suggested that this can be answered by considering the
structural and semantic characteristics of an IFC model and the
type of changes an IFC object can undergo. Fundamentally, a
change can be in (1) an object’s position, (2) shape and (3) prop-
erties. Position and shape are absolute for change, as if two
objects in a comparing process are at the same position and con-
tains the same geometrical shape, then these are likely to be a
similar object and thus, are candidates for comparison.
Therefore, the characteristics of an object related to its position
and shape can be used to create a signature for object recogni-
tion. For example, in an ‘IfcDoor’, the ‘IfcLocalPlacement’
defines the local coordinate system that is referenced by all geo-
metric representations. The three-dimensional (3D) shape of
‘IfcDoor’ is represented using ‘SweptSolid’, ‘SurfaceModel’, or
‘Brep’ to define the door geometry. Most BIM authoring tools
exchange arbitrary shape extrusions in IFC, which can be used
to create a unique object signature.
On the other hand, creating a signature from element proper-
ties is complex, as it involves a degree of change in object prop-
erties. It needs to determine what properties are important and
the degree of importance in IFC properties, to create a signature
based on the key properties. Several signatures can be created
from object properties, such as (1) The total number of property
count can be used as a signature; (2) A name key for all the
property sets names attached to an object can be used as a signa-
ture; (3) A name key of property names can be used as a signa-
ture and (4) A property value key can be used as a signature etc.
These signatures can be used as passes to determine the degree
of change in a potentially matching pair in a model comparison
process. Moreover, the position and shape are a way of reflecting
an object on a drawing and in a 3D presentation. Therefore,
these two components are compelling candidates to create a
unique object signature. However, the case with object properties
is different as it involves the degree of change that needs to be
incorporated into creating the relevant signatures. The following
section demonstrates examples of developing IFC object signa-
tures from the shape, position and properties.
Creating a signature from geometric representations (shape)
The geometry of an IFC element is defined by a shape definition
(i.e. 2D, 3D body and 3D path), the IfcProductDefinitionShape
and IfcLocalPlacement allowing multiple geometric representa-
tions. For example, an IfcDoor may have a profile, footprint,
bounding box and several 3D body definitions at different levels
of detail. There is an unlimited number of shapes within the IFC
schema, but it is a schema requirement that it must have at least
one 3D body. Therefore, the 3D shape of an element can be a
signature type as it is populated every time for an IFC element.
Another aspect is bounding box representation, as an
IfcBuildingElement may be represented as a bounding box,
which shows the maximum extent of the body within the coord-
inate system established by the IfcLocalPlacement. The bounding
box representation is the simplest geometric representation avail-
able. The same element shape should always be contained in the
same bounding box representation. Therefore, bounding box rep-
resentation and 3D shape definitions can be used as strong sig-
nature types where a hash code signature can be calculated by
the radius from the middle point that contains all the points in
the shepheId that contains the shape of an element. In simple
words, if two objects occupy a similar 3D space then they are
candidates for similarity checking. A shape-based matching rule
is represented in Figure 1.
A key aspect in defining shape signature type is to determine
how 3D shapes are being generated from BIM authoring tools,
as different BIM authoring tool may populate same 3D shape
using different profile definitions, due to their internal structural
differences and end-user domain applications. For example,
Autodesk Revit uses arbitrary profile definitions to generate 3D
shapes, whereas Tekla Structures uses parameterized profile defi-
nitions (IfcIShapeProfileDef, IfcEllipseProfileDef etc) as these

Figure 2. Matching rule for the position (centroid) signatures.
profiles can create more efficient shapes related to structural ele-
ments (e.g. beam, columns etc). The next step in a 3D shape cre-
ation is executed by ‘IfcTopologyRepresentation’ that include a
number of representation concepts as predefined representations
(e.g. vertex, edge, path, face shell and undefined). The topology
of a shape is a useful component of its signature, it deals with
connectivity rather than geometry, and topological signatures can
provide a good basis for matching objects prior to similarity
checking using their geometric data. The point of looking at how
a shape is created for an IFC element is that it follows a number
of computational steps, each of which can be used as a signature
and a combination of these signatures can produce a potent par-
tial signature for the corresponding IFC element for a match and
even to identify possible areas of changes if a shape has been
changed. In theory, IfcRectangleProfiledef should always create
and refer to the same shape and thus can be used as a signature
type using an ID for the shape profile definition. A shape-based
partial signature is particularly important in determining the
changes, rather identifying the candidates for comparison.
Creating signature from local placement
The geometry of an IFC element is defined by a shape definition
and a local placement (i.e. IfcLocalPlacement). The
IfcLocalPlacement defines the relative placement of a product in
relation to the placement of another product or the absolute
placement of a product within the geometric representation con-
text of the project (BuildingSMART, 2014). A signature for local
placement can be calculated by a hash code that represents pos-
ition signature of an element calculated from X, Y and Z posi-
tions from the middle of an element (Centroid x, Centroid y and
Centroid z). A local placement based matching rule is presented
in Figure 2.
Likewise, the shape signature, the local placement signature
cannot decide on its own for identification of corresponding
element pairs in the comparison process, but it can be used in
combination with other signature types, to detect potentially
matching pairs or also to reduce the amount of work in calculat-
ing and identifying potential changes. If two elements have the
same local placement and shape, it is quite strong to say that it
is a potentially equivalent pair and can be a candidate for com-
parison. If the local placement coordinates are different for an
element, in relation to its corresponding element in a
INTERNATIONAL JOURNAL OF CONSTRUCTION MANAGEMENT 5
comparable dataset, then it indicates that the element is ‘moved’
in the updated version of the dataset, thus helps to identify the
changes undergone.
Creating a signature from a set of properties and
relationships
Each IFC element also has a set of properties that reference to
all attached properties, including quantities. There are objectified
relationships, IfcRelDefinesByProperties, which defines the rela-
tionships between property set definitions and objects. Properties
are aggregated in property sets; property sets can be grouped to
define an object type and properties can be attached to multiple
objects (1 to N relationships) that share some properties
(BuildingSMART, 2014). Creating a signature from element
properties is complex, as properties have a degree of change and
how that change is important in term of a comparison result
and in the context of change management from end user’s per-
spective. For example, in versions A and B of the same IFC
model, change in properties can have the following scenarios
Properties of object A (version 1 of a dataset) ¼ P [A]
Properties of object B (version 2 of a dataset) ¼ P [B]
P [A] ¼ P [B] ¼ No change in properties
P [A] > P [B] ¼ some properties have been deleted
P [A] < P [B] ¼ some properties have been added
P [A]  P [B] ¼ Properties have been updated/edited
Therefore, it is important to determine what properties are
important and if we can determine the degree of importance in
IFC properties, then it can be used to create a signature based
on the key properties. However, another issue to deal with in
property signature comparison is the granularity level of com-
parison; a shallow comparison or deep comparison based on the
level we go down in comparing referencing from an object. A
shallow comparison of properties does not go outside from the
encapsulated properties. If an attribute is encapsulated inside an
object then it is owned by the object, it is a strong reference and
not expected to change outside the object. For example, a door
has a material and a door width. The material is a referenced
property as it is pointing to another object, IfcMaterial, but the
door width is a totally encapsulated property which is not going
to be shared with any other object. The encapsulated properties
are often simple types, called Defined types in the IFC schema,
6 M. T. SHAFIQ AND S. R. LOCKLEY
Figure 3. Matching rule for PropertyCount signatures.
also called value types in computer science. These properties can
be used as a default signature in shallow comparison. A number
of signatures can be created from object properties, such as (1)
The total number of property count can be used as a signature;
(2) A name key for all the property sets names attached to an
object can be used as a signature; (3) A name key of property
names can be used as a signature and (4) A property value key
can be used as a signature etc.
For example, in two comparing datasets, IFC model A and
IFC model version B, a partial signature can be computed where
hash code that represents total properties given to an element by
the author in addition to what it would have by default
(PropertyCount Signature). Another partial signature can be cal-
culated from a hash code that represents the names of all prop-
erty sets in alphabetical order (ElementPropertySetName
signature). If the hash codes are matching, then the elements are
equivalent and can consulate a matching pair and vice versa.
Figure 3 reflects a simple flow chart for the PropertyCount
matching rule.
Similarly, matching rules can be defined for property names,
property values, tags, HasAssociations, ReferencedBy,
HasStructuralMember, HasCoverings, or HasProjections etc.
These are all inverse relationships which point outside the object
to external objects. However, all the properties may not be
important for comparison purposes if these are not usually
populated and if these have less value for change identification
from a user’s perspective. Statistical evidence from the current
models being generated by end-users is needed in order to deter-
mine the value and contribution that these Properties and
Relationships have for signature matching.
In the IFC schema, a relationship object is used to associate a
material, to an element, the relationship object would have a ref-
erence to a material layer and the elements to which the material
has been applied. To generate an effective signature, all the rela-
tionships need to be considered and a methodology must be
developed to decide which relationships are important to be
included in an object-specific signature. There are also changes
in associations of IFC objects that need to be considered. For
example, if a door has a material association pointed out by a
relationship object, what impact will a material change have on
the use of the door at a specific stage of design development? If
the material changes from glass to wood, is it a significant
change to the door at this stage? Who needs to be made aware
of this change? Clearly, it’s a matter of perspective and is
dependent upon a situation in a domain. A signature for an
element in a model comparison needs to consider the undergone
changes in the process and how it is related to the end-user. A
simple principle to follow is if a change affects graphical repre-
sentation then it should be reflected graphically to the end-user,
and the end-user should be provided with a reasonable indica-
tion about what has been changed. For example, if a door name
is changed from door number 46 to door number 47, then it is
not particularly important to show in a 3D model as the infor-
mation is held relationally in the database. Similarly, a door
swing is not usually reflected in a 3D model, but it is reflected
on 2D drawings, which makes a huge difference if the door
swing is changed in a drawing. Therefore, considering all the
relationships is important for signature matching but it has more
value in the fine-grained comparison analysis and can be used in
deep comparisons to identify changes in IFC models, which is
excluded in this research.
Creating signature from other IFC characteristics
Similarly, signatures can be created from other IFC object char-
acteristics (e.g. Schema type, Object Type, Name, Property Count
(see Table 2) and can be used to support establish similar candi-
dates for comparison.
Each IfcBuildingElement has a schema type that defines what
type of building element it is, for example, IfcDoor, IfcWindow,
IfcWall etc. These type definitions can be useful as a default sig-
nature to start a comparison process, especially the schema
TYPE, because a door should only be compared to a door and
so on. If the schema TYPE does not match, there should be no
further comparison for two records, as they are fundamentally
different and should not be a candidate for comparison in the
first place. Hence, a Schema Type based signature can be devel-
oped. It is to be noted that GUID itself can be used as a signa-
tures type as matching GUIDs would constitute a match but
different GUIDs can be ignored (i.e. same objects can have dif-
ferent GUIDS).
The name of an IFC element is a label in the term by which
something may be referred to, i.e. IfcLabel ¼ String (Max.255
characteristics). It is generally a string that represents the

Table 2. The signature types defined for IFC objects in the research.
Signature type
Model ID
SchemaType
DefinedTypeId
GUID
Name
ObjectType
PropertyCount
PropertySetNamesKey
PropertyNamesKey
PropertyValuesKey
MaterialId
Centroid X
Centroid Y
Centroid Z
RadiusBoundingSphere
ShapeId
human-readable name in natural language. Name of an element
is not expected to change even if the element undergoes any
change. Therefore, the name can be considered as another
default signature type to recognise candidates for comparison in
the first step, however different BIM tools handle name differ-
ently. For example, Autodesk Revit inserts its database accession
number within the name string, the name of an IfcDoor
exported from a Revit model is ‘IntSgl (1): 1010  2110 mm:
1010  2110 mm: 195846’, where last 6 digits of the name string
represent Revit’s own database number for that door. This is a
mechanism to effectively make the name unique. Therefore, the
name can be a strong signature type, if it is populated (some-
times it is not populated as it is optional in the schema) consist-
ently in the models. However, name signature type is tool
dependent, as different tools may create the name string differ-
ently or even completely ignore as it is optional in the IFC
schema (e.g. ArchiCAD uses a sequential hash number for ele-
ments in the name field).
These signatures can be used to uniquely identify matching
(equivalent) element pairs to start the comparison process and to
identify potential changes in more fine-grain analysis. For
example, if two elements have matching signatures for schema
type, shape and position, and then these are most likely the same
element, even if their GUIDs are different. The proposed meth-
odologies for creating IFC building element signatures are imple-
mented in a signature calculation tool, xBIM signature exporter,
and implemented on a test case models to verify the usefulness
of signature matching for IFC models.
Implementation: XBIM signature exporter
The xBIM signature exporter is developed on the platform of the
xBIM toolkit, the eXtensible Building Information Modelling
INTERNATIONAL JOURNAL OF CONSTRUCTION MANAGEMENT 7
Description
A number that represents the internal ID of an element inside the model. E.g.
2552 for an IfcDoor.
A name for a type of building element. E.g. IfcDoor for a door.
A total number of defined types attached to an element. E.g. the value for the
defined type of IfcDoor is calculated as 2539, in the test model.
A fixed 22-character length string, which is associated with each element and
is exchanged with the IFC exchange file structure.
The name of an IFC element is a label in the term by which something may be
referred to, i.e. IfcLabel ¼ String (Max.255 characteristics).
The type of object of an element.
A number representing the count of total properties given to an element by
the author in addition to what it would have by default (i.e. Extension
properties in Revit)
These are single value property sets that can be used to generate a signature,
considering that the complex property sets are hardly ever used in real
examples of IFC models
Similarly, a hash key is created from ‘Names’ of the properties (e.g. level, the
height of offset from level etc) by sorting out names of the properties in
alphabetical order and creating a hash code signature
Similarly, a signature is calculated for the values of the properties
This is the name of the material attached to an IFC building element
This is the position signature calculated by x, y, z positions of the middle of an
object. Thus, centroid determines the local placement of the object that can be
used as a unique identification signature for object recognition and also detect
if there is any change in the object’s position
This is a number that represents a radius from a middle point that will contain
all the point in the shepherd that contains the shape of an element. In
simple words, it is the radius of the bounding box of the shape of an
element. If the shape of an element is changed, it will change the bounding
box and vice versa. Thus, it can be used as a unique signature for the shape
of an object
This is the shape ID that defines the shape of an object
(xBIM) Toolkit, which is an open-source, software development
tool that supports IFC schema (Please see http://www.openbim.
org/ for more information). The xBIM toolkit supports IFC
models for geometric, topological operations and visualisation
that can be used to create bespoke BIM middleware for IFC-
based applications. The xBIM signature exporter reads an IFC
file and creates an xBIM model from where it will calculate and
export the element signatures according to the defined method-
ologies. The tool creates an output file with changed extension as
a CSV file and writes the results in an excel sheet. The xBIM
model first writes the header of the input IFC file in the CSV
file and analyzes every IfcBuildingElement in the IFC file and get
the assigned signatures, then it writes the signatures in a loop for
all the building elements in the output excel file. The proposed
approach is not project-specific and independent from authoring
software of the exported model. The xBIM signature exporter
works as a plug-in to xBIM toolkit and export signatures using
defined methodologies in this paper. The XBIM signature
exporter was developed in a commercially funded research pro-
ject; therefore, the source code of the tool is not presented in
this paper.
The test case
The xBIM signature exporter tool is tested for an IFC model,
‘Standard classroom’ model corresponding to IFC coordination
view 2.0. A small-scale example is used (1) the model should val-
idate against IFC coordination view 2.0 to minimize authoring
software imprints during IFC export which is simple to control
in a smaller model; (2) It is easier to visually see changes in two
versions of models and verify against comparison or signature
validation result (3) Even for a larger model, only samples of
8 M. T. SHAFIQ AND S. R. LOCKLEY
Table 3. Examples of door and slab signature from xBIM signature exporter.
Signature Type Example of door signatures
Model ID 2552
SchemaType IfcDoor
DefinedTypeId 2539
GUID 3A3Tihl61FQRUYE_9VB72L
Name IntSgl (1): 1010  2110 mm: 1010  2110 mm: 195846
ObjectType 1010  2110 mm
PropertyCount 56
PropertySetNamesKey 863509959
PropertyNamesKey 1703689443
PropertyValuesKey 570000713
MaterialId (empty, no material assigned)
Centriod X 3908.871582
Centriod Y 4958.726563
Centriod Z 1072.5
RadiusBoundingSphere 1205.268555
ShapeId 914375451
IFCBuildingElements can be presented, therefore size of the
model is irrelevant for the purpose of this paper.
The test model contains several IfcBuildingElements, such as
IfcDoor, IfcSlab, IfcWallStandardCase, IfcWindow and
IfcOpeningElement. The xBIM signature exporter has extracted
signatures for the building elements using the signature calcula-
tion methodologies, as described in Table 2. A summary of sig-
natures exported for a door and a slab in the test model is
presented in Table 3.
In theory, each signature for an element should be unique if
there is no change in the element in all the versions and variants
where that element is populated. To verify the signature match-
ing approach, another version, version B, of the test model is
created and the same signatures are exported using the xBIM
signature exporter. Version B of the test model has a lot more
details than the previous version and several things have been
added to this version, which exactly represents a typical design
development scenario in a real-world situation. The changes in
test model version A and version B are shown in Figure 4.
The xBIM signature exported has extracted the defined signa-
tures for all the building elements for an updated test model,
which can be used to compare it with the signatures from the
original test model. The signatures should be identical for identi-
cal elements and vice versa, and it should also indicate potential
areas for changes to help reduce the amount of work for a fine-
grained analysis in the later stages of the model comparison pro-
cess. A comparison of signatures for the test model version A
and Version B is presented in Table 4.
The results presented in Table 4, verify several signature
methodologies as proposed in this paper. The signature matching
establishes a door as a candidate for comparison as it has the
same signature for Schema Type, GUID, Position and bounding
box representation (centroids). So, even, without the GUID sig-
nature match, when GUIDs are inaccurate or unavailable,
schema Type, position and centroid signatures provide enough
evidence to establish the door as a candidate for comparison in
both models. The unmatched signatures indicate where the
comparison process should check for potential changes in fur-
ther analysis. Mainly, the door object type has been updated
and thus, the related properties are also changed. The signa-
tures for NAME, Object Type, properties indicate these changes
and help to reduce the amount of workload to precisely detect
changes in further analysis. Thus, verifies the signature-match-
ing of IFC building elements that can be used in establishing
candidates for comparison, without GUID dependency, and
helps to downsize the problem of model comparison for a
Example of a slab signatures
249
IfcSlab
0
3A3Tihl61FQRUYE_9VB75i
Floor: Ground Bearing Concrete: 195839
Floor: Ground Bearing Concrete
29
1452519724
1976711505
1589767974
Floor: Ground Bearing Concrete
1556.871582
828.9765625
250
6259.641113
444593825
more fine-grained analysis in later stages to detect changes in
IFC models.
The results suggest that the schema type, GUID, position and
bounding box signatures are strong signature types. Considering
the volatile nature of GUIDs, schema type, position and centroid
signatures provide enough evidence to establish candidates for
comparison in the first pass, even if the GUIDs are not matched.
After establishing matching pairs for comparison analysis, signa-
ture matching can also help to reduce the size data for detecting
fine-grain changes if there are any. For example, if a matching
pair has a different PropertyCount or PropertySetNamesKey, it
means some properties have been added or deleted, and it
should be checked for more detailed analysis. Thus, the signature
types, such as NAME, Object Type, properties, can reduce the
amount of workload to precisely detect changes in further ana-
lysis. It is not a brilliant way of calculating differences, but it
reduces the amount of work required for further analysis.
Conclusions and future work
This paper describes that model matching and comparison strat-
egies for platform-neutral models (i.e. IFC models) are the keys
to solve the problem of iterative change management. A critical
issue IFC model comparison is establishing the right candidates
for comparison, regardless of what comparison mechanical is
being used. Typically, GUIDs are being used to identify corre-
sponding objects in IFC model comparison methodologies,
which is criticised for their accuracy and efficiency. This paper
proposes that the characteristics of an IFC object can be used to
create unique signatures for IFC elements, in addition to GUIDs,
to effectively compare corresponding objects in a model com-
parison process. An object’s position, shape and properties can
be used to formulate partial, default or complete signature for an
object, which can be used as passes to establish candidates for
comparison and to highlight changes in a comparable object
pair. This approach is useful in establishing accurate candidates
for IFC model comparison and model merging without GUID
dependence and can reduce the workload of the overall model
comparison process, especially for model server enabled collabor-
ation. Also, the application of signature-based matching supports
pre-defined protocols to control data concurrency and iterative
changes in server-enabled BIM collaboration. Pre-defined proto-
cols use methods similar to library management, where slots and
prerequisites for data inputs and outputs are defined in advance
that make the object recognition and changes identification pro-
cess significantly easier. The proposed signature-based matching
 INTERNATIONAL JOURNAL OF CONSTRUCTION MANAGEMENT 9

Figure 4. Version A and Version B of the standard classroom test model.

Table 4. Door signature exported from xBIM signature exported for model version A and Version B.
Signature type Door signatures_ TestModel_CIC_2 Door signatures_ TestModel_CIC_3 Comments
Model ID 2552 3734 Changes every time, not useful
for comparison
SchemaType IfcDoor IfcDoor Match; signature for Schema type
matching verified
DefinedTypeId 2539 3721 Unmatched for a door; some building
elements do not have
this signature
GUID 3A3Tihl61FQRUYE_9VB72L 3A3Tihl61FQRUYE_9VB72L Match; GUID is maintained. GUID
signature verified
Name IntSgl (1): 1010  2110 mm: IntSgl (dis): Ed Building - Glazed Int Unmatched; Name matching signature
1010  2110 mm: 195846 Single 1010  2110 mm: Ed Building indicates a change; the door may
- Glazed Int Single be changed (and it is changed).
1010  2110 mm: 195846 NAME signature is verified
ObjectType 1010  2110 mm Ed Building - Glazed Int Single Unmatched; Indicates a change in the
1010  2110 mm object type (the door type is
updated in the new version).
Object TYPE signature verified
PropertyCount 56 66 Unmatched: indicate that some
properties are added.
PropertyCount signature verified
PropertySetNamesKey 863509959 81069332 Unmatched; indicates that some
property sets are different, and it
should be further analysed to
detect changes. PropertySetName
signature verified
PropertyNamesKey 1703689443 1159863088 Unmatched; again, indicate changes in
properties. PropertyNameKey
signature verified
PropertyValuesKey 570000713 1468664780 Unmatched; indicates that values of
the properties are also changed.
PropertyValueKey signature verified
MaterialId (empty) No signature available
Centriod X 3908.871582 3908.871582 Matched
Centriod Y 4958.726563 4958.726563 Position has not changed
Centriod Z 1072.5 1072.5 Position signature verified
RadiusBoundingSphere 1205.268555 1205.268555 Matched; RadiusBoundingSphere
signature verified
ShapeId 914375451 561216383 Unmatched; Because Object Type is
changed, so it has a
different shapeID

approach can lead a way towards defining predefined protocols
for the IFC schema which will not only improve the iterative
change management process but will reduce interoperabil-
ity issues.
In terms of creating an element’s signature, there are several
issues that need to be considered in the broader perspective of
change management in a model server environment. This
research has only developed signatures for IfcBuildingElements
as it has the highest importance for an end-user from a change
management prospectus. Even for IfcBuildingElement, the
research has defined signatures for IFC object characteristics
which are largely optional and may have different population if
models are created using heterogeneous applications. In the con-
text of creating unique signatures from these optional attributes,
such questions need to be answered that what level of utilisation
these optional properties are in the IFC models? And how likely
these are to be found in real-world examples? Potentially, a sub-
set of data can be derived, with the statistical reasoning that
some characteristics, relationships and properties of IFC objects
can be neglected or be focused on in creating object signatures,
depending upon the usability proof from a wider and real-world
dataset. This abstraction would require further empirical
10 M. T. SHAFIQ AND S. R. LOCKLEY
evidence from the analysis of real-world IFC models, reflecting a
cross-sectional view of different BIM authoring tools that are
used in creating IFC models. A critical issue is to consider the
associated weighting of different signature-type attributes of IFC
objects to constitute an effective signature for IFC objects.
This study is limited to using optional object properties to
create a property-based signature (such as PropertyCount,
PropertyValuesKey), however, these optional properties can be
referring to the same object but on a different LOD. Therefore,
Future research is needed to explore property signatures in more
details, considering associated LOD and degree of change in an
object’s properties. Future research will explore the application
of the proposed signature-based matching strategy on IFC mod-
els with different LOD and complexity within a model server
enabled collaboration environment.
Disclosure statement
No potential conflict of interest was reported by the authors.
References
Arthaud G, Lombardo JC. 2006. Automatic semantic comparison of STEP
product models. In: van Leeuwen JP, Timmermans HJP, editors.
Innovations in design & decision support systems in architecture and
urban planning. Amsterdam: Springer. p. 447–463.
Berlo LAHM, Beetz J, Bos P, Hendriks H, Tongeren RCJ. 2012. Collaborative
engineering with IFC: new insights and technology. Proceedings of the
9th European Conference on Process and Product Modelling, Reykjavik,
Iceland.
Cho CY, Won J, Ham S. 2018. IFC model restructuring framework for effi-
cient bulk-loading to object-relational IFC model server. KSCE J Civ Eng.
22(12):4930–4939.
East E, Nisbet N, Wix J. 2009. Lightweight capture of As-built construction
information. 26th International Conference on IT in Construction,
Istanbul.
Gao G, Liu YS, Lin P, Wang M, Gu M, Yong JH. 2017. BIMTag: Concept-
based automatic semantic annotation of online BIM product resources.
Adv Eng Inf. 31:48–61.
Hjelseth E, Nisbet N. 2010. Overview of concepts for model checking.
Proceedings of the CIB W78: 27th International Conference, Cairo, Egypt.
Jeong YS, Eastman CM, Sacks R, Kaner I. 2009. Benchmark tests for BIM
data exchanges of precast concrete. Autom Constr. 18(4):469–484.
View publication stats
Kang TW, Hong CH. 2015. A study on software architecture for effective
BIM/GIS-based facility management data integration. Autom Constr. 54:
25–38.
Kiviniemi A, Fischer M, Bazjanac V. 2005. Integration of multiple product
models: IFC model servers as a potential solution. Proceedings to the
22nd Conference on Information Technology in Construction CIB W78,
Dresden, Germany.
Lee G, Ph D, Won J, Ham S, Shin Y. 2011. Metrics for quantifying the simi-
larities and differences between IFC files. J Comput Civ Eng. 25(2):
172–181.
Lim JI, Kim JW, Kwon HD, Yoon SW, Kwon SW, Chin SY. 2008. IFC test
between commercial 3D CAD application using IFC. J Korea Inst Constr
Eng Manage. 9 (3):85–94.
Lockley S, Greenwood D, Matthews J, Benghi C. 2013. Constraints in author-
ing BIM components for optimal data reuse and interoperability. Int J 3D
Inform Model. 2(1):29–44.
Ma H, Ha K, Chung C, Amor R. 2006. Testing semantic interoperability.
Proceedings of the Joint International Conference on Computing and
Decision Making in Civil and Building Engineering, Montreal, QC,
Canada.
Nour M. 2007. Manipulating IFC sub-models in collaborative teamwork envi-
ronments. Proceedings of the 24th CIB W-78 Conference on Information
Technology in Construction, Maribor, Slovenia, p. 26–29.
Nour M, Beucke K. 2008. An open platform for processing IFC model ver-
sions. Tinshhua Sci Technol. 13:126–131.
Nour M, Beucke K. 2010. Object versioning as a basis for design change
management within a BIM context. International Conference on
Computing in Civil and Building Engineering, Nottingham.
Oliveira K, Breitman K. 2009. A flexible strategy-based model comparison
approach: bridging the syntactic and semantic gap. J Univ Comput Sci.
15(11):2225–2253.
 2008. Interoperability in practice: geometric data exchange
Pazlar T, Turk Z.
using the IFC standard. J Inform Technol Constr. 13:362–380.
Reddy R, France R. 2005. Model composition - a signature-based approach.
In AOM Workshop, 2005. [accessed 2019 Feb 2]. https://pdfs.semanti-
cscholar.org/1cd6/de7807b59d5d7d82f323adc88d26753c74a0.pdf.
Shafiq MT, Matthews J, Lockley S, Love PED. 2018. Model server enabled
management of collaborative changes in building information models.
Front Eng. 5(3):298–306.
Shi X, Liu YS, Gao G, Gu M, Li H. 2018. IFCdiff: a content-based automatic
comparison approach for IFC files. Autom Constr. 86:53–68.
Singh V, Gu N, Wang X. 2011. A theoretical framework of a BIM-based
multi-disciplinary collaboration platform. Autom Constr. 20(2):134–144.
Weise M, Katranuschkov P, Scherer RJ. 2003. Generalised model subset def-
inition schema. CIB Report, 284, 440. [accessed 2019 Feb 2]. http://www.
irbnet.de/daten/iconda/CIB20597.pdf.