You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've verbally discussed this in the past and I want to say that @ahwagner was the one that ideated it (apologies if it was someone else).
Anyway, the idea here is to build something into the spec and vrs-python that allows for the creation of previous digest ids on all future VRS objects. This would provide a bunch of benefits (we presume). I'm not sure what the final design should be but the spirit of this is that we would add an attribute to all identifiable objects (Alele, SequenceLocation, etc...) and if the current version of that class has the ability to also generate the same exact object in a prior version's schema (say 1.3, 1.0) then it would either automatically do this and provide just the digests for these past versions in the response.
With this type of feature we would be able to link the current VRS 2.x Alleles to datasets that have 1.3 digests already built in (e.g. gnomad v4 is using VRS 1.3 right now). The hope is that datasets that implement VRS would not suddenly be cut out by someone promoting their system from one major version of VRS to the next. However, this would only work if methods can be determined to map future version contstructs to prior version constructs without altering the intended identity of the value object. With the Allele model going from 1.0 to 1.3 to 2.0 the digest was impacted but the values captured in all three schemas are sufficently translatable to be able to get a digest for each that is an exact mapping of the variant. It is yet to be seen if this will translate to other objects as we expand the breadth of identifiable objects in VRS.
I would like to discuss whether this idea is worthwhile and if it is important enough to be required by the VRS 2.x specification itself. Or maybe it's just a nice feature added to VRS-Python and we suggest to folks that they support it?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We've verbally discussed this in the past and I want to say that @ahwagner was the one that ideated it (apologies if it was someone else).
Anyway, the idea here is to build something into the spec and vrs-python that allows for the creation of previous digest ids on all future VRS objects. This would provide a bunch of benefits (we presume). I'm not sure what the final design should be but the spirit of this is that we would add an attribute to all
identifiable
objects (Alele, SequenceLocation, etc...) and if the current version of that class has the ability to also generate the same exact object in a prior version's schema (say 1.3, 1.0) then it would either automatically do this and provide just the digests for these past versions in the response.With this type of feature we would be able to link the current VRS 2.x Alleles to datasets that have 1.3 digests already built in (e.g. gnomad v4 is using VRS 1.3 right now). The hope is that datasets that implement VRS would not suddenly be cut out by someone promoting their system from one major version of VRS to the next. However, this would only work if methods can be determined to map future version contstructs to prior version constructs without altering the intended identity of the value object. With the Allele model going from 1.0 to 1.3 to 2.0 the digest was impacted but the values captured in all three schemas are sufficently translatable to be able to get a digest for each that is an exact mapping of the variant. It is yet to be seen if this will translate to other objects as we expand the breadth of identifiable objects in VRS.
I would like to discuss whether this idea is worthwhile and if it is important enough to be required by the VRS 2.x specification itself. Or maybe it's just a nice feature added to VRS-Python and we suggest to folks that they support it?
Beta Was this translation helpful? Give feedback.
All reactions