Review Comment:
In this paper, the authors propose an ontology extension for modelling complex recurrent time expressions to extend OWL-Time. Some original classes and relations are proposed, but the novelty is unclear as there are existing solutions for modelling recurring events, e.g. [1]. I also have concerns about the proposed ontology.
Main concerns:
- In my view, the proposed ontology is overly complex and not a very clean solution, its logical soundness is also difficult to assess.
- There is no evaluation of the usefulness of the proposed ontology. Although many metrics are mentioned in the evaluation section, there is no result from them.
- The paper is not well written, the figures are difficult to interpret, the description of classes and properties lacks structure. There are many language problems, typing errors and redundant descriptions.
- The ontology data file is not provided.
More detailed comments:
- I'm not sure if it is necessary to define all objects of a periodic entity as periodic, it makes the ontology too complex and may be logically questionable. From my point of view, the class of periodic events can be modelled by defining reasonable properties rather than going in a circle of defining so many periodic classes. A cleaner example solution can be found in [1].
- Contributions 1 and 2 should be merged into one.
- In the related work section, subsections 1.1/1.2 should be 2.1 and 2.2.
- It may be necessary to define the scope of some important terms such as "time expression".
- Authors should really consider adding some structure (e.g. item list, tables) to the description of defined classes and vocabularies.
- Table 2 is hard to read. Moreover, how are compositions created? Is it always possible to split an expression into two parts?
- In Figure 1, some arrows represent subclass relations, some are different (e.g. hasIntervalTime), the specific relations should be made visible.
- Please make a clear distinction between object properties and datatype properties.
- Instead of describing the time period with "upper limit" and "lower limit", perhaps standard terms like "start" and "end" would be easier to follow.
- For the example in Figure 3, what rule is used to ensure that the "everyMonday" and "everySaturday" should give time limits in the same week?
- For the example in Figure 4, the recurring nature of the entity is already shown, so why does the time span used to describe the properties of this entity need to be periodic? Why would a normal time span not work in this case?
- For all figures, it would be good to have a clear distinction between the newly defined classes and properties and the existing ones. Also, the entity identifiers should adopt a more formal format to avoid the possibility of mixing entity identifiers, object properties and data type properties.
- How "three" becomes (and why it is necessary) in the model in Figure 8 is unclear to me.
- Figure 9 is incomplete.
- Please highlight the classes to be introduced in Figure 10.
- I do not see result of the long list of metrics.
References:
[1] Carriero, Valentina Anita, Aldo Gangemi, Andrea Giovanni Nuzzolese, and Valentina Presutti. "An ontology design pattern for representing recurrent situations." In Advances in Pattern-Based Ontology Engineering, pp. 166-182. IOS Press, 2021.
|
