Skip to content

KANBAN-838: Allow structured, post-composed phenotype annotations (alternative model).#308

Merged
chris-grove merged 7 commits into
mainfrom
new-phenotype-annotation-model-2
Jun 24, 2026
Merged

KANBAN-838: Allow structured, post-composed phenotype annotations (alternative model).#308
chris-grove merged 7 commits into
mainfrom
new-phenotype-annotation-model-2

Conversation

@gouttegd

Copy link
Copy Markdown
Contributor

This PR implements an alternative proposition to #307 (to be discussed in the upcoming Disease WG).

It amends the PhenotypeAnnotation class by adding two slots: affected_entity and qualifier.

affected_entity represents any entity that is affected by the phenotype that is being described. It can be an anatomical structure, a developmental stage, or a biological process. The slot has a dual purpose:

  1. It can refine a phenotype that is otherwise described in phenotype_terms, by indicating which organ, stage, or process is affected by a phenotype.

  2. It can describe a phenotype on its own (with phenotype_terms left empty), if the main characteristic of the phenotype is that it affects a particular organ, stage, or process (this is especially the case for some FlyBase-style phenotype annotations).

qualifier is used to further refine ("qualify") a phenotype that is otherwise described either by phenotype_terms or by affected_entity. It must contain at the very least an ontological term from either PATO or one of the phenotype ontologies (for the phenotype ontologies that have "modifier" terms). It may also contain a related_entity, which describes an additional entity (in the same sense as affected_entity) that is linked to the phenotype through the qualifier term. This slot is especially intended to allow representing ZFIN-style "Entity+Qualifier" (EQ) phenotype statements.

gouttegd and others added 3 commits November 12, 2025 14:10
This commit amends the PhenotypeAnnotation class by adding two slots:
`affected_entity` and `qualifier`.

`affected_entity` represents any entity that is affected by the
phenotype that is being described. It can be an anatomical structure, a
developmental stage, or a biological process. The slot has a dual
purpose:

1. It can refine a phenotype that is otherwise described in
   `phenotype_terms`, by indicating which organ, stage, or process is
   affected by a phenotype.

2. It can describe a phenotype on its own (with `phenotype_terms` left
   empty), if the main characteristic of the phenotype is that it
   affects a particular organ, stage, or process (this is especially the
   case for some FlyBase-style phenotype annotations).

`qualifier` is used to further refine ("qualify") a phenotype that is
otherwise described either by `phenotype_terms` or by `affected_entity`.
It must contain at the very least an ontological term from either PATO
or one of the phenotype ontologies (for the phenotype ontologies that
have "modifier" terms). It may also contain a `related_entity`, which
describes an additional entity (in the same sense as `affected_entity`)
that is linked to the phenotype through the qualifier term. This slot is
especially intended to allow representing ZFIN-style "Entity+Qualifier"
(EQ) phenotype statements.
Some phenotype may need to be described by a qualifier that is a simple
"tag" (coming from a dedicated vocabulary) rather than an ontology term.
For that, we add an additional `qualifier_tag` slot to the
PhenotypeQualifier class.
@gouttegd gouttegd marked this pull request as ready for review November 20, 2025 12:47
@gouttegd gouttegd requested a review from chris-grove November 20, 2025 12:48
Comment thread model/schema/phenotypeAndDiseaseAnnotation.yaml Outdated
Comment thread model/schema/phenotypeAndDiseaseAnnotation.yaml Outdated
@sbello

sbello commented Jan 7, 2026

Copy link
Copy Markdown
Contributor

Need to add XPO to list of phenotype ontologies in this section
slot_usage:
phenotype_terms:
values_from:

MP, HP, and ZP would not be used to refine the description of a
phenotype and therefore don't need to be listed in the allowed sources
for `qualifier_term`.

Conversely, XPO needs to be added as an allowed source for
`phenotype_terms`.

Also relax the comment stating that only terms from the GO process
branch should be used in the `AffectedEntity.process` slot, because
terms from the molecular function branch might be used there as well
(and so arguably the name `process` is not ideal, but I'll leave the
question of its eventual renaming to others).

@chris-grove chris-grove left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposed changes are a great step in the right direction, but will ultimately need to be modified to accommodate use cases (from WormBase, at least) where multiple independent EQ pairings need to be supported. As I understand from the current proposal, a phenotype annotation can have multiple affected entities (anatomy, stage or GO term) and multiple qualifiers/qualities but as modeled all qualifiers apply equally to all affected entities. I would suggest creating an EntityQualityPairing class that links affected entities to qualities. Then a phenotype annotation can refer to multiple EntityQualityPairing objects to fully describe the phenotype.

@chris-grove

Copy link
Copy Markdown
Member

This will be discussed further on the next (May 13) Disease & Phenotype working group call

@gouttegd

gouttegd commented May 5, 2026

Copy link
Copy Markdown
Contributor Author

I won’t be able to attend that meeting.

And given that I am no longer remotely involved with the Alliance at all (either directly or through one of its constituent MODs), I believe it would probably be best if, after that meeting, someone else took over that PR.

@chris-grove chris-grove merged commit eb6f1a9 into main Jun 24, 2026
1 check passed
@chris-grove chris-grove deleted the new-phenotype-annotation-model-2 branch June 24, 2026 20:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants