Open Physiology viewer layout issue

[bdebono]

nk-bdb_hl2.pdf SCKAN Explorer.pdf

1) Let's start with a UCSD viewer of the NPO representation of prostate:11 - see the attached SCKAN explorer PDF first, then go to SCKAN Explorer: https://services.scicrunch.io/sckan/explorer/ 2) Input "prostate:11" into the Neuron ID form (blue oval in the attached SCKAN explorer PDF), then click on "Click to Visualize" (red oval in SCKAN explorer PDF); 3) Now compare the topology in the SCKAN explorer PDF with the one generated in the Open Physiology Viewer for prostate:11 [LINK TO NEUROVIEW] - a screen shot for prostate:11 in neuroview is also attached (ApiNATOMY_prostate_11.png); 4) The topology interpretation issue, I surmise, is outlined in nk-bdb_hl2.pdf. Topology A is what SCKAN explorer is indicating we should be seeing, Topology B is what we're getting.

The following question...

Can we explain why the topology in the viewer does not look like segments from S3 and S4 are going DIRECTLY to the inferior mesenteric plexus ganglion, but seem instead to FIRST route through a node in the S2 housing lyph?

...elicited the following response:

It may be a Neuroview issue or general ApiNATOMY issue as, according to our interpretation of housed chain assemblies, first chain must traverse the common housing lyph while 4 short chains must end in it... The converted topology is certainly correct.

[albatros13]

To confirm that the converter respects topology, here is the chain assembly without housing lyphs

[tgbugs]

@bdebono suggests that maybe what we need is just a way to indicate which link has priority for converge location when there are multiple links that share the same node. One way we could do this with the existing tooling would be to give priority to any link specified in the nodes sheet, though we would probably still need a way to mark that link.

[tgbugs]

Another possibility is to cheat and always use the link where the node is marked as a source, but that probably isn't a good solution because e.g. I know that we want to turn a number of the source/target directions around in some of these neurons, and it doesn't resolve the many-to-many case.

[tgbugs]

A third option, when there is 1:n, n:1, and n:n cases for clones, which actually just looks like the number of links that have a node listed is greater than 2, then the location for convergence should not be any of the locations of the links, and should be e.g. midway between all participating clones.

This is only relevant when the nodes cannot move to colocate e.g. because the links that they are attached to are far apart and cannot move.

[tgbugs]

Thought: there is a need to be able to indicate that two segments of a chain are not actually adjacent i.e. that they do not share a border. This is a pervasive issue for neurons sourced from nlp.

[tgbugs]

A fourth possibility would be to have n > 2 clones all connect to each other at all links, this is visually noisy but probably a more accurate rendition in some cases.

[tgbugs]

5th possibility, if you have 3 links in the chains with unknown locations (can only be created automatically if we have a way to indicate that housing regions are not adjacent), then those three regions are free to float and can physically colocate in the viewer, which means you only need a single line from each of them to T13, L1, L2, and from all of them to IMNP.

[tgbugs]

Part of the issue is that this corresponds to and illegal topology in apinatomy. The solution on our end is leverage the fact that hasSomaLocatedIn implies hasAxonLocatedIn, and use that the fill in the gap seen on the right so that we get what is on the left.

[tgbugs]

The remaining issue with the rendering in the metacell version is not something that we can address without reviewing and modifying the code in the pull request for neuroview/from the hackathon. @jrmartin @ddelpiano @enicolasgomez