Should we change name of profile directories and file names to be more descriptive and consistent?

[mbrush]

IMO these should more clearly convey what the profiles are about, and be consistent w.r.t. their use of abbreviation.

e.g. change "t-resp" to "therapeutic-response"
e.g. change "caf" to "cohort-allele-frequency"

. . . Note there is no need to include "variant" in these names as this is implied to be at the beginning of each.

Note also that the profile catalog proposal in #140 would support the desire for a consistent naming approach outlined here.

[larrybabb]

@mbrush I think this is a reasonable request. please go forward with the names as you see fit in a PR and make sure to fix the references in the *-source.yaml files and any *.rst files that may exist.

[larrybabb]

I'll try to take this one on and at least move things in the right direction. I'll likely do this with the caf liftover work.

[larrybabb]

@mbrush the new va-spec/profiles folder has been reorganized to remove the profile specific subfolders. All standard profiles are defined in the profiles-source.yaml file and all names of those profiles have been brought up to your standards. Please verify and close this if it meets your expectations.

[mbrush]

I still prefer the distinct standard profiles to be defined in separate yaml files.

• I think it is conceptually easier to understand how the profiling process is working, and the idea that each profile is a stand alone schema for representing a particular type of variant knowledge - if the yaml files where they are authored are separate
• I think it will make the work of creating/editing standard profiles easier to have them split apart.
• It seems like more modularity here would also make it technically easier to reuse/extend a specific standard profile of interest.

The only complication that this introduces is a minor (and currently hypothetical) one IMO. If we decide to bring back the the 'abstract' Statement schema (VariantStatement', 'Variant Classification') that @larrybabb removed per #138, then we will need to determine where these abstract classes live. A merged profiles-source.yaml file wold have been a clear choice, but without it, another solution will be needed.