Add genome groups

[bilalebi]

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/

⚠️ Won't work until Ensembl/ensembl-metadata-api#172 is merged and deployed

Example(s)

/api/metadata/genome_groups

Request:

http://127.0.0.1:8014/api/metadata/genome_groups?group_type=structural_variant

Response:

{
  "genome_groups": [
    {
      "id": "grch38-group",
      "type": "structural_variant",
      "name": null,
      "reference_genome": {
        "genome_id": "a7335667-93e7-11ec-a39d-005056b38ce3",
        "genome_tag": "grch38",
        "common_name": "Human",
        "scientific_name": "Homo sapiens",
        "species_taxonomy_id": "9606",
        "type": null,
        "is_reference": true,
        "assembly": {
          "accession_id": "GCA_000001405.29",
          "name": "GRCh38.p14",
          "url": "https://identifiers.org/insdc.gca/GCA_000001405.29"
        },
        "release": {
          "name": "2025-02",
          "type": "integrated",
          "is_current": true
        }
      }
    },
    {
      "id": "t2t-group",
      "type": "structural_variant",
      "name": null,
      "reference_genome": {
        "genome_id": "4c07817b-c7c5-463f-8624-982286bc4355",
        "genome_tag": "t2t-chm13",
        "common_name": "Human",
        "scientific_name": "Homo sapiens",
        "species_taxonomy_id": "9606",
        "type": null,
        "is_reference": false,
        "assembly": {
          "accession_id": "GCA_009914755.4",
          "name": "T2T-CHM13v2.0",
          "url": "https://identifiers.org/insdc.gca/GCA_009914755.4"
        },
        "release": {
          "name": "2025-02",
          "type": "integrated",
          "is_current": true
        }
      }
    }
  ]
}

/api/metadata/genome_groups/{group_id}/genomes

Request:

http://127.0.0.1:8014/api/metadata/genome_groups/grch38-group/genomes

Response:

{
  "genomes": [
    {
      "genomeUuid": "a7335667-93e7-11ec-a39d-005056b38ce3",
      "genome_tag": "grch38",
      "common_name": "Human",
      "scientific_name": "Homo sapiens",
      "species_taxonomy_id": "9606",
      "type": null,
      "is_reference": true,
      "assembly": {
        "accession": "https://identifiers.org/insdc.gca/GCA_000001405.29",
        "name": "GRCh38.p14"
      },
      "release": {
        "releaseLabel": "2025-02",
        "releaseType": "integrated",
        "isCurrent": true
      }
    },
    {
      "genomeUuid": "4c07817b-c7c5-463f-8624-982286bc4355",
      "genome_tag": "t2t-chm13",
      "common_name": "Human",
      "scientific_name": "Homo sapiens",
      "species_taxonomy_id": "9606",
      "type": null,
      "is_reference": false,
      "assembly": {
        "accession": "https://identifiers.org/insdc.gca/GCA_009914755.4",
        "name": "T2T-CHM13v2.0"
      },
      "release": {
        "releaseLabel": "2025-02",
        "releaseType": "integrated",
        "isCurrent": true
      }
    }
  ]
}

Dependencies

⚠️ Don't merge this one until Ensembl/ensembl-metadata-api#172 is!

[azangru]

I have all sorts of questions about this PR, which arose after trying to understand this Genome model.

1. Is the /genome_groups endpoint 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?

2. Especially if we expect the two images above to be generated from data from different endpoints, then could you remind me what the reference_genome in the JSON payload was intended for?

[azangru]

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_groups endpoint also be used to power the search UI?
• Shouldn't the reference genome payload resemble the response from the explain endpoint: 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.

[veidenberg]

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?

[azangru]

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.

[azangru]

Doesn't a group also need a count?

[veidenberg]

I don't think the SV app uses counts anywhere.

[azangru]

Genomes in group should match the search results payload, I think. If we want them to populate the table in the same way other search results do:

[bilalebi]

@azangru I updated the output to use the same model used by /explain (please see the updated output exmaples in the PR description) and removed group_ from GenomeGroup attributes

[veidenberg]

Looks good for SV app requirements (has genome id, common name, assembly name).

[azangru]

Just remember that this is a nullable field. We should always have a reference genome for structural variant groups, but not for other groups.

[bilalebi]

The object name is kinda deceiving at this stage, I think of changing it to SVGenomeGroup because it's SV specific