search

opengeospatial / sensorthings

The official web site of the OGC SensorThings API standard specification.
134 stars 29 forks source link

Handling transient "things" #34

Open dpmcgarry opened 6 years ago

dpmcgarry commented 6 years ago

We have an issue handling things that are transient. For example, tracking a vehicle. Since a vehicle may report for a while and then cease to report, there is no clear way in the spec for the vehicle to know what it's @iot.id will be. This introduces the requirement to store arbitrary state in the client to remember it's id across sessions. There is no "easy" way we could see in the API for a thing to grab what it's ID was and continue to update it after a period of offline.

In addition to this, there is the issue of things never going away unless they are explicitly deleted. Since there are no time fields explicitly associated with a thing, there is no clear way to determine when things should be deleted.

hylkevds commented 6 years ago

The car will always need to have some way to identify itself, so some form of state is required in the car. This does not have to be the @iot.id from the SensorThingsAPI. You could for instance store the licence plate number in the properties field of the Thing, and use that to find the correct Thing to update:

v1.0/Things?$filter=properties/plateNr eq 'xyz 123'

You are correct that there is not explicit time associated with a Thing, but there is nothing stopping an implementation from keeping track of that internally, and automatically deleting Things based on that. This time could even be exposed through the properties field of the Thing.

dpmcgarry commented 6 years ago

Gotcha thanks. So would it be a "good" approach for an implementation to have a specific set of items within the properties field as somewhat of a STAPI "profile" based on the needs for that implementation?

hylkevds commented 6 years ago

Most server implementations allow you to put anything you like in the properties field. It's completely up to the client. I think it would be good to have to best-practice sets for different domains, so clients know better what to expect.