Meeting minutes
Organizational
Agenda
<kaz> agenda for today
Ege: Agenda is there way in advance.. please add to the list if needed
Next week
Ege: Question about next week meeting. Public holiday in Germany.
… I cannot chair
Koster: Not sure if there are enough people
Ege: <checking>
… seems enough people ... so we could have a meeting
Mizushima: Japanese holiday is later next week
Minutes
<kaz> Oct-18
Ege: approved
Ongoing General Topics
Ege: For the 1.1 publication we agreed on it last week
… there are some pending PRs
PR 1903 - Delete NAMESPACES.md
<kaz> wot-thing-description PR 1903 - Delete NAMESPACES.md
Ege: Agreed already last week. Any objections ?
… none -> merging
PR 1904 - Copy over last changes to ontology documents
<kaz> wot-thing-description PR 1904 - Copy over last changes to ontology documents
Ege: replicates content to publication folder
… not really needed but for the sake of consistently we should do it
… no objections -> merging
PR 10 in WoT - Moving td 1.0 related contents to td 1.1 table
<kaz> wot-resources PR 10 - Moving td 1.0 related contents to td 1.1 table
Ege: Discussion in main call
… table with ttl. resources ... should be in 1.0 readme
… PR moves content accordingly
Ege: Kaz, can we merge it in this call?
Kaz: Good question
… personally I am okay
… I think we can merge it
… no objections -> merging
<kaz> i|wot-resources PR 10 - Moving td 1.0 related contents to td 1.1 table|
PR 1906 - TM Schema regex error
<kaz> wot-thing-description PR 1906 - TM Schema regex error #1906
Ege: Discussion issue
… late but somewhat a bug
… in TD spec we use a regex
… this regex causes problems with slashes
… e.g., in golang validators
… it fails in Rust also
Luca: Rust does not have regex ... it boils down to a different issue
Ege: according to JSON schema what we are doing is correct
… the problem is it fails in golang
Cristiano: It could be solved by finding workaround or fixing golang
Luca: We could try to setup/point to given JSON schema validator
… it should not be our job to fix implementations
<mahda-noura> +1
Luca: BTW, Rust implementation is fine
… ack luca_barbato
… we could look into libraries that work ... to have better knowledge
Ege: There is a tool that tests 1 schema across multiple implementations
<Ege> w3c/
<luca_barbato> bowtie-json-schema/
Cristiano: we can list supported validators and maybe mark the ones we know that have problems
… I don't think we should fix the JSON schema
Ege: I was looking for other regex
… since our regex is not perfect
… should we keep the *old* regex?
… or should we make it more correct?
Cristiano: I am in favor to be more correct
Ege: I will try to fix it
… I appreciate if someone can help with regexes
… Kaz, is this still fine to update resources that are not index.html
Kaz: Yes, we should/could maintain the resource files separately from the spec itself under /TR. That is part of the reasons we split the schema definition from the spec./
PR 1909 - Inconsistencies in wotsec ontology
<kaz> Kaz: That's also part of my reason I suggest we shift to the easier namespace definition (=/ns/wot) to make the maintenance easier, but let's see the response from PLH about that point.
wot-thing-description PR 1909 - Inconsistencies in wotsec ontology
Ege: Mahda can you explain the issue
Mahda: checked ontology file ...
… class PopSecurityScheme .. is commented out but still referenced
… it causes the ontology to link URI that do not exist
… I removed those references in the domain
Ege: For these ontology files we do not enough testing
… we can/should improve there
Ege: This PR also fixes OAuth2SecuritySchema .. missing vocabulary terms
Ege: I think Sebastian was manually generating the PNGs
… not sure what causes the issue
Mahda: in SVG not everything is considered
… for example if it is not linked/used
… the SVG lacks information
… like in the case of the proxy term
Daniel: PNGs were manually updated over the time
Mahda: The layout is also different ...now I know the reason
Ege: but content is also different .. sometimes
Ege: Will talk with Sebastian
… suggest to generate SVG again and cross-check the results
… w.r.t to PR 1909 I think we can merge
… no objections -> merging
Issue 1908
<kaz> wot-thing-description Issue 1908 - Inconsistencies in wotsec ontology
Ege: Can you explain the proxy issue again?
<kaz> wot-thing-description/ontology/wotsec.ttl
Mahda: looking at "proxy" in wotsec.ttl
… it has no range therefore it cannot connect to anything
… it should be linked with security and something else.. but something else does not exist
… rest is correct.. since other security schemes are subclasses
Ege: Mahda can you provide a fix?
Mahda: SHACL file has same issue
Ege: adding a range would suffice?
Mahda: Will check with McCool
Issue 1907
<kaz> wot-thing-description Issue 1907 - Security Figure is missing proxy term
Ege: looking at issue 1907
Mahda: I think I can provide a fix
… using dataProperty instead
Binding Templates
Figure Fix
wot-binding-template PR 311 - Replace to 'Custom devices' in Figure 1
Ege: same done in Architecture
… merged PR in main call
… replacing "Philips Hue" with "Custom devices"
… for me it is fine
… no objections -> merging
Guide document
wot-binding-templates PR 298 - Add additional explanations to vocabulary creation guide
Ege: PR is still open
BACnet PRs
<kaz> wot-binding-templates PR 307 - [BACnet] Fix examples and one formulation
Ege: we still wait for feedback
Koster: I think it is straightforward enough to merge
Ege: Okay than we can merge PR 307, w3c/
PR 308
<Ege> wot-binding-templates PR 308 - Adding BACnet JSON Schema
Ege: as per last week discussion I removed the Data Type Mappings from the jsonschema
Koster: I'm ok with merging it
<Ege> w3c/
PR 309
<kaz> wot-binding-templates PR 309 - Reorganizing uri variables section
<kaz> related Issue 302 - URI Variable for BACnet
Ege: We rely on the default key to signal that if the consumer does not set a value the driver is going to use the declared default (see the examples about covIncrement)
Daniel: I'm wondering what lead to this solution
Luca: In the issue I provided the full example, it boils down to put the vocabulary terms involving the binding protocol only in the form, so consumers unaware of the binding can still safely consume the affordance as long there are forms it can consume
Luca: if there are vocabulary terms in the affordance, the strict degraded consumption rule would require to ignore completely that affordance
Koster: We need to formalise the data mapping of dataschemas and protocol side-channels
Koster: I agree we need to keep the concerns separated
Koster: For the problem at hand with the bacnet bindings, the consumer that uses the form has to be aware of the side-channel and we should not pretend the uriVariable are something they aren't
Ege: <update the issue> I'd keep it open so we can get more feedback on the issue since it is a big change from the initial proposal
TD Next
Work Items
<Ege> https://
Ege: this is the planning document, we need to prioritise the topics. Please only change the md
Ege: We trasferred the content of the wiki in the md
Ege: We should not have too many work items
Ege: We have 3 categories so far: Usabilty&Design, New Features, Supporting Work Items
Luca&Ege: <shuffle items across the categories>
Mahda: About timeseries and historical data, what is the intention?
Mahda: Do we want to add additional vocabulary terms?
Ege: Maybe, depends on what we want to support, we need to be able to describe the different use-case
Mahda: We have already properties, how they need to change to fit historical data and time series?
Ege: we can go into details later on
Koster: There is a use-case to map a property and how the property change over time
Koster: And would be good to have a standardise way to describe the instant property and the property over time
<Ege> btw webthings.io has some solutions for the history of events, actions, property changes
Kaz: We can look into known solutions like ECHONET for those items
PR 1112
wot PR 1112 - Historical data workitem analysis
Ege: We can use historical_data-explainer.md as template for the other work items
<kaz> [adjourned]