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|Feb-3|
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> WebRTC REC - collaboration between W3C and IETF
Sebastian: we need just the ontology
<kaz> Spatial Data on the Web Best Practices - collaboration between W3C and OGC
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> PR 1032 - Add URI template location for security scheme parameters
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> Sebastian shows section "10. Thing Model" around "Example 45"
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> PR 1024 - Topics around Thing Model
<kaz> Preview of section "10. 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> Example 49 on the Preview
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> Example 51
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: https://
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> https://
Sebastian: ok PR not merged, it needs more iterations
<Ege> https://
Sebastian: (capturing TODOs in the PR)
<kaz> Sebastian's comments for PR 1024
Sebastian: thank you for the feedback
issue 1020
<kaz> Issue 1020 - Which is better to actuate devices, invoking ACTION or writing PROPERTY?
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> Issue 1044 - Adding term to indicate a stream of data
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