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

Enable relations across models #592

Open
goodb opened this issue Dec 14, 2018 · 8 comments
Open

Enable relations across models #592

goodb opened this issue Dec 14, 2018 · 8 comments

Comments

@goodb
Copy link

goodb commented Dec 14, 2018

Use case description:
As an example, a curator has a molecular function node in their model and they want to create a 'causally upstream of' edge between that node and a biological process node that already exists in another model.

Curator needs to be able to find the target node in the other model, create the edge, and be able to view content from the other model in the context of what they are working on.

@alanbridge
Copy link

cool sounds a bit like pathway collages! https://www.ncbi.nlm.nih.gov/pubmed/?term=27964719

@cmungall
Copy link
Member

(did you mean to say biological process, or MF?)

There are perhaps some sub-use cases here it may help to enumerate as they may require different approaches

  1. The curator is trying to make one large model and is partitioning into sub-models as this is cognitively/visually easier to deal with, but the intent is to treat as if this were a single model. As such, the same semantics apply, i.e. no crossing between species unless this is explicitly a host-symbiont type of model. Connections would have to backed by evidence as they are now.
  2. The curator is curating potential areas of connectivity or cross-talk between independently curated models. We would still want no species crossing, but evidence may be weaker.
  3. Curator or researcher is interested in discovering and exploring links between models. Here we may want to suggest links based on either something as simple as a shared specific ontology class (e.g. a connecting reaction, or a shared broader cellular process) or graph/semantic matching. This may be more like the collages. The goal is discovery so we may want to allow species crossing. We generally don't want to persist but if a genuine connection is discovered that can be backed up with evidence, this could be saved back.

I'm not sure if this precisely maps to curators ways of thinking, it would be good to make some concrete examples of where this is desired, with PMIDs.

It's important to think about the meaning of these linkages. If the intent is that the semantics of an inter-model MF-MF link is the same as intra-model, then obviously they must be the same species (for non host-pathogen). But we have subtler cases, as we may have models at different levels of granularity or "prototypicality". In a single model we would not connect a neuronal process to a liver process, even if the same underlying modules are used (unless we were explicitly modeling some nervous system-liver interaction). I think we want to apply the same restrictions across models, and if you need an analogous model that deploys some of the same components then there would be a clone/copy operation.

@kltm kltm changed the title enable relations across models Enable relations across models Dec 14, 2018
@goodb
Copy link
Author

goodb commented Dec 15, 2018

@cmungall when I wrote that, I was thinking of the MF - BP connection made in this model: http://noctua.geneontology.org/editor/graph/gomodel:5b91dbd100000506 (which I have used in my recent talks). Generally speaking I find MF-BP connections a little weird (seems like MF-MF where MFs may be part of different BPs would generally be more useful), but I see curators doing that often. I agree that it would be very useful to have some curator driven use cases spelled out here - ping @vanaukenk .

The other use case emerging from my work on the Reactome import are the connections that they make between reactions (MFs) in different pathways. One reaction can be part of one pathway but be e.g. causally downstream of a reaction in a different pathway. As long as we separate pathways into different models (which I think is a good idea unless we want to end up with one giant one) we currently have no way of capturing those connections.

I'd suggest splitting your bullet 3. into the curator use case and the researcher use case (and in fact putting the researcher use case into a different issue on a new project made specifically for end-users, not curators). I'd restate something like this:
3a. Curator is building a model and desires to be aware of related models that may be used to extend or minimally inform their current model. (Avoiding potential duplication of effort and increasing efficiency). 'Find' operations might be made node specific e.g. a 'show related nodes in other models' button. Find could be followed by options to link the source node to the target node (with alerts regarding semantic alignment (species, cell, other context)) or to clone and import the target content into the current model (with appropriate provenance attached).

@vanaukenk
Copy link

@goodb - thanks for adding this ticket.
It makes sense to me to link BP-BP and/or MF-MF when linking models. I think we could come up with some curator-drive use cases (already have some in mind) that we could work on and discuss on future calls.

@ukemi
Copy link

ukemi commented Dec 17, 2018

Ras-Raf to MAPK would be an interesting example. What do we do with the linking MFs? Are they part of more than one pathway? I think so.

@pgaudet
Copy link

pgaudet commented Jun 17, 2022

This is a functionality that Colin and Swiss-Prot curators would find very useful.
Copying selected activity units from models could be an alternative way to address this.

@kltm
Copy link
Member

kltm commented Jun 17, 2022

@pgaudet Could you explain the use case for the SP curators in a little more detail here? Is it included in @cmungall 's list above, or is there something else going on? Cross-model linking is potentially a very "disruptive" change, so I'd like to understand if there are alternative paths rather than declaring it as a requirement upfront. Specifically, I'd like to understand the desired workflow or type of curation needed and then work backwards to what an appropriate architecture or tooling might look like (before getting to how much effort might be involved, priorities, etc.).

Additionally looping in @balhoff and @thomaspd .

@thomaspd
Copy link

The main idea is to modularize the models as biological units, so that we can "reuse" the modules in models of larger biological processes. This will reduce redundancy among models, avoid unnecessary curator work in re-creating the same module as part of different BPs, and ensure that updates to a module won't require manual updating in any larger model that refers to them.

I will work with @pgaudet and the Swiss-Prot team to get some examples that illustrate what they want to do, and some visuals that might give us a starting point for discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants