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.

[DanielPuthawala]

Not sure how I missed this discussion when you first posted it @larrybabb, but yea, lets talk about it. Especially since my background is in typed logics, so this stuff is my jam, and I've spent a decent amount of time thinking in terms of types and the logic thereof with CatVars in the past year.

My main question after reading the above is, what problem are you trying to solve by introducing subtypes? Like do we want to be able to fully curry out the arguments of CategoricalVariant and keep track of what arguments it has received/still needs? That's sort of useful if we are looking at partial CatVar records and trying to decide what to do with them and how, but I get the sense that that's not what you are thinking about here.

Are you saying that you to type CategoricalVariable objects according to what and which constraints they satisfy? That's my best guess based on the schema mock-up you put above. As I think Alex was saying in the VA discussion thread, we can in principle do something like that, I'm just not entirely certain what the utility is, because it would basically constitute the same information as just reading the CategoricalVariant object and checking the contents of constraints.

As Alex said, part of the problem is that the type space of CatVars is combinatorial, so you'd have this HUGE space to deal with, and anything other than a really uniform dataset would probably end up populating that space pretty sparsely. But we can deal with that problem somewhat by making sure that the types are compositional, ie, the type of the whole CategoricalVariant object derives, in a consistent and deterministic way, from the contents of constraints. This would also solve the a slightly different problem.

Say we have one CategoricalVariant object, which satisfies DefiningAlleleConstraint, GeneContextConstraint,and FunctionConstraint, in such a way that it can work as either a Protein Missense Variant, a Gene Function Variant, or in fact, both. Handing this compositionally as outlined above, we could handle this by, say, adding your CategoricalVariantSubtype` property, and then generating a string subtype label in a deterministic way depending on which constraints are populated. For this toy example, let us pretend that we assign a unique letter to each constraint:

• A for the DefiningAlleleConstraint,
• B for the DefiningLocationConstraint,
• C for the GeneContextConstraint,
• D for the CopyCountConstraint,
• E for the `CopyChangeConstraint", and
• F for the FunctionConstraints

Under this scheme, our example variant above would have the following subtype:

CategoricalVariantSubtype: "ACF"

And finding CatVars of some given type amounts to searching for CatVars whose CategoricalVariantSubtype contains your prompt, so the above example is a sub-category of any of the following types:

• ACF
• AC
• AF
• CF
• A
• C
• F

But is NOT a subcategory of any type that includes anything in addition to A, C, and F, like ABCDF

This is fundamentally the way that the constraints and recipes system works, and so aside from perhaps increasing search speed slightly by only needing to search one property rather than checking against the each constraint itself, adding this would not change the fundamental properties of the system in any way.

Is that sort of what you were thinking about or am I completely misunderstanding you, Larry?