See also: IRC log
<kaz> scribenick: victor
<kaz> Today's agenda
Sebastian: topics were 1. interaction with Alexa, 2. capabilities for semantic modeling, 3. observable properties
<kaz> TPAC agenda topics
<kaz>
[[
]]
Sebastian: does the group agree on the topics? Questions?
Kaz: PlugFest participants should think of how to expose the capabilities of their devices based on their PlugFest implementations
in particular, Japanese use Echonet, McCool OCF. What are the common capabilities?
Sebastian: I also first put in the list an item about a terms for protocol bindings. I removed it because the Protocol binding TF wanted to discuss this.
Michael_Koster: right. Nothing we would implement now, though.
Michael_McCool: you also mentioned capabilities. Any draft?
Koster: nothing yet, see later.
<kaz> Sebastian's slides
1. Alexa. Developers should know what to do before the event.
<kaz> (updated one to be shared later)
McCool: I have slides on this
<kaz> McCool's slides
an idea is to scan a Thing Directory for markup, and map TDs to Alexa "skill adapters" (e.g. a power controller)
is a JSON object
skill also include light control and streams (e.g. camera image stream)
door lock and thermostat
<kaz> https://developer.amazon.com/docs/smarthome/understand-the-smart-home-skill-api.html
the reason why I asked whether there is a draft for capabilities is that we should define these skills in RDF
Koster: capabilities are just pieces of TDs.
I haven't looked at streams yet. But streams are just objects, it should be possible to define actions/events on these objects
<kaz> https://developer.amazon.com/docs/device-apis/alexa-powercontroller.html
McCool: how to generate the payload to send to Alexa from a TD?
<kaz> https://developer.amazon.com/docs/device-apis/alexa-powerlevelcontroller.html
Koster: does Alexa map a message to a (vocal) command?
that is, does Alexa send messages to IoT devices in response to commands?
McCool: so it is basically a bridge between a user and the device. Similar to what a TD does
we should use built-in skills (home skills) and not custom skills (e.g. door lock vs. front door lock/back door lock). It's easier.
<McCool> https://developer.amazon.com/docs/device-apis/alexa-powerlevelcontroller.html
Darko: I've been working on capabilities (based on the previous PlugFest).
some are ready (e.g. thermostat)
the most common. You will be able to review them right after I commit.
we are reviewing OCF, Haystack, openT2T, SAREF, etc. We can review Alexa as well
McCool: ok, let's coordinate
Koster: the goal of iot.schema.org is to make two servients using each one of the frameworks above be interchangeable
McCool: one scenario I'm working on is "smart security", with a person recognition service
(to lock/unlock one's door)
Kaz: this discussion, more specifically Michael Koster's queston on mapping between messages and vocal commands, reminded me of a W3C recommandation about speech recognition semantics
<kaz> ... binding template might want to have that kind of capability to interact with Amazon Alexa at some point
<kaz> https://www.w3.org/TR/semantic-interpretation/
McCool: note on Amazon: security aspects in Alexa are well done, and also in AWS IoT. This was also a reason to look at it.
Kaz: yes, on the other hand, Amazon Alexa is an application Servient from the WoT viewpoint, so we might want to see the interface between Alexa and other Servients at some point
Sebastian: sync between Darko, McCool. We need a decision soon
<kaz> https://github.com/w3c/wot-thing-description/pull/54
Victor: made a PR to wot-thing-description
<kaz> [[
<td><code>observable</code></td><td>Boolean
value that indicates whether a remote servient can subscribe to
("observe") the Property, to receive change
notifications or periodic updates.</td>
]]
Sebastian: should be moved to the Current Practices doc
Victor: ok, I'll do this.
Sebastian: we also had 'stability' as a field.
<kaz> Current Practices (Dusseldorf version)
<kaz> 3.2.3.1 Property
but it was rarely used (if ever)
Sebastian: shall we discuss this field as well in a breakout?
<kaz> kaz: note during TPAC we don't have a breakout room, so we should assume all the sessions are plenary (at least at this moment)
Kaz: note that we don't have any breakout room at the TPAC
Koster: we also had a discussion about 'observable' in the Protocol Binding call.
Sebastian: as I said before, isn't this too soon?
Koster: we'll try to experiment with it at the PlugFest
next Wednesday, we'll have some draft.
(PB call deadline)
Darko: w.r.t. observable properties, what would be the difference with events?
Koster: the discussion last Wednesday was about events with/without state
an event is something that is not a Property state change
is an hypothesis at this point.
Kaz: where shall this discussion take place (TD, Protocol bindings)?
<kaz> Koster: maybe during the main meeting
<kaz> Kaz: that would make sense, I think
Sebastian: Protocol bindings. The TD should only reflect the decisions taken there
anyway, clear guidelines are needed.
Koster: at least, best practices.
McCool: some protocols are more event-oriented and speaking about states might seem confusing
Koster: You said Zigbee? It also is oriented towards state change.
Sebastian: new issue from Taki
<kaz> issue 56
are (should) the RDF files (be) normative?
Koster: is the TD RDF vocab constraining anything? If not, we maybe shouldn't standardize it?
Sebastian: no need to decied now. To discuss at the TPAC
<kaz> issue 53
second issue: docs for semantics in TD
idea of "integration level" of semantic annotations
third: stability. We discussed that today
<kaz> issue 29
<kaz> issue 16
TD serialization, nothing new?
Kaz: fiy, Dave recontacted Ben and I'll also follow that up
Sebastian can you ask him if he's going to the PlugFest?
<kaz> Kaz: will do
Daniel: is the new proposal for data types going to be implemented for the PlugFest?
<kaz> issue 14
S: yes
identical for most types
<kaz> Sebasitian's slides (see slide 3: Data Type (Prio 1))
<kaz> Koster's slides for the Binding call
Koster: I've started to use it. The change regarding name/value results in a more compact representation, a sort of emplatet
Victor: by the way, there is a PR pending
<kaz> issue 13
Victor: its outcome was the proposal for data types using Linked data
<kaz> Sebastian: will close that later
<kaz> issue 12
<kaz> Koster: Issue 12 is related to the issue on serialization
<kaz> Sebastian: maybe we should change the title of this issue
<kaz> issue 9
Sebastian: issue 9 is from Maria. Not put in practice by PlugFest participants, though
<kaz> issue 3
Darko: issue 3 is old. The discussion moved on to TF LD, right?
<kaz> https://w3c.github.io/wot-thing-description/#namespaces
Darko: I can put this on the agendo of TF LD
<kaz> issue 2
Sebastian: last issue about binary encodings. No news on it.
<scribe> new issue from Maxime
<kaz> Maxime's issue on the ML
context: one Property(, 1. data type), 2. serialization/media types
the question is whether we should have one data type def per media type or not
<kaz> Maxime's proposal to have discussion on Oct 20
Maxime is not here today, we'll postpone the discussion for next week
<kaz> PR 55
There is also a PR from Maria, which actually depends on the discussion initiated by Maxime
<kaz> [adjourned]