WoT-IG/WG vF2F Meeting in March - Day 5

Meeting minutes

opening / agenda

Sebastian: reminder: contribute to use case PRs and issues
… profile discussions in issue #73
… We may need to increase the profiling time. One hour is often not enough.

McCool: there are also a number of discovery issues requiring feedback. Editorial ones may be merged today.

Christian: the listing PR should not be merged yet. It is still under discussion.

Lagally: the next architecture call, after Easter (April 22) will be 2 hours and dedicated to profiling discussion.

<sebastian> Kaz we cannot hear you?

Sebastian: today's agenda will cover:
… What's new in TD 1.1
… Next TD publications
… Thing Model
… TD canonicalization
… News from iotschema.org

Sebastian: the profiling discussions should continue on the issue tracker and in PRs. Three weeks break is a long time.

Kaz: Ben has some long and reasonable comments.

Ben: Can create a PR with the proposal

McCool: Better discuss and resolve open issues before creating a PR. Otherwise the discussion will be moved to the PR.

McCool: It is best to have small PRs with concrete proposals that we can quickly agree on and move on.

<kaz> kaz: we should be careful how to handle the contributions. starting with summarized comments from each contributor on Issue 73 with possible disposition of all the comments would be useful for the discussion on April 22.

What's new in TD 1.1

Form

<kaz> 5.3.4.2 Form

Sebastian: added (un)observeallproperties type for op

Ege: Is this referring to when "any" property is changed or when "all" properties are changed?

Ege: will the response include all changed properties or only those that have changed?

Zoltan: If the implementation doesn't support an observeall in a single transaction, should it fail or fall back to another op?

Sebastian: if the implementation doesn't support it, then it should not advertise it in the TD.

EventAffordance

<kaz> 5.3.1.5 EventAffordance

Ben: if there is observeall, should there also be subscribe all events?

Ben: this currently exists in WebThings and also the directory spec. We may need an equivalent to this for events. Also, we may need to get past events.

McCool: It makes sense, but need to discuss in a separate issue.

Sebastian: This may be offered by a subprotocol, but adding everything to the top level spec may not be appropriate.

Ege: The op values are not properly explained. It would be useful to add a table (instead of sentences in a paragraph) to explain individual values.

Sebastian: It is a good point.

McCool: It will be useful, but the descriptions should be protocol agnostic.

<kaz> 5.3.1.5 EventAffordance

Link

Sebastian: Next change is the relations table

<kaz> 5.3.4.1 Link

Sebastian: possible values are listed. Mostly based on existing IANA link relation registrations.

McCool: we also have a relation type used in discovery (describedby), which didn't make to this list
… extends is strange in the given context

<victor> my question: can you elaborate on 'controlledBy'?

McCool: proxy-to may be redundant. Need to check if the use is different with the existing proxy relation type.

Victor: What is the purpose of controlledBy relation type?

<victor> ack

Sebastian: controlledBy refers to devices controlled by another Thing.

Ben: is manifest used in the right context?

<mjk> https://html.spec.whatwg.org/multipage/links.html#link-type-manifest

<kaz> i|next change is|subtopic: Link|

McCool: I think the IANA explanation specifies the manifest format. which may not be TD. Need to look into that,

Ben: Will create an issue to discuss the manifest relation type

exclusiveMinimum and exclusiveMximum

<kaz> 5.3.2.4 NumberSchema

Sebastian: Next change: exlusiveMinimum and exclusiveMaximum

McCool: We need to look into the discussions in SDF. They have been working on these for a while. We should make sure we don't have any contradicting definitions.

AdditionalExpectdResponse

<kaz> 5.3.4.4 AdditionalExpectedResponse

Next change: one or more AdditionalExpectedResponse
… each AdditionalExpectedResponse may have success, contentType. The schema field is currently under discussion and may be removed.

McCool: The success if false by default
… the schema may be moved outside and made reusable

Ben: What is the use case for this addition?

McCool: There could be multiple success responses distinguishable by means other than the content type.
… The existing schema did not allow defining that and also the various error responses.

uri assignment for authentication location

<kaz> 5.3.3.1 SecurityScheme

Sebastian: Next change: URI assignment for authentication location

McCool: there is a PR right now to extend the body to include a JSON pointer into the data schema

Thing Model features

<kaz> 10. Thing Model

Sebastian: concepts, modeling tools
… Modelling tools: versioning, extension and import, placeholder, required
… derivation to TD instances
… the algorithm and process. This is subject to change. The explanation will be improved.

<kaz> s/topic: Additional/subtopic: Additional/

McCool: "required" field isn't in TD, so TD Model cannot be considered as a partial TD.

