See also: IRC log
<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
<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
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
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 ]