Review Comment:
The paper presents an ontology to support automated manipulation of objects in a 3D environment while taking advantage of virtual applications. The topic is relevant and fitting to the special issue.
Since the manuscript is a "full paper", it is reviewed along the following dimensions.
(1) originality
The authors have paid attention to the existing literature (even though some clusters of authors can be identified), but it's hard to appreciate the actual novel contributions.
The introduction is lacking focus and missing to provide key motivations for the proposed ontology, in particular from an industrial perspective.
The need for a new ontology for geometric description is not properly motivated because the problem has already been addressed in the literature. STEP is mentioned, but it's not clear to what extent it was used.
IFC (and its ontology version ifcOWL) covers most of what is discussed about geometry and topology. In addition, GeoSPARQL and Well-Known Text (WKT) are potentially relevant and should be assessed, since they provide also mechanisms for automatic calculations.
(2) significance of the results
It is not clear why the "automated extracted taxonomy of AP203 is meaningless as STEP standards...".
The specifications (Section 3) could be better developed, because much space is dedicated to a specific little example. Competency Questions should be better explained. It would be beneficial to specify also requirements, goals, constraints, etc. The initial part of Section 4 would probably better fit Section 3.
If more than one ontology is used, then the addition of prefixes would help to avoid ambiguity.
The authors are not addressing the problem of generating the large set of data that are needed to instantiate a 3D environment and run queries. Which would be a feasible workflow? Are you relying on CAD models? Point clouds?
Moreover, basic mathematical concepts (e.g., Vector3D, RotationMatrix3D, etc.) are defined in a verbose way that will pose challenges for the generation and querying of data.
The definition of Hole, Opening, and Container as context-dependent is quite surprising and not well motivated.
The presented simulation scenarios (Section 5.1) are very simple and have little relevance from an industrial perspective. In addition, the authors don't explain how the scenarios were instantiated, therefore it is assumed that this task was carried out manually, making it not scalable. Figures like Figg.11 and 15 are little informative and could be replaced by a table and complete online resources.
Which are alternative technologies that could help to answer the competency questions defined in Table 10 and Table 8? Which is the actual advantage of using SPARQL queries?
SPARQL queries in Figg. 14 and 18 are customized to the specific scenario. Instead, general purpose queries would be expected as reusable contributions, receiving as input only the URI of the solid body or place to be analyzed.
Overall, the paper is focused on the geometry and topology data, so it is difficult to appreciate the advantage of using an ontology to integrate also other knowledge domains, since the contextual part is only marginally addressed.
Also, the conclusions (Section 6) fail to highlight the significance of results. The added value of aligning the proposed ontology with a top-level ontology is not clear in the scope of the paper.
(3) quality of writing
The use of English must be improved with a proper proofreading. There are typos and sentences that need to be rephrased.
e.g., "to across" is not a verb (Table 1).
Table 8 is referenced in page 12, but it is not included nearby. There is a Table 8 in page 21, but its content is not consistent.
(A) The repository contains a README file, but it is basically empty, so the content is poorly documented.
(B) it is not possible to identify the implementation of the two simulation scenarios. Moreover, the repository doesn't include relevant SPARQL queries. Therefore, the provided resources don't help to replicate the experiments.
(C) The authors provided the link to a GitHub repository.
(4) The provided data artifacts are not complete, as commented above.
|