<inserted> scribenick: dape

Agenda

Sebastian: Agenda bashing
... minutes
... Monday Wishi meeting
... CoAP in RDF
... Issues
... PlugFest topics
... F2F meeting topics
... Anything more?

<inserted> (none)

Preliminaries

Sebastian: BTW, Cristiano has now "invited expert" status

Prev minutes

<kaz> May-15

<kaz> typos - eample, licnse, sript

Sebastian: Minutes checking May 15 --> approved

<sebastian> May-29

Sebastian: iotschema.org updates, issue discussions (bug in JSONLD playground, ...), oneDM, Ege's static TD approach
... --> minutes May-29 approved

T2TRG meeting on Monday

Klaus: no changes to Agenda recently

Sebastian: Unfortunately I am on vacation next week
... asked M. Koster to present oneDM/TD discussion

<sebastian> https://github.com/w3c/wot-thing-description/issues/903

Sebastian: Klaus, do you think we can add issue to agenda item (1400Z)
... one important aspect for us is also the topic about hypermedia control, 1430Z

Kaz: after hypermedia control discussion, we might want to take a look at RESTful design document

Sebastian: Maybe Klaus can give a quick overview

Klaus: in many meetings we had questions how to do design decisions
... this document tries to capture the best practices
... not a standard, it is not prescriptive
... e.g., long running actions --> use collection resource
... or light bulb, do I need history of dimming?
... we hope document is useful for others
... so far not that much feedback
... we appreciate any feedback

Sebastian: Should try to make people aware about this document

Klaus: Shall we add names to agenda points ?

Sebastian: Some people take over whole discussion block
... should be fine I guess

Kaz: Maybe we also check with M. Koster to make sure

Sebastian: Not sure about topic "Handling URLs"

Klaus: Not sure either

Sebastian: No "real" news from our side I think

Kaz: Related to DID? We should ask McCool

Sebastian: I see.
... Will talk to McCool and Koster

Binding Templates

Sebastian: CoAP in RDF
... we provided some basic terms in binding templates document already
... cov:options, cov:methodName, ...
... not yet in machine readable RDF representation (no ontology yet)

<kaz> Binding Template draft - 5.3.2 CoAP Vocabulary

Sebastian: We have HTTP ontology
... we need the same for CoAP
... VC started initial document for MQTT and also CoAP

<sebastian> https://github.com/w3c/wot-binding-templates/tree/master/ontology

Sebastian: we need to work on RDF (ttl files)

Ege: Note: Vocabulary is not the same
... methodName vs methodCall

Sebastian: I am happy that Klaus is also interested in the CoAP work
... we have the framework setup. we need to work on content now

Ege: information how to use render script is in readme of repo

Sebastian: How do we want to organize the work?
... github discussions, regular meetings, .. ?

Klaus: One initial meeting to kick off would be fine

Sebastian: Makes sense

Kaz: initial meeting: using one TD call or additional call?

Sebastian: Suggest additional call
... mainly Klaus, Ege, Sebastian, Koster, Victor
... Next week im on vacation, the week after is PlugFest
... maybe in PlugFest week?
... will setup Doodle poll

Klaus: Shall we narrow down choice ?
... Monday, Wed, Friday does not work for me

Ege: Thursday works for me

Klaus: Tuesday my preference
... List of Editors: premature putting me on this list

Sebastian: not "final" yet

Kaz: I think Tuesday works better, Thursday are plenty of calls already

Sebastian: OK, will setup Doodle

Issues

<inserted> Issue 899

Sebastian: Issue 899, long running actions
... we have different proposals
... Victor proposes dynamically changing TDs --> https://github.com/w3c/wot-thing-description/tree/master/proposals/hypermedia-control
... Ege proposes static TDs --> patterns in TD

<Ege> PR 907

Ege: proposal is in PR
... similar to what Victor did... unless TD is static
... e.g., we have fade operation returning with brightness value as number
... important to note: output refers post response
... want to manage fade operation (query, update, cancel)
... after POST/fade new resources are created (e.g., GET /fade/1)
... href of new resources can be static
... e.g., GET fade/ongoing
... 1 fade operation at the time vs. multiple operation
... suggest adding additional operation types (queryaction, updateaction, cancelaction)
... one problem in non-fixed href --> it is not clear how to get final href
... in case hrefs are dynamic (e.g., {id}) we need to describe that
... meaning of input/output should not change --> refers to action request
... added query>input, update>input, update>output, cancel>input
... implementations may choose the according information (e.g., no cancel input needed)
... open issue -> how to integrate dynamic hrefs
... part of header of response
... could also be in payload
... complications: information in header vs. body
... Scripting API concerns -> access to headers?

