Some genes not available in autocomplete, symbol and id issues

[vanaukenk]

Hi - I'm unable to find a C. elegans gene, cyk-7, that I'm trying to annotate in Noctua.

It is not available in the autocomplete in the form or graph editor.

Here is its entry in our gpi file:

WB WBGene00015591 cyk-7 CYtoKinesis defect CELE_C08C3.4 gene taxon:6239 UniProtKB:P34325

That can be found here:
ftp://ftp.wormbase.org/pub/wormbase/species/c_elegans/PRJNA13758/annotation/gene_product_info/c_elegans.PRJNA13758.current.gene_product_info.gpi.gz

Is the C. elegans gpi file being loaded into NEO?

We have discussed a similar issue with another gene in a separate ticket, but I don't think this ever got resolved:

#580

[vanaukenk]

From @kltm

@vanaukenk Your issue is a separate one--the above issue is about the loader, your issue seems to be about being in NEO, which is seems to not be:

sjcarbon@moiraine:/tmp$:) wget http://purl.obolibrary.org/obo/go/noctua/neo.owl
sjcarbon@moiraine:/tmp$:) grep "cyk-7" neo.owl | wc
0 0 0
The source we have for you is

source: ftp://ftp.wormbase.org/pub/wormbase/species/c_elegans/PRJNA13758/annotation/gene_product_info/c_elegans.PRJNA13758.current.gene_product_info.gpi.gz
with the last load a few days ago. If your GP is less recent than that, we should open up a new ticket.

[cmungall]

Context geneontology/go-site#595

We switched to the WB GAF while these issues with the WB GPI were being sorted

This was the temp fix:
7ab68c9

It should be possible to revert the code now and provided no further issues with the GPI, all should go well

[vanaukenk]

Okay, thanks @cmungall and @kltm
Let's see how things go if we revert the code.
If any further issues come up with our gpi, let me know and we'll work to fix them.

[kltm]

The code has been reverted.
It will be updated once the code is either manually re-run or we get a NEO-only pipeline running (preferred).

[vanaukenk]

@cmungall @kltm
What is the estimated time-frame for each of the options:
"...the code is either manually re-run or we get a NEO-only pipeline running (preferred)."

[kltm]

@vanaukenk A few days to a week, I think.
We are currently having issues (starting very late December) with the loaders disconnecting. I'd like to look into that a little before retrying this load.

[Edit]
Actually, strike that--it will likely be this weekend as it's the only time I'll have to knock out the neo golr server (until we get the above pipeline changes done).

[kltm]

Looks like neo now has "cyk-7"; will go ahead with trying to get it through.

[kltm]

@vanaukenk Noctua should now have the fixed version of neo. Looking, you appear to now have several lovely cyk-7s to choose from. If this seems correct, please go ahead and close out the ticket.

[vanaukenk]

Thank you @kltm

Marie-Claire and I have tested a few genes and it looks like there may be varying behavior on what is returned depending on what genes we search for in the autocomplete and how many associated transcripts and proteins that gene has.

For example, 'cyk-7' and 'pal-1' , return all of the possible gene, transcript, and protein IDs no matter where we type in the gene name (although the order is different depending on where in the graph editor we input the gene name).

However, for genes like 'daf-4' with more transcripts and proteins than 'cyk-7' or 'pal-1', the WBGene ID is not returned when searching in the 'Add annoton' or 'Add function' box in the graph editor, nor in the Noctua form.

If we search for 'daf-4' in the 'Add individual' box of the graph editor, however, the 'daf-4' WBGene ID is at the top of the list.

At the moment, we are annotating to WBGene IDs, so would typically choose those IDs from the autocomplete list.

[kltm]

From discussion at the hackathon, I believe that @cmungall attempted to address this in c18d20f

[kltm]

Attempting rebuild of NEO now.

[kltm]

@tmushayahama I believe that there may be some improvement on this front now? At least for "ags-3" I seem to be getting an appropriate response?

[tmushayahama]

@kltm it seems like the problem still exists. I have created a related issue (geneontology/minerva#221)

[vanaukenk]

Closing this ticket, as I think the issue has been resolved.