Deletable logic
This will be a first draft of some rules for when we could and when we should not delete something. The rules are stated in terms of relationships or references to the candidate for deletion. In most cases, do not delete if any other references to the candidate. In some cases, cascade or consider a tombstone.
These considerations may vary depending on the feasibility of finding references in a particular technical environment. If finding references is difficult, consider leaving a tombstone. Given that we are targeting distributed environments, a tombstone might be the best bet in all cases.
If we opt for tombstones in all cases, "delete" means "leave a tombstone".
- Agent:
- do not delete if:
- any EconomicEvents or
- any Commitments
- any Intents
- cascade (also delete) other references?
- or consider a tombstone?
- do not delete if:
- ResourceSpecification:
- do not delete if:
- any RecipeResources
- any Intents
- any EconomicResources
- any EconomicEvents
- any Commitments
- any Claims
- do not delete if:
- RecipeResource:
- do not delete if any RecipeFlows
- ProcessSpecification:
- do not delete if:
- any Processes
- any RecipeProcesses
- do not delete if:
- Process:
- do not delete if:
- any EconomicEvents or
- any Commitments
- any Intents
- do not delete if:
- Plan or Scenario:
- do not delete if:
- any non-deletable Processes
- any non-deletable Commitments
- otherwise consider cascading (deleting) associated Processes and Commitments?
- do not delete if:
- Action:
- do not delete if:
- any EconomicEvents
- any Commitments
- any Claims
- any Intents
- do not delete if:
- Intent:
- do not delete if:
- any Satisfactions
- do not delete if:
- EconomicResource:
- do not delete if any EconomicEvents
- will a tombstone suffice for other references?
I think EconomicEvents and Claims are not deletable at all.
RecipeProcesses and RecipeFlows seem to be deletable at-will. Maybe also Proposals?
@fosterlynn what did I miss?