What to do with the profile keyword

[egekorkan]

Now that profile will not be published as REC, what should we do with the word?

[egekorkan]

@mmccool said we can keep it so that it can be used in the next charter and we have passing cases. I find it a bit weird to keep it if the values for it are not constrained and what a profile can do is not constrained

[benfrancis]

I was wondering about what might happen in this scenario.

Given the resolution is to delay the transition of WoT Profile to REC status to early in the next charter period rather than cancel it, I think it's very important that the profile keyword is not removed from Thing Description 1.1. If it's removed then this will effectively delay the publication of WoT Profile 1.0 until WoT Thing Description 2.0 is published (presumably towards the end of the next charter period), which is definitely not what we want.

That leaves the problem of what to do with the dangling reference to "WoT Profile" in the Thing Description specification, since the WoT Profile specification will not be published by the time that Thing Description 1.1 is published (although strictly speaking that may be the case for WoT Architecture and WoT Discovery too).

To be honest, the profile member is already poorly defined inside the Thing Description specification at the moment:

Indicates the WoT Profile mechanisms followed by this Thing Description and the corresponding Thing implementation.

There is no formal reference to what "WoT Profile mechanisms" means.

Below are the steps I would suggest to resolve this...

1. Change the description of the profile member in the Thing Description specification to something along the lines of:

"A URI or list of URIs which identify one or more profiles to which the Thing Description and corresponding Thing implementation conform."

2. Move the definition of the term "profile" from WoT Profile to either WoT Thing Description 1.1 or WoT Architecture 1.1.

For reference, the latest version of that definition reads:

"A technical specification which provides a set of assertions such that any Consumer which conforms with the those assertions is out-of-the-box interoperable with any Thing which also conforms with those assertions."

Personally I think those two steps would be sufficient, since that's really all that a profile is in WoT Profile 1.0 and it explains what the member is for, even if there aren't any profiles defined yet.

---

If this isn't sufficiently clear then a third step could be...

3. Move all the assertions from the Profiling Mechanism section of WoT Profile to WoT Thing Description 1.1.

This would define the profiling mechanism in the normative Thing Description 1.1 specification, without needing to publish a separate WoT Profile specification, with the actual profiles being published later at the start of the next charter.

---

I realise this would be a late change to the Thing Description specification, but it's arguably a bug fix since the profile member is poorly defined in the current draft. I think there are sufficient implementations of the profile member itself to allow this feature to advance to recommendation status.

An alternative to the steps above would be to publish a WoT Profile specification as a REC in this charter period which only defines the Profile Mechanism, and nothing else. But I think that would involve more work overall.

Note: There is one other reference to WoT Profile in WoT Thing Description 1.1, in the privacy considerations section.

[mmccool]

Note also there was a PR to make references to Profiles in Architecture 1.1 to be informative in nature.

The profile keyword in the TD spec points at a URL, and imo is in a similar situation as extension URLs in @context: in @context we have not explicitly defined what vocabulary extensions there will be (in fact it is open-ended), just how they can be indicated. So I don't think it is a problem at all to provide a place to indicate profile URLs in the same way without necessarily defining specific profile URLs (yet).

[mlagally]

@benfrancis wrote:

Below are the steps I would suggest to resolve this...

1. Change the description of the profile member in the Thing Description specification to something along the lines of:

"A URI or list of URIs which identify one or more profiles to which the Thing Description and corresponding Thing implementation conform."

I certainly think this is a good solution that provides additional clarity.

2. Move the definition of the term "profile" from WoT Profile to either WoT Thing Description 1.1 or WoT Architecture 1.1.

For reference, the latest version of that definition reads:

"A technical specification which provides a set of assertions such that any Consumer which conforms with the those assertions is out-of-the-box interoperable with any Thing which also conforms with those assertions."

Personally I think those two steps would be sufficient, since that's really all that a profile is in WoT Profile 1.0 and it explains what the member is for, even if there aren't any profiles defined yet.

I suggest, instead of moving things out / around at this point of the process, we better copy the definition to the Architecture spec.

[sebastiankb]

I think, we already agreed to keep the "profile" term since we have also TDs used in the TestFest.

@benfrancis

"A URI or list of URIs which identify one or more profiles to which the Thing Description and corresponding Thing implementation conform."

I think, this can be seen as an editorial change to bring more clarity.

@mlagally

I suggest, instead of moving things out / around at this point of the process, we better copy the definition to the Architecture spec.

+1
A definition is missing anyway. Also see the comment here.

[egekorkan]

I think that the keyword itself can stay, adding propose closing.

[egekorkan]

Call of 05.04:

• It is also not at risk so we cannot remove it
• We decide to keep it.