Pipeline from Reactome

[kltm]

Pipeline from Reactome. Ideally, the user is able to just input an ID somewhere and have the converted model loaded/merged in.

Questions about exactly when in the process this would be best.

[cmungall]

Instructions for running the service here:

https://github.com/cmungall/pl-sysbio

This will need iterative refinement with Huaiyu and Peter D once we integrate the service in.

Probably the best place to integrate is when you are working with a (possibly empty) model. Under a plugins menu or import menu or similar in Noctua the user would see "import from Reactome". They would enter an ID (in future, possibly autocomplete using reactome services). The service spits back OWL. This probably has to go via Minerva for the axioms to be merged, since the client is ignorant of OWL, cc @hdietze .

Another route would be for the user to upload a BioPAX file. The flow is essentially the same - the biopax is sent to the service, it returns owl to be merged into the model.

(whilst in theory any biopax should work, reactome is most well behaved)

[kltm]

If your service is more generally applicable, another option would be to turn it into a webapp and federate it with Noctua.

[kltm]

cc @guanmingwu

[kltm]

Meeting notes:
Data API access may be much faster and more detailed.
Also thinking about a file dump from the Reactome pipeline.
It may be easiest to have a light exchange format, going both directions; ideally this format is light and easily generated, something short of OWL, but less abstract than a graph. Will need to talk to
Will also want to include a separate export ticket.
@cmungall .
Also @guanmingwu .

[cmungall]

We should be able to take in any OWL Abox from the web, and optionally shallow copy/clone

[kltm]

I would agree, but I was thinking about a lightweight exchange format for: 1) people not wanting to use the OWL API to produce a file that can be used for bulk upload and 2) a file that is easily parsable and usable from JS as that is our current scripting language. Pondering that, I suppose that the graph response format would probably fit the bill.
(Although, our libraries should still work in rhino, I think it might get weird to use the OWL API from in there (although I've never tried)).

[cmungall]

Example Minerva-json:

https://raw.githubusercontent.com/cmungall/reactome-in-lego/master/Homo-sapiens/DNA_Damage_Reversal.json

Is there a secret power-user option to bring this in to a blank model? The desired behavior is to do the equivalent of a clone (ie new Individual IRIs would be minted, as I am the external provider I should not be in the business of minting stable model instance IDs)

More examples here:
https://raw.githubusercontent.com/cmungall/reactome-in-lego

Some may be massive

What would be awesome would be a js app I can run locally to do a quick visual inspection of my json

[guanmingwu]

Hi Chris,

As long as there is a format specified, we can bring it in for Reactome pathways :)

Thanks,

Guanming

On Apr 7, 2016, at 5:53 PM, Chris Mungall notifications@github.com wrote:

Example Minerva-json:

https://raw.githubusercontent.com/cmungall/reactome-in-lego/master/Homo-sapiens/DNA_Damage_Reversal.json https://raw.githubusercontent.com/cmungall/reactome-in-lego/master/Homo-sapiens/DNA_Damage_Reversal.json
Is there a secret power-user option to bring this in? The desired behavior is to do the equivalent of a clone (ie new Individual IRIs would be minted, as I am the external provider I should not be in the business of minting stable model instance IDs)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #37 (comment)

[cmungall]

Great!

We should probably split this ticket. It originally started out with the requirement to bring in an existing reactome pathway into noctua, for exploratory purposes. What should the biopax<->lego mapping look like? What is hard to map? Do the start and end boundaries line up? What would we do differently if modeling using the LEGO approach?

that's what the static json dump is (in fact I think the version of reactome I used is a few iterations old, but the first step is to see if it works at all)

After your discussion with Seth at OHSU I think we can start moving along in parallel on the next phase, which could involve more connections at the UI level, bidirectional interchange (depending on resources).

When you say Bring in, do you mean as a means of importing into Reactome?

[guanmingwu]

“Bring in”: I mean to use this as a file format. We in the Reactome will export all pathways for you in this format.

Guanming

On Apr 8, 2016, at 10:48 AM, Chris Mungall notifications@github.com wrote:

Great!

We should probably split this ticket. It originally started out with the requirement to bring in an existing reactome pathway into noctua, for exploratory purposes. What should the biopax<->lego mapping look like? What is hard to map? Do the start and end boundaries line up? What would we do differently if modeling using the LEGO approach?

that's what the static json dump is (in fact I think the version of reactome I used is a few iterations old, but the first step is to see if it works at all)

After your discussion with Seth at OHSU I think we can start moving along in parallel on the next phase, which could involve more connections at the UI level, bidirectional interchange (depending on resources).

When you say Bring in, do you mean as a means of importing into Reactome?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #37 (comment)

[kltm]

Talk with @guanmingwu and @cmungall

We've decided that the best way forward, so that we can easily iterate on the modeling and figure out any problems would be to:

• base ourselves (for the time being) on @cmungall json models (see: Pipeline from Reactome #37 (comment))
• fix (or create, I forget) json model import into noctua
  • like the syngo import, initial mark as delete

[kltm]

Well, for a very first pass and to get us started with whether the current conversions are satisfactory, it turns out we have a way of viewing JSON-ified models right now, with a few caveats:

• they cannot be edited
• one cannot use workbenches on them

Currently, there are no labels, but this seems to be caused by (incorrectly) using rdfs:label as an annotation rather than label within type (ex: https://github.com/berkeleybop/bbop-graph-noctua/blob/master/tests/minerva-09.json). (pinging @cmungall for this)

To access this functionality, copy a JSON-ified model, go to http://noctua.berkeleybop.org, select "Danger Zone" from the menu at the top, copy the JSON-ified model into "JSON Debugging", and click [Load]. There is no need to be logged in.

[goodb]

I took a first pass at converting Reactome Biopax to the GO-CAM structure. The models are accessible for the moment at noctua-dev. For example, the Glycolysis pathway (Reactome view) or the Apoptotic Execution Phase (Reactome view) . Feedback about the mapping would be most appreciated. cc @ukemi @cmungall @kltm @thomaspd @yy20716 @vanaukenk

The mapping rules so far are described in a google doc.

[goodb]

The generated Reactome models on noctua-dev and the documentation for the mapping rules have been updated. Would be great to get some feedback on this. See e.g. updated glycolysis pathway. Note that its pretty big and is definitely best viewed using the Pathway View workbench.

[vanaukenk]

@goodb - I'm doing some noctua tracker cleanup.

Would you like to leave this ticket open or close it and note that this work now has its own repo: https://github.com/geneontology/pathways2GO

[goodb]

@vanaukenk I think it would be fine to close this ticket for now. If we do get serious about integrating reactome models into the production workflow that will be its own new project. Closing.