- From: Francois Daoust <fd@w3.org>
- Date: Mon, 27 Jun 2016 12:42:22 +0200
- To: Scott Jenson <scottj@google.com>, Dave Raggett <dsr@w3.org>
- Cc: 전종홍 <hollobit@etri.re.kr>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Hi Scott, all, Le 22/06/2016 16:21, Scott Jenson a écrit : > On Mon, Jun 20, 2016 at 12:04 PM, Dave Raggett <dsr@w3.org > <mailto:dsr@w3.org>> wrote: > > I very much agree with what you say. Is this something that you can > help to realize? It would be great to have Google involved. Do you > have any comments on the new Web of Things Interest Group Charter > [1] currently undergoing W3C AC Review, and the early draft charter > for a Web of Things Working Group [2]? The Interest Group could > study ways to support versioning, and if there is sufficient > consensus, this could be standardized in the Working Group. What > suggestions do you have in respect to standardizing the > device/service models for specific domains such as smart homes? > > > I'm happy to help as I can, but as there are multiple teams at Google > working on various IoT projects and I can't speak for them. I will > suggest, however, that one of the key groups contact you. Is someone > from Apple already on this list and participating? > > As to standardizing on the device/service model, it usually helps to do > a quick survey of what existing models are already out there. In > addition to HomeKit, can anyone else suggest any other projects? It > seems reasonable to start with these existing models, find a resonable > subset for "Version 1" and then allow the differences to be expressed > using the 'optional' mechanism. Subsequent standards work would then try > to move the optional pieces into the required. Most Home Automation Systems provide a similar Home-like user interface that lets the user discover and interact with nearby devices/services. I had a quick look at the following projects to see which device categories or service characteristics they support: - Amazon Alexa: https://www.amazon.com/smarthome-home-automation/b?ie=UTF8&node=6563140011 - Apple HomeKit: https://developer.apple.com/homekit/ - Crestron: http://www.crestron.com - Google Nest: https://nest.com - HomeSeer: http://homeseer.com - Insteon: http://www.insteon.com - LG HomeChat: http://www.lghomechat.com - Samsung SmartThings: https://www.smartthings.com - Wink: http://www.wink.com Some of them, such as Apple HomeKit, LG HomeChat or Google Nest seem to restrict support to a few device categories. Targeted categories are not the same in each case. For instance, LG HomeChat focuses on large home appliances, while others focus on smaller appliances. However, it may be possible to view a large appliance as a group of more atomic devices (e.g. a refrigerator might be viewed as a light, thermostat, door, and fan). Other systems, such as Crestron, HomeSeer or Insteon, tend to be generic all-purpose home automation systems and by definition try to support a large number of device categories. That said, their Web sites usually feature similar restricted sets of device categories. Roughly speaking, trying to take a stab at a possible subset, the following device categories are prominently highlighted in most systems: - Lighting - Thermostats / Weather systems - Outlets - Doors (door status, door locks, garage doors) - Shades - Cameras (security cameras, front-door camera) Looking at it more in terms of exposed characteristics than in terms of device categories: - Brightness - Door state - Temperature - Pressure - Lock state - Power state Also, all of these systems incorporate some sort of grouping mechanism (zones, rooms, scenes, etc.). There are of course many more projects that may be worth looking at. This is by no means meant to be exhaustive... and may not even be correct, so feel free to chime in! This is also obviously restricted to the home scenario, where e.g. geolocation does not really play a role. Perhaps not surprisingly, these categories and characteristics seem to match the examples that I often see mentioned in this WoT IG. Taking this back to a discussion on standardization, I note that the current proposed draft charter [1] for a possible Working Group focuses on creating a Web-based abstraction layer but leaves concrete instantiations of that layer out of scope. The abstraction layer is a means to an end. I wonder if leaving the end out of scope is a good idea. Other device-focused working groups at W3C are typically chartered to work on exposing a particular set of functionalities: - The Device and Sensors WG develops 6 concrete APIs (e.g. Battery Status, Wake Lock, Proximity, Ambient Light): http://www.w3.org/2016/03/device-sensors-wg-charter.html - The Second Screen WG only deals with second screens: http://www.w3.org/2014/secondscreen/charter.html - The TV Control WG only deals with tuners: http://www.w3.org/2016/03/tvcontrol.html - The Automotive WG is more generic in scope, but builds upon a previously agreed set of Vehicle Data interfaces: https://w3c.github.io/automotive/vehicle_data/data_spec.html These WG sometimes develop a generic "platform" or "framework" to ease their work: - The Generic Sensor API: https://w3c.github.io/sensors/ - The Vehicle Information Access API: https://w3c.github.io/automotive/vehicle_data/data_spec.html ... but they also specify the "end", meaning the concrete specifications that make use of that platform. I believe that it would be useful to scope a possible Working Group to an initial set of concrete device categories as well. Could the above list provide a useful starting point? Thanks, Francois. [1] https://w3c.github.io/wot/charters/wot-wg-2016.html
Received on Monday, 27 June 2016 10:42:57 UTC