- REF Open Access Compliance Checker for DSpace
- Submitting compliant items
- Workflow
- Accessing compliance information for live items
- Curation task to set Date of first compliant Open Access (FOA)
This documentation describes tools created to assist institutions using DSpace repositories to comply with the audit requirements for Open access in the post-2014 Research Excellence Framework (REF).
Try out these features through the online demonstrator at https://hefce.atmire.com
These tools rely on the RIOXX metadata profile and guidelines. In addition to the fields offered by RIOXX, following fields were added to comply with the open access requirements:
- REF target panel
- Date of first online publication, to be used in cases where an article is already available online before the official (print) publication date
The following 3 additional fields were also added. Unlike the previous fields, these are calculated automatically by DSpace and should not be manipulated manually in a production system:
- Date of first compliant deposit (FCD)
- Version of first compliant deposit (version FCD)
- Date of first compliant open access (FOA)
For testing purposes, we have made it possible on https://hefce.atmire.com to manipulate these automated fields by hand. This is why the submission on the demo server includes a step that looks like this:
Even though these dates are set automatically by DSpace in a production environment, someone who is testing the functionality can use this dialog to experiment by manually setting these dates and assessing the effect on the compliance of the item.
A part of the requirements as described in the REF information and audit requirements encompasses the open-access policy. The policy defines a number of exceptions to cover cases for publications that will still be eligible for the next REF, even though they don't fully comply with all openaccess requirements. A specific step has been added to the DSpace submission process, so a user can fill in exceptions as to the reason why a deposit, publication, etc does not (fully) comply with the open access requirements.
An additional submission step has been added to give the user the possibility to enter these exceptions (NOTE:Only 1 exception can be given for a single item). The "Exceptions" step occurs after the upload step and contains a couple of options, based on a configuration.
The initial page preselects the "No Exception Applicable" checkbox.
Upon clicking a different option, extra fields are presented to the user. These extra fields are also configurable in the same file as where the configuration for what options to show is set.
Apart from the "No Exception applicable" There are 2 different "types" of exception-views.
- Deposit, Access and Technical Exception -> These Exceptions all have subdivisions. This is shown as a dropdown box containing extra options. The helptext underneath the textarea changes depending on what option was selected.
- Other Exception -> This only contains the input field where the user can fill in the explanation of the exception.
As stated before, only 1 exception can be present on a single item, if a new option/explanation is set, the previous is removed. If, during the reviewstep or the workflow review, the exceptions step is shown again, the page preselects and prefills the saved data.
The DSpace submission forms have an out of the box feature to hide or show metadata fields in the describe steps, based on publication type specified at the start of the submission. This is often referred to as "type dependent submission".
However, it was not yet possible to show or hide entire submission steps, based on a publication type.
Because the REF OA exceptions only apply for conference and journal publications, a type dependency system has been put in place to hide the step to register exceptions and assess compliance for other publication types. Currently, the type-dependency is set to only show the Exceptions and Compliance step for items with rioxxterms.type "Conference Paper/Proceeding/Abstract" or "Journal Article/Review".
The steps are hiddin up to the point when the publication type is defined.
If we then select one of the configured types, we can see that 2 more steps have appeared in the progress bar.
The Compliance submission step provides an overview of the submission's compliance with the open access policy. If the submission is not compliant then this page will explain why and how the submission can be made compliant.
The color of the bar at the top of the page content will immediately make it clear if the item is compliant. The bar will have a green background if the submission is compliant, or an orange background when a rule has been violated.
If there is a violation then another orange bar is shown under the top bar with a summary of the actions the submitter should perform to make the submission compliant.
When the submission contains a 'technical' or 'other' exception, a section "Technical and Other Exceptions" is visible. This section contains information about the exception.
The Compliance page contains a separate section for each category of requirements.
If a requirements section title is grayed out, none of the requirements in that section are applicable on the submission. If a requirement is grayed out then this requirement is not applicable on the submission.
Requirements that are not applicable to a submission are hidden by default. To show all requirements, link "show all rules" under the top bar(s) can be clicked.
Requirements and requirements section titles have a question mark next to their name. When the submitter hovers over these question marks hints appear with extra information about the requirement or section.
At the bottom of the page section "REF Compliance related data" shows an overview of the submission's metadata that is relevant when determining if a submission is compliant.
Some of these values contain text (estimated). These values were estimated so that they could be used in the compliance check. They will receive a “real” value upon item archival or at the end of the embargo.
The workflow Compliance step provides an overview of the item's compliance with hefce. This step's overview contains the same information as the submission's compliance step.
The workflow reviewer has 2 options after reviewing the compliance step:
- Continue: Finish the compliance step and send the item to the final edit step. Note: This option might be disabled if the item is not compliant with the HEFCE policies. Collections can be configured to enforce item compliance before allowing the submission to continue.
- Return: Return the item back to the edit step to resolve the issues found by the compliance step.
Compliance information is also available for live items in the repository, with a display that is similar to the one shown in the submission and workflow dialogs.
To view the item compliance view of an item the user can visit the item page and click on menu option "Item compliance" in the "Compliance" menu.
Note: Access to compliance information for an item is only available to the original submitter, administrators and members of the group "REF Compliance Viewers". Users not in one of those groups, including anonymous users, are not able to access compliance information for archived items.
For items that are deposited without embargo, date of first compliant open access is set immediately when the item becomes live in the repository. For items under embargo, it is necessary to wait until the embargo actually expired and the item becomes available. The date of first compliant open access is never set to a date in the future.
A curation task to set the Date of first compliant Open Access of an item is available from the list of curation tasks for items, collections and communities.
This curation task checks the embargo of an item's bitstream and updates the Date of first compliant Open Access to the end date of the embargo if the embargo has expired.
The Date of first compliant Open Access is stored in metadata field refterms.dateFOA. This date is considered to be immutable: it should not be manipulated manually by an administrator once it is set.