Digitalization of culturally significant buildings: ensuring high-quality data exchanges in the heritage domain using OpenBIM

Abstract

Cultural heritage building information models (HBIMs) incorporate specific geometric and semantic data that are mandatory for supporting the workflows and decision making during a heritage study. The Industry Foundation Classes (IFC) open data exchange standard can be used to migrate these data between different software solutions as an openBIM approach, and has the potential to mitigate data loss. Specific data-exchange scenarios can be supported by firstly developing an Information Delivery Manual (IDM) and subsequently filtering portions of the IFC schema and producing a specialized Model View Definition (MVD). This paper showcases the creation of a specialized IDM for the heritage domain in consultation with experts in the restoration and preservation of built heritage. The IDM was then translated into a pilot MVD for heritage. We tested our developments on an HBIM case study, where a historic building was semantically enriched with information about the case study’s conservation plan and then checked against the specified IDM requirements using the developed MVD. We concluded that the creation of an IDM and then the MVD for the heritage domain are achievable and will bring us one step closer to BIM standardisation in the field of digitised cultural buildings.

Introduction

Benefits of heritage building information modelling

The Building Information Modelling (BIM) methodology applied to building heritage has generated a significant catalogue of experiences classified under the title Heritage Building Information Modelling (HBIM) [1]. Some researchers have already highlighted the fact that parametric modelling, database formulation and structured information management through BIM could offer many benefits to managing a built historic environment in the operation and maintenance phases, and particularly in Conservation, Repair and Maintenance (CRM) programming [2,3,4]. HBIM could also play an important role in defining the best retrofit solutions among a set of alternatives proposed by research and design participants as well as other stakeholders [5]. Furthermore, HBIM could help integrate other criteria, often neglected or applied in a non-structured way, such as compatibility with restoration and conservation guidelines, economic aspects through the whole lifetime, including the energy efficiency of the end solution, as well as environmental aspects of the long-term heritage management plan.

Despite advantages, communicating information through the BIM process for historical architecture and thus creating HBIM models has proven to be problematic [3, 6]. One of the challenges in HBIM is to provide appropriate geometrical accuracy. The creation of a HBIM model for conservation projects requires the collection of available information, interpretation, and the final modelling of the different structural elements [7]. The HBIM can include the following BIM dimensions: (1) analytical survey (3D), including establishing the geometrical model; (2) historical evolution (4D), including an overall evaluation of the cultural significance of the asset; (3) diagnosis (5D), including characterization of the state of knowledge, protection, possible conservation and dissemination; (4) cultural context (6D), including environment and territorial infrastructure; and (5) related assets, conservation and intervention (7D), including the programme for future research, protection and conservation activities [1].

It is not unusual to capture the different historical stages of built assets in HBIM with several simultaneous models that correspond to each phase so as to understand and represent the development of the object under study [8,9,10]. Furthermore, dating periods as well as historic information on building materials and historical changes to the building, such as demolitions and renovations, can be integrated into the model for a better understanding and managing of the asset. Lastly, a damage assessment for conservation practices using HBIM is often performed too. This can be a part of the overall analysis and generation of knowledge regarding the building itself. Usually, a considerable amount of such data is condensed into a conservation plan prepared by experts in ethnology and history [4, 11,12,13,14]. A major problem within HBIM is the interoperability of heritage data models. An early call for a unified HBIM library was made by [7]; however, to date there is no such library. Attempts to support the HBIM ontology through various standards have been made, such as the CIDOC CRM by [15]. While such a system has major advantages over using BIM or CIDOC CRM in isolation, the approach does not natively integrate the heritage information with the BIM, but keeps the two paradigms as separate entities that link together. The ideal approach would harmonise the heritage information with the BIM concept.

Industry foundation classes (IFC)

Interdisciplinary data sharing and the exchange of information between a diverse set of software tools are accepted standards in the Architecture, Engineering, Construction/Facility Management (AEC/FM) industry [16]. Thus, the interoperability of HBIM is of great importance, since interdisciplinary weighted decisions are made based on the model created and shared using BIM tools. Hull and Ewart [2] acknowledged that common data environments (CDEs), structured datasets, and the use of naming conventions would offer a significant benefit to heritage-asset management. Projects that involve the creation and management of built environments are increasing in complexity; the needs of data sharing and exchange are expanding; and thus BIM technology has been adopted to address the creation, storage and management of information throughout a building’s lifecycle in an integrated way. However, the data interoperability between diverse software tools involved in managing built environments is traditionally limited to point-to-point, direct conversions, which turned out to be a limiting factor in collaborations [17].

When it comes to software, public authorities need to be vendor-impartial [16]. With heritage, public authorities play a major role in the process, as the conservation plan is required by the cultural heritage institute. Vendor lock-in by proprietary software vendors can cause accessibility problems in BIM. This is even more so in fields where BIM is not one of the core businesses, as is the case with heritage. The exchange of information between different actors is complicated, because not all of them have the resources to use the same software. In these cases, there is a need for open formats. The price of proprietary software packages that deal with BIM models can be a barrier to purchasing [18]. Alternative systems to commercial packages give problems if proprietary data formats are used. These are often only compatible with one distributor. OpenBIM copes with these accessibility issues, as a vendor-neutral and open concept. The IFC schema is a manifestation of the openBIM concept.

The IFC schema was initiated in 1994 as an open-data-model standard. It is governed by the buildingSMART International (bSI) organisation and standardized by the International Organization for Standardization (ISO). The most up-to-date version IFC4 ADD2 TC1 is defined in ISO 16739-1:2018 [19]. The data model is intended to provide software-agnostic data interoperability in the AEC/FM industry [20]. It is very common to drop data into CDE using the IFC schema, which supports data sharing and exchange between heterogeneous software tools. bSI [21] reports that over 200 software tools can import or export IFC files. OpenBIM is widely recognised in the area of heritage as a valuable asset [22,23,24], although setbacks exist when it is combined with heritage data: the IFC language is not familiar to people working in these field. Diara and Rinaudo [25] attempt to overcome this by opting for an extension of the IFC schema itself in the form of data-extraction methods and not IFC classes, which do not yet exist. However, as IFC is a standardised schema, such an approach can be counterproductive and lead to reduced interoperability. A better approach would stay within the boundaries of the IFC schema and use existing methods to include heritage information, for example, property sets.

Information delivery manual (IDM) and model view definition (MVD)

The IFC schema is implemented in BIM environments through MVDs, proposed by bSI. As described by, e.g., Jiang et al. [26], this “handshake” protocol MVD defines a subset of the IFC schema, concept templates and properties that are needed to satisfy the data-exchange requirements. The IFC is always exported according to one MVD. To exchange the data, the exporting and importing software need to understand the same MVDs on the export and import sides, respectively. This is also the basis for software implementation and certification.

However, there are different challenges to face when using MVDs: interoperability between MVDs, the low level of the understanding of the difference between IFC and MVD on the user’s side, the implementations of MVDs in the software tools and the challenges related to releasing versions of the IFC, for example, updating each software release for new IFC versions [27, 28]. The IFC2 × 3 schema has four final MVDs: (1) Coordination View (CV); (2) Space Boundary Addon View; (3) Basic FM Handover View; and (4) Structural Analysis View [29]. The two common MVDs based on the IFC4 ADD2 TC1 schema are the Reference View (RV) and the Design Transfer View (DTV). Apart from RV and DTV, there are four other official MVDs within the IFC4 ADD2 TC1 schema: (1) Quantity Takeoff View; (2) IFC4Precast; Energy Analysis View; and (3) Product Library View [27, 29,30,31].

The idea of MVD as a handshake protocol is only partly implemented. While it is possible for an organisation to develop a new MVD, it is not possible for existing software implementations to export according to these MVDs without the developers implementing it first. This takes time and the responsibility lies with the software vendors. Exports are currently achieved using the base MVDs, such as the CV in IFC2 × 3 and the RV/DTV in IFC4 [27]. However, it is possible to validate the BIM models exported as IFC files using any valid MVD [32].

The development process of an MVD can be described by three core steps: establishing an IDM, establishing an MVD, and implementation [33]. The specification relating to what business processes and information need to be included in each MVD is standardised in ISO 29481-1:2016 [34]. The standard was developed by bSI to have a methodology that can capture and specify processes and information flow during the lifecycle of a facility. The IDM documents the business processes and information requirements. It also defines for one or more use cases what data are needed, who will provide the data and who is requesting it, at which stage of a project this happens and why it is needed. The Exchange Requirements are the part of the IDM that show what data are needed for the use case. Another part is the process map, a visual representation of the process. It shows how actors exchange information during the relevant phases [32, 35].

While the IDM forms a human-readable predecessor of the MVD, mvdXML represents the MVD as a computer-interpretable format. MvdXML has multiple purposes, one of which is the support of automatic IFC file validation [32, 36]. It can be used to define the correct nomenclature, as well as data types, must-haves, may-haves and similar rules to prepare a specific BIM project for easy data mapping and implementation. Several researchers have attempted to define valid and functional mvdXML documents using a variety of software, such as xPPM and IfcDoc [27, 32]. No matter which path prevails in the future, HBIM-specific interoperability challenges will need to be addressed. In previous research we have seen how important the quality of metadata is for heritage science [37, 38]. Therefore, it is not only necessary to advance the geometrical accuracy of HBIM models, but also to agree on the semantic classification of cultural heritage peculiarities in HBIM models. Thus, previous research proposed an experimental IFC classification implemented within HBIM open-source software (FreeCAD), whereby the limitations of IFC standards can be overcome thanks to the freedom of access to libraries and codes [39].

The conservation plan

The Register Kulturne Dediščine (RKD, eng. Cultural Heritage Registry) in Slovenia lists 16,207 heritage buildings that have some form of protection or restrictions [40]. In addition, based on national datasets on buildings and protected areas, we can deduce that 135,105 buildings are under some form of cultural protection, for example, protected city views [41, 42]. While there is no official data available for Europe on this matter, we can safely say that there are a vast number of buildings under cultural protection. In the case of renovation, acquiring approval from a cultural heritage authority is necessary to start the process.

In Slovenia, a conservation plan is a legal document based on the Cultural Heritage Protection Act [43]. It is produced by conservators to provide guidelines on the renovation or restoration of monuments and heritage buildings. The Slovenian conservation plan draws its roots from the Australian James Semple Kerr’s ‘The Conservation Plan’ (first edition 1982) [44]. This book is still widely used by heritage professionals and had a great influence on conservation research field in Europe [45]. This can be seen in other authors taking similar approaches to conservation documentation, such as [13, 23, 46]. The Slovenian protection act defines the duties of the conservators, including research oversight and restoration interventions in heritage, advising owners on protection procedures, participation in the preparation of cultural protection conditions and consents for interventions on immovable heritage and in the preparation of management plans [47]. A conservation plan typically consists of images, 2D floor plans and descriptions of the elements that have some particular importance or that are vulnerable.

The plan can be divided into three sections: (1) a basic document dealing with the conservation; (2) a specific document in the case that the heritage is more complex (the heritage survey); and, if extensive changes are planned; and (3) a document focusing on the execution of the conservation/restoration (the conservation/restoration project). The conservation plan deals with understanding the object, assessing the significance of the heritage itself, and the elements inside. It assesses the vulnerabilities and threatened objects and declares policies on how to deal with the heritage [43].

The conservation plan is a comprehensive document, containing mostly textual descriptions of objects [48]. While objects are typically grouped by element type (floors, windows, doors etc.), the spatial context around the object is not always self-evident. In the best approach to the renovation of heritage buildings and restoration we would integrate the guidelines and the design into a single common environment. However, with the current approach, the conservation plan is only read by a small group of people [49]. This hinders an understanding of the importance of heritage conservation in buildings. The entire chain of problems boils down to one common factor: limited communication.

The inclusion of HBIM in the process reduces these problems. A spatial context is provided, and data can be added as semantic information to objects or the complete project. Conservators are, however, usually neither BIM nor IFC specialists. So far, there is no MVD that limits the scope of the IFC for conservators. In addition, to prevent a loss of information that is added to HBIM models during the process, a data model must be formalised. This could add to the interoperability between software when dealing with HBIM models.

Previous research on a similar topic to the conservation plan includes data models for damage assessment [13, 46] or other structural or physical properties [50]. Moreover the use of HBIM for stratigraphic analyses has been researched [9, 51]. Acierno et al. looked at the interactions between actors and HBIM data for the purpose of heritage conservation [52]. The connection between standardised heritage ontology and BIM was described in [15]. The authors expressed the need for a methodology that links the IFC and the heritage data model. This research is not the first with regard to cultural heritage proposals for the IFC schema: Diara and Rinaudo [39] proposed informal additions to the schema using FreeCAD. Instead of including heritage elements in the ISO standard, they proposed the use of data-extraction methods to exchange the heritage information between different BIM software.

The use of MVD instead of data-extraction methods for data exchange was not yet investigated. It has the capability to be more standardised, automated and to ensure a higher-quality model. While the focus of Diara and Rinaudo [39] was on the classification of elements into ‘roles’ fit for heritage (such as Cladding Wall or Retaining Wall for the IfcWall element), the focus of this study is the standardisation of the information in the conservation plan into the IFC schema.

Aim of the research

The interoperability and accessibility of HBIM data should be addressed to increase usability. A formalisation of the needs for heritage is required to ensure the transparency and traceability of the decisions and actions. Even given the many advantages of HBIM (see [2,3,4,5, 23, 50]), it is understandable that conservators are reluctant to move to a BIM-enabled workflow: the existing processes are well documented and clear, whereas there is no framework for dealing with Heritage BIM that ensures a quality of data such that the output is fit for the replacement of a conservation plan [23, 39].

Therefore, this study describes the concept of a new bSI domain: the heritage domain. In this research the process of MVD creation was followed to open discussion about the domain. An IDM is developed to describe a part of the conservation-and-restoration process. Consequently, an MVD is extracted from the IDM. Concepts not available in modern buildings are introduced and evaluated based on the state-of-the-art data-exchange specification format mvdXML. Additionally, a completely new data model is proposed and mapped to IFC to facilitate data exchanges in HBIM. The MVD in the context of this research is by no means meant as a comprehensive definition for cultural heritage, but rather a showcase about what is possible and the beginning of a larger process of IDM/MVD development within heritage domain. This process should lead to a better quality of data quality in HBIM.

Methodology

Selecting the case study to create HBIM: Mrak’s homestead

This is explorative research into the use of IDM/MVD OpenBIM processes for heritage. In such circumstances the use of a single case study is justified. Multiple use cases can help to find possible frictions and exceptions; however, this is desired in the later stages, where the use case has proven to be effective. We had access to a conservation plan and supplementary documentation for Mrakova domačija (Mrak’s homestead, Fig. 1), a residential building built in the seventeenth century that is in the north-west of Slovenia near Bled and protected as cultural heritage of local significance. The conservation plan of the case study is taken as a basis for the research. The focus on Slovenian documentation means that the applicability of the research is narrow. However, as with any case when working with cultural heritage it is necessary to deal with regional regulations; therefore, the focus is justified. As the Slovenian conservation plan is largely based on the groundwork of Kerr and draws on previous attempts at HBIM data models like [13, 46], this research is still widely applicable.

Fig. 1

Mrak’s Homestead (left) and the entrance portal (right)

Today’s homestead is the result of alterations from the 17th to the twentieth century. It reveals the traditional method of building farmhouses and interior design. It was identified as architectural heritage because of this and it will be restored and renovated to serve as an ethnological museum, showcasing the lifestyle of Slovenian farmers in the past. The decision to use it as a demonstration case was based on the assessment of a conservation plan that contains all the relevant data, the inclusion of which we wanted to showcase in our study. Furthermore, a point cloud was acquired and the basic BIM model was built for other research purposes. Developing the IDM and MVD complemented wider research efforts for the digitalization of this built asset that might help revitalize it and use it as a demonstration project for innovative approaches for heritage protection.

Methodology for evaluating IFC import and export data quality

This research consists of three parts: (1) development of the IDM as a predecessor of the Heritage MVD; (2) creating a Heritage MVD using IfcDoc; and (3) automatic checking of the IFC model using the newly created MVD. This is illustrated in Fig. 2.

Fig. 2

Conceptual model

Developing an IDM for heritage

