Open danielpeintner opened 2 years ago
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
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):
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"
}
]
}
}
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.
status
which in the end means it is not following the TM which says it should extend Ventilation and LED
ORFMPOV 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:
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.
@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.
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.
from today's TD call:
from today's TD call:
extension
and its limitationshttps://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"...
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
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.
I have a question about 2 ThingModel examples.
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?