W3C

- DRAFT -

SV_MEETING_TITLE

08 Aug 2019

Attendees

Present
Michael_McCool, Kenneth_Christiansen, Zoltan_Kis, Dan_Appelquist, Sebastian_Kaebisch, David_Baron, Matthias_Kovatsch, Kaz_Ashimura, Yves_Lafon
Regrets
Chair
SV_MEETING_CHAIR
Scribe
kaz

Contents


TAG review for WoT Thing Description

TAG review for WoT Architecture

da: clearer and simpler use case description for the explainer

db: making it understandable to those who don't have knowledge about WoT

mm: would add a one-pager to explain the simpler use cases
... but please note that WoT Thing Description is machine-readable data format
... applies many possible use cases
... we're not necessarily aiming completely automatic processing

kaz: agree we (WoT WG) should provide clearer/simpler use case description
... btw, there is another proposal for WoT guys to give a project review for W3C Team and Members
... I've talked about that idea to the WoT guys, and we're preparing for it
... providing that kind of resources/stories is important to let people understand WoT

db: regarding JSON-LD processing, you should be clear about how to process it

mk: we should elaborate how to process it
... there is some text already in the spec
... section on processing

db: suppose so
... but it's not clear for interoperability

Section 6. TD Representation Format

tk: in response to the comment
... there is an overview section within the WoT Architecture
... RDF and JSON-LD
... using JSON-LD makes the system more autonomous

mk: what is the core of the concern?

db: interoperability concern; maybe would work for some specific implementation but maybe not for another one
... what if you're looking at RDF version but somebody is looking at JSON version?

mm: compromise of JSON-LD vs JSON

da: not sounds like a requirement
... is that inline with the design goal?

sk: Thing Description is a data model
... relying on JSON-LD as a serialization format
... want to have information out of the document
... if you only rely on a JSON parser
... the information should be the same

mm: as Sebastian mentioned, the data model is the same

db: would elaborate the issue

sk: tx

mm: tx
... we (WoT WG) also will elaborate the use case description
... regarding the security review, we've done the self checks
... would know if it's enough

da: that's good
... the question is does that mean we can close the issue?
... major issue we should work on is Thing Description rather than the Architecture

mm: design decision section
... we would like to continue to work on
... and close the GitHub issue

tk: please note that we're working on the Binding Templates document which describe protocol bindings
... maybe there is confusion with that as well
... Binding Templates document itself will become a WG Note rather than part of the REC track spec

da: using fine language
... going back to the user needs
... what happens when
... how the functions come up to the end users
... maybe you think the TAG focus on browser-specific standards, and it might be fair
... however, you need to provide information for regular people
... how do you envision how Thing Description to be discovered, etc.
... all that kind of stuff

mm: we have a modular approach
... Architecture provides the whole picture
... each building block provides details

kaz: that's correct from the WoT viewpoint
... but as Dan mentioned, we should provide at least example use cases
... please note that we've already started to think about how to deal with discovery for the next charter period

mk: joint discussion with IETF as well
... note that there is a need for common platform
... based on modular approach
... so we need this kind of incremental approach

mm: we should make sure the issue on GitHub to be updated
... also use case description for the explainer
... any other comments/concers?

(none)

<inserted> kaz: before ending the call, I'd like to repeat we really appreciate your kind help from the TAG, Dan, David and all. Thank you!

[adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/08/08 17:07:33 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/JSON version/JSON version?/
Succeeded: s/db:/da:/
Succeeded: s|comments?|comments/concers?|
Succeeded: i/[adjourned]/kaz: before ending the call, I'd like to repeat we really appreciate your kind help from the TAG, Dan, David and all. Thank you!
Present: Michael_McCool Kenneth_Christiansen Zoltan_Kis Dan_Appelquist Sebastian_Kaebisch David_Baron Matthias_Kovatsch Kaz_Ashimura Yves_Lafon
No ScribeNick specified.  Guessing ScribeNick: kaz
Inferring Scribes: kaz

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]