Graph Browser component requirements

[ddelpiano]

@dosumis @Robbie1977 below the main questions came out from our explorative meeting on this component and possible libraries to use:

1. Should we represents this as a 3D or 2D view? (vasturiano's library allows to switch from 2d to 3d and viceversa, see also (this)[https://github.com/switch from 2D to 3D layout vasturiano/3d-force-graph#201] for future reference for myself in case this will be the chosen one).
2. Should we implement filtering per type we want to show?
3. Which actions should we implement onClick on the node?
   3.1 Visualise the node (load 3D data, load image(s), load metadata in the terminfo) changing the focus term?
   3.2 run another query that returns more data from that node?
4. Should we go for a multiscale or a single scale navigation (using breadcrumbs to allow the user to navigate through his tree) as per image attached.

The implementation per node will be as much generic as possible since each node can represents different objects (neurons, images, others).

[dosumis]

We need 3 different graph widgets, all of which will have full underlying JSON graph specified in initial query (i.e. no dynamic querying to generate more graph during browsing). Nodes should be selectable => change in focus term). All edges must be have direction and we need the ability to label and render edges and to adjust their width. Prefer static over dynamic layout.

Component 1: Tree browser (not connected graph) for template: single root or small number of roots - many branches and leaf nodes. This one should be folded out to some limited number of nodes. Would also be good if automatically folds out to focus term (this is what VFB1 does). We don't need edge types displayed. See original VFB1 tree browser:

http://vfbsandbox1.inf.ed.ac.uk/site/stacks/index.htm - Note - this simple text layout has the advantage of compactness.

Component 2: Context browser - connected graph starting from one root (a bottom) = focus term - graph laid out above in rows with all arrows pointing up. Row[0] = search term ('apoptotic body' in graph below); Row[1] = nodes one hop away by longest path ('extracellular vesicle' in graph below), Row[2] nodes 2 hops away by longest path etc. Note the graph has multiple paths so some nodes are 2 different distances from search term. Nodes should (ideally) be big enough to display term name. Nodes should be clickable to select.
Graphs are generated in response to one of a small number of queries about focus term: what is it? where is it? What does it develop from? Implemented in that order
Context browser should be self contained widget - launch-able from menus and from TermInto. Default = What is it? Options on Context browse where is it? What does it develop from?

Modelled after QuickGO: https://www.ebi.ac.uk/QuickGO/term/GO:0097189

Component 3: Circuit explorer - connected graph organised in columns. Would be good to be able to display edge strength as thickness. Graphs are generated from two leg queries => starting entity class or individual & ending entity class or individual + specification of max number of links. Column position determined by simple algorithm we provide. We need to be able to colour render nodes by type (Neo4J label / Geppetto model supertype). We need to think carefully about how queries are driven.

[Robbie1977]

https://github.com/vasturiano/d3-force-3d
https://github.com/vasturiano/3d-force-graph

[Robbie1977]

May be of help further down: https://www.graphviz.org/pdf/dotguide.pdf