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
The alleleOriginQualifier attributes on many Statement profiles are currently constrained to an enum (one of germline, somatic, or combined). This would seem to limit broader use by data creators wanting to use a broader set of terms here. Or is the thinking to start with a small enum and expand as new users request them, evaluating the utility of allowing for Codings / implementation-defined value sets in the future.
In previous work, we had recommended use of GENO allele origin ontology terms in Codings for this attribute. My understanding was that enums were used only when there is a strong reason for the spec/standard to tightly control the set of allowable values. And we would use Codings when we want to allow implementations to select their own terms (but we would provide strong recommendations here to facilitate interoperability).
FWIW linkML enums will provide a single solution for this issue - when we move over to that framework.
The text was updated successfully, but these errors were encountered:
Related: allelePrevalenceQUalifier also uses an enum (one of rare, common) - which may be fine. But we should define the terms in the enum here - so they are applied consistently, and so users understand what these mean.
The
alleleOriginQualifier
attributes on many Statement profiles are currently constrained to an enum (one ofgermline
,somatic
, orcombined
). This would seem to limit broader use by data creators wanting to use a broader set of terms here. Or is the thinking to start with a small enum and expand as new users request them, evaluating the utility of allowing for Codings / implementation-defined value sets in the future.In previous work, we had recommended use of GENO allele origin ontology terms in Codings for this attribute. My understanding was that enums were used only when there is a strong reason for the spec/standard to tightly control the set of allowable values. And we would use Codings when we want to allow implementations to select their own terms (but we would provide strong recommendations here to facilitate interoperability).
FWIW linkML enums will provide a single solution for this issue - when we move over to that framework.
The text was updated successfully, but these errors were encountered: