Introducing the HERACLES Ontology—Semantics for Cultural Heritage Management

Round 1

Reviewer 1 Report

The HERACLES ontology is well presented. However, the methodology of designing the ontology is too short to explain and support the result (ontology). The related work and discussion sections are too weak.

Author Response

Point 1 :

The HERACLES ontology is well presented. However, the methodology of designing the ontology is too short to explain and support the result (ontology).

Added approach of Grüninger and Fox to show what methodology guided the development and how the idea of applying competency questions arose.

Point 2:

The related work and discussion sections are too weak.

Specified, why CIDOC-CRM is a heavyweight ontology and why it is not reasonable, to use an ontology this complex for our project. CIDOC-CRM was enhanced by Acierno for built cultural heritage. We value the approach and point out it was not available, when we started using the ontology.

Reviewer 2 Report

The paper discusses the design and development of the EU project HERACLES ontology, aimed at providing a semantic layer on cultural heritage management data. The project requirements leading to the definition of the ontology are discussed, particularly those relating to the preservation of cultural heritage in the context of climate change. A basic discussion on related work highlights some of the reasons behind the choice of developing a new cultural heritage ontology whereas the design method is discussed in section 3.  The main body of the paper presents the core elements of the ontology and the paper concludes with a brief and limited paper discussion section.

Section 2 fails to acknowledge the range of projects and relevant research using CIDOC-CRM for accommodating the semantics of conservation data. The discussion of related work is somehow superficial and oversimplifies research facts. CIDOC-CRM does address conservation and the model clearly can accommodate subtyping of materials, through interfacing with thesauri (skosification). I suggest the authors to review CRMsci, the CIDOC-CRM extension for Scientific Observation and also to review the following papers in order to obtain a better view on the use of CIDOC-CRM in conservation, and how can it be extended to address particular domain problems.

Niang, C., Marinica, C., Leboucher, É., Bouiller, L. and Capderou, C., 2015, September. An ontological model for conservation-restoration of cultural objects. In Digital Heritage, 2015 (Vol. 2, pp. 157-160). IEEE.

Velios, A. (2016) ‘Beyond Databases: Linked Open Data for Bookbinding

Descriptions’, in Engel, P. et al. (eds) Historical book binding

techniques in conservation. Horn: Verlag Berger, pp. 173–194.

http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.2.5%CE%91%CE%9Ab-AV.pdf

http://www.cidoc-crm.org/sites/default/files/2017_10_10.pptx

The paper should make clearer the case for designing and developing a new cultural heritage ontology, in order to better justify the need for such contribution. Obviously, not every single CH project should adopt CIDOC-CRM but at the same there is no need to reinvent the wheel. Many of the proposed semantics of HERACLES ontology are already specified in CIDOC. For example, in the case of Acierno et al.  2017 (ref [9] on paper) many CIDOC declarations have been integrated in the model which though have been adapted to the proposed framework matching the logic structure of the conservation process. It would have been more appropriate to focus on the semantic areas which are particular to HERACLES project such are Risk, Damage, CH Value, and Vulnerability and less on introducing semantics which are already standardised in the CH domain.

Section 3 presents the design choices which are driven by a bottom up approach which puts end-users at the centre of the process. It would useful to give some additional details of the expertise and background of end-users and the method in which their views and input informed the design process and the work of data/knowledge-base architects. In addition, it is important to give examples of the use-cases employed by the design process.  

The discussion about designing the HERACLES ontology should be elaborated in the context of ontology engineering and to take into account some of methodological approaches as discussed in the following papers;

Fernández-López M (1999) Overview of methodologies for building ontologies. In: Proceedings of the IJCAI-99 workshop on ontologies and problem-solving methods: lessons learned and future trend, Stockholm, Sweden, August 1999. http://oa.upm.es/5480/

Gómez-Pérez A, Fernández-López M, Corcho O (2003) Ontological engineering. Advanced information and knowledge processing series. Springer, Heidelberg, ISBN 1-85233-551-3

Corcho, O., Fernáandez-Lóopez, M. and Góomez-Péerez, A., 2003. Methodologies, tools and languages for building ontologies. Where is their meeting point?. Data & Knowledge Engineering, 46, pp.41-64.

Pinto, H.S. and Martins, J.P., 2004. Ontologies: How can they be built?. Knowledge and information systems, 6(4), pp.441-464.

Section 4 discusses the core elements of the ontology and provides several figures which illustrate the semantic arrangements of the model.  My comments below are based on reading the paper and reviewing the actual ontology (OWL file) in Protégé.  

The ontology should be improved to allow for a reliable representation of the targeted semantics.  In order to reduce information discrepancies and inconsistencies and to enable versatility and expendability, please consider the following;

