Temporal data

[heidivanparys]

The Agency for Data Supply and Efficiency (Denmark) has a use case for queries in data with multiple temporal properties. Our data specifically contains bitemporal properties (see references to literature below) but they could in principle have even more temporal properties.

We have looked at #155 and the time-parameter in the WFS core specification. We find that it is not sufficient for our needs wrt. bitemporality. Moreover, it is unclear to us how it is announced to the client which data is being used. We assume that details about representations of time in data as a "time field" or intervals would be left to the server implementation.

We propose an extension that somehow supports queries in data with multiple temporal properties. This functionality need not be implemented as an individual extension dedicated to temporal queries. It could also be implemented as part of a "fuller query language". I.e. a way to support queries that in current WFS-versions are using the filter encoding (with temporal operators).

Note that the concepts transaction time and valid time are also mentioned in ISO 19108 (with a reference to an older version of [2], see relevant literature below).

Note that INSPIRE also uses these concepts, the terms "lifespan version" (begin and end) and "valid" (from and to) are used.

Relevant literature
[1]
SNODGRASS, Richard T. Developing time-oriented database applications in SQL [online]. San Francisco, California : Morgan Kaufmann Publishers, 1999. ISBN 1-55860-436-7. Available from: http://www.cs.arizona.edu/~rts/tdbbook.pdf
[2]
JENSEN, Christian S. The Consensus Glossary of Temporal Database Concepts—February 1998 Version. In : Temporal Databases: Research and Practice [online]. Springer Berlin Heidelberg, 1998. p. 367–405. Lecture Notes in Computer Science. Available from: http://www.cs.arizona.edu/people/rts/pubs/LNCS1399.pdf
[3]
FOWLER, Martin. Temporal Patterns. [online]. 16 February 2005. Available from: http://martinfowler.com/eaaDev/timeNarrative.html
[4]
GAMPER, Johann, DIGNÖS, Anton, JENSEN, Christian S and BÖHLEN, Michael Hanspeter. Temporal Data Management - An Overview. In : [online]. Springer, 2017. Available from: https://www.zora.uzh.ch/153529/1/tdb_tutorial.pdf

[pvretano]

@heidivanparys Have you looked at the temporal support in WFS 2.0 & FES 2.0? Is that suitable for your needs? Just asking as a guide for future extensions for WFS 3.0.

[morpl]

@pvretano We need a query language that enables us to do more comparisons than FES 2.0. Let me elaborate on that:
We became aware of this need through a support case in which a developer was trying to access a WFS 2.0 service and use filter encoding to filter data based on the bitemporal attributes. It seems that the temporal operators in FES and our bitemporal attributes are not compatible (at least not in the WFS server that we use).

The temporal operators (based on ISO 19108) in our server seems only to compare time intervals. An operator has two operands: a "value reference" to an attribute in data and a "literal" with a time interval. The problem is that we use two attributes (datetime) to represent a time interval. Consequently, we cannot just refer to a single attribute with the time interval. The data is also used in other contexts in which our representation of time intervals works well (and use of GML datatypes would be considered odd and cause problems), so we would like to keep it that way.

Looking at FES 2.0, section 7.9, I think the temporal operators looks adequate, but our problem still seems to be that a TemporalOperator has a ValueReference as operand1. We would like to compare datetime attributes with literals (timestamps and NULL values). I think this could be achieved in various ways - new operators could be introduced or existing operators could be expanded/overloaded. If the comparison operators could work on attributes of type datetime, it would solve our problem - filters dealing with our representation of bitemporal properties would look like the SQL statements that we use in custom-built services.

(If I have overlooked something in FES, please let me know - it would be great if we actually had an easy solution for our current problem.)

PS: Sorry about the late reply - I'm the only one to blame.

[cportele]

This is out-of-scope for the Core and something that could be addressed in an additional part, if there is sufficient need for such a capability.

[cportele]

@morpl @heidivanparys - Do the temporal operators from Part 3 (https://docs.ogc.org/DRAFTS/19-079r1.html#enhanced-temporal-operators) provide the requested capability and we can close this issue?

Alternatively, if there is a need to create an interval from begin/end properties and direct comparisons with begin or end do not work for some reason, you could support a function in the CQL implementation that takes begin and end as parameters and returns an interval.

[heidivanparys]

@cportele We still have to read part 3, we'll do so next week and get back with an answer.

[cportele]

Thanks @heidivanparys - by the way, if you need more time for the review of Part 3 there is no rush, we will extend the review period to allow for more implementations and implementation feedback.

[heidivanparys]

This issue is related to #565.

[heidivanparys]

This issue is also related to #566. I'll close this one, the discussion can move to the other two issues.