Phylotastic

From Evoio

(Redirected from ToL-o-matic)
Jump to: navigation, search

Phylotastic logo.png

This is the public page for the Phylotastic hackathon (as distinct from the Leadership Team's planning page).

Contents

Where to go

This is the main page for pre-hackathon planning, including

  • agenda development
  • overview of phylotastic plan

There are other pages for specific topics:

attention new participants!

This is your wiki to write collaboratively with other authors.

Of course you should be polite about that-- but you shouldn't be shy. If everyone is shy about adding or editing or deleting or rearranging ("re-factoring") content, then the wiki becomes a mess, or it becomes the work of 1 non-shy person, which isn't what we want.

So, if you can improve this page by adding, removing, rewriting, or rearranging text, please do it. Edit this wiki like you own it. You don't have to ask permission-- you have it already. If you think the wiki would benefit from comments about topic X, don't add one of those annoying little notes that says

(Bob: shouldn't we have some comments about topic X?)

Instead, just add the comments about X, or create a new section for comments about X to be added later.

resources: software, references, tutorials, and other useful links

Add links to papers, websites, code, tutorials, etc that would help people get up to speed on any of the proposed tasks.

before, during and after the hackathon

before the hackathon

  • use the wiki to participate in planning
  • add your info & pic to the participant table

Hackathon agenda and guiding principles

Starting on Monday, June 4th at 9:00AM

agenda

  1. day 1: informational presentations
  2. day 1: design discussions, spec-ing
  3. days 2 to 5: work
  4. day 5: wrap up (hackathon ends at 3:00PM on Friday, June 8th)

guiding principles

  • create a demo implementation of a system based on open standards
  • allow alternative implementations, at least for some steps
  • allow flexibiilty for multiple use-cases
  • have at least one graphical front end that will make the promise of this project clear to users

after the hackathon

Opportunities right after the hackathon to build on the phylotastic momentum

  • do a challenge project for Geneious, present it at iEvoBio
  • do the iEvoBio challenge at iEvoBio
  • work on Galaxy integration at a workshop

Manuscript

Phylotastic design

draftiness

This is a draft plan and a place to develop ideas. The overall target of the hackathon is fixed (build phylotastic), but no single aspect of the plan has been fixed. Participants are encouraged to develop plans here in April and May, before the hackathon starts. We will have the opportunity to re-think things on day 1 of the hackathon.

goal statement

Statement of goals. 1. Build phylotastic, a collection of interoperable web services that collectively provide the means to extract a subtree (specified by tips) from any of several large species tree, and to supply branch lengths and provenance annotation. 2. For demonstration purposes, leverage these services within a graphical interface that also integrates the resulting species tree with the user's choice of several high-value types of data. Optionally, this may involve adapting an existing environment (e.g., Galaxy, Taverna) to manage a phylotastic workflow.

inputs and outputs in brief

inputs = {

  • the user's list of species { S }; # the main input under the control of user
  • optionally, the user's character data, one row for each species in { S } ;
  • repository of megatrees that we have built for the project ;
  • any information on { S } conveniently available online via web services (e.g., NCBI, gbif)

outputs = {

  • phylogeny (with branch lengths) including only species in { S }; # main output
  • optionally, user's comparative data with tree (NEXUS or NeXML), ready for phylogenetic character analysis;
  • optionally, a mash-up with other information on { S } from online resources

}

where this output is presented graphically in some viewer that is relatively adaptable, e.g., Mesquite.

a bit more about the issue of integration and mashups

The main work of this project is to develop the "engine", the stuff that is "under the hood". But if this is going to benefit users all over the world, we need to show what the engine can do. For this reason, a substantial fraction of the energy will be devoted to creating integration tools that combine the engine of phylotastic, with species information that is easily gathered via existing services, such as:

  • images of an individual of the species, collected from EoL or wikipedia; or silhouettes from phylopic
  • geographic distribution of the species, from GBIF
  • the location of the nearest museum specimen of the species
  • whether a genome is available for this species, from NCBI
  • the number of protein sequences known for this species, from NCBI
  • the rDNA or cytochrome C sequence for this species, if available from NCBI
  • the average<link rel="shortcut icon" href="/favicon.ico" />

<link rel="search" type="application/opensearchdescription+xml" href="/wg/evoioaps, is just a web form with a place to submit and validate a species list, and a set of check-boxes for which types of information to collect for those species. The user enters the species list, clicks on the desire information, and then clicks "Go", and the software goes and gets the information and the phylogeny, and presents it to the user for visualization (e.g., in Mesquite or some other viewer that can be adapted). For an example species mashup, see Rod Page's ispecies, which creates an on-the-fly web page for a species based on info from NCBI, google scholar, etc

thinking about phylotastic in an MVC design pattern

background This is an application of Model-View-Controller or MVC design pattern (http://en.wikipedia.org/wiki/Model–view–controller, or see the discussion here: http://msdn.microsoft.com/en-us/library/ff649643.aspx). In the design sketched below, the model (the M in MVC) is precisely the USER's tree. This may sound odd at first, if you've been thinking of "phylotastic" as a centralized resource with back-end megatrees at its heart. The design below gives us considerable freedom (to imagine different kinds of phylotastic implementations) by abstracting the operations away from the model. It frees us from thinking of a conventional workflow, because many operations can be done asynchronously (e.g., we can decorate OTUs with images before or after getting the topology). Because of this potential for multiple asynchronous operations, it may be helpful to add an "Observer" element to the MVC design.

model The "model" is the user's tree along with its metadata. Of course, the user typically doesn't begin with a tree, but with a kind of pre-tree. In mathematics its ok for a "graph" to be a set of unlinked nodes. We'll borrow that way of thinking and imagine that the initial state of the tree is (typically) a list of OTUs that will become the terminal nodes. The final state of the tree typically is a fully connected tree with a topology and branch lengths. The final tree may be missing some nodes that could not be found. Also, there may be annotations of individual nodes, and annotations (metadata) for the tree-as-a-whole (e.g., this tree was assembled on a particular date by a particular service).

operations If that is the model, then here is how we would conceptualize the KINDS of operations that update the model:

  • a "TNRS" updates the model by replacing input OTU names, or annotating input names, with qualified OTU names.
  • a "topology service" updates the model by linking some or all of the OTUs into a connected graph
  • a "scaling service" updates the model by estimating the lengths of branches connecting nodes
  • a decorating or annotating service updates the model by adding annotations to nodes or branches, such as
    • collecting images of OTUs
    • gathering fossil-based dates for internal nodes
    • assessing quality or reliability of a node
    • and so on

In addition

  • every service updates the model by adding provenance information (e.g., describing how it has modified the model)

controllers and views The typical view of the model is going to be a phylogeny or an OTU-based table. A controller invokes services to modify the model (the user's tree) in response to user commands. Frequently we have discussed phylotastic in terms of automated controllers, such as workflow engines that manage the inputs and outputs of a series of operations. But we also could think of an interactive controller.

Background

A problem faced in many areas of life sciences research, from community ecology to comparative genomics to biomedical genetics, is given some comparative data for a set of species, put these data into a phylogenetic context. For all we know, scientists are facing this type of problem hundreds of times every day. Given that past decade of efforts to assemble a large "tree of life", it ought to be possible to solve this problem in many cases by taking an existing megatree of species, pruning away unneeded parts, and grafting on (where possible) missing species.

An existing tool called "phylomatic" does precisely this: starting with a user-supplied list of species and a huge phylogenetic topology for plant genera, it grafts the species onto the tree wherever it can match the genus name, and it prunes away all the rest. This is just a topology, so users find ways to add branch lengths to the resulting tree. The result is that the user, so long as she is only interested in plants, can get a phylogeny for an arbitrary list of named species. Phylomatic rocks: its frequent use shows that big species trees are highly useful for applications in ecology, biodiversity, & trait analysis,when the interfaces that serve user needs— and the mega tree providing vast coverage— are available.

This suggests that if a more general tool can be built, it will be extraordinarily useful, especially if

  • it is an open standard that can be implemented in many ways
  • the back-end data store is populated with large phylogenies available for fungi, fish, mammals, butterflies, etc (not just plants)
  • the core functionality (name-matching, grafting & pruning) is modularized in open-source bioinfo toolboxes
  • methods for adding branch lengths are easier and more generalized
  • all of the above operations are wrapped up as web services that can be invoked from existing computing environments

If this were a web service, we could plug it into Mesquite, and users could load up their species-based character matrix, then get a tree for it. In fact, lets go back a step, to consider users with only a list of species, and no data to compare: consider an even more open-ended discovery environment, which we could implement in Galaxy or Taverna (given that this is all based on web services). The user starts with a list of species (or a higher taxon), and a request for some useful types of data that could be obtained by querying various available sources, e.g., whether it has a cyt oxidase sequence in GenBank, whether it is found in California, where is the nearest specimen, etc.

Architecture

flowchart of phylotastic, version 1


Tasks => People

Indicate which tasks you are interested in working on, or add them if they aren't here!

  • Backend Tree Store: Jeet,Jamie
  • Components
    • Phylomatic-style Pruner: Jeet,Jamie
    • TNRS: Jeet, Gaurav
    • Branch Length Estimation: Jeet
  • Service Interfaces
    • REST API: Ben
    • CGI Scripts (wrappers): Ben
  • Data Mashups (Tree + Character Data)
    • How to do it?
    • What types of data will be allowed?
  • Use Cases Holly
  • Documentation Holly
Retrieved from "http://www.evoio.org/wiki/Phylotastic"
browse site