Dont use species specific anatomy terms in Uberon?

[matentzn]

Someone used http://purl.obolibrary.org/obo/FBbt_01000119

What is the policy here?

[github-actions[bot]]

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.

[matentzn]

@gouttegd do you agree the best way here is to:

• [ ] Create a new Uberon class with the same scope as the FBbt class
• [ ] Map new Uberon class to FBbt class
• [ ] Have as policy not ever to have any species specific identifiers in Uberon?

[paolaroncaglia]

@matentzn

• [ ] Have as policy not ever to have any species specific identifiers in Uberon?

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 (https://github.com/obophenotype/uberon/issues/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).

[paolaroncaglia]

@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 https://github.com/obophenotype/cell-ontology/issues/1279#issuecomment-966378826.

[gouttegd]

@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 SubClassOf, be a part_of, or more generally have any kind of relationship with a term from a species-specific ontology (as in this example, where UBERON:600094 is part_of FBbt:01000119).

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.

[gouttegd]

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 clypeo-labral anlage in statu nascendi…

FYI, we have 7 different anlage in statu nascendi in FBbt. Two of them have corresponding classes in Uberon: this clypeo-labral anlage in statu nascendi and insect visual anlage in statu nascendi. Not sure either of them are needed.

My “gut feeling” is that Uberon should either have none of these precise terms (that is, Uberon should just have the superclass insect anlage in statu nascendi, mapped to the corresponding FBbt class), or it should have all 7 of them. Unless someone has a real a need for those terms, I am strongly in favour of the first solution.

[cmungall]

That is, a Uberon term should never be a SubClassOf, be a part_of, or more generally have any kind of relationship with a term from a species-specific ontology (as in this example, where UBERON:600094 is part_of FBbt:01000119)

Agree 100%, and there is an actionable step here to create a check for such inter-ontology axioms

I would first question whether Uberon really needs a term such as clypeo-labral anlage in statu nascendi

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)

[matentzn]

Do I understand it correctly then that:

• [ ] Add a check to avoid inter_ontology part of axioms (@anitacaron)
• [ ] Go with @gouttegd and obsolete anlage in statu nascendi terms in Uberon?

(@anitacaron @gouttegd lets not act on anything until we get confirmation)

[gouttegd]

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)

I agree on fixing the 6x terms on a case-by-case basis for now (e.g. in this particular issue, obsolete insect anlage in statu nascendi and its two subclasses, as summarised in Nico’s last message).

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.

Add a check to avoid inter_ontology part of axioms (@anitacaron)

I think it should rather be “avoid any axiom involving a term from a species-specific ontology”. That is,

• it should not be limited to part_of axioms;
• but it should not apply to all inter-ontology axioms, only those with species-specific ontologies.

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.

[github-actions[bot]]

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.

[anitacaron]

Is this somewhere in the UBERON documentation? Can you add this to the documentation, @bvarner-ebi? In any case, this was solved in PR #2347.

[ghost]

Hi, @anitacaron, once a clear policy is outlined, I can update a page if pointed to the right place.

[gouttegd]

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 AnnotationAssertion(semapv:crossSpeciesExactMatch) on a Uberon class pointing to a taxon-specific class).

[cmungall]

agree with @gouttegd

[github-actions[bot]]

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.