sensing v2.0 task proposal for TC

[liangsteve]

According to OGC policy, we need to follow the SWG Task approval process, i.e., propose and present a new task to TC, get it approved before we can work on them.

We need to describe:

1. Scope
2. Justification
3. Tentative timeline
4. Relationship with existing SensorThings API standards
5. Implementation Commitments

[hylkevds]

Not to forget: Relationship with other OGC Standards:

• O&M (We're talking observations)
• Features (In many use-cases, our Things are (related to) Features)
• The one currently known as EDR (They have some cool trajectory queries)
• Coverages (Since Observations can be Coverages, or served as Coverages)
• Processes (Since they are related to tasking)

[liangsteve]

add more to the above list:

• Moving Features (orientation and location)
• GeoPose
• TimeseriesML
• Point Cloud

[liangsteve]

Justification 1

STA v1.0 conformance class follows the typical OGC web services model, designed to be READ first (Conformance Class A.1). Pub-sub (e.g., Conformance Class A.7 and A.8) is an extension. However, many of the users only use pub-sub. As a result, STA v.2.0 would consider re-organize the conformance classes to be pub-sub first, and rather than pub-sub is depending on READ.

[liangsteve]

Justification 2

STA v1.0 is based on OGC O&M v2.0 data model. Now O&M has been updated to v3.0. As a result, STA v.2.0 would consider updating its data model to be compliant with O&M v3.0.

[liangsteve]

Justification 3

OGC API becomes a clear trend in the geospatial community. OGC APIs uses the simple Open API pattern, while STA is based on the OData pattern. Some preliminary work has been done to show how OData pattern and Open API pattern can work together. One possible approach for STA v2.0 is to consider having a simpler conformance class for Open API pattern, and a more comprehensive conformance class for OData.

[hylkevds]

Another "brainstorm" item: Something with JSON-LD

[hylkevds]

Some additional information on Justification 1: Currently the STA MQTT extension only allows for:

• subscriptions on modifications,
• the creation of new Observations

This means that the MQTT extension does not allow for request/response type data retrieval.

MQTT5 has formalised the way to do request/response data exchange over MQTT, so this makes it possible to apply the complete SensorThingsAPI rest interface to MQTT as well, instead of just HTTP.

Some of the relevant changes between 3.1.1 and 5.0 from https://github.com/mqtt/mqtt.org/wiki/Differences-between-3.1.1-and-5.0

• Payload format and content type: Allow the payload format (binary, text) and a MIME style content type to be specified when a message is published. These are forwarded on to the receiver of the message.
• Request / Response: Formalize the request/response pattern within MQTT and provide the Response Topic and Correlation Data properties to allow response messages to be routed back to the publisher of a request. Also, add the ability for the Client to get configuration information from the Server about how to construct the response topics.
• User properties: Add User Properties to most packets. User properties on PUBLISH are included with the message and are defined by the Client applications. The user properties on PUBLISH and Will Properties are forwarded by the Server to the receiver of the message. The meaning of user properties is not defined by MQTT.