<scribe> scribenick: dsr

Soumy introduces the agenda for today’s call

Edoardo presents on his ideas for requirements for discovery

Oxford flood monitoring project based upon IoT sensors, and tools for analysys and visualisation.

The sensors need to be able to register themselves and to discover metadata such as who their owner is

There is a low power radio link from sensors to gateways as well as a peer to peer mechanism

The sensor needs to disover where to send its data

along with how frequently

The metadata is maintained in the cloud, and hence the sensor/gateway have to find that from the cloud

Soumya: do you think there is a need to combine registration within the discovery framework?

Edoardo: there are a lot of links between security, discovery and registration.

I will now turn to the application perspective. Here we have maps and external data sources and can use this with the sensor data for visualisation and analytics

Given some information about geographical features, can we find external data from the Web?

One aspect of course is the location, another is quality of data and whether particular readings match the desired quality including the timeliness.

We also want to find devices that are relevant to a particular geographical feature such as a river.

It is thus interesting to explore information in terms of a given context

Trust is another factor than can be useful in discovery.

Another piece of context is whether a given waterway is accessible.

I hope this provide a useful input to the task force

Soumya asks Edoardo to summarise his points for use on the wiki.

Soumya displays the table of use cases, and asks for volunteers to talk about the discovery implications for each one

Dave briefly summarises for the smart washing machine - either the device directly registers with a cloud service, or the home hub discovers the washing machine and searchs for suitable drivers.

Soumya: let’s move on to discussing the lifecycle

In the previous call we chatted about the scenario where someone removes a wristband and asked the question how long does it take for the cloud service to be aware of this. From that we opened up the general topic of lifecycle in the context of the discovery framework.

Dave presents some ideas about the use of context events, monitoring mechanisms, and the means to interpolate measurements when a sensor is missing from a mesh

Eoardo: some systems provide a heartbeat that indicates liveness of the sensor.

Danh: heartbeat is one mechanism, another is streaming of continuous data

discovery can be static based upon static metadata, the other is based upon dynamic info

Johannes: for long lived battery operated devices, these are only active every now and then, so it may be possible to monitor that as a sign of liveness

Dave: keep alive mechanisms at the transport layer for keeping firewall traversal sessions alive and may be used to indicate a measure of liveness at the abstraction layers above

Johannes: some protocols have something like this and could be so used
... as Dave raised the question of firewalls, we have a distinction between local area and wide area presence

Soumya: let’s now turn to potential building blocks for discovery

We definitely need a module for managing registration of devices, either in a hub or in the cloud

What else can we envisage? One instance is a search engine

Let’s go around the table to sample everyone’s ideas

Edoardo: does this include lifecycle

Soumya: yes it could

Soumya asks if Edoardo has any comments on discovery building blocks?

<Edoardo_Pignotti_> My WebEx stalled

Dave: one way is for the things acting as agents to make use of platform specific discovery mechanisms

Johannes mentions a number of decentralised discovery mechanisms

e.g. bluetooth beacons, NFC, barcodes …

Soumya asks if Johannes could prepare a presentation on peer to peer based discovery?

Johannes: we could get back to Scott Jansen (Google) to talk about his work on the physical web as a basis for discovery

Soumya: could you contact him about that?

Johannes: yes

Arne: CoAP supports multicast based discovery (as an alternative to mDSN and SDP)

You can imagine search engines like Google which allow informal queries, or you could have more formal search interfaces

Arne asks what the plans are for collecting our thoughts in a report

Soumya: in the last meeting we decided to set up a draft report in GitHub for us to collaborate on via the issue tracking mechanism

Johannes points to https://github.com/w3c/wot/tree/master/TF-DI

Danh: you can ask gateways what sensors are connected right now, or you can query the log for historical record

what are our requirements here?

Soumya asks Danh if he could prepare a presentation about the context related info that discovery needs to expose

Danh: in our use case, we expose the sensor data, but not the devices themselves

I could talk more about this next week

I would like to understand how discovery relates to the overall architecture

Soumya: yes indeed, for instance is discovery hidden from users or not
... we should start using the issue tracker for the Github report for this task force (see link above)

Edoardo: peer discovery could be an interesting building block, and context is another.

Johannes: in the APIs and protocols TF call, the issue of legacy devices was raised. Here a registry could be valuable for retrieving suitable drivers for such devices

We need to discuss how the requisite info to enable this is discovered and along with the requirements for registries of device drivers

Soumya: I’ve done some work on that.

Dave: we also need to address discovery in the sense of when things are compatible or safe to use - this is part of provisioning

Soumya: let’s pick up on that in a future call

any other comments? [no]

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/ideas …/ ideas about the use of context events, monitoring mechanisms, and the means to interpolate measurements when a sensor is missing from a mesh/
Succeeded: s/layer may/layer for keeping firewall traversal sessions alive and may/
Found ScribeNick: dsr
Inferring Scribes: dsr

WARNING: No "Topic:" lines found.

Present: Soumya Edoardo_Pignotti DanhLePhuoc Dave Ashok Arne Danh Edoardo Hamid Kathy Johannes
Got date from IRC log name: 10 Jun 2015
Guessing minutes URL: http://www.w3.org/2015/06/10-wot-di-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report