W3C

WoT-WG - TD-TF

17 February 2021

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura, Michael_Koster, Michael_McCool, Philipp_Blum, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian
Scribe
dape, McCool

Meeting minutes

Minutes Approval

https://www.w3.org/2021/02/10-wot-td-minutes.html

Sebastian: talked about OPC UA
… PRs w.r.t. security
… placeholder concept
… ThingModel discussions
… actions vs property discussions

<sebastian> issue 1044 - Adding term to indicate a stream of data

Sebastian: Any objections?

-> none --> minutes approved

Collecting topics for vF2F

Sebastian: I put some topics already like ThingModel

Philipp: w.r.t ThingModel, using multiple TMs
… merging seems tricky?

Sebastian: at the moment TD can only refer to *one* TM

Philipp: Extending: e.g., "base" sensor + TM for X and Y

Koster: I have similar use case also
… iotschema, light bulb having several capabilities

<McCool> https://github.com/w3c/wot-testing/blob/main/events/2021.03.Online/scenarios/digitaltwin.md

McCool: Wrote this up for plugfest scenario, see link above

<kaz> kaz: +1 with McCool

Koster: separate TMs seem to be useful

McCool/Sebastian: discussing outcome of these topics from the PlugFest

Sebastian: Agree. Experience in the area of TMs seem important.

Kaz: agree we should think about concrete scenario for plugfest. also if possible we should think about how to deal with Thing Model at the discovery phase.

McCool: in discovery we do not look into TM right now. Not sure if we should though
… being TM in directory as well

Koster: topics of overriding

Sebastian: How much time do we have for TD task force?

McCool: 3-4 hours for TD?

Sebastian: ThingModel seems to be the most important TD topic for the upcoming F2F
… let's continue discussing the F2F topics next week

WoT Bindings

Cristiano: I committed Modbus changes

<sebastian> 109 - Refining Modbus protocol binding

Cristiano: I fixed renderer script
… I also proposed Modbus document
… followed TD pattern: HTML enhanced by SPARQL queries

<CA sharing his screen>

Cristiano: sharing rendered Modbus document
… rendering is still not complete ... eg. missing whether something is optional

Sebastian: You might need SHACL file for doing that

Cristiano: I also added default Modbus mappings
… readproperty to modbus fuction
… I would like to get feedback whether the document structure makes sense

Sebastian: Looks good.
… I am missing TD examples

Cristiano: Agree

Koster: ontology might be a standalone document
… could be used in other areas as well
… practical examples make sense also

Cristiano: having various documents makes linking more problematic
… i think the current proposal could be a template for future bindings

Sebastian: I imagined a self-contained document for Modbus ... forgot about ontology file

Sebastian: wonder how we best align with binding core document
… wonder about the number of documents, Ontology and HTML, general documents multiplied by every binding

Koster: Remember the discussion
… lots of documents vs generic template spec
… not sure there are arguments for both

Kaz: I wonder whether we should talk to Modbus implementors or not

Cristiano: Agree

Sebastian: 2 topics
… 1. content makes sense
… 2. whether we use multiple documents

Kaz: We started to think about other liaison as well. We can ask them what they would like to see
… For example, ECHONET and others could provide ontology

Sebastian: Yes, need to get in touch

Koster: Having separate vocabulary makes sense
… we did have HTTP pattern
… we can not push others to do the work
… propose to have vocabulary separate
… I recommend core document being stable
… maybe just having some pointers to bindings
… standalone document should be self-contained

Sebastian: like Uniform resource Locator ?

Koster: Yes

Cristiano: Question: separate document for ontology?

Koster: start with one document. Once it is final we might break it up
… suggest to talk to Ege also

Sebastian: MQTT is part of core at the moment

Sebastian: Okay, lets go with having separate documents in the future for each binding

Kaz: DID could be useful in the future

Cristiano: What are the missing steps on my side?

Sebastian: Good so far. Examples are missing ...
… ontology should be generic. examples are related to TD.

Koster: TD mapping should not be part of generic ontology. rather part of binding document

