Applying Ontology Engineering to build a Poetry Domain Ontology.

The paper presents and describes an ontology modelling the domain of poetry. The presented ontology imports / reuses the FRBRoo and CIDOC-CRM ontologies. The ontology has been designed in a modular way. The ontology comprises of the following modules: Ontopoetry Cor, Ontopoetry Transmission module, Ontopoetry Poetic Analysis Module.

The paper focuses on the description of the Ontopoetry Module. In terms of methodology, the ontology has been designed following the NeOn methodology, focusing in particular on Scenario Six.

Overall, I have the following concerns with the ontology and its description:

1) The motivation for the design of the ontology is questionable. The design of the ontology is motivated by the desire to overcome the "idiosyncrasies" inherent in the field of literature, poetry in particular. The fact that in the special case of poetry there is "no uniform academic approach" is seen as a problem to "solve" or "overcome". The "uncoordinated evolution" that yields different terminologies is presented as problematic. I find this line of argumentation quite reductionistic, suffering from "solutionism". I agree that the field of literature and poetry would profit from an ontology allowing for a more unified approach to analyzing data, but I find the motivation truly problematic. It is a characteristic of literature and humanities research that it follows a "discursive" method in which new terms or concepts are introduced are proposed as a way to introduce new perspectives into the scientific discourse. So the "idiosyncrasies" that the authors talk about are actually an important aspect of humanities research. There is typically no "standard" way to analyze and interpret literary and poetic works. Having said that, this is not to criticize the work in itself, but the way it is framed. If we as Semantic Web community want the relevant communities to adopt our proposed models, we should be more careful in the way we "pitch" and "frame" them. I would like the authors to rethink the way they are motivating the work on the ontology and be a bit more "nuanced" and being more sensitive to the way other disciplines perform research.

2) There are no specific use cases or competency questions presented and discussed in the paper that would have guided the design of the ontology. As such, it is difficult to judge whether the ontology as it has been designed satisfies its purpose and requirements. There is also no evaluation of the ontology in the paper. I find this very weak as it is impossible to judge whether the designed ontology is "fit for purpose".

3) The ontology designed is quite "shallow" in the sense that in most cases it introduces a relatively "thin layer" on top of CIDOC-CRM and FRBRoo ontologies. The proposed ontology consists of a number of equivalence axioms that establish equivalence axioms between newly introduced concepts and existing concepts in the FRBRoo ontology. Many other axioms are subproperty or subclass axioms that introduce subproperties and subclasses to classes from FRBRoo. The ontology thus introduces very few genuine own ontological "content". The design of the ontology thus appears quite "trivial". This together with the fact that there is no evaluation allowing to judge the adequacy of the ontology makes the contribution of the paper quite "thin".

4) There are quite some questionable ontological design decisions made in the paper. For example "pdc:PoeticWork" is modelled as being equivalent to "frb:IndividualWork". Ontologically, this can not be correct as it implies that every IndividualWork is a PoeticWork, a choice that is surprising and not justified in the paper.

Given these fundamental criticisms, I can not recommend accepting this paper.

The submitted work details an evolved version of the POSTDATA/OntoPoetry ontology developed in the POSTDATA project, deriving from the CIDOC-CRM and FRBRoo ontologies. The submission describes the need for such an ontology in the philology/literature research fields, describes the process by which the ontology was developed, and the ontology itself.

The introductory motivation for the work is its strongest point. Unfortunately, the remainder of the submission is not as strong. In the end, I cannot recommend this submission for publication, as I consider its flaws meriting at least a major revision. Given that this is a resubmission, per SWJ standards, I therefore recommend that the submission be rejected.

My complaints relate both to the ontology itself, and to the article submission describing it.

Article issues:

1. The article is too long for its category. Per the author instructions, "Descriptions of ontologies" should be "short papers" and "brief and pointed". This article submission is 23 pages long, much of which is devoted to detailed ontology concept/relationship listings.
2. Per those same author instructions, this category of submission should "indicat[e] the design principles, methodologies applied at creation, comparison with other ontologies on the same topic, and pointers to existing applications or use-case experiments".
2a. This submission is very limited in terms of comparison with other ontologies -- there is some related work mentioned, but hardly enough for the reader to place the work in a context; and several of those related works are merely listed, rather than properly compared against.
2b. There is no indication of existing applications or use-case experiments using this ontology.
3. The submission deviates from SWJ formatting, viz., header styles, tables that are not really tables, etc. Figures are as small as to be unreadable in print.
4. The text lacks narrative quality; it follows what must be the authors' design/thinking process, but for the reader who was not involved in the project in question to follow those processes, it is much too unstructured. E.g., Section 3, lists four layers of the FRBRoo model in flowery natural language, lacking exemplification or concise definitions; it would much benefit from, e.g., a bullet list clarifying exactly what characterizes each such layer. In the same Section, POSTDATA Core and Transmission are discussed at some length, but the Poetic Analysis module barely touched on. This is but one example, but much of the submission follows a similar style of writing with similar lack of structure and language precision. It becomes particularly troubling in the long listings of classes and relationships that make up Section 5. It's simply not very readable.

Ontology issues:

5. The GitHub repository structure is unclear and a mix of ontology (of different versions), documentation, and large PDFs with what seems to be scanned documents. Cloning it for evaluation takes 50+ megabytes, a bit excessive for a single ontology.
6. Opening the ontologies in Protégé gives the user next to no discernible structure of the ontology as a whole; it seems to consist mostly of sub- and equivalence class assertions linking features of OntoPoetry/POSTDDATA to those reused ontologies. If they are not loaded, what we get is a disjointed list of concepts. This design may be OK from a purely logical point-of-view, but it is not particularly user-friendly.
7. The extensive use of equivalence axioms also makes this reviewer wonder as to what is the authors' contribution vs the contribution of those upstream ontologies. For my part, I would have put such alignment axioms in an optional loadable file, such that the own contribution and design intent be clearer.
8. Due to the aforementioned issues I have not carried out an in-depth review of all classes and relationships, but I did note at least one oddity: the naming of the class "Redaction". This seems a poor term for the intended concept. It may be specific to the literature studies/philology domain, but outside of that domain it carries a much more common meaning than the one seemingly intended here. As ontologies are about reducing ambiguity, I would urge the authors to reconsider its use.

Minor things:
• It is narratively unclear if the resulting ontology is called "OntoPoetry" or "POSTDATA 2.0". Both OntoPoetry and POSTDATA appears in text and figures. Which is it?
• The last paragraph of the introduction introduces the structure of the submission, but in the wrong order (3 and 4 are flipped vs what actually follows).
• Illustrations use the same arrow glyphs and styling for subclassing, equivalence, typing, relationship domain/range and relationship instances. It would improve ease-of-reading and reduce guesswork if more specific graphics could be used for these different arrows.
• Figure 17 uses (I believe) incorrect glyphs for pdc:Definitely_Not, and refers to a class pdc:Creator which is not in the OWL sources.