Re: [Iotsi] interactive vs. programmatic IoT

[Andy Bierman <[e-mail]>]

On Thu, Mar 24, 2016 at 9:01 AM, Michel Kohanim <
[e-mail]> wrote:

> Ummm …. Where does one draw the boundary between what must be relegated to
> the user vs. the machine?  If we expect the machine to make all the
> decisions, then:
>
> 1.       The machine must know everything a priori … this means, for
> every change in the semantic world, there needs to be a change in the
> machine world
>
> 2.       Or, the machine has to learn … this means that we would have to
> use some AI techniques. Are we up for it? If so, which AI paradigm are we
> going to use?
>
>
>

(1)

Typically new functionality only shows up when new firmware or new devices
are added.
This is true for SNMP and NETCONF devices that use SMIv2 or YANG modules
to define the functionality.  The client is typically hard-coded to utilize
specific
revisions of specific modules.  Any new managed device simply advertises
known modules and the client works.

Perhaps IoT devices can do better.



>
> With kind regards,
>
>
>
> ********************************
>
>   *Michel Kohanim*
>


Andy


>   CEO
>
>
>
>   (p) 818.631.0333
>
>   (f)  818.436.0702
>
>   http://www.universal-devices.com
>
> ********************************
>
>
>
> *From:* Iotsi [mailto:[e-mail]] *On Behalf Of *Kreuzer, Kai
> *Sent:* Thursday, March 24, 2016 8:37 AM
> *To:* Subramaniam, Ravi <[e-mail]>; Andy Bierman <
> [e-mail]>; [e-mail]
> *Subject:* Re: [Iotsi] interactive vs. programmatic IoT
>
>
>
> Hi,
>
>
>
> I fully second Ravi on this – the ultimate goal is that algorithms can
> make “sense” out of the services that they find. Being able to only operate
> through UIs pushes the semantic knowledge” onto the user, so I would not
> even talk about semantic interoperability, but rather “only” about
> technical interoperability (see also the second half of my blog post here
> <http://kaikreuzer.blogspot.de/2016/03/semantic-interoperability-in-internet.html>
> ).
>
>
>
> > HATEOAS doesn't really help here
>
>
>
> I do not agree on this. The idea of having the links on the resources is
> to make them self-descriptive and navigatable. So algorithms should be able
> to dynamically “discover” what the service is about and use it adequately
> without any prior knowledge. But Matthias is probably the best person to
> comment on this.
>
>
>
> Best regards,
> Kai
>
>
>
> *Von:* Iotsi [mailto:[e-mail] <[e-mail]>] *Im
> Auftrag von *Subramaniam, Ravi
> *Gesendet:* Dienstag, 22. März 2016 18:49
> *An:* Andy Bierman; [e-mail]
> *Betreff:* Re: [Iotsi] interactive vs. programmatic IoT
>
>
>
> Hi Andy,
>
>
>
> IMHO, for IOT to be successful it would be primarily (what you are
> calling) “programmatic clients” – most **useful** IOT systems would tend
> to be relatively or fully autonomous with human interactions at the
> “periphery” of such systems.
>
>
>
> OCF has called out that it is “declarative and late binding” because the
> expectation is that a “human” would declare “what” they wanted the system
> to be and its objectives and the rest is done by autonomous interactions of
> “programmatic participants” (well… at this stage, OCF spec is in the
> “crawl” stage so this ‘vision’ is hard to see but the basic concepts
> support this direction J )
>
>
>
> Ravi
>
>
>
> *From:* Iotsi [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Andy Bierman
> *Sent:* Tuesday, March 22, 2016 10:29 AM
> *To:* [e-mail]
> *Subject:* [Iotsi] interactive vs. programmatic IoT
>
>
>
> Hi,
>
>
>
> It seems to me that the use-cases discussed at the meeting
>
> assume there is a human with access to UI driving the client.
>
>
>
> Does this mean use-cases which do not assume any human interrupts
>
> are possible are not IoT, but something else? In this environment
>
> everything is usually programmed in advance. HATEOAS doesn't
>
> really help here.  It is not likely the client can make decisions
>
> about code-points it has never seen before.
>
>
>
> Are there any expectations that IoT includes programmatic clients
>
> or is it just for interactive clients?
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
>
>