Add new ontologies

[elserj]

Figure out how to add PO, TO, EO to Noctua.

I think I need to add them to "ONTOLOGY_LIST" in startup.yaml and rerun Minerva.

There may be some needed work to modify the left sidebar to make it not specific to GO.

Thoughts, @kltm?

[kltm]

Well, there is already a variable in startup.yaml for non-GO specific modes for NOCTUA_CONTEXT: "open" (as opposed to "go" (default) or "monarch").

That said, there is various GO-ish hooks that will be here and there. With future refactors (e.g. all "apps" as plugins) that will be cleaned-up.

[elserj]

So, I'm confusing myself a bit on how we want/need to modify this for us.

If I change NOCTUA_CONTEXT to open, the "Add annoton" section in the editor disappears. Trying to follow the code, this appears to be by design (changing "noctua_minimal_p" to true). I think can add new annoton text inputs in templates/noctua_editor.tmpl, but then need to add corresponding sections to js/NoctuaEditor.js similar to "annoton_mf_auto" and others. Does this sound about right?

Do I even want to do it this way? Maybe just leave it as "open" and not have that section of the sidebar?

I guess I'm saying I can use some direction on what to change for our version.

I have changed it so that it loads planteome.owl with our ontologies, although I came across something that may be a bug. Having multiple lines in the "ONTOLOGY_LIST" section in startup.yaml causes minerva to fail. I ended up creating a new planteome_noctua.owl file and added go-lego.owl to it to get it to load.

[kltm]

That is correct open makes no GO assumptions and it reverts to (almost) being just a graph editor with arbitrary ontologies.

I'm not sure what changes you want to see in your version, so it's a little hard to give guidance. It might be better to have a call at some point or to make sure we overlap when we're in Corvallis. Maybe I could come up a day early or something.

That ONTOLOGY_LIST thing is possibly a bug due to parameter passing in the gulpfile (or, less likely, in Minerva itself). We can explore that; you seem to have found a usable workaround.

[jaiswalp]

We are looking at adding the following ontology classes in addition to the existing three GO classes (default).

plant anatomical entity (PO plant structure development stage (PO) Plant Trait Ontology (TO) Plant Environment Ontology (EO)

@elserj please confirm.

[elserj]

I guess the way that I'm inclined to go is that we have a new context "planteome" where the sidebar will have the 3 GO classes (aspects?) as well as the 2 from PO and then TO and EO, don't know/think we need more than that.

Looking through the code, it looks like this should be possible by adding more "annoton_XX_auto" bits in NoctuaEditor.js. Just wondering if this is a rabbit hole I want to go down myself and am I thinking clearly about how to go about this.

[kltm]

It's a little more complicated than that, and gets into the modelling of what you are doing. The three GO classes are pretty much what defines an "annoton" and how it interacts with minerva. The open mode drop it back to it's most basic operation. At this point, adding a new context would likely be a poor idea. We are on our way to removing some of the legacy code and getting a bit of a clean re-write for the graph editor. As part of this, the sidebar items would be reusable widgets (instead of the spaghetti there now for historical reasons) that could be configured about what labels and constraints were used and what part of the model that described.

Another way forward, for more simplistic modelling is to write your own plugin. However, if you are most interested in the graph editor at this point that's probably too much work.

[kltm]

Actually, to be a little more clear on this, modifying "annoton_XX_auto" bits actually is a rabbit hole, and one that has been done more than once against my will, creating a hideous hairball in there that is very tricky to maintain, much less understand. It can be done, but short of something critical, it should probably be avoided.

[elserj]

That's what I was afraid of. So, are you saying that eventually it will be possible to add our own widgets for our own ontologies easily? If that is the case, what can I do to help?

That probably won't be ready in that case before the Corvallis meeting, so aside from some possible theming, the interface will probably not change much.

Per the call this morning with @cmungall, I think I will focus on the planteome version of neo to get the genes we want loaded in. I believe that at this point the ontologies we want are loaded in, just not as easy accessible via the sidebar, so I think we are functional enough for the meeting if I can get the genes loaded.

[kltm]

Depending on the meaning of widget, yes, probably. I'm currently looking at using vue.js as the base for the UI portion rewrite of the graph editor, but react is also on the table (progressive versus complete rewrite). Any widget has to translate what it wants into a command stream for minerva (grossly: https://github.com/berkeleybop/bbop-manager-minerva/wiki/MinervaRequestAPI). You can prototype these now as a standalone "workbench".

[cmungall]

btw, Oryza genes are loaded in the GO noctua instance.

[jaiswalp]

How many? Possibly not updated with the new IDs, mappings and nomenclature

[cmungall]

Just the genes in the gramene oryza GAF (so no unannotated genes)