search

TreeViz / metastyle

Styled publication of NeXML/NeXSON trees
MIT License
2 stars 6 forks source link

Rooting? #6

Open msrosenberg opened 10 years ago

msrosenberg commented 10 years ago

Something we never discussed (or I don't recall anyway), the first time through was the issue of rooting. I see at least three issues here:

  1. Styling the "root" of the tree. It's easily conceivable that someone might want to style the root of the tree in various ways. Is the root specified in NeXML in such a way that it's already context-ready to be selected through nexss, or do we need special root properties?
  2. Is the choice of where the root gets placed something that should be controlled through nexss, or is this always a property of the tree itself? I lean toward it being a property of the tree itself. An interactive renderer may allow rerooting the tree, but that's not a nexss property.
  3. On the other hand, drawing a tree as unrooted vs. rooted could be viewed as a nexss property? A specific subproperty of our "tree" element, presumably.
jimallman commented 10 years ago
  1. I know that NexSON stores all trees as trees (directed graphs with a single root). In the OpenTree curation app, we assume that this rooting may be arbitrary / suspect until a curator confirms it or re-roots the tree. I suspect that these properties are true of trees in NeXML as well, and that an unrooted tree is not really possible, though one could indicate arbitrary rooting with metadata.
  2. If another node (not the "natural" root) were marked as the root node using metadata, I think we would depend on the tree-viz app to recognize this and re-root the tree. This seems "out of scope" for PST.
  3. Nexss current dictates whether a tree is drawn with a rectangular layout, versus circular or (presumably) a "triangular" cladogram. We're dependent on the current tree-viz app to provide these layouts, analogous to CSS support in a web browser.

Drawing unrooted networks is quite a different challenge, and probably out of scope for PST. If the tree-viz app is capable of this, I think we should pass along whatever other styling hints we can (edge thickness, node size/shape, etc) and hope for the best. But without the "hierarchy" of a rooted tree, some nexss selectors won't be applied in these cases.

daisieh commented 10 years ago

@jimallman , my understanding is that a tree, as a data structure, has the property of being able to be rooted at any node/branch and have that be a correctly rooted tree, but technically, as @msrosenberg pointed out yesterday, most phylogenetic inference concepts don't actually designate a single root. We use, as a convention, midpoint rooting along the longest (outgroup) branch. Is that right? In that context, I think that any NeXML/NeXSON implementation should be clearly applying metadata to the whole edge w/o an implied directionality and should make sure that node properties actually apply to the node itself and not its implied, rooted, edge.

daisieh commented 10 years ago

I think rooting should be expressed only as a metadata property within the nexml/nexson document, and as such, can be addressed stylistically via nexss, but it shouldn't be more special than any other property. I think the issue of rooting and how that affects edges and nodes should stay within the realm of the nexml/nexson annotation.

jimallman commented 10 years ago

Since the nexss interpreter (for ETE, at least) expects to be working within a clear hierarchy of nodes, I'm afraid we're dependent on the tree-viz app to correctly identify the intended root.

Here's what the ETE docs have to say about tree rooting. In this case at least, we can find the annotation that defines our preferred root and (re)root the tree as needed with its TreeNode.set_outgroup() method, or un-root the tree using TreeNode.unroot().