Inputs with a contributes_to MF need to be associated with the MF, not the GP about gocamgen HOT 9 CLOSED

I see what's going on here. I default any relation that I haven't specifically handled (right now "contributes_to" is in this bucket) to have extensions hanging off the annotated GP and not the primary term.

I'll start to organize this behavior according to certain relations.

Thanks for spotting this @vanaukenk !

from gocamgen.

@dustine32 - I've checked the latest models for mec-3 (WB:WBGene00003167) and the contributes_to annotation looks correct.

Also, wrt the self-referential annotation extension, this is actually a case of transcription auto-regulation, so it's okay to have the same ID as the subject of the annotation as well as the annotation extension. @ukemi I think this is in keeping with your explanation above that self-referential extensions are likely cases of some form of auto-regulation.

I'm closing this ticket for now, but we can re-open, if need be.

from gocamgen.

Thanks @dustine32
Annotation extensions were supposed to modify the GO term, so we should be safe always hanging them off the term.

from gocamgen.

Ah! Then I will switch it to default off the GO term. Thanks for clarifying!

from gocamgen.

@vanaukenk @ukemi Question about one of the has_input annotations in this model's annotation set. There's one that looks to be circular:

WB	WBGene00003167	enables	GO:0000977	PMID:1361171|WB_REF:WBPaper00001664	ECO:0000314			20120723	WB	has_direct_input(WB:WBGene00003167)

Meaning the extension is saying the same gene has_input of itself. Just wanted to double-check that this is valid and should be translated in the model. Is this OK?

from gocamgen.

I don't know the specifics here, but I know that I have run into some cases like this for things like autophosphorylation. I'm not sure from a conventional annotation if we can distinguish a gene product that acts on itself from a gene product that acts on another molecule like itself. These kinds of questions are popping up in other areas of modeling too.

from gocamgen.

@ukemi @vanaukenk I forgot to come back around to the WBGene00003167 enables GO:0000977 has_direct_input(WB:WBGene00003167) self-referencing extension issue on today's call. For now, after looking at this example with @thomaspd , I just removed the simple restriction code in 114eb11 so that these extensions will get expressed.

from gocamgen.

Based on the discussion on yesterday's call, I think this is the best we can do for now. We just have to assume that these are functions that are 'auto-catalysis' or are curation mistakes.

from gocamgen.

@vanaukenk @ukemi Well unfortunately it seems we lost extensions in the latest batch of models pushed to noctua-dev. I already know the reason why (ontobio upgrade moved around the annotation data structure) but it's a great excuse for me to spend time writing tests for these specific features.

For this issue, I'll create a static (not subject to regular GO release changes so always has extensions) GPAD file with just the WB:WBGene00003167 annotations. The test will create the model object and assert that the term individual has a has_input edge.

from gocamgen.