An Ontology-Based Representation of Vaulted System for HBIM

Abstract

In recent years, many efforts have been invested in the cultural heritage digitization: surveying, modelling, diagnostic analysis and historic data collection. Nowadays, this effort is finalized in many cases towards historical building information modelling (HBIM). However, the architecture, engineering, construction and facility management (AEC-FM) domain is very fragmented and many experts operating with different data types and models are involved in HBIM projects. This prevents effective communication and sharing of the results not only among different professionals but also among different projects. Semantic web tools may significantly contribute in facilitating sharing, connection and integration of data provided in different domains and projects. The paper describes this aspect specifically focusing on managing the information and models acquired on the case of vaulted systems. Information is collected within a semantic based hub platform to perform cross correlation. Such functionality allows the reconstructing of the rich history of the construction techniques and skilled workers across Europe. To this purpose an ontology-based vaults database has been undertaken and an example of its implementation is presented. The developed ontology-based vaults database is a database that makes uses of a set of ontologies to effectively combine data and information from multiple heterogeneous sources. The defined ontologies provide a high-level schema of a data source and provides a vocabulary for user queries.

1. Introduction

In the last decade, the advent of digital modelling tools and in particular the rise of the building information model (BIM) paradigm, changed completely the approach of representing ad managing the so called “built cultural heritage”. Indeed, by adopting the BIM concept to historical building information modelling (HBIM) it is possible to correlates 3D models—describing the geometry of heritage architectural objects and their elements (i.e., walls, covering systems, vaults, decorations)—with different pieces of information (materials, construction techniques, physical properties, decay, etc.). Several works in literature are proving the effectiveness of HBIM as a new paradigm for managing restoration works, maintenance works and management of historical buildings [1,2,3,4,5,6].

BIM can represent a powerful tool to boost digital economy, for example in Europe the ‘Directive on Public Procurement’ (EUPPD 24/2014) asked the 28 EU countries to adopt ‘building informative modelling’ by February 2016 in order to support the whole LCM (life cycle management). However, several authors [7,8,9] have highlighted bottlenecks to an effective adoption of BIM, and even more of HBIM, in current practice. Brumana et al. [10] underline that to increase the HBIM adoption it is necessary to undertake different actions devoted to tackle two of the main issues: improve the time-cost effectiveness and diminishing the technical gaps nowadays present in the HBIM workflow.

As highlighted by different author main requirements to fully adopt BIM for historical architecture are: (i) the quality of the model and its reliability to represent the geometrical complexity of components (e.g., irregular vaults, out-off-plumb walls, etc.) [11] and, (ii) the addition of a comprehensive semantic database of historical components, materials, information and notes regarding each building element and changes during time [12].

In addition, digital cultural resources have a great economical potential, even if often not fully exploited. Indeed, once a cultural heritage site is digitized it can have multiple uses. For example, it can be used for not only managing and conserve the digitized element but it may have different secondary uses like giving access to cultural heritage to citizens, researchers, having an impact on cultural and creative industries [13]. This way, the cost-effectiveness of the adoption of the digitization is increased. However, such exploitation of the HBIM is seldom preformed. In many cases, HBIM models are used only for case specific purposes limiting this way their general impact.

On the other side, several works highlighted interoperability as a main gap to be overcome for an effective adoption of HBIM [14,15,16]. Indeed, the architecture, engineering, construction and facility management (AEC-FM) sector is very fragmented. In addition, when dealing with historical buildings further expertise (restorers, historians, archivists, etc.) are generally necessary to have an in-depth understanding of the building. For this reason, experts in several different domains collaborate on the same project. Some of them feeding the model with specific information (e.g., restores reports material and conservation state of elements, historians contribute in understanding the different historical phases etc.), while some other query the HBIM model as a centralized model and extract specific information for the different construction domains (e.g., estimating, scheduling, supply chain and fabrication). Each construction domain has specific requirements and needs a specific set of information representing their views of the project. In addition, a further gap to effective interoperability is given by the fact that each sector stores their information in heterogeneous data formats [17].

