ThingModel composition and TD relation

[danielpeintner]

I have a question about 2 ThingModel examples.

• Example 57, Thing Descriptions of the Smart Ventilator
• Example 58: Self-contained TD of the Smart Ventilator TM

Both examples speak about ThingDescriptions. To me, only Example 58 is a real TD. Example 57 is still a TM since all the links are not resolved. I don't assume a client needs to resolve any links. My assumption of a TD is that it is self-contained and no further link resolution needs to be done. Am I wrong?

[egekorkan]

I am guessing you are saying that the link container has some link elements whose href have relative URLs? I would not call it a TM just because of that but indeed it is not normal to have relative URLs in links (or in forms) without a base. Adding a base term or making the links` hrefs absolute would solve this problem right? Also, example 58 also has relative href in links

[danielpeintner]

It is not purely about links but also about the actual affordances. The links point to Ventilation.td.jsonld and SmartVentilator.tm.jsonld.

Isn't it the case that a valid TD should contain all the affordances of those referenced TDs. If this is not the case, a consumer of such a TD needs to read those external files also which is not what we want (I think):

[egekorkan]

I have a feeling that we are looking at different TDs :D All the affordances have the absolute URLs:

"properties": {
        "switch": {
            "type": "boolean",
            "description": "True=On; False=Off",
            "forms": [
                {
                    "href": "http://127.0.13.212:4563/switch"
                }
            ]
        },
        "adjustRpm": {
            "type": "number",
            "minimum": 200,
            "maximum": 1200,
            "forms": [
                {
                    "href": "http://127.0.13.212:4563/adjustRpm"
                }
            ]
        }
    }

[danielpeintner]

My comment is not about URLs.

My comment is about the file itself. The file labelled as "Top level Smart Ventilator TD" in Example 57 is not self-contained.

• It either has only one property, namely status which in the end means it is not following the TM which says it should extend Ventilation and LED OR
• a consumer of the TD needs to parse the external files ("./Ventilation.td.jsonld", "./LED.td.jsonld", ...)

[thjaeckle]

FMPOV the "submodel" / composition is not an extension - so the "Smart Ventilator TM" in Example 56 does not extend "Ventilation" and "LED" TMs, but references them as "has-a" associations (similar to a class in object oriented programming which defines that instances of it will include references to instances of other classes).

In OOP it would be an anti-pattern to e.g. expose state of a "has-a" association via the instance containing the composed instances. Staying at the "Smart Ventilator" example - smartVentilator being an instance of the Smart Ventilator class (a.k.a. TM) you would e.g. not have access to the "Ventilation" properties by doing:

SmartVentilator smartVentilator = ...
boolean switch = smartVentilator.isSwitch(); // from ventilation
double adjustRpm = smartVentilator.getAdjustRpm(); // from ventilation

Instead you would do:

SmartVentilator smartVentilator = ...
Ventilation ventilation = smartVentilator.getVentilation();
boolean switch = ventilation.isSwitch();
double adjustRpm = ventilation.getAdjustRpm();

The question however remains whether Thing Descriptions and their relations to Thing Models aim to follow the best practices of object oriented programming with classes and instances, or not.

I also see the benefits of having a fully self-contained TD as shown in Example 58, mainly:

• the consumer of the TD does not need to resolve and parse additional links

If that however is the goal, you could still use the extension mechanism when modeling TMs.

What I currently don't like is the 2 options when using the composition: I think there should be either Example 57 or Example 58 as "recipe" how to convert the composition modeled in TMs into TDs - having both options leaves the decision to the TD generator - and is potentially different for each TD generator.

[sebastiankb]

@danielpeintner

My assumption of a TD is that it is self-contained and no further link resolution needs to be done. Am I wrong?

You don't need any further link resolution if, for example, you want to use only the top-level TD. All interactions are "self-contained" and independent of the underlying sub-Thing Descriptions. This is also true in the reverse direction. The link container just gives the consumer a hint that there is more opportunities to do by navigating to a subsystem that has its own (self-contained) TD.

[danielpeintner]

My fault, I think I really confused Composition with Extension.

Maybe a "reason" why this happened. Example 57 talks about a "Smart Ventilator" and links to a normal "Ventilation" which gives the impression one extends the other. May I suggest to label the "root" TD differently, e.g., a "Room". A room can be composed of a ventilator and an LED and fits a composition better.

[sebastiankb]

from today's TD call:

• we should find better TM/TD names than "Smart Ventilator" and avoid "top level" text
• I like to collect some alternative names that avoids confusions and do not need to define a complete new example
• maybe we should also consider to move the TD transformation to the section 10.4. This should also aligned with the provided algorithm there

[sebastiankb]

from today's TD call:

• we should provide in addition to the introduction text an explanation what is the different to extension and its limitations
• it seems that we should select a different example to avoid confusion, eg., multi-sensor system that consist of two different sensors, multiple power strips that has different devices connected, LED strips (used by oneDM as example)
• @sebastiankb will provide a PR as a proposal for discussion

[mjkoster]

https://github.com/one-data-model/exploratory/blob/master/sdfThing/sdfthing-outletstrip.sdf.json This outlet strip uses an array... Actually in SDF you can define multiple instances without naming them It doesn't mean that it is necessarily an array Just multiple instances SDF can apply "minItems" and "maxItems" to any definition without using an explicit array even though in this definition it's called "OutletArray"...

[mjkoster]

Here's an example with named instances of the outlet unit https://github.com/one-data-model/exploratory/blob/mjk-examples/sdfThing/sdfthing-named-outletstrip.sdf.json

[thjaeckle]

I created a new example in scope of the TM->TD generation in Eclipse Ditto (e.g. in order to test/show all TM concepts like "tm:extends", "tm:ref" and "tm:submodel". The example TMs are available here: https://github.com/eclipse/ditto-examples/blob/master/wot/models/ And the TM including several submodels is this one: https://github.com/eclipse/ditto-examples/blob/master/wot/models/floor-lamp-1.0.0.tm.jsonld

And another TM example I worked on (a "multisensor device"): https://github.com/eclipse/ditto-examples/blob/master/wot/models/octopus/octopus-suite-edition-1.0.0.tm.jsonld

Maybe that can be a good start for an example.