ontology navigation improvement

[mellybelly]

our ontology browsing up and down the subclass hierarchy is not very intuitive. I had an idea that maybe there was a way to reuse some functionality from AmiGO for this purpose?

or if nothing else, perhaps indent the subclasses under the superclasses in the display?

[kltm]

The AmiGO 2 browser widget and drawing could probably work slightly modified assuming that you had data coming in in the right format. Taking a quick look at what seems to be coming over the wire, assuming that the transitive closure is already in that blob, it might be possible to transform it into the necessary topology (degenerate would work fine) and transitive closure graphs that the AmiGO 2 tools want.

Slightly deeper in, most of the bracketing/indenting stuff should run fine on a server, with final rendering left to something else.

[harryhoch]

Melissa: which pages are you referring to?

On Feb 24, 2014, at 7:23 PM, "Melissa Haendel" notifications@github.com<mailto:notifications@github.com> wrote:

our ontology browsing up and down the subclass hierarchy is not very intuitive. I had an idea that maybe there was a way to reuse some functionality from AmiGO for this purpose?

or if nothing else, perhaps indent the subclasses under the superclasses in the display?

— Reply to this email directly or view it on GitHubhttps://github.com/monarch-initiative/monarch-app/issues/148.

[cmungall]

@ktlm - can you post the format that amigo would accept?

@harryhoch - any disease or phenotype page

Before diving in to a bigger refactor we should spec this out so it's robust and does the right thing for equivalence axioms, inter-ontology linkages etc.

As a short term fix, indenting for direct parents/children (what is currently shown) should be simple enough to do, @sarahjkim can look at this tomorrow

[cmungall]

Sketch:

• superclass1
• superclass2
• ...
• superclassN
  • class ["=" equivclass1, "=" equivclass2, ...]
  • subclass1
  • subclass2
  • ...
  • subclassM

It would be nice to show counts next to each (# diseases, # genes, ...) but this is harder and we may be looking at even more reuse of amigo

[mellybelly]

preliminary indenting sounds great as per your sketch. longer term integration with AmiGO would be awesome.

[harryhoch]

Sorry, Chris, I’m trying to understand this. Do you mean the “ontology” section on the phenotype overview? Or something different?

I have no problem per se with the amigo idea, but it might help to consider other possibilities….

On Feb 24, 2014, at 8:46 PM, Melissa Haendel notifications@github.com wrote:

preliminary indenting sounds great as per your sketch. longer term integration with AmiGO would be awesome.

— Reply to this email directly or view it on GitHub.

---

Harry Hochheiser University of Pittsburgh Department of Biomedical Informatics harryh@pitt.edu 412 648 9300

[mellybelly]

yes phenotype page, like this: or this

and with apologies for the penis-centric examples today ;-).

[harryhoch]

Right. We might be able to do a D3- based local view of the ontology that could let you go higher or lower in the tree on demand…

On Feb 24, 2014, at 10:09 PM, Melissa Haendel notifications@github.com wrote:

yes phenotype page, like this:

or this

and with apologies for the penis-centric examples today ;-).

— Reply to this email directly or view it on GitHub.

---

Harry Hochheiser University of Pittsburgh Department of Biomedical Informatics harryh@pitt.edu 412 648 9300

[kltm]

@cmungall The format is probably described by an example. This graph:

http://amigo2.berkeleybop.org/cgi-bin/amigo2/amigo/term/GO:0051179#display-lineage-tab

is based on this type of data:

/// Example degenerate topology graph centered around "localization".
var topology_graph_json = {
    "nodes":[
    {"id":"GO:0051179","lbl":"localization"},
    {"id":"GO:0051234","lbl":"establishment of localization"},
    {"id":"GO:0008150","lbl":"biological_process"}
    // Lotsa other child nodes erased.
    ],
    "edges":[
    {"sub":"GO:0051234","obj":"GO:0051179","pred":"part_of"},
    {"sub":"GO:0051179","obj":"GO:0008150","pred":"is_a"}
    // Lotsa other removed edges.
    ]
};