However, the user of a BIM platform is limited to the platform schema and is not able to define information that falls out of it, as in the case of a HBIM project [14]. In many cases also the adoption of the Industry Foundation Classes (IFC) representation of BIM data is not enough flexible to allow an effective sharing of the data. Semantic web technology can be used to try to bridge the previously defined gaps. Indeed, by using semantic web tools data, pieces of information provided by different users can be combined with other data sources in a smooth way [18]. Anyone involved in the project can express his/her information about the building in a way that can be easily combined with the information provided by other actors. In addition, the fact that web technology is used allows also the sharing of building information on the web and, more in general, to a larger public of experts. Indeed, the HBIM represents a punctual in-depth analysis of a specific building and once generated each HBIM represents a node of information. In order to avoid the risk to lose such richness and knowledge, and as previously underlined the economic value associated with an effective exploitation by cultural and creative industries, the possibility to share information stored into a HBIM in a web platform way is fundamental. We can also envisage that in the future the availability of growing HBIM will increase the opportunity to access to all these nodes in a cross-sectorial way in order to correlate all the nodes and the information contained.

The aim of this paper is to present the usefulness of a semantic-based tools in the BIM by expanding the approach presented in Niknam et al. [19] to HBIM. In particular, two different domains will be explored in order to prove the effectiveness of the presented method to integrate knowledge coming from different sectors in the AEC-FM domain: (i) the restoration domain with the definition of an ontology for vault element and (ii) the survey domain with the construction of a specific ontology describing survey characteristics and outputs. An ontology is a representation in terms of: formal naming and definition of the categories, properties and relations between the concepts, data and entities into a specific field. The defined ontologies provide a high-level schema of a data source and provides a vocabulary for user queries. A final discussion is carried out presenting the possibility of using the semantic web tools for sharing knowledge derived by several HBIM model.

2. Motivation and Main Contribution

This paper focuses on vaulted systems, a common architectural covering in the past. The vaults are characterized by a variety of typologies (barrel vault, cross vault, cloister vault, etc.) with different shapes and materials (bricks, stones, wood, etc.). Mixed combination of forms and geometries were developed across time and space: their construction techniques come usually to light during analysis and diagnostic phases planned for preservation purposes. It is possible to trace diverse constructive traditions across Central Europe, Northern Europe, Middle East and Mediterranean regions, to cite just some cases. Thanks to the activities of skilled worker families across Europe the adoption of specific solutions (construction techniques, arrangements and centering construction) has been progressively documented and can be found across different regions. A notable example is the ‘Magistri Comacini’ from the Como Lake during the Middle Age [20]. Different vaulted systems have been obtained thanks to worker capacities of assembling materials through specific construction techniques, such as the ancient skills of stone cutting (stereotomy) or brick blocks disposal in the space [21] or wooden vaults solutions. Unfortunately, a cross-sectorial study of such knowledge is nowadays largely absent, and is sometimes just documented at a fragmented local dimension without any correlation to a global scale, where all the gathered information can be related to each other.

The potentials offered by HBIM to represent these elements, not only geometrically but also from an informative point of view (e.g., materials, arrangement, construction technology, etc.), can significantly contribute to create a wide knowledge of vault typologies at a larger scale. However, a shared way of describing vaulted system is necessary to fully exploit the knowledge that can be extracted from HBIM analysis, as well as the need of specific tool to share collected information. Semantic web technologies can significantly contribute to this aim since they can be used to integrate different pieces of information here applied to the vaulted systems, allows reconstructing a new framework of the different construction techniques adopted around the world, as well as permanencies and mutations respect to the common typologies. A specific ontology framework needs to be defined to achieve this and this is the main contribution of this paper.

3. State-of-the-Art

Currently, the AEC-FM domain is very fragmented for what concern data sharing and formats. Indeed, each domain in the sector has its own specific requirements and specification, for this reason different operators in the sector store data in different formats and schema [17]. This heterogeneity of the domain determine duplications or information lack, delays and increases of construction cost. Indeed, a simple integration of data stored into different data structures is prevented due to:

