Review Comment:
The paper “Modular Ontology Modeling” presents the Modular Ontology Modeling (MOMo) methodology on the one hand (as an abstract process or workflow) and the Comprehensive Modular Ontology IDE (CoModIDE) on the other. CoModIDE is a tool/implementation – realised as a Protégé plugin – that plays a crucial role when fully implementing the MOMo workflow in a concrete ontology development project. The MOMo workflow comprises the following ten steps: 1. Describe use cases and gather possible data sources; 2. Gather competency questions; 3. Identify key notions for the domain to be modelled; 4. Identify existing ontology design patterns to be used; 5. Create schema diagrams for modules; 6. Set up documentation and determine axioms for each module; 7. Create ontology schema diagram from the module schema diagrams; 8. Add axioms spanning more than one module; 9. Reflect on entity naming and all axioms; 10. Create OWL file(s).
This is a review of the revised version of the paper. Many of the remarks from the initial review have been taken into account. Having said that, below I’ll keep those comments not addressed by the authors in the revised version of their paper.
The following remark from my original review has not been addressed by the authors: On page 2 (lines 5-8) the authors claim: “using a fine-grained ontology for a use case that requires only coarse granularity data is unwieldy due to (possibly massively) increased size of ontology and data graph.” This is certainly true, but what about the simple solution of deleting the detailed bits and pieces from the existing ontology that are not needed in the new application scenario?
The following remark from my original review has not been addressed by the authors (except for changing “cooking recipe” to “cooking process recipe”): “Modules” are an essential concept in MOMo. On page 3 (left column, line 20) an example is mentioned: “cooking recipe”. Is this a good/representative example for such a module? Shouldn’t “ingredient” be the right module or perhaps “instruction”, maybe “prerequisite” – out of which “cooking recipe” is being constructed? Also, “cooking recipe” is conceptually very close to the well-known text type of the same name. This reviewer finds this example unnecessarily confusing. In addition, I’d like to suggest to provide some more examples, especially examples that contrast good modules with bad ontologies.
The following remark from my original review has not been addressed by the authors: The participants of the study were given the two schema diagrams shown in Figures 11 and 12 (Section 4.2.3)? These two schema diagrams explicitly mention several design patterns: Provenance, Event, Trajectory, ExplicitTyping. If we zoom into Figure 10 (the CoModIDE screenshot), these design patterns are actually listed in the tool itself while in standard Protégé they are obviously not listed. I don’t think it’s a big surprise that the participants could solve the task faster and more efficiently with CoModIDE (given that it explicitly lists, in the tool, the main building blocks shown in the hand-drawn figures) than with standard Protégé (which does not show these main building blocks). In other words, in one tool the needed building blocks are presented in a menu, ready to be used, in the other tool they aren’t. Unfortunately, this aspect is still not addressed in the evaluation of the revised paper but it obviously should and must be.
| 
