W3C home > Mailing lists > Public > public-wot-ig@w3.org > January 2016

Re: 2. WoT Thing needs to have istate/ostate Bands

From: David Janes <davidjanes@davidjanes.com>
Date: Thu, 28 Jan 2016 20:20:45 -0500
Message-ID: <CACp1KyOj_mjSs+rcELfpYrYBxXcQgtsgDk9QAwow-7Cp5KH0tQ@mail.gmail.com>
To: john.nj.davies@bt.com
Cc: "t2trg@irtf.org" <t2TRG@irtf.org>, Public Web of Things IG <public-wot-ig@w3.org>
Hi John,

I am, thank you - and I've been tracking it for a while here!
https://iotdb.org/social/imadeit/tagged/hypercat

I think the kind of models / meta (etc) infrastructure I've been proposing
could easily be "HyperCat transported", and it's been on my mind to do this
with IOTDB for a while.

HyperCat doesn't semantically define terms for sensors, actuators, etc.
which also makes it dovetail nicely with things I've been proposing.

The reason I'm not necessarily saying "start with the HyperCat model" is I
think there's something much nicer / cleaner in terms of representation -
the band model - as a starting point.

D.


On Thu, Jan 28, 2016 at 5:33 PM, <john.nj.davies@bt.com> wrote:

> David,
>
>
>
> This is new to me and I have just checked out your Slideshare overview
> presentation – looks interesting.
>
>
>
> Are you aware of the Hypercat specification: a lightweight, JSON-based
> spec for describing IoT resources (actually could be used in principle to
> describe anything you care to ascribe a URI to). As you advocate, it is
> based on JSON and RESTful tech for low barrier to participation.
>
>
>
> Hypercat has a small mandatory core of metadata elements and can be
> arbitrarily extended as required with additional elements.
>
>
>
> If interested, take a look at: http://www.hypercat.io/standard.html
>
>
>
> There is also a serialisation of Hypercat in RDF.
>
>
>
> Regards,
>
> John Davies.
>
>
>
> *From:* davidjanes@gmail.com [mailto:davidjanes@gmail.com] *On Behalf Of *David
> Janes
> *Sent:* 27 January 2016 09:33
> *To:* t2trg@irtf.org; public-wot-ig@w3.org
> *Subject:* 2. WoT Thing needs to have istate/ostate Bands
>
>
>
> ****
> Formatted Version:
>
> https://github.com/dpjanes/homestar-plugfest/blob/master/docs/2016-01%20W3C%20IETF/2.%20WoT%20Thing%20needs%20to%20have%20istate:ostate%20Bands.md
> ****
>
>
> 2. WoT Thing needs to have istate/ostate Bands
>
> Points:
>
>    - WeMo Model
>    - Interstitial State
>    - What do the properties return?
>
> WeMo
>
> Consider the WeMo Switch, a popular "stater" IoT device. Turning a light
> off to on looks like this.
>
> Stages:
>
>    1. the switch is *off*
>    2. the user sends *turn on* command / the WeMo receives it
>    3. about 300ms (guestimate) passes
>    4. the switch is *on*
>
> It's step (3) we're considering.
> WoT Thing
>
> So let's look at this as a WoT property manipulation. Note that I'm just
> pseudocoding this, I don't know if there's a property called exactly "on"
> but I'm sure there's something like it.
>
> thing.getProperty("on")         ## (stage 1) a promise that yields false
>
> thing.setProperty("on", true)   ## (stage 2)
>
> thing.getProperty("on")     ## (stage 3) WHAAA?
>
> thing.getProperty("on")     ## (stage 4)
>
> The contradiction
>
> It's Stage 3 that's the concern. We don't have a clean way of knowing that
> we're turning on the light, but the light is currently off.
>
> This is called the "Interstitial State" and it's important that this is
> indicated in the UI.
>
> Now, the immediate objection might be "Well, thing.setProperty('on',
> true)" returns a Promise that will tell when the the light turns on. But *this
> is not sufficient* because *thing.getProperty("on")* might be called *somewhere
> else in the code* or *by someone else entirely in a different process*
> The solution
>
> Break up the properties into two states:
>
>    - the *istate*, the "input state", the actual state of the thing
>    - the *ostate*, the "output state", the state we're trying to
>    transition to.
>
> These are independent
>
> Now our code looks like this
>
> thing.istate.getProperty("on")      ## (stage 1) a promise that yields false
>
> thing.istate.setProperty("on", true)    ## (stage 2)
>
> thing.istate.getProperty("on")      ## (stage 3) FALSE
>
> thing.ostate.getProperty("on")      ## (stage 3) TRUE
>
> thing.istate.getProperty("on")      ## (stage 4)
>
> Or even more simply if we make the assumption that the istate and ostate
> are basically views of the properties
>
> thing.istate.get("on")      ## (stage 1) a promise that yields false
>
> thing.istate.set("on", true)    ## (stage 2)
>
> thing.istate.get("on")      ## (stage 3) FALSE
>
> thing.ostate.get("on")      ## (stage 3) TRUE
>
> thing.istate.get("on")      ## (stage 4)
>
> thing.ostate.get("on")      ## (stage 4) NULL - "nothing happening"
>
>
Received on Friday, 29 January 2016 01:21:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 January 2016 01:21:40 UTC