Update wot-wg-2023-draft.html: Adding digital twins #46
Conversation
|
Comments from meeting:
|
|
Consider also #24 |
|
While I said it's quite broad, this is in the context of much more specific work items. Lately I've been thinking we should uplevel the entire section and just lay out some general goals. In that case "support for digital twins" could be one such general goal (although I think even if it's not in the charter, we should still have some detailed planning for specific work items; as a work item "digital twins" is too vague). |
There was a problem hiding this comment.
I think there are problems with this PR and I don't think we should merge it. Digital Twins cannot be a work item on its own but maybe a category? In any case, we already enable doing this so it is not clear what is really missing. Regarding behavioral description: There are many many standards and methods out there and it would be unwise to try to do it ourselves. Especially, if we are really going into describing how a heater changes the room temperature, we are opening a can of worms in simulation areas. A linking mechanism of WoT operations to state machines would be an interesting direction and we can leverage standards like SCXML. So I agree with what @mmccool says.
There was a problem hiding this comment.
Giving my a review as requested. I agree with the above, but perhaps with a more radical take on the Behavioral Description section. Sadly, I missed the latest profile calls, but I am not sure we should commit to describing the behavior of Web Things in a declarative way inside Profile deliverables... It feels out of scope with the out-of-box interoperability (as I understand it) and it is probably a whole spec in-it-self (kind of a new programming language). Therefore, I would remove it.
The behavioral description could be part of the TD spec, described in a profile, a WG note etc. The entire section currently just lists potential candidate "homes". |
…-description Update mlagally-digital-twins for wot-wg-2023-draft.html
|
@mmccool @relu91 @egekorkan |
| <dd> | ||
| Enable using WoT for describing digital twins and structures thereof, | ||
| i.e. virtual things that are an abstraction of real world devices and services. | ||
| This includes management of historical data, intermittent connectivity and twin graphs. |
There was a problem hiding this comment.
historical data is covered by another work item but I guess it is fine to repeat. However, the other two subitems are a bit unclear to me.
Intermittent connectivity is already solved with MQTT. Do you have something specific in mind?
What do you mean by twin graphs?
I think the changes are welcome. I have left a minor feedback above |
|
As discussed in the charter meeting digital twins doesn't really make sense as a work item, it's more of a general application area of the Web of Things which multiple work items may contribute to. I think many of the requirements that digital twins might have of the Web of Things are already covered by existing features or other work items already proposed in the charter.
I would argue that all Web Things are an abstraction of real world devices and services. What is missing?
This is already covered in another work item.
This needs to be dealt with at the protocol binding level (e.g. a Consumer can catch up on missed events using SSE), it's not specific to digital twins. Perhaps a new topic relevant to digital twins might be synchronisation of data between a Thing and a Virtual Thing? But that may require a bit more in the way of requirements analysis before it can be turned into a concrete work item.
Presumably a "twin graph" would take the form of links between Things, which are already possible with Thing Descriptions. Are new types of link relations needed perhaps? My understanding of digital twins in the context of WoT is that:
From this list I think only 3, 4 and 5 are new areas for the charter. 3 is already covered in another work item. 4 is interesting but is there something well defined that's missing from WoT specifications which this working group needs to standardise, or is this just implementation specific? 5 is possibly something that could be addressed in a WoT specification (synchronising state between Things), but I'm not sure how. |
|
I think there is a misunderstanding about the "intermittent connectivity" issue. That is the problem. The digital-twin-ish solution (feature) would be a "state shadowing service" that can report the last known state or expected state of a Thing if it is disconnected (generalizing the retained feature of MQTT). |
There was a problem hiding this comment.
I don't think we can merge this as is, as IMO digital twins are not a work item, they are a broad category. I would update the description of digital twins in the summary, and the work item currently labelled as "Digital Twin" should be labelled something like "Shadowing" and the overlap with "Historical Data" resolved (the latter is also part of a "digital twin").
|
suggest rebasing, moving Digital Twin up to the summary section, then adding appropriate low-level details. For now good to add such things to both documents (at some point we need to consolidate) |
|
Note: after (if) we merge #64 then we can add work items to the "plan" without having to commit to them in the charter. We should discuss (after the charter is done) the plan as well, including prioritizing work items, deciding which are central and which are stretch goals, where they should go (in what deliverables, etc). But I think as for the charter scope we just need a broad statement of intent, such as "Continue to develop standardized features supporting Digital Twins" or the like. |
|
Regarding the part about digital twins: #55 has introduced the use cases related work item that talks about DTs. I suggest removing it from here. See |
|
Probably at this point this PR will have to be closed without merging, as the structure of the document has changed. Suggest new PRs to update the scope summary (if necessary) and add detailed work items to the "details" document if some are needed. |
|
Agreed in mtg that this is stale and needs to be closed, but may be other PRs later. |
Preview | Diff