Web of Things Interest Group - Discovery Task Force Teleconference

Soumya introduces the agenda, Dave to present notes on semantic web discovery after Louay's presentation

Thing API proposal from Louay

<dsr> https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/att-0057/2015-09-204-Thing-API-Proposal-Fraunhofer-FOKUS.PDF

Louay: Proposal for a Thing API for the browser. Some of the concepts are taken from the work I'm doing on the Presentation API, so I'd like to start with an intro of that API.

-> Louay's slides (PDF)

Louay: Some ideas and requirements on the API. One important question is whether we need such an API. I think we need it for the Browser but we can discuss this later on.
... The API should abstract from the underlying protocols and re-uses the concepts discussed in the Thing Description task force.
... In the Presentation API, we are considering displays (e.g. TV) but here we are considering things. In the end, we want to discover devices and interact with them.
... Some background on the Presentation API: Community Group proposed in September 2013 by Intel with active participation by Google, Mozilla, Fraunhofer FOKUS, Netflix, etc. Final report published in 2014 was used to create a Second Screen Working Group.
... According to the charter, final date for the Presentation API should be mid-2016.
... In the Presentation API, you have a control page and a display which may be a TV, a Chromecat, etc.
... The control page creates a PresentationRequest, passing the URL it wants to display on the second screen. Calling starts will end up with a session that gives you the ability to send and listen to messages to and from the second screen.
... One important point is that, upon call to start, the user agent will display a native dialog that will display the list of devices that are available, so that the user can pick up one device in the list.
... Once the user has selected a display, the URL is loaded on that device and the communication channel established.
... This is important because it forces a user interaction each time the API is used. The user agent could propose to save user preferences for later but the default is to ping the user with a selection list.
... In the future, we will have dedicated APIs to support presentation of audio, video and so on (on top of HTML content)
... We will have issues on interoperability between devices and user agents because the API is agnostic of the underlying protocols (on-going discussions in the Second Screen WG).
... Fraunhofer FOKUS implemented the API on top of various protocols in a Cordova plugin (for an earlier version of the API but the functionality is still the same). Some of the code is open-source.
... Different presentations from the WG participants were presented during the 5th Web Media Symposium in Berlin this summer.
... Now back to the Thing API proposal
... First of all, I propose to have a namespace such as navigator.thing or navigator.things
... Then to define a ThingRequest that is similar to the Presentation API's PresentationRequest object.
... The app can then call "start" on that ThingRequest object which will prompt the user to select a Thing in the list of things discovered by the user agent.
... The dialog may not be needed if user already gave her permission, or perhaps if the Web app has access to the ID of the Thing.
... The Thing object returned encapsulates all the functionality needed to interact with the actual thing.
... In the end, discovery is done by the user agent and not exposed to the Web app, as in the Presentation API.
... The Thing object exposes properties, actions and events. All names presented in the slide are taken from the Thing Description work.
... I can imagine ways to determine whether the thing is still available and monitor that availability.
... The slides contain a few code examples.
... I am now working on a Cordova plugin that implements this approach. On iOS, we're accessing Homekit accessories, so I will have access to them.
... The Web application will not get any information on the kind of accessory. It's hidden inside of the Cordova platform.
... I will show this demo in TPAC. I will bring a few accessories (e.g. temperature, switch).
... I think there is some on-going work on a Generic Sensor API that could be relevant to this proposal.
... Of course, we need community support to work on this API, refine use cases and requirements.

Dave: Given the different approaches of handling asynchronous calls, do you think we can define only one API as it may be Promise in JS or callbacks in other languages?

Louay: This is really an API to give access to Web applications. You still need the other protocols like CoAP and so on to talk to the Thing.

Dave: So the proposal is to define a JavaScript API for the browser?

Louay: Yes, although this API could be used in other environments such as Node.js.
... But we need to look at places that require user interaction since these environments would not allow this.

Dave: I also prototyped in Node.js. Using JavaScript dynamic nature, using getters and setters felt more natural, although it has disadvantages.
... Allows to put properties directly as properties, although the async nature requires something like events

Louay: I don't know how to specify it in a specification if we go down that road.

Dave: I agree that everything is async. One may not need to expose that directly to the Web app if the server handles things under the scenes.
... It may be more related to the Thing Discovery task force, so perhaps we should discuss that in that task force instead.

Johannes: Agree we should not hijack the Discovery call for this.
... Does this API cover the possibility to discovery things in a directory?

Louay: No. This API only covers discovering things that can be discovered by the user agent.
... Otherwise, you may use something like WebSockets to interact with a server-based directory and talk to thing through a relevant gateway.
... Here, the goal is to get access to things that are not part of a directory.
... For instance, I have a device that is only available through Bluetooth LE discovery, this API allows to interact with it.
... This API addresses privacy and security issues, since the user gets to approve the interaction with the thing with a dialog that she understands (a list of things).

Johannes: I understand, thank you.

Soumya: The Thing API is mostly for discovery, right? And yet you say that you can control the thing afterwards. Could the API be used for thing management as well?

Louay: The API is not only about discovery. It's about discovery and communication. I find it hard to separate the two. From a Web application perspective, the API is more or less complete to discover and get access to things.
... The user agent will look for the things internally, discovery is hidden to the Web. The communication then happens by the exposed Thing API.
... You cannot use Bluetooth LE from your Web app to control a Thing. This API hides the protocol, allowing the user agent to use Bluetooth LE under the hoods to interact with the Thing.
... This is a very similar approach to the Presentation API where we do not want different APIs for Google Cast, WebSocket, WebRTC, etc.
... In the end, it depends on what the user agent implements.

Soumya: OK, I have a couple of action items for you that I will send over to update the Wiki. Thank you very much for the presentation!

Semantic-based discovery (Dave)

Dave: Essentially, there's informal and formal semantics.
... In formal semantics, things are described by some ontology. You can talk about where the thing is located.
... You end up with a formal mechanism to search for things that match a specific set of constraints.
... There are available query languages, such as SPARQL.
... Another approach is not to rely on formal semantics but to make an informal crowd-based mechanism.
... This is what you can do for pictures for instance.
... In one of our F2F, someone suggested folksonomy.
... When you do a query, do you want to get back the best one (perhaps ranked by some search engine) or do you want it to return back to you some set of matches that your local agent could filter?

Soumya: I am working on such a search prototype. I am creating an index from properties stored in a database. I should be able to show it at TPAC.

Dave: Binding formal semantics with social networks would be interesting so that you can talk about devices of a given person.

Soumya: What I propose is to drop a small summary of the discussion on the mailing-list for inclusion in the Wiki and then see what agenda item could be worthwhile for next call.

Dave: More and more people are realizing that semantics are key to WoT.

Soumya: Exactly. [missed name of project]. I'll send that over..

Dave: I've been invited to the ETSI M2M december workshop, so will be there.

Discussion on Requirements

Soumya: I gathered different requirements. What is pending is to agree on them.
... When we have this type of requirements, we need to liaise with the other task forces.
... Starting with the first one "Discovery should be independent of the communication technologies used by the physical things"
... Any comment on this requirement?

[none heard]

Soumya: OK, so we'll say that this fine.
... Next one: "The communication technology used by the thing should be visible in the metadata to later ease the binding to that technology".
... Johannes, could we add this to the WoT-AP agenda?

Johannes: Yes, I think we can.

Soumya: OK. Any comment on the second requirement?

Ari: Sorry, I had trouble unmuting myself but have a comment on the first one. What does "smart agnt in the middle" mean?

Soumya: To provide access to a Thing that is using some discovery mechanism, there needs to be some smart agent that implements all the discovery mechanisms for you.
... We do not forbid situations where there are no smart agents. These are just ways to handle this scenario.

Ari: OK, makes sense. Thanks.

Soumya: For the third one "The things should be capable to automatically register themselves to the central registry for the discovery process".
... For this, we need interaction with the thing discovery task force.

Arne: What is the purpose of these requirements? What do we do with them?

Soumya: There are to serve as fundamental step stones to build our discovery module.
... The central registry is not a requirement per se. There are things such as Google's Physical Web where there is no central registry but rather a directory.

Johannes: Could you make an example about what you mean by "automatically"? Would the thing need to discover where the central registry is?

Soumya: If you remember my presentation for OneM2M, there is a bootstrap phase. Where do I register? You get back an entry-point to the central registry. This is one way. The central registry could also be hardcoded in the device.

Dave: Some of the words like "should", "automatically" and "register", I'm not sure I agree with in all cases.
... There may be cases where you do not need a "central" registry.
... It might be that you need a "may" here instead. Or it may be that the registry needs to discover the thing, not the thing actually registering that thing.

Soumya: Right, legacy devices won't be able to do that, but smart things will know how to do that.

Dave: Maybe. I'm not convinced. Actually, there may be cases where the smart thing should not know about registry.

Soumya: I am working on a demo so maybe I can show that in next call.

Dave: OK, I don't know how this requirement should be phrased but I think it should not be as it is.

Johannes: "if you have a registry, then it should be possible to register a thing there without human interaction". Would that be a good way to rephrase that requirement?

Soumya: Hmm, I will have another look at this requirement and get back with proposals.
... Moving on with discussion on the notion of central registry. I'll merge that point with the point we just discussed.
... Another point is about the "lifetime" attribute for which we need a use case.
... Is there such a use case? A lifetime during which the thing is discoverable? This might relate to privacy but I'm not sure.

Ari: Of course, many technologies such as Bluetooth have a duration during which devices are discoverable. Exposing that semantic could be useful.

Soumya: OK. About the ability to enable both local and remote discovery depending on the context and use case.
... We did not have much discussion about where this requirement should go.

Arne: Could you elaborate on local vs. remote? Geographically? On a network, that does not play a role.
... Examples: local would be within your home, remote would be in a city environment.

Dave: The wording could be adjusted by using "physically local" to clarify what we mean.
... When you try to discover something, it's for a purpose usually. Depending on the context, you'll get different answers.

Soumya: Do you think this needs rephrasing?

Dave: Maybe there's just a need for a little bit more of context.

Soumya: OK.
... Any comment on the last two points?

Dave: Again, it all depends. There are persons who want to track activity and then there is the problem with attackers.

Soumya: the last one could thus be optional.

Dave: Here as well, it makes sense to add some intro paragraph.

Soumya: Understood. Moving on in the interest of time.
... Putting out to the wider audience, the Discovery Tech Landscape was updated to evaluate against the 5 aspects listed in this slide: "Interaction patter", "support of higher layer discover concept", "bootstrapping", "lifetime/sleepy nodes", "S&P".

Dave: It seems reasonable at first glance.

Johannes: One thing that seems to be missing: maximum range?

Soumya: Right.

Dave: The richness of the query mechanism and ranking seem to be missing as well.
... You may want to search for nearby printers or nearby printers that support color.

Soumya: It could be client-side or done by the search engine.

Dave: Right, but it comes back down to the richness of the means to exposing the criteria for discovery.

Soumya: OK. Anything else?

Johannes: I also agree that the richness is important for the evaluation of these technologies.

Soumya: OK.

Kick start the discussion on provisioning

Soumya: Skipping the next topic in the absence of Oliver. For provisioning, one possible candidate that we have is Open Mobile Alliance Lightweight M2M Technical Specification. Dave, this may be good to reach out to them, to have a presentation from them in the future.
... I think it can serve as a good candidate for provisioning.
... 4 different operations: bootstrap, client registration, device management, and information reporting
... No human interaction, exchanges over CoAP, very simple architecture.

[Soumya quickly goes through LwM2M spec]

Soumya: I need to do a thorough analysis on how much of it is directly relevant.

Dave: I guess we could have a look at some existing IoT devices. What do you get when you unwrap your Nest box?
... There are probably many other mechanisms.

Proposal for WoT WG

Soumya: Very little time left to discuss this. I will send a proposal I wrote around to the mailing-list.
... To be discussed in the call for the entire group. Please send comments quickly.

Arne: The discussion on requirements was lively. Is the latest version?

Soumya: I took some notes. I'll update the requirements based on them and will update the wiki so that we can continue the discussion.

[call adjourned]