Re: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and webex details - 24 Sept 2015 at 15:00 CEST)

Hi Romain,

The aim of the Web of Things is to simplifying scripting by decoupling details of protocols and messaging formats. The models are essential to this by enabling servers to create the scriptable objects  that act for sensors, actuators as well as abstract entities. The models allow the server to figure out what kinds of messages are needed to wire up the software objects in the script execution space to the the protocol drivers. Some IoT devices may use CoAP, others MQTT, and some might use HTTP, Web Sockets or XMPP. Other IoT devices could use IoT communications technologies like ZigBee, or EnOcean, and require a gateway to expose them to the Web of Things.

When you say discovery based upon device type, this is where the semantic descriptions of things comes in as we will need a common vocabulary for talking about things of the same type.  For interoperability, we need to know what the data model is so that we can transform the data types as necessary e.g. transforming temperature units, or video formats. We need metadata for the protocols and data formats a given device supports so that we can talk to it using the protocols it understands. Likewise, we need security metadata so that we know what its requirements are for authentication and encryption etc.

I am probably misunderstanding you. When a Web app would like to interact with a device/service, it would need to learn about it in some way. What kind of device it is, what interfaces it supports, what protocols and data formats it supports and so forth. This metadata could be provided directly by the device, or indirectly, from another source.  By abstracting discovery from the underlying mechanisms, we can provide considerable flexibility in how this can be realised.  Perhaps a discovery agent can use the UPnP data to construct the metadata or to look it up somehow, e.g. via a query on a cloud service. We want to avoid the service logic needing to know the details of the UPnP XML formats and identifiers.

Best regards,
   Dave

