<mkvoatsc> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Agenda

<kaz> scribenick: uday

Matthias: discusses agenda

<mkvoatsc> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#23_Aug_2017

FPWDs

<kaz> editors call minutes (member-only)

Kaz: briefs editors call, schedule&issues discussed,
... target doc- architecture and TD

Matthias: one issue about architecture doc structure discussed

<mkvoatsc> https://github.com/w3c/wot-architecture/issues/27

<mkvoatsc> Terminology: https://github.com/w3c/wot-architecture/blob/master/terminology.md

Kajimoto-san: terminology discussion of architecture doc

Matthias: will go ahead with agreed structure and then Kajimoto-san to further work on it
... group can comment using pull requests

McCool: will close the MD version by Moday 28.08

Taki: will work on TD pull requests-data type change for august 30th review

McCool: to add few issues in TD repo

Matthias: briefs scripting doc work

Koster: to work on PB basic doc by 30.08

Matthias: release candidates by 30.08 followed by group review, final consensus on 06.09 and then final publication

clarifying capabilities

Koster: iotschema.org capabilities
... capabilities are actions, events and properties of a single function of a thing

e.g: on/off switch

capabilities can be composed together to define the whole thing

capability can be a separate schema/definition

can be implemented as individual instances

can themselves be semantic descriptors?

<McCool> question - can a proposed definition of "Capability" be given that can be included in the terminology listing (tentatively... we may not want to include it in the FPWD)

Koster:

McCool: can be sub-things, or one array of intereactions
... can capability also be a link?

Koster: too restrictive to have all semantic definitions at top level
... could put links on capabilities

McCool: maybe as optional

Matthias: see two aspects- 1) capabilities can group multiple interactions together, 2) how do we link interactions to capabilities,where are the names of ineractions

Koster: refers to schema.org example

Matthias: does a capability prescribe what interaction to access

Koster: we don't want to limit any of that, what should be required? something minimum for interoperability

<inserted> scribenick: uday_

Matthias: iot.schema.org might trail WoT TD

McCool: iot.schema.org is going one level up, could have a capability with zigbee style but have a concrete definition at some level

Koster: tradeoff of interoperability Vs not being able to implement too specific things

<kaz> Kaz: we just have 8 more minutes

<kaz> ... so should record the possible need for 2 layers of abstraction

<kaz> ... and go ahead for other agenda topics

<kaz> ... (esp. TPAC logistics)

Victor: iot.schema.org not only defines capabilities but also interactions
... can use interaction patterns individually with their own TDs

still a need for unified vocabulary

<kaz> [ Kaz would like to note we have to let all know about the TPAC update. ]

Zoltan: capabilities are informative, need some capability negotiation

Matthias: feel this could be counter productive to TD idea

Darko: example with TD and TD+capability should help to discuss

<inserted> matthias: would be happy if there are concrete examples

TPAC plugfest

Matthias: Fujitsu offered plugfest in sunnyvale

<kaz> McCool: Kaz will put the coordinate on the wiki

<kaz> Taki: fine

<kaz> Kaz: will put the info on the wiki then
... please note that we need to clean up the room and leave the room by 6pm on Sunday

<kaz> [ adjourned ]