Meeting minutes
agenda
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://
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://
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://
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 "5.3.4.1 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
+1
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
https://
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
adjourned