In the absence of any quickly achievable ideas for a bioinformatics app, I ported over the OpenRef application I wrote on top of TurboGears a few months back.

Just like the original, the new app, ResolveRef, is essentially a RESTful way of doing PubMed queries.

A query like:

http://resolveref.appspot.com/ref/journal/year/volume/page

or when there is no volume number, like:

http://resolveref.appspot.com/ref/journal/year/page

will query PubMed and forward you to the DOI. Usually this means you will be forwarded to the electronic version of the article at the publishers site. The nice thing about these OpenRef style URLs is that unlike the DOI (eg doi:10.1093/molbev/msm031) or PubMed ID (eg PMID:17329230), they are easily guessable if you have the biblographic reference in front of you. See Noel’s original OpenRef post and the “About” box at ResolveRef for more details.

Here’s a reference and the corresponding ResolveRef URL you can click on to test it out:

http://resolveref.appspot.com/ref/Mol Biol Evol/2007/24/1149

(wow … I really should have chosen one without such a large forest of authors )

I’ve called it ResolveRef rather than OpenRef, since based on the discussion on Noel’s blog, it became clear that this method of mapping PubMed queries to URLs doesn’t completely fulfill Noel’s vision of what an OpenRef resolver is meant to be. It looks like this discussion is on-going (and has been had before) … in some ways it looks like this style of reference location by URL has missed the boat since DOIs and the CrossRef database are already well established and prevalent.

As far as how difficult the porting from Turbogears was … well, for an app like this with no database access, and essentially no web interface templates (I only added the front page with a form for the ResolveRef version, the original app served no actual html pages) … it was pretty straightforward, and I nice way to learn some of the ins-and-outs of App Engine. The biggest trick was hacking the Biopython Bio.EUtils.ThinClient class to use Google App Engines urlfetch rather than urllib2, which amounted to changing something like:

import urllib2
return urllib2.open(url)

to

from google.appengine.api import urlfetch
fetched = urlfetch.fetch(url)
return cStringIO.StringIO(fetched.content)

Bugs and feature requests are welcome … but I don’t make any promises about fixing/adding them. I’ll release the code soon, when I get some time to clean it up for public consumption

I’ve always wanted to be able to ‘search outward’ from just my delicious links … a recent post from Alf about Google Co-op ‘on-the-fly’ search engines just triggered a simple but really useful idea; make a Google Co-op search of my delicious linkstream … this way I can search just within pages I’ve deemed worthy of bookmarking.

After a bit of wrangling with the various ways of getting data out of delicious (see my own comments to this post), I found this script for generating an html page of links from delicious. This page contains all my delicious links, not just the most recent ones (it seems you can only get a subset of the most recent links without authenticating with delicious, hence the PHP script using the delicious API).

So, after hosting the PHP script revealing all my links, I can point the Google Co-op Custom Search Engine to that page, and search away ! It’s a nice way of using search to ‘retrace’ my steps, since it should generally restrict results to the parts of the web I’ve already seen and rated as worthy of re-examination.