There are a few differences between the form in which predicates relating to events and processes are structured in pure logic and in the system implementation. One difference is that, in the system, a special predicate is used to represent temporal standpoint semantics parameters. This predicate takes the formtime threshold(0,2,0,0,0,0), where ar- guments correspond to the number of years, months, days, hours, minutes, and seconds. This structure allows the system to perform temporal calculations involving these thresh- olds and timestamps represented using ISO 8601 date and time descriptions (as required by the temporal reasoner described in Section 5.5). This predicate is passed as arguments of other predicates as exemplified below.
proceeds(on, time_threshold(0,2,0,0,0,0), ProcType, Intv).
Another important distinction is that the system employs a special argument in predi- catesactive,proceedsandoccursto denote their different variations, such as ‘active at’ and ‘active on’. For instance, the predicateactiveis structured as shown below.
active(Active, ProcessType, Interval)
In the Prolog predicate shown above, the argument Active should be unified with constantsonorat. Specifying these variations using an argument (rather than defining different functors) enables code reuse and consequently makes the code more concise and maintainable. Moreover, these arguments are essential to enable the reversibility of these predicates, that is, to allow free variables to be specified in place of these arguments to ask the system to find appropriate values for them in different situations (though it is not implemented in the current version of Progress). In this case, these arguments would be fundamental for improving efficiency, since tasks which are common for all variations of a predicate can be processed first, and then auxiliary predicates are called to perform specific tasks (e.g.,active aux(on, ProcessType, Interval)).
As noted in Section 5.2.3.1, an important characteristic of Prolog is the flexibility in the manner arguments of a predicate can be used, allowing different arguments to
be queried by perfoming the reasoning in different directions. However, there are cer- tain cases in which such a reversibility of Prolog programs is not possible. Implement- ing this reversibility is particularly challenging when dealing with spatial and temporal information. For example, the predicate active(at, ProcessType, Instant) is not supposed to be used with Instant as a free variable. This is not expected since there may be an infinite number of time instants within a given interval. On the other hand, active(on, ProcessType, Interval) might be included in a query with
Intervalinstantiated or not.
Other cases within Progress implementation which requires special treatment include the case where a given predicate argument corresponds to an element that might have been explicitly asserted in the KB with the objective of gaining efficiency. Thus, the implementation of these predicates should include artifices to enable different possible reasoning flows. A typical example is for an argument representing a geographic fea- ture13, where the system has to decide whether the feature will be directly retrieved from the KB or inferred at query time. Specific points in Progress’ code where the reasoning direction should be controlled are determined by employing the predicates nonvar(X)
orvar(X), that checks whether a variableXis instantiated or not, respectively.
There is still a relevant difference between theory and implementation which should be highlighted. In Chapter 4, the predicate Active-At is defined in terms of feature lives, whereas Active-On is defined in terms of the Active-At. However, this cannot be imple- mented in the system as it is not able to derive all time instants within an interval. Thus the system implements these predicates the other way round. That is, the activeness of a process on time intervals is inferred from the feature life, and then Active-At can be used by specifying a constant value to the argument representing the time instant.
Another important aspect of the implementation of Progress that is worth to be high- lighted is that it explicitly asserts facts describing primitive events (beyond the elements mentioned in Section 5.6.3). The motivation for this is similar to that of asserting max- imal extensions of geographic features. That is, while bottom-up reasoning (inferring events from MLPs) requires significant amount of time to be performed, top-down rea- soning (e.g., to infer process activeness at a given time instant from primitive events) can be performed quite quickly.
13Arguments denoting geographic features are specified within the predicates representing event and
5.9
Summary
This chapter presented Progress, a system prototype implemented to evaluate the appli- cability of the theory proposed in this thesis. A description of the system’s architecture and an overview on its main components has been given. Then specific discussions have been conducted on the approaches to implementing the spatial and temporal reasoners; the STAR model presented in Chapter 3; and the logical framework presented in Chapter 4.
Results of Using the System with
Spatio-temporal Data
6.1
Introduction
This chapter describes the experiments carried out using the system prototype (presented in Chapter 5) with temporal series of topographic data, and examines the results obtained from these experiments.
Results will be assessed for different components of the system, in particular the logic-based approach to modelling spatio-temporal data and the logical framework for representing and reasoning about geographic events and processes. The former will be examined based on the system’s capabilities of inferring implicit spatio-temporal data in different situations, and of producing appropriate representations of geographic features that are said to exist over time. The latter will be tested based on its suitability for an- swering different types of logical queries.
The main objective of these experiments is to evaluate the applicability of the proposed theory to processing real spatio-temporal data, with particular attention to the consistency and coherence of output results. Although the computational performance is not the fo- cus of the experiments, this chapter also describes the overall performance (in terms of executing time) for carrying out a variety of different tasks with the system.
This chapter is organised as follows. Section 6.2 describes the methodology applied
to evaluate the coherence and correctness of results produced by the system. Following this, Section 6.3 describes the case study considered for conducting the experiments and presents the dataset input to the system. Then tasks carried out for preprocessing the input data are described in Section 6.4. Then Section 6.5 examines the experiments and results obtained by using the STAR model to derive implicit spatio-temporal data and to indi- viduate geographic features. Section 6.6 describes the results obtained when the system was tested for answering queries formulated using the logical languageℜ, interpreted by the REGEP framework. Following this, Section 6.7 gives an overall analysis of obtained results and draw some conclusions. Finally, Section 6.8 summarises the chapter.