This is a candidate solution for the Temporary deployment scenarios.
In reaction to the solutions in Temporary deployment: Automation Result state, it was suggested that the deployed resource should be modeled as its own RDF resource, and a link from the Automation Result should mark that resource as a contribution to the result. Then that other resource could have some (well-defined?) means of modeling its state, including the request to tear it down.
These points were raised in response to that suggestion:
- The fact that the state currently defined for the Automation Result describes the state of the deployment process, and that perhaps a separate state model should be used for the deployed resource once deployment has completed, is a valid point.
- Would the state use an OSLC-defined vocabulary, or one specific to the resource type? If OSLC-defined, then it seems strange requiring other resource types to use our vocabulary. If from other vocabularies, then there’s no way for a generic OSLC client to achieve teardown.
- Also, some providers are lightweight adapters/wrappers on to an existing API, and may not want to expose additional RDF resources (plus there may be no appropriate vocabulary to do so).
- As a compromise, we could define an OSLC-defined state vocabulary, which could be used either on the result contribution resources, or on the Automation Result itself (as a separate state property to the one that already exists), and the consumers should be instructed to look in both locations. This is being tracked as a separate suggestion: Temporary deployment: Separate state vocabulary.