Ontological entities usually reflect nouns in singular form. “Cultural Heritage” is a vague labelling for an ontological entity. I can understand the label is used for capturing both tangible and intangible pieces of CH. In this case, what is referred as “Cultural Heritage” is most likely a “Cultural Heritage” Thing or an Item which can be tangible and intangible. The Ontology must clarify the distinction between the Asset class (CuturalHeritage subclass) and the class Cultural Heritage Element. It seems that these two classes refer to the same thing, is “Asset” a “type” of a Cultural Heritage Element? or is Cultural Heritage Element a subclass of “Asset”? Why to explicitly define Building – Monument – Wall, are all these types of Cultural Heritage Element, why a Building cannot be a Monument and why Wall is a sibling of Building when clearly a wall is part of a building, What the ontology refers to Monuments (according to the entity note i.e. “A structure or building that is built to honour a special person or event”) is clearly a Memorial.  All the above describe a weak specification of ontological entities which should be addressed.

Use of a proper hierarchical structure of properties can improve the semantic specificity of the model. For example, the property “hasChProperty” is used extensively in the model, having Domain “CulturalHeritage” and Range “CulturalHeritageProperty”. Instead hasMaterialProperty, hasEconomicProperty, hasMechanicalProperty could have defined as sub-properties of the “hasChProperty” to provide better semantic definition and scope.

See also my comment in connection to the use of E55 Type in CIDOC-CRM and the way different types such Effect Type, Damage Type, Action Type are defined in HERACLES ontology. The approach of introducing a new type (as an ontological class), every time a type is required, overloads the ontology with classes of very similar scope.

The semantics of “Location” are very weakly identified. It is not possible to know how several Location instances of Sensors which are used in a sampling activity, relate the Location of the Cultural Heritage Element in which the sampling activity has occurred. This can be really problematic since the aim of the ontology is to support a heavily sampling and measurement activity.  Either all Sensors and the Cultural Heritage Element that participate to the sampling activity share the same Location reference, which I cannot see how useful this can be, since it does allow distinction between location of different sensors. Or each sensor has a unique Location which though (according to the HERACLES ontology) cannot be correlated to the Location of the Cultural Heritage Element.

Section 5, Discussion is very brief and does not provide a clear insight on the use of the ontology in a real use case. The section should be extended to include discussion about how the inference and semantic capacity of the HERACLES ontology is evaluated against project-related use case scenarios and what are the achievements and limitations.

OVERALL,

The paper presents a significant effort in the design and development of particular application ontology in connection to the HERACLES project. The paper should be improved to a) make a clear case as to why the proposed semantics are required and why the existing domain standard ontology CIDOC-CRM is not extended to accommodate the specific ontological requirements of the project, b) to connect the method of designing a new ontology to the context of ontology engineering, c) to evaluate the value of the proposed ontology to support the project by employing clearly defined use cases. It is not necessary to re-design the ontology to meet any of the above, what is important is to clearly state that this a project specific ontology which has been designed with certain use cases in mind and has been evaluated against such use cases. Claims about the generalisability qualities of HERACLES ontology cannot be made without a major re-design of the ontology.     

MINOR TYPOS

Page 4 The following chapter (there are no chapters, only sections)

Page 4 The class pictures … (images, illustrations , figures?)

Page 4 Through  

Author Response

First of all, thank you for a thoroughly and valuable review!

a) make a clear case as to why the proposed semantics are required and why the existing domain standard ontology CIDOC-CRM is not extended to accommodate the specific ontological requirements of the project,

We try to make clear, that the semantics were developed through the workshop and enable the ontology to answer the developed competency questions. More CQs are introduced in the text.

We argue that CIDOC-CRM is far too complex for our use cases and that its main application areas are exhibition objects in musuems, not free-standing built heritage, that is exposed to the effects of climate and climate change.

b) to connect the method of designing a new ontology to the context of ontology engineering

We introduce the methodology of Grüninger and Fox and reason, why we chose to apply competency questions, to develop the ontology. Further, more competency are introduced.

c) to evaluate the value of the proposed ontology to support the project by employing clearly defined use cases. It is not necessary to re-design the ontology to meet any of the above, what is important is to clearly state that this a project specific ontology which has been designed with certain use cases in mind and has been evaluated against such use cases. Claims about the generalisability qualities of HERACLES ontology cannot be made without a major re-design of the ontology.    

The Competency Questions are closest to use-cases what  we have now. Four scenaria are in developtment, against which the ontology shall be tested against. We tried to point out more precisely, that we developed a lightweight ontology .

Round 2

Reviewer 1 Report

N/A

Author Response

precised the ontology classication

Reviewer 2 Report

The paper has been improved and addressed most of my comments in connection to methodological approaches and design choices. However, there is something that  needs your attention. The HERACLES ontology contains 105 classes and  208 Object properties which describe a complex domain,  far beyond a simple hierarchical classification of concepts and a backbone taxonomy of  "is-a"  relationships between parent and child classes, which is what a lightweight ontology is mostly  about. I suggest you consider redefining HERACLES as an Application Ontology , rather as a lightweight ontology. Saying that the HERACLES ontology is a lightweight ontology contradicts with all the rich semantic relationships you are describing in the various figures of the paper.

Author Response