Add pathogenicity predictions and allele to frequency

[costero-e]

This is the work that @dglemos has been working on and already deployed in the genomicVariations feature branch. This is ready to be merged into the develop branch IMO as the work seems finished.
Can you please review, @mbaudis and @redmitry ?

[redmitry]

Since it was merged, I have updated my java model... a month ago.

https://gitlab.bsc.es/inb/ga4gh/beacon-v2-api/-/blob/master/beacon-data-model/src/main/java/es/bsc/inb/ga4gh/beacon/model/v200/variations/PopulationFrequency.java#L41
https://gitlab.bsc.es/inb/ga4gh/beacon-v2-api/-/blob/master/beacon-data-model/src/main/java/es/bsc/inb/ga4gh/beacon/model/v200/variations/VariantLevelData.java#L43

D.

[jrambla]

I have some questions about the suggested changes. I know the PR has been waiting for some months.

1. Why do we need to add the allele if, actually, the section is inside a given genomicVariation?
2. The pathogenicityPrediction should be linked to an specific phenotypic effect, is not generic to any condition.
3. The "phred_score:0.381" example doesn't seem compliant with the ontologyTerm, is it?

[costero-e]

@dglemos Can you check @jrambla questions?

[dglemos]

Hi @jrambla,

For the following query: assemblyId=GRCh38;referenceName=9;start=22125503;referenceBases=G;alternateBases=C
The Ensembl Beacon returns a match: rs1333049 -> this variant has two alt alleles A and C. As some of our data is not attached to a specific allele (only attached to ID rs1333049) our beacon returns both alleles in the response.
This is how the alleles are returned in the response:

"variation": {
              "referenceBases": "G",
              "alternateBases": "A,C",
              "variantType": "SNP",
              "location": {
                "interval": {
                  "type": "SequenceInterval",
                  "end": {
                    "value": 22125504,
                    "type": "Number"
                  },
                  "start": {
                    "type": "Number",
                    "value": 22125503
                  }
                },
                "type": "SequenceLocation",
                "sequence_id": "9"
              }
            }

1. We prefer to attach the specific alt allele associated with the frequency in the response. This way we make sure the user knows which one has the frequency.
2. The same applies here. We don't have pathogenic predictions directly linked to phenotypic effects.
3. I'll review this one.

[jrambla]

@mbaudis I'm not convinced that the approach here matches the overall genomicVariations approach and I fear the we could be creating confusion. Opinions?

[mbaudis]

@jordi @dglemos The root cause here is the treatment of variants with the strange VCF concept where you are able to capture haplotypes for observations but each VCFvar (i.e. line) can express multiple alternative possibilities (0|1|2... alleles changed etc.). Therefore when storing/expressing variants as VCF lines you always will have ambiguous responses (the 0 wouldn't match, the 1 or 2 alleles would and the might be different). So reporting back becomes an issue - in the current Beacon way the caseLevelData would be ambiguous:

Do we report all the samples which have a match on the request but where the observation might differ as one or as different variants depending on their allelic composition (i.e. here separate C,C, A,C variants and their samples)? The latter option makes sense but compared to VCF represents a kind of de-composition. And we do not have this defined. And makes sense comes with a big caveat: Are we talking about haplotypes (we shouldn't) or alleles?

My take:

• Beacon queries are for alleles so any variant (allele or haplotype etc.) matching the query should be returned.
• The Beacon legacy variation does not allow for the representation of haplotypes, so in this case all matches would look the same.
• We have to work on a new variant schema (I'd started a draft... which basically should be lifted from current VRS v2.n.
• We have to revise the confusing mix of variants and calls and e.g. get rid of the caseLevelData embedding in favour of reporting individual observations (no ambiguities there) and referencing common identifiers etc. (and @redmitry has made some technical points why this is necessary, beyond the logic of a hierarchical model currently being broken).