// Transitive ancestor relations from the perspective of a "focus"
// node; in this case, "localization". Relations with immediate
// children are currently gleaned from the topology graph.
var transitivity_graph_json = {
    "nodes":[
    {"id":"GO:0051179", "lbl":"localization"},
    {"id":"GO:0008150", "lbl":"biological_process"}
    ],
    "edges":[
    {"sub":"GO:0051179","obj":"GO:0008150","pred":"is_a"}
    ]
};

If you had a data resource like this (as opposed to chewing it on the server), it would also be possible to create a browsing widget relatively easily (a la the beta A2 Browse widget in the Tools & Resources section).

[mellybelly]

Thinking more about this as I'm testing, I would really like a more adequate browse feature for each type of content. So we need a hierarchical browser for phenotypes, diseases, anatomy, GO, but possibly for models and genes we'd want some other way of browsing rather than autocomplete. Lets think about this for July release.

[mellybelly]

I am resurrecting this. @tudorgroza @kltm or @nathandunn perhaps you can help get this moving? Ideally we'd have ontology navigation browsing with data attached for a number of pages. Start with phenotypes and diseases? then add the above anatomy, GO, etc.

Note that we may wish to have a separate HPO from uberpheno for clinicians. -m

[harryhoch]

Agreed. let's discuss requirements and goals. Listing out explicitly might help. See https://docs.google.com/document/d/1K1kPmlNZZOVy-6Xfe2EhSpHbQCIx8XhJhFfyRefT730/edit

Note that we might not want to think of a separate view for HPO, but rather a selectable view that might switch between HPO & uberpheno...

[tudorgroza]

As you know (and as per our last chat), we've started working on this, but parked it for the time being. We did, however, made progress on a different project that can easily feed into this - I can give you a quick demo when we can catch-up sometimes via Skype.

[pnrobinson]

Would be interestent to see! -Peter

Dr. med. Peter N. Robinson, MSc. Professor of Medical Genomics Professor in the Bioinformatics Division of the Department of Mathematics and Computer Science of the Freie Universität Berlin Institut für Medizinische Genetik und Humangenetik Charité - Universitätsmedizin Berlin Augustenburger Platz 1 13353 Berlin Germany +4930 450566006 Mobile: 0160 93769872 peter.robinson@charite.de http://compbio.charite.de http://www.human-phenotype-ontology.org Introduction to Bio-Ontologies: http://www.crcpress.com/product/isbn/9781439836651 I have learned from my mistakes, and I am sure I can repeat them exactly ORCID ID:http://orcid.org/0000-0002-0736-9199 Scopus Author ID 7403719646 Appointment request: http://doodle.com/pnrobinson

---

