The ICOM 3.0 Intelligent Conceptual Modelling tool and methodology
This is a revised resubmission after an "accept pending minor revisions", which has now been accepted for publication. The reviews below are for the original submission.
Solicited review by Andreas Harth:
The paper presents a tool for modelling ontologies based on a UML-style class diagram metaphor.
The tool integrates complete logical reasoning support.
More than half of the paper discuss several example scenarios in which reasoning helps to amend the modelled artifact and uncover logical inconsistencies.
The paper should spend less space on describing example scenarios and more on fundamental properties of the system.
For example, the authors claim that the "ICOM interace supports ontology engineers in engineering ontologies that meets [sic] clear and measurable quality criteria", but fail to mention these criteria, and do not explain how these criteria are measured (I would guess the authors propose to use the number of logical inconsistencies as quality criteria).
Also, the authors should provide a clearer exposition of what they mean with "general entailment" (main points in the Introduction).
Again, my guess would be that ICOM adds handling of cardinality contraints, but maybe there is more.
Rather than mentioning scenarios, the paper should try to identify key points in a more principled manner.
A discussion of how the ICOM tool helps to address the two key points would be helpful.
I acknowledge that a formal evaluation is beyond the criteria set forth in the call, but the author should try to present anectodal evidence or at least a discussion.
I'd also be interested in how large the ontologies can be that graphical modelling still makes sense (10s of classes, 100s, 1000s?).
Similarly, can you provide a statement about the scalabilty of the reasoning procedure in face of 1000s of concepts.
Solicited review by Stijn Heymans:
Summary:
The paper describes the ICOM 3.0 tool for conceptual modeling of
UML-like languages with reasoning support via Description Logics to
help validate the models. The system is especially helpful for
validating integrated models (and support for the integration of
models is provided).
Comments:
The paper is well-written and communicates clearly what the system is
capable of by means of some well-chosen use case scenarios. The
angle of approach is extremely useful for modelers out there in the
real world vs the SW community. For example, in healthcare most
models (e.g., the HL7 RIM) are formulated in UML. There is however
interest in using SW technologics (i.e., DL reasoners) in lots of
healthcare applications.
Bridging this gap as the ICOM system is sure to make the threshold for
using SW technologies smaller than it is now.
A minor negative point is that I would like to see the following
things in the paper:
1- The authors write that one can import XMI (which is exactly what is
needed!); what does this mean exactly - in other words what of UML 2.0
could you for example not handle?
2- I would like to see a future work section; where do you want to go
with this system (you mention ORM)? Are there plans to tackle real
use cases?
Typos/English:
1- Section 2.1: "engineer in the creating" -> "engineer in creating"
2- Section 2.1: "mOrigin is a included" -> "mOrigin is included"
3- Section 2.2: "the ontology introduced the view" -> present tense
for introduce is more appropriate.
4- Section 3: In this section the quality of the English goes down,
please check:
4-1 "one or more UML class diagram" -> diagrams
4-2 "Isa" -> you wrote this before and after as IsA
4-3 "Upon their creation the system allocate" -> allocates
4-4 "speed identification" -> speed up
4-5 "exploiting its full capabilities require" -> requires
Solicited review by anonymous reviewer:
This paper presents ICOM, a conceptual modelling tool that allows users to design multiple EER or UML diagrams with inter- and intra-model constraints. The paper is clear and well written. The main part of the paper introduces the editor, its connection to a Description Logic reasoner and some example user scenarios.
Here are some minor comments:
- Given that OWL API is widely used these days for Description Logic reasoners, OWL API should be mentioned and comparisons between OWL API and DIG interface should be provided.
- The paper seems to regard EER and UML diagrams as ontologies, which is not widely agreed. The paper should justify why.
- The paper does not discuss any related work, such as those on using UML diagrams to model ontologies. This should be added should the paper be accepted.
- 16598 reads