[Open-access] HEFCE OA policy and the issue around date of acceptance

[Reimer, Torsten F]

First of all to state for the record: I am not suggesting universities should rely on the publishers for this but rather that they could help us to make the process smoother. The HEFCE policy requires robust systems and process in place to monitor this and I should think that is what all institutions are aiming for.

I like the workflows as suggested by Cameron, although in my ideal world (it is Easter after all) I'd like the IR to be copied into the email and automatically ingest the data so that author/librarian would only have to press an approval button. This may be more difficult to implement though. Anyway, just getting the email with the file and the metadata, even if it all has to be copied in manually, would be helpful I think.

Happy Easter,
Torsten

From: Cameron Neylon [mailto:cn at cameronneylon.net]
Sent: 14 April 2014 12:10
To: Reimer, Torsten F; 'open-access at lists.okfn.org'
Subject: Re: [Open-access] HEFCE OA policy and the issue around date of acceptance

So this is an interesting challenge for an OA publisher who wants to be able to sell the concept of "publish with us and you're always compliant". That said its an interesting opportunity to sort out some of the pain points in the workflow of deposition. In turn it offers an opportunity for publishers to provide services that help, while at the same time allowing IRs to ensure that they're not relying on publisher systems.

I agree with Stevan that institutions shouldn't rely on publishers. We've had several weeks of demonstrations of why that's a bad idea with the Wellcome and Cambridge University data releases. But that doesn't mean that those of us who want to help shouldn't.

An interesting workflow might look like this:

  1.  Paper accepted
  2.  Publisher sends email to author containing: final manuscript, link to IR deposit site, metadata package
  3.  Author clicks on link, then drags and drops the metadata package file and manuscript onto the deposit window, IR does the rest
  4.  IR notifies publisher of an update link/webhook for any further deposits of updated versions
  5.  At any additional update publisher sends a similar email, If author wishes to update the IR with proofs or final published version they can follow the same workflow each time
  6.  IR can poll publisher for any updates if it wishes, and publisher can notify IR of any updates as appropriate.
This could be a nice example of creating systems which can talk together to be helpful, but ultimately aren't dependent on any other player in the system. At the same time it enables a publisher to be helpful, without requiring that an IR use 'their' system. All it would really require is a deposit form that can accept a dropped file and the defined format for that package.

Cheers

Cameron

From: "Reimer, Torsten F" <t.reimer at imperial.ac.uk<mailto:t.reimer at imperial.ac.uk>>
Date: Wednesday, 9 April 2014 16:15
To: "'open-access at lists.okfn.org<mailto:'open-access at lists.okfn.org>'" <open-access at lists.okfn.org<mailto:open-access at lists.okfn.org>>
Subject: [Open-access] HEFCE OA policy and the issue around date of acceptance

Dear All,

A potential issue with the HEFCE REF/OA policy's focus of "acceptance" as opposed to "publication" is that institutions have no way of knowing whether an academic is about to publish a paper unless they tell us. Had it been date of publication (+3 months) there would at least have been a chance that our CRIS could have picked up there is a new publication so that we could have checked whether it has been made open access in the way the policy outlines - or alternatively work with the author to make that happen.

Now, it will be in the interest of the author to meet the requirements of the policy and we can certainly put effort into communicating the policy, but even assuming everyone is aware of it an plays along there is still the issue that at the point of publication we only have incomplete metadata. So the academic has to somehow share the accepted version of the paper with us, including what metadata they have. Once we know the publication date we then have to update that record and set the correct embargo period (where there is one) from the date of publication. Now, the latter step can be automated, the first one can't.

...unless: Wouldn't it be great if the publishers would, on the date of acceptance, alert us to the fact that there is an article, send us the metadata and ideally also the peer-reviewed manuscript - preferably in a way that can then go directly into the repository. That would ensure that no article is forgotten; it would not burden the author with extra effort; it would ensure we comply with the policy;  and finally, the publisher and the university could be confident that the correct version ends up in the repository, so we can forget about takedown notices etc.

Especially with more widespread use of ORCID I cannot see a reason why in principle this would not work. What are your thoughts?

(While I am thinking naïve thoughts: Wouldn't it be great if articles would be submitted through a kind of shared system that did all of this work in the background, even the reporting and compliance? Automate the process for everyone? This may be unrealistic, but if I were still at Jisc this is what I would at least consider.)

Best wishes,
Torsten

Dr Torsten Reimer
Project Manager (Open Access)
Research Office
Level 5, Sherfield Building
Imperial College London, Exhibition Road
South Kensington, London, SW7 2AZ
Tel: 020 7594 3190  Fax: 020 7594 1265
http://www3.imperial.ac.uk/researchsupport
https://twitter.com/torstenreimer

_______________________________________________ open-access mailing list open-access at lists.okfn.org<mailto:open-access at lists.okfn.org> https://lists.okfn.org/mailman/listinfo/open-access Unsubscribe: https://lists.okfn.org/mailman/options/open-access
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-access/attachments/20140416/d5615b32/attachment-0002.html>