VALIDATION OF THE BCH-ONTOLOGY

In the heritage domain, capturing facts and knowledge for preventive conservation of Built Cultural Heritage (BCH) requires access to a large variety of data. It is a multidisciplinary activity and uses heterogeneous terminologies. In this regard, the BCH-ontology has been developed to facilitate integration and exchange of heterogeneous built cultural heritage information. The BCH-ontology reuses three already developed ontologies: Geneva City Geographic Markup Language (Geneva CityGML), Monument Damage ontology (Mondis), and CIDOC Conceptual Reference Model (CIDOC-CRM). Additionally, it provides a complete semantic framework by defining some classes and properties for improving BCH management. This paper presents the validation of the BCH-ontology ontological model to determine whether the ontology is able to represent BCH data under a preventive conservation approach. The San Luis seminary is a historical building built in the late XIX century in Cuenca-Ecuador and it is employed as use case. This validation allowed the identification of further use cases where the ontology offers a potential additional value in the BCH-domain.


Built cultural heritage domain
Built Cultural Heritage (BCH) is characterized by a plethora of heterogeneous information that is gathered by several stakeholders. International charters such us the Athens (ICOMOS, 1931), Venice (ICOMOS, 1964), and Burra (ICOMOS, 2003) charters recommend applying a preventive conservation approach for BCH-management.
Preventive conservation of BCH suggests conservation actions considering not only the assessment of state but also periodic assessments of risks and threats. Thus, there is a necessity to integrate and share this information (Hart, 2008). The following section explores some initiatives designed to facilitate this necessity.

Preventive conservation approach
The preventive conservation approach for managing BCH demands a cyclical and systemic process of conservation actions. It goes beyond the assessment of state of conservation to include periodic assessments of risks and threats. It is meant to facilitate early damage detection by addressing first the deterioration causes so that intervention can be kept to a minimum (Forster, Kayan, 2009).
According to the ICOMOS Charter -Principles for the Analysis, Conservation and Structural Restoration of Architectural Heritage- (ICOMOS, 2013), the preventive conservation approach comprises four main steps: analysis, diagnosis, therapy and control.
The analysis searches for substantial information and data; the diagnosis aims identify the individual damage and causes; the therapy defines remedial measures; and, finally, the control step checks the efficiency of the measures adopted (Van Balen, 2013). * Corresponding author

Related work
Some ontologies and data models were created to support cultural heritage data integration and exchange. An ontology consists of a hierarchical finite list of terms and the relationships between these terms, creating a conceptual model for a specific domain. Axioms are used to represent the relationships between the terms and to add a logical layer to the conceptual model (Antoniou, Van Harmelen, 2004).As an example, the following figure shows a fragment of the Monument Damage ontology (MONDIS) (Cacciotti et al., 2013). An ontology that records damages in historical buildings. This fragment shows an object change as a subtype of an event, in turn structural changes, manifestation of damages and intervention are subtypes of object changes. A manifestation of damage is repaired by an intervention which prevents another event. Components have materials which may have a manifestation of damages.  (Cacciotti et al., 2013).
CIDOC-CRM is the most popular ontology in the cultural heritage domain. It was created by the International Committee for Documentation (CIDOC) of the International Council of Museums (ICOM) (ICOM, 2015). The scope of this ontology is limited to scientific documentation of heterogeneous museum collections and the integration of this documentation in libraries and archives. Heras et. al. (2013) developed a CityGML-ADE model through several interviews and workshops with BCH-managers. The model is based on the building module from the CityGML standard (Kolbe, 2009) which enables a 3D representation of buildings and their components.
The preventive conservation approach is integrated in the model allowing identification of buildings' heritage values, condition and risks. The City-ADE model was implemented using traditional data base management systems. Zalamea et. al. (2018) present an ontology called BCHontology developed to facilitate interoperability of built cultural heritage information. BCH-ontology merges and expands 3 other ontologies: CIDOC Conceptual Reference Model (CIDOC-CRM) (Doerr, 2009), Geneva City Geographic Markup Language (Geneva-CityGML) (Kolbe, 2009), and Monument Damage ontology (MONDIS) (Cacciotti et al., 2013). The BCH-ontology is based on the CityGML-ADE model developed by Heras et. al.
The BCH-ontology was selected since it is a more complete proposal. An assessment of the response of the user requirements in the BCH domain is presented in this paper. Chapter 2 shows a short description of BCH-ontology and the methodology used for its assessment. Chapter 3 presents the user assessment of the BCH-ontology. Chapter 4 presents the discussion regarding to lessons learned with the ontology validation and the added value of using ontological approaches. Finally, the conclusion is presented in chapter 5.

