search

Planteome / noctua

Graph-based modeling environment for biology, including prototype editor and services
BSD 3-Clause "New" or "Revised" License
0 stars 2 forks source link

Limiting existing relationships and adding new ones relevant for Planteome #2

Open jaiswalp opened 7 years ago

jaiswalp commented 7 years ago

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.

jaiswalp commented 7 years ago

we want to get this ready by May 15 max, for showcasing at the GOC noctua jamboree June 1-5.

kltm commented 7 years ago

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.

jaiswalp commented 7 years ago

As we are training new folks, I am trying to limit their choices with top level slim relations and avoiding scope of making errors.

kltm commented 7 years ago

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.)

cmungall commented 7 years ago

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...

cmungall commented 7 years ago

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

cmungall commented 7 years ago

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]
jaiswalp commented 7 years ago

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.

cmungall commented 7 years ago

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.

cooperl09 commented 7 years ago

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.

kltm commented 7 years ago

The browser search function (control+f, control+s, something) can be used in this case as a workaround.