Review Comment:
This ontology description paper introduces SQuAP-ONT, an ontology formalizing the authors' previously developed SQuAP model, which covers software quality, process quality, and architectural quality, within financial software (specifically on the Italian banking market).
An ontology description paper shall, per the SWJ reviewer guidelines, be reviewed per the following dimensions: (1) Quality and relevance of the described ontology (convincing evidence must be provided). (2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology.
-- Review Summary --
The quality of the SQuAP-ONT ontology itself is generally acceptable (with some room for improvement, see detailed comments below). However, the authors do not sufficiently motivate the relevance and impact of this resource in the article; there are also several ambiguities and some faults in the text that require fixing. This article could perhaps be acceptable for publication after a major revision. Note that since the article is only 10 pages long, there is some room for additional text describing those bits that are in the present version not sufficiently covered.
-- Detailed Review --
* I do not see sufficient potential for reuse of the developed ontology. This is essentially a formalized version of a pre-existing quality model, developed in a partly grounded manner from observations in the Italian banking sector (there are quality factors in the model that are explicitly local to Italy.). The explicit purpose of the ontology to support consultancy work in such a context. Reuse outside of that context is not addressed.
* Regarding the underlying SQuAP model on which this ontology is based, there are at least two major issues:
1) While the 28 quality factors have been validated by 124 domain experts, the article does not indicate that the mappings of these factors to the quality characteristics from the referenced ISO standards have been validated in the same manner. So there's arguably little empirical foundation for a large part of the relations in the ontology.
2) The article that describes the development of the SQuAP model's 28 quality factors, in fact, describe only 15 factors. Where the remaining 13 factors referenced int his paper come from is unclear.
* While the SQuAP model design/development process is described over several pages (partially repeating, e.g., 3rd paragraph 1st section and 1st paragraph 3rd section), the SQuAP-ONT design process and methodologies are glossed over in only one paragraph. This is unfortunate, especially as the method employed customizes the XD method with a (to my mind very reasonable) approach to pattern reuse.
* Related to the above, it would for instance be interesting to see a motivation for the use of design patterns in this case, where a basic model already exists to build from. The argument for using patterns and XD is typically that it simplifies and speeds up the development process of new ontologies. Arguably, adding the D&S pattern (which is somewhat abstract) can make the resulting ontology less useful for a practically-minded and applied software developer/engineer/manager; what is the rationale for using it here? Development speed? Quality of the result? Improved interoperability?
* There's some potentially very interesting discussion on the need for and consequences of punning on page 6. But this is glossed over rather quickly, which is a shame; punning such as done in this ontology is in my experience not done often, and if the authors have experience of use cases for this OWL 2 feature, and the consequences of employing it, I think that might be interesting for the community to read about.
* Relating to punning: why use both subclassing for specialization (on class level), _and_ the custom :specializes object property (on individual level)? Are both truly needed? And if so: this property should probably be transitive.
-- Formalities --
* The ontology is published at a w3id and loads in Protégé via content negotiation. However, the text/html-representation promised on page 7 (http://stlab.istc.cnr.it/squap/) results in an Internal Server Error.
* The authors claim on page 7 that the ontology uses the VOID vocabulary to describe license information. That is incorrect, at least for the presently published version, which uses dc:rights to provide a link to the license.
* Figure 2 color coding seems to indicate that :parametrizes is a local object property, when it is (I believe) in fact sourced from an ODP.
* The DL formalization in Section 4.2 is inconsistent with the schema diagram in Figure 2 and the published ontology (not only regarding the abbreviated classes). Also, Figure 2 is inconsistent with the published ontology (e.g., :hasMetric).
* Section 2, paragraph 2: the paragraph's last sentence is incomplete.
* Section 4.2: the first sentence is a tautology.
|