10 March 2021


Cristiano_Aguzzi, Ege_Korkan, Kaz_Ashimura, Klaus_Hartke, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima
cris, kaz

Meeting minutes


Sebastian: no guest today

Sebastian: we'll start from the modbus biding pr
… then go trough the issues
… in particular about the additionalResponses topics
… is there anything else
… ?

Ege: there's a PR about the required term
… is this included in the agenda?

Sebastian: kind of we have a PR point in the agenda

previous minutes

<sebastian> https://www.w3.org/2021/02/24-wot-td-minutes.html

Sebastian: no call last week because of PlugFest
… then we discussed CR/PR planning
… collected some topics for the F2F meeting
… discussed the additionalResponses
… finally we merge a PR about TM json schema

Sebastian: ok, any objection to publish the minutes?
… ok, minutes accepted

Sebastian: ok then a quick update. I'd suggest skipping next meetings during the f2f
… any comments about the f2f agenda?

<kaz> TD day on March 24

Sebastian: ok

Modbus binding

Sebastian: cristiano has updates about his PR

PR 109 - Refining Modbus protocol binding

Cristiano: captured the discussion so far


Cristiano: would like to get feedback
… what is lacking and nice to have is URL for modbus and the other binding

Ege: should be sort of another content for chapter on URL scheme
… modbus TCP
… applied to RTU

Cristiano: need to specify that
… not sure which one to try first, though

Ege: modbus standards to be referred

Sebastian: we should have a subsection on the base URL
… for modbus scheme, etc.
… also we should think about the title of the document

Sebastian: another question is "entity and function"
… what do you mean?

Cristiano: depends on the modbus vocabulary

Sebastian: not typically to have the information on the header
… maybe a separate section
… reference section

Kaz: agree with Sebastian, and think we should discuss how to deal with this document
… possibly (1) an example section or (2) a separate best practice document

<Mizushima> +1

Koster: we have protocol binding template document which defines how the binding works
… new binding could be added without changing the model
… but actual binding examples like modbus binding would cause too many dependencies
… for binding templates, we want interoperability
… not really sure about the procedure but we could produce multiple documents for the guidance
… e.g., modbus binding

Cristiano: that's my understanding as well

McCool: we can add informative notes if needed

Kaz: right

McCool: easier to mange is important

Cristiano: right
… btw, the ontology itself here doesn't exist

Sebastian: would agree too
… the situation around IoT changes everyday
… what you have to do for the possible protocols in the future?

Cristiano: have some more thing to do as well
… so can wait before merging
… e.g., I'd like to add additional sections based on the comments

Kaz: btw, you use the same tool to generate the HTML based on the template HTML like the TD spec. right?

Cristiano: exactly

Kaz: btw, why there are so many changes with the .gitignore file as well?

Cristiano: let me check


Klaus: which ontology are you using here?

Cristiano: this was created by a student of Ege
… for modbus nod-wot binding
… so basically we ourselves generated it

Kaz: so the final modbus ontology might be bigger

Cristiano: right

Sebastian: Ege, your student reflects the existing modbus standards. right?

Ege: yeah

Sebastian: maybe we should ping the modbus community to review this

Sebastian: for example, about security for modbus

Cristiano: once it's published, we can get more feedback

Koster: maybe there are some terminology questions

Cristiano: ok

Klaus: do we classify everything?

Cristiano: you have classes and properties

Klaus: HTTP in RDF doesn't use this grouping
… maybe for COPA, MQTT, etc.?

Cristiano: right
… not for HTTP here

Klaus: btw, what about CoAP binding?

Sebastian: also interested in that
… and wanted to ask you, Klaus, about that :)

Klaus: you can see the possible values here
… what I did is automatically convert this
… that is the 1st step
… and then we could tackle CoAP binding

Cristiano: basically there are 3 scripts here
… which were generated by Victor

Klaus: can generate a TTL file and convert it to RDF
… the TTL are to be reviewed

Sebastian: in that case, you both (=Cristiano and Klaus) can work together offline

Cristiano: can help Klaus

Sebastian: let's make a prototype based on this description (=coap.ttl) first
… thanks a lot for your hard work
… remaining question is modbus security

Sebastian: we should reach the modbus community

Cristiano: yes, we could try

<Ege> https://modbus.org/

Ege: there's something going on in the modbus community
… not properly a standardization. (see link above)

Sebastian: Itachi is member, we could also aske them

<sebastian> https://control.com/forums/forums/modbus.36/

Koster: the real name is the modbus organization

<kaz> topi: Defer issues to TD 2.0

Sebastian: ok, let's move the next topic

<kaz> Issues to be deferred to 2.0

Sebastian: btw please look for propose closing and TD 2.0 labels

PR 1058

<kaz> PR 1058 - WIP: Add JSON pointer assertion to definition of body sec location

Sebastian: let's start form add json pointer assertion to definition of body sec location #1058

McCool: we discussed briefly on the format of the json pointer.
… any further comments are welcomed

Sebastian: is the json pointer format standard?

McCool: yes it has its own RFC. it has been around from 2016

PR 1060

<kaz> PR 1060 - fix issue #980

Sebastian: I fixed an issue with @type for contentEncoding in the context-1.1.json ld
… should we merge it?
… merged
… issue 980 closed

<kaz> Issue 980 - Definition of contentEncoding should be of type xsd:string

PR 1061

<kaz> PR 1061 - Fix cardinality of Link.rel

Sebastian: in the current draft the type of link type and rel is wrong. it is string or array but we didn't agreed on this change
… this pr fixes this problem

<kaz> Preview of " Link"

Sebastian: it seems that the problem is not completely solved in the PR. rel field is still anyURI whereas previously was simply string
… I'll ask victor to look at it

PR 1065

<kaz> PR 1065 - fix: the "required" keyword was placed incorrectly in the TM schema

Sebastian: simple PR about fixing the validation of TM. It basically wildcard the term required. However, I don't like the required implementation so I think we should directly improve the implementation instead of validating

Ege: he edited the wrong file, we should describe the process

Cristiano: we can set up a github actions saying which file should not be touched

Ege: cool, can we set up the github action?

Kaz: right he should edit the index.template.html
… we could do the process manually also
… there's two separate issues validation and the generation

Sebastian: not easy we should involve victor
… we automated the process to avoid mistakes

Ege: I think we diverged a little bit. I would like to have simply the validation

Sebastian: btw I updated the discussion on the issue with the comments.

Kaz: PRs should be generated by the editors
… or at least included in the editors group
… it might be good to file an issue and the editors will create the PR

Sebastian: ok next topic

Issue 1053

<sebastian> Issue 1053 - Consider adding DataSchema to response and additionalResponses

Sebastian: it is about the new additionalResponses

McCool: btw additionalResponses is not a subclass of regular responses. For example contentType is mandatory

Sebastian: and it has also schema

McCool: yes

McCool: there's question if the additionalResponses should be used for successful responses
… not sure about examples but I suspect there're some API which as different dataschmas

Sebastian: in the issues we discussed if it is good to have the schema in the additionalResponses

Koster: exactly I wrote about this in my comment

McCool: we could rename it as errorResponses
… the default behavior should be a protocol generated response

Sebastian: in the issue I created an example using json pointers
… we could introduce addtionalSchema

McCool: yeah we could make it an object
… then we have to decide to use json pointers or json schema pointers

+1 for additionalSchemas

McCool: we could use names to define addtionalSchemas

Koster: +1

McCool: that would allow to reuse schemas


Ege: also we could use this feature to help TD designers
… so that they could not repeat the schema

McCool: like the idea, let me update the PR

Ege: should we restrict the kind of data to be put in the additionalSchemas?

McCool: should avoid using pointers to much

McCool: btw with definitions we could avoid using json schema pointers

McCool: we should use json pointers than schema it is standard

Cristiano: good the direction, I like it. Keep in mind that it might get harder to parse the TD in a linear way
… canolization could help

McCool: agree, but I would avoid to expand pointers cause we could reduce the bandwidth

Sebastian: good point about parsing, but this is an exceptional situation
… it might not be present in all TDs

klaus: +1 it is a good practice to have a well defined place

Cristiano: it is easier also to validate

McCool: ok, I'll work on the PR to bring these updates

Sebastian: this concepts we could reuse for log running actions

Sebastian: I'd put that the same place of URI variables

McCool: btw you can define objects in uriVariables which is difficult to serialize
… at least we should add an assertion

Koster: it might be some way to serialize objects to URI

McCool: btw if disallow having object in URI we could re introduce it later.

Issue 1047

<kaz> Issue 1047 - Two step generation of the TD from a TM should be clear

Sebastian: how to generate TDs from TMs

<mjk> (Koster leaves)

Sebastian: cristiano made a point to make the last points towards the term partialTD

Sebastian: afraid that the partialTD could confuse

Cristiano: yeah it might, but we have the definition in the architecture

Ege: also partialTD is not so hard to understand. it should be clear the difference between a TM and a partialTD


Sebastian: good I'll provide a pr

Issue 1037

<kaz> Issue 1037 - The "body" location value for security schemes is underspecified

Sebastian: it seems we could close this one

McCool: it needs to be closed only after merging the linked PR

Sebastian: ok next time then

Issue 1020

Sebastian: defer to the next meeting, it is really interesting because it compares our definition of action and properties with other standard

Kaz: totally agree
… my impression is they don't really restrict the usage of actions or properties
… it depends on the implementation
… actually, that's why I've been asking you all to generate guidelines from our previous experience in plugfests :)

Cristiano: it depends a lot if you are modelling a new device or mapping an old one to wot

Koster: it is good to discuss this. I spent a lot of time describing the usage of actions to rest guys

Kaz: we could have complicated actions, e.g., changing the brightness within one minutes gradually
… in that case, using properties would be very hard

Sebastian: yeah I would use actions
… let's discuss next time


Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).