See also: IRC log
Soumya introduces the agenda, Dave to present notes on semantic web discovery after Louay's presentation
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!
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.
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.
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.
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]