– DRAFT –
WoT Next Charter Detailed Planning - Day 3

Liaisons

Sebastian: I gave a talk in the OPC UA conference
… also a podcast

Sebastian: we are working on a document to agree on the collaboration

Kaz: please explain the background why the liaison is needed

Kaz: So like for further deployments of WoT, e.g. smart factories

McCool: I think for each liaison we should have a use case or requirements etc.

McCool: even for internal liaisons

Sebastian: for opcua we have documents like slides and also use cases

<sebastian> https://www.linkedin.com/posts/activity-7066325889348694016-1ntV/?utm_source=share&utm_medium=member_desktop

<McCool> https://register.gotowebinar.com/register/9175989014285781856

Sebastian: Here are the slides, it starts with HMI23 and intro to WoT
… we can build mashups
… it is complex in IoT though
… then I have shown how OPC UA works
… with TD we can onboard devices into OPCUA
… those devices can have many protocols
… We will also have opcua bindings

McCool: WoT Connectivity WG is from OPCF right?

Sebastian: yes that is simply taking what already exists in WoT.
… However, the OPCUA Binding will be a collaboration

Sebastian: microsoft already has an open source implementation
… they use TDs to onboard devices
… they want TDs, otherwise you have to manually type a lot of stuff
… we can have TDs with OPC UA as well, it fits very well

McCool: so we need a protocol binding for this right?

Sebastian: yes indeed

Sebastian: we have to agree on the terms

Sebastian: security will be tricky, they need terms for that

Luca: it shares the same problems as modbus
… we can address the binary payload problem for both
… you are blind if you have octet stream

Sebastian: in modbus, you can only exchange small data types

Luca: seeing octet stream, you cannot use the data schema

<McCool> (time check, 20m left in the hour, roughly)

Luca: leveraging the data schema or not will be interesting

<McCool> (let's drain the queue, then I intend to suggest moving to the next topic)

we can still represent octet stream, I can explain later on

also, in the slideset of yesterday you can see an example of how cert security is extended for opcua

McCool: we should move on, we should explain why the liaison is needed in general

Kaz: thank you for the background but I am confused. It seems like a proposal from OPC UA side

<mjk> +1 queue up later discussion on data schema and protocol-specific structured data

<McCool> (for each liaison, we need to collect certain information - how the liaison is structured, what the technical goal is, what collaboration is needed, etc)

Kaz: we have to discuss what is for WoT

Sebastian: I can share slides about it, they were communicate in the past

<sebastian> https://github.com/w3c/wot/blob/main/liaisons/opcf/2021-11-30-WoT-OPC-UA.pdf

Kaz: what is our view? What are your expectations as WG co chair?

Sebastian: we have to find good entry points to enable cross domain applications

Sebastian: I would like to move on the next topic

McCool: the goal is to have an opcua binding and them to use TDs for that

Asset Administration Shell

Sebastian: there is activity about having digital twins of assets
… it is standardized by IEC 63278 as well
… there is a working group about asset interface description there, it follows the TD

<kaz> OPC AAS information model

Kaz: I am confused as well. AAS is part of OPC Foundation right
… why did you bring this up?

Sebastian: they have nothing to do with each other
… AAS is not a protocol, it is more like a data structure

Kaz: OPC Foundation people mentioned it when we met a year ago

McCool: AAS need to describe non-OPCUA information as well
… we have to think of them as a separate liaisons
… we should think of how to handle different liaisons

Kaz: if you want to talk about a new liaison, you should make it clear

Sebastian: I have the impression that you do not approve these liaisons

McCool: sebastian has shared that this group is adopting our standard. The question is whether they need more our support

McCool: let's make sure to clarify to situation

Smart Cities

Kaz: smart cities refers to a set of technologies, which includes WoT
… I have organised a workshop with multiple stakeholders, SDOs and companies like Takenaka
… we have seen use case like ECHONET in Smart Home, Takenaka Smart Buildings, Siemens via OPCF on manufacturing
… so I have proposed an architecture where WoT, DID and VC can work together
… after talking with W3M, we have decided on an Interest Group
… we should launch it soon and it will be related to WoT

McCool: what is the goal of the collaboration? Do they need our support or just point to our deliverables?

Kaz: expected deliverable is use cases and requirements
… IGs are also chartered for 2 years

McCool: so start around november is planned?
… so they will start after us, it would be good to get input from them
… I do not want to push geolocation and have a suboptimal solution

luca_barbato can you take over scribing?

Kaz: we should not wait for their results

McCool: can they fast track?

Kaz: there are many relationships

McCool: so this group is more to organize

Kaz: like a central hub

McCool: we will keep things flexible but it would be good to lock down some features

<Ege> brb

Sebastian: Which kind of stakeholders do you want here
… ?

Kaz: Ideally getting representatives from related group:
… iot companies representatives,

<sebastian> I need to go

<sebastian> MM please take over moderation

Kaz: industry stakeholders and w3c groups and external sdo
… concretely: intel, siemens, hitachi and other from the WoT group

Jan: also cities

Kaz: yes, many cities got previously contacted and more are getting involved

<kaz> draft charter

<kaz> latest updates

(e.g. Singapore, Korea, Japan, Brazil, Sweden)

Luca: Do we want to do more outreach on other nations?

Kaz: It is in scope, we need more use cases from even more areas

McCool: let's look at the other liasons

McCool: We have a list of other groups
… and external organisation

McCool: we need to have some structure way to indicate how we are going to interact with them
… we can use the experience with OPC UA and try to replicate it with the other groups

Ege: I support the idea and if we have a joint deliverable with the other party we could
… highlight it different from org that just use WoT.
… or if we have a dependency on them (e.g. ietf)

McCool: we should coordinate with them regarding 2.0 if they already adopted 1.1 to make sure we avoid a python2 vs python3 situation

McCool: We can use the OPC UA experience in this regard

<McCool> https://github.com/w3c/wot/tree/main/liaisons/opcf

McCool: I wonder if we can do the same to track our interaction with other orgs such as ietf

<adds a template entry based on opc>

Kaz: I'm ok with this and it should be useful, and just want to suggest we should use more categories based on their interest (e.g. industry::broadcast, standard::ietf)

McCool: What should we put in the template?

Luca: We should create issues and link the issue from there

<cris_> looks good to me

<pr created>

McCool: Do we need anything else for liason?

Kaz: Given this template, how to proceed and in which call to fill the information about liasons?

McCool: I think different TF have different interaction with different orgs
… we can have a volunteer and review each group during the Main call

Kaz: At some point we need yet another TF dedicated for liaisons. Note that the official Liaison Contact from the W3C side is the W3C Team Contact.

Discovery

<kaz> wot PR 1094 - Discovery Planning

McCool: I prefer working on md files on github
… while ege prefer shared slides

Ege: I'm fine with md

Luca: We can use hackmd for interactive editing, marp for presenting and rendering

McCool: I'm more into having the content well tracked and less on presentation

Kaz: I also prefer having the changes tracked on GitHub

Cristiano: I think depends on the purpose. some tools are better than others

Ege: +1, I assumed we'd have discussion and brainstorming, so I went for slides

McCool: <present the markdown for the Discovery detail plans>

Ege: is it a goal to prioritise the work items?

McCool: This document is about building a priority list and add notes on the detail item

Kaz: When we make planning meeting the aim is to reach consensus

Kaz: and record the remaining issues

Luca: if we want categories we are better of with a github project/issues

Cristiano: One downside of using issues is that we need to make sure the issue alone is that we need good labels, gh project solves it

<mjk> +1 using github project when needed

McCool: I'm afraid we could be locked with gh

Kaz: We can choose the best fitting tool for the job

McCool: back on the needs we have
… in architecture we have REQUIREMENTS/ template
… I'd defer to tomorrow, but I'd like to review how we capture requirements

McCool: Would be nice to see a prototype for project usage

Ege: We have a prototype to show based on the experience with the TD group

Kaz: There is one example of the Strategy Pipeline using the GitHub Projects capability to manage the progress of chartering groups. However, what is more important here is clarifying

Kaz: The more important part is the content on the planning for our deliveralbles like Discovery and TD

<kaz> Strategy Funnel as an example (but Kaz suggests we work on the content first)

McCool: one more thing before we close the meeting

Policy Process

<McCool> w3c/wot#1093

McCool: This is a proposal to streamline how to propose new policies
… look at the PR offline and give feedback

<mjk> the project feature may be a more structured way than using only labels to track progress and dependencies across existing issues and PRs

McCool: any final business before closing the meeting?

[adjourned]