CQL: instant-interval and instant-instant relations

[heidivanparys]

Regarding the following in 9.3. Requirements Class "Enhanced Temporal Operators":

CQL supports date and timestamps as time instants, but even the smallest "instant" has a duration and can also be evaluated as an interval. For the purposes of determining the temporal relationship between two temporal expressions, an instant is treated as the interval from the beginning to the end of the instant. The following diagram illustrates the meaning of the temporal operators.

Yes, time is continuous, which means that any moment of time can be divided into an infinite number of smaller moments. But, time is measured by dividing time into time intervals with a specific duration (temporal resolution = granularity). In practice, a time interval whose duration is less than the temporal resolution used is considered to be an instant.

So to take example 15: when using a temporal resolution of one second, 1969-07-20T20:17:40Z is treated as an instant (although we know that we can subdivide it in fractions of seconds, but that is not the resolution used in this case) and 1969-07-16T13:32:00Z/1969-07-24T16:50:35Z is an interval.

The Time Ontology, listed as a reference, also makes a distinction between instants and time intervals.

As a minimum, the "TOVERLAPS" and "OVERLAPPEDBY" relations are only meaningful for interval-interval relations, not for instant-interval or instant-instant relations. So how should a server react when the client submits a query containing 1969-07-20T20:17:40Z TOVERLAPS 1969-07-16T13:32:00Z/1969-07-24T16:50:35Z? That query is not meaningful. Should an error code be returned?

How about https://www.w3.org/TR/owl-time/#time:hasBeginning and https://www.w3.org/TR/owl-time/#time:hasEnd? They have time:Instant as range and are conceptually similar to https://www.w3.org/TR/owl-time/#time:intervalStarts and https://www.w3.org/TR/owl-time/#time:intervalFinishes. BEGINS is mapped to time:intervalStarts, but a time interval has a start instant.

[heidivanparys]

More background info, from https://github.com/opengeospatial/ogcapi-features/issues/180#issuecomment-439724522, by @morpl:

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.

Note: whatever the outcome of this discussion: it is important that the abstract test cases have scenarios for both time intervals and instants.

[heidivanparys]

Bonus info: this website has a good explanation - including diagrams - on temporal relationships: https://pro.arcgis.com/en/pro-app/latest/tool-reference/big-data-analytics/temporal-relationships-with-big-data.htm

[cportele]

Meeting 2021-04-26:

• One problem is that any deviation from the CSW CQL will break backwards compatibility. That said, since CSW CQL was not clearly specified, how much of an issue is this in practice? We want to get it right and addressing some of the comments, like this one, will require "breaking" changes.
• We want to keep the branding, so we can call it "CQL2" and add an annex to explain how CQL relates to CQL2.
• We agreed to distinguish between intervals and instants - and the behaviour of the operators depending on the type of the operands.
• To avoid an "explosion" of operators, we can make them applicable to both instants and intervals and be clear about the behaviour in the description.
  • We need to clarify all the possible combinations of instants/intervals.
  • A request with a filter containing 1969-07-20T20:17:40Z TOVERLAPS 1969-07-16T13:32:00Z/1969-07-24T16:50:35Z should result in an error.
• In that process we will align the operator names with OWL Time.

[aaime]

Maybe also call the conformance class and filter-lang text-cql2, gives an opportunity to keep on using classic CQL in applications that already implement the classic one.