- 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