Re: IOTDB: modeling state

These distinctions become much more obvious when you work with real
devices. We, as programmers are using to things happening immediately - we
update a database, and the value is what we updated it to.

This isn't true for Things.

Consider a WeMo Switch, which is about the simplest Thing we can consider.

   - It is either on or off - that is, it's passing power or it is not.
   This is it's "actual value"
   - It can be turned on or off physically
   - We can turn it on or off via software

The _actual value_ is the state it is reporting: on or off, which we assume
corresponds to whether it is passing power or not.

The _control value_ is what we would like the WeMo switch to do (via
software): turn on or off.

Now normally we think these are the same, but with Things (and specifically
the WeMo Switch) these become disassociated. In particular, when we ask a
WeMo (or any other Thing), it takes time for the command to execute:
sometimes this can be measured in seconds.

   - "actual on"=true
   - I want to turn it off. We do this be "control on"=false
   - --- time passes, and it eventually turns off ---
   - "actual on"=false

In the middle, in the "time passes" we have "on" being in two different
states:

   - "actual on" is true
   - "control on" is false

If we want to be able to accurately model Things, this distinction has to
be made.

D.

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

>
> On 2 Jun 2015, at 16:13, David Janes <davidjanes@davidjanes.com> wrote:
>
> One issue you are going to face as you start modelling 'real world' things
> is there's a lot of 'near duplication' of semantic terms.
>
> For example, in DR's definitions you end up with something like this for
> Lights (my apologies if this isn't 100% correct)
>
>    - on: turn the light on /off - { write: true }
>    - is_on: is this on or off - { read: true }
>
>
> For an on/off light switch it is easier to have a single writeable boolean
> property.   The proxy object can use getter and setter methods so that
>  assigning true or false result in the switch being turned on and off
> respectively. If a human activates the switch, then the proxied property
> will be updated automatically to match.
>
> Of course it is good practice to re-use ontologies/vocabularies where
> possible as this will simplify the lives of developers.
>
> Now consider a Denon Audio / Visual Receiver. It has, amongst other things:
>
>    - on
>    - volume
>    - band
>    - mute
>
> So you end up with a parallel set of definitions
>
>    - is_on
>    - actual_volume
>    - actual_band
>    - is_muted
>
> Why not stick with the first set of properties and make them writeable?
>
> I am not sure what you mean by the difference between control values and
> actual values, can you provide an example that clarifies your distinction?
>
> —
>    Dave Raggett <dsr@w3.org>
>
>
>
>