<inserted> scribenick: victor

Prev minutes

Sebastian: (goes through the minutes)
... can these minutes be published?
... no objection

Repo logistics

<inserted> wot-thing-description top page with TD family

Sebastian: new doc, 'feature log'
... for each feature: provide author (or issue),TD examples, implementations
... 2 entries so far (for exemplary purposes), the list will be extended

Daniel: we also have a 'changes' section in the rec. Must the content of this new doc be copied into the 'changes'? Can we reference this new document instead?

Kaz: for a first public working draft (status of the next version of the TD doc), no need to have a 'changes' section, a link to the v1 REC would suffice

Sebastian: other question about render.sh (render script to generate pieces of the spec)
... for the REC version of the spec, rendering was disabled. Can we have it back?

Victor: I will have to rewrite the script, it evolved a lot over the course of v1 work

Sebastian: this rendering script generates HTML and graphviz graphics. The latter is important.

Victor: I don't know when I'll be done, maybe you can edit index.html manually until the script is rewritten

Sebastian: would still need the rendering of graphics.

Victor: ok, it's easier to restore that part.

Summary of the WISHI workshop

Sebastian: (shows slides he presented at the workshop on TDTs)

<Ege> https://www.iana.org/assignments/link-relations/link-relations.xhtml

Sebastian: meeting next week with Michael Koster for the next WISHI workshop
... note copyright/license should be terms that we add to next TD version
... I'll have to ask Ari where the slides have gone on the WISHI Github repo
... meeting minutes are also available on the repo

PR updates

Sebastian: created a PR for JSON schema terms (https://github.com/w3c/wot-thing-description/pull/896)
... waiting for rendering to be restored to close this PR

Issues

Sebastian: https://github.com/w3c/wot-thing-description/issues/892
... how to get events from the past?
... issue creator wishes to have the same feature as Mozilla WebThings

Ege: different types of events being targeted between TD (regular events) and Mozilla WebThings (rare events)
... suggested a property affordance but seems not to be well received

Koster: the question is how to expose event objects in a RESTful way. Two options: expose them as a property or create a new op type like 'retrieve event'.
... we should collect requirements for this use case.

Sebastian: should we add this use case to the WoT architecture spec?

<Ege_> Should we also consider property values that have been emitted as an observed properties

Ege: we should probably include in the discussion the question of 'observe property'

Lagally: the topic also relates to the problem of clock synchronization

<kaz> +1

Victor: I would expect the problem to be addressed at a lower level (e.g. timslotted exchange of IP frames)

Sebastian: agreement on starting describing the use case of historical data/events (and defer decisions on TD design after we have it)?
... issue to create on the arch repo

Koster: this use case could be integrated to the smart home use case

Lagally: but it also applies to other domains (manufacturing, for instance)

Kaz: also smart city (mentioned by Singapore), transportation (mentioned by Zoltan); it is more a category?
... should we change the template to include categories?

Lagally: templates already have categories for applications, there could be one for 'historical data'.

Sebastian: next issue, https://github.com/w3c/wot-thing-description/issues/898
... terms in Vorto templates to combine different templates, have inheritance, etc
... what are the equivalent constructs in RDF?

Victor: about 'multiple', it seems this is information that would usually be part of a Web ontology

Sebastian: not sure about 'breakable', is it specific to TDTs or an extension of the general TD model?

Victor: and for 'extension', there can be conflicts if we allow arbitrary extension, we'd need to specify how to resolve them

Daniel: Kevin (working on Vorto) mentioned they have some implementation for extension that can detect some conflicts

Sebastian: we'll ask Kevin when he's back
... next issue, https://github.com/w3c/wot-thing-description/issues/897

<Ege_> Vue.js also uses {{ }}

<Ege_> https://vuejs.org/v2/guide/syntax.html

Lagally: I see a difference between "templates" (pattern replacement) and "classes", which we can combine, instantiate into TDs, etc

Sebastian: can you provide examples on how Oracle is defining its own "TDTs (DeviceModels)"?

Lagally: I'll create a presentation, next week or the week after

PlugFest planning

Sebastian: what features should we test?
... (in our next PlugFest)
... proposal so far is to request the state of an invoked action
... see https://github.com/w3c/wot-thing-description/issues/302
... proposal is to have a 'hypermedia' key to know in what JSON key to find the link to the handle resource
... but we don't know what the response looks like, still

Koster: old idea of returning parts of a TD to expose all this information

Victor: first comment in that sense of from Matthias Kovatsch, in this issue

Koster: we are still missing a way to indicate where to find a link in a JSON response, though (see Sebastian's proposal)

Victor: initial ideas about that in the HTML documentation of the JSON Schema vocabulary (e.g. https://www.w3.org/2019/wot/json-schema#defining-a-json-ld-context-for-data-instances)
... I'll create a new issue to have a discussion specifically on these aspects

Sebastian: other topics for the PlugFest?

Ege: eventing with complex events

Sebastian: right. One example in the REC, WebhookThing

<kaz> Example 35

Ege: the example is complicated and it tries to define the Webhook "protocol" in a TD

Lagally: to me, it is not a protocol but a state machine, a state model

Victor: looks related to the earlier discussion about action cancellation/update to me

Koster: common idea of a "subscription" but still a distinct discussion

Ege: looks to me that we can just refer to Webhook as a subprotocol. Question: is there just one Webhook interaction pattern or can there be variants?

Sebastian: seems we don't have many answers yet regarding eventing. How about not including it yet in the PlugFest?

Kaz: other subject for PlugFest is discovery, so we might want to think about how to get "id" for specific use case scenarios (as well as TD feature testing)

Sebastian: end of the meeting, we'll have to postpone the discussion. To the next PlugFest call?

<Ege_> I need to leave now though, I have another meeting. Can we allocate more time for this next time in case it is not finished?

Binding Template

Victor: created Turtle and HTML files for CoAP and MQTT vocabularies
... requires review

<kaz> [adjourned]