See also: IRC log
<trackbot> Date: 03 June 2015
<scribe> scribenick: dsr
Soumya introduces the agenda.
The discovery TF wiki https://www.w3.org/WoT/IG/wiki/Discovery_TF
Louay: we should cover local network discovery
Another term is a registry where you can look up things that have previiously been registered.
Soumya: yes, we should cover resource directories.
Dave: We should generalise “Physical Web” to Bluetooth based discovery, Beacons, NFC, Barcodes with Googles Physical Web as one of these.
Soumya: let’s discuss use cases for discovery
I’ve volunteered to provide a use case on remote health.
Eduardo has volunteered on community based flood monitoring.
Dan has another use case, but can’t quite remember the details.
See: https://www.w3.org/WoT/IG/wiki/Use_case_contributions
Louay: I am taking over from Robert Kleinfeld who has now left FOKUS.
Soumya asks Dave and Louay to prepare to discuss how discovery fits into their use cases.
Soumya: I’ve looked at the use case from Claes. This involves a wristband talking to a smart phone which in turn talks to the cloud
The wristband is discovered during installation via BLE binding to the phone, and the phone needs to register the service in the cloud.
Dave: there are a broad range of BLE profiles for wearables and other devices.
Louay: Apple’s HomeKit is very similar, and they recommend using BLE and the Apple TV as a bridge to the cloud.
Soumya: does the cloud have to trigger discovery, or is it initiated from the client? It could be either.
Louay: the user normally has to initiate the process of registration, and we need to define a lifecycle for discovery.
Soumya: what happens when you remove the wristband at the end of the day, how quickly should the cloud discover this?
Louay: if the device is already connected, it can signal this change in status
We need to define the expectations for the communication frequency
Dave talks through details of BLE binding as a way of grounding the discussion
Soumya: the next use case is home automation from Takuki Kamiya
see https://lists.w3.org/Archives/Public/public-wot-ig/2015Mar/0048.html
Soumya: he says: Each device and sensor connects to home gateway through
various technologies (e.g. Wi-Fi, Bluetooth, ZigBee, etc.).
For this case, we would have proxies in the home gateway that handle each technology
Louay: application perspective for discovery doesn’t care about the IoT technology
We have discovery then binding, but binding is out of scope for this task force. We certainly need some gateways/drivers for specific technologies
These need to be modular for extensibility
Perhaps we shouldn’t use the term proxy here as it has another sense in the web of things framework
Dave: drivers is perhaps a better term
Soumya: the IoT technology should be visible in the metadata
Louay: we can have an abstract interface that generalises over IoT technologies, and perhaps is more oriented around the kind of sensor or reading and independent of the IoT technologies used to connect to the sensor.
There may be additional data is needed to support dthat iscovery at the lower layer to address specific IoT technologies.
Soumya shows a slide for the ETSI based IoT architecture he has implemented.
I used IoT technology specific data locally within the gateway, but not at the application layer
Dave: this is about the abstraction layers and how they relate to discovery
Soumya: let’s now discuss scopes and dimensions of discovery
Louay: we should allow for local and remote discovery, and allow applications to combine this using the same interface
Dave: there may be ways to using delegation models for discovery where one agent consults another
Soumya: what about the dimensions, I currently list context, location?
Dave: another dimension is human, who owns what
There needs to be access control around this
Dave: human constructs such as your home, your office, your friends
Soumya: I had a brief chat with Oliver who leads the security & privacy task force, and we plan joint discussions, likewise for the thing description TF
When it comes to collaborative editing of the document what do you suggest? I understand that we can’t use gdocs.
Louay: maybe GitHub, issue tracking and pull requests, which works quite well if you have an editor in charge
Dave: I would support this and suggest initial discussion by email on the outline structure
Louay: markdown would be a simple choice for the GitHub document
<Louay> Example from other WG: https://github.com/w3c/presentation-api/blob/gh-pages/uc-req.md
It also integrate well with GitHub processes
Soumya: any other suggestions for the next call? [no]
… end of meeting
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Louay/Soumya/ Succeeded: s/is/that is/ Succeeded: s/ ot/ to/ Found ScribeNick: dsr Inferring Scribes: dsr Present: Soumya Louay Dave Found Date: 03 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/03-wot-di-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]