13 Oct 2017


See also: IRC log


Kaz_Ashimura, Darko_Anicic, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Takeshi_Yamada, Victor_Charpenay, Taki_Kamiya, Masato_Ohura, Ryuichi_Matsukura, Tomoaki_Mizushima, Daniel_Peintner, Amelie_Gyrard


<kaz> scribenick: victor

Agenda for today

<kaz> Today's agenda

Sebastian: topics were 1. interaction with Alexa, 2. capabilities for semantic modeling, 3. observable properties

TD breakout topics

<kaz> TPAC agenda topics



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.

TD for PlugFest

<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

Pull request on observable properties

<kaz> https://github.com/w3c/wot-thing-description/pull/54

<kaz> https://github.com/w3c/wot-thing-description/pull/54/commits/9b0e1978c939ea5c98ee5339467a4901cca7c72a

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 (&quot;observe&quot;) 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> 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.

New vocabulary for Protocol Bindings

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.

open issues and current discussions

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]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/10/13 09:09:45 $