Create an repository for Reactome models that would be immutable by curators

[ukemi]

On the Pathways2GO call May 27, we decided that the imported Reactome models and other imports should not be edited by curators. These models would be house in separate repositories where they would be immutable by curators and only be updated through the regeneration process at each Reactome release. ping @kltm This will be the paradigm forward for imported models.

[kltm]

To clarify a little of what is in my mind from the discussion during the call. A possible data flow, that could be followed for both reactome->go-cam and other "immutable" upstream sources (e.g. current syngo, other pathways databases), could be roughly as follows:

• every "immutable" upstream has it's own repository, similar to geneontology/noctua-models for easy history tracking
• when an upstream releases (or otherwise), it is passed through a (possibly GO) (possibly QC) pipeline and the product is place into the repository
  • possibly tagged
  • should produce reports and notes, also possibly in repo
• note that these models are marked as "immutable/fix/uneditable" and that minerva will throw an error when attempting to edit a model marked as such (as well, marking as such is not available through the usual API)
• with a TBD period, the models in these repositories are flushed into minerva, either with:
  • minerva reading from multiple directories (but only writing to one)
  • clobbering out the ones currently folded into noctua-models
• any models marked as production--including "immutable" ones, go through our system as normal, becoming part of the versioned data product that we produce

This would allow for the upstreams to have: 1) fairly independent lifecycles 2) to have built-in versioning and history (github).

[goodb]

Okay @kltm here you go. https://github.com/geneontology/reactome-go-cams Should I start making updates to that one or continue updating noctua-models with reactome changes currently bound for noctua-dev ?

[goodb]

@kltm @ukemi what project should this be in ?

[kltm]

@goodb It might be good to stick a pin in the home project for the moment. As the week progresses, we should have a better idea where we're at (hopefully). As far as the data flow goes, I think that's still TBD--what I said last week was a hasty proposal off the top of my head. I think, maybe, it goes one of two ways:

• minerva can handle multiple directories/sources, so there is no need to worry about "merging"
• there is some process, manual or automated, for folding these into the main noctua-models branches

Thinking about how these would mechanically work and how fiddly it would be to have to multiple branches running around, it seems like the former would be easier, although it would require more effort upfront. How does that sound to you, and would you like to talk about this a bit more on the software call (or some other time) this week?

[kltm]

@goodb Another, somewhat orthogonal issue, is how to mark models like this as "immutable" (or whatever we want to call it). Naturally, coordinating the decisions there with changes in Minerva.

Also, to answer your original question to me more directly, I think the "best" thing for the moment, given infinite time at your end, would be to update here, them clobber on noctua-models in a PR until we sort out some of the other issues outlined above.

[kltm]

Also also, it would be easy-ish to still stream these into the the triplestore and the /go-cam interface without going through the editorial system. To answer an unasked question, it would also be easy to turn these into JSON-response-like objects and create a set of static pages a la http://noctua.geneontology.org/workbench/pathwayview/?model_id=gomodel:5ed1aab700000024 and deliver them out of GitHub pages, as there is now a separate repo.