Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling Function Variants #14

Open
DanielPuthawala opened this issue May 13, 2024 · 1 comment
Open

Handling Function Variants #14

DanielPuthawala opened this issue May 13, 2024 · 1 comment

Comments

@DanielPuthawala
Copy link
Collaborator

DanielPuthawala commented May 13, 2024

Currently there are two issues with the current structure of the schema that I would like to address.

First, the CanonicalAllele and Protein SequenceConsequence both exist and are more or less identical, but are simply meant to describe sequence variants at two different levels, genomic and protein, respectively. While classes are cheap, DRY. I want to explore the option to subsume these two classes under a more general SequenceVariant class (name can be contested) that keeps the canonicalized properties of both, while differentiating genomic from protien variants by some sort of required level: one of {"genomic","protein"} property.

Second, while sequence variants are handled by CanonicalAllele or the new SequenceVariant class , and CNVs are handled by the CategoricalCNV class (subject to ay changes as a result of issue-11), there is a coherent class of variants not covered so far: Function Variants. Here's some suCatVars in this category:

  • Overexpression Variants
  • Unerexpression Variants
  • Gain-of-Function (GoF) Variants
  • Loss-of-Function (LoF) Variants
  • Loss Variants
  • Amplification Variants
  • Nonsense Variants (?)

These variants all entail some sort of assayed quantitative change, often but not always associated with some sort of sequence change. That is, capturing this class of CatVars requires properties from both the CategoricalCNV class and the SequenceVariant class. We could either create a third class that just happens to contain the same classes as both of those, or I propose we make a third class that is a generalization of the notion of quantity change and sequence change variants, subsuming both CategoricalCNV and SequenceVariant into a larger class, which, by way of optional properties, can handle CNVs, sequence variants, AND intermediate cases like the function variants described above.

@ahwagner
Copy link
Member

This seems like a duplicate of #16; I suggest we keep the discussion open but close the issue until there is consensus on developing this feature, as part of our GKS Technical Specification Maintenance process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants