-
Notifications
You must be signed in to change notification settings - Fork 29
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
Dont use species specific anatomy terms in Uberon? #2025
Comments
This issue has not seen any activity in the past 6 months; it will be closed automatically in one year from now if no action is taken. |
@gouttegd do you agree the best way here is to:
|
In principle I agree, with the exception of terms that are clearly taxon-specific but whose labels are ambiguous, usually because they come from species-specific ontologies. See e.g. UBERON:6003624, previously labelled 'adult brain' (xref FBbt:00003624 and child of UBERON:6003007 'insect adult head'), and renamed 'insect adult brain' by Chris to disambiguate (#1759). For its nature, Uberon contains many terms that may have that issue. Some are being reviewed as part of producing the human slim etc, but I suspect that there are still cases where it'd be helpful to make the label species-specific in addition to taxon constraints. Years ago we had a similar discussion in GO for dinoflagellate-specific terms that had ambiguous labels, and Chris suggested to make the label species-informative (https://www.ebi.ac.uk/ols/search?q=dinoflagellate&ontology=go). |
@matentzn also recently in CL we agreed to let some terms be labelled 'human' (or similar) because they do represent human-specific types and it helps to have that info made explicit for those particular cells in that branch, see obophenotype/cell-ontology#1279 (comment). |
@paolaroncaglia My understanding of @matentzn ’s third point was that it is about using a species-specific term in the definition of an Uberon term or in a relationship with a Uberon term. That is, a Uberon term should never be a I would agree with such a policy – if this was indeed what Nico had in mind. This would have no bearing on using taxon-specific labels. |
Regarding the first two points: In principle I would agree, but for this issue specifically I would first question whether Uberon really needs a term such as FYI, we have 7 different My “gut feeling” is that Uberon should either have none of these precise terms (that is, Uberon should just have the superclass |
Agree 100%, and there is an actionable step here to create a check for such inter-ontology axioms
Agreed. There are a lot of issues with the 6x terms. The intent was to have generalization for terms that were typically referenced in GO but the initial import likely brought in too much, and many of the generalizations are pseudo-generalizations like the ZFA->TAO->Uberon:2x terms. We also need to revisit these with a general strategy for all the arthropod anatomy ontologies. But this is a lot to tackle. I think for now the general principle is don't have inter-ontology axioms to ssAOs, to fix 6x terms if they truly cause issues, and to revisit when we have adequate resources to fix (If however you feel we do have resources to commit to this then we can start drafting out some more specifics) |
Do I understand it correctly then that:
(@anitacaron @gouttegd lets not act on anything until we get confirmation) |
I agree on fixing the 6x terms on a case-by-case basis for now (e.g. in this particular issue, obsolete I’ll still make a complete list of the 6x terms and try to see how many of them exactly can be considered problematic. When we know the extent of the problem we may decide whether it is reasonable to try to address it in one go.
I think it should rather be “avoid any axiom involving a term from a species-specific ontology”. That is,
The second point may require having a hard-coded list of which ontologies are species-specific, because I don’t think this is something we can easily check automatically. |
The two terms `clypeo-labral anlage in statu nascendi` and `visual anlage in statu nascendi` are way too specific to belong in Uberon. Having the parental term `insect anlage in statu nascendi` (mapped to the corresponding term in FBbt) should be enough--anyone looking for a more precise term should go look for the children of the FBbt term. Obsoleting `clypeo-labral anlage in statu nascendi` allows to remove the FBbt term `anterior ectoderm anlage`, which was imported into Uberon since `clypeo-labral anlage in statu nascendi` has a part_of relationship to it. (As stated in #2025, we do not want any Uberon term to have any kind of relationship to a species-specific foreign ontology.) Obsoleting these two terms has cascading consequences: * `insect clypeo-labral anlage` is the starting point of a chain of `develops_from` relationships that goes up to `insect clypeus`; * similarly, `insect visual anlage in statu nascendi` is the starting point of a chain that goes up to `insect Bolwig organ`. It is doubtful that all these terms are really useful, but I don’t want to obsolete them all for now, so this PR simply breaks the chains at their beginnings by removing the first `develops_from` axioms. Deciding what to do with all the "insect anlage" and "insect primordium" terms will need to be done later (probably as part of a larger review of all the 6xxxxxx terms). close #2154
This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken. |
Is this somewhere in the UBERON documentation? |
Hi, @anitacaron, once a clear policy is outlined, I can update a page if pointed to the right place. |
I think the clear policy is the one outlined in my comment above. That is, no term in Uberon (and this should also be valid for CL) should ever depend on any way on a term coming from a taxon-specific ontology. Put differently, no axiom that has a Uberon or CL class as its subject should have a taxon-specific class as its object (the exception being mapping annotations; it’s OK to have an |
agree with @gouttegd |
This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken. |
Someone used http://purl.obolibrary.org/obo/FBbt_01000119
What is the policy here?
The text was updated successfully, but these errors were encountered: