St George's have raised an interesting issue.
So, it turns out that 2020 is a leap year (so 366 days) - and this unfortunately impacts on REF OA compliance related to maximum embargo periods. If the 'Maximum file embargo' period has been input as 365 days, any 12 month embargo period spanning 2020 will come up as not compliant.
It feels like the most pragmatic solution would be to simply change the 'Maximum file embargo' days to 366. I think there could be a very strong argument for this remaining compliant with the *spirit* of the policy. Further, when the REF OA policy was originally published, we had gotten confirmation from (then) HEFCE that 1 month could be interpreted as 31 days - so you could make the argument that then 12 months = 372 days.
How does the rest of the community feel about this? It would be great to hear your thoughts.
Thanks for posting this up. I was thinking as well after we discussed this, how are other systems/monitoring plugins handling this - eg REF Compliance Checker, or Pure for instance. Do they refer to actual calendars for compliance, or just stick to a notional 365 days?
Maybe others will have some insights. If everyone is just using 365/6 for now, I guess we'd be ok
By 'REF compliance checker' - do you mean the Sherpa REF service? I'm not sure how they calculate '12 months' ... we could find out :) Ah, but wait ... this service just states the publisher's embargo policy - it doesn't actually do any calculations ... so I don't think this is an issue for them.
For Pure, they are only just now introducing logic around the embargo period maxima - and I have to admit, the thought of leap years never even crossed my mind when I spec'ed the functionality! Depending on how the period is implemented, some programming languages do the leap year calculations automatically ... I could see if I could find out how Pure are handling it :)
Curious what others' (Elements institutions) thoughts on this are :)
REF CC plugin info is here http://bazaar.eprints.org/1113/ plus
I think there is a DSpace vers but we're not a DSpace user - see https://www.jisc.ac.uk/repository-technical-support
SHERPA REF service you maybe thinking of https://ref.sherpa.ac.uk/
Now that the REF audit guidance has been published https://www.ref.ac.uk/media/1164/ref-2019_04-audit-guidance.pdf this says that as they are looking to confirm that data are "accurate, verifiable and robust" there will be checking made of what we say about our compliance by using data from Crossref & CORE (point 40):
"Research outputs (REF2)
40. We will undertake verification of the dates that outputs became publicly available, particularly where they were published early in the REF period or are marked as ‘pending’ publication (for example, by obtaining a letter from the publisher). This will include checking the publication year against the Crossref database and against Jisc CORE"
"46. iv. Using Jisc CORE, comparing the datePublished and depositedDate and identifying where the number of days between the two dates is greater than 92."
"OA Policy Settings
Reading the audit guidance, they don't seem to cover any checking of embargo periods per se (other than the overall check whether a journal is compliant with the policy)... which is interesting - but my reading of the guidance in this area is what they have prescribed that they will check, that's just the first phase of compliance checking. If any flags are raised during this first phase, then anything is open to verification.
But yes, reading the guidance we provide in the FAQ on 'How should I configure the settings?', this appears to continue to align with the expectations of REF and more specifically, the newly published audit guidance.
At Liverpool we've got "deposit within three months" - swapped from 91 days - and depending on faculty we have the maximum embargo periods set to 366 and 731 to account for leap years.
It might be worth looking back at this feature request which was requested a couple of years ago:
OA Monitor - deposit deadline needs to use a calendar to accurately calculate deposit within 3 months
This was implemented as the ability to set the deposit deadline in months or days - if there was a calendar behind this then that would make it more accurate eg for this scenario
Or otherwise could there be some code written specifically to calculate according to 366 days for embargo periods spanning 2020?