You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an item contains a document which is open access, content: accepted / published, visible: anyone, embargo: none/past, this causes the field hoa_date_foa, the date of first compliant open access to be set. This happens in...
cfg.d/hefce_oa_triggers.pl
When the checker comes to see if the item has a document which will be open access within the bounds of the stipulated times for the different panels 12/24 months, the item is seen as open access. Because it has no embargo period.
This makes sense, unless the open access document was set as such by mistake. If a user sets the document to be visible to staff only and sets an embargo period after the fact, then the item will not have the embargo period length field (hoa_emb_len) updated because it already has the hoa_date_foa field set. This plays out in line 102...
cfg.d/hefce_oa_integration.pl
I am hesitant to create a "fix" in case this is done by design. But it seems to me that an item without an open access item (outside of embargo timeframes) should not be reported as compliant even if it was once the case (by mistake or otherwise).
The text was updated successfully, but these errors were encountered:
Hi @fatchild ,
This is something that was discussed at some point in the past.
The following configuration option was added - to allow 'mistakes' such as the one you describe - that are quickly resolved - to be automatically fixed:
# If this configuration value is set, and an item is updated within the number of day specified,
# the FOA date can be removed, if the item no longer has an appropriate Open Access document attached.
# If the value below is commented-out, or undef, no FOA retractions will happen.
# If the value below is 0, then only updates on the same day can alter the FOA date.
# If the value below is 1, then updates on the same day, or the day after the FOA date may change the value.
# A value of 2 means up to 2 days after the FOA date... etc.
# The value below
$c->{hefce_oa}->{foa_retraction_period} = undef; #number of days
IIRC (it's been a while since I had a deep conversation about this stuff), there are circumstances where a repository AAM has been open-access for a period, but then restricted as publisher's version is available from their site, and the author wants traffic to go to the 'official' version.
It might be useful to know about this: https://github.com/eprintsug/ref_cc_c
which I think would detect the situation you describe - and could also update the metrics accordingly.
PS Did you get my email about ExifTool - or did Outlook scupper that?
If an item contains a document which is open access, content:
accepted
/published
, visible:anyone
, embargo:none
/past
, this causes the fieldhoa_date_foa
, the date of first compliant open access to be set. This happens in...When the checker comes to see if the item has a document which will be open access within the bounds of the stipulated times for the different panels 12/24 months, the item is seen as open access. Because it has no embargo period.
This makes sense, unless the open access document was set as such by mistake. If a user sets the document to be visible to staff only and sets an embargo period after the fact, then the item will not have the embargo period length field (
hoa_emb_len
) updated because it already has thehoa_date_foa
field set. This plays out in line 102...I am hesitant to create a "fix" in case this is done by design. But it seems to me that an item without an open access item (outside of embargo timeframes) should not be reported as compliant even if it was once the case (by mistake or otherwise).
The text was updated successfully, but these errors were encountered: