Re: IOTDB: bands

Well, still don't have millions in funding yet to be an organization lol…

D.


On Wed, Jun 3, 2015 at 8:34 AM, Dave Raggett <dsr@w3.org> wrote:

> Yes, that’s the case. If you work for a W3C Member organization you can
> join the Interest Group and participate in the IG calls.  However, we can
> always set up separate calls for members of the Community Group, e.g. using
> Skype.
>
>
>
> On 3 Jun 2015, at 13:26, Vlad Trifa <vlad@evrythng.com> wrote:
>
> Hey,
>
> not sure how this works for external participants (@Dave Raggett,
> thoughts)?
>
> I believe the calls are only for W3C member organisations, but I might be
> wrong.
>
> The infos are here: https://www.w3.org/WoT/IG/wiki/Main_Page
>
> Vlad
>
>
>
> On 03 Jun 2015, at 12:15, David Janes <davidjanes@davidjanes.com> wrote:
>
> When / where are these calls?
>
> D.
>
>
>
>
> On Tue, Jun 2, 2015 at 4:10 PM, Vlad Trifa <vlad@evrythng.com> wrote:
>
>> Hey David,
>>
>> First, thanks for all the input/comments/feedback. Lots of goodness in
>> there!!
>>
>> Sorry for my rather long mail (you can skip to "showtime" below and
>> control a REAL device in our office via a REST API!!).
>>
>> After spending a decade on building Web-conntected devices (and getting
>> my phd on the Web of Things ;) ), I fully agree we need both "current" &
>> "planned" states. We face this exact problem for commercial connected
>> products at EVRYTHNG, so the model we propose supports both (have look here
>> if you didn't see it already, it's pretty detailed:
>> https://github.com/w3c/wot/blob/master/TF-AP/WoT-Label%20v0.1.pdf).
>>
>> ** PROPERTIES **
>> A property "SHOULD" always reflect the most recent (known) state of a
>> thing. So for simple scenarios, it's OK to be able to change them on the
>> spot. For example, the location of a thing: the device doesn't know where
>> it is (no GPS, etc. on board), so I could use an app on my phone and set
>> the "location property" from outside the device. Another exception is when
>> you don't care about the status and assume that sooner or later the device
>> will update it successfully (does this even exist?) or maybe when you know
>> that the current status will be updated right away (Web API runs on device
>> and has the confirmation asap).
>>
>> The model you suggest, where you have two copies of the same property
>> (current_X and planned_X) is very useful when the device can only poll data
>> from a server (it knows which one to listen to: planned_X, and updates the
>> current_X when its done). This is how NEST API does it. But I don't think
>> we should force *every *property to be doubled, unless for those you
>> really need this.
>>
>> This is what we've been doing with EVRYTHNG and works well in the real
>> world (see here: https://dev.evrythng.com/developers/apidoc/properties)
>>
>> ** ACTIONS **
>> But when you need to model any operation that is more complex than "just
>> change the value" (which is common in the real world), then you will use
>> *ACTIONS*. An action is a higher level abstraction for what a device does
>> which has a special meaning, a context, some validation, and more (who can
>> access it, when, how, how many updates per day, etc.). The simplest action
>> would be "setStatus()" which takes a boolean as param. If the Web thing is
>> on a proxy, it can use a callback that send this command in
>> "whatever-the-device-understandsese" to the actual device and update the
>> "status" property once it gets a confirmation. So a simple action, is
>> nothing more than a getter/setter around properties, but with room to add
>> as much complexity as required.
>>
>> But many operations will involve and change various properties (some
>> instantaneously, other later), and the logic of this ("code" of the action
>> handler) is left to the developer (either on the device itself, so would be
>> C/C++/etc., or in the proxy). Think of a printer - you will obviously need
>> to expose high-level actions (print X, reboot, etc.), as I don't think I'd
>> like to write a script that coordinates and sets a bunch "raw" of
>> properties that control the various motors, inks, etc. each time I'd like
>> to print something.
>>
>> (To see how we've used actions at EVRYTHNG, here's our API:
>> https://dev.evrythng.com/developers/apidoc/actions )
>>
>>
>> ** WHAT'S NEXT? **
>>
>> I suggest you look at the JSON payloads I've uploaded in our github (
>> https://github.com/w3c/wot/tree/master/TF-AP/JSON%20Payloads), this will
>> give you an excellent idea of how you would implement the various
>> operations you suggest over REST, from getting the metadata and also
>> interacting with the device (from discovering actions, how they work, how
>> you create them, etc.). I would truly love your feedback on those.
>>
>> We'll also present this model tomorrow during the TF-TD call, so please
>> join!
>>
>>
>> ** SHOW TIME!!! **
>> Finally, you can see how this model works with actual devices (
>> http://devices.webofthings.io/ --> hint: ask for "application/json"
>> using curl/postman on those URLs, it's more fun!!). It's obviously a work
>> in progress, but we'll be releasing the source code of the server side (in
>> node.js as well) in the next few weeks.
>>
>>
>> Would love to discuss this more in detail in the upcoming calls.
>>
>> Vlad
>>
>>
>>
>>
>>
>>
>>
>> --
>> vlad trifa, phd ////
>> co-founder, head of r&d + innovation
>> m +44 750 888 2051 // w evrythng.com <http://evrythng.net/>
>> t @vladounet /////// w vladtrifa.com
>>
>> On 02 Jun 2015, at 19:32, David Janes <davidjanes@davidjanes.com> wrote:
>>
>> 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>
>>>
>>>
>>>
>>>
>>
>>
>
>
> —
>    Dave Raggett <dsr@w3.org>
>
>
>
>