Add subType or something to computationally indicate type of variant

[larrybabb]

As we are dealing with getting VA-spec to Trial Use 1.0.0 we are finding that we need some of the basic CategoricalVariant classes to be in Trial Use as well. We also have hit the following point of discussion which needs to be hashed out with the Cat-VRS folks.

In the va-spec/tests/fixtures (1.x branch) folder there are several test yaml files for various va-spec statement, evidenceline and studyresult types. The AVE-clinical-classification.yaml in particular has the following comment in it at this time

type: EvidenceLine
targetProposition:
  type: VariantPathogenicityProposition
  subjectVariant:
    # LB: Alex, please verify the following... I am using a Cat-VRS: ProteinSequenceConsequence
    #     I want to review this because there's nothing in this object to tell you that
    #     It looks identical to the CanonicalAllele except for the data constraints on
    #     which relations are allowed. 
    #     I think it makes sense for some Recipes to have a more specific object type or subtype property
    #     maybe something like recipeType: ProteinSequenceConsequence? (recipe is a bit non-computational computationally speaking)
    #       categoryType or categorySubtype seems better - the focus is on the category portion of CategoricalVariant.
    #     
    #     I recognize that computational validation will work fine without this
    #     but I would imagine it may make debugging validation failures much easier
    #     if the categoryType or recipeType was stated explicitly in the object.
    type: CategoricalVariant
    # subtype: ProteinSequenceConsequence  or categoryType: ProteinSequenceConsequence
    constraints:
      - type: DefiningAlleleConstraint
        allele:
          id: ga4gh:VA.t0rDoiIessOWmP0SF0plhXtOwi8TRaZz
          type: Allele
          location:
            type: SequenceLocation
            sequenceReference:
              refgetAccession: SQ.w7LxW0PSaVPNsPFvOL24weFjHcfaHyOi
              type: SequenceReference
            start: 10
            end: 11
            sequence: R
          state:
            type: LiteralSequenceExpression
            sequence: T
          expressions:
            - syntax: hgvs.p
              value: NP_000305.3:p.Arg11Thr
        relations:
          - translates_from
          - translates_from_reading_frame
  predicate: isCausalFor
  objectCondition:
    conceptType: Condition
    label: Unspecified
  geneContextQualifier:
    conceptType: Gene
    label: PTEN
... goes on...

I am in favor of adding a categoryType field that allows us to specify the particular type of categorical variant that is being represented, since we no longer put that in the type field based on how we are using constraints instead of subclassing CategoricalVariant.

I think this information if quite important to the downstream computational consumer (and human consumer) in that you do not have to discern the type of variant from the mixture of constraints.

[larrybabb]

Adding @ahwagner s comments from my original post in a PR on va-spec on this topic. We decided it best to move this entire discussion to Cat-VRS so we can get some resolution.
Here's @ahwagner s reply to the above from 11-09-2024...

ahwagner 5 days ago
I think this boils down to a domain issue. I get that if you are only considering a handful of common patterns (e.g. three categories of Canonical Allele, Canonical CNV, and "other stuff"), ideally you would want these as named classes, similar to how we do things in VRS.

I just want to caution against the idea that we rely on typing for top-level concepts Cat-VRS. Typed constraints should get you everything you need and scale far better in this problem space. I know I have gone over the Somatic Variation Landscape before, but these are just a handful of what are a combinatorial number of potential types of categorical variants based on the various ways different constraints are used. Should I build an implementation that looks for a subtype based on a combinatorial list of types that conveys an object has a gene constraint + functional constraint, or a gene constraint + location constraint + functional constraint, or a gene constraint + location constraint + molecular constraint, or a location constraint + molecular constraint, or the various combinations of input configurations of those constraints (e.g. location constraint with "liftover_to" relation), ad nauseum? I hope not. When consuming these data for use in a system that covers the broad heterogeneity of concept types seen in the VICC knowledgebases, I would instead rely on the types of functional constraints for processing. Ultimately, I would think you would want the same thing, once you start digging into what that "other stuff" in ClinVar is.

It seems to me like the current setup generalizes cross-domain concerns and saves us the difficulty of explicitly naming the many potential combinations of constraints and constraint properties. Building our systems in the absence of such named category types seems like the right mindset for generalized software in this domain.

Do you disagree? If so, I recommend we move this conversation to a discussion thread in Cat-VRS and hash it out there.