Creating an IDM that can be used to create an MVD that is accepted by bSI as an official model is a process that requires many actors from different countries. The rules on how to develop an IDM are defined in the ISO standard 29481:2016 [34]. Currently, this process can be followed in the Building Energy Modelling (BEM) field, where actors have made progress to create an IDM. Another completed IDM can be found on the bSI website for geo-referencing, the Model Setup IDM [53]. In this research we are not trying to develop an official, all-encompassing standard for a heritage MVD; rather we wish to demonstrate a base that is able to show that a heritage MVD is possible and why it is needed. No consensus between countries is needed yet and the MVD developed will be simple. Therefore, we consider it appropriate not to follow the rules defined in the ISO standard strictly, but rather to use them as guidelines. The process on data flows is studied in detail and a data model is found that describes the relations between element classes, attributes and properties.

The IDM is based on the rules of the Slovenian Heritage Agency with a single use case: the conservation plan. The data are derived from various acts found in the Official Gazette of Slovenia. The acts together make the regulations on conservation and restoration. Uradni list RS, št. 66/09 [48] defines the Rules on the Conservation Plan, which is essentially a template for conservation plans. Also, the conservation plan of Mrak’s homestead follows this template. Other relevant documents are [42], which establishes the various types of heritage, and [43], which defines policies around the protection of conservation.

Creating an MVD based on an IDM

The constructed IDM is formalised into an MVD appropriate for the IFC schema. This is achieved by mapping the extracted data entities stemming from the conservation plan to their appropriate IFC classes. MvdXML is chosen as an appropriate format to formalize the MVD. In the mvdXML format, the applicable entities are defined and the rules set in the data model are created using template rules in the mvdXML format. The baseline is an IFC version that allows the referencing of existing entities and concept templates. In this research, IFC4.0.2.1. (IFC4 ADD2 TC1) is used as a baseline.

HBIM model checking

The IFC model of Mrak’s homestead is created and the data relevant to the conservation plan are added to the model. The conservation plan’s data are added to the HBIM model as replacements for the PDF document and conform to the IDM/MVD. However, deliberate errors are produced in the IFC file, with the purpose of testing the quality of the MVD for model checking. Consequently, detected and undetected errors are reported.

Data acquisition and resources

A georeferenced point cloud of the entire building was created using photogrammetry and a geodetic survey. DSLR cameras we used for the photogrammetry and the point cloud was built in Autodesk Recap. The point cloud and survey were used as a reference for creating a CAD floor plan and the sections. Together with the point cloud, these were used as the input for building the BIM model (See Fig. 3). The point cloud and BIM model were available at the start of this research.

Fig. 3

Point cloud of Mrak’s homestead (left) and BIM model (right)

The HBIM model of Mrak’s homestead was created in Blender¹ with the BlenderBIM² add-on. Blender is used because of its reliability in IFC exports. The add-on uses the IFC schema to structure the BIM model. Therefore, there is no data loss expected (in contrast to many other BIM programs that use a mapping table to map the elements to the IFC, see [30]). Newer versions of BlenderBIM (versions after January 2021) work directly with IFC files, so exports are not needed. The case-study model was created in an earlier version (v.0.0.201025).

The properties and property sets were added programmatically using the IfcOpenShell library.³ While it is possible to do this manually in Blender using the BlenderBIM add-on, this way was chosen to save time. A mapping table was made with the name of each modelled element, the ifc class and the property values that should be added. Using a Python script, the values were linked to the actual elements and added.

The mvdXML was created using IfcDoc⁴ (IFC documentation generator). This is a tool, created by bSI, that is able to produce mvdXML, a computer-readable MVD format that can be used to test IFCs on that MVD. In the IFC documentation generator it is possible to propose updates to the IFC schema that can later on be adopted by the bSI organization as an official new version of the IFC exporting handshake protocol for different software environments. The IfcDoc structure is very similar to any IFC documentation found on the bSI website. The reason is that IfcDoc is used to produce the documentation in the first place. The checking involved a small prototype developed by one of the authors that follows the MVD structure and reports on the errors identified in the IFC file. Other methods are available for checking with mvdXML, e.g., xBIM or mvdXMLChecker [32], but for the purpose of this research, our method is sufficient.

Results

Developing an IDM for the heritage field

