Open goodb opened 5 years ago
f/ @ukemi
Causal events that are not part of of the process should not be included in the model, at least as a first pass. If we are going to show upstream and downstream causal relations, it might be more useful so show the process.
See planning discussing document https://docs.google.com/document/d/1SDdlEhWnRc6OuhrfpkLUfK8GQbckbUkcLFOPFn1NaGg/edit @kltm and @balhoff we can also use this issue thread if you like.
Its now a very simple switch to turn on to test this idea from the converter's perspective. The main work here is in the Noctua client. Stopping any changes here until there is time/feedback from client dev.
Apologies for spam - clicked the wrong button and took a couple of tries to repair the damage.
I think we actually did this, but I'm not sure if all the technical work was completed.
@ukemi While I believe some of the conceptual technical work was done, I think there is still a fair amount of work to do for anything practically usable.
Thanks @kltm . I know that these bridges exist in the Reactome imports. For example R-HSA-1889955 (B3GAT dimers transfer GlcA to tetrasaccharide linker) bridges R-HSA-1971475 (A tetrasaccharide linker sequence is required for GAG synthesis) with R-HSA-2022870 (Chondroitin sulfate biosynthesis). R-HSA-1889955 is a step in R-HSA-1971475 that is upstream of a function in R-HSA-2022870. Ben did some fun queries for me back in the day, but I wasn't certain of the extent of this ticket. It is actually pretty cool. If it goes beyond just the Reactome imports, and encompasses better viewing of the linkages and extension to other models, maybe we should reformulate it or move it to a different project???? I assume this code will remain in future imports.
(I'm @kltm -- edited above:)
@ukemi I think you're right that we might want to step back and consider the scope of what kinds of final products we want out of this. IIRC, we figured that we could stitch models together doing things like referencing "remote" entities to a model, but getting that into the clients and editors was still out a bit. As well, I know Ben did work making larger models from the individual ones; that's probably connected to what you're referring to.
I definitely can't do this as an editor. It was all part of the import.
_I know Ben did work making larger models from the individual ones; that's probably connected to what you're referring to__ But in the above case the linking reaction is from two different models. But I have no idea how he did it under the hood.
HI team! I think @kltm sums it up correctly. We could do anything with the import, but stopped work on this awaiting client support to follow. The linking example referenced high above in this thread was generated by adding in the subPathwayOf links from Reactome to connect multiple models together by reference. Hope all is well in GO land.
Hey @goodb , great to hear from you! Thanks for clarifying. Hope things are going well with you. So @kltm should we tweak this and move if to a more global repository or should we leave it here and try to make it a specific task for the Reactome2GO work? Happy to go with whatever you think is best.
@ukemi I think it depends on what's wanted. There is definitely the idea of having linked models floating around, but things like how to edit, display, query, etc. for users has not really been fleshed out. I think this should probably be scoped to the given Reactome2GO task, and a larger discussion can be opened up and pursued elsewhere.
I think this should probably be scoped to the given Reactome2GO task, and a larger discussion can be opened up and pursued elsewhere.
A managerial issue is how to do this Reactome-specific work in a way that maximizes the odds that whatever we come up with will be more generally usable. It makes sense to work for now specifically on connecting Reactome-derived GO-CAMs - how can we use @kltm et al. for sanity testing to keep us going in broadly useful directions?
At least for now we do have the linking references from model to model. So from that perspective, this is already in place. Perhaps this ticket would be to allow a user to query across models based on conserved reactions. I'm not exactly where this would fit on the priority list, but I think that's the desirable outcome. It sounds like this is a project all in itself.
For edges between nodes in different pathways (nextEvent, PrevEvent) add these to a separate 'Bridge' model. Test how this can be used for cross-model queries in complete RDF store.
This can be used by @kltm and @balhoff to develop client code and reasoner code respectively.