Daniel: Do we need {id} in header... in body seems better for Scripting and other protocols than HTTP/CoAP

Ege: Issue with existing protocols

Klaus: depending on the case we might need multiple running actions (e.g., different coffee orders)
... queeing actions vs one action is possible (depends on use case)

<inserted> scribenick: kaz

Klaus: going back to the original question about dynamic TDs
... starting, monitoring, etc.
... pause, resume, etc.

<inserted> scribenick: dape

Klaus: instead of working with ids, plugging in url templates

Ege: Makes sense

Klaus: descriptive vs. prescriptive
... need to look what products do today

Ege: we should not have to change... maybe we do not support alle specific solutions
... e.g., with what has been shown we can describe Mozilla implementations

Kaz: Useful if we could have concrete use-cases/devices
... should clarify variations

Ege: can look at some examples (Mozilla, coffee machine)

Kaz: Yes, please think about concrete devices
... and combination of devices so that we could clarify actual behavior of them and what is required to handle them. that would be useful for this initial discussion of course, but would be useful to the future plugfet as well

Ege: should also look into Oracle implementation

<Zakim> dape, you wanted to running actions

Daniel: starting with requirements lists also?

<inserted> kaz: right, and if we could clarify use cases and scenarios with concrete device setting, it would be easier to clarify the requirements as well :)

<inserted> EK: thought there were some use case descriptions related to hypermedia control already

Sebastian: Let's start with looking into the Oracle and Mozilla use cases
... w.r.t. PlugFest
... we have 2 versions on the table. shall we pick one or check out both
... my feeling is we might want to evaluate both

Ege: +1

Kaz: after clarifying the use cases and requirements, we could clarify which would be better. or there is a possibility that both approaches could be handled

Sebastian: Suggest merging PR 907

<kaz> [PR 907 has been merged]

Sebastian: T2T discussions on Monday will be helpful also

Issue 307

<sebastian> Issue 307

Sebastian: Next issue $ref
... initiated by Toru a while ago
... use $ref from JSON schema in TD also
... allows to define model in global space and point to it (reduces redundancy)
... I support introducing $ref

Ege: there is one limitation: validate input/output by getting schema
... input for example is not any longer self-contained

<kaz> Example 1

Sebastian: whole TD is JSON schema valid

Ege: Correct, but validation would like to check value only

Daniel: Dynamically updating json schema constructs

Ege: Correct, or passing multiple schemas to validators

<Ege> https://github.com/tum-esi/wot-sys/blob/master/Devices/nodewot-pantilthat/src/base.ts#L315

Ege: "outer" definitions are not visible to validators

Sebastian: Correct. We need to combine the outer definitions with the interaction type definitions
... Shall we work on proposal

Klaus: $ref at JSON level or TD level
... recommand TD level

Daniel: Support having one global space for definitions

Sebastian: Question: allowing referring to "external" files

Klaus: Useful, but what happens IF TD is retrieved from somewhere et cetera.. or should it selfContained

<Ege> I need to leave now :)

<Ege> See you next week

Klaus: compromise: TD templates
... TD might be better selfContained
... oneSDF / WISHI has same discussion

Kaz: old issue, so maybe kind of related to Kajimoto-san's object-oriented project. however, I think this is definitely related to the TD Template discussion.
... so we should think about use cases and requirements for both this proposal and the TD Template proposal a bit more, and then get back to this proposal itself later.
... relates to TD template as well

Sebastian: Not sure if it fully tackles Kajimoto-Sans proposal/idea

Kaz: yeah, this proposal #307 might be not directly taking over Kajimoto-san's idea, but we should work on requirements first

Sebastian: Will work on proposal and requirements

Daniel: I am interested also

Issue 908

<sebastian> Issue 908

Sebastian: Next issue, 908, no default value for observable

Klaus: what does "observable" mean? not intersting to observe or possible to observe

Sebastian: observable does not say anything about stability of value

Daniel: not much value in observable

Klaus: +1

PlugFest

Sebastian: talked about a bit
... test new terms, long running actions
... maybe CoAP RDF is ready

Topics for VF2F

Sebastian: Any input?
... feeback from PF about long running actions
... TD templates
... $ref/definitions from JSON schema
... oneDM TDT
... iotschema
... please contact me via email if you have more topics

Kaz: CoAP RDF ontology

Sebastian: Yes
... Next week I am on vacation. I will ask Taki to moderate

<kaz> [adjourned]