Open suzialeksander opened 6 years ago
Is this a question about the inferred GPAD output? As in you want to suppress the CC annotation that is being generated by the GPAD inference?
Yes, exactly. Is there any way to do that?
I tried to think of some tricks you could do with leaving off evidence on the edge to 'vacuolar lumen', however I think that would also remove the term from the annotation extension in the MF annotation. I don't think there's a way to do this at the moment.
We should discuss this in a Noctua call @vanaukenk @ukemi.
@suzialeksander Is the issue that you don't want redundant annotations to the CC term in the GPAD output or that you don't want any of the CC annotations? If the former, then maybe that's something we could address with the GPAD output. Before we go further, though, I have some other questions about the model, so maybe we could Skype chat?
@suzialeksander - would you like to keep this issue open? If so, please just comment on what still needs to be addressed. Thanks!
Hi @vanaukenk, the issue was we don't want duplicate annotations in the GPAD. It seems from other conversations that duplicates may be an issue in the pipeline overall: with some annotations from Protein2GO, some from Noctua, and up to a month-ish delay before we can easily search models in https://geneontology.cloud/home, there may be curators inadvertently overlapping newly made annots. Not sure the best way to address this.
Bottom line, SGD policy is to not "stack" annotations- we want just 1 to 'vacuolar lumen', not a half dozen, so we don't want to import 'vacuolar lumen' if that's not what we wanted out of the model.
From conversations with @kltm it seems like this filtering has to be done on our end after we've retrieved the NOCTUA GPAD, does this sound correct? If there's no other way to do this and no plans this ticket can close. We really would like an upstream solution though.
I think we want to produce GAFs with non-redundant annotations, but we are not that close from doing it - we first need to define specs. How urgent is this for you @suzialeksander ?
At this moment, not very. We are waiting for our very first production models to make a full trip (NOCTUA -> display on SGD pages), but this is a valid concern due to multiple curators working on the same corpus of literature.
Maybe this is wishlist for now?
it's important enough that it's stopping us from adopting Noctua.
As a sort of follow up, is there any reason that another group would be propagating our Noctua annotations appearing in our (future) noctua_fb.gpad? Asking because Noctua is inferring other annotations that we don't necessarily want, this time a P: http://noctua.geneontology.org/workbench/annpreview/?model_id=gomodel:5b91dbd100001818
(Even though this isn't a production model, we wouldn't want the vague "macromolecule metabolic process" ).
Would be happy to talk to @vanaukenk about any of our models, there area few things we're definitely still working on.
Note: our handful of prod models are currently packaged in the Uniprot noctua gpad (https://github.com/geneontology/neo/issues/36); should be resolved soon.
If there is GOC-wide agreement then we can add this to the do_not_manually_annotate subset, otherwise the filter could be implemented on the SGD end
I would be comfortable as having this do not manually annotate.
I would also be fine with having a 'do not manually annotate' flag on terms like these, but if I'm reading the inference explanation correctly on this model, the macromolecule referenced in this annotation is actually the gene product, GPC1, since it is classified as an information biomacromolecule and is a participant in the metabolic process.
I don't yet see a ticket in the RO tracker for our has_participant proposal from Geneva.
@ukemi @cmungall - how would you like to proceed with that?
Can you make a new ticket on the RO tracker (there are existing tickets but they are tied up with other things, I will link them)
Okay, just to be sure, this is what I have from the whiteboard in Geneva:
has participant proposal
has participant -has primary input or output NEW --has primary input NEW --has primary output NEW -enabled by (new parentage) -has input --has primary input NEW -has output --has primary output NEW functionally related to -enabled by
The 'primary' terms still need definitions.
https://github.com/oborel/obo-relations/pull/291
I think the best we can do for now with the primary terms is to create a subjective distinction of participants. The primary participants are those that are the focus of the occurent. For example in named processes, they are the participants that are specified in the label. Do we really want these for Noctua or will they only be used in the ontology?
Thanks @ukemi If you have time to go over that pull request, that'd be great.
@suzialeksander Yes, I'd be happy to go over models with you some time. Let's set up a time after the holidays.
It is one that was added by @cmungall in Geneva.
Created http://noctua.geneontology.org/workbench/noctua-form/?model_id=gomodel%3A62b4ffe300002236 as a reference for this ticket.
Note to self- we made the desired annot here in P2GO so this model can be discarded.
Bumping as this probably is an issue in the SGD import, discussed after Feb 8 Noctua outage and on a Feb 9 call with @dustine32 @kltm @balhoff @vanaukenk
http://noctua.geneontology.org/editor/graph/gomodel:5b91dbd100000065
In this model, I'm trying to state the MF occurs_in the GO:0005775 vacuolar lumen as an an extension (in Protein2GO under PMID:29514932). We don't want to add a separate CC annotation, necessarily: in the scenario where we have a dozen annotations to "cytoplasm", we don't want to be forced to add "cytoplasm" every time we make a F annotation as well.
Is there a way to state
without adding