Modular Ontology Modeling

Tracking #: 2806-4020

Cogan Shimizu
Karl Hammar
Pascal Hitzler

Responsible editor: 
Guest Editors ESWC 2020

Submission type: 
Full Paper
Reusing ontologies for new purposes, or adapting them to new use-cases, is frequently difficult. In our experiences, we have found this to be the case for several reasons: (i) differing representational granularity in ontologies and in use-cases, (ii) lacking conceptual clarity in potentially reusable ontologies, (iii) lack and difficulty of adherence to good modeling principles, and (iv) a lack of reuse emphasis and process support available in ontology engineering tooling. In order to address these concerns, we have developed the Modular Ontology Modeling (MOMo) methodology, and its supporting tooling infrastructure, CoModIDE (the \textit{Comprehensive Modular Ontology IDE} -- ``commodity''). MOMo builds on the established eXtreme Design methodology, and like it emphasizes modular development and design pattern reuse; but crucially adds the extensive use of graphical schema diagrams, and tooling that support them, as vehicles for knowledge elicitation from experts. In this paper, we present the MOMo workflow in detail, and describe several {\color{ForestGreen} useful resources for executing it. In particular, we} provide a thorough and rigorous evaluation of CoModIDE in its role of supporting the MOMo methodology's graphical modeling paradigm. We find that CoModIDE significantly improves approachability of such a paradigm, and that it displays a high usability.
Full PDF Version: 
Revised Version:
Previous Version: 

Minor Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Christoph Lange submitted on 30/Aug/2021
Review Comment:

The revised manuscript addresses all reviewers' concerns in a convincing way. A few minor linguistic mistakes remain. Please find them annotated at Other than that, I have one remark about the newly added scientific content: in Section 3.6.3, you argue that "ideally [the] workflow [of keeping track of requirements and their provenance, from use case descriptions through competency questions
through key notions and subsequently modules] is supported by integrated requirements management tooling that provides traceability of those requirements." What tool could play this role in the context of ontology engineering?

Review #2
Anonymous submitted on 06/Sep/2021
Minor Revision
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.

Review #3
Anonymous submitted on 06/Sep/2021
Review Comment:

I checked the revision of the paper wrt the remarks in my previous review. As a result I can state that the paper could be accepted and published after making the figures better readable. To my satisfaction, the authors constructively reacted to all my comments pointing to the flaws in the initial version.