Architecting TM support

[FadySalama]

1. General:

   • We do JSON, JSON-LD, normal TM validation and probably additional check (need to restructure core package)
   • New assertion validation for TMs

2. Assertions Package:

   • Add 2 assertion folders and 2 list.json for TMs and TDs

3. CLI consideration

   • Add options for validating TM or TD
   • Allow the user to specify additional schemas for validation?

4. Frontend (low priority)

   • Dynamically detect TD or TM etc...

[fennibay]

Hi, I'd like to see this issue solved, as well.

Regarding detection of TM vs. TD, I think this should be handled based on the @type of the Thing, as explained in Thing Model:

definitions are identified by the "@type": "tm:ThingModel".

This way we don't have to implement different solution for CLI and Frontend.

Based on this detection, for instance the appropriate schema should be picked for JSON Schema validation, further checks can vary on that basis.

[egekorkan]

So we have decided to not do this based on @type. Our reasoning was:

• If you are trying to validate TM but forget @type you will get lots of errors
• Finding the correct validation can be done on top, this will be done later. WIP for now

[egekorkan]

A first version is available for CLI since a couple of weeks btw: https://github.com/thingweb/thingweb-playground/blob/master/packages/cli/index.js#L38

[egekorkan]

I think that we can close this now given that we have TM in the web as well. The additional schemas can be another issue since it is not just about TMs in general

[mkovatsc]

So we have decided to not do this based on @type. Our reasoning was:

• If you are trying to validate TM but forget @type you will get lots of errors
• Finding the correct validation can be done on top, this will be done later. WIP for now

I want to revisit this in the context of a potential bug in the Thing Model design in TD v1.1:

• First of all, someone forgetting a key element should be rewarded with lots of errors. So I cannot see the argument.
• Second, "finding the correct validation" sounds a lot like media type guessing to me and should not be done.

On top, I believe we have a bigger issue:

To my understanding a node cannot be be of (@)type Thing and tm:ThingModel at the same time, as they have conflicting rules about default/mandatory/optional fields apply (i.e., ontology conflicts),

Previously, the TD context file always implied @type because there was just one core type: Thing. Hence, there was no default value definition at Thing level for @type and the rules that even if an @type is given, e.g., "saref:LightSwitch", Thing was still implicitly part of the @type predicate (i.e., ["saref:LightSwitch", "Thing"]).

Now, this does not work anymore, as an @type of "tm:ThingModel" would also become ["tm:ThingModel", "Thing"] -- BAM, conflict. We do need proper default value mechanics for @type now.

Hence, the TD spec 1.1 first needs a fix of this bug. And then we can also rely on the @type, while TM authors forgetting to set the correct the @type are rewarded with lots of honestly earned errors :)