20 January 2021


Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Kaz_Ashimura, Michael_Lagally, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima
cris, dape

Meeting minutes


Cristiano: Talk about ModBus next week

McCool: Open PRs from my side we might want to look at

Last minutes - Review

see https://www.w3.org/2021/01/13-wot-td-minutes.html

Sebastian: any objections?
… none --> minutes approved

Defer issue to TD 2.0


Sebastian: Please take a look at these issues and raise concerns

Propose closing issues

Sebastian: Also here, please comment if you see problems
… so that we can discuss the issues

PR 1025

Sebastian: Introduce observeAllProperties and unobserveAllProperties, https://github.com/w3c/wot-thing-description/pull/1025

Sebastian: there was a bug in the PR Victor fixed
… PR is about adding op for observeAllProperties and unobserveAllProperties
… PR is ready to be merged
… arghhh, merge conflicts
… w.r.t. SVG images
… fixing it right away
… any objections before merging?
… none -> merging...

PR 1030


Daniel: respec warnings only

Sebastian: looks good to be merged

PR 1034

PR 1034

Sebastian: introduced new chapter about link relation types
… not completed yet
… the values in link relation table are coming from IANA
… should re-use them as much as possible
… e.g., "service-doc"
… e.g., "alternate" representation like RDF, HTML et cetera

McCool: link type for directory federation?
… "proxy-to" to be used?
… not sure if this is right

Sebastian: First set at the moment
… might need to improve
… we have requirement document

<mlagally_> Will be back in 5 mins

<sebastian> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/link-relation-types.md

<cris> +1 also from my side

McCool: What about non IANA types?
… do we propose to add them to IANA?

Sebastian: There is a column indicating the source.. IANA or any other place
… "extend" coming from WoT Thing Model

McCool: what about "implements" ?
… seems important to me
… for geo-location we need to point where location is

Lagally: Thanks for addressing the link type comment
… surprised about being "informative"
… shouldn't it be normative?
… we need column about cardinality also
… e.g., multiple inheritance: 1 or *

McCool: we need a decision about each

Sebastian: Makes sense

Ege: would see link table in Chapter 5

Sebastian: Was thinking about it also...
… in/under ?
… have examples in *new* Section 11
… where should examples go?

Ege: In chapter 6 there are already examples

McCool: Note: "controlledBy" is not yet in the list but in example
… "assembly" is another type

Lagally: will it ever make sense to have one of this links mandatory?

McCool: in certain contexts, like profiles...
… in general making them mandatory causes backward compatibility issues

Lagally: Makes sense

Sebastian: will keep working on the PR

Ege: in some cases people combine keys

Sebastian: multiple rel values?
… yes, I have seen that
… do we want to allow that?

McCool: Isn't "link" define somewhere.. what does the RFC say
… alternative is to duplicate link with different rel type

Koster: RFC 8288 talks about it

Ege: "+" used to give further precision
… will try to find more information

McCool: "+" in relation names may cause problems
… "-" is allowed in name

Sebastian: Let's try to find out more

PR 1031


<mlagally_> (signing off)

McCool: PR not complete yet
… rendering is not working

Daniel: had same issue, not recalling where to put the content.. i guess some parts need to be duplicated

McCool: Will contact Victor
… w.r.t. content
… APIkey vs. PSK
… APIkey cloud service provider example
… expanded the description
… PSK meant when you have standard for key
… add cypher-suite parameter?
… in both cases key should be put in TD
… no assertion ... but we should discourage it
… Ege can you check my work

Ege: commented already

PR 1032


McCool: key as part of URI
… see Philips hue
… parameter map pointing will be updated in PR
… replace with actual set of data schema
… still WIP
… I also added explainations
… extend body to allow more
… maybe in a seperate issue/PR
… also, rendering is not working

PR 1035


Sebastian: multiple op in forms
… PR gives some kind of guidelines for HTTP
… there is an example in the PR that shows how to create multiple forms
… for htv:methodName

Cristiano: looks good to me
… I am wondering about other protocols
… maybe have dedicated section in each binding about the limitation

Sebastian: Did not think too much about other protocols yet

Cristiano: Should find a place for such things... in bindings?

Sebastian: Yes, should get some experience
… we are missing the big picture

Daniel: CoAP would have the same limitation

Sebastian: Correct, but CoAP is not defined in TD

Koster: It comes down to how defaults are defined for bindings
… MQTT could be also such a use case
… up to bindings to specify defaults
… for MQTT no command would be required

Ege: MQTT defaults are up to version 5

Cristiano: for forms, contentType gets duplicated also?

Sebastian: Yes, any other metadata should be duplicated also

<cris> Ok to merge +1

Sebastian: shall we merge PR?

Koster: don't see any issues

Sebastian: relates to a relatively old issue 712
… -> let's merge then

Issue 617


McCool: No PR yet, working on it

Issue 980

<McCool> (have to drop, ttyl)


Sebastian: schema definition using wrong type
… issue seems still existing
… should be fixed
… I will provide a PR

Issue 1002


Sebastian: ML asks for term "reliability"
… correct vs false readings

CA/Ege: use existing ontologies

Sebastian: "reliability" comes with multiple different meanings
… hard to generalize
… I don't think we should introduce it in core TD
… should have a discussion with ML

Koster: "reliability" added where?
… associated to value?
… having a model makes sense to me
… as value constraints it might be useful

Sebastian: Suggest using existing ontologies

Koster: reliability for values might make sense

Sebastian: Is there a standard way? Percentage value?

Koster: it is usually some number of 999 / percentage
… there are different ways
… mean-time failures
… bunch of different types

... what kind of information do we need then?
… the main use case would be to get reliable data from unreliable sensors
… I think it is a good case

Sebastian: I think we need Michael Lagally here

<kaz> IEC 61360 Common Data Dictionary V2.0014.0017 - liability of an item

Kaz: we could use this linked ontology
… or at least ask the IEC group for use cases and how to use their ontologies.

Sebastian: good

Kaz: We should define a policy for the Thing Description model. like how to introduce new terms, because we can't define everything and TD should concentrate on the basic framework based on the affordance model.

Sebastian: I agree. If this term can be generalized we could employ it. But it is not easy

Issue 972

<kaz> Issue 972

Sebastian: about issue 972 we are discussing about a json schema for TM
… I think we could postpone the discussion since daniel is not here
… maybe Cristiano has any input?

Cristiano: basically now a Thing Model is really similar to a Partial TD. In the future the TM may has more requirements. Which field should we require in a TM?

Sebastian: good question, right now I don't have a clear answer we should talk more in the future calls.

Sebastian: maybe @context could be required

Koster: we could even have multiple templates in the Schema

Sebastian: right, let's continue the discussion in the next meeting

<kaz> [adjourned]

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