PhyloPic Week 2: Lineages, Browsing, and API

Another good week for PhyloPic. There are now well over 200 silhouettes in the database. I also rolled out some new features and enhancements.

Redesigned Lineage Pages

Lineage pages now provide taxonomic and license information for each image. As a visual touch, figures now fade as they go deeper and deeper into the past. Here's a few of my favorite lineage pages so far:

• Anhanguera santanae (pterosaur)
• Catocala nupta (moth)
• Corvus corax (avian theropod dinosaur)
  
• Damon johnstonii (whip spider)
  
• Giraffatitan brancai (sauropod dinosaur)
• Homo sapiens sapiens (primate)
• Pantodon buccholzi (butterflyfish)
• Therizinosaurus cheloniformis (theropod dinosaur)

Yes, they're all bilaterian animals. There's a definite bias.

Image Browser

Now you can peruse the entire gallery much more easily, with the Image Browser. Use the arrow(s) on the side to navigate through pages of silhouettes.

Developer API

For any developers out there who want to use the PhyloPic database to create their own apps, now you can. I've provided an initial API, available both as a JSON service and an AMF service for Flex apps.

Also of news to developers: I've opened up the code base for viewing and cloning. (Still need to add the licenses, though.) It's a Django app, written in Python. Feel free to poke around.

Thanks

I'd like to thank everyone who's submitted images so far, especially FunkMonk, Scott Hartman, Matt Martyniuk and Maija Karala for their many contributions. (Each of them has submitted at least a dozen.) Thanks also to Steven Coombs, Craig Dylke, Mo Hassan, Neil Kelley, Dann Pigdon, Ville-Veikko Sinkkonen, Patrick Strutzenberger, Reka Szabo, David Tana, Michael P. Taylor, and Emily Willoughby!

A Plea to Providers of Open Webservices

Let's suppose you have a webservice, and you have decided, out of the goodness of your heart, to make it "open". Anyone can browse it, search it, and utilize the data it provides. This is something you want—for anyone to be able to utilize the data and present it in new, creative ways.


I'm willing to bet you missed a step.


Consider my Flash application, Names on Nodes. Right now it's a standalone program—it can import and export files locally from your system. But it doesn't read data from any webservice. There are many places in the program where it would be extremely useful to do so. For example, instead of having to enter LSIDs manually, it could search for them in uBio. Instead of having to open NexML files locally, it could pull them from TreeBase. Wouldn't that be nice? Why haven't I done that?


Well, fact is, I can't.


The Flash Player has a security mechanism whereby it will not load data across different domains. If my SWF resides on namesonnodes.org, then that is the only place it can load data from. Of course, there are ways around this: a good way, a less good way, and a really stupid way.




The Good Way


If your domain has a file called crossdomain.xml in its root, then the Flash Player will read that to see if cross-domain permission has been allowed. Here's an example of a crossdomain.xml file that allows maximum access across all domains:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="all"/>
   <allow-access-from domain="*" secure="false"/>
   <allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

(Or, download it here.)


For more information, see the Cross-Domain Policy File Specification.


(Note that the folks at TreeBase are looking into this. I'm on tenterhooks.)




The Less Good Way


I could also make Names on Nodes as an AIR application. This is less good because it means the user would have to install it as an application on their local system, and they couldn't just access it online. But it would allow for more possibilities—not just the ability to load data from anywhere regardless of policy files, but also drag-and-drop from other applications, etc. I am actually planning to create an AIR version someday, but it's not my top priority right now.




The Really Stupid Way


Of course, I could also make a little server-side component on my domain and simply have it pull data from your domain before feeding it to the Flash application. This is really stupid because it greatly increases traffic on my webserver while still causing just as much traffic on your webserver as it would if you had just allowed cross-domain access with a policy file.




In Summary


It takes a matter of seconds to place a cross-domain policy file in your server's root directory (assuming you have access), there are no drawbacks if your service is intended to be open anyway, and there are huge benefits for us Flash developers who want to use your service. I mean, really, why not?