-
Notifications
You must be signed in to change notification settings - Fork 0
Add genome groups #78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
app/api/models/genome.py
Outdated
| assembly_name: str = Field(alias="assemblyName") | ||
| is_reference: bool = Field(alias="isReference", default=False) | ||
| is_group_reference: bool = Field(alias="isGroupReference", default=False) | ||
| release: Release = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have all sorts of questions about this PR, which arose after trying to understand this Genome model.
- Is the
/genome_groupsendpoint intended to provide data both for this part of the UI:
and for this part of the UI:
I understand that the first image shows "organism groups", and the second one shows "genome groups" — are you planning to keep this distinction, or are you planning to somehow unite both at the level of the json api?
- Especially if we expect the two images above to be generated from data from different endpoints, then could you remind me what the
reference_genomein the JSON payload was intended for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry; I realised that I was being stupid and that we are actually talking about the structural variants UI 🤦♂️
In that case yes, I remember why we needed the reference genome for group.
But even so:
- Will the
/genome_groupsendpoint also be used to power the search UI? - Shouldn't the reference genome payload resemble the response from the
explainendpoint: https://staging-2020.ensembl.org/api/metadata/genome/grcm39/explain? Or actually, the shape of a search match (https://staging-2020.ensembl.org/api/search/genomes?species_taxonomy_id=10090), if we reuse the genomes endpoint for the search UI
Perhaps @EbiArnie should also be among the reviewers then, since there are overlapping concerns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd address search needs in its own PR, this more compact payload is good for SV. I don't think we even need the release info for the genome selection dropdowns.
@azangru do the payload fields here cover the different genome labelling options in the dropdown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would need:
- genome_id
- genome_tag
- common_name
- scientific_name
- type (a json object)
- is_reference
- assembly (a json object)
But at that point, adding the release probably shouldn't be a problem.
app/api/models/genome.py
Outdated
| group_id: str = Field(alias="groupId") | ||
| group_type: str = Field(alias="groupType") | ||
| group_name: str | None = Field(alias="groupName", default=None) | ||
| reference_genome: Genome = Field(alias="referenceGenome") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't a group also need a count?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the SV app uses counts anywhere.
app/api/models/genome.py
Outdated
| genome_groups: list[GenomeGroup] = Field(alias="genomeGroups") | ||
|
|
||
| class GenomesInGroupResponse(BaseModel): | ||
| genomes: list[Genome] = Field(alias="genomes") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
@azangru I updated the output to use the same model used by |
veidenberg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for SV app requirements (has genome id, common name, assembly name).
| id: str = Field(alias="groupId") | ||
| type: str = Field(alias="groupType") | ||
| name: str | None = Field(alias="groupName", default=None) | ||
| reference_genome: BaseGenomeDetails = Field(alias="referenceGenome") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just remember that this is a nullable field. We should always have a reference genome for structural variant groups, but not for other groups.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The object name is kinda deceiving at this stage, I think of changing it to SVGenomeGroup because it's SV specific

Description
Added two REST endpoints that will be used by the structural variant page
Related JIRA Issue(s)
Main JIRA ticket: https://embl.atlassian.net/browse/ENSPLAT-269
Sub task: https://embl.atlassian.net/browse/ENSPLAT-271
Review App URL(s)
https://ensembl.github.io/ensembl-web-metadata-api/
Example(s)
/api/metadata/genome_groupsRequest:
Response:
/api/metadata/genome_groups/{group_id}/genomesRequest:
Response:
Dependencies