- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 03 Mar 2021 19:15:39 +0900
- To: public-wot-wg@w3.org
available at: https://www.w3.org/2021/02/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 February 2021 [2]Agenda. [3]IRC log. [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Feb_10.2C_2021 [3] https://www.w3.org/2021/02/10-wot-td-irc Attendees Present Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Jack_Dickinson, Kaz_Ashimura, Michael_Koster, Sebastian_Kaebisch, Tomoaki_Mizushima Regrets - Chair Sebastian Scribe cris Contents 1. [4]agenda 2. [5]previous minutes 3. [6]master to main 4. [7]bindings 5. [8]PR 1032 6. [9]PR 1024 7. [10]issue 1020 8. [11]adding term for stream of data Meeting minutes agenda Sebastian: today we have to discuss about the migration from master to main, protocol bindings and Github PRs/issues … something else? … ok previous minutes Sebastian: we discussed modbus binding document and PRs <kaz> i|discussed|[12]Feb-3| [12] https://www.w3.org/2021/02/03-wot-td-minutes.html Sebastian: notice now we are able to define multiple responses in TDs … also we discussed about different topics around the Thing Model … we still need a jsonschema for Thing Model … any objections to publish the minutes? … ok master to main Sebastian: there are some issues in the process of renaming … Michael McCool is working on it. … in a couple of weeks it should be solved … any comments? Daniel: I'm not sure what will happen to open PRs Sebastian: good point. let's wait for Michael's input on the issue bindings Sebastian: modbus, any news? Cristiano: sorry I am in late. let's discuss it next week Sebastian: ok Sebastian: then we have OPC-UA binding. As you now there's a liaison between our group and OPCF but there's still not common activities … I think it's a good time to start a collaboration with them … the motivation is that we can use TDs to describe OPC endopoints … it is the same motivation of other bindings. … I know that opc ua is not so common in the web domain, but it is wide known in the industry field Sebastian: I think the work is minimal. we can use the other documents as example … it is important to evaluate the security patterns in OPC-UA … the outcome should be a document, an ontology and finally a prototype. Kaz: Do you want to talk about the liaison with OPC-UA today? Sebastian: yes, it was my intention Kaz: I have some trouble to understand this proposal. In my understanding concrete binding document should be handled by external organizations (like OPCF). Why do we need a joint specification work? … if we go down that path we should do the same also for other bindings (mqtt, Fiware, etc.) Sebastian: then I can ask why do we have this liaison … ? Kaz: it is mostly for discussion about implementation and use-cases … we don't need a joint specification … work Sebastian: we can ask the OPCF to do the work in their Companion specification document. … however the document would be difficult to connect with W3C and WoT … OPCF is comparable in size to W3C. They have their management process to update spec and it could be a problem if our specification disalign with theirs. Kaz: we could start from an integration of a OPC-UA device to WoT in a PlugFest … but first we have to start to actual need for this integration Ege: the benefit could be to prove again that the WoT could be applicable in this field too … a joint specification is more powerful Sebastian: agree … it is a way to have more impact in the industry domain … it is kinda a marketing aspect … the joint work is helpful to have aligned solution in both organizations Kaz: I am not objecting to the liaison itself. I am always open to discussion with external organization. However, I wonder if the joint specification is really needed. We should start from plugfest. Kaz: we should start from discussion with the group and then extend the liaison to the next level (e.g., joint specification documents) Sebastian: so which is the concrete next step here? … we already had some discussion with the opcf group … I need a concrete next step suggestion Kaz: based on the discussion we had, we can start from the plugfest integration … why can't we start from plugfest? Sebastian: option 1: UA foundation create a sub group for the definition of the protocol binding. Option 2 work together. I like option 2 more. Kaz: we could start discuss about the collaboration Sebastian: did you join the meeting about the validation? … I can share slides. I think we already did this kind of pre-work Koster: my advice is to continue the work on the spec separately under the current simple liaison … maybe later join together <kaz> kaz: exactly Sebastian: which is the advantage? Koster: I don't see this option as a disadvantage. The disadvantage is that the joint spec open some IP problems Daniel: W3C WoT WG generates W3C specs and OPC UA generates OPC specs, so no IPR problems there … correct? Sebastian: it should. all the content from the companion spec should be hosted publicly in a w3c site. Kaz: we could refer to existing ontologies in our document safely … for a joint spec we need to discuss the process beforehand Sebastian: maybe we are on the same page … starting from the ontology. It should be generated by the OPCF or from some expert from that group. It is not our job … I'd expect this as the main outcome … the ontology could be hosted in OPC UA side Koster: do we need to claim authorship of this joint spec?who's responsible for it Sebastian: right <kaz> [13]WebRTC REC - collaboration between W3C and IETF [13] https://www.w3.org/TR/2021/REC-webrtc-20210126/ Sebastian: we need just the ontology <kaz> [14]Spatial Data on the Web Best Practices - collaboration between W3C and OGC [14] https://www.w3.org/TR/2017/NOTE-sdw-bp-20170928/ Sebastian: then our work is to describe how to map those concepts and network communication with an OPC UA device. … ok, I'll take some time to think about it. Probably we could start from the Companion specification and contribute there Kaz: I shared two examples … as you can see collaboration can happen … for example ogc and w3c published a joint note Sebastian: we can considered this option … like a joint document where to describe the vocabulary Kaz: based on the discussion today, my impression on the relationship between w3c and opcf is similar to w3c and IETF. We can simply acknowledge opcf work citing their vocabulary ontology, etc. Kaz: we could invite experts in our binding call and work together Sebastian: so should I delete the current draft document? Kaz: we can continue the discussion under the current liaison with opc-ua. Starting from this document. … maybe just rename charters to liaison. Or rather move to a proper location … the document is a good starting point Sebastian: thank you for the input Kaz: I think there is a possibility of a joint specification but only when we identify a substantial missing building block. PR 1032 <kaz> [15]PR 1032 - Add URI template location for security scheme parameters [15] https://github.com/w3c/wot-thing-description/pull/1032 Sebastian: number 1032 uri template for security scheme parameters Sebastian: the approach here is similar to uriVariables … in the text there's a clarification about how to solve possible name conflicts … I am ok merging this Cristiano: I am afraid to have a lot of similar mechanisms for the same thing Cristiano: it might be difficult to read Sebastian: the thing model has templating but it has a clear different scope Sebastian: currently we don't have a better idea Daniel: I kinda of agree with Cristiano. I wonder now weather to put placeholder in other document at all <kaz> [16]Sebastian shows section "10. Thing Model" around "Example 45" [16] https://w3c.github.io/wot-thing-description/#example-45-mybuzzerthingmodelserialized-in-json Sebastian: the problem is that the Thing model uses the concept of the TD model <dape> ack Sebastian: the idea is also to move the Thing Model in other docuemnt Sebastian: back to the PR. I am ok merging it. It is self contained. … we can improve also the number of devices described by a TD … any objections to merge? … merged PR 1024 Sebastian: next PR <kaz> [17]PR 1024 - Topics around Thing Model [17] https://github.com/w3c/wot-thing-description/pull/1024 <kaz> [18]Preview of section "10. Thing Model" [18] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#thing-model Sebastian: it's about Thing Model chapter … (showing the preview) Ege: there's an issue in the version field in the TM model Sebastian: please note that down in github Sebastian: showing examples of TMs <kaz> [19]Example 49 on the Preview [19] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#example-49-thing-model-with-the-required-term-for-interaction-affordances Sebastian: I introduced the relation type called "type" … it serves as an indication that a TD is an instance of a TM Sebastian: the required keyword can force the presence of a particular field in the final TD instance Ege: some issues: … I don't like the require keyword clashes with DataSchema required Sebastian: it is another level Ege: for validation it will be challenging … I am not super happy about this new require feature <Zakim> dape, you wanted to required causes validation issues array/object Ege: it would be better to have just a flag … required on not Koster: we could have just one place to list the required affordances … flags it might be a problem for reusability. Sebastian: so how's this solved in sdf? Koster: we a field with pointers to required properties/values Sebastian: Ok, I'll add a note in the required section stating that it is under discussion … also we'll discuss about sdf pointers in the F2F meeting … actually the whole TM section has a note saying that is under discussion Ege: I'll create an issue on this Ege: what if in TM I don't put forms? or other required TD field without a placeholder? … it should be clear that in the end other properties will be add in the final TD … we have an use-case to not have forms in a TM, however from the text it is not clear. It seems that I need to put a place holder to generate forms automatically <kaz> [20]Example 51 [20] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#example-51-thing-description Sebastian: right Cristiano: this issue is really linked with the work we are doing in the scripting API Sebastian: yeah it can be multiple ways … in ediTDor we ask to the user Cristiano: I think there's two phases. One filling the placeholders and the other filling missing required properties Sebastian: yeah I agree. I'll describe the process focusing more in the in end goal Daniel: +1 to Cristiano's point … it might be valuable to have shared algorithm for PartialTD->TD process Koster: in ODM we have a more schema oriented approach. We should spend sometime to think about it … approach about placeholders Sebastian: schema approach? Koster: Like macro preprocessing … we could use an object instead of the place holder. … the object could act like a schema Sebastian: placeholder are easier for overriding Koster: in ODM it is a not-mechanically checkable rule that states that if you are overriding something you should maintain the semantic. Sebastian: by the way there's a npm module which is doing the heavy lifting for replacing placeholders Daniel: first comment is about the required. I'll post on the github issue <Ege> dape, I am in your service: [21]https://github.com/w3c/ wot-thing-description/issues/1046 [21] https://github.com/w3c/wot-thing-description/issues/1046 Daniel: I am not sure if we need to enforce a particular style for placeholders … it could be just a best practice Sebastian: I can lessens the wording. <Ege> [22]https://github.com/w3c/wot-thing-description/issues/ 1047 [22] https://github.com/w3c/wot-thing-description/issues/1047 Sebastian: ok PR not merged, it needs more iterations <Ege> [23]https://github.com/w3c/wot-thing-description/issues/ 1045 [23] https://github.com/w3c/wot-thing-description/issues/1045 Sebastian: (capturing TODOs in the PR) <kaz> [24]Sebastian's comments for PR 1024 [24] https://github.com/w3c/wot-thing-description/pull/1024#issuecomment-776855059 Sebastian: thank you for the feedback issue 1020 <kaz> [25]Issue 1020 - Which is better to actuate devices, invoking ACTION or writing PROPERTY? [25] https://github.com/w3c/wot-thing-description/issues/1020 Sebastian: current definition of actions or properties it is not very precise … different people use properties or actions for the same concepts … ok there's more comments on the issue. Let's discuss next time adding term for stream of data <kaz> [26]Issue 1044 - Adding term to indicate a stream of data [26] https://github.com/w3c/wot-thing-description/issues/1020#issuecomment-776676562 Ege: currently scripting api define how to handle stream of data however there's no way to understand that from TD Daniel: it is kind of a hint Ege: to me it is a requirement … kind of contentEncoding Cristiano: it might be more an hint … but we need more experience with the new api to judge Sebastian: I agree, leave issue open … however I'm surprised to see that content Type could be also an array. Ege: +1 Cristiano: +1 Kaz: out of time Sebastian: adjourned Minutes manually created (not a transcript), formatted by [27]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC). [27] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 3 March 2021 10:15:44 UTC