Ben: TM adds complexity to implementations. The complexity should ideally be shifted to the cloud.

Sebastian: TM is not meant to result in a TD during runtime. It is mostly useful to create TDs during development/configuration/startup time.

Ben: it is not necessary to turn this into a standard. Also, requiring clients to be able to process them add complexity.

Sebastian: Standardizing it makes it easy to reuse models

<Zakim> dape, you wanted to required part of JSON properties

Daniel: The inheritance may need to be reworked. Some thing are restricted in TD but allowed in TM. We need to improve this to simplify validations.
… ideally, we should start from an abstract model and define other things on top.

Lagally: We should maintain the completeness of TD with semantic annotations.

Kaz: technically, TM is not part of the normative Thing Description features, so probably it would be cleaner to split it (=TM) into a separate document on best practices or implementation guides.

Sebastian: TM was "Thing Template" within the Appendix for the Thing Description ver. 1.0, and it's becoming more official these days and moved to the section 10. However, agree there is still a possibility to make it a separate spec.

McCool: The TMs need to be addressable if we want to maintain them in the directory.

Ben: Do consumers need to understand TM if they come across a TD which links to a TM. See Example 50 The TD is incomplete with the TM.

<kaz> Example 50

McCool: We need to define validation to check this. There are also security considerations. The type definition is just to check if the TD is compatible with the model.
… The TD should be self-contained.
… If there are required fields in the TM, should we fetch the TM to validate the TD? This needs further discussion.

Sebastian: Yes, the TD is self container and the type link is just for validation.

Ben: WebThings does this kind of validation with semantic annotations. So there might be some redundancy here.

Sebastian: Yes we need to check this

Publication Roadmap

Sebastian: next working draft by end of April
… we have many open issues and with Easter holidays in between, it may not be realistic to have all included.
… regarding the candidate recommendation (CR), we need at least one more plugfest to test everything

Lagally: Adding vocabulary and links for profile will be easy

Ben: What is the deadline for adding things to TD 1.1 and what goes to TD 2?

McCool: We are behind the schedule. We should have a solid draft by June 1st.

Sebastian: We should discuss on issue tracker to know what is realistic. We also need a plugfest to test some new features.

McCool: We may need a plugfest in June. October is too late.

Lagally: canonical and signing can be included in profiles and moved to TD later.

McCool: I think canonicalization belongs to TD. It is not so difficult to add. Also, we need a formal validation process.

<kaz> +1

McCool: Deadline proposal: May 15th: complete draft. June 1st: pre-CR and plugfest

Lagally: canonicalization will be simple if we follow existing specs

McCool: validation is a lot of work, but not so complicated

McCool: validation is important before storing TDs in a directory.

Kaz: Please remember that we need an implementation report plan doc (including assertion list) and also need to identify features at risk for CR transition.

McCool: The plugfest will show the implementations status

<kaz> kaz: provide assertion lists and identify features at risk

<McCool> june plugfest should probably be a "testfest" and should have the goal of generating a draft implementation report

Ege: there should be a deadline to have feature-freeze to allow stable implementations

<McCool> ... and can then identify at-risk items

<FarshidT> sk: 10 minutes break

<kaz> [10-min break]

Thing Model

sebastian shows slides summarising issues arising from the plugfest

The required term is from JSON schema

but is at the same level as properties

McCool: move it up a level

It is at the wrong place and would preclude properties named "required"

<McCool> to dape: it can just apply to all interactions

sebastian cites work with SDF

<McCool> although... then we can't have properties and actions with the same name. Sigh...