• Data formats adopted by different sectors may present incompatible data structure,
• Different sectors may use different vocabularies to refer the same entity or the same term may have different meanings in different domain,
• Data schemas are generally locally stored and cannot be shared and dynamically modified among different applications.

Those problems make interoperability one of the most important issues connected with HBIM [11,14]. A typical interoperability issue is associated to different class hierarchies to describe the same building element in the restoration and scheduling domain. Integration problems of data stored in relational or object-oriented databases are typical in the case of semantic web applications [22]. Semantic web technologies extend the World Wide Web fundamentals to data [23]. In particular, the semantic web provides a common framework allowing data to be integrated, shared and reused across different applications and domains [24]. For this reason a semantic representation of a HBIM would allow different actors involved in the same project to express data and information according to their own specific requirement in a way that can be easily integrated with the ones provided by other domain [16,25].

To integrate different data sources, semantic web technology uses formal ontologies [26] to define concepts (named as classes) and relationship between them [27]. Ontologies represent a shared formal view, defined between several parties, of a specific domain expressing the main elements addressed in the sector and their relationship [28]. In other words, an ontology is representing a domain knowledge base. In a semantic web, a distributed network of connected knowledge is defined and can be related each other by using uniform resource identifiers (URIs). Ontologies are generally expressed using the RDF/OWL languages. In RDF/OWL languages, concepts and relationships are represented in triplets (subject verb and object) that can be also described using a graph data structure [29]. URIs and triplets provide an information space of interlinked scattered data.

Currently, there is a lack of a standard ontology that can be used for converting HBIM data to a semantic format. Some actions are on-going to formalize a standard ontology for BIM by the linked data working group (LDWG) [30] that is formed under the umbrella of the BuildingSMART International. Starting form the first attempt of Beetz et al. [31], that used an EXPRESS-to-OWL conversion to develop an ifcOWL ontology, the Linked Data Working Group (LDWG) is working to standardize ifcOWL [30,32]. However, this ontology lacks some aspects to entail the specificity of HBIM representing historical architecture and cultural heritage.

Concerning cultural heritage, a well-known attempt to provide a cross-sector knowledge across many cultural heritage sources is the CIDOCS/CRM (conceptual reference model) ontology [33]. Different works in literature are building specific applications on the top of the CIDOCS/CRM ontology [34,35,36]. Cultural heritage ontologies are mainly used to develop high-level tools for exploration of digital archive and digitalized contents, allowing integration of distributed and heterogeneous resources [37,38]. Simeone et al. [39] proposed an integration between HBIM and ontology to take advantage of ontology reasoning for historical artifacts. The ontology proposed in Simeone et al. [39] was further developed to take into consideration the relationship between historical artifacts and the actors involved in their conservation and restoration process [40]. Recently, workflows for integrating HBIM and semantic web technology were presented in Quattrini et al. [41] and Garozzo et al. [42]. In Quattrini et al. [41] semantic data enrichment is carried out in Autodesk Revit©, one of the most used commercial BIM platforms. The main advantage of this approach is to proceed in the same time at the 3D modeling and data enrichment with parameters defined in a specific ontology. In Garozzo et al. [42] a specific ontology named as CulTO, Cultural Heritage Tool based on Ontology, was developed to support enriching HBIM models in the case of religious historical buildings. The developed ontology is aimed at enriching the HBIM with non-geometrical information such as historical documents, images, decay, etc.

4. Overall Methodology

Definitions of ontologies are necessary to set up the organization of building information [43]. As discussed in the previous section, many initiatives are ongoing to define a standard ontology for BIM. However, the case of HBIM presents some specific challenges since the building itself is a cultural heritage artefact. For this reason, HBIM is on the edge between different disciplines and the definition of a reference ontology is even more a crucial issue. In such a multi-domain environment, different methods can be used to defining a shared ontology:

• Develop a unique ontology that covers the different domains involved.
• Each domain develops its own ontology in an independent way and in a second step the ontology is aligned in terms of vocabulary and relations for information exchange.
• A “foundation” ontology is defined sharing the basic concept and relationship for each domain and starting from this each domain develop specific ontologies.