> On 12 Oct 2015, at 18:05, BELLESSORT Romain <Romain.Bellessort@crf.canon.fr> wrote:
> 
> Hi Louay,
> 
> Thanks for your response. By other contexts, I basically mean all the cases where a web app would like to interact with a remote device/service but without having to rely on WoT model.
> 
> This may especially be the case when interacting with local devices that can run servers, such as network cameras, TVs, copiers... Services running on such devices can be discovered based on their types (e.g. UPnP service types), said types also defining how to interact with selected services. Therefore, in this context, relying on WoT model and WoT-customized API is not necessary. More generally, not all services may want to provide a Thing Description, just like not all web services provide a WSDL description. A generic API would allow addressing such cases.
> 
> Of course, it would be possible to define a generic API on top of Thing API (e.g. by defining default "sendMessage" action and "onmessage" event), but it seems more logical to define a specialized API over a generic API than the other way around.
> 
> Regards,
> 
> Romain.
> 
>> -----Original Message-----
>> From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de]
>> Sent: vendredi 9 octobre 2015 18:22
>> To: BELLESSORT Romain; 'fd@w3.org'; 'Hund, Johannes'; public-wot-
>> ig@w3.org
>> Cc: FABLET Youenn
>> Subject: RE: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and webex
>> details - 24 Sept 2015 at 15:00 CEST)
>> 
>> Hi Romain,
>> 
>> Thx for your feedback, I saw your Mail on the Presentation API CG ML. As
>> you said, the Thing API proposal follows some Ideas of the Presentation API
>> especially for abstracting from Discovery and Communication technologies as
>> well as showing Selection Dialog for the user (Select Displays vs Select
>> Things). I agree with you that we can make a more generic API for
>> communication that can be customized to support WoT TD and other
>> contexts. Do you have use cases that covers "other contexts"?
>> 
>> regards
>> Louay
>> ________________________________________
>> From: BELLESSORT Romain [Romain.Bellessort@crf.canon.fr]
>> Sent: Friday, October 09, 2015 1:12 PM
>> To: Bassbouss, Louay; 'fd@w3.org'; 'Hund, Johannes'; public-wot-ig@w3.org
>> Cc: FABLET Youenn
>> Subject: RE: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and webex
>> details - 24 Sept 2015 at 15:00 CEST)
>> 
>> Hi Louay,
>> 
>> Thanks for this interesting proposal. We have been following both
>> Presentation API and WoT IG, and we agree that Presentation API may
>> provide a good model for a broader discovery and interaction API (we have
>> recently proposed that Second Screen CG may work on such an API [1], but
>> of course we would also be interested if things were to happen in another
>> group).
>> 
>> In addition to comments regarding the number of devices (selection,
>> filtering), which have already been addressed, I was wondering about the
>> scope of this API. Your proposal is somehow specific to WoT model as it relies
>> on property/action/event. This perfectly makes sense in WoT context, but
>> have you investigated the opportunity for simply defining how to
>> send/receive messages, as in Presentation API? Such an API could then be
>> customized to obtain something like the Thing API in WoT context, or
>> another API in another context. Maybe your implementation builds over
>> such a generic message exchange primitive?
>> 
>> Regards,
>> 
>> Romain.
>> 
>> [1] https://lists.w3.org/Archives/Public/public-
>> webscreens/2015Oct/0000.html
>> 
>>> -----Original Message-----
>>> From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de]
>>> Sent: vendredi 25 septembre 2015 12:59
>>> To: 'fd@w3.org'; 'Hund, Johannes'; public-wot-ig@w3.org
>>> Subject: AW: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and
>>> webex details - 24 Sept 2015 at 15:00 CEST)
>>> 
>>> Hi Francois,
>>> 
>>> Thx a lot for your feedback ;) please find my comments inline.
>>> 
>>> Louay
>>> 
>>>> 
>>>> Not raised during the call as I was busy scribing, but I have a
>>>> couple of comments as well, so thought I'd share them here.
>>>> 
>>>> The Presentation API is currently limited to selecting only one
>>>> second screen at a time. That is not a real problem as the main use
>>>> cases considered only involve one second screen (at least one second
>>>> screen at a time). However, I wonder whether discovery of a single
>>>> Thing is also a common use case for connected objects.
>>>> 
>>>> For instance, looking at the Generic Sensor API [1] that was
>>>> mentioned during the call, I see that the entry-point to that API is
>>>> to retrieve and monitor *a list of sensors*. Although a Thing in the
>>>> WoT case may be contain more than one sensor, I suppose that, most
>>>> of the time, the mapping will be one Thing per physical object, as
>>>> in "a light bulb". I see value in the ability to select and interact
>>>> with a particular light bulb, but I also think that it might be
>>>> useful to select "all the light bulbs
>>> in this room" for instance.
>>>> 
>>>> Would supporting the ability to select more than one Thing at a time
>>>> be useful? Do you see what API changes could do the trick? (That
>>>> feature could actually be useful for a future version of the
>>>> Presentation API)
>>> [Louay] Completely agree on this I think I see more relevance in the
>>> Thing API for multiple select than for the Presentation API because in
>>> the Presentation API when you start a PresentationRequest the
>>> presentation page  will be launched  when the user  selects a display
>>> but in the Thing API proposal the web page will only  get the thing.
>>> To support multiple changes an array of things can be passed to the
>>> page when the Promise is resolved instead of only one (input things
>>> instead of
>>> thing):
>>> ThingRequest(filter).start().then(function(things){...}).catch(function(
>>> err){...}
>>> );
>>>> 
>>>> Also, although we're addicted to screens, the typical number of
>>>> available displays for the Presentation API should remain pretty
>>>> small in most contexts. There may be more Things to choose from,
>>>> which might mean that the list could grow out of control. I suppose
>>>> that the user agent could be smart enough to group things together
>>>> but that would require additional logic on their side.
>>> [Louay] Yes this is a feature of the UA how to show the Things in the Dialog.
>>> E.g.
>>> the UA may offer groups and search field and also sort things
>>> according to user preferences or proximity.
>>>> 
>>>> Or it may be that the light example is not a very good one.
>>>> Requiring the user to select a light in a list just to be able to
>>>> switch it on or off may not lead to the best user experience. The
>>>> API may be much more useful to interact with more complex things:
>>>> the user won't have many of them and selecting only one will be the
>>>> default need. What do you
>>> think?
>>> [Louay] yes I agree if the user always needs to  select a Thing from
>>> the Dialog to interact with it is not a good user experience. This is
>>> why in my API proposal there is another function
>>> navigator.things.getById(id).then(...) which is relevant for things
>>> that are already selected by the user.
>>> This means the user needs to select a Thing from the dialog only once
>>> in most case. The dialog is needed to get access to NEW  things which
>>> are not available yet for the web page. The web page can use in
>>> addition the function
>>> thing.getReachability().then(function(reachability) {
>>>      handleReachabilityChange(reachability.value);
>>>      reachability.onchange = function() {
>>> handleReachabilityChange(this.value);}
>>> });
>>> to watch the reachability of a Thing. This is very similar to the
>>> getAvailability() function in the Presentation API.
>>>> 
>>>> Thanks,
>>>> Francois.
>>>> 
>>>> [1] https://w3c.github.io/sensors/
>>>> 
> 

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>