Re: IOTDB: bands

I think I understand, pretty well, what your model does. I just don't see
how putting all these disparate concepts into one pile makes things simpler
or easier for implementers or for people trying to understand how things
work.

   - Things have an actual state. Things have a control state. I can sit
   and watch things in front of me demonstrate that these are different: I'll
   take a video if you want!
   - Things have metadata, which includes its name, its reachability, its
   facets (definable by the user), perhaps an ACL, perhaps manufacturer data
   and so forth.
   - Things have a model, which is a description of how it works, and what
   the values in it's state mean. The model is basically static after
   definition.

Your model - from the slideshow - looks like this

   1. HTTP GET to retrieve a thing's description
   2. HTTP GET to retrieve all properties of a thing
   3. HTTP PUT to update all properties of a thing
   4. HTTP PATCH to apply changes to some properties
   5. HTTP POST to invoke actions on a thing
   6. HTTP POST is also used to notify events

So specifically

   1. A Things Description - lets say this is the JSON-LD - isn't the same
   as its Metadata, it's actual state (istate), or control state (ostate)
   2. Is this the same URL as #1? If so, you're already basically doing
   bands as I describe it. Otherwise you're returning tons of redundant data -
   the JSON-LD Model, the Metadata, and so forth, &c &c. And if it's just the
   URL, you _still_ need to differentiate between all these different types of
   data
   3. why do you need to update the Model of a Thing, assuming that's what
   you mean by properties.
   4. same
   5. so doing POST to a Thing changes one set of data (making an
   operation), and doing PUT changes a different set of data
   6. same

D.

On Tue, Jun 2, 2015 at 1:10 PM, Dave Raggett <dsr@w3.org> wrote:

>
> 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/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>
>
>
>
>