Each solution presents pros and cons. The development of a unique ontology requires a significant standardization and a general agreement among different actors. For that reason, this solution is quite difficult to achieve. In addition, the resulting ontology would have thousands of concepts and relations that would be difficult to understand and maintain. Finally, this solution will lead to a quite rigid structure of the ontology. Indeed, the addition of a new actor would determine the redesign of the ontology and of the general agreement.

A more flexible approach would be the definition of completely independent ontologies for the different actors working in the HBIM domain. For example, specific ontologies for as-built survey, restoration, scheduling, cost estimating etc. The main advantage of this approach is the fact that new actors can contribute in the overall project with a new ontology without the need of modifying existing ontologies defined in another domain. However, the lack of shared vocabularies results in difficulties in the integration of completely independent ontologies. In order to align them a manual and time consuming “mediation” phase is necessary in order to provide concept mapping, i.e., finding correspondences between concepts in two different ontology [44].

The definition of a “foundation” ontology can partially cope with the shortcomings of the previous two ontology definition methods. The main aim of the “foundation” ontology is to provide a common vocabulary among the concepts used by different domain ontologies. In this case, a loose interaction among the different actors is needed to define a relatively general framework. Starting form this shared view each domain can develop its own specific domain ontology by extending the “foundation” ontology. In this architecture, Semantic Web Rule Language (SWRL) rules or SPARQL queries are used to integrate data from different domains. The feasibility of this approach in the case of BIM was proved in Niknam et al., 2017 [19] to integrate design, cost, and schedule domain ontologies.

The aim of this paper is to extend this concept by enlarging the “foundation” ontology and including specific aspects that are relevant in the case of HBIM. For example, HBIM is generally an as-built BIM and the survey concept has to be added in the general framework. The addition, the survey concept is fundamental to report the accuracy and reliability of the HBIM model. In addition, it can provide the link to other survey products such as orthoimages and/or discrepancy maps among the original data and the HBIM model. We have to also underline that this approach is not in contrast with the standardization approaches existing in both BIM and cultural heritage communities. Indeed, for the “foundation” ontology we modelled building elements at a high abstraction level making direct reference to standard ontologies and schemas (e.g., ifcOWL), thus enabling the extension to other domain as well as integration with existing cultural heritage ontologies (e.g., CIDOC-CRM). The adaptability of the proposed approach to HBIM is proved by developing an ontology for the vaulted systems and an ontology for the survey domain. This study also presents a case study that applies the vault and survey ontologies to a building model proving effectiveness of the presented approach in facilitating access and integration of various domain data. Finally, an extension of the proposed method for creating an ontology-based database allowing the integration into a unique framework of different HBIM models is provided.

4.1. HBIM Shared Ontology

This section discusses the requirements for extending the building shared ontology presented in Niknam et al., 2017 [19] to the specific case of HBIM. The aim of this shared ontology is to provide a general framework providing a conceptual knowledge for a building that can be used as a starting point for developing domain-base ontology. The developed ontology presents concept that can be easily integrated with the ones in ifcOWL, this way allowing a possible integration with this second ontology. As in the case of Niknam et al., 2017 [19] a building is composed by several building elements (e.g., walls, roof, vaults, etc.). Since each domain has its own view of the building elements, both in terms of information and relations, definition of the specific role of each building element is not carried out in the “foundation” ontology but, if necessary, the specification will be carried out in the domain-ontologies. An historical building is generally characterized by different construction phases that may be designed and/or planned by a specific designer and/or owner, named as “actor” in the ontology. The different building elements are organized into rooms and the different rooms are organized into levels and spaces. Since and HBIM is always an as-built BIM the data source used to model each building elements play a key role. For this reason, each building element is associated to survey.

In particular, this general view of a HBIM process requires the following elements that are used in the “foundation” ontology:

• Building
• Building element
• Room
• Level
• Space
• Historical Phase
• Survey
• Actor

Figure 1 shows the main concepts and the relations included in the “foundation” ontology implemented in RDF/OWL language. In this framework each domain creates its own domain ontology by adding domain-related properties and relationships to “foundation” elements. The following sections explains how two different ontologies can be built on top of the “foundation” ontology: (i) a vaulted system ontology, and (ii) a survey ontology.

4.2. Vaulted System Ontology

The main core of the proposed methodology is the vaulted system ontology and the associated ontological database, which has been designed to characterize a wide range of vaulted systems. Before describing the developed ontology in detail, some key aspects connected with the problem of defining a comprehensive ontology of vaulted stems are given.

After an eclipse of almost one hundred years, vaults have returned to the center of architectural heritage studies. In France, thanks to the policy set up by Jean Marie Pérouse de Montclos, the revival of the inventory in 1964 led to a census of the significant realizations of stereotomy and the re-evaluation of the wide and learned writing treatises on the subject from the 16th to the 19th centuries. Similar trends can be also observed in Spain studies of the late Gothic and Renaissance periods [45], in England, especially for the medieval period, and in Germany with specific studies that include the Middle Ages to the Baroque period [46]. In Italy, even if some more extensive works exist, they seem focusing on specific time-space perimeter [47]. The result of this scenario is an extremely fragmented and heterogeneous picture where the level of knowledge is function of the methodological way the analysis is carried out, with a discontinuity in term of level of detail acquired and of space and time extension of the analysis. In this scenario, a general classification of vaults turns out to be a system with infinite variables, which would bring difficulties even in the limits, according to which a classification must be undertaken.

For this reason, an ontology approach seems the more adequate to create a vaulted system database. In the case, if a new vault typology, material or construction typology is identified this can be simply added to the previously identified. The most important things to be defined is the choice of the main parameters to be considered in the description, and classification, of the vaulted system. To define such characteristics the previously listed literature works and the experience of studying different case studies during the last 15 years were used.

Starting from the “foundation” ontology, a building element has a subclass horizontal (like a slab), vertical (like a wall or a column) and a trusting element (like a vault or a dome). As subclass of the trusting element, we identified as vault, dome and truss elements. The vault element is differentiated according to the vault typology (e.g., BarrelVault, CloisterVault, CloisterPavilionVault, Planterian, etc.). Vault elements are connected with some other object properties:

• Arrangement: courses along the generatrix, courses along the directrix, etc.
• Geometry: circumference, ellipse, ellipsoid, cone, etc.
• Texture: soldier-laid, in foglio paper applied or undefined;
• Material: clay brick, stone, etc.
• Subtexture: single texturing or double texturing.

All these elements, designed in the ontology as subclasses of VaultDescription, are characterized by peculiar properties. The authors did not use Free Class OWL ontology (FC) to classify building and construction materials since historical material may not present properties comparable with the modern ones that mainly compose the European Building and Construction Materials Database [48].

Each vault possesses the same components: StructuralArch, TieRoad, Frenelli, TieRoadExtrados, VaultElement. All components do not apply to every vault. This is one of the differences between semantic modeling and object-oriented modeling. Element identities are defined using the data type property hasIdentity and its sub-properties (e.g., hasDescription, hasID, hasSize, hasPosition, etc.).

The different object class and relationships are shown in Figure 2. It contains a partial visual representation of the developed ontology, and it specify which class should be considered part of another (blue arrows).

4.3. Survey Ontology

As previously discussed, since an HBIM is an as-built BIM, the reporting of the survey activities plays a key role in the modelling phase and needs to be included in the general workflow. Clearly, the view of a surveyor is different with respect to the one of the restorers and the semantic web technology may help in bridging them.

In the case of a surveyor, a BuildingElement is composed by two faces that are represented as subclass (in the case of vaults we will name then intrados and extrados). A BuildingElement is associated with a Survey with the relation hasSurvey. Three different elements are subclass of a survey: geometrical, material and crack.

