Meeting minutes
Agenda
<kaz> Agenda for today
McCool: We did not discuss TPAC last time, so we should focus on that today
… other than that, we have a few ontology topics to resolve
McCool: To better organize ourselves, I prepared an agenda for next time so that we can assign "homework" for the next meeting as we go along
Minutes Review
<kaz> Sep-18
McCool: Technically, everyone should have read it, but I want to give people the chance to go through
… does anyone have an objection to publishing the minutes without review within the meeting?
No objections
McCool: Minutes are approved
Ontology
<kaz> PR 516 - Create "resources" directory to capture frozen resources for publication
McCool: There are a few things we need to take care of
… mapping from URL to file
… encoding questions (e.g., UTF-8)
… GitHub links need to fixed
… we should create a frozen state and put in a separate repo or a subdirectory
… any other thoughts?
McCool: Let me start with a list of things we need to take care of
… problem is, if we add things without testing, there is the problem that links are broken
… potential solution: add links and make a candidate release
… then test the published version, e.g., content type
… and check every link
… until publication happens
… before, a frozen version needs to be captured
… we should do this in two steps
… there should be a "local" version first and then a "global" version
… we should do at least the local version
… any comments?
Kaz: I still have a bit of a strange feeling regarding the local version under the "publication" area
… if we create another dedicated directory, that's fine
Andrea: From my side, it's fine
<kaz> NAMESPACES.md including proposed URL mapping
McCool: Regarding the mapping, the TD repository chose a different route with a "NAMESPACES.md" file
… however, they have a more complicated situation
… they have GitHub URLs
… pointing to the main branch, which can be updated, which seems a bit dangerous to me
… furthermore, we should probably also be explicit regarding the charset
… how do we want to deal with this to be consistent?
… We could use NAMESPACES.md to be consistent
… although I am not happy with the format
… GitHub URLs should point to a frozen version
… can anyone explain the background here?
… why are there two states ("current state" vs "desired state")? Is there also a reorganization?
Kaz: Yes
McCool: The links in the TD file are also the old ones
… we should create a resources directory in our repository
… and use their format to be consistent
<kaz> i|regarding the mapping|NAMESPACES.md including proposed URL mapping|
McCool: (creates a directory and a README.md file to capture the frozen resources for publication)
… later on, I will copy the appropriate resources over
… (creates a PR with the changes)
… will not merge this one yet, but copy the resources first
… I will add a comment to the existing issue 509 regarding the PR
… the PR does not have the most useful name yet
… (changes the PR title)
… (adds a description with todos to the PR)
… the other thing I am thinking is that the namespace mapping should be for each file and not for everything, so should that we can do it for each version
… then we can add new URLs for each version
… let's copy over the README content for now
Jan: Just a general question: Is it common to host resources on GitHub? Or are resources moved to a W3C server eventually?
Kaz: Discussion within WoT working group was to have them on GitHub to be able to maintain them easily
McCool: I think the opposite should be done, once resources are finished they should be fixed and published like a specification, to enable caching for example
… the other thing is reliability, for which GitHub might not be the best infrastructure
… however, in the short term redirecting to GitHub should be fine
Kaz: I think we had this discussion for several months one or two years ago with the decision to host the resources on GitHub
… as W3C does not provide an account to maintain the resources to members anymore
… my proposal for about two years was to simply use the "ns" namespace for hosting resources
McCool: I think the whole year thing was a mistake, we can simply create an alias
… I am okay with hosting on GitHub, but they should be fixed
Kaz: From my viewpoint, the most important thing is the maintenance policy
… and the question how resources should be updated
McCool: Most important thing should be the organization for now
… put the topic on the side for now, I will create a PR
TPAC Follow-up
<kaz> TPAC minutes - Day 1 - Discovery
<kaz> McCool's slides on Discovery
McCool: We had a short meeting on discovery
… we have the minutes
… which did not capture all of the discussion
… took some notes in the discussion which also did not capture everything
… I already did a summary for security, but we should do one for discovery as well
… there is already a link in the wiki that is broken at the moment
… we should create a document under that URL
… (creates a file in the wot repository)
… let's use the security summary as a template
… (creates PR 1134)
<McCool_> wot PR 1134 - Create 2023-09-14-WoT-TPAC-Discovery-Discussion.md
McCool: multi-protocol support was one point
… with a directory API for CoAP as a sub-point
… as well as MQTT
… another main point was new introductions
… question is: do we want to have a directory API for MQTT? Or do we want to have an introduction method and then query the directory via HTTP or CoAP?
… a directory API using MQTT might be complicated, but having CoAP might be useful for small devices
… (takes another look at the TPAC minutes)
… another aspect was introduction via OPC UA
… (adds a point regarding missing MQTT standardization from OASIS to the summary)
… there was a question regarding the use of MQTT during the exploration phase
<cris_> +1 for MQTT server
McCool: I think it would be at least useful to have an MQTT TD server
… maybe we should add a well-known topic for finding self-describing things
Jan: I think there already was some promising discussion in discovery issues
ca: Should be a low-hanging fruit, in node-wot we already support that
… we publish the TD to a pre-defined topic
McCool: We should define a standard for a pre-defined topic
… so we should add a well-known topic that includes wot somewhere
McCool: The other thing is that we can have multiple TDs for a single thing, but we don't have a directory service yet
ca: CoRE RD could probably be used here
McCool: Let's capture that in the summary
McCool: Generic discovery to handle protocols is difficult, we could delegate that to different protocols
… follow-up comment: if we have a TD for a directory service, can we bind those to multiple protocols?
Jan: Could also bindings be used for defining new discovery approaches?
McCool: Security bootstrapping is also a relevant aspect here
… (adds final comments and points to the summary document)
… let's commit this, I'll add it to the PR, feel free to add comments, next time we'll hopefully be able to merge it
Next Agenda
McCool: One topic will be the review of the two PRs we currently have open
… (adds the links to the wiki page)
… then we will review issues and AOB, anything else?
… Let's leave it at that
[adjourned]