How to populate the relations property within DefiningAlleleConstraint and DefiningLocationConstraint

[brendanreardon]

The recipes for and CanonicalAllele and ProteinSequenceConsequence currently require the relations property to contain primaryCodes of liftover_to, transcribes_to, or translates_from. Examples in this repository (canonicalAllele and proteinSequenceConsequence) do not expand upon what this representation should look like.

@brendanreardon asked the following on Slack to @korikuzma, @DanielPuthawala, and @larrybabb on 2025-02-19 (paraphrased):

relations is a mappableConcept and primaryCode is supposed to be a code that points to a coding under mappings. Shouldn't the relations be a list of mappable concepts? In this example of the DefiningAlleleConstraint representing an hgvs.p of EGFR p.L858R, shouldn't the relations be mappable concepts to VRS Alleles for the relevant hgvs.c or hgvs.g representations? I'm left thinking "translates from what?"

relations:
   - primaryCode: translates_from

@larrybabb wrote back with the following, referencing this Issue from the va-spec repository with regard to changes to Mappable Concept and Coding models:

The whole MappableConcept class has not been updated to reflect the changes that Matt/Alex/I discussed and Matt B reviewed at the last VA meeting. That said, this is an area that is challenging on several levels. If we craft our own "codes" or "enumerations" for things then we need a method for how we disseminate and maintain those codes. Ideally, they would be really well vetted by the implementers and the community, but that creates a cart and horse dilemma. So, we may go the route of saying "just use the terms we provide in the name attribute of the MappableConcept and do not bother with any other codes or mappings. It's just that simple and straightforward until such time as we can all agree on where/how to register these codes.

we could consider using FHIRs terminology service (if that is available to terms that are not formally used within the FHIR domain)? They have built a very sophisticated service for registering value sets like this that are needed throughout FHIR. This would be too big for GA4GH to take on IMO. So we need to think very "simply" for now (which I recognize gets push back and makes the adopters a bit uncomfortable since there's no solid plan going forward).