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

Define stable protocol for pipeline #68

Closed
goodb opened this issue Aug 23, 2019 · 3 comments
Closed

Define stable protocol for pipeline #68

goodb opened this issue Aug 23, 2019 · 3 comments
Assignees
Labels
software work here is writing code

Comments

@goodb
Copy link
Contributor

goodb commented Aug 23, 2019

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:

  1. 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.
  2. 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.

@kltm heads up - intertwingled with geneontology/noctua#624 and I suspect other pipeline considerations.

@kltm
Copy link
Member

kltm commented Aug 29, 2019

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...)

@ukemi
Copy link

ukemi commented Sep 5, 2019

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.

@goodb
Copy link
Contributor Author

goodb commented May 9, 2020

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.

@goodb goodb closed this as completed May 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
software work here is writing code
Projects
None yet
Development

No branches or pull requests

4 participants