Precedings, pt2

We're going to try using groups and forums on Nature Network as places to discuss Web Publishing products. The idea is that Network's limitations will become apparent very quickly (well, not very quickly, it's well written - but complex and still relatively new) and we'll be able to prioritize fixes and new features better. This makes sense. Before anybody mentions it in the comments I think that Network needs RSS too. AFAIK it's on the to-do list.

Anyway, Precedings has a group there which you can use to request new features, discuss the issues surrounding biomedical preprints, ask questions about the site, etc. Hilary Spencer (who runs Precedings) has already posted about submitting research to Precedings vs just posting it on your blog.

It's interesting stuff - wasn't there a similar discussion on NFTB or Nodalpoint or somewhere a while back, about using WebCite to archive blogged research?

Take a look.

Publishers, trackbacks and shared data

The elevator pitch version of this post: if you're a science publisher interested in the web then let's talk about collaborating on a shared system that will stimulate online discussion, kickstart commenting and recognize the sometimes valuable contributions already being made every day by science blogs.


I'm a strong believer in allowing commenting on online papers. This is something under serious discussion at Nature (the question is how to do it properly). The vast majority of researchers read, organize and discover papers online; we should give them the tools and opportunity to discuss papers online, too.

It's easy to be dispirited by the lack of comments on early adopters - though what would an appropriate number of comments on a paper be? Is one comment pointing out a critical error worth more than a hundred saying 'nice paper'?

In the relatively near future two things will happen to help push commenting forward:

• We'll (scientists in general) develop systems that track and credit scientific contributions - including relatively minor ones like wiki edits and comments - that aren't in manuscript form.


• We'll make it easy enough to leave comments and for content stakeholders to be alerted so that they can reply for a positive feedback loop to kick in - more authors responding means commenting is seen to be more useful, so more comments are left... etc.

Until then, though, there is a way of supplementing comments submitted directly to journals: science blogs.

I think it's fairly safe to say that the number of blog posts discussing papers is much, much larger than the number of online comments left on papers from all STM publishers combined. Prove me wrong and I'll take you out for cocktails.

Some specific examples of papers discussed in blog posts:

This recent paper in Cell has no comments but three blog posts written about it. This paper in PLoS One has two blog citations but only one comment (which is a link to one of the blog posts - this has been discussed previously on the PLoS One blog).

So how can publishers use blog content to supplement commenting systems? I think Postgenomic is the answer, or at least a good starting point.

Postgenomic is a science blog aggregation site with an open source codebase. The data it collects is accessible via a REST based API.

Postgenomic follows several hundred science blogs and tracks the papers that they link to. Publishers can easily - and should, IMHO - access this data and display blog trackbacks next to the papers that they publish online.

Technorati or a homegrown system could possibly be used to do the same thing. Here's why STM publishers should use Postgenomic instead:

• Postgenomic was written specifically to deal with scientific literature. It handles tricky things like disambiguation: a single paper X might be linked to at different URIs by different blogs (imagine that one blogger links to the abstract on PubMed, another to the PDF and a third to the fulltext view). It understands DOIs and PMIDs. We have a lot of experience with this sort of thing at Nature - see Connotea.


• As the list of aggregated blogs is strictly controlled there's no need for publishers to manually curate each and every trackback on their papers.


• Postgenomic has been running for more than a year and is recognized by the community - at least to the extent that new blogs are submitted regularly. If somebody starts a new blog and wants to be included on paper trackback whitelists, or a blog changes address or an archive is deleted then it makes sense for there to be one, central place for this to be dealt with. The science blog community is relatively small already, why fragment it further?

My suggestion is that wherever you'd allow comments on papers you also collect trackbacks, displaying the title and excerpt of blog posts citing the paper in question.

Blog trackbacks on papers are a winning proposition for everybody involved. Bloggers get recognition and increased exposure, readers get more relevant content, publishers get papers worth coming back to after you've downloaded the PDF, authors see more discussion surrounding their research.

If you're interested in talking about this further then please get in touch.

Precedings

Precedings launched officially last week. Pedro has blogged his impressions with the closed beta already. Egon and Deepak both had posts about it too. It's now open to everybody.

The thirty second overview: it's a preprint server for the life sciences. Submitted manuscripts gets a DOI and are citable. There's no peer review (though you can leave comments).

Facebook as a platform, pt2

I thought that it might be useful to blog my experiences with the new Facebook Platform API. For the past two weeks I've been working on Bookshare in my spare time. Bookshare is a book review site with social networking features (feel free to sign up and let me know what you think).

Anyway....

Facebook makes you think about scalability

Here was my first harsh Facebook lesson: apps can spread fast. Not necessarily exponentially but always faster than you can iterate over your code optimizing it. Quick hacks come back to bite you in the ass hours after you implement them, rather than months, because your userbase can double overnight.

Here's a fictional but in no way implausible scenario: imagine that you wrote an application that shows lolcats on people's profile pages to try out the Facebook API. You make the app public and then forget about it. A week later it has 1.7 million users.

A good problem to have? Maybe. Until you get your bandwidth bill (not a problem for images, luckily, as Facebook caches them locally, but still) or you want to use your server for anything else... ever.

Usually if your site slowed down a bit you'd be OK, but unfortunately:

Facebook times out. A lot.

If you visit

http://apps.facebook.com/bookshare/dashboard.php

then Facebook fetches the output of dashboard.php from my server and renders it inside of the Facebook page template (containing the Facebook logo, sidebars, footer etc.).

The problem is that there is an awfully short timeout on the Facebook server fetching remote pages. If your site is being slower than usual (because of an unoptimized SQL query, perhaps?) then this is reflected on Facebook by all of your application's canvas pages being totally unavailable - they get replaced with a non customizable 'could not retrieve page, try again in a couple of days' type error. A couple of days? Way to drive off users. What's wrong with suggesting that they hit 'reload' instead?

Imagine getting 1.7 million messages of complaint from angry lolcatters who can't access your app any more.

Official support is a bit lacking

I can kind of understand this as they've presumably been inundated by requests and bug reports, but for a company that's done right by developers in so many other respects their direct support sucks. I emailed off a report about a specific bug and got back an intensely annoying 'thanks for trying the Facebook Platform, all the documentation you need to get started can be found online' form letter reply.

The documentation was written by developers

The official client library is in PHP (as is the UI of Facebook itself). Unfortunately the online documentation only ever refers to the underlying REST calls to the server, so you have to actually delve into the code to see what the naming conventions are.

Despite all this, it's brilliant

You don't have to worry about persuading users to come visit. You don't have to write login or session handlers. Or friends lists. Or a messaging system. Your images get cached. The audience is large. The API is well designed.

I think they're on to a winner.

Scintilla

We're doing some pre-launch tweaking of Scintilla, a new science aggregation product, at Nature. It's a something that Alf and I have been working on recently (well, Alf has been working on it, I mostly just complain and then swoop in to take credit by sending out invites at the last minute ;)).

You're welcome to check it out and send any comments, suggestions or bug reports to scintilla@nature.com. We'll be acting on your feedback, so do drop us a line.

There'll be more official announcement on Nascent later.

If you're goin' to San Francisco...

I'll be in San Francisco for a couple of days at the beginning of August (1st-3rd), before SciFoo.

Anybody in the Bay Area fancy meeting up?