- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 05 May 2021 16:11:38 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/03/10-wot-td-minutes.html
also as text below.
Thanks a lot for taking the minutes, Cristiano!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT-WG - TD-TF
10 March 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Mar_10.2C_2021
[3] https://www.w3.org/2021/03/10-wot-td-irc
Attendees
Present
Cristiano_Aguzzi, Ege_Korkan, Kaz_Ashimura,
Klaus_Hartke, Michael_Koster, Michael_McCool,
Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian
Scribe
cris, kaz
Contents
1. [4]agenda
2. [5]previous minutes
3. [6]Modbus binding
4. [7]PR 1058
5. [8]PR 1060
6. [9]PR 1061
7. [10]PR 1065
8. [11]Issue 1053
9. [12]Issue 1047
10. [13]Issue 1037
11. [14]Issue 1020
Meeting minutes
agenda
Sebastian: no guest today
Sebastian: we'll start from the modbus biding pr
… then go trough the issues
… in particular about the additionalResponses topics
… is there anything else
… ?
Ege: there's a PR about the required term
… is this included in the agenda?
Sebastian: kind of we have a PR point in the agenda
previous minutes
<sebastian> [15]https://www.w3.org/2021/02/
24-wot-td-minutes.html
[15] https://www.w3.org/2021/02/24-wot-td-minutes.html
Sebastian: no call last week because of PlugFest
… then we discussed CR/PR planning
… collected some topics for the F2F meeting
… discussed the additionalResponses
… finally we merge a PR about TM json schema
Sebastian: ok, any objection to publish the minutes?
… ok, minutes accepted
Sebastian: ok then a quick update. I'd suggest skipping next
meetings during the f2f
… any comments about the f2f agenda?
<kaz> [16]TD day on March 24
[16] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_March_2021#Wednesday_March_24
Sebastian: ok
Modbus binding
Sebastian: cristiano has updates about his PR
[17]PR 109 - Refining Modbus protocol binding
[17] https://github.com/w3c/wot-binding-templates/pull/109
Cristiano: captured the discussion so far
[18]preview
[18] https://pr-preview.s3.amazonaws.com/relu91/wot-binding-templates/pull/109.html
Cristiano: would like to get feedback
… what is lacking and nice to have is URL for modbus and the
other binding
Ege: should be sort of another content for chapter on URL
scheme
… modbus TCP
… applied to RTU
Cristiano: need to specify that
… not sure which one to try first, though
Ege: modbus standards to be referred
Sebastian: we should have a subsection on the base URL
… for modbus scheme, etc.
… also we should think about the title of the document
Sebastian: another question is "entity and function"
… what do you mean?
Cristiano: depends on the modbus vocabulary
Sebastian: not typically to have the information on the header
… maybe a separate section
… reference section
Kaz: agree with Sebastian, and think we should discuss how to
deal with this document
… possibly (1) an example section or (2) a separate best
practice document
<Mizushima> +1
Koster: we have protocol binding template document which
defines how the binding works
… new binding could be added without changing the model
… but actual binding examples like modbus binding would cause
too many dependencies
… for binding templates, we want interoperability
… not really sure about the procedure but we could produce
multiple documents for the guidance
… e.g., modbus binding
Cristiano: that's my understanding as well
McCool: we can add informative notes if needed
Kaz: right
McCool: easier to mange is important
Cristiano: right
… btw, the ontology itself here doesn't exist
Sebastian: would agree too
… the situation around IoT changes everyday
… what you have to do for the possible protocols in the future?
Cristiano: have some more thing to do as well
… so can wait before merging
… e.g., I'd like to add additional sections based on the
comments
Kaz: btw, you use the same tool to generate the HTML based on
the template HTML like the TD spec. right?
Cristiano: exactly
Kaz: btw, why there are so many changes with the .gitignore
file as well?
Cristiano: let me check
[19]changes
[19] https://github.com/w3c/wot-binding-templates/pull/109/files
Klaus: which ontology are you using here?
Cristiano: this was created by a student of Ege
… for modbus nod-wot binding
… so basically we ourselves generated it
Kaz: so the final modbus ontology might be bigger
Cristiano: right
Sebastian: Ege, your student reflects the existing modbus
standards. right?
Ege: yeah
Sebastian: maybe we should ping the modbus community to review
this
Sebastian: for example, about security for modbus
Cristiano: once it's published, we can get more feedback
Koster: maybe there are some terminology questions
Cristiano: ok
Klaus: do we classify everything?
Cristiano: you have classes and properties
Klaus: HTTP in RDF doesn't use this grouping
… maybe for COPA, MQTT, etc.?
Cristiano: right
… not for HTTP here
Klaus: btw, what about CoAP binding?
Sebastian: also interested in that
… and wanted to ask you, Klaus, about that :)
Klaus: you can see the possible values here
… what I did is automatically convert this
… that is the 1st step
… and then we could tackle CoAP binding
Cristiano: basically there are 3 scripts here
… which were generated by Victor
Klaus: can generate a TTL file and convert it to RDF
… the TTL are to be reviewed
Sebastian: in that case, you both (=Cristiano and Klaus) can
work together offline
Cristiano: can help Klaus
Sebastian: let's make a prototype based on this description
(=coap.ttl) first
… thanks a lot for your hard work
… remaining question is modbus security
Sebastian: we should reach the modbus community
Cristiano: yes, we could try
<Ege> [20]https://modbus.org/
[20] https://modbus.org/
Ege: there's something going on in the modbus community
… not properly a standardization. (see link above)
Sebastian: Itachi is member, we could also aske them
<sebastian> [21]https://control.com/forums/forums/modbus.36/
[21] https://control.com/forums/forums/modbus.36/
Koster: the real name is the modbus organization
<kaz> topi: Defer issues to TD 2.0
Sebastian: ok, let's move the next topic
<kaz> [22]Issues to be deferred to 2.0
[22] https://github.com/w3c/wot-thing-description/issues?q=is:issue+is:open+label:"Defer+to+TD+2.0"
Sebastian: btw please look for propose closing and TD 2.0
labels
PR 1058
<kaz> [23]PR 1058 - WIP: Add JSON pointer assertion to
definition of body sec location
[23] https://github.com/w3c/wot-thing-description/pull/1058
Sebastian: let's start form add json pointer assertion to
definition of body sec location #1058
McCool: we discussed briefly on the format of the json pointer.
… any further comments are welcomed
Sebastian: is the json pointer format standard?
McCool: yes it has its own RFC. it has been around from 2016
PR 1060
<kaz> [24]PR 1060 - fix issue #980
[24] https://github.com/w3c/wot-thing-description/pull/1060
Sebastian: I fixed an issue with @type for contentEncoding in
the context-1.1.json ld
… should we merge it?
… merged
… issue 980 closed
<kaz> [25]Issue 980 - Definition of contentEncoding should be
of type xsd:string
[25] https://github.com/w3c/wot-thing-description/issues/980
PR 1061
<kaz> [26]PR 1061 - Fix cardinality of Link.rel
[26] https://github.com/w3c/wot-thing-description/pull/1061
Sebastian: in the current draft the type of link type and rel
is wrong. it is string or array but we didn't agreed on this
change
… this pr fixes this problem
<kaz> [27]Preview of "5.3.4.1 Link"
[27] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1061.html#link
Sebastian: it seems that the problem is not completely solved
in the PR. rel field is still anyURI whereas previously was
simply string
… I'll ask victor to look at it
PR 1065
<kaz> [28]PR 1065 - fix: the "required" keyword was placed
incorrectly in the TM schema
[28] https://github.com/w3c/wot-thing-description/pull/1065
Sebastian: simple PR about fixing the validation of TM. It
basically wildcard the term required. However, I don't like the
required implementation so I think we should directly improve
the implementation instead of validating
Ege: he edited the wrong file, we should describe the process
Cristiano: we can set up a github actions saying which file
should not be touched
Ege: cool, can we set up the github action?
Kaz: right he should edit the index.template.html
… we could do the process manually also
… there's two separate issues validation and the generation
Sebastian: not easy we should involve victor
… we automated the process to avoid mistakes
Ege: I think we diverged a little bit. I would like to have
simply the validation
Sebastian: btw I updated the discussion on the issue with the
comments.
Kaz: PRs should be generated by the editors
… or at least included in the editors group
… it might be good to file an issue and the editors will create
the PR
Sebastian: ok next topic
Issue 1053
<sebastian> [29]Issue 1053 - Consider adding DataSchema to
response and additionalResponses
[29] https://github.com/w3c/wot-thing-description/issues/1053
Sebastian: it is about the new additionalResponses
McCool: btw additionalResponses is not a subclass of regular
responses. For example contentType is mandatory
Sebastian: and it has also schema
McCool: yes
McCool: there's question if the additionalResponses should be
used for successful responses
… not sure about examples but I suspect there're some API which
as different dataschmas
Sebastian: in the issues we discussed if it is good to have the
schema in the additionalResponses
Koster: exactly I wrote about this in my comment
McCool: we could rename it as errorResponses
… the default behavior should be a protocol generated response
Sebastian: in the issue I created an example using json
pointers
… we could introduce addtionalSchema
McCool: yeah we could make it an object
… then we have to decide to use json pointers or json schema
pointers
+1 for additionalSchemas
McCool: we could use names to define addtionalSchemas
Koster: +1
McCool: that would allow to reuse schemas
+1
Ege: also we could use this feature to help TD designers
… so that they could not repeat the schema
McCool: like the idea, let me update the PR
Ege: should we restrict the kind of data to be put in the
additionalSchemas?
McCool: should avoid using pointers to much
McCool: btw with definitions we could avoid using json schema
pointers
McCool: we should use json pointers than schema it is standard
Cristiano: good the direction, I like it. Keep in mind that it
might get harder to parse the TD in a linear way
… canolization could help
McCool: agree, but I would avoid to expand pointers cause we
could reduce the bandwidth
Sebastian: good point about parsing, but this is an exceptional
situation
… it might not be present in all TDs
klaus: +1 it is a good practice to have a well defined place
Cristiano: it is easier also to validate
McCool: ok, I'll work on the PR to bring these updates
Sebastian: this concepts we could reuse for log running actions
Sebastian: I'd put that the same place of URI variables
McCool: btw you can define objects in uriVariables which is
difficult to serialize
… at least we should add an assertion
Koster: it might be some way to serialize objects to URI
McCool: btw if disallow having object in URI we could re
introduce it later.
Issue 1047
<kaz> [30]Issue 1047 - Two step generation of the TD from a TM
should be clear
[30] https://github.com/w3c/wot-thing-description/issues/1047
Sebastian: how to generate TDs from TMs
<mjk> (Koster leaves)
Sebastian: cristiano made a point to make the last points
towards the term partialTD
Sebastian: afraid that the partialTD could confuse
Cristiano: yeah it might, but we have the definition in the
architecture
Ege: also partialTD is not so hard to understand. it should be
clear the difference between a TM and a partialTD
[31]https://w3c.github.io/wot-architecture/#dfn-partial-td
[31] https://w3c.github.io/wot-architecture/#dfn-partial-td
Sebastian: good I'll provide a pr
Issue 1037
<kaz> [32]Issue 1037 - The "body" location value for security
schemes is underspecified
[32] https://github.com/w3c/wot-thing-description/issues/1037
Sebastian: it seems we could close this one
McCool: it needs to be closed only after merging the linked PR
Sebastian: ok next time then
Issue 1020
Sebastian: defer to the next meeting, it is really interesting
because it compares our definition of action and properties
with other standard
Kaz: totally agree
… my impression is they don't really restrict the usage of
actions or properties
… it depends on the implementation
… actually, that's why I've been asking you all to generate
guidelines from our previous experience in plugfests :)
Cristiano: it depends a lot if you are modelling a new device
or mapping an old one to wot
Koster: it is good to discuss this. I spent a lot of time
describing the usage of actions to rest guys
Kaz: we could have complicated actions, e.g., changing the
brightness within one minutes gradually
… in that case, using properties would be very hard
Sebastian: yeah I would use actions
… let's discuss next time
adjourned
Minutes manually created (not a transcript), formatted by
[33]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[33] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 5 May 2021 07:11:44 UTC