Skip to content
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

Fixing SynGO models for P2GO/QuickGO compatible GPAD export #102

Open
dosumis opened this issue Aug 23, 2018 · 7 comments
Open

Fixing SynGO models for P2GO/QuickGO compatible GPAD export #102

dosumis opened this issue Aug 23, 2018 · 7 comments

Comments

@dosumis
Copy link
Contributor

dosumis commented Aug 23, 2018

(Possibly not the right place for this ticket, but convenient to post here)

SynGO models are currently failing a bunch of P2GO checks. These checks were built over many years and reflect agreed GO curator rules - most of which are presumably still valid.

i've pasted a summary of these errors at the bottom of the ticket. A full log can be found here.

The main problems are with evidence codes. IIRC, SynGO has it's own evidence codes which are mapped (by SynGO) to ECO in SynGO JSON - which is then consumed by my SynGO2Lego Scala code.

To fix think we need a table (tsv/csv) of mappings currently being used. @BarbaraCzub may be able to help updating these to be valid. That table should then be used programatically either by SynGO or by the SynGO2Lego code and can easily be updated in future. Fixing the 'with' issue would require discussion with SynGO and extension of their tool.

(Note - I will not be working on this - I'm just the messenger).

SUMMARY

Number of lines processed: 16528
Total number of annotations: 16504
Number of annotations assigned by SynGO|SynGO-VU: 15494
Number of annotations assigned by other sources: 1010
Total number of problems detected: 11920
Number of annotations with error "Unsupported / unmapped identifier": 6934
Number of annotations with error "Unsupported evidence code": 4527
Number of annotations with error "With/from is mandatory for this evidence code": 459
Number of annotations excluded with evidence ECO:0000005 (): 2
Number of annotations excluded with evidence ECO:0000164 (): 262
Number of annotations excluded with evidence ECO:0001120 (): 17
Number of annotations excluded with evidence ECO:0005593 (): 2535
Number of annotations excluded with evidence ECO:0006065 (): 1711
Total number of warnings: 4527
Number of annotations with warning "No usage constraint found for this evidence code": 4527
Number of annotations with no errors: 5585

ANALYSIS

Number of annotations lacking mandatory with/from: 459
ECO:0000353 (IPI): 385
ECO:0001183 (IPI): 11
ECO:0005805 (IPI): 63

Number of annotations with unmapped identifiers: 6934
Number of unmapped identifiers: 537

Number of annotations with unsupported evidence code: 4527
ECO:0000005: 2
ECO:0000164: 262
ECO:0001120: 17
ECO:0005593: 2535
ECO:0006065: 1711

Number of annotations where there is no usage constraint for the evidence code: 4527
ECO:0000005: 2
ECO:0000164: 262
ECO:0001120: 17
ECO:0005593: 2535
ECO:0006065: 1711

CC @tonysawfordebi @BarbaraCzub @ftwkoopmans @Pimmelorus @dustine32

@BarbaraCzub
Copy link

This is not directly related, but also important. (And I had no idea what would have been the right place for that ticket either). I noticed that annotations displayed as "regulation of synapse disassembly/pruning" in the SynGO VU annotation tool, get displayed in QuickGO and AmiGO as "synapse disassembly/pruning", and not the regulation term. geneontology/syngo2lego_data_conversion#4
(I did not check whether this happens also for other SynGO "regulation of..." annotations).
cc @RLovering

@cmungall
Copy link
Member

We have two repos

  1. https://github.com/geneontology/syngo2lego_data_conversion "A repo for conversion of syngo JSON to GO-CAM OWL", last commit by @ftwkoopmans in March
  2. https://github.com/geneontology/syngo2lego "scala app for converting SynGO JSON to OWL (ttl) for loading into noctua" last commit by @dosumis in January

Both of these appear to do the same thing judging by the description

@dustine32 I believe that you use 2? Can you shed any light on this.

We should only have one repo and one codebase for performing this task, one should be marked deprecated, the other should have the tickets transferred.

@dosumis
Copy link
Contributor Author

dosumis commented Aug 23, 2018

  1. is a simple JSON schema checker for SynGO JSON. This is a useful first step before running a parse with the code in 2.

I posted here because the syngo repo is private & it's not clear to me where the required work will happen. Could be repo 2 (above) - or, could be mostly in the SynGO curation tool.

@dosumis
Copy link
Contributor Author

dosumis commented Aug 23, 2018

@BarbaraCzub - @ftwkoopmans can likely explain the odd mapping.

@pgaudet
Copy link

pgaudet commented Sep 11, 2020

@dustine32 Howcould we fix those errors ?

@dustine32
Copy link
Contributor

@pgaudet Looks like these require some input from the SynGO folks to either change their data upstream and/or commit an updated annotation JSON file to https://github.com/geneontology/syngo2lego_data_conversion.

  1. Blank with/from col on IPI annotations - the curator needs to supply the target protein in a new field we'll need to add to the JSON schema file and then the https://github.com/geneontology/syngo2lego conversion code will need to parse it out and add it to the translated model.
  2. Unrecognized evidence code - As @dosumis suggested, SynGO has to decide what evidence code from our list of acceptable ECO codes (does this list exist?) should replace those invalid evidence codes. They could then update the data in the annotation JSON or send us an old-ECO-to-new-ECO table to use in the conversion code.
  3. Unmapped identifiers - This could simply be due to outdated annotation data using since obsoleted UniProt IDs. An updated JSON file with corrected or dropped annotations should fix this.

@pgaudet
Copy link

pgaudet commented Jul 4, 2022

Emailed Frank about IPIs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants