<zkis> scribe: zkis

Approving past minutes

<kaz> https://www.w3.org/2020/02/14-wot-td-minutes.html

Sebastian: Couldn't join the previous call, so Taki please go through the minutes

Taki: PRs, Issues. Ege discussed some of interaction aspects in the Architecture call as well.
... also discussed Bindings, on what clarifications we need for next version.

Sebastian: any comments on the past minutes? If not, ask Kaz to publish
... minutes approved

Virtual F2F meeting

Sebastian: there is already a time slot

Online f2f wiki

Sebastian: please fill the questionnaire
... vote on the session you'd like to join
... would you like to collect topics we should discuss on the F2F
... I propose discussing on TD templates
... what do you think we should discuss

Zoltan: there are issues marked for next version

Daniel: eventing
... more efficient formats for TDs

Zoltan: yes, the github issues

Sebastian: we should prioritize the issues and pick a few

Github repository

Sebastian: should we go to a new fresh repo?
... this is not typical
... usually done when a major change happens, like TD 2.0

Kaz: there are examples for separate repositories for major changes
... or we could use the current repo with specific tags

Daniel: much easier to keep one repository, everyone already knows it
... we could use branches
... one entry point

Sebastian: what JSON-LD did?

Kaz: they use a new repo for JSON-LD 1.1

Daniel: not sure about the old, but the new repo doesn't have a number on it

JSON-LD 1.1

JSON-LD 1.1 Framing

JSON-LD 1.1 Processing Algorithms and API

Kaz: can talk with Ivan Herman and the JSON-LD Chairs about their general policy

<kaz> ACTION: kaz to ask JSON-LD WG guys about their GH repo management policy

Zoltan: FWIW I would also think a single repo is better and use tags and branches

IANA media type

Sebastian: now we have application/td+json IANA media type

<mjkoster> https://www.iana.org/assignments/core-parameters/core-parameters.xhtml

Sebastian: there is also CoAP

Kaz: we should make PR for both the static and github.io versions

Sebastian: will do that

PRs

PR #872

<sebastian> https://github.com/w3c/wot-thing-description/pull/872

Kaz: this is for the ReSpec template, not for the content

Zoltan: not only TD, but Scripting as well

Kaz: we should just merge the PR and make sure to propagate the change
... the changes need to be reflected to the index.html

Sebastian records the todo in a comment in the PR

Sebastian: any objections against merging?
... none, so merged

Issue discussion

Sebastian: Issue #878

https://github.com/w3c/wot-thing-description/issues/878

Sebastian: this was the one also discussed in the Architecture call
... since Ege and ML are not here, should we just read the thread
... also has impact on lifecycle

Koster: one way it to look at Node-RED
... if you make a connection to an MQTT broker you can reuse that
... we can define connections and put security info there
... does it make sense to do something similar here?

Sebastian: issue #302

https://github.com/w3c/wot-thing-description/issues/302

Sebastian: ML made a comment with an example from Oracle
... there is a URL where one can ask for status etc

Taki: made one suggestion for supporting cancel
... in transactions we can rollback, but in distributed systems it is better to handle cancel as an independent request

Sebastian: I also made a comment with a hypermedia approach
... include in Forms the hypermedia term that gives a value which can be used to identify the term in the payload of the response message that represents the resource one can make the request to

Koster: in CoAP there is a header field for using hypermedia control
... used in resource directory
... HTTP also has a location header
... if you have this in a Form, then the protocol bindings could figure out, not always from declarative way, but at least as a hint

Daniel: question about the two examples, what does href point to

Sebastian: points to the JSON term in the response payload

Koster: sometimes it's in the payload and sometimes in the header

Sebastian: updated the comment with more specific explanation.

Koster: we discussed this in OCF as well
... it's better to use the payload in order to not be needed to go to the header which may be in a different context
... in code is easier to use the payload

Sebastian: maybe we can introduce a hint in the TD spec

<mjkoster> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location

Koster: pasted a link for description of the HTTP header

Sebastian: we should perhaps mention what is out there and then define it in the TD

Koster: could share more info

Sebastian: Koster, please present payload templates

Payload Template

scribenick: Mizushima2

Koster: Semantic API

Koster's slides

<kaz> (the basic idea is handling discovery, adaption, etc., at the abstract/semantic layer rather than various concrete APIs)

Koster: There are binary switch properties.
... "switch.read" is important.
... this case is simple case.

(Mizushima-san has some trouble with audio and Kaz takes over)

scribenick: kaz

Daniel: lookup is good but wondering about read/write

Koster: possibly much simpler cases
... properties would allow complicated payload

Daniel: not sure about iot:BinarySwitch here

Koster: part of the switch property
... switch might have a property affordance
... for turn on or off
... might be confusing and better to clarify it

<Zakim> kaz, you wanted to ask about expected underlying mechanism and other approaches like DID's CRUD APIs

Kaz: are these slides available online?

Koster: can make them available

Kaz: do you have any idea about the underlying mechanism for lookup?

Koster: not really at the moment
... quite generic
... might be a lot of different ways
... may be some kind of query language
... imagine some kind of directory

Kaz: next, we might want to look at DID's CRUD approach as well, since the DID WG is working on CRUD operations as McCool mentioned during the Discovery TF call
... would make sense to have collaborative discussion with the DID guys

Sebastian: you're using semantic annotation to identify properties you want to operate?

Koster: right
... (shows schema annotation)

Sebastian: my presentation was focused on payload
... different kinds of containers
... is this also your expectation to have light.property?

Koster: both
... (shows the annotation again)
... type: boolean
... @type: iot:SwitchData
... you could use only the data
... (shows DataInstance Dictionary)
... this is how the payload looks like

(Kaz needs to leave for another meeting, and Taki takes over)

<kaz> scribenick: taki

Koster: JSON pointer is for filtering to choose which data.
... It works on JSON structure.
... selecter matches, instead of validating.
... you could match more than one.
... you apply filter, you get pointer.

Sebastian: Do you have implementation?

Koster: there are two steps.
... I would integrate into scripting api instead of standalone implementation.
... to make scripting api understand filters.
... JSON pointer is well understood already.
... Node Red is already doing similar. We need to make it work in NodeJS
... I think now is good time to pick up this work.
... Scale and Units adaptation. Integer vs Float, for example.
... Conversion has to happen somewhere.
... it is a way to automatically handle payloads.
... abstract data model is an attempt to remove payload data schema. Payload definition can be part of protocol binding.

Sebastian: We can even try some of this idea in next PlugFest.

Koster: Helsinki can be the target.

Sebastian: Do you have URI of the presentation?
... We should think about API for semantic based access to affordances instead of names in API TF.

Daniel: It can be on top of current API.

Sebastian: Thank you for presentation, Michael Koster.
... Thank you Zoltan and Mizushima-san for taking minutes.

[adjourned]