- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 03 Mar 2021 19:15:39 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/02/10-wot-td-minutes.html
also as text below.
Thanks a lot for taking the minutes, Cristiano!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT-WG - TD-TF
10 February 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Feb_10.2C_2021
[3] https://www.w3.org/2021/02/10-wot-td-irc
Attendees
Present
Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan,
Jack_Dickinson, Kaz_Ashimura, Michael_Koster,
Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian
Scribe
cris
Contents
1. [4]agenda
2. [5]previous minutes
3. [6]master to main
4. [7]bindings
5. [8]PR 1032
6. [9]PR 1024
7. [10]issue 1020
8. [11]adding term for stream of data
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|[12]Feb-3|
[12] https://www.w3.org/2021/02/03-wot-td-minutes.html
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> [13]WebRTC REC - collaboration between W3C and IETF
[13] https://www.w3.org/TR/2021/REC-webrtc-20210126/
Sebastian: we need just the ontology
<kaz> [14]Spatial Data on the Web Best Practices -
collaboration between W3C and OGC
[14] https://www.w3.org/TR/2017/NOTE-sdw-bp-20170928/
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> [15]PR 1032 - Add URI template location for security
scheme parameters
[15] https://github.com/w3c/wot-thing-description/pull/1032
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> [16]Sebastian shows section "10. Thing Model" around
"Example 45"
[16] https://w3c.github.io/wot-thing-description/#example-45-mybuzzerthingmodelserialized-in-json
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> [17]PR 1024 - Topics around Thing Model
[17] https://github.com/w3c/wot-thing-description/pull/1024
<kaz> [18]Preview of section "10. Thing Model"
[18] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#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> [19]Example 49 on the Preview
[19] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#example-49-thing-model-with-the-required-term-for-interaction-affordances
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> [20]Example 51
[20] https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/1024.html#example-51-thing-description
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: [21]https://github.com/w3c/
wot-thing-description/issues/1046
[21] https://github.com/w3c/wot-thing-description/issues/1046
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> [22]https://github.com/w3c/wot-thing-description/issues/
1047
[22] https://github.com/w3c/wot-thing-description/issues/1047
Sebastian: ok PR not merged, it needs more iterations
<Ege> [23]https://github.com/w3c/wot-thing-description/issues/
1045
[23] https://github.com/w3c/wot-thing-description/issues/1045
Sebastian: (capturing TODOs in the PR)
<kaz> [24]Sebastian's comments for PR 1024
[24] https://github.com/w3c/wot-thing-description/pull/1024#issuecomment-776855059
Sebastian: thank you for the feedback
issue 1020
<kaz> [25]Issue 1020 - Which is better to actuate devices,
invoking ACTION or writing PROPERTY?
[25] https://github.com/w3c/wot-thing-description/issues/1020
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> [26]Issue 1044 - Adding term to indicate a stream of data
[26] https://github.com/w3c/wot-thing-description/issues/1020#issuecomment-776676562
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
Minutes manually created (not a transcript), formatted by
[27]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[27] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 3 March 2021 10:15:44 UTC