<blockquote>
<p>Thoughts on the described method from Bristol?</p>
</blockquote>
<p>I don't immediately see the benefit to this over rsIDs.</p>
<blockquote>
<p>What might be the maximum length for an indel we could encounter?</p>
</blockquote>
<p>Potentially very long. However, why does it matter? This will be rare.</p>
<blockquote>
<p>Is there a broader effort underway to address this concern?</p>
</blockquote>
<p>dbSNP comes to mind.</p>
<blockquote>
<p>Would adopting the Bristol approach set a potential standard, or
should we explore or develop alternative methods? For example should
the genome build be built into the id? or species?</p>
</blockquote>
<p>It depends on the type of analysis you're planning on doing. Are you doing cross-species analyses? And if so, what types? Do you expect to be comparing genomes with different genome builds?</p>
<blockquote>
<p>For example GWAS summary statistics. I want to be able to match
variants from different studies so I want to have an identifier for
the variants.</p>
</blockquote>
<p>Both chr:pos as well as rsID work for this, but just make sure that the genome build matches if you go with chr:pos.</p>
<blockquote>
<p>I could use rs numbers I could use chr:pos I could use chr:pos:ref:alt
I could use chr:pos:effect:noneffect I could use
chr:pos:population:effect:noneffect or
studyid:chr:pos:populatoin:effect:noneffect or etc</p>
</blockquote>
<p>If you're sure your input data has rs numbers and always will, that might be easiest. However, you may find that sometimes it doesn't have rs numbers (e.g. some Affymetrix data), and it's surpassingly annoying to add them. I'd choose chr:pos, personally, and then consider the effect/non-effect/ref/alt/ on a per-analysis basis, because I would want to still identify the same position if there was a different ref/alt for example.</p>
<p>Edit:
Based on the comment (OP wants to match effect direction), I would suggest chr:pos:effect_allele, but of course this means there is an effect allele (i.e. the position has been studied).</p>

