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 ….

It barely warrants it’s own blog post, but here we go anyhow: my one-liner shell script for counting the number of sequences in a FASTA “flat-file database”, based on the presence of the “>” header symbol.

Dead easy huh ? I put this in ~/bin/countseqs, make it executable (chmod +x ~/bin/countseqs) and use it in lots of situations, as a quick sanity check.

(oh, btw, this is not public domain and u can’t use it for commercial gain without paying me a license fee. academic users can fax me something for a free license. k thx bye).

Couldn’t help myself … everyone else is doing it

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 ?

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.

There were the usual complaints on Slashdot that FoldIt doesn’t have a Linux version. Well, I’m happy to report that it seems to run alright using Wine (on Ubuntu Hardy Heron). I couldn’t log in to try the competitive puzzles, but I suspect the server is just in the midst of a Slashdotting. I’ll try later.

From the FoldIt FAQ:

Can humans really help computers fold proteins?
We’re collecting data to find out if humans’ pattern-recognition and puzzle-solving abilities make them more efficient than existing computer programs at pattern-folding tasks. If this turns out to be true, we can then teach human strategies to computers and fold proteins faster than ever!

Not sure where I saw it, but I remember reading an argument that the future of crowdsourcing would be to not just blindly trust the whole crowd, but also identify experts in the crowd and weight their predictions more strongly. I’d say this is will be the case with ‘manual’ protein folding – just like some players become l33t at first-person-shooters (like my favorite, RTCW: Enemy Territory which depsite enjoying, I’m not so l33t at), and could beat any AI player that doesn’t cheat… some people will probably become pretty good at folding up proteins. Maybe FoldIt will identify them, and they can make their gaming skills useful, and teach their tricks to software to automate the process. Or maybe it will just remain a fun-ish puzzle game

Although it was published in 2006 (and earlier in 2000), with the original URLs now dead, I noticed the latest update for the version of texshade in CTAN (v1.18) was on 15th of April, 2008 … ie texshade was updated just 14 days ago !

It happens all to often that published bioinformatics tools cease to be updated or even disappear from the Web not long after the peer-review publication is released. Kudos to Eric for not abandoning his software.

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

Here’s a screenshot of Qutemol running under Cedega on Ubuntu Gutsy Gibbon, just to prove it.

No, it’s not Photoshopped … (or GIMPed) …