- From: Francois Daoust <fd@w3.org>
- Date: Thu, 24 Sep 2015 17:00:20 +0200
- To: <public-wot-ig@w3.org>
Hi all,
The minutes of today's WoT Discovery task force are available at:
http://www.w3.org/2015/09/24-wot-di-minutes.html
... and copied as raw text below.
Thanks,
Francois.
-----
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/0056.html
See also: [3]IRC log
[3] http://www.w3.org/2015/09/24-wot-di-irc
Attendees
Present
Dave, Louay, Soumya, Francois, Ari, Claes, Arne,
Johannes, Yingying, J_Lynn
Regrets
Chair
Soumya
Scribe
Francois
Contents
* [4]Topics
1. [5]Thing API proposal from Louay
2. [6]Semantic-based discovery (Dave)
3. [7]Discussion on Requirements
4. [8]Kick start the discussion on provisioning
5. [9]Proposal for WoT WG
__________________________________________________________
Soumya introduces the agenda, Dave to present notes on semantic
web discovery after Louay's presentation
Thing API proposal from Louay
<dsr>
[10]https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/
att-0057/2015-09-204-Thing-API-Proposal-Fraunhofer-FOKUS.PDF
[10] 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.
-> [11]Louay's slides (PDF)
[11] https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/att-0057/2015-09-204-Thing-API-Proposal-Fraunhofer-FOKUS.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]
Received on Thursday, 24 September 2015 15:00:32 UTC