D3 Paths to Root (and other concept graphs)

[everbeek]

See #330 when this is nearing completion, for tree layout implementation. Treat layout issues as separate ones.

296 might have a good checklist for this as well (UI stuff).

I created the ticket late, but I have been working on the D3 implementation of the paths-to-root. I tried using the batch requests, and commented on the problem in #322.

So far I haven't had to do D3 changes, just new programming for requests and data processing.

[everbeek]

Have edges getting added. Need to sort out positioning a bit more, and stylings of nodes and edges.

[everbeek]

The layout behavior is sort of odd, with nodes and arcs out of step. Also, one arc seems to stay "detached" from its nodes, until I manipulate it with the mouse. Trying to see why.

The detached arc...every time an arc is added, it seems to be detached, and only the final arc to be added suffers for any serious length of time. This is a good hint to figure it out.

Moving the call to get bound links fixes it, but this doesn't seem like a good solution to me; it would make binding calls unnecessarily, on every tick. The trouble is that the binding set only includes those just bound (enter()), which goes against my expectations. Ah, in the example I see, the enter() set is passed in instead of the bound set. Let me try this.

That did not work. Nor did returning the appended items (which doesn't make sense anyway).

Ok, what worked is to use vis.selectAll() instead. This can be used with the closure I had in place, to prevent unnecessary calls to selectAll(). If the pattern changes later and we will not be redefining the onTick() method on every add, we can move that into the method without much cost, I think. I am looking at this refactoring after committing this small change.

[everbeek]

Now to work on mappings neighbourhood and term neighbourhood. I will put off the layouts for later (Peggy suggested that someone else might want to work on that part). After that, work on node menu, edge and node stylings (rounded edges, edge types), and drop down boxes.

[everbeek]

Working on term neighbourhood, and trying to figure out an edge instantiating bug. When I only load the parent node in my example (commenting out children stuff; or vice versa, only child no parent), no edge is instantiated. When I let all instantiate, all of the edge appear, but there is a significant delay in adding them.

I think edges are not getting added when I intended.

Aha, I see; edges appear only after retrieval of the second end of the node...let me rephrase...node 1 gets added, we make queries for its neighbours, and we check to see if any edges need instantiating, and none do. Then node 2 has the same occur, but we add an edge to 1; this edge is added, in my test case, when we ask for the parent relations.

I think this means I have a bug when I try to add edges immediately after adding a new node, as in manifestEdgesForNewNode() called in parseNode()...but...maybe it's an ordering problem, where I parse the node then register edges...looking further.

Yes, I changed the edge registry, and that broke the function for adding edges right after node creation.

[everbeek]

Going to clean out crufty comments, and review expandAndParseNodeIfNeeded() and manifestOrRegisterImplicitRelation(), prior to sharing code with Elena (tomorrow?), then get back on task here.

When I switch between path to root and term neighbourhood, things misbehave thoroughly. Do mapping neighbourhood after fixing that.

[everbeek]

Seeing if I can fix the bug that happens when we use the drop down to switch visualizations. It works fine if you change the optional URL parameter, so the individual visualizations work, but the resetting of the graph is probably failing.

[everbeek]

Needed to reinitialize a few more structures, tested with: http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=term_neighborhood&ontology_acronym=CHEBI&full_concept_id=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FCHEBI_24870 and http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=path_to_root&ontology_acronym=SNOMEDCT&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F82968002

[everbeek]

We could be checking not for the visualization mode to determine if a set of nodes should be expanded as their relations are parsed, but instead we should be checking against a list of expanded nodes. Whenever a node should have its relations expanded, we add it there. It can track whether the parents, children, composition and mapping relations have been completed or not. Then when we parse we can set those flags, and do expansions as we go. When I add the expansion boxes, I can use the same system, but either use stored relations data when the flags are set (all are completed) or requery for relations data (with the concept in the expansion registry, thus parsing as we receive the new relation data). This last part is mostly a fail safe against the possibility of failing one relation parsing and not flagging that category of relations as completed.

[everbeek]

349 extended this. Remaining bits of this will be in other issues.