I think that if you need such a tight coupling between ‘goals’ and ‘problems’ you might consider a template in combination with ckm-published or self-made archetypes (if the use case is not covered by the ones already published). This will allow you to specify constraints that makes sense semantically, but also can be used (programmatically) by any application.
If on the other hand, the coupling is a bit less tight, use of LINKs are always an option. You could also point to specific version of a composition, even to specific node inside it. It comes down to the uri of the target node. But the semantic of this construction is always less transparent, often deferred to application logic.
The third option is to pack (an organize) all related compositions into a FOLDER (and a potentially subtree). You can also point here to specific versions, and you can also assign meaning to such linking by archetyping and naming folder accordingly. In RM 1.1.0 you also have the ‘other_details’ part, so …lots of options there. This way you maintain a certain level of semantic of goal/problem coupling, the structure is archetyped, while you also keep the whole structure machine-processable, and not so much application depended as the LINK variant.
At Code24 we use all these three variants, for various reasons and purposes, so I can confirm that all are ‘workable’.
2 Likes