Gather All Composition Relations & Specialize Link Rendering

[everbeek]

I suspect the term neighbourhood isn't getting composition relations. Test and see.

http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=term_neighborhood&ontology_acronym=SNOMEDCT&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F81745001

It is clearly getting some or all (that have the attribute labels we knew to look for). The arcs are not rendered differently, nor do they have arrows. I haven't worked on this for the D3 view yet, of course.

I do not know if we can actually get all the composition relations possible. This is definable by the ontology author, and there is no standard way of naming it. This is very disappointing. In fact, I don't think we can identify a priori which attributes are even links to nodes. There can be so many for some types that it would be hazardous to try to grab all of them anyway (some link collectiosn appear to have a hundred links).

1) Get arcs rendering differently 2) Look over some ontologies to see how diverse the composition relation names are.

[everbeek]

Have links rendering based on type, and figured out the best way to add SVG triangle midpoints to arcs. Quite the fancy method: use a path or polyline, define markers, and magic makes them work. Have to fix up the highlighting code to use classes that can be easily added and removed. That won't work for nodes, but I'm only looking at edges for this anyway. Alternately, I can use only opacity and not style or color for the highlight functionality.

[everbeek]

Got the markers (arc heads) working, but then started refactoring CSS classes out of string constants, and moving code-based style to CSS. The reason is the same reason we refactor anything, to make it easier to make changes, and to cluster semantic encapsulation.

It was painful, and I still have some string literals to deal with, but link and node styles, as well as their highlight and dim transformations, are now fully CSS based. It is good.

Also refactored the highlighting code into the graph view class, since the logic was pretty much identical between ontology and concept graphs.

Also did some more pressing of types into the generics used by graph data entities. There is a limitation to TypeScript that they introduced to simplify the compiler: you cannot have generic arguments that refer to other sibling arguments. So you can't force two provided classes to be related in a particular way. This doesn't lose us anything in practice, but it sure was hard to figure out. You use "any" when you hit this wall in TypeScript. Ok, duly noted.

[everbeek]

I still need to get labels on the arcs (with luck, SVG has support for labels like it has for markers).

I still need to look at the data too, and see how diverse the composition relation property names are. I feel like that part will not turn out well.

[everbeek]

Added labels, but they made even small graphs animate slower and they also cluttered the view. I used markers to do so. I commented it out for now. We can comment them back in if requested.

A non-marker option is as follows, but performance should not be improved...if anything it could be worse. http://stackoverflow.com/questions/18316056/d3-js-force-layout-edge-label-placement-rotation http://stackoverflow.com/questions/8663844/add-text-label-onto-links-in-d3-force-directed-graph

[everbeek]

Looking at composition data examples to see how many ways there are to designate composition relations.

[everbeek]

Well...the UI takes a very long time to search through for data like this. Since the old specs didn't include other attribute names, I should move on for now.