PTN000273640 - PTHR12395 NOT annotation conflict

[hattrill]

FBgn0260932 cuff has a NOT RNA pyrophosphohydrolase activity (IDA) but is getting a positive annotation from PTN000273640

http://amigo.geneontology.org/amigo/gene_product/FB:FBgn0260932

I thought the the PAINT pipeline was blocking propagation to NOTs?

Could you block this and check that the filter is working.

[sjm41]

Another example may be fly Wsck (FBgn0046685/P83097):

• has NOT 'protein kinase activity' IKR
• but also getting 'non-membrane spanning protein tyrosine kinase activity' IBA (PTN002521528)

http://amigo.geneontology.org/amigo/gene_product/FB:FBgn0046685

But this may not be a good example if the term has to be an exact match (not parent-child) for the PAINT pipeline to block propagation when a NOT is present?

[sjm41]

@hattrill @pgaudet @marcfeuermann - looks like the FBgn0260932 cuff example has been fixed (one way or another). Agree?

However, my Wsck (FBgn0046685/P83097) example (and the ones in the linked ticket #2880) are still problematic. (Though as I mentioned, I'm not sure if this is the same issue - I don't know whether the block on PAINT annotation propagations is supposed to work when the two terms involve a parent-child relationship rather than being the exact same term?)

[sjm41]

Anyone know the answer to this?: I don't know whether the block on PAINT annotation propagations is supposed to work when the two terms involve a parent-child relationship rather than being the exact same term?

In the example above, fly Wsck (FBgn0046685/P83097) has NOT 'protein kinase activity' IKR But is getting positive annotations to the child terms 'non-membrane spanning protein tyrosine kinase activity' via PTN002521528 and ' protein tyrosine kinase activity' via PTN002521457.

Should the NOT on the parent term be blocking the application of the IBA child terms to Wsck, or do the terms have to be the same for this block to work?

[pgaudet]

Hi @sjm41

In the example above, fly Wsck (FBgn0046685/P83097) has NOT 'protein kinase activity' IKR But is getting positive annotations to the child terms 'non-membrane spanning protein tyrosine kinase activity' via PTN002521528 and ' protein tyrosine kinase activity' via PTN002521457.

This is not the correct behavior. @huaiyumi and @mugitty can you please check what the problem might be?

[pgaudet]

In the PAINT UI there is no MF/IBA annotation to this gene

[sjm41]

Yep, as mentioned in my 14th Jan comment, Helen's example with 'cuff' has been resolved.

But my example with 'Wsck' is still problematic: _In the example above, fly Wsck (FBgn0046685/P83097) has NOT 'protein kinase activity' IKR But is getting positive annotations to the child terms 'non-membrane spanning protein tyrosine kinase activity' via PTN002521528 and ' protein tyrosine kinase activity' via PTN002521457.

Should the NOT on the parent term be blocking the application of the IBA child terms to Wsck, or do the terms have to be the same for this block to work?_

[pgaudet]

Sorry, this is confusing - especially PTNs - it's not easy to see in which tree they belong. So, I assume PTN002521528 = PTHR24418, a PK family with almost 1000 members. Sometimes those dont open easily, please ping again if there is no reply soon.

Generally can you please open a new ticket for different tree/annotation issues?

[pgaudet]

Also - note that this seems to be a 'known' issue - https://github.com/geneontology/go-annotation/issues/3546

Looks like all those trees should be reviewed.

[sjm41]

Thanks, and sorry for the confusion. I normally would open a separate ticket, but we thought at the time that the issue wasn't specific to certain nodes, but rather a general problem about PAINT erroneously adding an IBA annotation where there's a NOT annotation in place - I guess that's true from looking at #3546?

At this point, would it best to leave this ticket open, or better that we close it and I put the 'Wsck (PTN002521528 / PTHR24418) example in a new ticket, or maybe add to #3546?

[pgaudet]

PTHR24418 is in #3546 already, so we're good.

I am not sure this is the issue, but we are more likely to have forward tracking problems than NOT problems in PAINT.

[pgaudet]

I'll open a new ticket.