search

geneontology / noctua

Graph-based modeling environment for biology, including prototype editor and services
http://noctua.geneontology.org/
BSD 3-Clause "New" or "Revised" License
36 stars 13 forks source link

Add ability to create and reuse generic templates for core modules #254

Open cmungall opened 8 years ago

cmungall commented 8 years ago

Proposal for how this would work.

Template/Prototype models

For this component no particular features in Noctua are required beyond having the ability to edit annotations with arbitrary annotation properties in the Model/edit annotations tab. However, having some special purpose widget for doing this will make it more obvious.

Caveat: if we make the link between the model and the BP an OPE, then we are forcing punning. This may or may not be desirable. Another option is that this option creates a class axiom

BP SubClassOf has-prototype value gomodel;NNNN

But thus far the minerva API doesn't support this and it takes Noctua beyond a pure ABox editor. This is probably overmodeling here. Best to stick with direct triple, either OPE or APE.

Dropping in a template

This will require some additional widgetry or UI futzing.

Example of how this might work:

One possibility is to simply copy references into the model without making new individual IDs. But we would have to make sure that the shadow is not editable, or the union of all models will have conflicting statements.

One fun way of doing this would be to show the list of all possible templates graphically. Imagine even having faceted browsing of all thumbnails... best for a new enhancement ticket. One possibility is to put multiple templates into the same model (kind of like a Stencil panel in tools like OmniGraffle)

Modeling of variability

Example: a MAPK cascade where the 4th MAPK activity is optional.

I think it easiest to avoid these situations by making two distinct templates. We can imagine combinatorial explosions. But cross this when we come to it

cc @dosumis @ukemi

dosumis commented 8 years ago

Quick comment: I think it's a great idea to have a pattern system for LEGO, but I want a clearer sense of the boundary between ontology patterns and LEGO patterns.

On Thu, Dec 10, 2015 at 1:16 PM, Chris Mungall notifications@github.com wrote:

Proposal for how this would work. Template/Prototype models

  • Each template would live in its own model
  • The model will be like any other model, but will include some additional owl:annotation that indicates its template-like status
    • a template model will typically not fill in enabled_by since the intent is to reuse in any species
    • at some point we will want to explore filling in general and ancestral (PTN) gene products, but this is best discussed in a distinct ticket
  • Edges should have evidence in general, but these will typically be non-experimental?
  • A template is always associated with a biological process
    • Examples: nuclear import, MAPK cascade
    • Use RO:0002214 'has prototype' to connect. E.g. "nuclear import" has-prototype gomodel:nnnnnnn (but see caveat below)
    • Cardinality TBD. having max 1 prototype for each process has some advantages

For this component no particular features in Noctua are required beyond having the ability to edit annotations with arbitrary annotation properties in the Model/edit annotations tab. However, having some special purpose widget for doing this will make it more obvious.

Caveat: if we make the link between the model and the BP an OPE, then we are forcing punning. This may or may not be desirable. Another option is that this option creates a class axiom

BP SubClassOf has-prototype value gomodel;NNNN

But thus far the minerva API doesn't support this and it takes Noctua beyond a pure ABox editor. This is probably overmodeling here. Best to stick with direct triple, either OPE or APE. Dropping in a template

This will require some additional widgetry or UI futzing.

Example of how this might work:

  • A menu item "Add template" with sub-items being each model/BP, where these are associated as above
  • Selecting one performs a partially deep copy of the original model into the current model
    • don't clone entities like PMIDs
  • The copied model should have annotations that retain memory of the fact that this was copied
  • We may want to prohibit the user from editing these

One possibility is to simply copy references into the model without making new individual IDs. But we would have to make sure that the shadow is not editable, or the union of all models will have conflicting statements.

One fun way of doing this would be to show the list of all possible templates graphically. Imagine even having faceted browsing of all thumbnails... best for a new enhancement ticket. One possibility is to put multiple templates into the same model (kind of like a Stencil panel in tools like OmniGraffle) Modeling of variability

Example: a MAPK cascade where the 4th MAPK activity is optional.

