-
Notifications
You must be signed in to change notification settings - Fork 0
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
Obsolete redundant IBDs on same node #35
Comments
following |
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 Though, those redundant positive IBAs on |
From geneontology/go-annotation#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?The text was updated successfully, but these errors were encountered: