Meeting minutes
Agenda
Cristiano: Talk about ModBus next week
McCool: Open PRs from my side we might want to look at
Last minutes - Review
see https://
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://
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
https://
Daniel: respec warnings only
Sebastian: looks good to be merged
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://
<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 5.3.4.1 ?
… 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
https://
<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
https://
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
https://
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
https://
McCool: No PR yet, working on it
Issue 980
<McCool> (have to drop, ttyl)
https://
Sebastian: schema definition using wrong type
… issue seems still existing
… should be fixed
… I will provide a PR
Issue 1002
https://
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]