Meeting minutes
Agenda Review
<kaz> agenda for today
Ege: In the binding templates part there are a lot of PRs
… but we can add them to the agenda once we get there
… then we have a lot for TD next
… we have prepared the agenda in advance, does anyone have any other points?
Kaz: Please make sure that the agenda includes Michael McCools points regarding WoT resources
Ege: I'll add it to the agenda
Minutes Review
<kaz> Nov-29
Ege: I glanced over them, look good to me
… (scrolls through the minutes)
<kaz> i|grance|Nov-29|
Ege: any objections to approving them?
No objections, minutes are approved
Cancellations
Ege: I won't be available from December 26 until January 2
… common in Europe
… does anyone prefer to have the calls in this period?
… otherwise I would suggest to cancel them
Daniel: I think there was a general agreement to start again on January 8
Ege: Generally hearing no objections to the cancellations, then I am going to cancel the meetings and update the W3C calendar
… (cancels the calls in the W3C calendar)
Kaz: Just to make sure: Since the calls on January 8 have already been cancelled, your intention is to start again on Jaunary 10, right?
Ege: Yes
Kaz: and the second part on 11th
Ege: yes, I will talk about that shortly
TD Call Slot
<kaz> https://
Ege: There have been no objections to the new TD call slot as determined by the doodle poll
… with the results, the current proposals are Wednesday, first hour of the current TD call and Thursday after the main call
… the split of TD and binding templates between the two slots is up for discussion next
… I will prepare a proposal for a resolution for the new slots
<Ege> proposal: switch the TD call slots to Wednesday 10am EST (1 hour) and Thursday 9am EST (1 hour)
RESOLUTION: switch the TD call slots to Wednesday 10am EST (1 hour) and Thursday 9am EST (1 hour)
Ege: Any objections to the proposal?
No objections, resolution is passed
Ege: The next question is how to split the topics between the two slots
… might have the benefit of attracting more people
… who interested in a certain topic
… otherwise, we could also split the topics in a more flexible way
Koster: I think it makes sense to have the adminstrative things in a certain place, not sure about the rest
… one proprosal would be to move the adminstrative things to one hour and treat the other one more as a working hour
… so it could rather be a adminstrative/working split rather than a TD/binding split
Ege: Since we agreed to integrate the binding mechanism into the TD spec, this division is not as clear anyway
Mahda: Generally, I'm in favor of a split because binding topics tended to not be included in the call. But a more flexible split could also work
Cristiano: Depends a lot on the agenda, but given that the agenda is agreed upon beforehand, people can just decide based on the agenda. I think I would prefer flexibility
… most important is to agree on agenda beforehand
Ege: One common thing mentioned is that we don't have enough time for binding topics, so maybe we can agree on a general separation and then carry over TD topics if needed
Kaz: I am generally fine with both approaches, but at the current point in time having a general split might work to determine how exactly the split should look like. More importantly, use case and requirements discussion should have more time. Generally, I agree with your proprosal, Ege, but we need clarification on how to organize TD/Binding discussion in general.
Ege: My initial feeling is to not do a too strict separation
… but people need to know how to arrange their calendar
… so, for example, if they know that bindings will always be on Wednesdays
… we should probably agree on the first topics that should be discussed in a call
… then the rest can stay flexible
… what do people think?
Cristiano: Sounds alright to me
Ege: (adds a summary of a possible direction to the Wiki)
… I am mentioning "Bindings" here to make clear that it is not necessarily about the binding mechanism but can also be about specific protocol bindings like Modbus, for example
… so this is decided for now
… does anyone have more comments in this regard?
No comments
TD 1.1
Kaz: Maybe we could start with the publication of the specification
<kaz> WoT Thing Description 1.1 Recommendation
Ege: TD 1.1 is now a W3C Recommendation
… thanks to everyone, I think the final document is now in a great shape
… there is an official press release, which you can you use to let people know
<kaz> Press Release
WoT TD 1.1 Resources
<kaz> TD 1.1 resources
<kaz> TD 1.0 resources
Ege: The resources table is wrong at the moment
… currently, there is only the .ttl file mentioned for the Thing Model but not the HTML file
Mahda: Is this related to the svg file issue?
Ege: Probably, yes
… I will update the issue to deal with empty TM documents in general
… (updates TD issue 1385)
… we can update the files and then update the table accordingly
… the SVG does not necessarily have to be updated, however
… then we can update the redirections
<kaz> TD 1.1 resource table
Kaz: Just for the record: This only concerning TD version 1.1, right?
Ege: Yes
Jan: And this is about the TM ontolology, right?
Ege: Yes
Ege: After the update, we can remove the "Draft" annotation from the README
… for TD 1.0, that should already be possible
… (updates the README file for TD version 1.0 accordingly)
… (includes the changes in wot-resources PR 18)
… can we do it here or should we do it in the main call?
Kaz: We can do it here since version 1.0 is already published, but we should also do it for version 1.0
<kaz> wot-resources PR 18 - Removing draft from 1.0 resources
Ege: (merges wot-resources PR 18)
Binding Templates
PR 298
<kaz> PR 298 - Add additional explanations to vocabulary creation guide
Ege: This has gone through a lot of a reviews, thank you everyone for that
… there is some points open, which we can have a look at here
… (opens the diff)
… there is one comment regarding "automatic" validation, which we could remove
The group discusses editorial changes and Ege updates the PR accordingly
Ege: There is one comment by Cristiano regarding the mapping.ttl and the SHACL file
Cristiano: The context.jsonld (?) is doing the actual mapping, that is what I meant here
… hadn't had the time to make a concrete proposal, we can move this into an issue, though
Ege: The rest should be resolved, then I am going to merge this and create an issue for the remaining comment
… (creates the issue)
… with that done, I think we can merge
… (adds a link to the new issue and resolves the open comment)
… any objections to merging?
No objections, merging
PR 324
<kaz> PR 324 - Adding Jan Romann to CoAP codeowners
Ege: Very small PR, proposes to add Jan as a Codeowner for the CoAP binding within the CODEOWNERS file
… Kaz has updated the GitHub Team for Editors as well.
… there is ongoing discussion among the chairs how to maintain this list
Kaz: I am not objecting to the change
… but generally asking, this is about the Editor's group on GitHub, right?
Ege: Yes
… since there are no objections, merging
Merged PRs
<kaz> Editorial changes
Ege: For the sake of transparency, based on our asynchronous decision policy, I merged three editorial PRs
PR 325
<kaz> PR 325 - Add BACnet to tables
Ege: This PR adds the BACnet binding to the table in the Binding Templates document
… it got several reviews
… and approvals, merging this one
PR 323
<kaz> PR 323 - Fix some typos in Modbus
Ege: There was some discussion about this one
… most comments have been resolved, but I just see that there is a new one
Daniel: I don't know where it comes from actually
… didn't do any change here, committed the changes via the GitHub UI
Ege: I think these are just whitespace changes
Jan: Maybe it is related to line endings?
Daniel: Unlikely, since it is comitted via the UI
Cristiano: My OS is sometimes making these changes, but should not have happen on GitHub
Ege: Probably an error caused by GitHub, but we can fix this later
… (merges the PR)
PR 331
<kaz> PR 331 - feat(modbus): introduce modbus type and byte/word order
Ege: PR went through some reviews
Cristiano: there is 1 last pending issue
… 2 open issues we can handle in a follow-up PR
… Note: XSD does not have ontology -> hard to understand how those terms are defined
… Mahda suggested revisions
Mahda: Understood Cristianos comment
… not sure about name individual or classes
… we could use them as name individual
… the other comment I had was about consistency
… w.r.t. oneOf
Cristiano: I think we can tackle it in follow-up PR
… suggest to move on with this PR as is
Mahda: SHACL uses enum, right?
Cristiano: Not sure..
… I don't think so
Ege: Let's create a new issue for it
Ege: I think we should check other bindings (besides Modbus) as well
<Ege> w3c/
Kaz: Can understand potential need for those features, but still not really expectation of implementations
… processor handling this additional type?
Ege: basic processor probably not..
… node-wot has drivers for protocols
Kaz: those mechanisms should be clarified
Ege: Correct, we just barely do this
Kaz: We tend to assume node-wot as typical implementation but need to check others
… could add Editors node as well
Ege: PR 331 looks good -> merging
… for the open 2 issues I will create issues
Ege: arghh , merge conflict
Cristiano: given it is about ontology .. we could merge either way.
… anyhow, let me re-generate the onotology
Ege: Ok, great.. Cristiano can merge PR once conflict is resolved
TD Next
Project Management: How do we organize the work?
Ege: Let's recap
… common agreement was that 1 person gets amount of work
… for a given time
… making sure person is working on it...
… or work is split
… prioritization should be also possible
Ege: for example
<Ege> https://
Ege: everyone should see the topic board
<mahda-noura> +1
Kaz: using Github management capabilities might be useful
… anyhow, we need to have clear procedure definition
<kaz> and template like the W3C Strategy Team's Incubation Pipeline
Kaz: and template
<kaz> strategy pipeline
<kaz> Issue template
Ege: Procedure is fine
… not sure about template
<Ege showing GH capabilities>
Ege: "Moving" issues allows to assign persons
… created tasks can be assigned
… moving issue/task to "Sorted" once we have know what we have to do
… "In Progress" shows issues being worked on etc
… "In Progress" column should stay small per person
… and simple
… no experience so far with it.. so feedback is welcome
Cristiano: Looks good
… we should try how it works out
Ege: We can also create subtopic while keeping the overall topics as well
Kaz: I am not objecting
… but we need to use specific template/procedure
… and how to review etc
Ege: Yes, we should document it
Kaz: W3C uses it as well
… for chartering process
Jan: Benefit is to have issues from multiple repositories
… e.g., issues coming from security
… there might be other topics as well
Ege: Good point
Analyses
Ege: No news
Use Case Analysis and Requirement Extraction
Ege: Shortly mentioned in main call
… should extract requirements from use-cases
Project management - revisited
<kaz> WCAG2ICT Note Update
Kaz: sorry but found another example for GitHub project
Use Case Analysis and Requirement Extraction - revisited
Ege: looking at existing use-cases
… how did it happen for security ?
Jan: In discovery case it was already linked
… not sure about security
Mahda: started the work for security
… had table for use cases
… we had 4 categories
… use case linking to category
Ege: categories were coming from where?
Mahda: General categories
… if for use-cases category was missing we added new category
Ege: I think we have categories already
<Ege> https://
Mahda: columns are the categories in the CSV
… afterwards we want to define the requirements
… discovery is different.. there are no categories
Jan: discovery had a pre-existing list
… Section 4.3.6.1 in discovery spec
<Ege> https://
Ege: it seems we need to find the requirements we already have
… strange
Kaz: I tend to agree with you, Ege
… wot-usecases/USE-CASES directory and the Use Cases document itself already have categories of use cases. on the other hand, "Public Service", "Private Information", etc., are rather aspects of potential risks.
… seems we need to reboot use-case task force
… and the Use Cases TF should talk with existing task forces
… to get nice refactoring / description etc
Ege: Not sure what we can do as a task force right now
<Ege> https://
Ege: did the coverage work a while ago
… this is just some sort of categorization
… concerning that it is done differently
… do we have such categories?
… it is more like tagging
Mahda: what do you mean by tagging?
Ege: not just one category.. but several tags
… I think we need further thinking
<Ege updating wiki with the links & information that have been collected so far>
Daniel/Cristiano: Did not do/start this coverage work for scripting
Cristiano: table did not suit the scripting work
Jan: Had difficulties to decide whether requirement matches given use-case
… need to work on that as well
Ege: I had the same impression
… we need something specific
<kaz> wot-usecases Issue 192 - Adding new fields to templates
Mahda: Even harder for TD to map
… use-case is more general
Ege: we have to go through all use-cases and extract the type of information we need
… this is a huge amount of work
… maybe also contacting people providing the use-case
… we need to go back in time why we have some features in the TD
Kaz: I agree with you, Ege
… we should revive use-case work
… at the moment I think we can start with new use-cases, and maybe we can pick up some of the important use cases from the existing Use Cases document as a starting point.
Ege: Agree. As TD task force we can collect what a use-case should have
… any other task force can do the same
… this should lead to a new template
[adjourned]