Update copyrights, unify naming, prepare RC1 #96
Conversation
Signed-off-by: Pierre R. Mai <[email protected]>
Signed-off-by: Pierre R. Mai <[email protected]>
Signed-off-by: Pierre R. Mai <[email protected]>
|
|
||
| *Abstract* | ||
|
|
||
| The SSP Layered Standard Traceability is a layered standard provided by MAP SSP upon SSP 2.0 to support traceability of simulation tasks. |
There was a problem hiding this comment.
Is the standard only applicable to SSP2.0?
There was a problem hiding this comment.
No, it also applies to SSP 1.0, in the sense that any SSP 1.0 file is a valid SSP 2.0 file. The rest of the document clarifies this, as the layered standard is still based on SSP 2.0, as it uses 2.0-introduced elements in its own file formats. I might clarify this here some more, however the abstract is non-normative in any case.
|
|
||
| __Note: The Credible Simulation Process Framework actually includes more than just Credible Decision Process and Credible Simulation Process. | ||
| However, the SSP Traceability specification currently only supports traceability with respect to the Credible Decision Process and the Credible Simulation Process.__ | ||
| However, the SSP Layered Standard Traceability currently only supports traceability with respect to the Credible Decision Process and the Credible Simulation Process.__ |
There was a problem hiding this comment.
Could the the Credible Modeling Process also be seen to be supported, in an intermediate way, via the SRMD format? If so should this be clarified or will it just introduce ambiguities.
There was a problem hiding this comment.
The SRMD format is not supposed to be the equivalent of an STMD in terms of credible modeling process - for this we await the next release of SSP-LS-Traceability that would introduce direct support - in one way or another - for a purely credible modeling process. So I would try to stay away from muddying the waters, things are already fairly ambiguous as it is...
|
|
||
| The exception is the derivation chain. Each time an STMD or DTMD file is written, a new entry is created in the derivation chain with a unique identifier of the file from which the new instance is derived. | ||
| When a tool or data management system receives an SSP Traceability container with STDM, DTMD back, it can check, by comparing the derivation chain with the target system's data infrastructure, which version of the DTMD or STMD was sent. | ||
| When a tool or data management system receives an SSP Traceability container with STMD/DTMD back, it can check, by comparing the derivation chain with the target system's data infrastructure, which version of the DTMD or STMD was sent. |
There was a problem hiding this comment.
Not really, as the SRMD format does not have a GeneralInformation/DerivationChain element. It is not really a round-trip supporting format in this specific sense.
There was a problem hiding this comment.
Follow up question, why does it not? Wouldn't it make sense for it to have such an element?
There was a problem hiding this comment.
It really was never intended as a round-trip format, and I don't think the current usage as such is a terribly good idea - if having arbitrary key-value pairs flying around between multiple partners is considered a good idea, then I would suggest we should remove STMD and DTMD from the LS and just specify SRMD.
The idea behind SRMD was just to be a neutral storage medium for additional meta-data that travels with a resource, and resource exchange in the SSP-LS-Traceability case always happens in an STMD or DTMD context, which provides for the round-tripping and necessary context.
If there is a change in focus here, I think we really should reconsider whether SSP-LS-Traceability makes sense in the current state of affairs: If just exchanging arbitrary key-value pairs is the core motivation, I would actually suggest to use existing standards like W3C RDF and friends, which seem much more widely supported.
No description provided.