Moving Sensors & MQTT Subscriptions

[hylkevds]

Imagine a moving sensor. Each Observation has a different FeatureOfInterest. I can subscribe to these Observations using MQTT, for instance on topic Datastreams(x)/Observations. For each Observation I receive the Observation data on this topic, but not the FoI. To get the FoI I would have to do a separate GET on the navigation link I receive in the MQTT message for the Observation.

Somehow this seems a bit inefficient. We should try to come up with a way to specify we also want the FoI with the Observation data. One way would be to allow $expand in MQTT topics, but that seems a bit excessive... Maybe there are better options.

This is related to, but not the same as, issues #29 and #33.

[taniakhalafbeigi]

The spec itself does not limit the topics that SensorThings MQTT topic supports. So, the server can implement the MQTT topics as needed for the use cases. Your point is absolutely valid and I faced that too for moving objects. But do we need to add this spec? I personally think it is more related to implementations and there is no need for it to be added to the spec.

[mjacoby]

Of course everybody could implement additional functionality as needed but the whole idea of having a standard is to be sure that certain things are supported. And if a standard is perceived as good or useful, it covers the features of real-world scenarios. So I would see this as something we should think about including in the standard. I would even think about allowing $expand in MQTT (maybe with limited recursion depth) if there are no good reasons to disallow this.

[taniakhalafbeigi]

The main point for using the standard is interoperability. The data model and the basic interface already provides interoperability between services so that we are able to create innovative applications over multiple IoT services. So, for everything we want to add to the spec we should always ask ourself if it has value in interoperability. For this case, I am not sure. My personal opinion is that $expand in MQTT does not have value in interoperability and only adds more complexity to the spec. But, for the specific case of moving Things I agree with Hylke that FOI in the Observation MQTT message is very valuable, but again we need to think carefully before adding it to the spec.

[mjacoby]

I agree with you that we should not make the standard overly complex. However, it seems we have different views on what overly complex is.

Your argument about the value w.r.t. interoperability would also apply for $expand command in the existing part of the standard - it does not add much value w.r.t. interoperability but just a more convenient way for accessing data, i.e. we could remove $expand completely from the standard and replace it with multiple GET calls without reducing the interoperability. Also, from talking to people using the standard, I got the feeling that the powerful query language (including @iot.navigationLink and $expand) is one of the main arguments for using SensorThings API.

This reminds us, that it is not only technical capability of a standard that counts but also usability.

Allowing $expand in MQTT is probably not adding any relevant complexity to the implementation as it is just a combination of already existing functionality (i.e. apply $expand before returning an MQTT result) but offers more flexibility for users. It also increases consistency between HTTP and MQTT interface.

[lieberjosh]

It has been useful in many applications to be able to form a topic from most any STA query expression, especially since it aligns the MQTT and HTTP interfaces. Such extensions have been created, so the experience should be available to specify this. An issue is that this requires being able to post queries so that they can become topics, but this really does seem to me to be important for usability.