mPartsRegistry is a simple interface to the Registry of Standard Biological Parts aimed at mobile smartphone browsers. It’s powered by the Parts Registry API, which provides a simple RESTful interface to key metadata about parts in the database. It features:

• . A simple interface tailored for mobile WebKit browsers (Android browser, mobile Safari, probably others). Web-based, zero-installation required.
• . Basic search of the Registry by part name.
• . “Favorite parts” to locally bookmark parts on your device.
• . Provides basic metadata associated with parts, including size, description, authors, DNA sequence, categories and availability.
• . Freely available and recyclable source code, released under the MIT License (fork it on GitHub).

The idea for a mobile interface to the Registry came out of a moment in the wet lab, where I was supervising the Monash iGEM team, and someone asked “How many basepairs is that part again ?”. I’ve found most ideas for smartphone apps in the lab a little contrived; nothing more than an excuse to jump on the Android or iOS app bandwagon, with limited practical utility. This was a situation where I could genuinely see a use for a simple mobile interface to look up some reference information, so I thought I’d create it.

The goal is not to completely replicate the functionality of the Registry (at this stage the API would not allow that anyhow), but to provide simple mobile-friendly interface to quickly look up important data about a Biobrick(tm) parts in a laboratory setting, where accessing a desktop computer is often less convenient. In this context, you generally know the part name (eg B0034) that is written on a tube, but would like to quickly lookup some details.

The project consists of two main parts: the web frontend, build using jQTouch and Django templates hosted on Google App Engine, and the parser backend (partsregistry.py) that deals with directly querying the Registry API.

The application uses BeautifulSoup on the server side to parse the XML served by the Registry’s API. This parser may be useful as a generic Python interface to the Registry API for other projects, although it is not yet feature complete. Why parse the XML on the server rather than the client ? The Registry API does not offer JSONP callbacks, making direct client-to-API queries by a web app served from another domain tricky (Same Origin Policy, yadda yadda). While this probably could have been done in straight clientside Javascript if I’d used some type of cross-domain AJAX hack, parsing on the server side also opens the possibility in the future to ‘value-add’ to the data in some way, potentially incorporating extra data not served directly by the Registry API, before it’s sent to the client.

Google App Engine works as a cheap hosting solution for a low traffic app like this, which is likely to stay within the free quotas. Also, GAE supports Python, and I like Python. jQTouch makes for a reasonable cross-platform mobile web interface, since it is optimized for WebKit-based browsers. While officially jQTouch supports iPhone/iPod Touch and doesn’t have official Android support, in my hands it works well enough on Android (and in fact displayed some minor bugs on Mobile Safari that were not evident on Android). Typically when using jQTouch you are expected to load multiple ‘pages’ all into several div-sections, lumped into a single HTML document. jQTouch then does the Javascript+CSS magic to render fast page switching, which actually working within a single HTML document. Since the main action of this app is to ‘search’, we don’t yet know what the results page will be, so this nice feature of jQTouch is barely used.

Searching for the same part all the time can get annoying, so mPartsRegistry provides a simple ‘bookmarking’ feature where a list of favorite parts can be managed and stored on the device. This is implemented via HTML5 localStorage – if there was demand then this could easily be turned into server side storage, but I doubt it’s necessary. In the future, it might make sense to pre-cache the metadata for any of these “favorite parts” so that the fast page switching features in jQTouch can be used to full advantage.

Currently, the interface does not show information about sequence features, subparts and twins, however I plan to implement these at some point. The Registry API currently does not provide information about samples, literature references or lab groups, but once these are enabled I plan to support this metadata within mPartsRegistry too.

Okay, that’s all kids .. and remember .. take off your gloves before using your smartphone in the lab !

As you may know, the Australian Federal Government is attempting to censor the Internet within Australia by forcing ISPs to block a list of websites. This proposed internet filter will not be optional; it will effect all Australians, and the blocklist will compiled by a small group of people. The list of blocked sites will remain secret, so the Australian public will find it difficult to determine if this power is being abused. It will not prevent the spread of illegal material, which is typically shared via peer-to-peer networks that will not be blocked by the internet filter. If it is not already self evident why this approach to internet censorship is both an ineffective, a waste of resources and a potential threat to the freedom of information flow required for a healthy democracy, you can read more at the Great Australian Internet Blackout site and the Electronic Frontiers Australia site.

