Re: IOTDB: bands

> On 2 Jun 2015, at 16:26, David Janes <davidjanes@davidjanes.com> wrote:
> 
> This is really one my favorite insights into how Things and APIs work together. I gave two presentations on Global IoT Day in Vienna about this
> 
> http://www.slideshare.net/dpjanes/2015-04-global-io-t-day-wien-interoperability-with-stanardless-iot <http://www.slideshare.net/dpjanes/2015-04-global-io-t-day-wien-interoperability-with-stanardless-iot>
> http://www.slideshare.net/dpjanes/what-a-thing-api-should-look-like-global-iot-day <http://www.slideshare.net/dpjanes/what-a-thing-api-should-look-like-global-iot-day>
> 
> So building on the previous message, we have the same definitions for controlling a thing as reading values of a Thing. How do we differentiate between these various aspects? Add into the picture that we also have to deal with _metadata_ and we have to deal with the _model_ (in JSON-LD), how does this fit?
> 
> So here's the key insight: a "Thing" is _not_ JSON dictionary that we manipulate. Instead a Thing, identified by some Thing ID, is a jumping off point to a cloud of related but independent JSON dictionaries. These are (at least):
> istate - the Input State: the actual state of thing
> ostate - the Output State: the state we want the thing to become
> meta - the Thing's metadata
> model - the Thing's JSON-LD Model
> The entire IoT / Web of Things can - and _should_ -  be seen as just reading an manipulating these four JSON dictionaries! The back end is just shuffling the data around to the proper point to be actioned!

This sounds over complicated. What is wrong with a single model of the thing and relying on the server platform to do its best to propagate property changes in both directions?

In my NodeJS server, the server creates a proxy object from its model. The object is set up with setters and getters for its properties. For the WebSocket protocol binding, a PUT message updates all of the properties whilst a PATCH message updates a subset. The model consists of {metadata, events, properties, actions}.  The script writer doesn’t have to deal with the protocol as this is handled by the server.

In principle, the metadata can change e.g. when a sensor is moved from one location to another.  This shows the need for propagating changes to metadata using same framework as for thing properties.  I think it would be appropriate to also associate events with metadata changes.

You could describe actions in terms of pre and post conditions and then use a reasoning engine to figure out what sequence of actions on what things are needed to address some goal.

Or perhaps I am missing your point?

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>