Sebastian: Thanks Cristiano for all your work

Sebastian: Summary can be found here https://github.com/w3c/wot-binding-templates/pull/109#issuecomment-780662878

Koster: I have one more issue in mind? Shall I add the comment to this PR?
… will create issue

Sebastian: Agree with what Kaz mentioned before. Should get in touch with Modbus people

<mjk> https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

OPC UA Binding

<mjk> https://www.modbus.org/specs.php

<mjk> https://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf Modbus application protocol spec

Sebastian: Kaz mentioned to have a separate call
… do we plan a web meeting?

Kaz: Yes, I think we should do that
… I can create doodle poll

Sebastian: or PlugFest week, re-using cancelled calls

Defer issue to TD 2.0

Sebastian: please look into https://github.com/w3c/wot-thing-description/issues?q=is%3Aissue+is%3Aopen+label%3A%22Defer+to+TD+2.0%22

Sebastian: and provide feedback

PR 1052 Fix HTML fragments in ontology docs

PR 1052

Daniel: fixed reference issue

Sebastian: I am OK with merging

PR 1049 TM Schema generation

PR 1049

Sebastian: PR is about JSON schema for ThingModel
… Ege provided version and script

Daniel: Ege uses script which is good

Sebastian: Since it is marked as WIP we should wait before we merge

PR 1042 Add additionalResponses to Form

PR 1042

McCool: PR is not yet done

McCool: wanted to get feedback before moving on
… proposal: use additionalResponses to avoid backward compatibility issue

<cris> +1

McCool: property should not report back different data from input (use action instead)

Sebastian: What is the use case for multiple responses?

McCool: e.g., different kind of errors
… or also different success responses

Sebastian: using oneOf?

McCool: oneOf is the alternative
… should add text when to use what

Cristiano: wonder whether it is possible to state response is error?

McCool: Could have error codes...

Cristiano: among those possibleReponses can we mark one that this is an error

McCool: having a boolean?
… could make sense

Cristiano: will add comment to PR

PR #1024 Topics around Thing Model

PR 1024

Sebastian: tried to incorporate input from last week
… re-structured chapters
… start with basic concept
… next is thing model declaration
… followed by "modelling tools"
… like using versioning
… extension and import (import is still missing)
… afterwards "placeholder" concept with example
… we have "required" feature also
… should look into SDF approach w.r.t. required
… I also explained the steps from TM to TD instance
… see section 10.4

McCool: Do we say we MUST NOT put security in TM?

Sebastian: No, it is weaker ... "MAY NOT"

McCool: Sounds good

Sebastian: I plan to extend the examples section 10.5

McCool: Placeholder for number types?

Sebastian: Placeholder provided as string. Mapping file is typed as number. There are libraries doing that already.

Koster: SDF style approach? Overriding?
… shall we have examples for it?
… I could create some of those examples

McCool: would be good to rewrite the existing examples in that style to compare

Sebastian: Expect more feedback after the PlugFest
… SDF examples make sense

Koster: SDF uses JSON pointer or reference mechanism

Sebastian: we cannot override interactions
… we cannot override type's
… except number being cast to integer

McCool: scale factor might be a related topic

Koster: OCF has some of these scale factors

McCool: step is a related issue

Koster: unit might also play a role here

McCool: narrowing types is another topic

Sebastian: created issue

issue 1054

Sebastian: I propose to merge Pr#1024
… will add come warnings that we are still collecting experience

<kaz> PR 1024

Sebastian: merged

McCool: I think we need section about validation
… relates to discovery

Issue 1037 - The "body" location value for security schemes is underspecified

Issue 1037

McCool: Not ready to close
… need to add mentioning of JSON pointer

Issue 1044 - Adding term to indicate a stream of data

Issue 1044

Cristiano: relates to scripting
… stream vs object
… from scripting API it is transparent

McCool: in directory we talk about streaming
… GeoPose streams data also

Cristiano: usually the protocol level handles it

McCool: I think we should capture the use cases

Cristiano: Agree

<kaz> [adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).