Feedback on proposed API

[kcranston]

Looking for feedback on the API design.

Questions for potential users:

1. How would you imagine primarily using this database?
2. Do you prefer one of the two formats (documented parameters or CQL), and why?
3. Do the initial search modes (age and tree position) make this a usable API? If not, why not? What are we missing?

[sckott]

1. I'm a developer so would be creating libraries for users to interact with the API. So i'm primarily interested in how easy it is to develop against...
2. I prefer the RESTful format. I have worked on developing some clients that work with CQL like services - the dev is easy enough, though I prefer developing against REST services since they seem cleaner

[grahamslater]

1. I'd imagine that I would be searching the database for calibrations within particular clades. So I guess my interests would be primarily empirical.
2. both seem fine to me given my needs. I'd defer to developers (^^) on this though.
3. I think that current search modes make this usable. My perspective is that most users will search from a clade-based angle mostly, and so age is really a secondary concern. Integrating up-to-date taxonomies is therefore critical. I would also like to see integration of calibrations for extinct clades. The development of tip-dating approaches means that we can now time calibrate phylogenies of extinct taxa inferred from morphological data. The studies publishes so far indicate that these approaches result in node ages that are too old at deeper divergences in the tree. Node calibrations (first appearance dates) are very useful in these cases and would be helpful to integrate where possible.

[rvosa]

1. Automatically harvest calibration points from within the supersmart pipeline
2. Don't really care, but agree with @sckott that the cleaner the better
3. I would like to be able to do similar to TimeTree: stick in two tips, and get some estimates for the age of their MRCA. I would also like to be able to get any stem fossils for a named clade.

[rvosa]

Also, it would be really, really nice if a simple database dump, ideally as database-agnostic tables (CSV or something), was available.

[sckott]

agree with @rvosa - a dump option or maybe a download API (rate limit needed probably) for the i want all the data use case

[josephwb]

+1