The processes around the renovation and restoration of cultural heritage in Slovenia have been researched extensively by [49]. A few key area where HBIM could enhance the renovation/conservation process were defined by various actors: (1) capturing the current state of heritage in BIM using scan-to-BIM (architect); (2) renovation proposal (architect); (3) guidelines of the conservation plan (conservators); (4) automatic checking of guidelines using MVD (cultural heritage authority); (5) plans of the renovation project (architect); (6) using 4/5D BIM in construction (contractors); (7) HBIM monitoring for Facility Management (heritage owner). The current project is focused on (3) and (4).

The data model can be found in Fig. 4. The project that is described is that of a conservation plan. This plan contains one or more objects that are defined as cultural heritage, and which are described in detail. The objects that are described (Cultural Heritage Object) refer to architectural heritage, a cultural landscape, urban heritage, or any other of the heritage types found in the Heritage Type. In the conservation plan, the general information about the heritage object is first described. This is information about the construction period, demolition period, the cultural significance of the object as well as the vulnerability and the risk. The demolition period may need an extra explanation: investigations of heritage over a long time period are not rare [11]. Sometimes the entire investigated site is already demolished or severely damaged [54], but for an analysis of its former structure, it must be modelled (see, for example, [55, 56]). This type of analysis calls for a demolition period attribute. The vulnerability describes the general threats to an object, such as climate impact or disasters, while the endangerment describes the immediate threats to the heritage.

Fig. 4

Created data model that includes all the relevant data for the conservation plan

Moving forward in the conservation plan document, more specific elements inside the object are described: first, the spatial layout (rooms and areas) and later the elements that are called physical elements in Fig. 4. These are the windows, doors, wooden beams, walls. Each room is detailed separately, with information about the function and use of the room in different time periods. Areas are the subdivisions of rooms into smaller parts and are elaborated in a similar manner. Each physical element is typically described with a photograph, a textual description (including construction year, description of materials, vulnerabilities and endangerments). Some elements can be deconstructed into even smaller parts: walls for example, can be subdivided into multiple surfaces, for stratigraphic analyses. One part of the wall might be painted and therefore more valuable than another. The significance value of each element is not found together with the description of the element, but expressed in a floor plan with standardised colour values somewhere else in the document.

Each element and each surface division can have one or more material attributes that describe the state of the material, together with the interventions that are needed to restore the material. The specialisation of the expert that is needed to deal with the material is described here, as well as the region of origin and the age of the material. Non-physical elements are described in the conservation plan too, such as the rooms and areas within the rooms. These are described with a function, a use and a period of use.

The period type is described with a start date and a possible end date. This is chosen instead of just using a date to describe the temporal elements in the data model, for two reasons. Many monuments and heritage buildings were not constructed over the course of a single year, but rather a decade. Churches could take up to a century to construct. The second reason is that it is often unknown when assets were constructed or demolished. In conservation-plan documents this could be described as ‘the first half of the sixteenth century’, or ‘the end of eighteenth century’. These text-wise descriptions are readable, but become a problem when searching for all elements from before the seventeenth century, for example. In these cases, a fuzzy date (1500–1550, or 1780–1800 in the examples) is a lot more convenient. As in some cases the year, or even month/day that something is constructed or demolished is known (for example, because it was demolished during an earthquake that was recorded), only a starting date needs to be provided.

Creating MVD based on IDM

Now that the data model is defined, it should be converted to comply with IFC standards. Therefore, all the elements in the data model should be assessed in terms of which class in the IFC schema they belong to. The conservation plan itself is on the same hierarchical level as the IfcProject class: it is the head of the document. The Cultural Heritage Object is somewhat more ambiguous: the objects could be of type Heritage Building, Cultural Landscape, Urban Heritage (multiple buildings) or Technical heritage (e.g., a bridge). In IFC4.3 these objects could be classified in the IfcFacility class [57]. However, as this class is not yet available in IFC4, we consider the IfcBuilding class to be the most appropriate. The logic follows that IfcBuilding is the central hierarchical element in the schema, and can be considered not only as a ‘structure that provides shelter for its occupants or contents and stands in one place’ [21], but also as any ‘built’ element in the built environment.. The Physical Element is mapped to IfcElement. Rooms and areas are both mapped to IfcSpatialZone, as they have the same properties and IfcSpatialZone defines both the rooms and the smaller zones. The Element Surface is equivalent to the class IfcSurfaceFeature in the schema. Materials are treated as a separate class in the IFC schema (the umbrella for all the material types is IfcMaterialDefinition). Therefore, instead of treating material as an attribute, with CHMaterial as an extension of that attribute, the material is treated as a class. As such, CHMaterial becomes a property set. While the Significance is a separate class in the data model, there is no such class in the IFC schema, and therefore its more appropriate use is as a complex property. The SignificanceValue and the HeritageType are both enumerations, a concept that exists in IFC. The Period data structure does not exist yet: coming soon are the IfcTimePeriod, which measures the duration (in 24 h), IfcDuration, which measures the number of days a task takes, but not when the task starts, and lastly IfcTaskTime, which among many other attributes contains a ScheduleStart and a ScheduleFinish attribute, both of the IfcDateTime type. However, this class would not correspond to all uses of the Period type in the IDM: The period of use attribute in the Room and Area classes and the Material age Material attribute are periods, but do not relate to tasks.

