How to represent VRS Variation without a refgetAccession?

[larrybabb]

Should I be able to create a sequenceLocation that is based on a reference sequence that does not have a refgetAccession?
I thought we originally decided that folks should not be required to use computed identifiers, even though it is strongly recommended.
Did we change that and make VRS formally dependent on the use of computed identifiers?

So for now, if my biocommons.seqrepo service does not have certain accessions in it (i.e. ensembl sequences) and I come across an hgvs or vcf record that is based on an ensembl sequence, I cannot represent this as a VRS allele, cnv, etc..., which feels incorrect.
The refgetAccession is required on sequenceReference.
Do I just stick some other value in there like the ensembl accession id?

This is sort of important to resolve (asap) because I'm trying to determine whether to always fall back to a categorical DescribedVariation in these situations, even though they seem like they should be representable as CanonicalAlleles with actual vrs Alleles as the defininingContext and associated members.

I'm good with taking the really obscure non-computational variants in clinvar and representing them as DescribedVariation but there's a number of these that fall into no-variants land which are really not DescribedVariation but not yet implementable as true vrs contextual Variation.

Suggestion...
Maybe we should loosen the requirement on certain vrs attributes (like on SequenceReference.refgetAccession) so that we can represent things that are still unable to be converted into true normalized vrs computed identifiers.

[larrybabb]

From @ahwagner on 3/14/2024 (via ga4gh slack thread)...

Agreed