Pipeline from Reactome about noctua HOT 17 CLOSED

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)

from noctua.

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

from noctua.

cc @guanmingwu

from noctua.

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 .

from noctua.

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

from noctua.

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

from noctua.

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

from noctua.

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 [email protected] 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)

from noctua.

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?

from noctua.

“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 [email protected] 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)

from noctua.

> In case this may be useful, our EBI group recently just developed a
> graph database for Reactome:
> 
> http://www.reactome.org/pages/documentation/developer-guide/graph-database/
> 
> The views in your two web applications are very similar to Neo4j graph
> database models to me. So probably working with our graph database may
> simplify things for you? Just a wild guess.

For the direct Noctua communication options, I don't think it would matter too much what your backend is as you'd be constructing the objects to send over the wire yourself; although, you might find it easier to work with.

For batching, I think it's a modeling issue that would require a few cycles with Chris to work out the details. The graph database may make it easier to explore the source data to begin with though. Chris could probably speak more to that.

I'll copy this into the ticket to make sure that information is captured.

from noctua.

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: #37 (comment))
• fix (or create, I forget) json model import into noctua
  • like the syngo import, initial mark as delete

from noctua.

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.

from noctua.

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.

from noctua.

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.

from noctua.

@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

from noctua.

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

from noctua.