It would be useful when a TD API has several sub-parts to be able to separate them in a modular way so they are easier to understand and also, when the sub-parts are each "implementations" of a sub-API capability described elsewhere (eg in a TD Model) we don't have to worry about name conflicts (eg if two different sub-APIs have a "status" property...). We would still want to use links to refer to the TD Models each sub-API "implements", and so maybe each component should have its own links section.
More concretely, I am thinking something like a "components": { "name": obj } structure, where "obj" is basically a Thing (perhaps with some metadata removed, i.e. no need for an id, etc). We could also use an array rather than an object to list components, and we would have to decide whether or not we should allow recursion. Having components names is good IMO though since then we can define a "flattening" operation that avoids name conflicts (for example, flattening to a "component.member" name syntax...).
Another use case is the TD we are writing for the WoT Directory, which has several sub-APIs. Right now they are all "mixed" together which is confusing.
Solution should be aligned with OneDM, ideally. Since OneDM uses the term "object" we could consider using that instead of "component".
why not using the link container for this?
from today's TD call:
Below is the image with which the WG discussed this issue during 2020-10-21 virtual F2F meeting (see minutes).

@sebastiankb wrote:
why not using the link container for this?
+1
E.g.
"links": [
{
"rel": "component",
"href": "https://example.com/things/mything/tv",
"type": "application/td+json"
},
{
"rel": "component",
"href": "https://example.com/things/mything/radio",
"type": "application/td+json"
}
]
@takuki is this issue still relevant? I would propose to close this issue
Most helpful comment
why not using the
linkcontainer for this?