<McCool> (anyhow... sebastian's proposals seems to address this)

<Zakim> dape, you wanted to one level up causes issues with properties/actions conflicts

dape notes that moving "required" up a level would preclude having the same name for properties and actions, etc.

McCool: sebastian's proposal uses a URI path to avoid that

Lagally: I am a bit puzzled about whether JSON-LD already provides a solution.

Sebastian: would we need to use SHACL for this?

McCool: we could use "tm:required" here

sebastian asks mlagally if he is against this proposal

Lagally: no

<benfrancis> FYI https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.6.5.3

<kaz> kaz: just to make sure, do you mean "required" here is affiliated with the context/namespace of "tm"?

McCool: I propose we have a context file for thing models

as distinct from thing descriptions

Cristiano: +1 for this proposal

Sebastian: I will raise this as a GitHub issue for further review

Sebastian: the extends feature doesn't yet support importing sub-definitions

<McCool> comment: likewise, "extends" could be "tm:extends", and only allowed in TMs...

Sebastian: sometimes you want to borrow part of a model, but not the whole model

<cris> we could move also ThingModel -> tm:ThingModel

<Citrullin> +1 on tm:ThingModel, I also prefer some kind of prefix for it.

Sebastian: JSON schema uses $ref, whilst SDF defines sdfRef

We need something like a macro inclusion ...

We could use tmRef or perhaps tm:Ref

McCool: this is basically a JSON pointer

adds +1

Sebastian: to clarify, this is only for tm not td

the imported definitions should be self-contained

McCool: we may need to allow for empty models in respect to validation

Koster: I agree with this

Cristiano: can you import a model and extend it?

Sebastian: yes

Koster talks through the extends behaviour

we should clarify what we mean

McCool: there is the potential for conflicts when importing stuff

I prefer to use ref to identify just what you want to pull in

Koster: the term "type" is preferable

McCool: "extends" would just indicate a dependency, but not the details

Cristiano: why do we need "extends" in that case if it is redundant?

Cristiano: tm:ref would override extends

Koster: we could say that ref doesn't change the meaning ...

"extends" brings some baggage we don't need

we need to define the processing model for interpreting TDs and TMs

Sebastian: I will create an issue to gather further review

Kaz: we want to think about compatibility between WoT TM and SDF, right?

we could explore this in the next plugfest

sebastian cites the discussion on media type for Thing Models

McCool: we need to include this in the IANA registration

we need to register our use of JSON pointer for both TD and TM

<kaz> sk: need more discussion and continue

feedback from PlugFest about SDF-TM usage

mjk provides feedback on OneDM and WoT plugfest

Exploration of generating TM/TD from oneDM's SDF

He cites a Modbus example

slide with model construction work flow

SDF doesn't really describe data schemas

it relies on the protocol and instance bindings

Koster: I also worked on semantic annotations

Some questions about terms

Sebastian: your @type is from RDF, right

I would expect a reference to RDF representations

Koster: @type just gives a URI and could point to Turtle or JSON-LD as needed

Use of RDF would enable use of RDF tools

Ben: this is what schema.org does, and we've followed it for webthings

<victor> from the JSON-LD rec: ""@type" value must a string, an array of strings, an empty object, or a default object."

mjk talks about gaps in the SDF conversion process

<victor> the RDF data model makes a distinction between resources (identified by URIs) and representations (which has a specific content types and "represent" resources)

some changes for SDF 1.1

JSON schema required for input and output elements

<victor> so, adding a content type to an RDF class shouldn't be possible

Koster: also we now have sdfChoice for enums

and a means to annotate generated TD/TM from the SDF source references

some stuff to do with fixed point decimal numbers

along with min/max and scaling

an open issue about non-linear scales, e.g. log scales

The Modbus experiments were helpful

some suggestions for vocabulary

need to specify precision for Modbus data, e.g. 16 bits

need to map array contents to properties

Sebastian: thanks for sharing this with us, please share the slides too

<sebastian> https://github.com/w3c/wot/tree/main/PRESENTATIONS/2021-03-online-f2f

Canonicalisation

Lagally: here are a few slides ...

architecture discussion now as GitHub issues

We're interested in canonical forms of TDs

useful for TD comparisons, crypto etc.

JSON has a canonicalization scheme RFC8785

we need additional rules and clarifications, e.g. default values

prefixes, array ordering, structural ordering

McCool: we also need to decide when we have multiple ways to express things

Further discussion needed

Lagally: now let's talk about signed TDs

essentially sign canonicalised form

IoT Schema

The IoT schema CG is rechartering

we're more aligned with web of things than schema.org focus on web search

The idea is to support a catalogue of device descriptions

There are a lot of existing models we can import

we want to normalise the models from the heterogeneous representations

is there enough critical mass, can we build a new consortium?

from those already in W3C

we're looking for people to sign up ...

Ben: I am very supportive of this work, we have 20 plus models for webthings

happy to contribute those models

what is the overlap with thing models? I will create a GitHub issue to discuss this further

Koster: good question

Sebastian: +1

<kaz> +1

<benfrancis> FYI https://webthings.io/schemas

Sebastian: we could include examples in the TD spec

<sebastian> https://www.w3.org/community/iotschema/#

Everyone is welcome to join the CG

<victor> I've got to go. Have a good day, all

kaz makes a comment on where work takes place, e.g., possibly we WoT group work on requirements and ask the CG(s) and SDF guys to work on actual spec work instead :)

sebastian wraps up today's meeting.

Tomorrow

McCool: we have a tight schedule tomorrow, please email me any agenda changes

Sebastian: no WoT calls next week

<kaz> [adjourned]

– DRAFT –
WoT-IG/WG vF2F Meeting in March - Day 5

24 March 2021

Attendees