- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 03 Mar 2021 19:03:25 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/01/20-wot-td-minutes.html
also as text below.
Thanks a lot for taking the minutes, Cristiano and Daniel!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT-WG - TD-TF
20 January 2021
[2]IRC log.
[2] https://www.w3.org/2021/01/20-wot-td-irc
Attendees
Present
Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan,
Kaz_Ashimura, Michael_Lagally, Michael_McCool,
Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian
Scribe
cris, dape
Contents
1. [3]Agenda
2. [4]Last minutes - Review
3. [5]Defer issue to TD 2.0
4. [6]Propose closing issues
5. [7]PR 1025
6. [8]PR 1030
7. [9]PR 1034
8. [10]PR 1031
9. [11]PR 1032
10. [12]PR 1035
11. [13]Issue 617
12. [14]Issue 980
13. [15]Issue 1002
14. [16]Issue 972
Meeting minutes
Agenda
Cristiano: Talk about ModBus next week
McCool: Open PRs from my side we might want to look at
Last minutes - Review
see [17]https://www.w3.org/2021/01/13-wot-td-minutes.html
[17] https://www.w3.org/2021/01/13-wot-td-minutes.html
Sebastian: any objections?
… none --> minutes approved
Defer issue to TD 2.0
[18]https://github.com/w3c/wot-thing-description/
issues?q=is%3Aissue+is%3Aopen+label%3A%22Defer+to+TD+2.0%22
[18] https://github.com/w3c/wot-thing-description/issues?q=is:issue+is:open+label:"Defer+to+TD+2.0"
Sebastian: Please take a look at these issues and raise
concerns
Propose closing issues
Sebastian: Also here, please comment if you see problems
… so that we can discuss the issues
PR 1025
Sebastian: Introduce observeAllProperties and
unobserveAllProperties, [19]https://github.com/w3c/
wot-thing-description/pull/1025
[19] https://github.com/w3c/wot-thing-description/pull/1025
Sebastian: there was a bug in the PR Victor fixed
… PR is about adding op for observeAllProperties and
unobserveAllProperties
… PR is ready to be merged
… arghhh, merge conflicts
… w.r.t. SVG images
… fixing it right away
… any objections before merging?
… none -> merging...
PR 1030
[20]https://github.com/w3c/wot-thing-description/pull/1030
[20] https://github.com/w3c/wot-thing-description/pull/1030
Daniel: respec warnings only
Sebastian: looks good to be merged
PR 1034
[21]PR 1034
[21] https://github.com/w3c/wot-thing-description/pull/1034
Sebastian: introduced new chapter about link relation types
… not completed yet
… the values in link relation table are coming from IANA
… should re-use them as much as possible
… e.g., "service-doc"
… e.g., "alternate" representation like RDF, HTML et cetera
McCool: link type for directory federation?
… "proxy-to" to be used?
… not sure if this is right
Sebastian: First set at the moment
… might need to improve
… we have requirement document
<mlagally_> Will be back in 5 mins
<sebastian> [22]https://github.com/w3c/wot-architecture/blob/
master/REQUIREMENTS/link-relation-types.md
[22] https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/link-relation-types.md
<cris> +1 also from my side
McCool: What about non IANA types?
… do we propose to add them to IANA?
Sebastian: There is a column indicating the source.. IANA or
any other place
… "extend" coming from WoT Thing Model
McCool: what about "implements" ?
… seems important to me
… for geo-location we need to point where location is
Lagally: Thanks for addressing the link type comment
… surprised about being "informative"
… shouldn't it be normative?
… we need column about cardinality also
… e.g., multiple inheritance: 1 or *
McCool: we need a decision about each
Sebastian: Makes sense
Ege: would see link table in Chapter 5
Sebastian: Was thinking about it also...
… in/under 5.3.4.1 ?
… have examples in *new* Section 11
… where should examples go?
Ege: In chapter 6 there are already examples
McCool: Note: "controlledBy" is not yet in the list but in
example
… "assembly" is another type
Lagally: will it ever make sense to have one of this links
mandatory?
McCool: in certain contexts, like profiles...
… in general making them mandatory causes backward
compatibility issues
Lagally: Makes sense
Sebastian: will keep working on the PR
Ege: in some cases people combine keys
Sebastian: multiple rel values?
… yes, I have seen that
… do we want to allow that?
McCool: Isn't "link" define somewhere.. what does the RFC say
… alternative is to duplicate link with different rel type
Koster: RFC 8288 talks about it
Ege: "+" used to give further precision
… will try to find more information
McCool: "+" in relation names may cause problems
… "-" is allowed in name
Sebastian: Let's try to find out more
PR 1031
[23]https://github.com/w3c/wot-thing-description/pull/1031
[23] https://github.com/w3c/wot-thing-description/pull/1031
<mlagally_> (signing off)
McCool: PR not complete yet
… rendering is not working
Daniel: had same issue, not recalling where to put the
content.. i guess some parts need to be duplicated
McCool: Will contact Victor
… w.r.t. content
… APIkey vs. PSK
… APIkey cloud service provider example
… expanded the description
… PSK meant when you have standard for key
… add cypher-suite parameter?
… in both cases key should be put in TD
… no assertion ... but we should discourage it
… Ege can you check my work
Ege: commented already
PR 1032
[24]https://github.com/w3c/wot-thing-description/pull/1032
[24] https://github.com/w3c/wot-thing-description/pull/1032
McCool: key as part of URI
… see Philips hue
… parameter map pointing will be updated in PR
… replace with actual set of data schema
… still WIP
… I also added explainations
… extend body to allow more
… maybe in a seperate issue/PR
… also, rendering is not working
PR 1035
[25]https://github.com/w3c/wot-thing-description/pull/1035
[25] https://github.com/w3c/wot-thing-description/pull/1035
Sebastian: multiple op in forms
… PR gives some kind of guidelines for HTTP
… there is an example in the PR that shows how to create
multiple forms
… for htv:methodName
Cristiano: looks good to me
… I am wondering about other protocols
… maybe have dedicated section in each binding about the
limitation
Sebastian: Did not think too much about other protocols yet
Cristiano: Should find a place for such things... in bindings?
Sebastian: Yes, should get some experience
… we are missing the big picture
Daniel: CoAP would have the same limitation
Sebastian: Correct, but CoAP is not defined in TD
Koster: It comes down to how defaults are defined for bindings
… MQTT could be also such a use case
… up to bindings to specify defaults
… for MQTT no command would be required
Ege: MQTT defaults are up to version 5
Cristiano: for forms, contentType gets duplicated also?
Sebastian: Yes, any other metadata should be duplicated also
<cris> Ok to merge +1
Sebastian: shall we merge PR?
Koster: don't see any issues
Sebastian: relates to a relatively old issue 712
… -> let's merge then
Issue 617
[26]https://github.com/w3c/wot-thing-description/issues/617
[26] https://github.com/w3c/wot-thing-description/issues/617
McCool: No PR yet, working on it
Issue 980
<McCool> (have to drop, ttyl)
[27]https://github.com/w3c/wot-thing-description/issues/980
[27] https://github.com/w3c/wot-thing-description/issues/980
Sebastian: schema definition using wrong type
… issue seems still existing
… should be fixed
… I will provide a PR
Issue 1002
[28]https://github.com/w3c/wot-thing-description/issues/1002
[28] https://github.com/w3c/wot-thing-description/issues/1002
Sebastian: ML asks for term "reliability"
… correct vs false readings
CA/Ege: use existing ontologies
Sebastian: "reliability" comes with multiple different meanings
… hard to generalize
… I don't think we should introduce it in core TD
… should have a discussion with ML
Koster: "reliability" added where?
… associated to value?
… having a model makes sense to me
… as value constraints it might be useful
Sebastian: Suggest using existing ontologies
Koster: reliability for values might make sense
Sebastian: Is there a standard way? Percentage value?
Koster: it is usually some number of 999 / percentage
… there are different ways
… mean-time failures
… bunch of different types
... what kind of information do we need then?
… the main use case would be to get reliable data from
unreliable sensors
… I think it is a good case
Sebastian: I think we need Michael Lagally here
<kaz> [29]IEC 61360 Common Data Dictionary V2.0014.0017 -
liability of an item
[29] https://cdd.iec.ch/cdd/iec61360/iec61360.nsf/SearchFrameset?OpenFrameSet
Kaz: we could use this linked ontology
… or at least ask the IEC group for use cases and how to use
their ontologies.
Sebastian: good
Kaz: We should define a policy for the Thing Description model.
like how to introduce new terms, because we can't define
everything and TD should concentrate on the basic framework
based on the affordance model.
Sebastian: I agree. If this term can be generalized we could
employ it. But it is not easy
Issue 972
<kaz> [30]Issue 972
[30] https://github.com/w3c/wot-thing-description/issues/972
Sebastian: about issue 972 we are discussing about a json
schema for TM
… I think we could postpone the discussion since daniel is not
here
… maybe Cristiano has any input?
Cristiano: basically now a Thing Model is really similar to a
Partial TD. In the future the TM may has more requirements.
Which field should we require in a TM?
Sebastian: good question, right now I don't have a clear answer
we should talk more in the future calls.
Sebastian: maybe @context could be required
Koster: we could even have multiple templates in the Schema
Sebastian: right, let's continue the discussion in the next
meeting
<kaz> [adjourned]
Minutes manually created (not a transcript), formatted by
[31]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[31] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 3 March 2021 10:03:34 UTC