$filter phenomenonTime in v2.0. $filter=phenomenonTime or $filter=phenomenonTime/start

[liangsteve]

Let’s consider the following example:

{
  "result": {
    "temp": 15,
    "press": 1024
  },
  "phenomenonTime": {
    "start": "2021-12-14T15:16:00Z"
  }
}

What is the correct filtering syntax for phenomenonTime?

$filter=phenomenonTime/start lt 2021-12-14T15:16:00Z

or

$filter=phenomenonTime lt 2021-12-14T15:16:00Z

I seem to see conflicts and inconsistency in the draft.

[hylkevds]

From the OData perspective only the former is allowed (with a clear /start) since in OData one can not use a complex property by itself in a filter.

The question is if we want to allow the second one as a shorthand, by specifying certain filters can be used on complex properties of the type TimeObject and TimeInterval.

[liangsteve]

In principle, we should minimize the shorthands, and I think we can all agree on that.

In our data model, phenomenonTime is a TM_Object, as a result, we should be able to perform Allen's interval algebra on it, similar to our topological operations.

Using gt, lt, etc. are not semantically correct anyways.

I guess the question becomes:

• should we introduce new temporal operations to STA?
• are there existing temporal operations in OGC we should follow? or bring to Architecture SWG?

let's discuss I guess. :)

[hylkevds]

Temporal logic is the oldest open issue in the issue list: #2 :)

Using /start and /end a client can build queries that correctly simulate all interval functions, but the queries can be quite ugly.

If we add interval functions, those functions can operate on complex properties.

If we don't want to add interval functions to the core API, we could put them in the planned extension document.

[humaidkidwai]

We did discuss #2 a couple weeks ago in the telco discussions and concluded that we can include the functions in the extension document. But the issue got buried away after that.