http://www.flickr.com/photos/alicebartlett/ / CC BY-NC 2.0

• MajorGroove.org pitches itself as a ‘forum for biologists’, which it is, however most of the content currently focuses on X-ray crystallography and associated techniques. It is currently in ‘bootstrap mode’, which means that reputation requirements are a little less strict until the userbase and site activity has grown to a critical size. Is there even a need for a Stack Exchange forum for biological crystallography ? Macromolecular crystallography already has a single, central, de facto standard forum – the CCP4BB mailing list. While it may be antiquated by Web2.0 standards, CCP4BB works well for a lot of people, and there is a huge amount of useful and important information buried in it’s archives. For many crystallographers, it seems CCP4BB would only be extracted from their “cold dead hands”. Despite this, I think the Stack Overflow format will be very beneficial for people new to the field.  As a side note - I discovered MajorGroove via Graeme Winters XIA2 blog right around the time when I was considering kickstarting a “Stack Overflow for crystallography”. At the moment it seems that a small userbase of crystallographers is already established on MajorGroove and there would be no purpose for another near identical forum. Even if questions about other techniques in the biosciences start to dilute out the structural biology, one click on the ‘crystallography‘ tag or the ‘ccp4‘ tag, and you can get straight to the good stuff. (In fact this feature was deemed useful enough by Google that they decided to bless the ‘android‘ tag on Stack Overflow as the official Android Q&A forum).
• NMRWiki Q&A (http://qa.nmrwiki.org/) is a StackExchange-clone for magnetic resonances, mostly focused on NMR, but also open to EPR/ESR and MRI users. It’s not actually running on the StackExchange platform, but uses the open source OSQA / CNPROG clone, built on top of Django. As far as I know, there is no “CCP4BB for NMR”, which makes the NMRWiki Q&A site potentially even more valuable to structural biologists than it’s crystallography centric cousin, MajorGroove. Back when I was doing my PhD using protein NMR spectroscopy as my primary technique, there were very few good resources like this online – I do less NMR these days, but you can bet that I’ll be using the NMRWiki Q&A and it’s associated wiki to refresh my memory and catch up on need methodological developments in the future.
• BioStar (http://biostar.stackexchange.com/), a StackExchange for bioinformatics, computational genomics and systems biology questions and answers. This one is busier and better established than the above mentioned forums, probably by virtue of the fact the bioinformaticians spend more time in front of the computer than your average molecular biologist or structural biologist.
• And, for a bit of fun: Skeptic Exchange (http://exchange.bristolskeptics.co.uk/), which covers rational questions and answers to various topics including pseudoscience, faith healing, the supernatural and alternative medicine.

Want more ? There are a bunch of science related StackExchanges listed under “Science” here: http://meta.stackexchange.com/questions/4/list-of-stackexchange-sites .. and digging back through the FriendFeed archives I see Matt Todd initiated a concise listing (which if I’d seen, I probably never would have started this post).

And now, the latest* news Stack Exchange 2.0 will be ‘free‘. It looks like they are trying to structure the new Stack Exchange ecosystem a bit like the Usenet hierarchy (comp.*, rec.* etc), with a fairly involved discussion, proposal and acceptance process for new sites – it’s unclear yet whether this approach is going to work out better than just open sourcing the whole shebang, but time will tell. My guess is that BioStar, MajorGroove and probably even an incarnation of NMRWiki Q&A will eventually become part of this formalized ecosystem.

On one hand making StackExchange sites free to run is great – it lowers the barrier to entry to allow many more sites to emerge and operate. On the other hand, as we have seen with the acquisition of FriendFeed by Facebook, not having a clear revenue stream can ultimately leave communities  (such as The Life Scientists) without any certainty in a sites future, potentially impacting growth and participation. Personally I’m much more inclined to invest time in a site if it is something like Wikipedia, where I know my contributions are very likely to live on, in some form, for decades (centuries ?) to come. Ideally the archives of these new Stack Exchange sites could become useful online resources for decades to come – but with a single company at the helm and a “Web 2.0 business model”, continued operation for even a decade seems unlikely. The one saving grace: all content on the new Stack Exchange sites will be licensed under a Creative Commons license – so if Stack Exchange itself is acquired and shut down, we will always be able to preemptively leech the archives and provide them online elsewhere. Maybe it’s strange that I’m already thinking about archiving the new Stack Exchange upon it’s demise before it’s even begun, but I think it’s important to take the long term view with our data and recorded wisdom. Unlike when in 1994 when GeoCities (R.I.P) was started, teh Internets is no longer a fad – the hard disks connected to it are fast becoming the sum of all accessible human knowledge, so we’d better make sure we can retain the good bits for a little longer than 10 years.

* – as all too common these days .. I’m a little behind the curve on this one. I meant to finish this post a month ago, but with a busy time pre-holiday, then the actual holiday, a month has gone by.

Here is my take on an approach to user submitted content to Uniprot. Essentially users should be able to add/change annotations piecewise, directly via the standard Uniprot web page for each protein record. These changes would ‘go live’ immediately, but since a large part of the value in Uniprot lies in its curation by expert annotators, the interface would also provide a very clear separation between user-submitted ‘uncurated’ annotations and the current expertly curated annotations.

I’ve made some mockups of how some parts of the UI may look in my little fantasy world:

• User login box at top (eg, OpenID)
• A History tab at the top.
• User submitted changes tab.
• Maybe a “Discussion” tab, ala Wikipedia (not pictured).
• Each field, or block of related fields, would have an Add/edit button at the top right of the block. (I’ve chosen the Universal Edit Button as an example)

Aftertought: Maybe putting these features under tabs isn’t quite the best place, since the existing tabs are ‘actions’ that can be taken rather than ‘extra info’ to be viewed. This UI detail could certainly be refined.

This proposal has many wiki-like features (history, attribution, open editing, curation by trusted users and potentially page/section locking) but doesn’t really fit my definition of a wiki since the input format is not free-form wiki-text, but is instead constrained by the interface to enforce the submission of (mostly) structured data (eg, a traditional data entry into an HTML form, or in-line editing of fields).

Any authenticated user would be able to add or edit fields by clicking on the “Add/edit annotations” button associated with that block (see mockup above). They would then be sent to a page where they can click to edit a particular field (in this case a point mutation and associated change in function), or click “Add new” to add a new mutation field and fill out the details (I didn’t make a mockup picture for this .. use your imagination). They also must specify one of the standard “evidence codes” from a dropdown box for each change/addition, including the PMID of a publication if relevant. User submissions are automatically flagged with some type of ‘user submitted’ flag too, and a username. Homologs (from UniRef clusters) could also be listed here to remind the user that certain annotations might need to be propogated to other members of the same family, if required (otherwise the curators would do this part, when applicable, for the next Uniprot release). For all I know, Uniprot may already have an interface similar to this, already in use by their professional curators. In effect, I’d like to see the 37signals “One interface” dictum applied.

User submitted changes would not automatically go live on the main Uniprot record page, but can be seen by clicking the “User submitted” tab at the top. Alternatively, the user submitted annotations could be put at the bottom of the page, like most blog comments, but clearly differentiated from the curated data by colour and other visual queues. The REST API could be told to include/exclude uncurated user annotations in responses by an extra query flag in the request (eg &userannotations=true). Uniprot curators can periodically review user submitted annotations and integrate them into the official Uniprot release as they see fit.

Under the History tab, the history of changes to that Uniprot record, both by user submitted changes and by Uniprot release would be available. This functionality is already mostly available under “Entry history->Complete history” at the bottom of the page, but user submitted annotations would also be included here with appropriate diff colouring (eg, coloured differently to curated changes, until they are officially accepted).

Providing user pages at a URL: http://www.uniprot.org/user/some_sensible_username with an associated RSS/ATOM feed would encourage participation by highlighting individual user contributions, and potentially allow a Wikipedia-like community of expert/fanatical annotators to emerge.

The Discussion tab would be used in much the same way Wikipedia Talk pages are – passive users, contributors and curators would be able to discuss the finer details of any submitted annotations. I’m of two minds about this one, since anyone who has read Wikipedia Talk pages knows things can get quite ugly there sometimes. On the other hand, the communication it allows would be important for building a community of annotators and helping clarify contributions.

PS: I’m a Uniprot fanboy. Can you tell ?

I think comfort with meaninglessness is an important skill in studying biology (and probably other sciences too). Many times, during the description of a system, various acronyms are thrown about as labels for entities (or ‘actors’) in that system. An important skill of the scientist is being able to follow how all the actors in the system relate to each other, without necessarily knowing anything about the specific properties of those actors. There are lots of protein and gene names which often bear very little meaning relative to the biological entity that they label, and fixating on what ‘the name’ means simply distracts from the true nature of the entity.

Example: TPR proteins are a superfamily of protein fold, often involved in protein-protein interactions. I have sometimes been asked at poster presentations, or the occasional talk: “What does TPR stand for ?”. “TPR” is an acronym for “tetratricopeptide repeat” … you may be able to glean from that expansion that the protein fold is composed of repeat sequences 34 amino acids long – but that is only one small aspect of the family, and isn’t the important point. Yet many molecular biologists appear uncomfortable with an “undefined” acronym, and insist on having it expanded to reveal the full name. TPR is just a convenient label for the superfamily … it could equally have been called GrratBlat or 5450520A, it would still be the same thing. The point is, you shouldn’t have to ask what TPR stands for. Sure, it’s a curiosity, and some protein names can be amusing (Sonic Hedgehog, or “Just Another Kinase” come to mind), it may also contain some meaning, but first and foremost it’s a label – something to link the entity to all the other descriptive information about it’s structure, function, localisation and regulation. Like many classes of protein, the original name was given at a time when little was actually known about the thing, and typically the meaning embedded in the name should be ignored lest it bias our interpretation about what that protein really does.

Summary of opinion: Molecular biologists should become comfortable with the notion that a name is just a label – meaningless without the associated metadata.

All of this is probably second nature those who studied philosophy (or computer science, or linguistics) … I’m guessing it is an issue of semantics. I really should have taken some of those subjects back in my undergrad days …

For example, typing:

gg open science on friendfeed

into the YubNub search box searches Google for “open science on friendfeed“, via YubNub.

I thought I’d highlight a few life science- and bioinformatics-related YubNub commands I find myself using quite often in my day-to-day work. Some are commands I created, others someone else created. This is the beauty of YubNub … often someone has already made the ‘obvious’ command … it’s worth just trying to search with a command you expect to exist, since it often does.

Onward, with the list:

• pubmed — Searches PubMed
• hubmed — Searches HubMed (Alf Eatons featureful alternative interface to PubMed)
• gopubmed — Searches GoPubMed (an ontology enhanced PubMed search)
• doi — Redirects you based on a Digital Object Identifier (DOI), via http://dx.doi.org/
• pdb — Searches the Protein DataBank for 3D structures. Usually the search term should be a 4 letter pdb code.
• uniprot — Searches the Uniprot database (use an accession, id or keyword as the query).
• ihop — Searches iHOP, information Hyperlinked over Proteins, for views of the biomedical literature guided by gene networks. Nothing to do with pancakes (or prayer).

There is also a class of more general, non-biomedical commands which I often use:

• gg — The Google.
• gim — The Google Image Search.
• wp — Good ol’ Wikipedia.
• ucc – The universal currency converter at XE.com. Use it like ucc 399 aud usd, to convert $399 Australian dollars to US dollars. Then, if you have your cash in Australian dollars, weep about the recent drop in the exchange rate
• man — Like *nix man ‘manual pages’, but for YubNub commands. Eg, man ucc will give the manual page describing how to used the ucc command.
• ls — A bit like the *nix shell ls, this command lists existing YubNub commands that contain your query in their name, description or url. eg. searching ls protein gives you a short list of all the commands related to proteins.

I’ve installed the YubNub opensearch plugin so I can search directly from the search box (or location bar) in Firefox. Maybe one day Ubiquity will fulfill this purpose, since in many way it is the natural progression of the YubNub idea. But for the moment YubNub is the fastest, most streamlined way I’ve found to quickly fire off a search when I need to hunt down a reference, protein sequence or 3D structure. Nothing like instant gratification

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

Recently I needed to install NCBI wwwblast on my local workstation to enable some software that needed to interface with BLAST via the web service. It was straightforward to install, but I took some notes, because there were a few changes required with respect to the official wwwblast documentation at NCBI. These instructions are for Ubuntu 8.04, but probably will work with many recent flavours of Debian.

Download and install

Download NCBI wwwblast from ftp://ftp.ncbi.nih.gov/blast/executables/LATEST/ (The version I used was wwwblast-2.2.18-ia32-linux.tar.gz).

Untar it into /var/www/ , preserving permissions.

$ cd /var/www/

$ sudo tar zxvpf wwwblast-2.2.18-ia32-linux.tar.gz

You will also need to make sure csh (the “C-shell”) is installed, since the blast.cgi script needs this to run:

$ sudo apt-get install csh

(Thanks to jpopesku for spotting this missing package [comments below])

Set up Apache2

The instructions in the official wwwblast manual didn’t seem to work for Apache2 .. (could be a typo: Follow SymLinks should be FollowSymLinks … one camel-case word without the space). I put this in into the VirtualHost definition in the standard /etc/apache2/sites-available/default file used by Apache2 in Ubuntu 8.04.

The code above was inserted just before the </VirtualHost> closing tag.

Restart Apache for good measure.

$ sudo /etc/init.d/apache2 restart

Configure your wwwblast to see your databases

Assuming you already have some existing BLAST formatted databases made with formatdb, you will then need to configure wwwblast to find them, as per the manual. In short, this involves putting the BLAST database files into /var/www/blast/db/ (or symlinking to the files), modifying /var/www/blast/blast.rc (or one of the other *.rc files, for other BLAST programs, eg psiblast) to associate the database name with a BLAST program, and modifying the dropdown database list in /var/www/blast/blast.html (or one of the other *.html files for other BLAST programs) to add the name of the database(s).

My BLAST databases live in /data/databases/blast/, so I simply moved the example database directory /var/www/blast/db to /var/www/blast/db.orig:

$ sudo mv  /var/www/blast/db /var/www/blast/db.orig

then symlinked /var/www/blast/db to /data/databases/blast:

$ sudo ln -s /data/databases/blast /var/www/blast/db

In /var/www/blast/blast.rc I changed the line:

blastp test_aa_db

to:

blastp nr swissprot pdbaa

(you may also want to configure blastn etc in the same way)

In /var/www/blast/blast.html, I changed the test database code:

to:

(you may want to do this for other BLAST programs too, eg also edit psiblast.html)

This will allow be to search the nr, swissprot and pdbaa databases I have installed using plain-vanilla BLAST.

Test it out

Go to http://localhost/blast/blast.html.

You should find the wwwblast interface, with a dropdown box featuring the database(s) you added. Run a test search with your favorite sequences (ensure you also select the correct blast program, eg blastp !). Enjoy using your own CPU time !

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.

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.