The paper was a review, published on the recent MDPI journal, “Animals” (http://www.mdpi.com/2076-2615/3/1/238). At first I was very apprehensive because I didn’t know the publisher – although they have been around since the 90s – and the journal itself was only in its third year of activity, and for that sake it didn’t have an impact factor yet (and it still hasn’t).

However, I took the time to read their editorial policies, to browse their articles, check the authors that had published in that journal and look at the editorial board. There were very few “top dogs”, but some of them were fairly known. Since it was a paper not central for my line of research – it was actually a “side-project” of mine – I took the chance, although I was already fairly convinced of its trustworthiness when I submitted the paper.

The reply from the editorial office was surprisingly fast. My paper was assigned to four anonymous reviewers – although I don’t know if it was double-blind, i.e., if they could know who was submitting the paper – with expertise in the field. All four of them gave fast (~two weeks) and very thorough reviews of my paper, that contributed immensely to its quality (so much that I included their contribution in the acknowledgements section).

The review/copy-editing process went smoothly and, overall, I was very well impressed. It actually went much better than with other reputable journals to which I had submitted manuscripts before. So far, the paper got many good online and personal comments by people and institutions with an interest in the use of animals in science (both from the “pro” and the “against” side), which may also give some insight into its quality.

I can’t speak for other MDPI journals, and I know some issues have arisen with a few papers published in some journals from this publisher (although the mere fact that they have retracted them and discussed this matter openly is a clear indicator that they are reputable), but I would recommend anyone who is all for open access but concerned with quality peer-review to submit to “Animals”. Of course, you also have to be honest and contribute to the transparency and “ethicality” of the process, by suggesting reviewers that 1) you consider to have right expertise in the field and 2) you don’t know personally (some people would advise AGAINST the latter, but that’s my view, anyway)

However, even if one is not obsessed with impact factors, most of us still need to publish papers in already established journals, so “Animals” may not probably be a first choice, yet. However, I will definitely consider it as a first choice for publishing secondary (but nonetheless relevant) work in the future. And, of course, I’m sure I’ll be submitting more important manuscripts as soon as they are given an IF.

Thanks for the reply, this is very helpful. My only quibble is that you attribute the motivation of my archive or Karthik’s Github archive to having a DOI. Personally, I agree entirely that the idea that this somehow makes it ‘citable’ is silly. My motivation, and possibly that of others, is almost entirely based on CLOCKSS backup. It is too easy to make the objection to someone providing data/content on either a personal site or on Github that there is very little to guarantee that content won’t be lost forever. Clockss isn’t perfect but it is a lot better.

I’m going to reply briefly here, as I think a full reply requires more space.

“I think Geoff does a good job pointing out the social contract dimension of successful archiving”

In this, Geoff is entirely correct. With Greycite, for instance, we cannot currently offer any form of service guarantee. As Geoff points out the technological base of crossref DOIs are nothing special.

“I have recently been thinking that I should be archiving my HTML directly instead, not least because it is a more standard format and contains metadata not found in the markdown.”

In 100 years time, if anything of us survives at all, it will be HTML. With any form of archiving, is is not simplicity, but sameness that counts. People in the future will be able to recover HTML because it will be worth the effort of doing so as this will give them access to millions of documents.

“On the downside, archiving a whole web directory with its CSS and JS, etc, seems cumbersome.”

Not your problem. People have been working on how to archive websites. Let them do this for you.

“While the figshare online display leaves something to be desired in archiving html files, and more to be desired in archiving git repos (e.g. vs Github, where interaction is easy) it seems those are UI problems more than archival problems.”

No. The problem is that the link between your Figshare DOI and what you are archiving is completely ad-hoc. You want to archive your website; you have not done so. You have archived something else entirely.

“I certainly see the advantage of being able to download and interact with Karthik’s git repo if I wanted to explore the history, even if it would be preferable to use an online-based exploration.”

Same problem. And why have you done this? Because of the “magic” quality of the DOI. Figshare says “make your data citable”. But this is nonsense. Your website was already citable. Giving a DOI to something else does not make it more so.

Of course, if you have minted a DOI, have it resolve to your website, and have a third-party escrow system which monitored your website, and moved the pointers to figshare if your website went 404, that would be useful. Better still, actually, would be to point to archive.org, or a web archiving solution, so people could view things. This is what greycite does (although with purls).

“(Minor comment, you missed the citation in your link to Karthik’s archive.)”

Sorry. It was there, but was being too clever with my hyperlinking. This will fix itself presently.

“Ensuring the existence of a copy is hard enough, but I think ensuring it has a persistent identifier is even harder (which gets back to Geoffery’s arguments I guess).

I think it misunderstands Geoffs arguments. Now, I think two-step identifiers have major problems for other reasons (which I will blog about at some point!), but as Geoff says, a two step identifier is no use at all *unless* someone updates the endpoint; I would add the second rider, which is and the endpoint is correct in the first place.

If you want persistent identifiers for your blog, my suggestion: generate a partial redirect purl, using http://www.purl.org. You do use a partial redirect, so you only need to do this once. If you move domain, you can update the endpoint. Then add a line to your will and testament saying that in the event of your death, this should be altered to point to http://wayback.archive.org/web/http://www.carlboettiger.info/. As Geoff says the solution is partly technical, partly social.

I think Geoff does a good job pointing out the social contract dimension of successful archiving, and I’d be quite curious what you think about his arguments.

Thanks for the mention and the feedback about archiving my notebook — it’s something I’ve asked myself. I went with markdown files since they are plain text (I could have given them .txt extension instead I suppose), and seemed the simplest to read even if you had no background or rendering software. I have recently been thinking that I should be archiving my HTML directly instead, not least because it is a more standard format and contains metadata not found in the markdown. On the downside, archiving a whole web directory with its CSS and JS, etc, seems cumbersome. Any thoughts on which is the lesser evil?

While the figshare online display leaves something to be desired in archiving html files, and more to be desired in archiving git repos (e.g. vs Github, where interaction is easy) it seems those are UI problems more than archival problems. I certainly see the advantage of being able to download and interact with Karthik’s git repo if I wanted to explore the history, even if it would be preferable to use an online-based exploration. (Minor comment, you missed the citation in your link to Karthik’s archive.)

Anyway, very good points and I agree it feels like we have no perfect solutions at this time. I see having copies of my notebook on Github and figshare more as hedging my bets than an ultimate solution. Ensuring the existence of a copy is hard enough, but I think ensuring it has a persistent identifier is even harder (which gets back to Geoffery’s arguments I guess).