Write a comment

In this work, the authors introduce an ontology to map academic curricula and, thus, export them within a knowledge graph of scholarly information. The paper presents the most relevant part of the ontology, providing justification for each of the main concepts. The paper is indeed of interest to the journal and provides a relevant contribution. Yet, some passages need more justification and additional material to make the paper's content fully transparent. They are listed as follows.

# Major issues

1. The authors said that they used the MOMo methodology, which has been described in detail in a referenced paper. However, to keep the present article self-contained, it would be important to provide a brief overview of the methodology (possibly with a diagram) to help the reader align with how it is structured. While it may seem redundant, it would offer the reader a clear view of which steps the methodology is based on and which kinds of users it involves. This is also particularly sensitive to the other points highlighted below, since some lack of clarity may stem from an incomplete understanding of the methodology adopted.

2. The ontology has been developed in a particular use-case scenario, i.e. the Prototype Open Knowledge Network. Did the authors involve some existing users (e.g. domain experts) from the scenario itself so as to gather relevant information (e.g. competency questions)?

3. It seems that the new ontology either does not reuse or is not aligned with other existing ontologies defined in the past to address, at least partially, some of the concepts introduced in the Curriculum KG Ontology. SKOS and other ontologies that use it to define topics in a similar way the Curriculum KG Ontology propose (e.g. the FBRR-aligned Bibliographic Ontology from the SPAR Ontologies), or the Publishing Role Ontology (PRO, still from the SPAR Ontologies) for defining roles that people may have within specific temporal and situational contexts, just to make a few examples [disclosure: I am one of the authors of the SPAR Ontologies]. Thus, why did the authors decide to avoid such an alignment/reuse?

4. The ontology source is indeed available in the GitHub repository of the project. However, the ontology should be appropriately published and described in a way that meets the community's basic expectations, as outlined in the usual guidelines adopted by Semantic Web-related venues (e.g. https://iswc2025.semanticweb.org/#/calls/resource). In particular, considering the present context, it would be necessary that:

* the ontology is compared to other resources having, at least partially, a similar scope, such as the ontologies mentioned before;

* the ontology should be accompanied by high-quality documentation (e.g. in HTML form) to be easy to (re)use by others. In addition, tutorials on how to use the ontology to model data may help with the ontology understanding as well;

* since one of the goals for having this ontology is to obtain RDF data compliant with it, starting from CSV documents, the software used to support such a convention should provide appropriate documentation to allow another user to run it easily, or at least to reproduce the same results in the conversion addressed in the paper;

* the ontology should be FAIR compliant - e.g. the ontology should be registered in an appropriate registry (e.g. FAIRSharing) to improve its findability;

* the ontology (and the related contextual material) should be published at a persistent URI (e.g. w3id.org);

* the ontology should specify in its own metadata the license used to publish it (mentioning it in the GitHub repository of the ontology is not enough).

5. The evaluation (section 3.2) is based on showing that some competency questions collected (not clear when?) can be translated into SPARQL queries compliant with the Curriculum KG Ontology. However, if such competency questions are defined during ontology development, which is reasonable given that the MOMo methodology prescribes them in one of its steps, it would be odd if one of them is not translatable into SPARQL, given that these CQs are the basic requirements for building the ontology. The evaluation presented here is circular, since it seems we can use the CQs used to create the ontology to check its validity. I do not think that this circularity is a valid mechanism for convincing an independent observer that the ontology is robust.

In my experience, one of the best ways to provide robust clues about the robustness of an ontology is to be fully transparent about the methodology adopted, explicitly showing what the various materials produced as a result of the execution of the methodology steps are, which have led to the ontology as presented in the paper.

In addition, no evaluation is provided by automatic tools developed to assess at least an initial level of quality, such as OOPS! and FOOPS!

6. In Section 3, the authors present some information about the materialisation of the CurrKG via application scripts that translate CSV documents into RDF data compliant with the Curriculum KG Ontology. However, it is not clear how this process works from reading the paper. In particular, it would be important to clarify, at least:

* what is the shape (e.g. the columns and how the values in cells are organised) of the CSV tables used in input by the conversion process;

* how are these CSV data generated from – are the domain experts/users to populate them (if so, with which software), or is it something that the ontology experts must create from data retrieved in some way from, e.g., websites?

* what is the justification to develop a new script, which is by definition more difficult to adapt and reuse in other contexts, instead of existing tools already available within the community to facilitate similar kinds of conversions, such as RML;

* what are the proofs that justify the strong sentence "our materialization pipeline and script are adaptable in nature and are not hard-coded to a specific data format or schema". In particular, how can I configure the pipeline/script to be reused on a different input tabular format, for instance?

7. In the related work section, the majority of the work is done in analysing other KGs dedicated to similar contextual aspects of the CurrKG introduced in section 3. However, the main topic of this article is the ontology presented. Thus, I would have expected at least a functional comparison with other ontologies (as already suggested in one of the points above), which seems to have been totally missed.

# Minor issues

1. Do the questions introduced in Section 2 (page two, second column) come from the CQs collected through the domain experts?

2. Software should be cited appropriately by following the expected practices introduced by the community. In particular, the use of the documentation of a software is a proxy to the software itself and should be avoided when referencing the software. For software available as open-source material, one possibility would be to use the guidelines provided by Software Heritage (https://www.softwareheritage.org/2025/05/07/software-heritage-citation-feature/) and CodeMeta (https://codemeta.github.io/).

Competing interests

The author declares that they have no competing interests.

Use of Artificial Intelligence (AI)

The author declares that they did not use generative AI to come up with new ideas for their review.