You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to specify/confirm the goals in terms of the GO pipeline for the GO-CAM models generated from Reactome.
One possibility could be:
Upon approval of the conversion rules (which I believe is pretty much done), we declare the generated models as uneditable (set template flag as true) and move them from dev into the Master/production collection.
Whenever Reactome releases an update, these models will be purged and re-added to the Master collection.
Adding to the master branch will mean that these models will appear in rdf.geneontology.org and other output pipelines from GO Central. This also implies that the Reactome Entity Ontology gets loaded into rdf.geneontology.org - likely meaning that it becomes a stable entry in the go_lego import collection. This may also have implications for Reactome GPAD - e.g. if we generate GPAD for these models as part of the standard GO Central protocol, we want to avoid redundancy with GPAD submitted from Reactome - especially if they decide to use the GO-CAM-generated GPAD.
One comment about 1: I think this would be better as a different type of flag than template. In the case of templates, they can be edited; for this, I think that minerva should deny all modification attempts (which raises questions about automated layouts...)
As discussed on the call Sept 5. The plan would be to drop and reload these models at each Reactome release. We will not try to perform any type of diff on the Reactome file. These files will also be used as the annotation source for the Reactome GPAD/GAF upon the completion of #52 to satisfaction. This may also impact a larger discussion about refining the GPAD output from models in general (@vanaukenk and @balhoff ). As @kltm points out above, we would also need a way to lock these models from editing (but allow copying?), but this raises questions about the default layout and whether changing the layout is considered an edit. I don't think changing the layout should count but I don't know what things are separable.
For the time being, the protocol is established. Models will only live on dev and will be updated manually. This is what we will go with for the purpose of the manuscript.
If we decide to spend effort including these models amongst the others, that will be added into a separate, new project.
We need to specify/confirm the goals in terms of the GO pipeline for the GO-CAM models generated from Reactome.
One possibility could be:
Adding to the master branch will mean that these models will appear in rdf.geneontology.org and other output pipelines from GO Central. This also implies that the Reactome Entity Ontology gets loaded into rdf.geneontology.org - likely meaning that it becomes a stable entry in the go_lego import collection. This may also have implications for Reactome GPAD - e.g. if we generate GPAD for these models as part of the standard GO Central protocol, we want to avoid redundancy with GPAD submitted from Reactome - especially if they decide to use the GO-CAM-generated GPAD.
@kltm heads up - intertwingled with geneontology/noctua#624 and I suspect other pipeline considerations.
The text was updated successfully, but these errors were encountered: