Turning test set CatVars into examples.yaml

[DanielPuthawala]

A hub for discussion related to turning variants fro our test set into examples that we can build in tests for in the schema.

Currently the first (and only) example we have is the proteinSequenceVariant found here. We will need to construct similar such examples for each category of variants we are covering in our test set going forward, ideally with the involvement of those respective domain experts.

As an mea culpa, I don't actually know how we go about doing this other than what I can reverse-engineer based off the example above, so if there is anyone with experience/expertise in this domain who would be willing to share a guide for how to go about this for myself and our domain experts, I'd be most grateful.

I'm also aware that this is most likely going to be an effort the runs alongside our schema development, and may not happen right now, but I want to get this discussion out there so its in our brains when we need to start getting the ball rolling on this.

[rhdolin]

Hi @DanielPuthawala ,

In the proteinSequenceConsequence example, if I'm reading it right, it shows a set of members (lines 15-18). A couple questions:

1. How do you figure out what variant this 'vrs.json#/ga4gh:VA.7jX7fHgVEqx4C4jMRyZOH0ZBHnLn7_gJ' resolves to?

2. It is theoretically possible that many variants (e.g. NC_000007.13:g.55259514:TG:GA; NC_000007.13:g.55259514:TG:GC) also result in LEU858ARG. Is there way to express a criterion such as "any DNA change whose predicted molecular conseuence is LEU858ARG"?

[DanielPuthawala]

Hey @rhdolin!

This example actually entirely predates my direct involvement and was added by @ahwagner, so we pick his brain when he gets back. In the meantime...

For 1. the VRS identifier is a truncated SHA 512 hash of the VRS variant info, so afaik there is no efficient efficient manner to cryptographically recover the entry from the just the identifier alone (since hash algorithms are specifically engineered to make that very, very difficult). Rather, I believe the intended functionality in this case is to access the knowledgebase where that variant is, and then query based on that identifier, for which there should only be one unique match.

For 2. Yes. Indeed, I have two trains of thought as to how this could be handled, one of which is much more hand-wavy, and the other of which is perhaps way too granular to be useful.

The one is to just treat it canonically via relations, which would let you map it to other coordinate systems, like to a set of trascripts or nucleotide sequences. This is what is already demonstrated in the other thread here.

On the other hand, you could do this projecting it back to the set of possible nucleotide sequences, and leaving it at that. This is one thing that Brendan and I were noodling on before connect. Below you can see a mock-up of that sort of implementation for BRAf V600E, where the two right-most "level variants" each defining the set of sequence variants the correspond to one of the codons for glutamic acid.

A simpler way to do this perhaps would be to allow the alt to be an array:

alt:
	oneOf:
		- CTC
		- CTT
Length:
	[1, 3]

Though in all honesty, this level of fine-grained representation probably belongs with the implementor, not the schema.

[rhdolin]

Thanks @DanielPuthawala. In practice, what I've been doing is running a VCF through an annotation engine (e.g. snpEff), and then querying for variants that have an annotation of, say, BRAF V600E. Is it possible or desirable that Cat-VRS be able to express constraints based on a variant's annotations or predicted molecular consequences?

[DanielPuthawala]

Hi @rhdolin, That's sort of a sticky point, right, because on the one hand, representing variant annotation is, well that's VA's job, not ours, so it's out of scope. But on the other hand, annotation-like labels often get used in categorical variation labels, so I think we want to be able to handle that, just not for the same use cases that VA-spec is working on. So yes?