- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 02 Mar 2020 10:17:11 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/02/21-wot-td-minutes.html
also as text below.
Thanks a lot for taking the notes, Zoltan, Mizushima-san and Taki!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-WG - TD-TF
21 Feb 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Daniel_Peintner, Michael_Koster,
Sebastian_Kaebisch, Taki_Kamiya, Zoltan_Kis
Regrets
Chair
Sebastian
Scribe
Zoltan, Mizushima, Kaz, Taki
Contents
* [3]Topics
1. [4]Approving past minutes
2. [5]Virtual F2F meeting
3. [6]Github repository
4. [7]IANA media type
5. [8]PRs
6. [9]Issue discussion
7. [10]Payload Template
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<zkis> scribe: zkis
Approving past minutes
<kaz> [13]https://www.w3.org/2020/02/14-wot-td-minutes.html
[13] https://www.w3.org/2020/02/14-wot-td-minutes.html
Sebastian: Couldn't join the previous call, so Taki please go
through the minutes
Taki: PRs, Issues. Ege discussed some of interaction aspects in
the Architecture call as well.
... also discussed Bindings, on what clarifications we need for
next version.
Sebastian: any comments on the past minutes? If not, ask Kaz to
publish
... minutes approved
Virtual F2F meeting
Sebastian: there is already a time slot
[14]Online f2f wiki
[14] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_16-19_March_2020,_Online
Sebastian: please fill the questionnaire
... vote on the session you'd like to join
... would you like to collect topics we should discuss on the
F2F
... I propose discussing on TD templates
... what do you think we should discuss
Zoltan: there are issues marked for next version
Daniel: eventing
... more efficient formats for TDs
Zoltan: yes, the github issues
Sebastian: we should prioritize the issues and pick a few
Github repository
Sebastian: should we go to a new fresh repo?
... this is not typical
... usually done when a major change happens, like TD 2.0
Kaz: there are examples for separate repositories for major
changes
... or we could use the current repo with specific tags
Daniel: much easier to keep one repository, everyone already
knows it
... we could use branches
... one entry point
Sebastian: what JSON-LD did?
Kaz: they use a new repo for JSON-LD 1.1
Daniel: not sure about the old, but the new repo doesn't have a
number on it
[15]JSON-LD 1.1
[15] https://w3c.github.io/json-ld-syntax/
[16]JSON-LD 1.1 Framing
[16] https://github.com/w3c/json-ld-framing
[17]JSON-LD 1.1 Processing Algorithms and API
[17] https://github.com/w3c/json-ld-api/
Kaz: can talk with Ivan Herman and the JSON-LD Chairs about
their general policy
<kaz> ACTION: kaz to ask JSON-LD WG guys about their GH repo
management policy
Zoltan: FWIW I would also think a single repo is better and use
tags and branches
IANA media type
Sebastian: now we have application/td+json IANA media type
<mjkoster>
[18]https://www.iana.org/assignments/core-parameters/core-param
eters.xhtml
[18] https://www.iana.org/assignments/core-parameters/core-parameters.xhtml
Sebastian: there is also CoAP
Kaz: we should make PR for both the static and github.io
versions
Sebastian: will do that
PRs
PR #872
<sebastian>
[19]https://github.com/w3c/wot-thing-description/pull/872
[19] https://github.com/w3c/wot-thing-description/pull/872
Kaz: this is for the ReSpec template, not for the content
Zoltan: not only TD, but Scripting as well
Kaz: we should just merge the PR and make sure to propagate the
change
... the changes need to be reflected to the index.html
Sebastian records the todo in a comment in the PR
Sebastian: any objections against merging?
... none, so merged
Issue discussion
Sebastian: Issue #878
[20]https://github.com/w3c/wot-thing-description/issues/878
[20] https://github.com/w3c/wot-thing-description/issues/878
Sebastian: this was the one also discussed in the Architecture
call
... since Ege and ML are not here, should we just read the
thread
... also has impact on lifecycle
Koster: one way it to look at Node-RED
... if you make a connection to an MQTT broker you can reuse
that
... we can define connections and put security info there
... does it make sense to do something similar here?
Sebastian: issue #302
[21]https://github.com/w3c/wot-thing-description/issues/302
[21] https://github.com/w3c/wot-thing-description/issues/302
Sebastian: ML made a comment with an example from Oracle
... there is a URL where one can ask for status etc
Taki: made one suggestion for supporting cancel
... in transactions we can rollback, but in distributed systems
it is better to handle cancel as an independent request
Sebastian: I also made a comment with a hypermedia approach
... include in Forms the hypermedia term that gives a value
which can be used to identify the term in the payload of the
response message that represents the resource one can make the
request to
Koster: in CoAP there is a header field for using hypermedia
control
... used in resource directory
... HTTP also has a location header
... if you have this in a Form, then the protocol bindings
could figure out, not always from declarative way, but at least
as a hint
Daniel: question about the two examples, what does href point
to
Sebastian: points to the JSON term in the response payload
Koster: sometimes it's in the payload and sometimes in the
header
Sebastian: updated the comment with more specific explanation.
Koster: we discussed this in OCF as well
... it's better to use the payload in order to not be needed to
go to the header which may be in a different context
... in code is easier to use the payload
Sebastian: maybe we can introduce a hint in the TD spec
<mjkoster>
[22]https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/L
ocation
[22] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location
Koster: pasted a link for description of the HTTP header
Sebastian: we should perhaps mention what is out there and then
define it in the TD
Koster: could share more info
Sebastian: Koster, please present payload templates
Payload Template
scribenick: Mizushima2
Koster: Semantic API
[23]Koster's slides
[23] https://github.com/mjkoster/wot-protocol-binding/blob/master/SemanticAPI-Aug312018.pdf
<kaz> (the basic idea is handling discovery, adaption, etc., at
the abstract/semantic layer rather than various concrete APIs)
Koster: There are binary switch properties.
... "switch.read" is important.
... this case is simple case.
(Mizushima-san has some trouble with audio and Kaz takes over)
scribenick: kaz
Daniel: lookup is good but wondering about read/write
Koster: possibly much simpler cases
... properties would allow complicated payload
Daniel: not sure about iot:BinarySwitch here
Koster: part of the switch property
... switch might have a property affordance
... for turn on or off
... might be confusing and better to clarify it
<Zakim> kaz, you wanted to ask about expected underlying
mechanism and other approaches like DID's CRUD APIs
Kaz: are these slides available online?
Koster: can make them available
Kaz: do you have any idea about the underlying mechanism for
lookup?
Koster: not really at the moment
... quite generic
... might be a lot of different ways
... may be some kind of query language
... imagine some kind of directory
Kaz: next, we might want to look at DID's CRUD approach as
well, since the DID WG is working on CRUD operations as McCool
mentioned during the Discovery TF call
... would make sense to have collaborative discussion with the
DID guys
Sebastian: you're using semantic annotation to identify
properties you want to operate?
Koster: right
... (shows schema annotation)
Sebastian: my presentation was focused on payload
... different kinds of containers
... is this also your expectation to have light.property?
Koster: both
... (shows the annotation again)
... type: boolean
... @type: iot:SwitchData
... you could use only the data
... (shows DataInstance Dictionary)
... this is how the payload looks like
(Kaz needs to leave for another meeting, and Taki takes over)
<kaz> scribenick: taki
Koster: JSON pointer is for filtering to choose which data.
... It works on JSON structure.
... selecter matches, instead of validating.
... you could match more than one.
... you apply filter, you get pointer.
Sebastian: Do you have implementation?
Koster: there are two steps.
... I would integrate into scripting api instead of standalone
implementation.
... to make scripting api understand filters.
... JSON pointer is well understood already.
... Node Red is already doing similar. We need to make it work
in NodeJS
... I think now is good time to pick up this work.
... Scale and Units adaptation. Integer vs Float, for example.
... Conversion has to happen somewhere.
... it is a way to automatically handle payloads.
... abstract data model is an attempt to remove payload data
schema. Payload definition can be part of protocol binding.
Sebastian: We can even try some of this idea in next PlugFest.
Koster: Helsinki can be the target.
Sebastian: Do you have URI of the presentation?
... We should think about API for semantic based access to
affordances instead of names in API TF.
Daniel: It can be on top of current API.
Sebastian: Thank you for presentation, Michael Koster.
... Thank you Zoltan and Mizushima-san for taking minutes.
[adjourned]
Summary of Action Items
[NEW] ACTION: kaz to ask JSON-LD WG guys about their GH repo
management policy
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [24]scribe.perl version
1.152 ([25]CVS log)
$Date: 2020/03/02 01:11:05 $
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[25] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 2 March 2020 01:17:19 UTC