odpt-compose.yml redesign

[caviri]

Context
Initially odtp-compose.yml was conceived as a way to describe and replicate any digital twin and its executions. There was some internal misunderstanding and this file was taken as:

• DT-History: An explicit description of executions including components, parameters, inputs, and outputs`. With this you should be able to run exactly all the steps computed previously

And

• DT-Template: A more flexible description containing templates for executions including components, some default parameters, and maybe inputs sources. This allows the designing of a copy of a digital twin able to run with new data.

Proposed solution
Design a procedure to describe both cases and export a DT history. This may involve the inclusion of semantic information about a DT input and output, paving the way for the reuse of DT as components when developing nesting DTs.

Acceptance criteria

• Plain-text format development for definition of both cases.
• Procedures to export this from ODTP
• Sharing method (based in Github?) for DT-Templates and DT-History

[jugdemon]

@caviri Is this DT-Template corresponding to workflows and the history to a sharable version of the DT which I previously labelled as a trace?

@sabinem Revisiting this issue, should we add trace information to the ODTWS under the workflow section? I think the section was rather short anyway and this could neatly encapsulate the logic?