Meeting minutes
previous minutes
<kaz> Mar-30
McCool: seems ok
… I'm sure I've created the OPC-UA call but there were some problems with the calendar
… sorry for the confusion
… btw we now a name for the core profile. it is based on http
… do you see any problems with the minutes?
… minutes approved
OPC-UA liaison
McCool: two things to talk about
… one is technical requirements and goals
… then we have the discussion about the collaboration with the opc organization
Technical requirements
<McCool> PR 1020 - Technical Requirements for OPC UA/WoT Binding #1020
<McCool> https://
McCool: two open points: objectives and deliverables
… as far as technical objectives
… we want that a wot consumer should be able to use an OPC-UA server as a thing
McCool: another thing is to integrate WoT TD metadata in OPC UA servers
… integrate also with discovery
… the endgame is to have WoT TD metadata be part of the OPC-UA vocabulary
… therefore we have to build different documents
… an onthology
… protocol binding template document
… then define a process to transform an UA NodesetFile to a WoT Thing Description and vice versa
… is there also a OPC-UA way to discover TDs ?
Lagally: I would first start from use cases
McCool: we can add it to the use case document
Lagally: I would not go with the metadata with the objectives
… what's the purpose of sharing metedata
… do you mean understanding tds?
McCool: a consumer needs to interpret metadata
Lagally: this means that a device described by a TD should be usable in the OPC-UA ecosystem
McCool: it is more about using opc-ua devices from a wot consumer
… it would be nice to have bidirectional interaction
… like a servient
Lagally: ok thank you
Lagally: d1 and d2 would they depend to each other?
McCool: yeah d2 depends to d1 but not the other way around
Lagally: right
… this begs the question who does what. Do we need separate groups ?
McCool: I think we can defer this conversation later
Lagally: ok
McCool: I'm going to merge the PR, if people want to make suggestions the y can edit the file
Sebastian: I agree with the objectives
… we need to sync with opc-ua
… especially for discovery
… we should also be realistic and stick with a small set of objectives
… we can prioritize task items
McCool: I agree
… however we need to be sound, and cover the industry needs
Kaz: great starting point
… we need to discuss about the process viewpoint as well
… also at some point in the future, we should think about potential integration with the other ontologies as well like IEC
McCool: we need to set up a set of liason call to discuss these points with them
<mjk> Discovery Binding
<mjk> +1 Discovery Binding
cris: two things: there might be difficulties with mapping opc-ua data model into wot data model
… plus I think the discovery derivable can be part of a greater discussion about how to map discovery methods in WoT
… Discovery binding
McCool: I agree maybe for Discovery 2.0
<mjk> Cristiano, do you have a summary of the issues in data model mapping? Would like to review
sadly no :( we had a very long call and in the end we decide to hide opc-ua model from WoT applications
… I think in the node-wot implemetnation there's an option to force the runtime return OPC-UA specific payloads
… i.e. timestamps etc.
process
McCool: we can start from a small group of people
Sebastian: we need people also from opc-ua foundation
… there's no working group taking care about wot integration there
… I know people interested in this integration
… I can contact them
… and invite them to this call
McCool: I suggest to bring up a good techinical proposal for opc-ua
… and ask for review
… and refine the proposal
… after we can go to the technical board?
Sebastian: ok I will ask interest people to join
Kaz: I agree with McCool's proposal
… also other groups don't have dedicated people working on wot
… they just join our meetings when the feel like
McCool: we have some action items
… gather people and input
… doodle pool for people to meet
… after this we can discuss how to organize things between the two organizations
Lagally: why don't we ask directly to the liaison officer in the OPC-UA foundation to look for interested companies
McCool: it would be better to trust Sebastian for this
… for the technical discussion
<kaz> OPC Liaison contact is Mr. Stefan Hoppe
Sebastian: we can but maybe we don't wont managment people for a technical discussion
McCool: right
Kaz: keep the Liaison Team in the loop, we have the mailing list, team-liaisons@w3.org
McCool: I agree
Use Case coverage
<kaz> coverage.csv
<kaz> wot-usecases Issue 189 - Clarify Expectations for Coverage Table
Lagally: we published the use cases document
… the second version is available
… in the repository we have the converage.csv
… what is the purpose of this document?
… I believe some clarity is required
… I wrote an explainer
… the table has a column for use case name and section number
… then we have a column for each deliverable
<Ege> I would like to discuss about https://
Lagally: for example reading the use cases there are a set of requirements/gaps
… the goal of the table is to find specific gaps in each wot deliverable
… I also added a comment column
… mccool is working on another table with requirements
… is summarizing the requirements from the use cases list
<mlagally_> https://
McCool: I created this requirement table
… we should identify also if the requirements comes from different use cases
… status of the device is an example of requirement that is in multiple places
<kaz> wot-usecases PR 191 - Create requirements-summary.csv
<kaz> proposed requirements-summary.csv file
McCool: I want to suggest to use this table to enrich the coverage.csv with a quick definition
… I grouped security and privacy requirements in their own section
… I want to merge this PR so that we can collaboratively edit it
Daniel: coming back to coverage.csv, it is not about coverage itself. it's rather about gaps
Lagally: correct
Daniel: looking at it from the scripting api point of view is hard
… I'm not sure if the use case is meant to work with script api as it might be written with scripting api in mind
… but they are just application descriptions
<sebastian> I need to go. See you in TD call
Daniel: got it
Ege: added an issue
… we need dedicated sections to point directly to wot deliverables
Lagally: I agree, but we can do it in a second phase
… can I ask you to create a PR ?
Ege: I want to discuss it in today's PB call
Lagally: yeah we can start from there
Kaz: I tend to agree with Mccool
… but we need to define a policy
Kaz: my question is whether we want to do this effort for the current 1.1 version specs or not, if we want, we should rather go for a summary level description on which technical requirements should be covered by which spec(s) rather than detailed use case template. If we want to do this for the 2.0 spec work, we could try detailed gap analysis, though.
McCool: aob ?
McCool: adjourned