This is a candidate solution for the Temporary deployment scenarios.
In response to the suggestion Temporary deployment: State property on Automation Result contribution, it was suggested that we could define an OSLC-defined “resource 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.
Teardown could then be achieved by updated this state to “tearing down”, or “torn down”, or we could have a “desired state” property similar to existing automation RDF resources.
This adds some complexity to the consumers (compared to Temporary deployment: State property on Automation Result contribution and some possible implementations of Temporary deployment: State property on Automation Result contribution), but only in terms of having to look in two locations for the property to use for teardown. It allows providers that want to support teardown to be flexible: they can either provide a complex graph of the resources that were deployed, and add this state property on them, or it can provide a single state property that can be used to “tear down everything that was deployed by the deployment that created this Automation Result”.
However it would take a lot of thought (if it’s possible at all), to design an OSLC-defined state model that is flexible enough to be useful for other actions beyond teardown, while also simple enough for consumers to be able to achieve teardown with as little knowledge about the provider as possible.