Adding the properties and property sets

The properties and property sets are the first structure elements added to the MVD. All possible enumeration values that will be referenced by property enumerations will be added to the PropertyConstants tab (e.g., ARCHITECTURAL HERITAGE, CULTURAL LANDSCAPE, etc., as well as DISTURBING, SMALL, MEDIUM, etc.). Consequently, the enumerations are added to the Property Enumerations tab and the related PropertyConstants are referenced.

As can be seen in Table 1, a new domain IfcHeritageDomain is created in the Domain-specific schemas-tab in IfcDoc. In this domain, property sets are created for applicable entities. Six property sets are added: (1) CHPeriod; (2) CHSignificance; (3) CHElement; (4) CHType; (5) CHSpace; and (6) CHMaterial. The CHPeriod has two properties: StartDate (IfcDate) and EndDate (IfcDate). CHSignificance has three properties: SignificanceValue (SignificanceValueEnum); SignificanceType (IfcLabel); and SignificanceDescription (IfcText). CHElement has properties: Vulnerability (IfcText), Endangerment (IfcText), Demolished (IfcBoolean), ConstructionPeriod (complex property inheriting properties from CHPeriod), DemolitionPeriod and Significance (a complex property inheriting properties from CHSignificance). The CHElement property set is applicable to IfcElement and IfcBuilding. The CHType property set only has the HeritageType (HeritageTypeEnum) property and is applicable to the IfcBuilding. The CHSpace has the properties: Function (IfcText), Usage (IfcText), and PeriodOfUse (a complex property inheriting properties from CHPeriod). CHSpace is applicable to the IfcSpatialZone entity. Lastly, CHMaterial is applicable to IfcMaterialDefinition (parent of IfcMaterial, but also to IfcMaterialConstituent or IfcMaterialLayerSet, etc.). The CHMaterial properties are: MaterialState (IfcText), Region (IfcText), Specialisation (IfcLabel), Interventions (list of IfcText), and MaterialAge (complex property inheriting properties from CHPeriod).

Table 1 Data model translated into property sets, applicable IFC classes, properties and IFC property types

he ‘material association’ template is added to the IfcElement and IfcSurfaceFeature tables. The IfcElement implements the ‘Decomposed by’ template and is decomposed by IfcSurfaceFeature. IfcProject implements the Project Document Information template.

Creating a new MVD

In the Scope tab, a new view is added on top of those already existing (CV, DTV, RV and General Usage). The Heritage View is meant for cultural heritage use cases. As this research deals with only a single use case, the conservation plan, only one Exchange Definition is added: the Conservation Plan Exchange. For each previously mentioned entity, a table definition is added to the MVD and rules are added for each entity. The property sets that are previously described are added with the Property Sets for Objects template that is found under the ‘Fundamental concepts and assumptions’ tab. The template for material association is also used to link objects with materials; the Decomposed by is used as an object decomposition relation and the Document Information template is used to describe the general project. Using the Export File function, the mvdXML is created. Manually, some extra rules are added that were defined before, but were found impossible to implement in IfcDoc. Examples of such rules are: if the Demolished property is TRUE, the DemolitionPeriod complex property is required, otherwise it is not. The structure with all the added elements is shown in Fig. 5.

Fig. 5

Relevant classes in the Heritage MVD

BIM model and MVD checking