CC BY-SA 4.0
2023-10-29T17:05:34.810Z
The vast majority of variants (remember that variants are effectively  infinite since you can have any length of indel at any position) won't have rsIDs. Novel variants won't, by definition. So if the OP needs to work with arbitrary variants, rsIDs won't help. If not, rsIDs are indeed the best approach.
terdon
CC BY-SA 4.0
2023-10-29T17:12:19.650Z
@terdon Yes. I think chr:pos would be ideal/most simple, and OP would just have to be careful regarding builds
BigMistake
CC BY-SA 4.0
2023-10-30T09:46:21.100Z
Thanks for the response and your thoughts. 
I guess the thing is in the context of merging GWAS results for coloc and mr etc, chr:pos does not seem sufficeint. I can make sure everything in on the same build, but how do I know if an effect of a snp on say bmi in a japanese study can be matched to a  study which finds an effect at the same position in a european study. I need to take into account ref/alt to effect non effect , direction..
user27815
CC BY-SA 4.0
2023-10-30T14:27:56.920Z
@user27815 I see. I would try chr:pos:effect_allele in that case. Would that work?
BigMistake
CC BY-SA 4.0
2023-10-30T14:47:41.117Z
gnomAD uses chr-pos-ref-alt, not as an official ID but as a unique way to access web pages detailing each variant. That might be worth looking into. Example: https://gnomad.broadinstitute.org/variant/1-55051215-G-GA?dataset=gnomad_r3
Ram RS
CC BY-SA 4.0
2023-10-30T15:12:00.827Z
chr-pos-ref-alt is a good way to match variants, but may become problematic (without further tinkering) if the same variant has opposite effect sizes in different studies
BigMistake
CC BY-SA 4.0
2023-10-31T14:45:22.680Z
yes, which is why I think some times chr:pos:effect:noneffect is often used, then that clears that up. But you still have the issue of population if the effect is differnt in differnt pops..
user27815
CC BY-SA 4.0
2023-10-29T16:30:36.953Z
2023-10-30T14:28:49.170Z
2023-10-30T14:28:49.170Z
BigMistake
<p>I'm currently pondering on the best approach to handle and standardize variant IDs within our department to mitigate the challenges associated with rsids and the potential ambiguity of just using chromosomal positions.</p>
<p>The GWAS glue (<a href="https://mrcieu.github.io/gwasglue2/articles/Strategy.html" rel="nofollow noreferrer">https://mrcieu.github.io/gwasglue2/articles/Strategy.html</a>) packagae, state oa method where a variant ID is crafted by integrating the chromosomal position (chr), effect allele (ea), and non-effect allele (nea). It assumes the format: chr:pos_ea_nea. For alleles that exceed 10 characters, like certain indels, they apply the murmur32 hashing algorithm from the R digest package.</p>
<p>Given our objectives:</p>
<p>We likely prefer not to have excessively lengthy IDs.
Yet, using hashed IDs for certain long variants might be perplexing for some who aren't informed about the approach.
Hashing every ID could yield consistency, but perhaps might not be as intuitive for regular use.
I'm keen on collecting insights:</p>
<p>Thoughts on the described method from Bristol?
What might be the maximum length for an indel we could encounter?
Is there a broader effort underway to address this concern?
Would adopting the Bristol approach set a potential standard, or should we explore or develop alternative methods? For example should the genome build be built into the id? or species?
I appreciate the community's feedback as we strive for clarity and efficiency in our variant naming conventions.</p>
<p>For clarity:
I want to store data on variants. For example GWAS summary statistics.
I want to be able to match variants from differnt studies so I want to have an identifier for the variants.
I could use rs numbers
I could use chr:pos
I could use chr:pos:ref:alt
I could use chr:pos:effect:noneffect
I could use chr:pos:population:effect:noneffect
or studyid:chr:pos:populatoin:effect:noneffect
or etc</p>
<p>There are pros and cons for each of these but I would like to here what people on here think these are.
I am also intrested in is there work out there to do this already. e.g. to update the idea of rsids to consider multiple alleles and effects in populations?</p>

CC BY-SA 4.0
2023-10-04T11:37:48.843Z
Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
Community
CC BY-SA 4.0
2023-10-04T12:45:03.623Z
I have tried to clarify
user27815
CC BY-SA 4.0
2023-10-29T16:23:04.933Z
I would not hash. Variant IDs should be static across builds, similarly to how rsIDs are handled between b37 and b38. I do not think hashing is worth it because there's not that much downside for a long ID
BigMistake
CC BY-SA 4.0
2023-10-29T17:08:14.713Z
You need this to work on multiple species, right? And across different reference genome builds? Are you only interested 8n species with a sequenced genome or do you also need to handle variants defined with respect to a specific transcript or protein only, in the absence of a reference genome?
terdon
CC BY-SA 4.0
2023-10-29T18:18:21.957Z
Also, are you open to paid tools? The company I work for has an API that will, among other things, provide unique ids for arbitrary (human) variants. If you are open to non-free tools check out https://landing.varsome.com/varsome-api.
terdon
CC BY-SA 4.0
2023-10-31T14:46:06.930Z
Thanks ill check that out.
user27815
<identifiers><variants>
Standardizing Variant IDs best practise
# Standardizing Variant IDs best practise

(Asked by: username_0 on 2023-10-04)

I'm currently pondering on the best approach to handle and standardize variant IDs within our department to mitigate the challenges associated with rsids and the potential ambiguity of just using chromosomal positions.

The GWAS glue (<https://mrcieu.github.io/gwasglue2/articles/Strategy.html>) packagae, state oa method where a variant ID is crafted by integrating the chromosomal position (chr), effect allele (ea), and non-effect allele (nea). It assumes the format: chr:pos\_ea\_nea. For alleles that exceed 10 characters, like certain indels, they apply the murmur32 hashing algorithm from the R digest package.

Given our objectives:

We likely prefer not to have excessively lengthy IDs.
Yet, using hashed IDs for certain long variants might be perplexing for some who aren't informed about the approach.
Hashing every ID could yield consistency, but perhaps might not be as intuitive for regular use.
I'm keen on collecting insights:

Thoughts on the described method from Bristol?
What might be the maximum length for an indel we could encounter?
Is there a broader effort underway to address this concern?
Would adopting the Bristol approach set a potential standard, or should we explore or develop alternative methods? For example should the genome build be built into the id? or species?
I appreciate the community's feedback as we strive for clarity and efficiency in our variant naming conventions.

For clarity:
I want to store data on variants. For example GWAS summary statistics.
I want to be able to match variants from differnt studies so I want to have an identifier for the variants.
I could use rs numbers
I could use chr:pos
I could use chr:pos:ref:alt
I could use chr:pos:effect:noneffect
I could use chr:pos:population:effect:noneffect
or studyid:chr:pos:populatoin:effect:noneffect
or etc

There are pros and cons for each of these but I would like to here what people on here think these are.
I am also intrested in is there work out there to do this already. e.g. to update the idea of rsids to consider multiple alleles and effects in populations?

**Tags:** identifiers, variants
> **Comments:**
> **username_1**: Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.  
> **username_0**: I have tried to clarify  
> **username_2**: I would not hash. Variant IDs should be static across builds, similarly to how rsIDs are handled between b37 and b38. I do not think hashing is worth it because there's not that much downside for a long ID  
> **username_3**: You need this to work on multiple species, right? And across different reference genome builds? Are you only interested 8n species with a sequenced genome or do you also need to handle variants defined with respect to a specific transcript or protein only, in the absence of a reference genome?  
> **username_3**: Also, are you open to paid tools? The company I work for has an API that will, among other things, provide unique ids for arbitrary (human) variants. If you are open to non-free tools check out https://landing.varsome.com/varsome-api.  
> **username_0**: Thanks ill check that out.  

---

## 1 answers

### Answer by username_2 on 2023-10-29. Score: 1

> Thoughts on the described method from Bristol?

I don't immediately see the benefit to this over rsIDs.

> What might be the maximum length for an indel we could encounter?

Potentially very long. However, why does it matter? This will be rare.

> Is there a broader effort underway to address this concern?

dbSNP comes to mind.

> Would adopting the Bristol approach set a potential standard, or
> should we explore or develop alternative methods? For example should
> the genome build be built into the id? or species?

It depends on the type of analysis you're planning on doing. Are you doing cross-species analyses? And if so, what types? Do you expect to be comparing genomes with different genome builds?

> For example GWAS summary statistics. I want to be able to match
> variants from different studies so I want to have an identifier for
> the variants.

Both chr:pos as well as rsID work for this, but just make sure that the genome build matches if you go with chr:pos.

> I could use rs numbers I could use chr:pos I could use chr:pos:ref:alt
> I could use chr:pos:effect:noneffect I could use
> chr:pos:population:effect:noneffect or
> studyid:chr:pos:populatoin:effect:noneffect or etc

If you're sure your input data has rs numbers and always will, that might be easiest. However, you may find that sometimes it doesn't have rs numbers (e.g. some Affymetrix data), and it's surpassingly annoying to add them. I'd choose chr:pos, personally, and then consider the effect/non-effect/ref/alt/ on a per-analysis basis, because I would want to still identify the same position if there was a different ref/alt for example.

Edit:
Based on the comment (OP wants to match effect direction), I would suggest chr:pos:effect\_allele, but of course this means there is an effect allele (i.e. the position has been studied).

> **Comments:**
> **username_3**: The vast majority of variants (remember that variants are effectively  infinite since you can have any length of indel at any position) won't have rsIDs. Novel variants won't, by definition. So if the OP needs to work with arbitrary variants, rsIDs won't help. If not, rsIDs are indeed the best approach.  
> **username_2**: @terdon Yes. I think chr:pos would be ideal/most simple, and OP would just have to be careful regarding builds  
> **username_0**: Thanks for the response and your thoughts.  I guess the thing is in the context of merging GWAS results for coloc and mr etc, chr:pos does not seem sufficeint. I can make sure everything in on the same build, but how do I know if an effect of a snp on say bmi in a japanese study can be matched to a  study which finds an effect at the same position in a european study. I need to take into account ref/alt to effect non effect , direction..  
> **username_2**: @user27815 I see. I would try chr:pos:effect_allele in that case. Would that work?  
> **username_4**: gnomAD uses chr-pos-ref-alt, not as an official ID but as a unique way to access web pages detailing each variant. That might be worth looking into. Example: https://gnomad.broadinstitute.org/variant/1-55051215-G-GA?dataset=gnomad_r3  
> **username_2**: chr-pos-ref-alt is a good way to match variants, but may become problematic (without further tinkering) if the same variant has opposite effect sizes in different studies  
> **username_0**: yes, which is why I think some times chr:pos:effect:noneffect is often used, then that clears that up. But you still have the issue of population if the effect is differnt in differnt pops..  

---

