VRS Recipes

[ahwagner]

For VRS 2.x, we want to demonstrate how VRS can be used to represent variant concepts in common applications (recipes). These recipes can include things like a:

• CNV array result
• a genotype at a locus
• an HGVS expression

[jsstevenson]

We have a distant interest in ingesting data from pharmacogenomic knowledge sources, in which variants are represented largely using the star allele system. It'd be great to establish a demo for this kind of application.

[ahwagner]

I really like this idea.

[afrubin]

I also really like this idea. We have MAVE data for several pharmacogenes in MaveDB already, and I don't want to have to deal with star alleles in order to connect those with relevant knowledge.

In particular, we have CYP2C9, which I think has already been VRS-mapped, and CYP2C19, which has not yet.

Maybe connecting one of these datasets with star alleles using VRS would be a relevant demo with a more tangible outcome?

[rrfreimuth]

I am very interested in this as well. The star allele nomenclature system suffers from several critical limitations, but the one that is probably most impactful to use with VRS is ambiguity in the definition of the alleles themselves. This could be addressed by creating fully defined (unambiguous) allele definitions. I believe PharmVar was working on this but am not sure how much has been done or whether the definitions would be precise enough for VRS.

[larrybabb]

I think this is combo VRS and Cat-VRS concern. Assuming we deploy something like CPBs for a contextual representation of a star allele on a given genome build, we would then need the Categorical representation of it to represent the actual star allele since they are not genome build specific.

It also raises the hairy parts of figuring out what is the proper definition of a star allele. Is it some subset of the mappings or is it some critical set of the mapped alleles? Maybe we have separate classes of star alleles, those that are used in common genetic testing practice and those that are super comprehensive. Of course they both would have to be versioned since they can change as new mapped variants are added to some of the start allele genes. Fun stuff.

[mbaudis]

@ahwagner Another one: Translation of variants from karyotyping (or FISH etc.), e.g. fusion events with fuzzy (megabase, cytoband) resolution. Not clear to me - how do you represent an imprecise result?

Current minimal way I see it - this is early Beacon prototyping, comments appreciated & maybe editing this will then become an example for a minimal chromosome level fusion event representation by position?¹:

t(14;18)(q32;q21) (IGH/BCL2²)

{
  "variantInternalId": "14:89300000-107043718::18:45900000-63900000:SO_0000806",
  "variation": {
    "type": "Adjacency",
    "id": "pgxvar-66b36f3f6425bd906071dd94",
    "adjoinedSequences": [
      {
        "type": "SequenceLocation",
        "sequence_id": "refseq:NC_000014.9",
        "interval": {
          "end": [89300000, 107043718]
        }
      },
      {
        "type": "SequenceLocation",
        "sequence_id": "refseq:NC_000018.10",
        "interval": {
          "start": [45900000, 63900000]
        }
      }
    ]
  }
}

Footnotes

1. Not discussing annotation of technical provenance, potential round-trip problems between sequence coordinates and cytobands here etc. Also pinging @larrybabb ↩

2. The IGH/BCL2 is inferred therefore no more specific coordinates should be used - this would be different for named events. ↩

[larrybabb]

@ahwagner I'm curious to hear your response. I believe you will be channeling this to the re-introduction of the vrs v1.3 ChromosomeLocation with its reference to CytobandIntervals (see here).

@mbaudis if you want to use sequence positions instead of cytoband positions then I think you are on the right track using the Range data type for the end and start position of the adjoining sequences. I will defer to @ahwagner to confirm but I do think you will need to add in the chr14 and chr18 Terminus entries before and after you Adjacency, respectively. Also, there's a new TraversalBlock structure that sits between the DerivativeMolecule and the various components that make up the sequence in an ordered array (which in all fairness where just reveleased today Aug.12.2024. see here ).

[ahwagner]

@mbaudis yes, this is one way of representing an adjacency at the designated breakpoints. If you wanted to explicitly reconstitute one complete derivative molecule (right now only the adjacency is explicit, not how far it extends), you would also want to add in the terminus entities @larrybabb mentioned. As you know (but stating for others reading this) ISCN also encodes the "reciprocal translocation" using the t, and we don't have an analogous concept in VRS. This is an area that needs further discussion, and likely one or more new systemic variation class(es) that allows us to represent multiple derivative molecules in a system.

@mbaudis, for pgx, what would the ideal look like for representing cytogenomic data? FISH data? Would it be sequence coordinates, or something that represents those specific features (e.g. the ChromosomeLocation objects from VRS 1.x)? Would this be different for Beacon than for pgx?

[mbaudis]

@larrybabb This was about the representation of the "atomic event" of a fusion, determined by a low non-sequencing technique, avoiding the discussions of complete reconstruction etc.

@ahwagner Exactly the important points coming up, too (I avoided the t implication here as well as the complete reconstruction referred to by @larrybabb , too). Let's do additional examples for those, as well as for cytobands, if those will be/remain supported ...

Now, after the feedback that I'm on the right track here comes a challenge: How to handle adjacencies w/o known directionality, i.e. from karyotyping where one approximates the translocated material but doesn't know the direction of fusion? Can happen.

This leads me to a general problem I have w/ the implicit directionality coming from use of either start or end. I would rather prefer a use of always start, end (Number) with explicit directionality ... Comments on this?

[mbaudis]

@mbaudis, for pgx, what would the ideal look like for representing cytogenomic data? FISH data? Would it be sequence coordinates, or something that represents those specific features (e.g. the ChromosomeLocation objects from VRS 1.x)? Would this be different for Beacon than for pgx?

For cytogenomic data you somehow have to preserve provenance which can be done in several ways (considering full stack / round trip problems); and no complete solution can/should be provided in the variant encoding itself (IMO always needs reference to analysis description). Generally:

• when using something like ChromosomeLocation, you
  • PRO keep provenance (regarding resolution) and mapping (genome edition independent)
  • NEUTRAL do not benefit from encoded directionality or genomic context from the annotation itself compared to SequenceLocation (AFAIK) since you have to "atomize" the events in either case
  • CONTRA regarding database and query, one needs to run an additional OR option (cytogenetic OR genomic coordinates) or have an internal shadow representation in sequence coordinates (and ATM Beacon doesn't allow this - we're prototyping in Progenetix/bycon, though)
  • CONTRA (Beacon specific) preferably would have position by cytoband query through dedicated parameters
• when coding cytogenomic events to SequenceLocation, you
  • PRO work in a unified representation of variant coordinates, making (backend) implementations much easier
  • CONTRA need provenance tracking which keeps the original cytoband ... style, for roundtrip or "GRCh39"

My personal preference would be to use SequenceLocation but keep ChromosomeLocation as an option for representing variants.

In bycon we have already some implementations of cytoband mapping, query by band location (8q22q24.1 etc.); and also multi variant queries. I already tested fusion queries both through encoding both sides separately (with multi variant matches) or now as Adjacency encoded variants (which I prefer).

[mbaudis]

Here is the live version how a t(14;18)(q32;q21) is currently encoded in a Beacon response progenetix.org/beacon/biosamples/pgxbs-kftvgifa/g_variants. This is obv. not compatible to the current Beacon variant format (which only supports VRS 1.2). New: Encoding both fusions of the translocation as independent variants - does this make sense @ahwagner ?

[jsstevenson]

I don't have a fully-formed or fleshed-out use case for this, but: a demonstration of dereferencing an rsID and translating the result to a VRS object might be beneficial. I think the variations in question are fairly trivial to manage but it might be good for us to present an opinionated pipeline for translating them.

[larrybabb]

I like this and also think it's a big need to be able to dereference any id-system that relates to a variant or categorical variant back to it's corresponding vrs or cat-vrs form. I'm not sure if what you are suggesting is more of a "method for quickly creating all of the contextual variants for a given rsID into vrs 2.0 objects" or "having a 'kind-of' variant store that allows lookup by different id-systems A la Clingen Allele Registry or dbSNP themselves"?

Just some related background in case folks aren't aware. NCBI added VRS 1.0 generation to their Variation Services, and they have a dedicated API endpoint for lookup by rsID here. If you try out the example and scroll down to the last node in the response under the attribute ga4gh you will see ALL the VRS 1.0 representations of this rsID for build 37 and 38 and the corresponding transcripts and even the protein alleles. dbSNP include(s|d) the ga4gh vrs 1.x ids in their dbsnp file downloads too. The did and I think they still do. We do need to show them how the community is willing able and ready to adopt vrs 2.x more broadly and I think we can get them to upgrade this stuff.

[larrybabb]

If we expand this to other identifier systems for variation then I suggest we consider how a tool like AnyVar could be used as a service/tool in a system to quickly spin up a variant store and load with data for dereferencing datasets like dbsnp (or any other service). Eventually AnyVar could be used as a VLM (Variant Level Matching) node in a federated system to help provide a means for dereferencing variant data and ids in very large distributed variant store systems. (Love that AnyVar potential)

[jsstevenson]

NCBI added VRS 1.0 generation to their Variation Services

I... did not know this! I think this covers what I was originally asking about (obviously would prefer 2.0, although it's not too hard to move back and forth when working with simple alleles), which originally came up many years ago in the context of adding some service (maybe PharmGKB) to our MetaKB project. Maybe an upshot of this could be to maintain a central listing of where and how your favorite genomics resources have incorporated VRS/GKS?