Error in CNVtranslator notebook example

[mbaudis]

The CNVtranslator notebook no. 6 uses an EFO class (CURIE) as input. However, the current translator fails (requires the string label value).

cnc = cnv_translator.translate_from("NC_000014.9:g.45002867_45015056del", "hgvs", copy_change="EFO:0030067")

...
pydantic_core._pydantic_core.ValidationError: 1 validation error for CopyNumberChange
copyChange
  Input should be 'complete genomic loss', 'high-level loss', 'low-level loss', 'loss', 'regional base ploidy', 'gain', 'low-level gain' or 'high-level gain' [type=enum, input_value='EFO:0030067', input_type=str]
    For further information visit https://errors.pydantic.dev/2.11/v/enum

This works:

cnc = cnv_translator.translate_from("NC_000014.9:g.45002867_45015056del", "hgvs", cop\
y_change="loss")

This is probably due to a change in the enum values from the well formed curies to malformed string labels. This is a nice example why this shouldn't be done: EFO:0030067 is variously labeled as "loss" (as used in VRS v2) or (authoritative) "copy number loss"¹.

Recommendation: Use (or at least allow) the CURIEs. And/or use the exact labels from the ontology definition.

Footnotes

1. I am myself not consistent in the use since it is a label. ↩

[korikuzma]

@mbaudis Thanks for this! I always forget to re-run notebooks. 🤦‍♀️

[korikuzma]

@mbaudis See PR #576 (also fixes another notebook)

[mbaudis]

@korikuzma Thanks - that fixes it on the notebook level though the inconsistencies between EFO and VRS labels (and the general problem with non-normative string identifiers) remain.

[korikuzma]

@mbaudis Let me know if https://vrs.ga4gh.org/en/stable/appendices/design_decisions.html#use-of-value-sets-for-vrs-computed-digests helps! If not, I recommend creating a discussion in the VRS repo

[mbaudis]

@korikuzma I understand it, but the implementation shows the general problem; i.e. the argument of

are maintained internally such that changes to these concepts in EFO will not affect their use in VRS (and therefore not affect the computed digests of CopyNumberChange objects)

is a cannon to the specification's foot (if I may). If it is being done like that (i.e. maintained internally) you have to abandon references to the original apart from non-normative ones "like e.g. in EFO..." ... which you have then to track (if you think concepts might change).

So:

• if using internal representation of externally derived concepts - make this obvious: gain is not the same as copy number gain - it doesn't match (though, in spirit)
• do not, ever, use non codified text labels, ENUMs etc.; if you think you need to be independent of other vocabularies develop a hierarchical code (ga4gh:vrs.vt_0030067 etc.) with pattern match ... for your concepts to make them mappable (loss is not something to be taken seriously). But then: We need more ontologies, right?

This is something for @ahwagner & @larrybabb, too, I guess; not specific only to this issue ╮(╯▽╰)╭. But maybe someone will pick it up ...