Engineering a formal representation of complex temporal Information using the Web Ontology Language

Tracking #: 3682-4896

Authors: 
Yusuf Aminat

Responsible editor: 
Elena Demidova

Submission type: 
Full Paper
Abstract: 
Ontologies, a common approach for knowledge representation, encounter challenges in effectively handling time expressions, particularly in languages like OWL. Despite various proposed mechanisms for achieving consistent time representation within a single ontology, OWL-Time constructs have limitations in modelling complex recurring time expressions, crucial for domains such as clinical or historical. Hence, extending the OWL framework to represent recurring temporal information identified in domain-specific challenges is necessary. This paper enriches OWL-Time with the concept of recurring time by identifying five recurring time-related problems namely strongly, nearly, intermittent, non-recurring, and stochastic recurring time, covering the spectrum in classical ontologies. We propose BOLA as a novel ontology, extending OWL-Time's primitive entities, calendar descriptions, and introducing a new concept for recurring time rules. This extension creates 33 core temporal classes, offering a comprehensive representation within OWL-Time constructs. We evaluate the ontology's completeness, expressiveness, and complexity. Experimental results show that BOLA effectively represents a wide range of complex recurring temporal information within OWL-Time constructs, achieving completeness scores of 87 and 88 for class and property coverage hierarchy, expressiveness score of 13 for complex expressions with 49 cardinality restrictions, and a complexity reflection of 266 axioms, including 123 logical axioms.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Reject

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 05/Jul/2024
Suggestion:
Major Revision
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.

Review #2
Anonymous submitted on 21/Jul/2024
Suggestion:
Reject
Review Comment:

The article proposes an ontology for modelling complex temporal expressions. The proposed ontology extends OWL-time and includes 33 classes, aiming to model recurrent time expressions.

The proposed modelling of the time expressions seems overly complex. Its practical value is questionable and not confirmed by the evaluation. Furthermore, no machine-readable representation of the proposed ontology is provided.

The evaluation of the proposed ontology describes the statistics in terms of the number of classes, properties and axioms. The evaluation does not provide any results confirming if the proposed ontology is applicable in praxis.

Overall, the originality and significance of the proposed ontology seem insufficient for a publication. The quality of writing can be further improved. Therefore, I recommend rejecting the submission.