Re: WoT IG Teleconference Nov 16th, 2016

Maybe this is a question of terminology or perhaps it is deeper?

My personal view is that Thing descriptions are for use in service platforms. Such platforms include hubs in smart homes and offices, web browsers in smart phones and desktop computers, and server farms in the cloud. A hub could use a thing description for a highly constrained device as a means for knowing how to connect to that device on behalf of applications running in the hub. Standards for this would enable hubs to support IoT devices from a wide range of vendors and using a wide range of protocols. This would allow an open market of devices for use with smart home hubs.

I wouldn’t expect highly constrained devices to consume thing descriptions, nor to support the corresponding APIs. This leaves the question of where the thing description for such devices is obtained from. One idea is for the hub to ask a cloud based service for a thing description for the device after having discovered the device. The hub has drivers for common discovery protocols and communication technologies (Bluetooth, WiFi, …) and is able to use these protocols to identify the device and pass the associated details to the cloud in the request for a thing description. This may also involve installing a matching service that exposes the IoT device as a virtual device with common interfaces for easier control by applications.  These applications would then be able to interact with devices based upon a variety of platform, e.g. EchoNet, OCF or oneM2M.  Applications would be able to choose between a vendor specific thing description with a comprehensive set of features, or a generic thing description for the features in common across devices from different vendors.

I therefore believe that we need to look at how to apply thing descriptions to constrained devices, and to work on this in collaboration with the organisations responsible for the corresponding platforms. Our aim is to create an abstraction layer that enables an open market for services and service platforms. I expect a great future for services implemented with JavaScript and common Web protocols such as HTTP. This will greatly expand the market for IoT devices in the home and office, etc. and allow vendors to support common feature sets as well as to differentiate themselves. Service platforms at the network edge are likely to use a broad variety of standards and technologies, as defined by other standards organisations. 

Best regards,
    Dave


