Wot-thing-description: id field in TD Templates

[egekorkan]

While working on Issue #552 I have noticed that we use _id_ field in the TD Template examples. I find it a bit confusing since _id_ identifies a unique Thing instance, virtual or physical. However, in the TD Template examples, they are used to identify TD Templates which are not Thing instances and should not have an _id_ field in my opinion. They are even used to link multiple templates together so _id_ is used intentionally.
I see that most of the TD Template examples are provided by @mlagally so could you provide your opinion on this?

[sebastiankb]

in today's TD meeting we decided to remove the id term in all the template examples.

In addition, we should remove Section B.1.3 since the mechanism is not really clear (e.g., id values should not be used within @type to make references to other templates.

@mlagally is this ok for you? Can you make a PR?

[mkovatsc]

Also see #600

We should mark it clearly as non-normative.

[sebastiankb]

to speed up, I fixed the issues in the PR #641
@mlagally can you make a review?

[mlagally]

@sebastiankb I'm not happy that the Thing template example has been removed.
It adds value and shows how the templates can be applied and how several templates can be used by a thing.
If there is some syntax problem in this example that needs to be fixed, let's rather do that and not drop it completely. I will create a PR.

[mkovatsc]

The whole mechanism of how to combine and reference Templates is very sketchy. It is valid to define them and to use them as input to ultimately produce a well-informed TD document. How this is done exactly is implementation-specific for now, as we are far from implementation experience and a consensus. The approach indicated in the previous example was technically wrong.

[egekorkan]

@mlagally I had actually find this way of combining the templates an interesting idea but as @mkovatsc has mentioned it is implementation-specific and there is not enough experience ( I am aware of the idea for a long time but I haven't seen any uses of it in the Plugfests for example ). The hint that this is possible is left as the final bullet point combining multiple models into a Thing. and also A concrete Thing Description can implement multiple Thing Templates and thus can aggregate function blocks into a combined device.

It adds value and shows how the templates can be applied and how several templates can be used by a thing.

@mlagally Wouldn't these explanations be enough?

[mlagally]

We are mixing several aspects in this discussion:

1. should templates have a (unique) id?
   Yes, this is required to make sure that it is easy to identify two things that implement the same template.

2. Template examples in the plug-fests
   The Oracle device models use a template mechanism. Since the plug fest members so far were implementing only single devices, we did not elaborate on that. In real world use cases there are multiple devices that have the same structure (i.e. implement the same template), that will be managed together. Please be aware, that the view of the world from the device manufacturer side and the cloud vendor side has different aspects

3. Templates and the corresponding specification section was discussed and reviewed at the end of last year. I'm concerned that spec sections get removed at this late point in time without giving the author an opportunity to comment (note that I was attending last week's TD call for the first hour, but the issue was not discussed during this time) and the section was removed during the weekend.

4. Implementing multiple templates in a thing
   The section we are discussing is an example in an informative annex.
   @mkovatsc Please clarify what you mean with "technically wrong"?

[mkovatsc]

1. This must then be something like templateId. I am not aware of any Vocabulary definitions for Thing Templates.
2. Oracle uses their vendor-specific "Device Models". The Protocol Binding for Oracle that I implemented uses Thing Descriptions with a custom field that points to an Oracle Device Model, not a Thing Template.
3. To my understanding, the section was for informationally documenting how the TD definitions can be turned into a Thing Template mechanism (by omitting the instance-specific members). We only agreed on removing the third example that shows an untested mechanism for pointing to Templates. It does not even explain what that means in detail. Thus, it should be left to implementations, how they generate well-formed TDs given a Thing Template and instance information as input.
4. Wrong from a technical perspective. Some point, as there are no details given supporting the example:
5. http://www.w3.org/ns/thing-templates is not a valid namespace
6. urn:dev:ops:32473-WoTLampTemplate-0000 is not a Subclass of Thing, but given in @type
7. id is identical to the ID of the template (urn:dev:ops:32473-WoTLampBuzzerTemplate-0000)
8. What does thing-templates:components do?
9. The given example shows a Thing that has no Interaction Affordances whatsoever
10. At this point, I am not even sure anymore, if you want to depict an example of a Thing based on Templates (you say @type: Thing), or a Template that is defined through some Template-include machanism.

[takuki]

The controversial third example in Thing Templates section was removed per resolution on 5/2 TD teleconference.

It was removed because “id” should not be used to make a reference in @type.

[takuki]

@mlagally suggested to defer this issue to the next version of TD during 5/9 TD teleconference.

[takuki]

Note that TD Templates will be discussed on 3/17 (Tues) during a virtual F2F TD session.

[mlagally]

Please review the use cases that motivate for the templates in the architecture repo,
specifically:
https://github.com/w3c/wot-architecture/blob/master/USE-CASES/big-data.md
https://github.com/w3c/wot-architecture/blob/master/USE-CASES/digital-twin.md

[sebastiankb]

@mlagally I read your use cases and I have some difficulty to see the concrete motivation why we need TDTs.

Using a digital twin allows businesses to analyze their physical assets to troubleshoot in real time, predict future problems, minimize downtime, and perform simulations to create new business opportunities.

For that you need TDs to know the offered data model of the assets and how to get the runtime data. For simulation you can skip the communication information in the TD and simple take the data model information that is provided in the interaction affordances.

Big data analysis enables to identify behavioral patterns across multiple production lines of the entire production plant and across multiple plants.The results of this analysis can be used for optimizing consumption of raw materials, checking the status of production lines and plants and predicting and preventing fault conditions.

Same situation here: You can rely on TDs which offers you the data model where you can apply data analysis. Checking that statues etc. you will need the communication setup to the physical device.

I think we need a specific use case sheet that addresses the need for TDT. For me the main motivation is to be able to define TDTs for device classes that can be instantiated when the device is deployed, e.g., in a system.

[mlagally]

@sebastiankb

I think we need a specific use case sheet that addresses the need for TDT. For me the main motivation is to be able to define TDTs for device classes that can be instantiated when the device is deployed, e.g., in a system.

I agree, however in the current TD the forms including protocol binding(s) are mandatory, which does not make sense for these classes. The same applies to the security definitions.

We have to collect and refine specific requirements in https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-templates.md

[zolkis]

If a template id is needed in order to tell if two Things implement the _same_ template,
then why not use a content hash (like git is using) instead of a stored id (that is, a _template id_)?

That hash could also be also mapped to database id's, separating the concerns.
In this way we could solve the use case without the need to store a template id.

[sebastiankb]

@mlagally

I agree, however in the current TD the forms including protocol binding(s) are mandatory, which does not make sense for these classes. The same applies to the security definitions.

That is the reason why we need a formal definition of TDT. I think this discussion should be continued here: https://github.com/w3c/wot-architecture/issues/454

@zolkis

If a template id is needed in order to tell if two Things implement the same template,
then why not use a content hash (like git is using) instead of a stored id (that is, a template id)?

I think this is not what we can standardize since such kind of mechanism is bound to a concrete system like git.

I'm wondering why the web linking mechanism cannot be used to clarify two Things implement the same TDT. We have just to define a rel like 'implementsTDT' or similar.

[sebastiankb]

id term is optional and can be used in combination with a PLACEHOLDER