Refining the CopyConstraint

[DanielPuthawala]

We need to refine the mockup of the CopyConstraint from the main constraint model discussion here.

That version supports reflects input from Out resident CNV experts to capture the properties important to them, such as the fact that values are often reported as absolute copy counts, x-fold changes, and/or log2 changes.

That version had a couple issues, one major one of which is that one would need to reconcile the values in scale and quantity to understand what that value means, and that invites... potential problems. Below I present possible refinements of that constraint mockup, reflective of two different strategies to capture copy number changes for categorical variants.

The version on the left maintains separate capabilities for representing an absolute copy number, vs representing copy change as either a fold change or a log2value. The constraint is restructured to make the associated quantity to be captured under the relevant value type.

The version on the right represents a different approach to representing the same information, treating is more as a sort of canonical copy number variant. Under this approach, we only support one scale in the constraint (here arbitrarily chosen to be the absolute copy count scale), for which we define relations to convert that absolute copy count quantity into either fold-change or log2value relative copy number change formats. This version has the potential advantage of making it easier to match a CNVs that are natively represented in different scales. (like TP53 - Copy number = 1 vs TP53 log2value copy change = 0.5)

I hope to hear people's thoughts on these two possible approaches to refining the CopyConstraint!

[DanielPuthawala]

The CopyContraint has been approved to Trial Use status, so this has been resolved.