I think it easiest to avoid these situations by making two distinct templates. We can imagine combinatorial explosions. But cross this when we come to it

cc @dosumis https://github.com/dosumis @ukemi https://github.com/ukemi

— Reply to this email directly or view it on GitHub https://github.com/geneontology/noctua/issues/254.

cmungall commented 8 years ago

Good question.

I had thought initially there would be a clear separation between the two. Broadly speaking, the 'slots' for LEGO modules are intended to be filled by gene products, and ontology patterns are filled by ontology classes. But this isn't always so clear, e.g. signal transduction.

We can imagine something like this. The ontology group creates the generic model for MAPK cascade. They owl:annotate some of the individuals to indicate that these are representative values for 'slots' that are intended to be filled in when anyone uses this model as a prototype (this can be done with the generic annotation editor right now). Constraints could be added here too. In this case, for a 3-step cascade there would be 3 slots.

Then we can imagine the derive-model-from-prototype option popping up with an autocomplete box for every such annotated slot (here the curator would enter 3 kinase gene products). I think this is what Seth means by super-grebe. Of course, the derived subgraph could be further modified.

We can also imagine model-level owl:annotations back on the generic model that specify how textual metadata such as labels could be generated (e.g. using the same syntax as DOSDP). However, there is not much requirement for labels on subgraphs in Noctua. I think people will want to see textual descriptions generated, but I think this will need to be more sophisticated (will need a separate ticket for this).

Bottom line is that we will be moving away from extensive pre-composition in the ontology, which dictates a distinct (but overlapping set of requirements).

cmungall commented 8 years ago

@dosumis some of the ongoing work in the synapse project would make great examples here. Do you plan to create any prototypical models in Noctua for classes like 'dense core granule exocytosis'?

dosumis commented 8 years ago

Doubt there will be time in the first round of this work (up to end of May). But we've discussed the possibility of including a LEGO component in an application for renewed funding for this work. For that we'll need to work up some examples of how it can work. This could include some prototypical models. Mainly we need a clear description of how the LEGO approach fits with Term enrichment.

On Fri, Dec 11, 2015 at 6:17 PM, Chris Mungall notifications@github.com wrote:

@dosumis https://github.com/dosumis some of the ongoing work in the synapse project would make great examples here. Do you plan to create any prototypical models in Noctua for classes like 'dense core granule exocytosis'?

— Reply to this email directly or view it on GitHub https://github.com/geneontology/noctua/issues/254#issuecomment-164008015 .

cmungall commented 8 years ago

A naive attempt at neurotransmitter reuptake:

http://noctua.berkeleybop.org/editor/graph/gomodel:5667fdd400000476

Strategy for TE is in order of difficulty:

  1. Standard lossy GAF export
  2. As 1, but on-the-fly materializing of an "analysis ontology" using e.g. templates to make both long specific terms and smart grouping terms
  3. New algorithms that combine the semantic GO-like TE approach and network-based TE

3 is where we want to go but nothing exists yet

cmungall commented 8 years ago

Update on this:

I believe @kltm told me that it was possible to copy a template into an existing model, but I don't see this functionality. @ukemi are you aware of it?

ukemi commented 8 years ago

No, but I thought it was in the works.

kltm commented 8 years ago

I'm shooting for something working at the end of the week, but I'm getting caught up on a lot of little side adventures. The hard template marking part is done, now, essentially, it will be a workbench that does a play-forward of a templated model into the target model (very very similar to one of the paths forward in #37 ).

dosumis commented 7 years ago

Discussed in the GOC meeting in LA (2016).

For compound molecular functions at least, and possibly for some BPs, we will have combined design patterns / templates that share variable slots. In this model, a template will include slots to be filled with entities from a specified range. e.g. a generic receptor template would have slots for ligand and effector function. It should be possible to insert one or more templates into any LEGO model. Slot filling could potentially be done via a form. If so, we would need some generic way to configure a form from a template specification. Working out how viable this would be may require working through examples.

vanaukenk commented 2 years ago

@ukemi @vanaukenk will test copying a template model