Ontology evaluation
According to Gómez-Pérez et al. (1995) ontology evaluation comprises ontology verification and validation. Ontology verification measures correctness, answering the question: Is the ontology built correctly?, while ontology validation measures quality, looking at how good the ontology models reality, answering whether the correct ontology was built.
The BCH-ontology models the BCH domain under an approach of preventive conservation. To this end, validation is made through use cases where some samples of the preventive conservation approach (PCA) are tested.

BCH-ontology
The BCH-ontology is a tool created to support the exchange and integration of BCH-data under a preventive conservation approach. In this section we describe its background, the study area where it was applied and the its data model.

BCH-ontology background:
The BCH-ontology was constructed using the city of Cuenca as case of study. It is a World Heritage City designated by UNESCO in 1999 and located in Ecuador, South America. As part of the efforts for improving managing of the built cultural heritage of this location, a Preventive Conservation Approach (PCA) has been fostered.
CityGML-ADE model developed by Heras et. al. has already determined the key elements for preventive conservation: the elements to be monitored and actors to be involved in the process. The BCH-ontology represents this information.

Figure 2. Phases and information of the cycle of Preventive
Conservation Approach (Heras et al., 2013).
The BCH-ontology is constructed utilizing 3 already developed ontologies which complement each other to fully cover the BCHdomain shown in Figure 2.
Firstly, the CIDOC-CRM is an ontology created by the International Committee for Documentation (CIDOC) of the International Council of Museums. Its scope is limited to the management of museum collections and libraries. It has been selected as the foundation for the construction of the BCHontology because of its high reputation, understandability, and popularity.
Secondly, the CityGML ontology developed by the University of Geneva in 2012 is an ontological version of the CityGML standard developed by the Open Geospatial Consortium (OGC). It allows 3D representation of buildings and their environment. This ontology was chosen since it corresponds with the reality of BCH-data which includes multi-scale and multi-resolution data. BCH is managed at several geographic scales: city level, zones or sectors, sites, buildings, among others. These geographic scales are represented by models with multiple resolutions. CityGML has different levels of detail (LoD), thus multi-scale and multi-resolution are well represented with this standard.
Finally, the Monument Damage Ontology was developed in 2011 by the Czech Republic University in the framework of the MONDIS research project which was supported by the Ministry of Culture of the Czech Republic. MONDIS includes classes for risk assessment. This was the only ontology found for risk assessment in the cultural field. Several applications, such as terminology editors, matrix of knowledge, mondis explorer, among others were developed in test mode to show the ontology utility. With these tools the relationships between the ontology elements are shown.
After its construction, the BCH-ontology was verified using the OntOlogy Pitfall Scanner (Poveda-Villalón et al., 2012), a web tool developed by the Ontology Engineer Group at Polytechnic University of Madrid. The tool is used to detect ontologies anomalies; it supports developers to automatically detect potential errors, improving ontology quality.
The tool was selected since it is easy to use, free of charge, available online and very consistent regarding the type of pitfall it can detect.
OOPS detected the following minor pitfalls: Missing annotations, missing inverse relationships, missing domain or range in properties, and using different naming criteria in the ontology.
In this regard, labels and comments were added for all the classes; inverse properties, domain and ranges were defined for all classes and properties. A name convention was established which is explained in the following section.

BCH-ontology model:
The BCH-ontology follows a naming convention based on the CIDOC-CRM naming convention in order to homologate names of classes and properties. The CIDOC-CRM identification codes for classes start with the prefix 'E' which stands for 'entity', followed by a sequential number and the name of the class (ICOM, 2015). CIDOC-CRM properties use the prefix 'P'. For the Geneva-CityGML ontology, prefixes 'G' and 'PG' are used to represent classes and properties. MONDIS classes use prefixes 'M' and 'PM'. For new classes, we use the prefix 'HB' since the extension is specific for 'historical buildings', while for properties, we use the prefix 'PHB'. Each word of the class's name is followed by a blank space and starts with upper case, except prepositions. Properties are written with lower case.
The final ontology comprises: 148 classes and 102 properties. Table 1 shows the main classes related to each phase of the preventive conservation approach.
Classes in table 1 will be explained through an example in the following chapter.

