- 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