A GeometricalSurvey has a subclass of the typology of the survey (Photogrammetry, LaserScanning, TotalStation or Direct) and has properties (geometricalSurveyAccuracy, geometricalSurveyPrecision, geometricalSurveyDate). For each GeometricalSurvey, the respective GeoemtricalSurveyProducts are associated (e.g., report, 3Dmodel, orthoimages, etc.). A similar approach is also adopted for CrackSurvey and MaterialSurvey. For the CrackSurvey the different typology of surveys are represented as subclass and each crack is associated to a Crack. Similarly, a MaterialSurvey has subclass the different survey tests (e.g., infrared thermography, sonic test, coring, etc.).

The different object class and relationships of the survey ontology are shown in Figure 3.

5. HBIM and Ontology Data Integration: Case Study

This section presents the integration of different data types by using the ontology-based approach described in Section 4. In particular, here it is summarized the case of the abacus of the HBIM vaulted system in the Magio Palace, Cremona (Italy). The survey of Magio Palace combined different technologies. In particular, the geometric survey is carried out to integrate both laser scanning and photogrammetry. Laser scanning data were acquired at the intrados while photogrammetry was mainly used to acquire the extrados to get the 3D model and orthophoto of the brickwork arrangement, if visible. On the other hand, a material survey was performed at the intrados with infrared thermography (IRT) for the indirect detection of material and the texture arrangement. In particular, three different vaults are addressed in this study:

• Manfredini Hall One, facing the road,
• Manfredini Hall Two, facing the court of the palace,
• The Stair Hall.

These three vaults belong to the same “cloister vault” category at first sight. However, the construction technologies influence the simplified conceptual shape coming from the vault typology classification (barrel vault, cloister vault, sail vault, dome), generating typologies turned toward mixed typologies [49]. In the case of the Magio Palace the survey integration evidenced the different arrangements and components of the three different vault typology: (i) the Manfredini Hall, tuned to trompe (Figure 4—top); (ii) the Manfredini Hall Two, with the typical rectangular slices coming from the intersection of two conceptual cylindrical solids (Figure 4—center); (iii) the stair hall, a dome turned to a cloister (Figure 4—bottom) [50].

Starting form acquired data the modelling of the vaults was carried out to generate the vault HBIM object. The Non Uniform Rational Basis-Splines (NURBS) originated through the generative modeling and were parametrized [51]. Specific properties were added according to the classes identified in the vault ontology (Figure 5).

Starting from the previously defined HBIM model, the steps to create a knowledge base of vaulted systems are summarized in Figure 6:

• HBIM model: HBIM or historical building information model is created by designers using a BIM platform (e.g., Autodesk Revit) with added information which defines the class of the defined ontology.
• HBIM ontology: HBIM ontology presented in this article provides the vocabulary for converting BIM data to RDF/OWL format before it can be saved in a vault knowledge base.
• RDF/OWL Converter: the converter module in this paper uses the database generated in the BIM platform (e.g., Autodesk Revit) and the ontology editor FlientEditor 2015 ©.
• RDF/OWL ontological database: the converted ontological database is saved in RDF/OWL format allowing the possibility to query it with a SPARQL endpoint interface that allows local and remote access to its data over the internet.
• Reasoner: connection with a reasoner adds logical interface to the knowledge base.

An ontology-based database is defined as a “database model that enables the ontology and the data to be stored in a common and single model” [52]. An ontology-based database explicitly represents ontologies, data schema, data and links among data and their schema and between the ontology [53].

Figure 7 shows a schematic view of part of the Magio Palace knowledge base. It points out how different instances of the BuildingElement are connected with the three different vaults used as a case study in this paper. We can also model the relationship in the vaulted system ontology. Figure 8 shows the representation of a BuildingElement; Manfredini Hall One. In particular, this vault is related to the historical phases, building level, and rooms. In particular, Manfredini Hall One belongs to the current historical phase and it is located in the room named as “Hall” at the first level (L1). In addition, we can infer that the Manfredini Hall One is a cloister vault, with in foglio single layer texture, has an arrangement with courses along the directrix, policentric geometry and is made of bricks. The Manfredini Hall One vault hasComponent and hasSurvey relations with component and survey elements. The vault also presents some specific properties (hasID and hasDescription).