> On 24 Nov 2016, at 00:09, <kajimoto.kazuo@jp.panasonic.com> <kajimoto.kazuo@jp.panasonic.com> wrote:
> 
> Dear WoT-IG members,
> 
> 1 week ago, in IG teleconference, how to treat wide variety of device
> class, that is,  from less resources sensors to rich intelligent devices
> which can be web server by themselves.
> 
> At that time,  
>> Specific issues
>> Classification of devices is defined in IETF(answering Uday's question)  Proposal of introducing class concept in WoT.
>> In the architecture document, many implementation pattern is described depend on device class which has >constraint. Then each device ability is represented and declared in TD.
>> This issue is discussed in TD.(Kajimoto)  How to treat constraint device is discussed in e-mail first kicked by Kajimoto.
> 
> But unfortunately, I've not input, so yesterday's meeting the same issue 
> came up again in the scripting API context.
> 
> Honestly, I'm embarrassed on this classification issue.
> 
> In the WoT architecture document https://w3c.github.io/wot/architecture/wot-architecture.html,
> IG members discussion has reflected how to treat wide variety of devices.
> 
> I'm confused the scope of WoT standardization.
> 
> SDOs such as Echonet Consortium, OCF, oneM2M covers very wide variety of devices
> by introducing device class, device type...
> Because such SDOs treats not only virtual device in cyber space but communication to/from concrete device.
> 
> In WoT, we've discussed lo long time on the scope of standardization.
> Of course all of IG contributors are aware of there are wide variety of device class.
> But in cyber space which is Web technology's main stage, in spite of there are big difference
> of resource and abilities of devices, we could conclude common architecture.
> 
> Please guess the implementation of sensor's connection to internet.
> In order to access the sensor, some intelligent GW and/or cloud-based server which aggregates
> the access to/from sensors and play as cyber sensor on behalf of physical sensor.
> 
> On the other hand, Raspberry pie attached sensors, CHRIMEN, which has high speed CPU and
> Relatively rich memory spaces can provide direct internet connectivity and play as WoT Server by itself.
> 
> So, the variety of device class is reflected in implementation examples in architecture document.
> And the scope of WoT standardization is focused building blocks of WoT servient in cyber space.
> 
> IG guys, please consider this discussion history.
> 
> BR,
> 
> 
> -----Original Message-----
> From: Kajimoto Kazuo (梶本 一夫) 
> Sent: Wednesday, November 16, 2016 11:34 PM
> To: public-wot-ig@w3.org
> Subject: WoT IG Teleconference Nov 16th, 2016
> 
> Quick Updates
> Status of AC Review
>  Google negotiation reported by McCool.
>  Github pull request, proposed to be reviewed by members.
>  headlines are sent via e-mail
>  Next process treating Google and Mozilla, window is Wendy.
>  We should talk with W3C Management within 1 week.
>  Next week, finalizing pull requests on charter.
>  McCool send e-mail to Wendy tomorrow.
> 
> Communication with OCF, oneM2M, OPC
>  By next week, we fix the strategy of collaboration with SDOs.
> 
> WoT Logo
>  W3C branding policy does not allow current logo, so disappointed.
> 
> OCF Data Modeling [Michael Koster]
> Today, no presentation slides, this is postponed next week.
> Michael will prepare slides and will explain.
> 
> F2F Logistics [McCool]
> Venue candidate: Crowne plaza (USD30,000 on 4 days)  Open day is issue and discussed thru e-mails  Fujitsu will expertized on F2F (Kaz)  Samsung might be able to help to provide meeting rooms as 2nd option.(Michael)  Fujitsu also might be able to host as 3rd option. (Taki)
> 
> oneM2M LS update [Yongjing]
> Liaison with WoT is agreed in oneM2M.
> Semantics model reflection, protocol binding is discussed in oneM2M  (comment)Security is new topic and led by McCool.
> 
> Technical Work
> TD [Sebastian]
>  Today's meeting was cancelled.
>  Closing pull request but we need volunteer to update current practice document
>  Schedule: end of Nov. TD issues are fixed and finalized.
>  Try to finalize current practice until next f2f
> 
> Hydra [Victor]
>  Discussion has done.
>  Until next f2f, preparation of updated hydra related proposals.
>  So from next teleconference remove this topic.
>  Google, Mozilla : RDF is powerful
> 
> Scripting [Johannes]
>  We have Monday regular teleconference.
>  Zoltan proposed call back mechanism, discovery APIs and so on.
>  Browser venders like Google, Mozilla, some discussion on Scripting API from the view point of pre-processing is planned as next meeting.
>  Samsung and Huawei also has JavaScript engine. (Michael)
>  Samsung's joining is welcomed.
>  It is better Web servicer such as Amazon enrolled (McCool)
> 
> Security [McCool]
>  Restart security TF former led by Oliver.
>  Charter of security TF, we would like to define.
>  Everyone interested in is welcomed.
>  Huawei guy might help (Yongjing)
>  Some guy maybe from Alibaba  expressed on security at Beijing f2f.(Johannes) so access him (Yingin)
> 
> Agenda for Next WebConf
> AC Review
> OCF Data Modeling (Michael)
> Next f2f logi
> oneM2M (yongin)
> Technical Work
>  TD [Sebastian]
>  Scripting [Johannes]
>  Security [McCool]
> 
> Participants recruiting:
> within IG first by survey(?), next outside  communication group treats collaboration strategy, so communication group help recruiting
> 
> Specific issues
> Classification of devices is defined in IETF(answering Uday's question)  Proposal of introducing class concept in WoT.
> In the architecture document, many implementation pattern is described depend on device class which has constraint. Then each device ability is represented and declared in TD.
> This issue is discussed in TD.(Kajimoto)  How to treat constraint device is discussed in e-mail first kicked by Kajimoto.
> 
> 
> -----
> Kazuo Kajimoto
> Senior Councilor of Groupwide Software Strategy, Groupwide CTO Office, Panasonic Corporation
> 
> 
> 

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