Replies: 5 comments 1 reply
-
Hi Petri, Thanks for the feedback. I suspect that the differences are coming from electronic annotations; can you check whether this is the case ? These are ran regularly, so we'd expect changes. If you have specific examples that would help us investigate what may be happening. Thanks, Pascale |
Beta Was this translation helpful? Give feedback.
-
Hi @petritoro This seems to match our automatic updates: 2018-02-04: Due to PANTHER library version update from PANTHER12 to PANTHER13.1, PANTHER12 families PTHR24300 contained nodes PTN000670523can not be directly mapped to Panther13 nodes by PTN but their direct child nodes PTN000670895,PTN002387263 can be directly mapped to Panther13 nodes in PANTHER13 family PTHR24300 by PTN these nodes were annotated with GO terms GO:0008392,GO:0019373. 2018-05-07: PAINT_EXP annotation to node PTN000670895 with GO:0008392 was obsoleted because there was no supporting leaf node experimental go annotation left after PANTHER library version update. 2018-05-07: PAINT_EXP annotation to node PTN002387263 with GO:0019373 was un-obsoleted because there now exists new supporting leaf node experimental go annotation after PANTHER library version update. 2018-06-27: PAINT_EXP annotation to node PTN002387263 with GO:0019373 was un-obsoleted because there now exists new supporting leaf node experimental go annotation after PANTHER library version update.
2022-10-05: In the PANTHER17.0 update, PANTHER17.0 family PTHR24300 lost IBD annotations. PTN001210788 (Eumetazoa - SPECIATION, contains HUMAN_CYP2U1) that was annotated with GO terms GO:0008395 (IBD) can not be mapped to PANTHER17.0. 2023-01-11 paint_validator Annotation Validity Update. 2023-04-05: In the PANTHER17.0 update, PTN001210788 can not be directly mapped but their direct child nodes PTN000670521 can be mapped to . These nodes were annotated with GO terms GO:0008395 (IBD). |
Beta Was this translation helpful? Give feedback.
-
Maybe @dustine32 @huaiyumi @mugitty have more insight into this. Also, in this case, the dates on the annotations do not align with the date of the error message; the annotation was brought back in 2018, and the GAF has 2020. When annotations are restored, we should also restore the original date of curation. |
Beta Was this translation helpful? Give feedback.
-
Hi I notice that I have misunderstood some GO evidence codes. I mixed IBA evidence code with experimental evidence codes. I have to revisit these... Petri |
Beta Was this translation helpful? Give feedback.
-
Dear GO community and gene annotators especially,
I have worked on code that aims to generate Gene Ontology (GO) datasets for our use. My aim is to allow various splits on the existing existing data. This would allow different training and test datasets from GO data. One of the planned ways to split the data is the date info in the GO gaf file. Here one would use a selected date to divide the data in two parts: One before and another after the date.
When I tested the code I noticed that that the later GO gaf annotations, with the selected date threshold, xx, do not return the same genes as the older gaf annotation file, downloaded on the date xx. Furthermore, it seems that more than half of the genes that were annotated in the older gaf file have been moved totally to a later date, occurring after the selected date threshold.
I cannot fully exclude potential coding error(s) as reason. However, I tracked specific gene names and their non-IEA GO annotations that have the altered newer date. I can distribute these, if needed. Can somebody explain reasons to this? This weakens, IMO, the usefulness of the date information in the GO gaf files.
Yours'
Petri
Beta Was this translation helpful? Give feedback.
All reactions