Declaring constraints for mutations on exons and functional domains?

[jsstevenson]

I have two categorical variants in mind -- one is variants on a functional domain, eg "ERBB2 Kinase Domain Mutation" (https://civicdb.org/molecular-profiles/409/summary) and the other is variants on a particular exon, eg "CTNNB1 Exon 3 mutation" (https://civicdb.org/molecular-profiles/2761/summary). At first I thought these are sort of just features like genes, so they could go in as FeatureContextConstraints, but I was having trouble with the best way to represent each feature as a MappableConcept:

• There are ID systems for proteins, and ID systems for domains, but I don't know of anything that assigns a unique ID to a specific domain ON a specific protein
• Obviously no one's shipping unique IDs for every exon on every gene

So then I thought that both could just be DefiningLocationConstraints on the respective protein and genomic sequences, maybe with some additional extension annotations to indicate the features that they enclose. Does that seem right?

(And if so -- what's the use case for FeatureContextConstraints at all, since you could also just express them as ranges on an accession?)

[DanielPuthawala]

Ok, so I think the intention is, as you suggest, to handle these with the FeatureContextConstraint. As you point out though, there's a bit of an issue in that either (1) there may very well not be a coded concept specifically for CTNNB1 Exon 3, and (2) the FeatureContextConstraint at present doesn't allow a, dunno, compositional feature? Like coding for CTNNB1 + Exon + 3 or something like that. Ditto the same issue in the case of the ERBB2 Kinase Domain.

Perhaps we should propose a property or enrich the featureContext property of the FeatureContextConstraint.

In some instances you could handle this with the DefiningLocationConstraint, but now always, especially wrt to provenance. For example, if we're just getting CTNNB1 Exon 3 mutation from a paper, and we don't know what reference build and transcript they were talk about, let alone whether they mean the HNGC gene CTNNB1 vs the Ensembl gene CTNNB1, then trying to instead use DefiningLocationConstraint, except for in certain cases and if you're being extremely careful, will almost inevitably involve introducing overprecision.

I'm all for enriching the FeatureContextConstriant if that's what we need to do, I would just love for a more someone with a deeper background in bioinformatics than I to weigh in on that issue first.

[brendanreardon]

I totally agree with Daniel's wonderful response, adding some additional thoughts, too.

So then I thought that both could just be DefiningLocationConstraints on the respective protein and genomic sequences, maybe with some additional extension annotations to indicate the features that they enclose. Does that seem right?

Adding that this also relates to the open Issue for combining categorical variants with boolean operators, or "complex" categorical variants. Indeed both "kinase domain" and "exon 3" are locations, so you could just represent both of those with the location, but you would have to use an "OR" criteria for the Defining Location Constraint with the former if you wanted to include the nucleotide locations for the kinase domain because it spans multiple exons.

(And if so -- what's the use case for FeatureContextConstraints at all, since you could also just express them as ranges on an accession?)

This is kind of an open question and we've been iterating on it through the calls! I think that people are agreeing~ish on perhaps having an additional property within DefiningAllele and DefiningLocation constraint to represent mappable concepts that may alternatively be placed within the FeatureContextConstraint, similar to how "location" is nested within the "allele" of DefiningAlleleConstraint. The example that we have been using is BRAF V600E and BRAF Missense Mutations, there needs to should be a way to communicate that the location is within BRAF for both. You can see in the meeting slides for the May 7th meeting.

[brendanreardon]

@jsstevenson and @DanielPuthawala I am going to close out this Discussion but feel free to open it at any time!