KANBAN-838: Allow structured, post-composed phenotype annotations (alternative model).#308
Conversation
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.
|
Need to add XPO to list of phenotype ontologies in this section |
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
left a comment
There was a problem hiding this comment.
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.
|
This will be discussed further on the next (May 13) Disease & Phenotype working group call |
|
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. |
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_entityandqualifier.affected_entityrepresents 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:It can refine a phenotype that is otherwise described in
phenotype_terms, by indicating which organ, stage, or process is affected by a phenotype.It can describe a phenotype on its own (with
phenotype_termsleft 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).qualifieris used to further refine ("qualify") a phenotype that is otherwise described either byphenotype_termsor byaffected_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 arelated_entity, which describes an additional entity (in the same sense asaffected_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.