categorize obsolete terms into GO aspect
balhoff opened this issue · 10 comments
Currently in query responses, an obsolete terms has no root type, which affects Noctua.
This was requested by @tmushayahama, I think related to geneontology/noctua#788
@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: geneontology/noctua-form#243
Thank you!
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).
@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
@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.
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."
@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 yes, that works for me.
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.