When to create a new otus block? about rnexml HOT 3 CLOSED

So, I just wanted to make sure that we were handling this third case
appropriately. We could instead add a new otus block in this case with all
the otus for the characters, which would mean duplicate entries of certain
otus. I'm not sure just how problematic that would be?

My sense is that it would be better to create a new otus node, with
possibly duplicate otus, than to automagically fold newly encountered
labels into an existing otus node without any user intervention. We can't
know ahead of time why people have an existing otus node (or multiples of
them) so it's not very polite to just start poking around in them. What
would be nice is to then, separately, have some sort of merge_by_name()
method that does the merging, perhaps with some additional intelligence
(e.g. ignore suffixes that look like accession numbers).

Because a characters node must refer to a single otus node for reference
(I think), there's no point in checking for matches across multiple otussets, or writing only the unmatched otu labels into a separate otus node. I
assume it's no trouble to have more otu nodes in an otus block than any one
trees or characters block actually needs?

Yes, it's OK to have non-referenced otus blocks, as many as you like, and
non-referenced otu nodes in a block.

from rnexml.

@rvosa Thanks, that makes sense. Will modify the function such that we will still use an existing otus block if it has all the taxa of interest (as we might often expect when adding a character matrix to a file containing a phylogeny), but will create an entirely new otus block if any taxa in the character matrix are unmatched.

Obviously this same issue comes up when adding trees to an existing nexml file (I just hadn't written that method yet -- so far our methods only support creating a new nexml object/file given a tree). Naturally I will follow the same rule of thumb -- create a new otus block if any of the taxa are unmatched.

Still, I cannot help feel that this may not produce the behavior the user expects in certain circumstances. Imagine a user adds a tree and then the corresponding character matrix to the same nexml file, and the matrix includes a few species not on the tree. This will result in two separate otus blocks with 99% the same contents, which is probably not the desired structure. In particular, I worry that this makes annotating the otu nodes difficult. It may also make it harder for a machine to recognize that the matrix and phylogeny cover the same otus (e.g. must explicitly check the matches, rather than just the otus attribute of each block.)

A user iteratively adding a set of characters and/or trees could wind up with lots of mostly duplicated otus blocks. Perhaps we must let the user toggle this behavior in the function call? We would still need a default option (or have a more confusing function).

from rnexml.

I think it's OK to ask for user intervention when integrating data. It's
how I do it in Bio::Phylo for the exact same use case - but I can also
appeal to a higher authority here: it's also how it's done in mesquite. If
we discover it's a frequent PITA (I doubt it) then it can always be changed.

from rnexml.