In October 2012, F1000 Research applied for inclusion in PubMed Central. In January 2013, F1000 Research trumpeted that their content would be indexed in PubMed based on its approval for inclusion in PubMed Central. Yet, as of this writing, no F1000 Research content has yet appeared in either PubMed Central or PubMed. As Rebecca Lawrence, Publisher for F1000 Research, explained in an email in response to some questions (response dated April 21):
. . . there’s been a delay. I think it’s pretty standard for there to be a hiatus between a journal’s being approved for indexing and its actually going live on PMC, but in our case it’s a slightly longer story.
This is what’s happening: We’ve been working with PMC to finalise the xml tagging, which is more complex than normal for us because we have versioning and also because PMC is going to index all the referee reports and comments plus all the underlying data. We are very nearly ready to go now and PMC has prepared the first batch of articles so I am hopeful that those first articles will show up in a week or so.
So far, there are still no F1000 Research articles appearing in PubMed Central.
A review of email correspondence surrounding the tagging and ingestion of F1000 Research content reveals the fundamental flaws of PubMed Central – its activities consist of redundant and duplicative efforts; it is overly complex and bureaucratic; and it costs the US taxpayers millions of dollars per year when its core functionality could be realized for a fraction of the cost, if not for free.
Because F1000 Research has a bewildering peer review model, one that allows multiple versions of the same article to exist simultaneously, supports iterative open peer review, and leverages the standards of indexing services as its editorial approval standards, the tagging model posed some obvious initial challenges, especially with versioning, as this email from Ed Sequeira from January 10, 2013, shows:
This email reveals a few problems PMC had to spend a lot of hours wrestling with — synchronizing feeds, dealing with multiple version files for one article, and the perplexing problem of the article that is accepted and later rejected, a problem I didn’t see solved in the emails received so far.
Remember, this email was sent in January, but discussions started much earlier, as emails from October 2012 show. The following comes from an email dated October 23, 2012:
Later emails show that capturing the various reviewer responses led to Sequeira proposing a complex color-coded tagging scheme that was proving frustratingly complex to some of his colleagues.
Fast-forward back to January 2013, and one of the main engineers seems to be giving up hope that the team at PubMed Central could ever adequately tag to the F1000 Research model:
Where does the redundancy and expense come in? Quite simply, government contractors, staff, and management at PubMed Central have all been involved for months and many, many meetings and test flights of files in solving a tagging protocol that F1000 Research had already solved. This is the epitome of redundant activity. If PubMed Central were merely an indexing service with signposts to the final versions, ala PubMed, it would cost far less to run, and problems like this wouldn’t arise.
F1000 Research is not the only publisher having to go through this duplicative and expensive process — the head-spinning complexity of its model merely makes the redundancy and expense vividly clear. Aside from PubMed Central’s perceived favoritism for eLife, over the past year the largest complaint I’ve heard from OA publishers is that PubMed Central is slow, difficult, and erratic in how they work on technical standards and content ingestion.
Posting and hosting duplicative copies of published articles not only costs US taxpayers money, it costs publishers money, as well. That’s inefficient, which makes it irresponsible.
You may believe that I personally think PubMed Central needs a serious reboot – at the management level, at the vision level, and at the technical level.
If so, you are quite perceptive.