RDF / linked data endpoint?

From a developer perspective, a few things would be nice to have:

1. A really well documented API. Of course no one likes writing documentation, but it makes developing tools that consume the API so much easier.

2. A RESTful API would be much easier to develop for than SOAP.

3. If possible, it would be nice to be able to query not only by tip names, but by node names so that someone can ask, “Give me the tree downstream from X taxon”

4. If you use authentication, IMHO it would be easier for developing desktop apps to avoid OAuth – just a simple authentication (user/pswd, or username/key, etc.) is easier to develop around (my opinion of course).

5. Maybe you could have some API write methods for approved users to annotate trees?

Thanks! Scott

http://phylotastic.org/

This is a scheme for a distributed system of components that, together, provided convenient access to the “tree of life”. The simplest version of the idea is that the user submits a query consisting of a list of species, and the response is a phylogeny for those species based on expert knowledge embodied in available trees.

Much of this is hypothetical but there are demos that show how the ideas work, e.g., this form:

http://phylotastic-wg.nescent.org/script/phylotastic.cgi

There is a “Taxonomic Name Resolution Service” component that takes user-supplied names and cleans them up. There is a “DateLife” service that calibrates the tree by integrating fossil information (using a super-efficient computational scheme)– it’s like TimeTree, except that it is an open project with a web-services interface so that it can be integrated into automated tools.

The Phylotastic project is in an early stage, still gathering partners and putting together a proposal for major funding. I’m part of the project and I would be happy to make a pitch to the OToL PIs for why they should partner with this project. The brief pitch is this: 99 % of researchers will not have the skills and know-how to integrate OToL into their research if you offer them one giant tree. But if this is part of a system that offers name-resolution, pruning, calibration, and metadata services, then OToL can rule the world.

My colleagues and I published a review last year with a lot of information on barriers to re-use of phylogenies:

http://www.ncbi.nlm.nih.gov/pubmed/?term=sharing+re-use+phylogenetic+trees

OToL represents a testbed for evaluating what makes phylogenies re-usable, how to make them more re-usable, etc. From what I can see, the important factors are going to be (1) externally meaningful identifiers that allow for semantic integration (same thing that David Hedrick mentions in his comment) and (2) methods annotations.

A somewhat separate problem is (3) integrating expressive well-defined formats into downstream user workflows. Most users can’t use your product if it isn’t Newick, but your product becomes meaningless if you have to distribute it in Newick format.

People who are doing Real Science are very concerned about quality, and as there is no accessible external standard of truth for phylogenies, this means that real scientists are very concerned about whether the methods used to generate a phylogeny appear to represent the best available methods– chosen for accuracy–, or appear to be chosen for convenience. That cannot be discerned without annotations of methods.

If the original authors have not supplied you with externally meaningful identifiers and computer-readable methods annotations– and in most cases they don’t– this is a problem. Trying to get this stuff retroactively from the original authors is not a scaleable strategy for a project like OToL.

So this means either wait for the time (in the future) when the trees generated by experts are sufficiently well described to satisfy the demands of users, or use the trees that are available now but create some way for 3rd parties to annotate them.