W3C

– DRAFT –
WoT Profiles

01 October 2025

Attendees

Present
benfrancis, David_Ezell, Ege, mkoster, Tomoaki_Mizushima
Regrets
-
Chair
benfrancis
Scribe
Ege, benfrancis

Meeting minutes

Minutes Review

https://www.w3.org/2025/09/17-wot-profile-minutes.html

bf: any feedback?

bf: hearing none, approved

Profiles 1.0 Publication

PR #451

bf: it is annoying that we had to change the editors
… as those who are more recently active cannot be listed
… is it fine?

tm: maybe McCool's w3c id should be changed
… since he is not Intel

<benfrancis> https://www.w3.org/groups/wg/wot/participants/

bf: did he change an account?

bf: Matsukura-san is not wg member anymore

tm: so the PR is fine
… we should check his id after he joins back as IE

bf: yes. I will check
… any other remarks
… I will contact Philippe directly

Profiles 2.0 Planning

Ege: I had one comment on HTTP-specific part. If you have the requirement to use HTTP, take this document and you will be fine. Currently can't do that because separate profiles for eventing.

Ege: Ideologically would prefer all operations can be done in one profile, so don't get different profiles

Ege: We talk about web and HTTP a lot, but when you go to Profiles implementers need to make decisions

asynchronous stuff is most important decision that is left to implementers. Would like to see SSE put into HTTP Basic, because Webhook needs completely different infrastructure./asynchronous stuff is most important decision that is left to implementers. Would like to see SSE put into HTTP Basic, because Webhook needs completely different infrastructure.

Ege: Eventing/asynchronous stuff is most important decision that is left to implementers. Would like to see SSE put into HTTP Basic, because Webhook needs completely different infrastructure.

benfrancis: Strongly agree

<Ege> bf: we ended up splitting it

<Ege> ... it would be also possible to integrate longpolling but I am not sure if people want that

tm: profile is not a subset of TD. So we should clarify difference between TD and profile and protocol bindings

bf: I agree
… we should do that
… we should define something more structured
… defining how extension points are constrained

ek: I would say any flexibility can be constrained

bf: example?

ek: maximum 100 properties. max 5 characters for property names
… something in the direction was tried but it is impossible to agree on this in a general way

Constraining Dimensions

ek: there are many aspects to constrain.

w3c/wot-profile#450
… that issue has some examples I mentioned

bf: in webthings, we have capability schemas
… this was inspired by schema.org
… I like that approach. profile guarantees technical interop
… this adds a layer on top
… however that creates silos again

ek: maybe thinking of Consumer roles would help

Ege: If I come to someone making a device like Conexxus, they want guidance while they are implemetnign it and want to ensure device is usable by the most amount of people

Ege: Need guidance + guarantees what they are doing will be useable by most amount of people

Ege: Would be helpful if we could say to them this is the smart safe profile, here's how you do it. E.g. what Matter does - this is a light, this is how you do it. What device manufacturers want to hear. Would like to get input from those types of people. Currently specifications are killing anyone who wants to get started with the Web of Things

unless they are already comfortable.

bf: matter commodizes devices and reduces differentation
… so we can keep profiles open like now so that implementations can be varied and can differentiate
… Creating domain-specific capability schemas is a lot of work

mjk: we tried iot.schema.org but the community did not want it
… some did not want constraints
… I asked why do you want to innovate on a light switch
… we couldn't attract the domain experts to contribute models
… matter-using companies want to differentiate in the cloud etc.
… maybe finding a middle ground like Ben said makes a lot of sense
… from the user side, it is better to have something easy to implement

bf: what is the best way to do that

benfrancis: Thing Models seem to constraining, but semantic annotations maybe aren't the right way either.

benfrancis: (regardless of whether it is part of Profiles or not)

mkoster: The community seem to be converging on SHACL style shape constraints.

ajourned.

<benfrancis> s/Topic: Publication/Topic: Profiles 1.0 Publication

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/fin/fine

Succeeded: s/scribenik/scribenick

Succeeded: i/I had one comment/Topic: Profiles 2.0 Planning

Succeeded: s/he is not wg member anymore/Matsukura-san is not wg member anymore

Failed: s/Topic: Publication/Topic: Profiles 1.0 Publication

Succeeded: s/topic: Publication/topic: Profiles 1.0 Publication

Succeeded: s/and that is a lot of work/Creating domain-specific capability schemas is a lot of work

Succeeded: i/it is annoying that we had to change the editors/subtopic: PR #451

Succeeded: s/I will contact him directly/I will contact Philippe directly

Succeeded: s/benfrancis: Evening/asynchronous stuff is most important decision that is left to implementers. Would like to see SSE put into HTTP Basic, because Webhook needs completely different infrastructure./

Maybe present: bf, ek, mjk, tm

All speakers: benfrancis, bf, Ege, ek, mjk, mkoster, tm

Active on IRC: benfrancis, dezell, Ege, Mizushima, mjk