<trackbot> Date: 03 June 2015

<scribe> scribenick: dsr

Discovery Task Force meeting

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.