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

Molecular Events should not be entities #119

Closed
ukemi opened this issue Dec 8, 2020 · 10 comments
Closed

Molecular Events should not be entities #119

ukemi opened this issue Dec 8, 2020 · 10 comments

Comments

@ukemi
Copy link

ukemi commented Dec 8, 2020

In the new Reactome import, I just noticed that when there is a Molecular Event in a model it shows up as an entities in the annotation preview. This is not correct from my understanding of how molecular events are supposed to work. They are supposed to be occurents.

@ukemi ukemi changed the title Molecular Events should not be enablers Molecular Events should not be entities Dec 8, 2020
@ukemi
Copy link
Author

ukemi commented Dec 8, 2020

gomodel:R-HSA-71240

@ukemi
Copy link
Author

ukemi commented Dec 8, 2020

These appear in the annotation preview. It might be a bug in how the preview is generated or it might be a bug in how the molecular events are represented in the model?????

Example:

Molecular Event | part_of | GO:0006739 | Reactome:R-HSA-71240 | imported information used in automatic assertion |   |   | 20201124

@goodb
Copy link
Contributor

goodb commented Dec 8, 2020

weird.. tagging @balhoff and @dustine32 .

@balhoff
Copy link
Member

balhoff commented Dec 8, 2020

My guess: these events are parts of processes in the model. That's fine. The GPAD export looks for things that have 'part of' relations to GO term instances, since 'part of' is one of the valid annotation relations. There is a filter which gets rid of things we don't want to output as annotation subjects:

https://github.com/geneontology/minerva/blob/809417340682bb982ab5770fae9c98635553667c/minerva-converter/src/main/resources/org/geneontology/minerva/legacy/sparql/gpad-basic.rq#L66-L73

The molecular event type needs to be filtered here. It's possible that some of Ben's newer work has added some kind of property to OWL classes which we can positively identify as valid annotation subjects; I'm not sure.

@ukemi
Copy link
Author

ukemi commented Dec 8, 2020

The molecular events are definitely occurrent parts of the processes in the model. Seems like we might be able to do this in a better way than a static filter? We really need to reexamine the methods for the GPAD output.

@ukemi
Copy link
Author

ukemi commented Dec 8, 2020

So summary take: The models are correct and this is a bug in the GPAD generator. Molecular event needs to be one of the things we filter out of the GPAD. It's weird that I hadn't noticed this before. I suspect I checked the anotations before we implemented the molecular events.

@balhoff
Copy link
Member

balhoff commented Dec 8, 2020

Seems like we might be able to do this in a better way than a static filter?

Yes, if all gene classes had some kind of annotation property that was available to the Minerva SPARQL query. I say "annotation property" because it also needs to distinguish them from their superclasses (can't just allow subclasses of 'information biomacromolecule').

@goodb
Copy link
Contributor

goodb commented Dec 9, 2020

@balhoff likely related to geneontology/go-ontology#19960 .
Molecular Event is still being built as part of reactor. I guess the sparql gpad code doesn't know what it is and is missing the filter becausee its asserted as a superclass of molecular function.

@ukemi
Copy link
Author

ukemi commented Jan 16, 2025

Seems like this is now fixed. @dustine32

@dustine32
Copy link
Collaborator

@ukemi Correct! The observed behavior back in 2020 was Molecular Event as subject in GPAD preview annotations for pathway R-HSA-71240. In Noctua prod, the GPAD export does not currently have these "Molecular event as subject" lines. I'm suspecting the minerva GPAD export code/query was properly updated to filter these out and therefore this ticket can be closed.

@ukemi ukemi closed this as completed Jan 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

4 participants