Understanding file structure for profiles

[korikuzma]

I noticed that profiles have multiple subdirectories, each containing its own source.yaml file as well as generated json and rst files. Current structure looks like:

├── diagnostic
│   ├── def
│   │   └── VariantDiagnosticStudy.rst
│   ├── json
│   │   └── VariantDiagnosticStudy
│   ├── diagnostic-source.yaml
├── prognostic
│   ├── def
│   │   └── VariantPrognosticStudy.rst
│   ├── json
│   │   └── VariantPrognosticStudy
│   ├── prognostic-source.yaml
└── t-resp
    ├── def
    │   └── VariantTherapeuticResponseStudy.rst
    ├── json
    │   └── VariantTherapeuticResponseStudy
    └── t-resp-source.yaml

However, in gks-common, there is a single subdirectory with multiple source files and a single def/json stores all concepts. Current structure looks like:

├── def
│   ├── Code.rst
│   ├── Coding.rst
│   ├── CombinationTherapy.rst
│   ├── ConceptMapping.rst
│   ├── Condition.rst
│   ├── Disease.rst
│   ├── DomainEntity.rst
│   ├── Entity.rst
│   ├── Expression.rst
│   ├── Extension.rst
│   ├── Gene.rst
│   ├── IRI.rst
│   ├── Phenotype.rst
│   ├── TherapeuticAction.rst
│   ├── TherapeuticAgent.rst
│   ├── TherapeuticProcedure.rst
│   ├── TherapeuticSubstituteGroup.rst
│   └── TraitSet.rst
├── json
│   ├── Code
│   ├── Coding
│   ├── CombinationTherapy
│   ├── ConceptMapping
│   ├── Condition
│   ├── Disease
│   ├── Expression
│   ├── Extension
│   ├── Gene
│   ├── IRI
│   ├── Phenotype
│   ├── TherapeuticAction
│   ├── TherapeuticAgent
│   ├── TherapeuticProcedure
│   ├── TherapeuticSubstituteGroup
│   └── TraitSet
├── common-source.yaml
├── conditions-source.yaml
├── genes-source.yaml
└── therapeutics-source.yaml

@ga4gh/va-admin , can you explain why the profiles are structured this way rather than following the gks-common approach? What are there advantages for current structure?

├── def
│   ├── VariantDiagnosticStudy.rst
│   ├── VariantPrognosticStudy.rst
│   ├── VariantTherapeuticResponseStudy.rst
├── json
│   ├── VariantDiagnosticStudy
│   ├── VariantPrognosticStudy
│   ├── VariantTherapeuticResponseStudy
├── diagnostic-source.yaml
├── prognostic-source.yaml
├── t-resp-source.yaml

[larrybabb]

This past weekend I combined all the profiles into a single yaml so that I could see the impact. I feel this is a simpler approach at this point. Others are welcome to look at the commit history to compare the current changes versus the older split out approach.

[larrybabb]

I also aggregated the DomainEntity subclasses that had separate yaml files in the gks-common repo so that they are all in a single domain-entities.yaml file in the gks-common/schema/domain-entities folder. We will continue to discuss this organizational change to determine if this is the best and final location for DomainEntity subclasses or not.

[korikuzma]

Going to close this discussion. All repos are using similar structure now. Consistency is nice!