Ontology-based Thematic Framing of Tangible and Intangible Cultural Heritage

This paper presents HerMeS, a well-conceived and original ontology-driven framework that integrates semantic reasoning with temporal AI planning to generate personalized cultural itineraries. By extending the ArCo ontology and grounding it in DOLCE, the authors introduce novel mechanisms for representing thematic relationships between tangible and intangible cultural properties. The use of a compositional framing approach, supported by taxonomic topics, sets this work apart from traditional CH modeling or recommendation systems.

The research is methodologically sound and supported by a real-world use case involving two historical districts in Rome. The integration of a REST API, dynamic knowledge retrieval, and planning components demonstrates the practical viability of the approach. The paper is clearly written, well-structured, and effectively illustrated with conceptual diagrams, tables, and examples.

The GitHub repository provided as a stable resource URL is appropriate, but it requires improvements to ensure reproducibility. While the ontology is thoroughly described, the repository should include a clear README file, sample data dumps, and deployment instructions for the reasoning services and planner integration. Archiving a versioned release on Zenodo with a DOI is also strongly encouraged to enhance long-term accessibility and citability.

Only minor revisions are needed before publication, primarily regarding the enhancement of documentation and packaging of data and code resources. The scientific content is solid and presents an important contribution to the domains of digital heritage, semantic web, and AI-based cultural tourism.

This work introduces HerMeS, an ontology based on ArCo and foundational models, which aims at modelling the relationship between material artifacts and intangible elements of cultural heritage, through a use case of cultural itinerary planning. It compounds the ontology with a dataset and a specification for a model-driven Web service infrastructure that implements the use case.

The paper itself is written in a style that is quite easy to follow and there are only a few issues with the writing (see later). Regarding the structure I have little to request, other than for section 4.2 to become a top-level section in and of itself, and that a section discussing the background/rationale/requirements/design decisions is sorely missing. The level of legibility, though, aso contributes to giving the impression of somewhat of a lack of focus in the narrative: there is a rather generic introductory paragraph about ontologies and cultural heritage, which does not pinpoint the problem at hand. It shows a focus on cultural itinerary construction, but it doesn't quite nail down how it perceives the tangible/intangible dichotomy, beyond what ArCo already offers and an underspecified "correlation" property.

The related work section, whilst sound, suffers from a similar issue, hovering over the theme of cultural heritage interfaces driven by semantic technologies, FAIR data publishing etc. but hardly focusing on comparable approaches and their shortcomings. One also struggles to understand what the authors are willing to consider as intangible heritage, sometimes seeming to embrace the UNESCO convention - which is however not spelled out -, sometimes suggesting through examples that it should be something more, such as when they hint about experience being a factor of ICH.

What I said about legibility applies to the text, but hardly to the figures and, to some extent, the listings. The text in most figures is almost impossible to read and, in general, the figures that seem to be generated by Protégé (e.g. 2, 3, and 9) are not laid out in a way that helps their legibility - they should develop vertically where possible. As for the code snippets: the JSON ones probably show more detail than what is strictly needed to appraise the reponse payloads (by the way, since we are in the semantic web realm, could JSON-LD be considered at all?); the SPARQL queries do not need to repeat the prefix mappings all the time: just state them once in one table and streamline the other snippets.

Now into specific issues with the presented approach:
- there are several Boolean properties: be *very* wary of using them, as they usually indicate parts of the design that are not quite thought-through. 99% of the times there are better ways to model them: for the accessibilty ones, perhaps it's enough to define intensional entities that represent groups visually-impaired, motor-disabled etc. and just use one property
- similarly for those properties that allow a string "FREE" for e.g. admission price and visitability: they can probably be modelled better by using classes or numeric literals in their range.
- Both issues above hint that a restriction rule system to strengthen the ontology could be useful, e.g. to state that AccessiblePOI is the class of all POIs for which certain axioms on the "accessiblility" property hold.
- In general, information such as accessibility, visiting hours and pricing is highly mutable and is probably not a great idea to attach it directly to the POI: perhaps it would be a good idea to reify a class that represents these visiting-related featuers and that has a validity over time.
- Usage of PROV-O: there are classes that subsume Person but denote roles: is this really necessary? Would it not be enough to instantiate the class Role that also exists PROV-O?

Onto what is illustrated as a REST API specification: perhaps it is more appropriate to call it Web API or HTTP-based API as it lacks some of the distinctive features that would make it RESTful, for instance:
- Uniform resource identification: I only see the URLs of endpoints, but when a resource is created, its data are returned but it is not clear if it becomes dereferenceable. For example, if I POST to the trip planner, I get a JSON which identifies it as, say, PLAN_0, but then I would expect to be able to access it at http://$REST_API_HOST:$REST_API_PORT/planner/trip/PLAN_0 and these references should be returned (HATEOAS)
- JSON data being passed to GET requests with the "Content-type" header: this is not great and, from the examples, I do not see why "uri" could not simply be passed as a query param
- The description of a specific model for the RESt API is confusing, unless that model is largely or entirely reflected in the available resource URIs.

The contribution has been evaluated though a series of competency questions. Now, we all know how long-standing the issue of ontology evaluation is, and what is there is definitely part of a sound evaluation, but the QCs should most of all be what sets the requirements for the ontology to be designed, which is missing in the paper: we don't meet them until the last part, and even then they do not seem to constitute an exhaustive set. They are all of the kind "Give me the POIs whose associated topic has these characteristics" plus a little more, but I don't see anything related to e.g. building a visit itinerary, which is largely discussed in the paper, or anything specifically querying for intangible heritage, which seems confined to a topical support of the tangible one. Even without bringing e.g. user studies into the fold, ontology evaluation should be more extensive, at least discussing logical consistency aspects (which will require more disjointness axioms, though).

The supplementary material includes an RDF/XML export of the ontology and of the dataset described in the paper.
The former shows a lightly axiomatised ontology, with only sporadic inline documentation (i.e. labels and comments) for some of its terms. The ontology has class and property hierarchies and no native equivalence/disjointness axioms: I would have expected the authors to discuss the rationale behind these design decisions, assuming they are design decisions (i.e. are you relying only on the inherited disjointness from, say, ArCo and if so why?) and, in any case, argument on the OWL profile chosen for this model.
The dataset also has a few quirks, including the RDF/XML serialisation (for a dataset one may want to use more scalable formats like NTriples or Turtle) and the fact that it redefines many entities that one may expect to find in authority files like GND, VIAF or the Getty thesauri, without any alignment of sorts, but if one takes it at face value for running CQ-queries upon it, I guess it may pass as a mere validation dataset.

Minor remarks:
- Sometimes "HerMeS" is stylised and sometimes it's just written as "Hermes": which one is correct?
- P2L33: "[...] has gained increasing attention" (remove 'an')
- P13L13: "semantic-based recommended system" -> "semantics-based recommender system"
- P14L33: "Tangibel" -> "Tangible"

While the work has undoubted potential, there are many points in its presentation that call for clarificaion or improvement to address the vagueness of its narrative and, since on top of that this work is admittedly preliminary, I would rather confide in seeing these changes applied to a more advanced state of the research, than go for revisions of this work which may soon be superseded by its own advancements. Regrettably, I am therefore not inclined to recommend this specific proposal.

This manuscript was submitted as 'full paper' and should be reviewed along the usual dimensions for research contributions which include (1) originality, (2) significance of the results, and (3) quality of writing. Please also assess the data file provided by the authors under “Long-term stable URL for resources”. In particular, assess (A) whether the data file is well organized and in particular contains a README file which makes it easy for you to assess the data, (B) whether the provided resources appear to be complete for replication of experiments, and if not, why, (C) whether the chosen repository, if it is not GitHub, Figshare or Zenodo, is appropriate for long-term repository discoverability, and (4) whether the provided data artifacts are complete. Please refer to the reviewer instructions and the FAQ for further information.

The authors present an ontology-based system for generating cultural itineraries based on user's preferences (topics, visiting time, accessibility requirements). The paper focuses on the ontology design, trip planner REST API, and evaluation of the ontological model and the "proof of concept" knowledge graph through competency questions.

(1) originality

There exists several ontologies on the cultural heritage domain, and ontology-based (tourist) route planner systems. The proposed HerMeS ontology is (partly) based on existing ontologies and is designed to support a compositional and thematic description of cultural entities and flexible correlation between tangible and intangible entities.

(2) significance of the results

The ontology seems to be fit for purpose for the specific tasks the authors have developed it for (based on the competency questions), and it could be useful for others working on similar aspects of cultural heritage. The ontology's core novelties lie in the modeling of the compositional relations and associations between tangible and intangible entities, and providing a topic classification for cultural entities for tourist itineraries. The work presents a focused example of an ontology-based recommendation system.

(3) quality of writing

In general, the text is easy to read and the structure is comprehensible. There are some minor language issues (see comments below), and proofreading would be needed.

The data file provided by the authors under "Long-term stable URL for resources": https://github.com/pstlab/HERMES_ONTOLOGY.git

(A) whether the data file is well organized and in particular contains a README file which makes it easy for you to assess the data

- The data file (repository) contains a README file, a LICENSE file, the HerMeS ontology (OWL) as an RDF file, and apparently a knowledge graph of cultural places from "Rione Esquilino" and "Rione Monti"(?) as an RDF file. The README file has a general description of the HerMeS ontology but does not explain what the individual RDF files in the repository are.

(B) whether the provided resources appear to be complete for replication of experiments, and if not, why

- Regarding the ontology and the knowledge graph, they appear to be complete. What I did not notice is the availability of the source code for the REST API and the full HerMeS system (Figure 10).

(C) whether the chosen repository, if it is not GitHub, Figshare or Zenodo, is appropriate for long-term repository discoverability

- GitHub is used.

(4) whether the provided data artifacts are complete.

- They appear to be complete.

Specific comments on needs for clarification and improvements:

Figure 2: Based on the figure, it is not clear which classes are from ArCo and which are part of HerMeS. What are the different relations (arcs of different colors) in the figure?

Some existing ontologies are used (ArCo, OntoPiA, ADMS-AP_IT, DC, PROV-O), but even more existing ones could be used for enhanced interoperability. For example, schema.org includes the property schema:openingHours which could be used (if applicable) instead of hermes:opening_hours (or mapped to it).

Use of object properties vs. datatype properties: some information is presented only as strings instead of using semantic concepts, e.g. regarding "visitability", it might make sense to represent "free admission" ("Ingresso libero") as an instance of "AdmissionType" class. That way the data would be easier to use, e.g. for finding out which cultural places are free, and would prevent inputting the same meaning (being "free") in different natural language expressions in the KG. Also, have you considered using a geographical gazetteer to represent the location of a cultural place? This would facilitate e.g. queries like "what cultural places (of certain topic) are in Rome".

You mention that the KG is exposed as a SPARQL endpoint - could this be made publicly available (I didn't notice a mention on this)?

Text in some of the figures is very small, making it difficult to read.

Regarding the REST API, is there an on-the-fly mapping to SPARQL, or how is the knowledge graph used when API requests are made?

A general note regarding SPARQL queries (e.g. concerning Listing 7): for efficiency, it is usually a good practice to have the most selective triple patterns first in the query, as SPARQL query engines might apply the triple patterns in order.

Competency questions: none of the competency questions include selecting POIs based on an area/territorial unit. Won't such a use case be relevant? I.e. the user is in location X - what are the nearby POIs?

Related work: the paper includes related work on cultural heritage ontologies and some on personalized cultural itinerary planning systems. Some further references could be added, e.g. the TravelSampo system:
- Project page: https://seco.cs.aalto.fi/applications/travelsampo/
- Publication: Eetu Mäkelä, Aleksi Lindblad, Jari Väätäinen, Rami Alatalo, Osma Suominen and Eero Hyvönen: Discovering Places of Interest through Direct and Indirect Associations in Heterogeneous Sources -- The TravelSampo System. Terra Cognita 2011: Foundations, Technologies and Applications of the Geospatial Web, CEUR Workshop Proceedings, Vol-798, 2011. https://ceur-ws.org/Vol-798/

Minor / language remarks:

- Page 3: "The work [27] proposes the Cultural Heritage Abstract Reference Model (CHARM) is a reference model to support the exploration and documentation of archaeological and anthropological entities." - Please reformulate.

- Page 6-7: "The process identified the following criteria as crucial for the proper characterization of cultural entities (generally referred to as Points of Interest - POIs)" - Cultural entity, as far as I understand, is a broader concept than a POI (page 14: "we distinguish three types of cultural entities: (i) Tangibel cultural entity; (ii) Intangible cultural entity, and; (iii) Residual cultural entity") and not all cultural entities have spatial dimension (e.g. intangible cultural entities don't have a physical location) -> This should be reformulated.

- Footnote 8 is a duplicate of footnote 7.

- Figure 4: Add a reference to the source of the figure.

- "ArCo" vs. "ArCO" vs. "ARCO" - Use consistent style.

- There is no explicit reference to Figure 7 and Figure 9(b) in the text.

- Page 13: "Tangibel" -> "Tangible"

- Page 13: "esntity" -> "entity"

- Page 15: "The application may show such contextual information would be shown in the detailed view of a particular POI (tangible entity) being visited during the path." - Please reformulate.

- Page 17: "The request body should contain an instance of TripRequest in JSON format (see Figure 11." -> "The request body should contain an instance of TripRequest in JSON format (see Figure 11)." (missing closing bracket)

- Listing 5: I would think that a shorter snippet of the JSON response would suffice here.

- Listing 11 and Listing 12: would it be possible to use a simple triple pattern:
Listing 11: ?d w3id:hasTopic hermes:TwentiethCentury .
Listing 12: ?d w3id:hasTopic hermes:Architettura_Neoclassica .
instead of the more complex set of multiple triple patterns and a FILTER?