Meeting minutes
Agenda
Koster: any changes or feedback to the agenda?
Ege: one agenda per week from now on
Koster: also we will review minutes accordingly
… wednesday of last week on wednesday of this week etc.
Minutes Review
<kaz> Jan-11
Kaz: I will fix the names
Kaz: there was a confusion with the links, now it should be fine
https://
Koster: Jan-10 minutes approved
<kaz> ss/html/html Jan-10 (which actually to be reviewed :)/
Resources
PR 1940
<kaz> PR 1940 - Fixing the Ontology HTML files to static versions
Koster: should we review all files
Ege: no we have left it open for a week so that people can review
PR 1933
<kaz> s|minuts.html|minuts.html Jan-10 (which actually to be reviewed :)|
<kaz> PR 1933 - toolchain description update
<kaz> big picture of the tool chain
Mahda: Ege has reviewed it and we have fixed some issues
Koster: it seems that quite some review went into it and this really closes a gap
Kaz: we should split the image and have an explanation so that a non-expert can use it
Ege: we cannot split the image since they are linked
… and we cannot expect a non-expert to use it
Kaz: we need to know what is written and when
Ege: this is explained with the legend of the figure
Mahda: this is correct. The legend and arrows explain it
Mahda: I cannot provide more details, unless we explain "how to write an ontology"
Ege: Maybe we need to understand if kaz means a specific format
Koster: small arrow issue on top
Kaz: a short explanation like, change this ttl file and apply this script to get HTML
Koster: maybe what you want is a more abstract figure, not splitting into smaller files
Mizushima: what kind of IoT network is used and how are the TDs generated?
Mahda: this is the tool for the specification. we do not manually edit the index.html
Kaz: maybe you use one big script but there are modules right? they can be explained separately. that kind of high-level description would be useful for maintenance purposes, specifically in case the original author lefts the WoT WG.
Koster: Will it be similar for someone creating a binding?
Mahda: it is similar
Ege: yes, some steps are not needed
Cristiano: about 80% similar I would say
Koster: we can merge right
Ege: yes
Jan: I did a similar thing for discovery. I think we can write a more generic tooling
Koster: really good point
TD
PR 1945
<kaz> PR 1945 - Assertion id alignment
Kaz: OK with merging this PR 1945 itself, but we should make this a policy
Ege: I can provide that to the wot repository
Koster: yeah that way we have a set working way
wot PR 1165
<kaz> wot PR 1165 - Initial expansion of the DataMapping work item
Koster: Luca, could you explain?
Luca: I have expanded the description based on the description from last week
Luca: we can extend this into a use case
… but we had talk about it already last year
Koster: we have a small discussion
Ege: we discussed yesterday. For me it is clear but I am not sure if it is for everyone
Luca: there is a proposal to rename it
Koster: maybe out of band
Luca: actually it is inband
Koster: or data that is not consumed by application?
Luca: actually it is consumed
Luca: (explains the examples)
Koster: ok I get it now
Cristiano: luca confirmed but basically I wanted to ask whether we also consider complex payloads
Kaz: this discussion is a good starting point, but we should sync with the use cases task force. for example, once the updated use case template is published by the Use Cases TF, we (as the TD TF) should clarify this idea based on that updated template.
… and use the new template
Koster: I agree
Ege: we need to be able to convey such technical information in the new use case template
… but we already have the requirements sort of ready
… maybe we should say that (sadly) td can express one channel and we need to express more
Luca: except uri variables
… I will work on it this week but I will need help
Koster: any other points?
… adjourned