Currently, variant page URLs specify only chromosome and position, eg:
https://fivex.pheweb.org/variant/eqtl/1_109274968...
As we add more datasets, multiallelic variants become increasingly likely. Eg, even if we modified the search box to support fictitious variant queries like chr1:109274968_A/C, the information that was automatically filled in would force the user to a different variant (1:109,274,968_G/T). It would literally not be possible to request certain multiallelics at all, and the logic for which option is chosen is not obvious.
Additionally, this could reflect rsIDs, which are known to be ambiguous in this situation. The user would not have a clear way to disambiguate their request. At present, the portaldev api uses a pretty old list of rsIDs, but if we ever upgraded the data behind the api to the newest set (with more multiallelics), searches could become more ambiguous in the future.
Currently, variant page URLs specify only chromosome and position, eg:
https://fivex.pheweb.org/variant/eqtl/1_109274968...As we add more datasets, multiallelic variants become increasingly likely. Eg, even if we modified the search box to support fictitious variant queries like
chr1:109274968_A/C, the information that was automatically filled in would force the user to a different variant (1:109,274,968_G/T). It would literally not be possible to request certain multiallelics at all, and the logic for which option is chosen is not obvious.Additionally, this could reflect rsIDs, which are known to be ambiguous in this situation. The user would not have a clear way to disambiguate their request. At present, the portaldev api uses a pretty old list of rsIDs, but if we ever upgraded the data behind the api to the newest set (with more multiallelics), searches could become more ambiguous in the future.