15:06:34 RRSAgent has joined #wot-td 15:06:38 logging to https://www.w3.org/2023/02/15-wot-td-irc 15:06:43 meeting: WoT-WG - TD-TF 15:12:16 luca_barbato has joined #wot-td 15:20:16 JKRhb has joined #wot-td 15:20:28 q+ 15:22:34 ack k 15:23:31 present+ Kaz_Ashimura, Ege_Korkan, Daniel_Peintner, Jan_Romann, Luca_Barbato 15:25:10 present+ Sebastian_Kaebisch 15:25:48 sebastian has joined #wot-td 15:26:03 scribenick: JKRhb 15:26:09 topic: Minutes Review 15:27:15 ek: We started with a Binding Templates PR but the discussion evolved into a general one regarding the Binding Template structure/purpose 15:27:25 ... a lot of opinions were exchanged 15:27:53 ... I think the consensus was to have more descriptive content in the specification 15:28:15 present+ Michael_Koster 15:28:20 present+ Tomoaki_Mizushima 15:29:01 ... the minutes seem to be missing TD subtopics 15:29:09 s/TD/PR/ 15:29:43 kaz: I just fixed the names and will make additional fixes regarding a change of the scribenick later 15:30:11 q? 15:30:42 ek: Minutes look good, minutes are approved with the scribenick changes that will happen later 15:31:09 rrsagent, make log public 15:31:13 rrsagent, draft minutes 15:31:14 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 15:31:43 chair: Ege/Sebastian 15:31:46 rrsagent, draft minutes 15:31:47 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 15:32:25 ek: (goes over the agenda) 15:32:25 i|We started|-> https://www.w3.org/2023/02/08-wot-td-minutes.html Feb-8| 15:32:25 rrsagent, draft minutes 15:32:26 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 15:32:32 ... we could start with your slides, Sebastian 15:32:35 dape has joined #wot-td 15:33:21 topic: Binding Template 2.0 Slides 15:33:57 q+ 15:33:57 sk: We can do so, is a proposal for how to deal with Binding Templates in the future 15:33:57 i|We can|@@@ slides tbd| 15:33:57 ack k 15:33:57 kaz: Are the slides available somewhere already? 15:34:07 sk: Have them only locally for now, will upload them later 15:34:42 sk: For now the slides refer to TD and TM as the same document, independent of a potential split in the future 15:35:00 ... as both have an impact on the Binding Template specification 15:35:43 ... everything that is binding-template-related and currently part of the TD document should be moved to the Binding Template specification 15:36:07 ... regarding the content: The Binding Template document should be the main entry point to the binding concept 15:36:47 ... should clarify that the concept of bindings is very broad (can refer to protocols, content type, and ecosystems) 15:37:18 ... all three concepts can be described by a binding 15:38:08 ... the core document should clarify the expectations for a concrete Binding document normatively 15:38:48 ... e.g., defining assertions for how to map a protocol concept to an operation type 15:40:09 sk: The core document should also provide a link or registry to the actual Binding Documents 15:40:09 ... non-normative in order to allow future additions 15:40:40 ... concrete description of bindings should not happen in the core document but in the individual Binding Documents 15:41:06 ... which should then follow the assertions defined in the core document 15:41:53 mjk has joined #wot-td 15:41:54 sk: Another question is what kind of document the individual Binding Documents should be 15:42:30 ... in our opinion, it would be totally fine in a WoT context to have the individual documents as notes 15:42:55 rrsagent, draft minutes 15:42:56 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 15:43:02 ... and not as normative specifications 15:43:22 ... this is also related to the fact that Binding Documents can be defined by other SDOs 15:43:44 ... so for example, OPC UA or ECHONET could define and publish their own Binding specifications 15:43:46 q? 15:43:48 q+ 15:44:24 ... since Binding Documents build on already defined normative assertions 15:45:37 ... in a discussion with Michael Lagally, we arrived at the conclusion that Profiles can also be seen as Binding Documents which should also follow the assertions from the core document 15:46:17 ... which itself will become a Recommendation in the future 15:46:27 q? 15:47:08 kaz: I am kind of confused because last week I already asked Ege and Michael regarding the reorganization 15:47:19 ... is this a proposal for the work by Ege and Michael? 15:47:21 -> https://github.com/w3c/wot-binding-templates/issues/232 @@@ 15:47:35 sk: You are right, we kind of reversed the order 15:47:44 s/@@@/wot-binding-templates issue 232 - Next WD Path/ 15:47:47 q+ 15:47:53 ... but from my understanding this is your understanding as well? 15:47:59 s/I already/we already/ 15:48:14 ek: I think we are also on the same page 15:48:29 s/regarding the reorganization/to work on the reorganization for the Binding Templates spec./ 15:48:46 ... the overall work we have to do is to define the mechanism 15:48:51 q+ 15:49:03 ... a main question is also how to construct payloads 15:49:19 ack k 15:49:21 s/main question/main technical question/ 15:49:30 ... but overall we are on the same page 15:49:41 ack e 15:49:44 ack m 15:50:12 q+ 15:50:39 mk: I also agree, we mostly talked about how to reorganize the document, the last section would mostly be instructions for creating a new Binding Document 15:51:24 ... we did not actually talk about the structure on a level this high, but I mostly agree with the proposal 15:52:03 ... there might be cases, however, where protocols might be extended and further constrained by a Binding document 15:53:18 ... you can assume that there is always an additional layer on top of a protocol, with WoT being one of them, defining defaults and a vocabulary for specific parameters 15:53:58 ... there will be the need to define additional constraints but we don't have the vocabulary to do so yet 15:54:34 q? 15:55:03 ... the ecosystem bindings, however, are going to describe how certain aspects are going to be mapped in practice, for example, LED colors 15:55:28 ... what we need is a semantic hook/interoperability to make bindings work 15:55:56 ... the diagram in the presentation implies that we already know how to it, but have not figured it out yet 15:56:42 ... also the "WoT" in the diagram implies that all bindings are equally "WoT", but there might be differences in the "WoT"ness of a Binding Document, especially when it is defined by an external SDO 15:56:55 ack mjk 15:57:13 kaz: I mostly agree with Michael Koster's view and also with what you have presented 15:57:43 ... this is what I've meant when I said that we need to define a mechanism for the WoT Binding Templates 15:58:28 q+ 15:58:34 ack k 15:59:21 ... also, the core document should describe the general mechanism, the details can then be defined in subdocuments 15:59:22 s/also with what you have presented/think this diagram is inline with what I also mentioned last week./ 16:00:34 s/this is what I've meant when I said that we need to define a mechanism for the WoT Binding Templates/we can include this kind of diagram into the Binding Overview section of the WoT Binding Templates spec./ 16:00:39 sk: In the diagram we also propose to remove the term "Template", to avoid confusion 16:01:32 q? 16:01:37 q+ 16:01:48 ack e 16:02:19 ek: I think the main question concerns the light-blue boxes (i.e., OPC UA, Profile Binding), the "simple" protocol bindings like HTTP should be pretty straightforward 16:03:57 s/also, the core document should describe the general mechanism, the details can then be defined in subdocuments/However, the WoT Binding Templates document should not assume this kind of prescriptions for ecosystems but should simply explain the binding mechanism like (1) how to use forms element, (2) how to use data schema, content type, href, etc., for actual binding. Then we can describe examples of concrete binding, e.g., HTTP, MQTT, OPC UA. If 16:03:57 needed, we can describe them in separate sub documents./ 16:04:09 rrsagent, draft minutes 16:04:10 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 16:04:20 ... also a question is how to refer to other binding documents, especially when it comes to payload bindings) 16:04:52 s/UA. If/UA. If needed, we can describe them in separate sub documents./ 16:05:12 s/needed, we can describe them in separate sub documents.// 16:05:14 rrsagent, draft minutes 16:05:15 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 16:05:23 q+ 16:05:31 sk: I think if a Binding Document reuses a definition from another document, it should rather refer to a normative document (?) 16:05:56 mk: This is a very important point to clarify in order to avoid conflicts 16:06:11 ack mjk 16:06:38 q+ 16:06:40 ack e 16:06:41 ... we don't need to already define this in the charter, but we need to talk this through 16:07:01 ... question is also if a Binding Document like HTTP can be used standalone 16:07:27 ek: HTTP cannot be used standalone since you need to use a payload binding 16:08:32 ... but the data schema from the TD could be used for JSON 16:08:35 s/HTTP cannot/the WoT HTTP Binding document cannot/ 16:09:10 q 16:09:22 ... however, you should always use a Binding Document, e.g. for payloads and ecosystems 16:09:47 ack mjk 16:09:58 mk: I agree, you cannot leave ambiguity in certain places 16:10:22 q+ 16:10:59 kaz: I agree, we need to clarify which areas are defined by which (kind of) document 16:11:59 sk: It is hard to generalize this, should be up to the Binding authors in the end, however, the core document should define the requirements 16:12:21 ... it is good, that we already have existing documents we can use as best practices 16:13:04 kaz: I am not objecting to the diagram, but I am still kind of confused. I think we should let the editors Ege and Michael Koster continue their view 16:13:10 s/view/work/ 16:13:24 ... the diagram should be included in the new core document 16:13:52 ... but there is work to be done to clarify the relationship between the different documents 16:14:06 dp: Not necessary to define all the details right now 16:14:08 s/should be/could be/ 16:14:26 s/there is/there is still necessary/ 16:15:01 ... I think what we have now is sufficient to write a paragraph into the charter, but we should then continue the discussion regarding the details 16:15:16 s/the relationship between the different documents/what to be described by which documents including the Binding Templates core document and the possible sub documents./ 16:15:22 rrsagent, draft minutes 16:15:23 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 16:15:56 sk: The question is now if the abstraction we see here is the right direction for now for the new charter 16:16:02 s/which areas are/what should be/ 16:16:35 mk: I think this the right direction for the charter. Details need to be clarified afterwards 16:17:04 sk: Core (Binding Template) document would be a REC 16:17:07 s/we should let the editors Ege and Michael Koster continue their work/we should simply let the Ediors, Ege and Koster, continue their work on improving the Binding Templates spec./ 16:17:37 q+ 16:17:39 ... concrete Bindings could then be defined in Group Notes or even in sections of other (external) normative documents 16:17:48 ack dape 16:18:09 ... for now we could agree on this structure and then move forward 16:18:56 ack k 16:18:57 +1 16:19:14 kaz: What is important is the intention to make the Binding Template specification a normative one and then parts of the document could become registries 16:19:31 q+ 16:20:14 s/important/important for the Charter document/ 16:20:19 ek: I agree, we don't need the details, the overall structure is agreed upon 16:20:22 s/is the intention/is our intention/ 16:20:37 ... we could make a resolution for the new structure 16:20:40 q+ 16:20:44 ack e 16:20:54 ... if no one disagrees I would make a proposal 16:21:22 ack k 16:21:47 kaz: As I said before, I am okay with the structure, and we should integrate the diagram into the document to tick yet another checkbox of issue xxx 16:22:07 proposal: The TF agrees that the next charter there will be a REC document called WoT Binding Templates 2.0 which will have Note documents for specifying the individual bindings 16:23:16 proposal: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates 2.0 which will have other separate documents for specifying the individual bindings 16:23:39 mk: I don't think we need to mention "Note documents" in the proposal 16:23:41 s/document to tick yet another checkbox of issue xxx/Binding Templates spec. So would suggest we add yet another checkbox to record this item for the document improvement within the Issue 232./ 16:23:47 proposal: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates 2.0 which links to other separate documents for specifying the individual bindings 16:24:03 q+ 16:24:09 ek: (updated the proposal) 16:24:44 ack k 16:24:44 proposal: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates which links to other separate documents for specifying the individual bindings 16:25:04 +1 16:25:17 RESOLUTION: The TF agrees that in the next charter there will be a REC document called WoT Binding Templates which links to other separate documents for specifying the individual bindings 16:25:22 kaz: Calling the document "WoT Binding Templates 2.0" is a bit confusing, should be removed from the resolution, versioning should be decided later 16:25:32 i|232|-> https://github.com/w3c/wot-binding-templates/issues/232 Issue 232| 16:25:51 The Task Force makes the resolution above. 16:26:40 sk: Going forward, we should focus on the base concept and figure out the details of the sub documents later 16:27:04 topic: TM Document 16:27:36 sk: The situation regarding TM and TD is that we need to clarify whether we want to have a separate document for TMs 16:27:38 rrsagent, draft minutes 16:27:39 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 16:27:48 ... or only one Recommendation for both 16:28:02 ... should collect pros and cons 16:28:27 ... I think the big "pro" is that it be that it would be more lightweight 16:28:41 q+ 16:28:43 ... the TM parts would also be easier to find 16:29:01 q+ 16:29:14 lb: It is worse than that: "Thing Model" currently points you to a completely unrelated document 16:29:40 ... separating the TM and TD improves searchability, which is already a big plus 16:29:59 ack luca 16:30:00 also see https://github.com/w3c/wot-thing-description/issues/1747 16:30:23 sk: One "con" I see would a lot of duplicated definitions 16:30:26 I was exactly thinking of that 16:30:41 q+ 16:31:08 ... question is whether we put the information in the TM document or point to the TD document 16:32:00 kaz: I would, once more, suggest to focus on what we want to achieve. A separate document might make things easier for the editors, but it is also harder to keep things in sync 16:32:28 ... we should think about what to describe by which document 16:33:02 ... regarding the search results from search engines, we cannot avoid these kind of overlaps 16:33:28 sk: I think it is not only this kind of search aspect 16:34:03 ... if someone asks me about the Thing Model, I need to tell them to scroll down to a section down below 16:34:18 ... and then they need to scroll back to understand the information model 16:34:38 ... I think this could be simplified by a standalone document 16:35:02 q? 16:35:12 ack k 16:35:16 kaz: The core issue here is that is unclear what the purpose of the Thing Model is in the current specification 16:35:25 ... rather than document separation 16:35:26 +1 kaz 16:35:36 q+ 16:35:45 q- 16:36:46 ... in any case, we should clarify what the purpose of Thing Models and how to generate Thing Descriptions 16:37:13 ek: This is already a normative part of the current specification, though 16:37:34 kaz: As I said, we should clarify what we need before discussion a separation 16:38:23 q+ 16:38:37 sk: The main change in TD/TM 2.0 would be the updated information model 16:38:37 s/discussion a/discussing/ 16:39:16 ... so there is not really much new content 16:39:54 sk: One feedback I got from a coworker at Siemens was that it is difficult to distinguish a TM from a TD, especially at the RDF level 16:40:20 q+ 16:40:21 ... for many use cases it is important to be able to separate the two 16:40:28 q+ 16:40:53 ... so ideally, you would have a different namespace 16:41:27 ... which might be difficult to accomplish since TDs and TMs share a lot of concepts 16:41:37 q+ 16:42:08 ack e 16:43:24 jr: my impression on the TM section is something added later, and think it's better to keep it within TD to avoid confusion 16:44:10 sk: we could think about further improvement even with the current structure with TM inside the TD spec 16:44:52 ... think that's what you're proposing 16:45:08 ack j 16:45:36 lb: the whole TM description is not based on the Thing Description model itself 16:45:45 q? 16:45:52 s/is/is conceptually/ 16:45:56 ack l 16:46:36 ... so think Thing Description is enough from my viewpoint 16:46:52 ... implementing TM is kind of burden 16:47:21 ek: What kind of burden do you see? 16:47:42 i/my impression/scribenick: kaz/ 16:47:52 i/What kind/scribenick: JKRhb/ 16:48:05 q? 16:48:19 lb: I would argue to keep them as separate as possible due to the fact that TMs require additional processing 16:48:50 q+ 16:49:06 dape: I would agree with using TMs as the base and then extending from TM to TD 16:49:20 ack d 16:49:38 ... making it also clear that the document is about TMs and TDs 16:49:59 kaz: I agree with Daniel's view 16:50:18 ... maybe we can think a bit more about what the issues with TMs currently are 16:50:35 ... and then revisit thinking about separation 16:51:07 sk: I think one of the big plusses of having one document is avoiding the need for another REC 16:51:27 ack k 16:51:56 mk: I just wanted to echo, we should elaborate a bit more why we need TMs 16:52:28 ... also TMs are the generalization and TDs are an instantiation or extension 16:52:38 +1 16:53:04 q+ 16:53:23 ack m 16:53:55 ... also using TMs make it possible to trace the place where a TD originates from when looking at a concrete implementation 16:54:53 ... regarding the document, an improved section might also make it easier to understand the differences between TDs and TMs (?) 16:56:08 sk: Regarding the overall structure, we can use the TM as the basis that is enhanced by a Binding Document and Security Schemes 16:56:14 ... to create a TD 16:56:29 q+ 16:56:49 lb: That is very problematic. What happens if we an ontology that is not a Binding Document or a Security Scheme 16:57:43 ack l 16:57:43 q+ 16:58:14 ... we have an overlap of concerns and definitions, which is problematic 16:58:55 sk: I just wanted to focus on our current structure, but I can clarify that additional ontologies can be used as well 16:59:14 ack k 16:59:17 kaz: We are running out of time, we should continue the discussion next time 16:59:32 ek: Wanted to reply to Luca 16:59:39 ... there are two types of TMs 17:00:04 ... the ones where only certain information is plugged in 17:00:09 s/discussion/discussion on how to improve the description on TM within the Thing Description (Section 9)./ 17:00:23 ... and the ones that are used in the context of ontologies 17:00:42 lb: We continue this next time. 17:00:52 i|Wanted|-> https://www.w3.org/TR/2023/CR-wot-thing-description11-20230119/#thing-model Thing Description 1.1 - 9. Thing Model| 17:01:43 sk: I would postpone, we collected a number of arguments 17:02:04 s/a number/a lot/ 17:02:07 [adjourned] 17:02:50 rrsagent, draft minutes 17:02:51 I have made the request to generate https://www.w3.org/2023/02/15-wot-td-minutes.html kaz 17:08:36 please find here the presented slides: https://github.com/w3c/wot-charter-drafts/files/10745556/WoT_Binding_2.0.pdf