Open jaiswalp opened 7 years ago
we want to get this ready by May 15 max, for showcasing at the GOC noctua jamboree June 1-5.
Well, the easiest would be to limit (or add) within the loaded ontologies--see startup.yaml ONTOLOGY_LIST and ONTOLOGY_CATALOG.
As well, there is a function in noctua/js/lib/noctua-widgetry/widgetry.js called add_edge_modal
that contains a hard-coded list for easy access for common GO relations. This is evil and created to meet an immediate deadline. At the very least is needs to be refactored to take a variable, but the way things are launched makes that irritating. The solution we're working towards is to have all of this information in the ontologies themselves.
https://github.com/geneontology/noctua/issues/392 https://github.com/geneontology/noctua/issues/414 https://github.com/geneontology/noctua/issues/165 https://github.com/geneontology/noctua/issues/129 etc.
Relationship collapsing similarly is listed in startup.yaml.
As we are training new folks, I am trying to limit their choices with top level slim relations and avoiding scope of making errors.
Minerva, on startup, returns a list of all known relations to Noctua, so you can get different choices there. For the day-to-day addition of relations, I'm afraid that switching the hard-coded list might be the fastest way. (And of course the ontologies/realtions that Minerva knows about must be reflect in any hard-coded interface.)
May 15 is ambitious, you will want to have a backup plan involving a cheat-sheet that people can manually look up.
@jaiswalp we can start working on this now. This will ultimately inform how we encode this in Noctua.
We want to do this in an ontology-driven way, but there are a lot of challenges here. For example, currently the plant EO is ontologically uncommitted. Are these qualities, planned processes (@pbuttigieg suggested this), ...? What are the relationship types that should be used to connect these? A lot of OWL modeling to be done...
Re: hardcoded list.
Noctua presents the user with a hardcoded hierarchy, but they can scroll down and select anything loaded into Minerva (typically all of RO).
This may actually suffice for Planteome, depending on the modeling commitments they want to make. I would opt for pushing everything to a unified occurrent-oriented causal view. E.g. if EO classes are planned processes that perturb the plant then the same set of broad relations that apply to GO processes could be used. The process could be broken into chunks, and they could exert a causal effect on wild-type plant processes.
But note with the hardcoded list, it doesn't constrain what is applicable between any two nodes. For this, we should concentrate our efforts here: https://github.com/geneontology/noctua/issues/165
From the other ticket it seems you would like to model things like A-interacts-with-B
This is certainly possible but it would be much better to model this causally. E.g.
[a MF ; enabled-by some A] causally-upstream-of [a MF; enabled-by some B]
May 15 is ambitious, you will want to have a backup plan involving a cheat-sheet that people can manually look up.
PJ> @cooperl09 and I can work on it
@jaiswalp we can start working on this now. This will ultimately inform how we encode this in Noctua.
PJ> perfect. What's the plan or give me some prointers
We want to do this in an ontology-driven way, but there are a lot of challenges here. For example, currently the plant EO is ontologically uncommitted. Are these qualities, planned processes (@pbuttigieg suggested this), ...? What are the relationship types that should be used to connect these? A lot of OWL modeling to be done...
PJ> not sure what thsi means. let me know what needs to be done at EO. Not sure what's ontologically uncommitted. As @pbuttigieg says some are planned conditions of teh experiment and some are the variables in an experiment. As a matter of fact interactive/regulatory conditions depend on the variable identified as an EO entity.
ontologically uncommitted: the superclass of all EO classes is EO:0007359 ! plant experimental condition, but we don't know what kind of thing that is in RO/BFO. Is it a process? A quality? Most of our domain/range constraints require an upper level classification of all concepts.
Getting back to the original intent of this Issue, we need to be able to customize the "Common Relations" list that appears at the top in the Planteome Noctua. The list of relations is very extensive (~600 relations) and there appears to be no means of searching for the one you are interested in.
The browser search function (control+f, control+s, something) can be used in this case as a workaround.
Is there a mechanism to limit the existing relationship types and adding new ones relevant for Planteome. e.g. connecting to anatomy, growth stage, trait/phenotype, environment in addition to all the GO ones.