Editing REF CC (section)

==Using the REF Compliance Checker plugin==
The REF Compliance Checker plugin integrates with the DatesDatesDates and RIOXX2 plugins. At a later point in time there will be further integration between the REF Compliance Checker and the REF Support plugin.

The REF Compliance Checker is able to produce reports showing by year which items are eligible for the REF. In order to enable this feature, the Generic Reporting Framework will need to be installed from the Bazaar (Generic Reporting Framework version 1.0.0+). This same package is also required for the RIOXX2 plugin.

===Installation===
The REF Compliance Checker plugin is available via the EPrints Bazaar. This is accessed from the “System Tools” tab on the Admin screen. A Bazaar package is normally installed by clicking the “Install” button next to a package displayed on the “Available” tab.

===Upgrading to version 1.3+===

When upgrading to version 1.3 or higher, please ensure all eprint records are recommitted. This will set the hoa_exclude field to FALSE by default, ensuring that all records appear in the Generic Reporting Framework reports.

<pre>
./bin/epadmin recommit repoid eprint --verbose
</pre>

===Changes to the workflow===
Once installed, a REF CC tab will appear in the workflow.

[[File:workflow.png|800px|thumb|none]]

Selecting the REF CC tab will open the user interface to the plugin.

[[File:workflow2.png|800px|thumb|none]]

===Working with the REF Compliance Checker plugin===
It is important when depositing an item that the content is correctly specified: the drop down list associated with the Content field, found in the optional section of the Upload stage of the workflow, enables the depositor to identify an item as being Accepted or Published. The REF Compliance Checker plugin refers to this information to help establish whether an item is eligible for the REF. In view of that, the repository administrator may choose to consider whether the Content field should become mandatory.

[[File:doc_content_field.png|800px|thumb|none]]

The metadata entry process for the Details and Subject sections of the workflow will be very familiar to EPrints users and the Compliance Checker plugin changes nothing here. Similarly, the RIOXX2 metadata collection page is standard and is being used by an increasing number of institutions that use EPrints.

The depositor may select a REF panel if appropriate; this is important because the maximum allowable embargo period differs according to the REF panel selected.

The one-screen user interface to the REF CC plugin is designed to collect metadata that cannot be entered elsewhere in the workflow process and provides an additional opportunity to enter key metadata if it has not been entered elsewhere – such as the date of acceptance. In particular, depositors can specify the REF panel relevant to the item being deposited and exceptions may be claimed. If depositors select one of the radio buttons in error, selecting the “Unspecified” radio button will override the erroneous selection.

[[File:hefce_stage.png|800px|thumb|none]]

Once a record has been deposited, the REF Compliance Checker plugin will then perform its logic-based tests on the metadata that has been supplied. The next screen provides an example of a record that is compliant with the Open Access policy. The plugin clearly indicates which data have been used to check compliance with the various different aspects of the policy: deposit; discovery; access or whether any exceptions have been claimed.

[[File:hefce_tab.png|800px|thumb|none]]

Where a record is ineligible this will be clearly indicated. The plugin will indicate where the deficiency lies. Clicking the “More” link provides more detailed information about the particular requirements of the Open Access policy. In some cases it may be, for instance, that a key date is missing, the embargo length exceeds the maximum allowed under the policy or the status of the item has not been established.

In the case depicted by the screen shot below, the deposited does not comply with the Open Access policy because it does not fully comply with the deposit rules. Clicking the “More” link provides a detailed account of what the rules are with regard to achieving compliance and by expanding the area under the heading “Data used to check compliance” it is clear that the Date of acceptance is missing.

[[File:hefce_tab_non_compliant.png|800px|thumb|none]]

Sometimes an output meets all the compliance criteria except that the full text is not OA, as an embargo has been placed on it. The screen shot below shows the 'clock' icon used to denote an item that will become compliante when the embargo is released.

In the screenshot, there is also an incomplete date (only year and month were specified) which generates a warning, as accurate compliance calculations need accurate dates to work from.

[[File:hefce_tab_will_become_compliant.png|800px|thumb|none]]

===Reporting===
The plugin offers two reporting options that provide an at-a-glance overview of the level of compliance in any one year. The first report category shows the compliance status of all relevant items (articles and conference proceedings) in a particular 12-month period. The second report category focuses on those items where one or more exceptions have been claimed.

In the example shown below, two of the five items in our test repository do not comply with the Open Access policy, resulting in a compliance score of 60% (3/5). Information is provided as to why the non-compliant records failed the tests.

[[File:reporting.png|800px|thumb|none]]

With the introduction of v2.0 of the Generic Reporting Framework plugin, new reporting options are available for REF CC. Custom reports may now be generated via a search config for either the standard report or the exceptions report, as shown in the screenshot below: 

[[File:reporting2.png|800px|thumb|none]]

The report exports have also been adapted to include fields relevant for determining REF compliance, along with RIOXX fields where available:

[[File:report_export.png|800px|thumb|none]]