The Manfredini Hall One vault is composed by a set of components. A partial view of the elements composing the vaults is presented in Figure 9. For example, the Manfredini Hall One vault is composed by a VaultElement with specific material and geometry and by Frenelli with specific material.

In addition to the above-mentioned relations, a HBIM knowledge database must also include survey properties. Survey properties include element like survey location (intrados or extrados), typology of the survey (geometrical, material or crack) and the survey products. Figure 10 shows the relations of two different geometrical surveys with Manfredini Hall Two.

As mentioned before, the ontology-based database is exposed using a RDF endpoint for further query and retrieval. Thanks to the ontology-based structure and the ontology reasoner, new added elements (vaults) are at the content-level encoding information and allows assessing the logical consequences of adding new knowledge and it may also infer new knowledge and add it to the vault HBIM knowledge base. The main objectives for using an ontological-base knowledge and a shared ontology are to provide query mediation and facilitate information integration across different domains. The data knowledge is stored as RDF/OWL format, allowing to query it by using a SPARQL endpoint.

For example, the knowledge base can be used to perform simple queries like finding all cloister vaults built with clay bricks (all SPARQL queries are presented in an abbreviated form to avoid clutter).

      SELECT ?element
      WHERE {?element rdf:type cloistervault.
      ?element hbimvault:hasMaterial ?material.
      FILTER (str(?material) = ‘clay-brick’).
     }
	 

Query 1 may be easily extended to retrieve properties for the selected building elements. For example, if we want to retrieve the survey products for this building, we can perform the Query 2.

      SELECT ?element ?product
      WHERE {?element rdf:type cloistervault.
      ?element hbimvault:hasMaterial ?material.
      FILTER (str(?material) = ‘clay-brick’).
      ?element hbimsurvey:hasSurveyProduct ?product.
     }
	  

The advantage of those SPARQL queries is that the different ontologies developed in the different domains can be easily integrated to provide a simple tool for a fast data search and retrieval. We have here to underline the role of the “foundation” ontology that works as a mediator. The fact that all building domain ontologies are derived from a shared ontology enables all building domain knowledge bases to understand queries composed of the shared ontology vocabulary. The approach proposed in this paper is a lot faster and flexible than the one based on a standard relational database. In addition, it is coupled with a reasoner and has the potential to infer new knowledge.

6. Accessing the Ontology-Based Vaulted System Database: A Geographic-Based Hub Platform

Querying the ontology-based vaulted system knowledge base with a SPARQL endpoint is not considered an end user task because it requires familiarity with SPARQL query language, that is not trivial, and also the structure of the underlying knowledge base. For this reason, a specific query interface is needed to enable end-users retrieve information from the vaulted system DataBase.

Figure 11 shows the data flows and the structure of the web-client application for investigating the vault knowledge base. In particular, the Database is connected with a geographic server by means of a script that queries the SPARQL endpoint and transform the answer of the query into a shapefile. This shapefile is then connected with a geographic server. The server-side software used is GeoServer [54] a powerful open source platform for publishing spatial data and interactive mapping applications on the web and standard GIS software (both commercial software, such as ESRI ArcGIS [55]), and open source software, such as QGIS [56]. More specifically, GeoServer allows the visualization of produced data by using Open Geospatial Consortium (OGC) standards like WMS, WMTS, WFS and WCS that are compatible with different solutions allowing data mediation [57].

For a simple consultation of the data a specific web-client graphic user interface (GUI) was designed (Figure 12) allowing data query and analysis using the common query language (CQL), created by the Open Geospatial Consortium (OGC), and an extended version of this language ECQL allowing for ID filters and having a higher similarity with standard query language (SQL). In particular, the GUI allows, by using a set of windows, to filter data according to vault typology. Let’s assume for example to perform a query aimed at extracting only barrel vaults surveyed by laser scanning from the vault system DB.

Input in the GUI are translated into a simple CQL query:

      VAULT_TYPOLOGY = ‘Barrel’ AND SURVEY_METHOD = ‘LaserScanning’
	  

If the user wants to filter the results into a specific area, he/she can simply draw the search area on the map and this is translated into the following CQL query:

      VAULT_TYPOLOGY = ‘Barrel’ AND SURVEY_METHOD = ‘LaserScanning’AND BBOX (the_geom, TLX, TLY, BRX, BRY)
	  

Where TLX and TLY are the top left coordinates of the bounding box of area we are interested in while BRX and BRY are the bottom right coordinates of the bounding box. Similar queries can be formulated also for temporal constraints and by using different logic operators.

The possibility of performing semantic queries allows giving back unexpected relationships among different vaults with regional dissemination, thus contributing to increasing knowledge and rising awareness on the vault constructions across Europe. For example, in the case of mixed arched-vaulted systems, the “frame vaults” [58], it was possible to observe some connection between the distribution of those system in Northern Italy (mainly Lombardy and Piedmont) and in the area of Prague (Czech Republic). Currently few examples are present in the vaulted system DB. However, it is expected that a larger number of samples will allow giving back a pan-European picture with unexpected correlations of traditions, permanencies and mutation across space/time, the skilled workers capabilities across Europe, their movements, enriching the socioeconomic framework of the different periods.

7. Conclusions and Remarks

HBIM modelling involves collaboration among several experts in different domains and continuous exchange of information among participants and addition of new information. Semantic web technology can be fruitfully used to improve information exchange efficiency among various actors. Indeed, semantic web technology uses a graph data structure for information modeling facilitating the integration of different types of information. In addition, since this technology is specifically designed for the Web, the obtained knowledge can be easily distributed over the Internet. A key role in this workflow is played by ontology that defines the organization of the data. ifcOWL is an IFC-based ontology that consists of all concepts included in the IFC library. Extending a single ontology such as ifcOWL to include all concepts and relationships in all AEC-FM domains is not easy and may not even be practical. This is especially true in the case of HBIM, where the building itself is part of the cultural heritage, with its tangible and intangible values. It is on the edge between different expertise and disciplines that are focused on specific and diverse aspects of it. Instead of developing a unique ontology, independent domain ontologies may be developed and used for information sharing built on the top of a “foundation” ontology. The role of this “foundation” ontology is to give a general and common view of the building among the different actors acting like a mediator to domain specific ontologies.

In particular, this work has focused on two specific domains of HBIM modelling: the characterization of vaulted system and the as-built survey stage. For those two fields, domain specific ontologies have been built. The architecture here developed was tested and adapted on the base of the richness of the documented vaulted systems. Being the methodology followed to its definition a bottom-up process, the database implements the elements for the main typologies of vault elements, including components, arrangements, properties and a new provisional taxonomy detailing the construction technologies and their related effects on the geometry. It allows to inherit the richness coming from the HBIM high level of detail and to connect the different DB information across time and space with possibility of semantic queries giving back unexpected relationship among different vaults with regional dissemination, thus contributing to increasing knowledge and rising awareness on the vault construction across Europe. The contribution is twofold: from the practical point of view, it makes available to architects/engineers a database of vaults with geometrical and historical data and material/construction techniques and structural/decay analysis that can be used for vaults structural assessment or restoration process. On the other hand, from an historical perspective, it makes available to researchers a collection of vaults related information, i.e., the work of the family of architects, enabling scholars to make cross-sectorial studies.

Currently few examples are populating the developed vaulted system knowledge base. For this reason, the main step, planned for the next years, is to develop a crowdsourcing platform updatable by different authors: experts, historians, architects, archaeologists, linguists, and surveyors. Vault vocabulary implementation needs to be done. Starting from reliable existing vocabulary, i.e., Art & Architecture Thesaurus^® Online (Getty Research Institute), vaults taxonomy could be implemented through the rich terminology gathered from the case studied in the DB (i.e., the hybrid vault typologies, such as the term “frame vaults”, which means the mixed arched-vaulted systems).