CyPhy - Cybertaxonomy and Phylogenetics

You are in a maze of twisty little passages, all alike.

2011-02-24T00:08:00.001-05:00

I poked at @rdmpage the other day pointing out that he should think about a 3D phylogenetic tree browser rather than thinking in 2D. Navigating 3D environments is very well worked out thanks to the multi-billion dollar gaming industry, it seems like one could borrow some of the concepts there and map them to viewing phylogenies.

After a little back and forth I decided to do a brain dump based on some ideas that were discussed at the recent GMOD hackathon about linking phylogenies to genome tracks. @hlapp chimed in that this might lead to a career in phylogame (tm?) programming. This resulted in the exercise taking a little more of a fantasy-role than first anticipated, but I think some of the original ideas might still come through. I don't claim that this solves Rod's problem (nor perhaps any real problem), but nevertheless here it is, an A-Z list of possible features for a 3D tree browser using a 3D-game-engine. Such a world might also act as a sort of memory palace. The major thing that's missing- some way to earn "points", because that's what people do in games, get points, so they must be important. If you have to ask- no I do not have a World of Warcraft account, I did however, beat Akalabeth. The graphic below in no way attempts to represent actual phylogenetic relationships, click to enlarge it. If someone wants the illustrator file to modify I'll gladly pass it along.

A - The world consists of a series of paths based on the tree(s) in question. Visible paths are rendered in the ground plane. As the user moves along the paths towards the horizon we see more paths, and the features on the horizon are updated to reflect the remaining tips of the tree.
B - In the horizon pane we see a generalized summary of the clades (paths) we might follow if we continue forward on that path. Much meta-data can be mapped to these features, and the surrounding environment.
C - Bigger features on the horizon (trees?) indicate more paths, giving the user a sense of where the additional information content is.
D - Trees can differ in their health (color of leaves), healthier trees are those that have clades that are supported by more data, or perhaps higher support values.
E - A forest of features might indicate some measure of complexity of the clades in question, or maybe the total number of clades.
F - The weather on the horizon (or above), indicates controversy with the clades in question, or perhaps uncertainty (clouds = doubt).
G - Horizon features need not be trees, they might vary based on some parameter- mountains are rock solid clades.
H - Like the original TOL tree houses you could stop in to learn more about the clades/taxa in question.
I - Trusty map radar.
J - Glowing purple portals let you exit to other websites with context-dependent information.
K - Are there genomes for the clade in question? Lamps, breadcrumbs or other features illuminate parallel paths.
L - Pubs indicated nodes where social-media are discussing the clade in question, pop in for a virtual drink.
M - People are authors, a crowd at a node corresponds to many unique authors.
N - Click to interact.
O - Lateral planes could alternatively map to other metadata. In a 2D system (moving only forward and back) looking left or right could bring up charts/graphs, images or other metadata.
P - Paths could turn to springs, then water courses, for aquatic clades.
Q - For the kids- BATTLE DINOSAURS!
R - Author avatars greet you at the trees they have published.
S - Synapomorphies are statues, monuments or other features along the road. Examine them to learn more.
T - Many trees are contradicted in places, swamps join clades to illustrate alternative arrangements.
U - Fruit on your tree? Someone has left comment(s) or feedback.
V - Strange auras? Multiple equally optimal trees exist.
W - Use the magic wand to toggle through things with auras.
X - Paths can be paved based on the underlying data supporting that clade (gold = morphology, cobblestone = single copy nuclear genes, mud = CO1).
Y - Paths to terminal nodes end with a picture .
Z - Look up! Constellations form alternative phylogenies.

Thanks to PhyloPic.

Longevity, agility, and standards in biodiversity informatics

2009-11-14T00:23:00.003-05:00

This post is mixed bag of equal parts #tdwg09 tweets response, clarification of the philosophy behind mx, and end-of-the-week-flu-induced rant. I really don't mean it to be an argument for using mx vs. say, Scratchpads (that's sort of an apples-oranges argument). I've always been very upfront in my cautioning potential users as to the pitfalls of using mx. I'm very aware of the arguments for standardization, stability etc., however, what is also painfully clear is that there is far to little diversity in biodiversity applications, i.e. tools which enable scientists to do new science. The worlds biodiversity is 10% described, and there are only so many ways we can mark up, search, map, and re-index this minuscule fraction of potential knowledge. Where are the new applications that are going to capture the remaining 90% of the data while making it inherently more useful?

Agility
A couple of premises. New science happens fast, really fast, to accommodate it we need "agile" (yes it's cliche) solutions. The funded life of many projects happens within 1-3 years, and the notice of funding is abrupt. mx exists, in part, because I need an environment that I can quickly modify if I want to test new things (visualizations), promote new ways of thinking about taxonomy (morphological ontology-based descriptions), mock up proof of concepts for grants, or provide new functionality for my self or my research colleges. I need to be able to provide features and functionality for active research immediately, as in today. The consequences of this type of approach is not always positive, among other things the probability of more features failing increases because they met too specific a need or just generally sucked is higher. The benefit of providing many mutations is that the best (one-click matrix coding) are rapidly selected for.

One practical example, poking at Scratchpads (because I think it's a great project) to make a point. This year Scratchpads is reporting its Nexus importing functionality. Last year mx needed to import Nexus formatted matrices and I justified the time to develop a general purpose parser and importer because we had people who would immediately be using the functionality. The functionality and has been available for over a year. This year we've added a more robust framework for handling sequence data (FASTA uploads automatically tying to specimen data) because I and my colleges will benefit greatly from it (we've already added hundreds of extract, pcr, and specimen records). I have no doubt that "next year" Scratchpads will get FASTA support. There is also no doubt that at some point Scratchpads, or some other uber project (e.g. Lifedesks, Lucid or Mesquite) will have all the functionality that anyone could ever dream of right now. At that point somebody will want to do something else, and it will take years for them to catch up and do that something else. You get my point. This definitely doesn't imply that mx will have everything a biodiversity app needs, nor that it is better, more quickly developed, more comprehensive, more reasonable or any such claim, it's just an illustration of a very pragmatic issue that biodiversity apps in general need to address- we need tools and we need them now.

Standards
Scientists will capture whatever data it is that is interesting to them, and waiting to do science because some standard is in place is a sure fire way to fail. One example among many- As various folks have tweeted (see #tdwg09, and if you dare read taxacom) there is some "discord" about the role of LSIDs in biodiversity informatics. Had my first priority been to ensure that everything that mx did was LSID compliant I would have spent an inordinate amount of time on functionality that to date I'm still not sure is going to be useful. The same goes for SDD, does anybody actually use this to do real work, and how might I find out if they did? It might turn out that LSIDs are critical, in which case I believe that mx is perfectly situated to take advantage of them, and perhaps even provide them.

I have very little fear that the data model used by mx is somehow incompatible with core biodiversity data. We've already provided or capture data in a large number of formats including DarwinCore, Nexml, OBO, FASTA, Nexus, TNT, ITIS import tables, and have many mechanisms for exporting data for users. Since mx is open source it's open to anyone (particularly those with ample experience- nudge nudge) to hack up new ways to expose or manage standards-compliant data. Getting data "out" will always be relatively easy, making data digital (getting it "in") is hard work that 1) doesn't get enough credit and 2) doesn't get enough funding.

Longevity
mx originally evolved largely out of my desire to have a unified environment for my research as a systematist. It exists because at the time no solution existed that integrated the types of data I wanted to manage. I maintain that no such solution (including mx) yet exists today. It is meant to by my "life-long-companion". If I get hit by a bus (better not go outside today on the 13th) will mx die? Probably. Will the data be lost? If someone finds it useful then probably not. Is it in some cryptic silo that only I know of? No- source is on SF, numerous labs have vested interested in keeping their data pertinent. Longevity should not get in the way of getting things done in the first place.

mx
mx is evolving, and funding or not I see no reason why it can't continue to do so. Because it does a lot of different things its role is somewhat foggy (harder to pin down and bash, I like it that way), but some central objectives are emerging:

Focus on functionality that allows researchers to do work. When in doubt about standards capture verbatim data. Worry about who to make friends with (which standards to adopt) when the apocalypse ends.
mx is not a final repository for data (is there such a thing?). It is an environment for gathering and working with data. When you publish your data your sequences should go to Genbank, your taxon names to Zoobank, your descriptions to EOL and plazi, your trees to Treebase, your specimen data to... oh hell just send it all to Rod Page.
Provide a tool that helps to generate new data that others want (the best way ensure longevity is to have useful data), then give others a way to access that data however they may want (a flexible web-based framework like Rails)- they just have to hack on their preferred API.
mx is not (just) about making taxon pages, taxon pages are somewhat of a nebulous concept that is best compiled by larger entities (EOL, ALA) with budgets for flash. We've provided some of the basics to make pages, but we hope that these are stopgaps for an integrated approach with larger projects. The multipurpose utility of an environment like mx is perhaps best exhibited by the HAO which was rapidly prototyped in mx and then NSF funded. The end product of the HAO is an OBO file which alone justifies the work on the application which may or may not exist in 5 years.
mx is an expert system and it makes no apologies for being so. Taxonomists, phylogenetists and ontologists are experts that work with complex data (that can't be handled by wikis...yet). Just as we don't expect mathematicians to use the Microsoft Equation Editor, but rather to understand the complexities of software like Mathematica, and expect engineers to use CAD, we should expect people who study biodiversity to be expert informatics tool users. Another way of saying this- you see nobody convincing math profs to do their work with wikis instead of Mathematica/R etc., there simply isn't the specialization in these applications to enable the data exploration and management that needs to be done (again, this is a big "for the foreseeable future" ... during which many grants will be written and much research will be done). While mx wants things to be easy and straightforward as possible (it's likely failing miserably now) it is not aspiring to be the Microsoft Word of Biodiversity Informatics.

mx is open source largely for selfish reasons- I wanted to see if there are other systematists who hack (whether it is possible to do both at the same time is unclear and will be the topic of an upcoming post), and hoped for mutual benefits if such existed. It's an experiment which I hope will slowly emerge as a successful one- big matrices take a long time to compile, as do taxonomic catalogs, specimen inventories and complex ontologies. These data in instances of mx are already significant (e.g. 85k new matrix cells from over 1800 characters and 5400 character states, 7700+ OTUs, 40k references, 12k taxon names, 60k tags, an ontology of 2500 morphological terms etc.) and the commitment to using and funding mx suggest an exciting future.

Nomenclature is Dead! Long Live Pragmatic Taxa!

2009-09-06T08:07:00.022-04:00

Roger Hyam's blog post is great. A few somewhat random thoughts on it follow, with apologies in advance to Roger for any (likely) misinterpretations. I don't read taxacom, so there might be some redundancy here. I'm not sure that what follows makes any sense, nor is it my personal position, that is, I'm trolling.

What Roger seems to point out, and what I've argued to others in the past is that something like this will ultimately exist in the future:

In the future we will have a lot of data on "the web".
These data will be very accessible to machines OR humans (hereafter "mahus").
The way mahus will access data of interest will be by using other data/observations,/measurements (hereafter lumped as "daomes").
Since taxonomic names are not daomes they are are pointless.

How does this work? Let's imagine some sci-fi:

Situation A: The mahu plumber laying fibre optic cable is having a bad day. In the depths of its subterranean workplace something is fouling its locomotion. The mahu applies a vacuum to the space itself sucking some of the offending stuff into a daome chamber. Some daomes are taken, including a daome which identifies some hydrocarbon present only in life (at least according to the mahu's reference ontology). Life has DNA, therefor the mahu's built in DNA reader makes another daome, which indicates that the offending stuff is a red, stinging thing that lives in colonies in the soil, fouls up electrical equipment, and can be killed by a dose of the contents of the red canister attached to the side of its locomotory appendage. The pesticide is applied, the problem goes away, and the mahu continues plumbing.

Situation B: Back on the surface two mahus are playing. Something hops onto the field in front of them and they want to know whether this thing might be dangerous and interfere with their game. They can see that this thing has a wing, beak, feather, is red and is singing a song (I'm looking at one out my window now). A few interactions with the cloud later they realize that they are looking at something that is mostly harmless.

Both cases illustrate that we don't need to work with names at all in many cases. Science would benefit immensely if we depended on daomes rather than names, since all our hypotheses and inferences would necessarily be tightly integrated with our primary daomes. Among other things this would result in an excellent audit trail, as is required by good science.

Note that this system only works if #2 above is (mostly) true. Names are useful now because data are not accessible. Names act as temporal place holders that allow us to jump from one reference to another without losing track of where we are. If data are unified, linked, and very easily (=instantaneously) accessible we don't need these place holders to do work.

Roger writes "If the purpose of taxonomy is to produce a system that people can actually use to hang data on - so that both people and machines can then infer more knowledge from the linked data - then this is really the only game in town." I think that Roger doesn't want to do taxonomy, he wants to do phenomics. He wants to produce a system of data that we can hang names on. This is a good idea.

Uncertainty

I have minor quibbles with Roger suggesting that DNA is the way to implement the necessary nomenclatory system, though this might be misunderstanding on my part. If his system works then I think it can work with genomic or phenomic daomes. What I'm doing here is disagreeing, for the point of argument, with Roger's statement "What the machine can’t do is take into account additional properties, that weren’t considered in the first place, like the human user can.", and taking the discussion in a different direction.

Roger's method works by instantiating a taxon and pointing to it with hard link. A hard link is something with two features, it is both an address and a property of the class itself. It's like using an id in a relational database as a meaningful property of the record it identifies, for instance using your SSN as a id for your medical records. Creating hard link identifiers in a RDBMS is typically taboo. His hard link is a string of letters, which just happens to be a DNA barcode, which is a property of an instance of his taxon. Note that hard links could be anything, it need not be a string of letters referring to a DNA barcode, it could be "blue". "Blue" the string of letters is unique, it's not "BlueRed" or "RedBlue", and it's also a property of the (polyphyletic) taxon that is blue.

There is another subtle aspect to these identifiers. "Blue" is obviously not unique as a property, and "ACGTG" (of suitable length) is. How about 475.0nm, the wavelength of blue light? That's as unique as some long string of "ACGTG". Thou taxon shall be identified by 475.0, not 475.1, nor 475.2, 457.3 is right out (or something like that, my MP is not so good). My taxon is Rhododendron luteum[475.0], Roger's is Rhododendron luteum [ACGTG...].

Going from "Blue" to "475.0" is really not that hard, it's just a matter of using a reference ontology to link the two (well, ok, that's a little tricky). I mean "blue" as in this ontology. This brings up a slightly more abstract possibility. What if within this ontology we include logically consistent classes that are compositions which reference complex phenotypes. As required by Roger's system our hard link both identifies a taxon, and is itself unique. Our identifier might look like this: "headsbluespinesverylongeyesredandsomeothertextthatjusthappenstodescribemytaxonandmakeslongstring". In the same way we might see issues with using "blue", we can instead point to something more specific in our reference ontology, so our human label just becomes some identifier, which references the class in the ontology, which logically defines our very long string.

The problem with using blue or phenomic characters is that the phenome ontology doesn't exist, and will be difficult to make. This shouldn't prevent us from trying.

The real issue with Roger's system is pragmatic. It is that it requires that [A_label] points to a method(s) which return a daome which is a hard link of the class [A_Label]. In other words, the labels "475.0", "ACGTG" and "headsbluespinesverylongeyesredandsomeothertextthatjusthappenstodescribemytaxonandmakeslongstring" are meaningless without context, and, unfortunately, context brings with it uncertainty. How exactly do I generate the daomes that also act as hard links? You likely require YAO (yet another ontology) which documents an experiment which when performed returns a daome which has some reasonable chance of being a hard link of the type you want. Since uncertainty is necessarily invoked when someone generates daomes of any type Roger's nomeclature using genomic daomes is no more valid from an ontological standpoint than is nomenclature using phenomic daomes. You can never completely be sure you are returning the string of letters that the label [atpH] is meant to return. This is true for any number of reasons, many of them well documented, many just due to the nature of making observations. The leap from label, to daome, is huge. Note that what Roger wants, a completely logically consistent ontology and all the goodness that comes with it, can't just mostly work (as he notes), it has to completely work, or it completely collapses. If we are OK with a system that "mostly works", then we should be OK with either phenomic or genomic approaches. One last way of saying this- it's all well and good if the ontology is completely internally consistent, but if I have to guess at whether my external data match the ontology, then guessing about morphology is as equally valid as guessing about DNA.

What typically happens in this point of the argument is that the issue becomes a pissing-match about how accurate we want to be (e.g. 80% correct identification), and whether or not genome out performs phenome in this regard. This is of course an argument of method, not nomenclature, so it's changing the topic.

Pragmatic Taxa

There are obviously lots of other uses for names, I don't see them going away anytime soon. One way to perhaps encourage (force?) people to think about the inverted process Roger is promoting would be to have journal editors require a statement of purpose with each new taxon circumscription. If you want to provide a new name, you have to provide a statement indicating what your taxon circumscription could be used for, i.e. make it pragmatic. The only rule is that the statement can not be "If you use my description then you can identify more of my taxon." That's a given. Statements could be something along the lines of providing the species concept definition you're using but more specific. It should come in the if-then form. If variation in the wing length of my taxon is studied then we can say something about flight dynamics. One fallout of this requirement is that there would quickly become several accepted "stock" answers, one of which might be "If you use the characters I discuss, which are all referenced in an ontology, then a mahu can reason over your results and mine." A nice way of getting data integrated into ontologies.

p.s. I purposely used the nonsense "daomes" and "mahus" not to confuse but rather to see if I can trace their reference in future discussion. Note also how well Google does with a few completely general terms in it's image search.

wolfram alpha + taxonomy = ?

2009-05-15T23:38:00.004-04:00

So whenever a new search engine is introduced I like to test it with the family of wasps I specialize on, the Diapriidae. Wolfram|alpha is getting a lot of hype lately, and tonight it went live. While it largely choked and acted oddly (if it worked at all) on my search terms, some searches did appear to complete. I tested the term Diapriidae, needless to say it didn't do too well as parasitic wasps are not dinosaurs. I suppose it gets some points for recognizing I was requesting something related to a taxonomic classification...maybe. "Hymenoptera" was more successful, but with (very) minimal results. "total species of hymenoptera" could not be interpreted. Searching for taxonomy returns some interesting results, including "taxonomic networks" (e.g.). You can click to see the sources for a given result, and those sources are (nicely) linked, Species 2000/ITIS is listed as one. It doesn't appear that you can drill down much past orders of insects. In general I'm very underwhelmed thus far. The primary source is listed as Wolfram|Alpha curated data, it will be interesting to see if they expand there database, watch for job postings cybertaxonomists!

augmented reality

2009-01-11T00:21:00.007-05:00

This technology is pretty cool, and seems to have been around for a while (see also this more recent application). I'm not sure how or what it has to do with cybertaxonomy, but it seems like it should have some application. Perhaps the technology could be used by including the "fiducial marker" along with barcodes (paper) that are attached to mounted specimens. By waving a device over a drawer of specimens one would get images (magnifications), meta-data, or some other cool or useful information. Maybe you could build a physical tree, with something like meccano or lego pieces "enhanced" with these markers, the relationships among the physical branches could be interpreted in the augmented reality, perhaps mapping character state transitions onto the physical tree, overlaying geographic distributions, or some such. This could also be a great way to get kids into museums. First, at sites (schools?) away from the museum, hand out "game" cards each with some information on an organism and an aforementioned marker. These cards could be brought to a museum that housed an augmentation system. There once "invisible" information would be revealed, for example movies, 3d representations, or pointers to where real live versions in the museum could be found.

ping (visualization)

2008-09-21T20:00:00.008-04:00

Popping up to note that from Rod Page's post on the recent Nascent meeting it appears that visualization is a hot topic. If you aren't following Moritz Stefaner's well formed data blog, and you are interested in visualization, then you are really missing out. His latest post brings up all sorts of possibilities for phylogenetic or taxonomic implementations. For kids or students, why not print up a collectible card game <cough>was a long time ago</cough> with a biodiversity theme, embed interesting data in the cards, and marvel as phylogenetic relationships (or ecological etc.) appear when the cards are placed on that ridiculously cool table.

Relationalizing Nexus files with Ruby and mx

2008-04-30T23:25:00.006-04:00

Ok, so "relationalizing" isn't really a word, but I kind of like how it sounds. For the past couple of weeks I've been writing a Mesquite (i.e. Nexus) file parser in Ruby. It uses the same basic lexer/parser engine that reads Newick formatted trees that I mentioned in a previous post to create a Ruby Nexus file object, with all the good bits (well most of them, some blocks are not parsed yet, but that's just a matter of extending the parser) easily accessible from the object. With this Nexus file object it was relatively trivial to write a conversion to mx (see fig.), i.e. a fully relational format.

The Ruby file parsing code is currently a plugin/library in the mx source, it can be easily extracted for use in other projects. Look for the code in mx 0.2.1540 and onwards when it makes it to Sourceforge, or contact me directly if you're really keen to get your hands on it.

Plasto-types?

2008-04-01T21:46:00.005-04:00

Slashdot and the BBC have picked up a story on the use of X-ray Radiography to look at fossil insects. I've seen some pre-press examples of the same technology on extant bugs, the results are incredible, in part because all the soft tissues are left intact and you can get any cross section you want. I'm really curious as to 1) the the resolution on the fossils, on extant critters it is apparently very close to SEM calibre; and 2) the cost. This could be a huge boon to making fossil data available to phylogenetic studies. The kicker at the end- the researchers suggest that the printed plastic insect could be designated as a type specimen. In many ways this would have huge advantages, as anybody with the technology could print their own types. The real suggestion underlying this is not that the plastic itself is the type, but rather that a set of 1s and 0s can be typified, the plastic of course being generated from digital data. This of course opens up a whole can of (prehistoric?) worms. How many 1s an 0s are needed before a (meaningful) type can be designated? Can I use a CoolPix for imaging and maybe bundle my images with some 1s and 0s that encode for some specimen data, and typify the resulting zip file? From a pragmatic standpoint- why not?

barcoding (dna) Google tech talk

2008-02-29T19:10:00.003-05:00

Haven't seen this pointed at yet, a little state of the union from Hebert and Janzen that was posted on Google's tech talks. "It [barcoding] works with startling clarity." ;). A number of interesting insights during the question period, with a general focus on scale, diminishing returns, and legal issues (curious that, coming from Google and all).

misc.

2008-01-27T15:27:00.000-05:00

Annotating images with user-created overlays is a must for defining morphological characters, or enhancing ontologies. This seems to be a relatively tricky thing to do over the web. Inputdraw is a SWF widget that is free for noncommercial use. It allows you to save overlays drawn on images into forms, the data are then saved as SVG text. The OpenCollections software also mentions an annotation system that is in the works, though the bottom line there is that its not quite ready prime time. At a recent Morphbank meeting someone (apologies for not remembering who) mentioned that another solution might involve using the Google Maps API to create polylines or points on custom "maps", which would in fact be your images. The Beginning Google Maps Applications with Rails and Ajax book is a decent starting point for implementing this approach. Note that you would need .gif or .png formatted images if you attempt this. I used the Beginning Google Maps book to finally implement maps "natively" within mx (we still have hooks to BerkeleyMapper, which is a great service), but not without several hours of frustration. While the book is quite clearly written the code provided in Chapter 3 is incomplete or erroneous in several very frustrating ways, so make sure to download the updated code from the website if you have the book.

As I add new tables to mx I'm starting to add fewer and fewer columns, with the idea that tagging can be used as the primary means of extending the basic objects. Tagging essentially allows you to extend your records to as many fields as you want, and is therefor a very simple way to provide extensibility. A new book on the tagging phenomenon by Gene Smith looks to be a must read, I think I'll order mine now.

Finally, while somewhat older news, I keep thinking about social annotation with respect to taxonomy, and also things like scoring phylogenetic characters. How might things discussed in this Google talk from Luis von Ahn be applied to systematics research? Within taxonomy one approach could be to simply photograph many specimens and then allow the general public to point out the similarities and difference. These could then be vetted by the "experts" as a starting point. This approach, albeit with a greatly simplified "taxonomy" and character set, is being used at GalaxyZoo. In the GalaxyZoo example the galaxies have already been classified by computer algorithms into various types, so there is an excellent comparative dataset for testing things like the trustworthiness of the public contributions. Games like those discussed by von Ahn could also be used in developing hypotheses of character homology. In systematics we present homology hypotheses that are then further tested using phylogenetic analysis. What if part of this testing requires that the definition of these hypotheses be agreed upon by two or more experts, using games like those discussed by von Ahn? In theory this agreement is already required, to some degree, as implemented in the review process that occurs prior to publication. It could, however, be made more explicit (and fun?). Given the right framework for playing these games there would be many beneficial spin offs including obvious things like annotated ontologies of morphological characters.

FigTree v1.1

2008-01-13T19:03:00.000-05:00

Andrew Rambaut has posted a message to the beast-users listserv, he's just released a new version of FigTree. Among other things this new version allows you to re-root trees (something I bugged him for a while back, as I'm sure others did as well). Perhaps even better, the source code has been released. With these new features, and now that others can conceivably add new bells and whistles, I suspect FigTree will remain the premier tree rendering software for some time.

T(ree analysis using)N(ew)T(echnology) is free

2007-12-22T11:48:00.000-05:00

This post at Blind.Scientist alerted me to the fact that TNT is now free, thanks to support from the Willi Hennig society. That's worth repeating here. The Blind.Scientist blog mentions a review is in the works, so check back there shortly. This is a great step forward as TNT has a lot of promise, particularly with respect to its scripting capabilities. Much of that promise is locked up in, if I dare say, its somewhat cryptic help documentation, and buggy script examples. I've worked a lot with TNT in the past, but haven't checked the latest documentation, so take this observation with a grain of salt (a small one). I've mentioned to Pablo, and have heard others comment, that what is needed is a community wiki similar to that supporting Beast (a wonderfully supported piece of software, see the active mailing-list for example). This suggestion has thus far fallen on deaf ears, but maybe now that the software is more accessible (somewhat, it still isn't open source, which is a major strike against it IMO), something will happen. As a side note- I've had problems running the latest TNT on OSX 10.3.9, and Pablo wasn't able to get me a compiled copy that worked. I'd be curious if anybody has similar problems, or whether its just my old PowerBook giving up the ghost.

pixels to Newick

2007-12-14T22:17:00.000-05:00

Bioinformatics sports a new paper on an application called TreeSnatcher. The meat of the problem is essentially recognizing and converting a tree in a picture (pixels) to a representation in Newick format. While nifty I'm not sure this is particularly useful, and perhaps its a reflection of the lack of awareness of sites like TreeBase. Older trees are relatively small, and can be rebuilt using Mesquite or other programs. New trees should of course be archived somewhere so that they can be grabbed auto-magically, or, as my shadowy friends put it, "just ask the $%@* author for the trees". Fire up those screen-caps!

Not practical, but pretty.

2007-11-26T00:58:00.001-05:00

A nested set representation of a Newick tree loaded into mx (source in 0.1.1379). Even though this isn't the best way to visualize a phylogenetic tree I was happy to just get this far. Now to see if trees can be drawn using only margins of divs and position:relative, with maybe a little opacity: for good measure. Don't hold your breath on that one.

storing phylogenetic trees in mx

2007-11-23T22:35:00.000-05:00

Turkey in belly I've sat down to flesh out the storage of phylogenetic trees in mx. Krishna's phylo_tree lexer/parser creates nice Ruby objects of newick formatted trees, all I had to do was incorporate another of his efforts better_nested_set, to translate the parsed tree to a database table, all in all just a couple lines of new code. Visualization is another can of worms. I think I'll likely wait till a nice Rails/Ruby graph (as in trees) generator comes out before attempting this. As a thought experiment its interesting to think about how to display a tree completely in ascii, and not just drawing the branches with _, -, and |, but rather displaying groups of terminals, or labeled internal nodes in some meaningful manner depending on where you are in the tree. Its late, so I envision starting with something like "you are in twisty set of passages all alike" ...

Morphbank updated, now with matrices

2007-11-21T15:53:00.000-05:00

Morphbank has been updated with new features including the ability to create and score OTUs. They will also be rolling out some new searches that return RDF and XML in the very near future, and functionality for allowing external clients to upload images.

relation_browser plugin for Rails

2007-11-07T17:57:00.000-05:00

The relation_browser plugin is a neat start at using a SWF plugin written by Moritz Stefaner in a Rails environment. I've implemented it in a crude manner in mx as a taxon name hierarchy browser. I'd like to get it to work with the simple ontology editor/displayer that's also in mx, though I'll likely wait to attempt this untill the plugin is a little more mature. Every once in a while its definitely worthwhile to check out Agile's catalog of Rail's plugins for gems like this.

Flare

2007-11-06T21:46:00.000-05:00

First post, maybe last. The open source visualization toolkit Flare appears at first glance (and second) to have some potential as tool for rendering phylogenetic trees. A quick look at the demo reel should convince you of this, click on the "GraphView" button therein to jump to the trees bit.