Open dustine32 opened 5 years ago
following
Also, pay attention to different
with
lists for the IBDs (e.g.[SPAC1B3.15c, SPAC1B3.16c]
vs.[SPAC1B3.16c]
). Does a distinctwith
list make an IBD worthy of saving?
How come there are different lists anyway ? These should all be part of the same evidence.
@pgaudet Agreed! Though doesn't the PAINT tool give the curator some options for which GO annotation evidence to associate with an IBD? I could be confused about this.
When an IBD annotation is created by the PAINT tool, the tool determines the list of all experimental annotations that can be used for the IBD. It then groups them based on the qualifier. If there is more than 1 qualifier, the system prompts the curator to select the qualifier. Based on the qualifier selected by the curator, the PAINT tool only uses those experimental annotations that have the qualifier selected by the curator.
Ah, that's where I was mistaken. Thanks @mugitty !
However, if there is a NOT annotation on the leaf, the positive annotation should NOT be propagated.
Right ?
Any leaf that that has experimental evidence that is used for creating the IBD will not have the propagated annotation.
Right ! So I don't understand why we are seeing those. There any many examples.
Do you have an example of it appearing on PAINT?
In PAINT you dont see the positive annotation. It seems like a pipeline/export problem.
@pgaudet @mugitty I believe by design the leaf SPAC1B3.15c
would still get a positive GO:0015225
IBA if the positive GO:0015225
IBD using SPAC1B3.16c
(vht1) as evidence is still valid AND there's no IKR/IRD on or above leaf SPAC1B3.15c
in PAINT to prevent the positive IBA propagation.
Though, those redundant positive IBAs on SPAC1B3.15c
are indeed a pipeline/export problem that I'm working to fix right now.
From https://github.com/geneontology/go-annotation/issues/2660: We recently introduced a script to obsolete redundant IBDs that are on different nodes in a tree. For example, an IBD on AN1 to GO:0015225 already accomplishes what another GO:0015225 IBD to AN1-descendant AN2 would do. Therefore, the GO:0015225 IBD to AN2 will be obsoleted. As it turns out, this meant redundant IBDs that are on the same node together were ignored and left alone. Will need to fix this script to include this scenario.
Also, pay attention to different
with
lists for the IBDs (e.g.[SPAC1B3.15c, SPAC1B3.16c]
vs.[SPAC1B3.16c]
). Does a distinctwith
list make an IBD worthy of saving?