The IFC file is produced according to the data model, as a replacement for the conservation plan (see Fig. 6). In this BIM model, the same information is stored; however, everything is related to the elements in the 3D models. Properties are added for each element of relevant classes. The file is produced with deliberate errors. The generated errors can be found in Table 2. All the errors are caught by the checker (see Table 3).

Fig. 6

IFC model automatically coloured by IfcSingleProperty SignificanceValue, that is part of the Significance complex property in the CHElement propertyset. The RGB values of the colouring are according to the Slovenian standard [48]

Table 2 Errors included in the IFC file

Table 3 All errors in the IFC file caught by the checker

With the creation of the mvdXML, we ran into several expected problems. As a developers’ tool, IfcDoc has little documentation on how it functions. In addition, it requires deep knowledge of the IFC Schema to use it [27, 58]. Firstly, importing a baseline was not straightforward. We could import the mvdXML of the baseline in the program. However, this did not provide the full schema. Instead, to add the baseline, the IFC4.0.2.1 branch from the BuildingSMART/IFC GitHub repository is forked and downloaded. The folder is opened in IfcDoc, not as a *.IfcDoc file, but as the whole folder.

The creation of template rules for property sets in IfcDoc does not work at the level we would hope. The template rule had some shortcomings in remembering the properties inside the property sets. The full issue (#71) can be found on the IfcDoc GitHub repository [59]. The template rules containing properties were added manually after the MVD export. That way we were able to add a checker for all the properties, while still producing a valid mvdXML. Like the single and enumerated values, complex properties are added manually too and copied afterwards. One additional problem with respect to the complex properties was the absence of the complex properties in the Property Sets for Objects template of IFC4 ADD2 TC1. The mvdXML file of RV1.2 did implement complex properties in the template; therefore, that one was imported and used.

Discussion

The interoperability and accessibility of HBIM data should be addressed to increase the usability and to improve the model’s data quality and completeness. Therefore, the process of MVD development was followed. In this research, the conservation/restoration process was investigated and formalised as an exchange model between the creator of the guidelines for the conservation and the authority that needs to approve the guidelines, by means of an IDM. A data model was developed that dealt with the information in the conservation plan for our case study of Mrak’s homestead. By means of an MVD, the guidelines’ data model was adjusted to the IFC schema using IfcDoc. Lastly, the MVD was used to validate an IFC model of the case study that was created to conform the guidelines. Nine deliberate errors were placed in the IFC model to examine the validator. All the errors were found.

As a result, we demonstrated that the OpenBIM approach to BIM data quality can be adapted for heritage needs. The IFC model can hold the necessary information in the conservation plan with the use of predefined property sets. The IDM/MVD workflow can check the IFC models on the completeness of the data and the data quality. This opens doors to computer-aided model checking for conservation plans, which can save resources. For use on a larger scale, more development is still needed, with new and larger case studies. For wider applicability and interoperability, we should use the CIDOC CRM instead of the Slovenian legislation as basis for future research. The balance between international standardisation and support for the local context will be a crucial component here.

For the effective implementation of a Heritage MVD, it is also essential that the necessary tools are developed. Currently, there is no easy-to-use MVD checker software available, where someone who is not a developer can simply drag-and-drop an MVD and an IFC model and check the model according to the rules in the MVD. When such software exists, other use cases of the Heritage MVD can be found, such as the automated checking of a renovation/restoration plan on the conservation plan using change detection. Such a use case can support better decision making in the distribution of building permits for heritage buildings. Using the GUIDs of elements, all the modified and removed elements in the IFC model can be found. We can check whether it is permissible to make these changes to the heritage building.

This research showcased the orchestration of the different OpenBIM standards in the HBIM domain. The great potential of the IfcDoc software for the development of customized MVDs based on different IFC schema versions is recognised. Additionally, the machine-readable mvdXML allowed for IFC model checking using algorithms, rather than manual checking. This saves a considerable amount of time during the development of the BIM model. However, we should be cautious with implementing a fully automated approach, which can also be prone to mistakes. Rather, the automated model checking should be included as a computer-aided process that is curated by experts. We see the OpenBIM methods as the best way forward in the heritage domain, where a continuous improvement of the models could be achieved with predefined human- as well as machine-readable specifications. Thus, we call for a joint effort by the international community and clear governance by bSI in the heritage BIM domain.