categorize obsolete terms into GO aspect

[balhoff]

Currently in query responses, an obsolete terms has no root type, which affects Noctua.

[balhoff]

This was requested by @tmushayahama, I think related to https://github.com/geneontology/noctua/issues/788

[vanaukenk]

@balhoff - can you let us know what the scope of the work is for populating a root type value in minerva for obsolete ontology terms, either GO or external ontologies such as UBERON or CL?

Curators are not able to update obsolete ontology terms in the Noctua form table because those terms are missing a root type value.

See: https://github.com/geneontology/noctua-form/issues/243

Thank you!

[kltm]

I'd like to understand the underlying issues before proceeding.

IIRC, obsoleted terms are no longer part of the graph, so have no natural branch, thus no aspect. A way around on the ontology side would be to keep "history" which sounds weird, or to capture historical aspect in some other field.

That said, this could be approached other ways besides the ontology. Technically speaking, a client could do this without help, it's just that the way these particular clients are structured makes it harder from where we're at (but maybe not n the future).

[tmushayahama]

@kltm we just want to constraint the replace functionality. If a curator sees an obsolete BP term then the replace value should have the same root type, in this case the BP term. Otherwise if the obsolete term doesn't have a root type or category, then there is no way of knowing which constraint to put and a curator can make a mistake of replacing a BP term with an MF term causing the whole activity to be error prone

tagging @vanaukenk if I explain it well

[vanaukenk]

@tmushayahama - yes, you've explained it well.

Without having information about root type/aspect for an obsolete term we currently can't constrain the replacement ontology term in the Noctua form table.

I'm open to discussing options on how best to do this, but the objective was to try to prevent curator errors at the point of data entry.

[kltm]

No doubt about the effect that we want to achieve, but the issue is deeper than the surface as, for how we do things now (IIRC), obsoleted terms are no longer in the graph--they exist as singletons, free-floating like plankton. Looking at go-edit.obo, it does seem that they still have a namespace entry, so that's a bit of history still sitting around.

From another angle (and I'm not sure if this is a good example), there are also terms like: https://www.ebi.ac.uk/QuickGO/GTerm?id=GO:0052247#term=history, which are obsoleted as "...it represents both a process and a location."

[balhoff]

@vanaukenk @tmushayahama I think it would be helpful to talk about this in a tech meeting. Shouldn't the necessary constraint be evident based on the other info (such as relations)?

[vanaukenk]

@balhoff @kltm - can you both join us on the Noctua workbenches call this coming Thursday at 1pm/10am to talk about this issue?

[balhoff]

@vanaukenk yes, that works for me.

[vanaukenk]

From 2023-11-16 workbenches call:

For obsolete GO terms, minerva will insert the root term appropriate for the GO aspect. If the obsolete GO term has a 'replaced by' GO term, then return the root term for the 'replaced by' GO term.

Note that for now, we are limiting this fix to obsolete GO terms. If this issue becomes a problem for other ontology terms, we will look at those separately.