VALIDATION OF THE BCH-ONTOLOGY
One historical building from the city of Cuenca was chosen to test whether the BCH-ontology is able to represent the preventive conservation cycle information. The San Luis seminary is a historical building built in the late XIX century in Cuenca. The seminary has a vernacular style materialized by several architectural elements of highly recognized historical value. The seminary will be employed as use case to test the phases of the PCA. The main classes will be explained in detail for the analysis phase, the remaining phases will be explained in a more general manner. Table 2 shows the terminology used in the following diagrams:

Term Description
Class A class represents a category of items that share a number of common features. It is represented by a rectangle.
Instance A class or a property is instantiated when a value of the real world is assigned to it. For example 'Ecuador' is an instance of the class Place.

Property
Properties define relationships between two classes. For example, 'historical building has condition stable,' means that a particular historical building from the HBdomain has a state of conservation for example 'Stable.' Properties are represented by a black arrow pointing to the range.

Inheritance
Ontologies show the hierarchical relationship among its classes. This hierarchical representation is also known as inheritance which means the subclass inherits all the properties from the superclass. Inheritance is represented by a white arrow pointing to the superclass.

Analysis
First we have to give a reference name to the seminary which in this case will be: HBSanLuis. The seminary is a building which is represented in Table 1, line 4. For readability reasons the whole classification of components is not shown in Figure 4 but it can be found in Figure A1 in the appendix chapter. The seminary identifier is the cadastral code '0102035001000' (Table 3, line 2) and its address is 'Benigno Malo 9-49 y Bolivar' (Table 3, lines 2, 7-9). The address is represented by the reference name 'AddSanLuis.' Table 3, line 9 indicates that 'AddSanLuis' is an address. The seminary is composed of two facades (Table 3, lines 5, 6). The first one is identified by the reference name 'HB1F1' and the second one by 'HB1F2.' The facade 'HB1F1' is composed of 15 arches, 7 windows and 6 doors (  BCH-ontology also documents damages. Figure A2 shows the full list of damages classification. For the San Luis seminary a detachment in the facade was documented (Table 4, line 4). Damages are produced by some deterioration agent (Table 4, line 23) such as: Fire, Water, Climate, etc.
The link between the damage and the deterioration agent is shown in Table 4, lines 24-26.

Diagnosis
A performance status is computed as a result of the diagnosis phase. Condition, risk and gravity are used to compute the performance status.
For the San Luis seminary, the condition is set as a qualitative value 'Stable' (Table 5, lines 1-3) however it can also be set as a quantitative value (Table 5, lines 10-13) or according to a list of parameters ( Figure A3.) A gravity value ( Risk is computed taking into account hazards and vulnerability. With a 'low' vulnerability and a 'medium' hazard, the general risk is evaluated as 'low.' Quantitative values can also be assigned (Table 5, lines 10-13).
Risk, gravity and performance status are linked to the heritage value through the HB41-HB47-HB35 assignment classes. Table  5, lines 14-16 shows the link for risk; the same process is applied for gravity and performance status.

Therapy
A therapy (Table 6, line 4-6) is set according the performance status value. The therapy consists of one suggested indirect action 'Special_plans_or_campaigns' (Table 6, lines 9-13) with a budget of 100 euros (Table 6, lines 20-23). Actions have a type (Table 6, lines 11, 14-16) which can be curative or preventive (direct, indirect). The status of the action (Table 6, lines 17-19) can be 'suggested action' or 'executed action.' After a therapy is suggested, an intervention (Table 6, lines 24-26) may be executed in which case the action changes its status. Figure 6. BCH-ontology therapy and control phases.  Table 6. Therapy phase of San Luis seminary.

Control
In the last phase the class intervention checks whether the conservation objective was reached after the intervention (Table  7, lines 1-4).  Table 7. Control phase of San Luis seminary.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIV-M-1-2020, 2020

Validation lessons learned
After validating the preventive conservation phases with the BCH-ontology we can conclude that the ontology is able to represent the information of each phase. However, some uncertainties and suggestions related to the documentation of the BCH-ontology arose.
First, there should be some guidelines for the selection of reference names. Some instances refer to features of a specific object like the facade of San Luis seminary 'HB1F1' while others are general instances that can be related to any object like the 'Form and design' aspect whose name in this example is HB26Aspect1. There is no specification of how the names should be established. The naming convention could be improved with some recommendations for the user.
The BCH-ontology classes and properties are well documented; nevertheless, its understandability and quality could be improved by including a user manual with examples of the actual ontology use.
The BCH-ontology provides an organized manner to store information, however it does not provides methodologies for risk assessment, intervention assignments, etc. The logic has to be implemented according to each methodology. Having the option to accommodate quantitative values, qualitative values and a parameters list is desirable, however it does not ensure that complex methodologies can be accommodated. Some examples of how to modify the ontology for other methodologies are also required.

Additional use cases
The main objective of this paper, validating the preventive conservation cycle, was achieved. However, other use cases are suggested to show the advantages of using ontological approaches.

Heterogeneous data integration:
Another important feature of the ontological approaches is that it supports data integration from heterogeneous data sets. In chapter 3.2, condition, risk, hazard and vulnerabilities can be set as quantitative values, qualitative values or as a result of several parameters. A use case where stakeholders integrate different risk assessment methodologies is suggested, it will be interesting to test how this integration is possible and what are its advantages.

3D representation of buildings:
3D feature models are becoming increasingly popular among BCH-managers since they provide interesting possibilities for visualization and analysis (Arízaga Guzmán, 2013). 3D model representation moving towards 3D analyses is the current trend.
In this regard, the inclusion of the CityGML standard into the BCH-ontology is an important asset which has not being tested yet.
Another needed use case should show the added value of having 3D models which go beyond visualization.

Ontologies additional advantages
An ontological model offers additional advantages:

Multilevel inheritance:
Ontological approaches implement the concept of inheritance in an efficient and practical manner. Superclasses properties can be used by the subclasses in any level without giving further specification. For example, 'P1 is identified by' is a property of the 'E1 CRM Entity' class which is the root class of the BCH-ontology; this property can be used by the remaining 147 classes of the ontology without having to define anything else.
In other data gathering systems such as databases, an inheritance has to be manually implemented. For example, if the BCHontology was implemented using a database and an identifier will be a property of every object, a column named 'identifier' must be added in each of the 148 tables.

Logical inferences:
The hierarchical structure of ontologies allows some basic inferences. For example: let's image we are integrating information from an external data set where there is not a definition of 'Heritage Building' and the information is just recorded as 'Building' and at some place information such as a component with heritage value is stored.
The ontology can establish a logical rule that states: "If a building or a component of it has a heritage value, then the building is a heritage building." When the information from the external data set is integrated into the ontology and the information regarding the component with the heritage value is found, the record is automatically classified as 'Heritage Building.' Other records of no-heritage buildings will be stored as well but only as simple buildings.
No additional efforts are needed to organize heritage buildings and simple buildings.
If a query is performed, the ontology can make the distinction between these objects and return 'all the buildings' or 'heritage buildings' automatically.
In other approaches, the same queries can be performed but it is the query builder who has to construct the query knowing where the information of building or heritage building is stored. The query builder needs to be well aware of the stored structure. The query builder is the one that knows the logical rule and implements queries according these logical rules while in an ontological approach the logical rule is stored in the same ontology. The query builder just needs to know that there are buildings and heritage buildings, not where or how they are stored.

No-populated ontologies have information:
Empty data gathering systems cannot answer any query. In traditional systems such as databases, the information is stored after creating a model. The model is just an empty container with no real use. An empty ontological model can offer plenty of important information. Figure A2, for example, shows that a damage classified as 'Biological colonization' is a damage in the material covering the component rather than in the component itself. It can also be known that if a damage is found in a component it will be: a deformation, displacement, rotation, failure or crack. Figure  3 shows that an action is related to a type, a status, a budget and resources.
All this information can be retrieved without having any data in the ontology.

CONCLUSION AND FUTURE WORK
In this research we found the BCH-ontology an appropriate tool for BCH-data exchange. The BCH-ontology proved to be able to implement the whole preventive conservation cycle as shown in Figure 1. Currently, it can be used as a structured glossary of terms.
Since CIDOC-CRM is the foundation of the BCH-ontology, there is guaranteed compatibility with other CRM systems, mainly but not exclusively those explored in section 5.1 (external datasets).
The BCH-ontology is a tool which provides additional values than representing thematic PCA data. It also supports data integration, however these aspects have not been tested in this paper. Future work will consist of the elaboration of more use cases such as those mentioned in chapter 4. Figure A1. BCH-ontology representation of components type. Figure A2. BCH-ontology representation of damages. Figure A3. BCH-ontology condition state and performance status representation.

APPENDIX
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIV-M-1-2020, 2020