Creating abnormalAnatomicalEntity phenotypes from FBBT for downstream tools

[matentzn]

Creating abnormalAnatomicalEntity phenotypes from FBBT for downstream tools

[Clare72]

Based on an old spreadsheet (Sep 2018) Gil made me, 2880 FBbt terms have been used in phenotype curation, maybe a few more now.
Can I just clarify what you want to do?
So there would be 'abnormal X' terms in the FBcv namespace, but these would not be incorporated into FBcv or dpo? Would these terms form their own ontology? Would this ontology import FBbt?
We would also need an ID range set aside and some mechanism for creating new terms automatically when an FBbt term is used in phenotype curation for the first time.
What do you mean by 'mappings', will the phenotype terms not be automatically mapped by using FBbt terms in the logical definitions?

[matentzn]

Where these abnormal terms life we have not yet decided. This are the considerations:

1. We want to be able to compare phenotype terms across species to integrate curated data from FlyBase with say data from WormBase
2. So we need a phenotype term wherever a phenotype is annotated
3. FlyBase has these, as you say 3K annotations against FBBT terms
4. To enable comparison between a WormBase phenotype and a fly phenotype, downstream tools have been generating their own weird flybase phenotype ontologies, see for example here, and in particular check the IRIs.
5. The hope would be that FlyBase would agree hosting all those weird abnormal anatomy fly phenotypes themselves. This would look like this:

A script pulls all FlyBase fbbt annotations and writes them to a table, like so:

anatomy	quality
FBBT:001	PATO:001
FBBT:002	PATO:002

A script then adds identifiers according to a prescribed scheme (that I already have implemented for ZP and XPO).

defined_class	anatomy	quality
FBCV:001	FBBT:001	PATO:001
FBCV:002	FBBT:002	PATO:002

Then we use the abnormalAnatomicalEntity pattern (uPheno) to generate an owl file. So each generated FBCV term is simply connected to it FBBT: term using the usual has part o inheres in boilerplate. FBBT terms would be imported from FBBT.

That OWL file is then imported into DPO (ideally), or, if this is not wanted by FlyBase, offered as a separate artefact in the DPO repository..

I understand that given the size, FlyBase might simply not want to integrate these terms into dpo (which would massively increase in size).

[Clare72]

Thanks for the clarification.
Those FBbt_00000028PHENOTYPE style IRIs are horrible!
There isn't currently anything greater than FBcv:1000000, so we could allocate FBcv:1000000 to FBcv:1009999 for this (and more later if needed).
I don't see any problem with keeping these terms on the dpo repo, but we wouldn't want to integrate them into dpo as they will not be used for curation at FlyBase and, as you say, will massively bloat the ontology.
Do you already have scripts to do what you need or would this require some input from FlyBase?

[matentzn]

Basically what we need to figure out is whether we can merge this file into the non-flybase-releases of dpo; This would mean they show up on OLS, etc.

My hole business here is: Once uPheno gets out, with all phenotypes across all species, people will start annotating to it; this will potentially include the fbbt phenotypes. It will be confusing to have the terms show up in the context of uPheno, but not in the context of dpo. So the ideal solution for me would be this:

• DPO officially contains the abnormal anatomical entity phenotypes, so all its release files do too (including simple OWL and OBO). All of these are marked with a subset (abnormal_anatomy).
• FBCV imports, instead of what it does now, a subset of DPO-simple, which first removes the abnormal anatomy terms.
• This means FBCV remains exactly as it is now.

This would ensure:

1. No one creates fly terms elsewhere, so the namespace is still managed by the people best suited for it (FlyBase)
2. Anatomical phenotypes are kept up to date (and not go stale elsewhere, which means wrong subsumptions and outdated mappings to Flybase annotations)
3. Fly phenotypes are interoperable with other species, especially human.

[matentzn]

(yes once the approach is agreed, I will implement everything with @dosumis)

[matentzn]

@dosumis @Clare72 says that FBBT:001 could mean that the physical entity is affected, or a processes/function in/of FBBT:001 is affected. Is it safe to map FBBT:001 annotations from FlyBase to the abnormalAnatomicalEntity pattern in this way? Or do you see potential pitfalls?