The Great Australian Internet Blackout is a combined online and offline demonstration against this imposed online censorship. For one week – January 25-29th – Aussie websites will “black out” to inform an even wider audience about the threat of imposed censorship.

This is what it looks like right now. I'm guessing that on January 25th something exciting (or educational) will appear inside that popup box !

I’ve created a simple WordPress plugin that makes it a little easier to participate in the demonstration and spread the word. It uses the ‘blackout.js’ script written by John Ferlito to display a popup box that tells the user about the Great Australian Internet Blackout, while “blacking out” (significantly darkening) your website in the background. Once the user closes the box things go back to normal – it uses cookies so they only see the popup once.

Download the Internet Blackout WordPress Plugin

(version 0.9, md5: 16522abb4d492f445a4c5ffccd845c73 )

{{{

git rm path-of-file-to-kill

}}

Install it as you would any other simple WordPress plugin – eg, unzip the archive in your wp-content/plugins/ directory on the server. Also, online demonstrations are all well and good, but that shouldn’t be where it ends. Finish the installation by Contacting your Member of Parliament.

This is my first WordPress plugin, so it may be sub-optimal (or even contain bugs !). I’ve put the Internet Blackout plugin  source on Github so that programmer-types can fix it, if need be.

Those who have been watching may have noticed I quietly started developing an Android application in the last month or so. It’s still super-buggy and far from feature complete, but I thought it was time to announce it here (“release early, release often”). It’s not ready for real users yet, but developers may like to take a little look.

Occyd (-k d .. sounds like rockied or oggied) is an application for tagging geolocations, aimed at GPS-enabled network-connected devices. It currently consists of an Android client, and a server backend running on Google App Engine. The (evolving) API is simple enough that it should be easy to write clients (or servers) for various platforms. The idea is to enable people to tag locations on the surface of the planet with a list of keywords, just like they can tag web pages with delicious. They should also be able to search for tagged locations, based on tag(s), on distance from their current location and recency of the post.

Here’s one possible elevator pitch (for a very long, slow elevator ride):

“You are a member of a large bird watching club. Your members like to record where they have spotted various species, and use Occyd to share the locations at which they have sighted various birds. You are out in the park, when you spot the rare Orange Bellied Parrot. You pull out your Android phone, fire up the Occyd client which automatically knows your location via GPS, and tag that current location ‘orangebelliedparrot parrot birds’. You then decide to see if others have spotted parrots in the area. You search for ‘parrot’ in the Occyd client; a map appears showing the locations of all the other sightings tagged ‘parrot’ in your vacinity. You tweak the search settings to show only ‘parrot’ sightings within 100 metres and 14 days … on the map you see that your friend RobHill spotted an Orange Bellied Parrot here last week – looks like the numbers of this population are recovering !”

Ponder for a bit, and I’m sure you can think up at least a handful of other great uses (tagging good fishing spots, favorite cafes, or maybe even sightings of parking inspectors ).

As with any new project, there are lots more ideas than time to implement them (and I have a day job that doesn’t involve Occyd …). The Occyd Android client and Occyd GAE server source is currently available under the GPL v3 on GitHub, and I’m keeping all my documentation and notes on the Occyd Android client wiki provided at GitHub. Watch this space ….

I’ve found QR-code “2D barcodes” really handy when playing with my Android phone.

Sometimes, I have a web page open on my desktop PC, and I want to quickly load it in the Android Chrome browser to see what it looks like. Rather than re-typing it with my thumbs, the Barcode Scanner application allows me to scan a QR-code from the screen of my computer, and if the decoded text contains a URL, open it in the Android browser.

These two bookmarklets turn the URL of the current page that is open in your browser into a scannable QR-code:

Google Charts API based bookmarklet: Drag this link –>Current URL to QR-code to your bookmarks toolbar.

The code is:
javascript:location.href='http://chart.apis.google.com/chart?cht=qr&chs=350x350&chl='+escape(location.href);

Alternatively, I made a Kaywa QR-code generator version. Drag this link –>Current URL to QR-code to your bookmarks toolbar.

The code is:
javascript:location.href='http://qrcode.kaywa.com/img.php?s=8&d='+escape(location.href);

They both do the same thing, so you probably only want one. Only tested on Firefox.

(Update:  seemed WordPress ate the javascript in the bookmarklet links … should be okay now)

Many University libraries use some server software called Ezproxy to do authentication and arbitrate access to full-text online journal subscriptions. Essentially, Ezproxy uses some URL mangling, rewriting all hyperlinks, to pass traffic via the proxy (rather than using a conventional browser proxy setting). For example, http://www.sciencemag.org/cgi/content/full/313/5785/314 is changed to http://www.sciencemag.org.ezproxy.lib.unimelb.edu.au/cgi/content/full/313/5785/314 . If the user is not logged in to the proxy (ie has no fresh & valid cookie), a login screen is given before being forwarded to the journal site.

This plugin helps mangle URLs to add the proxy domain to outgoing links from various journal sites as well as NCBI PubMed (eg, like .ezproxy.lib.unimelb.edu.au), meaning that the user doesn’t actively have to go to their library site to follow “ezproxy-fied” links. It makes getting full-text articles via the institutional library proxy a more seamless experience (assuming that your library subscribes to the journal).

The plugin contains a list of journal and publisher sites at which it is active, plus some “special case” code for making sure only fulltext links outgoing from NCBI PubMed are handled. You can add your own journal sites as needed.

The user needs to edit the variable proxyname to make the script use their institutions EZproxy … I can’t really help you with that part, since I only know that my workplace (The University of Melbourne) uses .ezproxy.lib.unimelb.edu.au .. beyond that, you are on your own !

I’ve uploaded the Library Ezproxy Forwarder script to Userscripts.org

I recently needed to make a simple, two dimensional figure of a beta-barrel membrane protein. I went hunting for programs that might take a sequence and/or structure and produce a pretty looking diagram to save me constructing everything by hand. Here are two I found and tried.

TMRPres2D

Ioannis C. Spyropoulos, Theodore D. Liakopoulos, Pantelis G. Bagos and Stavros J. Hamodrakas TMRPres2D: high quality visual representation of transmembrane protein models Bioinformatics. 2004; 20: 3258-3260. (link)

Pros:

• Cross-platform (Java)
• Simple interface, GUI (zero learning curve)
• Lots of input options (defines transmembrane regions directly from SwissProt or PIR annotations online, takes input from several transmembrane region predictors)
• Lots of output formats and options (Postscript, gif, jpg, png, svg, bmp)
• Various colouring options (hydrophobicity, charge, “printer friendly”)
• Makes reasonable looking diagrams of helical transmembrane proteins

Cons:

• Doesn’t handle beta-barrel membrane proteins gracefully (strand drawing is overlapped, messy).
• The membrane is assumed to be a eukaryotic plasma membrane, with labels “cytoplasmic/extracellular” (which should be, for instance, “extracellular/periplasm” for a bacterial outer membrane protein). This is easily changed on the diagram with external editing.

TeXtopo

Beitz, E. (2000), TeXtopo: shaded membrane protein topology plots in LaTeX2e. Bioinformatics 16: 1050-1051. (link). See the original publication or Professor Eric Beitz’s site for a better example than my image.

Pros:

• Beautiful, clean, publication quality diagrams, courtesy of LaTeX
• Multiple input options (Swissprot format, PHD, HMMTOP, user defined)
• Multiple sequence annotation options including colouring by various physiochemical properties (hydrophobicity, charge), sequence conservation or user defined schemes.
• Will depict membrane embedded half-loops and lipid anchors.
• Versatile output (Postscript, pdf, dvi, basically anything that LaTex can be rendered as)
• Also can generate attractive looking helical wheel plots
• Did I mention the output is clean and looks great … ?

Cons:

• Steep learning curve for the uninitiated, despite extensive documentation (ie LaTeX code, no GUI)
• No support for beta-barrel membrane proteins

If I ever need to make a 2D diagram of a helical membrane protein for a publication, TeXtopo would be my first choice. For quickly getting an overview of some transmembrane prediction results or a protein with defined tranmembrane regions in Uniprot, TMRPres2D is the quickest and easiest method.

In the end, since neither program would do a decent job at cleanly depicting the strands of a beta-barrel in a simple 2D plot, I ended up coding my own hackish solution (svg_barrel.tar.gz or svg_barrel_gui_win32.zip) using Python and a tweaked version of SVGdraw.py. This allowed me to generate some SVG graphics to use as a starting point, and then hand edit the result in Inkscape to align strands to loosely match the real hydrogen bonding patterns. I also added some simple beizer curves for the loops, since neat placement of loop residues was the tricky part that I decided I didn’t have time to tackle.

Here’s the end result, after hand editing:

And here is the 3D version, as a point of reference:

The 2D vector diagram could do with some work to aid in a more accurate representation (unfortunately ‘flat’ views of a 3D barrel always have to make some compromises), but it does the job. The goal was to keep it simple … simple it is. One day I may extend this code to actually use known structure coordinates to automatically align the strands (saving tedious manual alignment), and write some code that properly lays out the loops.

Anyone know any other programs of similar functionality I’ve missed ?

Checkout Mako from SVN and copy the directory mako/lib/mako to the path of your application, eg, on Linux:

$ cp -r mako/lib/mako myapp

(where myapp is the directory that your GAE app lives in).

In your app, obviously you’ll need to import some parts of mako:

Then, whenever you want to render a template as output (say, at the end of a ‘get’ or ‘post’ method .. see the GAE templating example for some context), call something like:

An example of some template text that could go into index.mako could be:

One possible modification: I need to look into it, but defining your Template class (eg templ in the example above) in the main() function (maybe as a global) rather than instantiating it every time it is rendered would probably give better performance.

New features include:

• Suggest/autocomplete for journal title field, using the journal title lists provided by PubMed.
• A “Verify” button. Allows a ResolveRef URL to be constructed with the web form and verified as working and valid without actually forwarding the user to the article.
• Some bugfixes (handled the case where there is no DOI in the PubMed record, handled network timeouts to PubMed)
• Refreshed visuals
• Disqus comments box for feedback

In the interest of just getting something working quickly, I implemented the suggest feature in the laziest, possibly most RAM and CPU hungry way possible (the “JQuery Suggest” code queries the web app with substrings as you type each character. At the server side, the app uses a regex to scan a ~1.5 Mb list of journal titles held in RAM). I’ve already noticed a few “This request used a high amount of CPU” warnings in the logs, with the threat “High CPU requests have a small quota, and if you exceed this quota, your app will be temporarily disabled“. If my nasty hack starts heating up Google’s datacentre too much, I might have to disable the ‘suggest’ feature until I can implement it “properly”.

Reflections, discoveries

This idea of implementing Openref-style article identifiers has been an fun experiment, and a nice way to learn more about the ins-and-outs of PubMed. When working on implementing the ‘suggest’ feature, a major drawback became even more apparent … journal titles (the [TA] field) used by PubMed are not always easily guessable, and many common abbreviations used in reference lists do not appear to exist in PubMed’s downloadable flat-file journal title lists. This is the list that ResolveRef uses to make the ‘suggestions’, so having ‘missing’ journal titles presents a problem if I want users to be able to painlessly construct ResolveRef URLs.

Proc. Natl. Acad. Sci. U.S.A. is a perfect example. Many article bibliographies use PNAS – that would be my guess if I were trying to create a ResolveRef URL for a PNAS paper – and yet this journal title does not exist as far as PubMed’s official journal list is concerned. Issues surrounding this problem were discussed on Noel’s original OpenRef post. The odd thing, is that if I search the PubMed Journals database, for “PNAS”, it finds it, and gives me a record where PNAS is listed under “Other titles(s)”. If someone could point me to where I can get these extra fields containing additional names for a journal that are not provided in the the downloadable flat-files, it would be much appreciated (I bet Alf knows the answer. Or maybe I should email the folks at PubMed). If I can get a better list of titles the ‘suggest’ feature in ResolveRef would suddenly become a whole lot more useful. Another way around this may be to use CrossRef, and I’m looking into that, but I get the feeling that usage of the CrossRef API is more restricted, so I haven’t bothered with it so far.

Thoughts about the future of ResolveRef / OpenRef

At this stage, ResolveRef URLs are not actually identifiers. They simply act like a frontend to a single-hit PubMed search, and several different ResolveRef URLs can return the same DOI URL (and hence the same journal article). A proper identifier would have a one-to-one mapping between the human-readable ResolveRef URLs and a DOI. In the future, I may attempt to get ResolveRef to ‘normalize’ URLs by allowing only a single journal title for each journal and forcing the use of volume numbers if present. The user could use the web interface to enter the values, and ResolveRef will return a normalized URL. Only normalized URLs would successfully forward to the DOI URL, others will return an error with “Did you mean ..insert normalized URL ..?“. One drawback is that this would reduce the guessablity of ResolveRef URLs, but the advantage is that they could be treated like identifiers: one article would have one and only one valid ResolveRef URL. By requiring a tool (like the ResolveRef web form) to help users build a vaild URL, and removing some of the guessability, ResolveRef would move a little closer to a reinvention of OpenURL (although I think OpenRef/ResolveRef URLs are still more readable and cleaner than OpenURLs, and are much more guessable if you have a bibliography in front of you).

A key cosmetic (and philosophical) difference between OpenURL and OpenRef/ResolveRef URLs is that OpenURL uses HTTP GET fields, eg ?title=bla&issn=12345, while OpenRef/ResolveRef uses the URL path itself eg, somejournalname/2008/4/1996. It’s a bit like one scheme was designed in the age of CGI scripts, while the other was designed for web applications capable of more RESTful behaviour. In my mind OpenURL is more versatile but much uglier, while OpenRef is cleaner and simpler but can only reference journal articles. OpenRef-style URLs will never be able to reference the breadth of resources that an OpenURL can theoretically handle. Maybe hybrid solution could work … some kind of OpenURL server that could “speak OpenRef” … accepting OpenRef-style URLs where possible, while still dealing with regular OpenURL style “?bla=blarg&” query strings for everything else.

As far as I can tell OpenURLs are not identifiers with a one-to-one URL-to-article mapping – this is a drawback since you could not do a Google search to reliably find sites that reference an article via it’s OpenURL … you theoretically could do this with a normalized OpenRef/ResolveRef URL, since there will only be one unique string used to reference any one article (as Noel pointed out, OpenRef strings have some properites akin to InChi strings). Obviously to do this cleanly, ResolveRef would need a nicer domain (something akin to dx.doi.org).

Anyhow, I’m not expecting ResolveRef / OpenRef to make any impact on anything anywhere anytime soon. I’m not a librarian, I don’t sit on an NISO/ANSI committee, and I don’t see publishers seeing a need to adopt anything beyond the DOI. But it’s been nice to play around with, and I’m likely to continue doing so.

Firstly, there is the “just testing and don’t actually have a citation on hand to key-in” class of users, that tried requests something like:

/ref/xx/2007//

Not much sympathy here … it’s pretty much like dialing a random phone number and hoping it someone will pick up.

Then there is a class of users who appear to have sensible intentions, but provide incomplete ResolveRef URLs, eg:

/ref/Organic%20Letters/2000//

Maybe I poorly described ResolveRef in the initial announcement, maybe the documentation in the “About” box on the ResolveRef site is unclear or maybe these users just didn’t read the docs in the first place. When I described the service as “A RESTful way to do PubMed searches”, maybe it would have been more accurate to say “A simple, RESTful way to resolve a single journal article using only the human-readble citation information”. ResolveRef does not give a list of results to a PubMed search; it forwards to a single hit (ideally the requested article), or gives an error if it can’t be found. By the looks of it, many users seem to want to use ResolveRef as a way to retrieve a list of results. While this goes against the original spirit of ResolveRef being a resolver for an [almost] unique identifier for journal articles (akin to Noel’s OpenRef proposal), I may be tempted to update ResolveRef to return a list of hits in the future (or just forward to the HubMed or PubMed results page).

There are also some actual bugs which throw nasty python backtraces (I think this one was actually me trying to use ResolveRef to look up a reference at work ):

/ref/Protein%20Sci/1999/8/689

This threw an error since ResolveRef (stupidly) assumed that every PubMed record has an associated DOI … however for some reason this Protein Science article does not have a DOI recorded in PubMed, so it fails to resolve with ResolveRef. This is (yet another) drawback to using PubMed as a backend. I’m thinking I may need to make ResolveRef interface with CrossRef somehow too, since that may act as a backup (or complete replacement) for these cases.

There also seem to be occasional errors generated when the HTTP connection from the Google App servers to PubMed fails; my fault entirely … that type of exception should always be anticipated and caught in a networked application.

Apart from guessing how people may like to use the application by examining the logs, edoardo.marcora also suggested that autocomplete/suggest for the journal field would be nice. I agree … this was a feature I was working on prior to the initial release, but it was taking too long so I just launched ResolveRef without it.

There is a new version in the pipeline, and will be ready for release soon. I’ll also put it on Google Code, warts and all. I already have the “suggest” functionality working, and once I resolve the few bugs discussed above, I’ll push out an update. Stay tuned.

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