Ontology-based Thematic Framing of Tangible and Intangible Cultural Heritage

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 have extended and made corrections to the paper based on a round of reviews. Overall, my comments have been taken into consideration.

My specific comments:

(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 authors have added explanations of most of the individual RDF files in the README file.

The repository contains a file hermes_25_09.rdf, but this is not explained in the README file.

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

The authors have now published the source code of the system (REST API) on GitHub and the server as a container image on Docker Hub.

However, the GitHub repository and the Docker Hub page do not contain any documentation or instructions for running the application.

E.g. when trying to run the Docker image: docker run -it --rm pstlab/hermes_ai_server, it only starts bash, but the server itself doesn't seem to be started.

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

In addition to GitHub, Zenodo is used now.

(4) whether the provided data artifacts are complete.

In the GitHub repository, are the ontology v1.1 and example KG v1.1 files in sync? It seems the KG file has the ontology content included, and has e.g. the following datatype property which is not anymore in the ontology v1.1: hermes:hermes#accessibility

The Zenodo repository seems to contain ontology and KG version 1.0, wherease the GitHub repository has additionally v1.1.

My previous comment:
"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)?"

Authors' response:
"We thank the reviewer for the suggestion. We prepared a dedicated Docker image and revised
the GitHub repository of the ontology by also adding instructions to run the SPARQL endpoint."

- However, I am not able to see instructions for running the SPARQL endpoint on https://github.com/pstlab/HERMES_ONTOLOGY/blob/main/README.md.

Minor/language remarks:

- Footnote numbering: number 8 seems to be missing?

- Page 7: "Considering the required organization of ta territory" - Please reformulate.

- Page 8: "the concepts and relationships identified for the refinement of ArCo are summarized below. ." - Remove the other period (or similar).

- Page 13: "The figure, in particular, shows:" ... "the POI geographical location (latitude/longitude)" ... "accessible to ... the elderly" - I fail to see coordinates and elderly accessibility in the figure.

- Page 16: "without the clause, the query would return 66 individuals instead of the 5 shown below" - If I understand correctly, this refers to Table 5, which includes four, not five, individuals.

- Page 16, footnote 11: "The query took 0.1s for its execution on GraphDB" (and other similar footnotes) - Add a missing period.

- Table 10: Could you include column "?dt" as it's in the SPARQL SELECT clause?

- Table 11: Could you include column "?time" as it's in the SPARQL SELECT clause?

- Page 22: "What are the intangibles associated with at least one cultural entity?" - If I understand correctly, you are interested in associations between intangibles and tangibles? Should "cultural entity" be "tangible"?

- Page 23: "It is worth noticing the use of hermes:isCorrelatedWith* in conjunction with the pattern on the subject of the retrieved triples, rdfs:subClassOf*." (in two paragraphs) - 1) "hermes:isCorrelatedWith*" -> "hermes:isCorrelatedWith"; 2) The sentence is difficult to understand ("in conjunction with the pattern on the subject of the retrieved triples"), please reformulate.

- Page 24: "The HerMeS app is then deals" - Please reformulate.

My previous review highlighted the need for improved reproducibility and recommended long-term archival via DOI. The authors have responded to these requests with significant additions to the system architecture and documentation sections.

I think that the authors have significantly strengthened the manuscript. The addition of Docker support and detailed API documentation transforms the paper from a theoretical proposal into a reproducible contribution to the Digital Humanities and Semantic Web community. The unique integration of tangible and intangible assets through rigorous ontology engineering is high quality.

Nonetheless, I suggest the authors consider adding a Zenodo DOI for the final camera-ready version to ensure archival permanence.

This manuscript is a revised version of the paper that presented the ArCo-based HerMeS ontology, which implements relationships between tangible and intangible cultural heritage through the use case of cultural itinerary planning.

The original manuscript showcased good application potential and an interesting framing of the tangible/intangible apparent dichotomy in digital heritage. This was marred by a plethora of issues both in the presentation and in the guiding principles of its design: I was not confident that both orders of issues could be addressed in one single revision. However, I must acknowledge that the authors have been quite zealous in revising their manuscript to bring it closer to the expectation of the reader, whether they are an ontology designer or a digital humanist. I must also acknowledge the work done to address other problems raised by fellow reviewers, such as those of the GitHub repository.

The authors have put much greater care in framing the problem within the affordances--and limitations--of the UNESCO notion of intangible heritage. They have also done quite convincing work of reflecting on what role the competency questions had in their design (most likely the biggest problem the previous paper had). Since the issues I pointed out also dealt with ontology engineering itself, it is safe to assume these QCs, which have been aptly categorised, were now taken into account during the re-design process. This has some noticeable benefits on the side, which stand out in the Web API use case, e.g. the Boolean features (definitely a no-no in ontology design, but perfectly acceptable in the JSON output of an API as a synthesis of the underlying complexity).

Not every way the authors addressed my issues is one that I agree with. The insistence on limiting disjointness between sibling classes and on referring to the API as a REST one do not quite find me in agreement. This is largely the reason I'm not ruling for an as-is acceptance, however, I am prepared to see this discrepancy of views to be offered as a minority opinion.

The presentation has been greatly improved as requested, and the newly added text introduced only a few minor issues.

- On page 12, Figure 5 relates individual boxes, like Arte Musica, to classes like Art, through an unspecified "Object property" (continuous line), but how can that be any other than is-a (or rdf:type, as fit)? later on Page 14 (lins 35-35) it says they are subclasses. What is happening here? is there a form of punning in place?

- On Page 16, line 44 mentions 5 individuals being returned by CQ 1.1, but on Table 5 I only see four.

- On page 19, Listing 5 relates the ?poi to constants like hermes:const_hearing_imp_acc through an arbitrary property ?p. Why is it acceptable that this property is just any? It seems like a way of adding a flag to the model, whch brings us a little back to the issue with Booleans.

- Several footnotes mention the query execution time for CQs. Perhaps it would be useful to synthesise these as one short section devoted to performance considerations, where the setting is provided in some detail (OS, CPUs/GPUs, GraphDB engine, Dockerised or not) and performance is measured upon multiple runs. Not a huge issue for a small validation dataset anyway.

- Page 24 line 37: "The HerMeS app is then deals...": remove "is"