Von: tudorgroza [notifications@github.com] Gesendet: Montag, 20. Oktober 2014 01:11 An: monarch-initiative/monarch-app Betreff: Re: [monarch-app] ontology navigation improvement (#148)

As you know (and as per our last chat), we've started working on this, but parked it for the time being. We did, however, made progress on a different project that can easily feed into this - I can give you a quick demo when we can catch-up sometimes via Skype.

— Reply to this email directly or view it on GitHubhttps://github.com/monarch-initiative/monarch-app/issues/148#issuecomment-59669910.

[selewis]

That's sounds good. Given the time difference can you make the UI call (which is 11AM on Thursday)? Realistically we should get something that's not quite such a stretch for you.

-S

On Sun, Oct 19, 2014 at 4:11 PM, tudorgroza notifications@github.com wrote:

As you know (and as per our last chat), we've started working on this, but parked it for the time being. We did, however, made progress on a different project that can easily feed into this - I can give you a quick demo when we can catch-up sometimes via Skype.

— Reply to this email directly or view it on GitHub https://github.com/monarch-initiative/monarch-app/issues/148#issuecomment-59669910 .

[harryhoch]

Maybe we can find a time to grab Tudor during the meeting this week?

On Oct 19, 2014, at 7:17 PM, selewis notifications@github.com<mailto:notifications@github.com> wrote:

That's sounds good. Given the time difference can you make the UI call (which is 11AM on Thursday)? Realistically we should get something that's not quite such a stretch for you.

-S

On Sun, Oct 19, 2014 at 4:11 PM, tudorgroza notifications@github.com<mailto:notifications@github.com> wrote:

As you know (and as per our last chat), we've started working on this, but parked it for the time being. We did, however, made progress on a different project that can easily feed into this - I can give you a quick demo when we can catch-up sometimes via Skype.

— Reply to this email directly or view it on GitHub https://github.com/monarch-initiative/monarch-app/issues/148#issuecomment-59669910 .

— Reply to this email directly or view it on GitHubhttps://github.com/monarch-initiative/monarch-app/issues/148#issuecomment-59670082.

---

Harry Hochheiser University of Pittsburgh Department of Biomedical Informatics harryh@pitt.edumailto:harryh@pitt.edu 412 648 9300

[tudorgroza]

Unfortunately, it would be quite hard for me to join the UI call. Would we be able to make some other arrangements?

[kshefchek]

As a follow up to the 8/20/15 UI call, we want some sort of improvement in by the 9/9 deadline. One idea is to reuse the amigo dynamic browse using SciGraph rather than GOlr, although we could theoretically set up a special golr route for this functionality as well.

Example: http://amigo2.berkeleybop.org/amigo/browse

[kshefchek]

I've made some updates to the ontology browser per the UI call, specifically:

• Show multiple paths to root, using allShortestsPaths, so we are still not showing all paths, but it is faster than using the neighbors service
• Show siblings of a class, thinking about making this a checkbox option as it adds many classes to the tree
• Show path back to the initial class when possible (the class of the page we're on).

The test browser is on any /labs/phenotype/{id} page

[cmungall]

This is quite nice as kind of embedded browser, but what we need here is a hyperlinked hierarchy that takes you to the relevant page. Here you're navigating to other phenotypes whilst still remaining on the original phenotype pages. I think this could be confusing. Others should weigh in

On 31 Aug 2015, at 12:19, Kent Shefchek wrote:

I've made some updates to the ontology browser per the UI call, specifically:

• Show multiple paths to root, using allShortestsPaths, so we are still not showing all paths, but it is faster than using the neighbors service
• Show siblings of a class, thinking about making this a checkbox option as it adds many classes to the tree
• Show path back to the initial class when possible (the class of the page we're on).

The test browser is on any /labs/phenotype/{id} page

---

Reply to this email directly or view it on GitHub: https://github.com/monarch-initiative/monarch-app/issues/148#issuecomment-136419428

[kshefchek]

Right now clicking the info button takes you to the relevant page, should I switch the functionality so that clicking the label takes you to page, and clicking some icon allows you to navigate the inferred tree view?

[harryhoch]

@kshefchek, that depends. What are our goals for this page?

I have noticed a bit of confusing behavior here. If I go to http://beta.monarchinitiative.org/labs/phenotype/HP:0000316, and I click on "hypoterlorism", the link at the bottom that reads "hypertelorism" with the child "ocular hypertelorism" changes to read "hypotelorism"/"ocular hypotelorism".

Furthermore, why do we have both hypertelorism and ocular hypotelorism? Redundancy?

[kshefchek]

That is expected behavior as it is designed now, when you click on a class the browser reorients around that class. The only difference here is that we will show the subclasses/equivalencies of hypotelorism instead of the subclasses of hypertelorism. What should be the behavior in this case?

I'm not sure I see the redundancy (hyperterlorism and ocular hypotelorism are different things right?). Although we will have redundant classes across different ontologies, for example Cryptophthalmos on this page.

[harryhoch]

@kshefchek, I think i see the problem. When I click on something, it is moved to the bottom of the list. I found this to be extremely disorienting. Is there any way it can be expanded in place?

As far as the other IDs go, I think these are ontology content issues. The two Cryptophthalmos entries are equivalences from MP and HP, which (in some sense) makes it sensible for them to be siblings, but it's potentially confusing to have them next to each other. Hypertelorism and ocular hypertelorism are also equivalent (http://beta.monarchinitiative.org/phenotype/HP:0000316), but it's not clear to me why in this case the second would be a subclass of the first. @cmungall, @nlwashington, is there a procedure for tracking/resolving such issues in the phenotype ontology?

[cmungall]

My point is that we shouldn't do this anyway. I think it's confusing to have a browser application embedded in a page for a particular ontology class

But if this is separated out into a separate browser then I agree this is confusing behavior and should be fixed

[kshefchek]

They are equivalencies the browser is just a bit confusing (the E next the class means it is equivalent to one the above).

[kshefchek]

@cmungall that works, I can disable the navigational behavior and just have these link to other pages (and remove the info icon).

[cmungall]

Perfect!

On 31 Aug 2015, at 14:49, Kent Shefchek wrote:

@cmungall that works, I can disable the navigational behavior and just have these link to other pages (and remove the info icon).

---

Reply to this email directly or view it on GitHub: https://github.com/monarch-initiative/monarch-app/issues/148#issuecomment-136463166

[harryhoch]

@cmungall, I could see the argument for using a browser as a way to generalize, but it would require some context - essentially moving from the "phenotype page" model to "navigating through the space of relationships.." this would require more discussion...

@kshefchek, I think disabling the navigation is a good start. I think the "e" for equivalence and the reorder on selection are likely to be confusing....

[kshefchek]

@harryhoch the reordering is related to using the amigo browse script, under the hood it's just a list of lists, and we add an indent every iteration to create the inferred tree view.

[harryhoch]

@kshefchek - right, so cant' you just indent in place, instead of at the end of the list?

[kshefchek]

@cmungall, I've removed the navigational functionality

@harryhoch it is doable, but probably a bit of a hack given the state of the widget. I'd prefer a rewrite using a different layout engine if we're going to ditch this on the overview tab, I think I just misunderstood the original requirements.

[harryhoch]

@kshefchek, ok. discussion for Thursday, perhaps?

[cmungall]

Looks much better than what we have, but I don't understand what is happening here http://beta.monarchinitiative.org/labs/phenotype/MP:0004028

[kshefchek]

Those classes are all siblings (per our graph), I'm working on adding a checkbox for removing these.

[cmungall]

I think it may be safer to park these for now. It's a good idea but the nature of the merged ontology means this could be confusing.

On 31 Aug 2015, at 16:47, Kent Shefchek wrote:

Those classes are all siblings (per our graph), I'm working on adding a checkbox for removing these.

---

Reply to this email directly or view it on GitHub: https://github.com/monarch-initiative/monarch-app/issues/148#issuecomment-136494944

[kshefchek]

I've moved the browser to the phenotype and disease pages and moved the interactive version to the labs page (it's much more intuitive without siblings and equivalences). @nlwashington still working on your suggestions.

[harryhoch]

I think we should break things up into UI issues vs. ontology issues. ...

[jmcmurry]

Sorry @harryhoch if I'm missing something but I don't quite understand; which part of this thread do you think is related to the ontology construction itself and not the UI? Perhaps there are specific ontology changes that you think would make the ontology work more easily / render more naturally? Based on feedback, @kshefchek has iterated on the ontology browser for this 2015-10 release; it would be great if we could regroup and figure out where to go with it from here.

[harryhoch]

Well, the combination of the human and mouse terms in the same ontology led to some difficulty in interpreting siblings, parentage, and equivalences. That's the main piece that I found confusing. Navigating from a page about a human term to a parent that is a mouse term only makes sense if you are familiar with Uberpheno.

I think it would be great to spend more time talking about this. Perhaps tomorrow?

[cmungall]

I think we should close this and open distinct tickets

For more research-oriented improvements, we can use this: https://github.com/cmungall/multi-axial-ontology-test/

[harryhoch]

@cmungall agreed. will look at that repo.