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

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

From: <john.nj.davies@bt.com>
Date: Thu, 28 Jan 2016 22:33:34 +0000
To: <davidjanes@davidjanes.com>, <t2TRG@irtf.org>, <public-wot-ig@w3.org>
Message-ID: <65de07d1170143699e600026a932515f@rew09926dag10c.domain1.systemhost.net>
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 Thursday, 28 January 2016 22:34:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 January 2016 22:34:09 UTC