5.6.05.6.0

• Read 'Open Access' metadata tags on Publisher PDFs
  • Publisher PDFs (Proofs, Versions of record, and in some cases Author Accepted Manuscripts) are starting to be produced with metadata tags that platforms can use to automatically detect certain OA properties. Where a user is uploading a file with such tags, Pure will populate the Document version and License to document, and derive the Public access to file, as per the properties embedded in the document.
  • Further information is available here (updated 16 June 2016)
• Improvements to SHERPA / RoMEO render
  • In response to feedback that SHERPA / RoMEO information on ‘Publisher’s Version / PDF’ was missing from the renders in Pure, we have now introduced this information, in addition to updating the render of SHERPA / RoMEO content to improve clarity, namely through more directly resembling the SHERPA / RoMEO website
  • In order for the improvements to take effect, the SHERPA / RoMEO Journal Synchronisation job must first be run
• Introduction of 'Proof' as a Document version type
  • Introducing ‘Proof’ as a Document version type brings us further in line with international standards (e.g. RIOXX, NISO), and enables us to take advantage of evolving initiatives to help users and institutions in ensuring compliance with Publisher policies on making content openly accessible (e.g. reading publisher PDF metadata tags).
  • The default version type name is 'Proof', with the description aligned with NISO's definition: 'Version created as part of publication process; publisher's layout; not normally made publicly available'
  • Note that this impacts on the logic employed to determine the Open Access status of the publication. An updated logic document is available here 
  • UK customers with the REF2020 module should also note that this impacts on the logic employed to determine the REF OA Compliance status. An updated logic document is available here 

Roles affected: Personal users, Editor and Administrator of Research Output, Administrator

Notes:

• The feature planned for accessing the ScienceDirect Article Hosting Permissions API in order to source embargo end dates and License to document for uploaded Accepted Author Manuscripts has had to be postponed due to unforeseen technical difficulties. We are still working on this feature and will include it in an upcoming release.

Create elsevier/atira users

• Elsevier support users can be created from the Administration module by accessing the Support tab in the Administrator workspace, and filling in the account details form found in the "Elsevier Support User creation" page
• The created users will have a special new role called 'Elsevier Support' that makes it easy to identify accounts created for support. The existing 'atira' account will also have this role.
• Note that only valid Elsevier mail addresses are supported. Further, the 'Switch user' function does not support switching to an Elsevier support user.

Database export

• To export your Pure database to Elsevier in a controlled fashion, a user with Administrator role should access the Administrator tab and select 'Support / Database export'. The dump will then be sent to Elsevier. 
• This feature provides several advantages over the previous database dump procedure, as it:
  • enables removal of sensitive data at the source (e.g. remove information like gender and date of birth before Elsevier receives the database dump)
  • provides a clear definition of the retention period, i.e. how long Elsevier will store the database dump, before deleting it
  • provides a clear indication of who requested the dump
  • no longer requires a database dump to be scheduled with the local database administration team

Adding PMID and PMCID to publications in Pure is configured in the job 'PubMed: Update PubMed/PubMedCentral IDs And Keywords', found in the 'Synchronisation with external systems' section of the job list of the administration tab. Outputs in Pure with a current publication date within the last 2 years, a DOI, and that do not already have a PMID or PMCID are matched with publications in PubMed and PMID and PMCID imported into the record in Pure.

When the job is added the following configurations should be considered:

• First run: By turning this on, ALL research outputs in Pure are checked once. Following this initial 'first run', only research outputs from the current or previous year (as per the publication date) will be checked. Following the running of the job with this setting on, the setting will automatically be turned back off.
• Overwrite existing: When this setting is turned on, all existing PMIDs and PMCIDs are overwritten if a match is found in PubMed.
• Add MeSH document types as keywords: When this setting is turned on, MeSH document types will be added as a keyword group to the matched research output in Pure. A list of the MeSH document types can be found here: https://www.nlm.nih.gov/mesh/pubtypes.html

• We have introduced two new elements of REF2 predicted grade functionality:   
  
  • Enable Personal users to view the predicted grades assigned to outputs proposed for REF2020
    • Is a configuration option, available in the REF2020 Settings (Enable predicted grades for REF2 to be visible to Personal users) (the setting is, by default, disabled)
    • This will be visible to Personal users, Editor of Persons, Administrator of Persons, and Administrator in the following locations:
      • Personal overview screen
      • Propose for Research outputs for REF2020 screen
      • Propose output screen
  • Introduce a new job that enables REF2 predicted grades to be imported in bulk - see the REF wiki for further details
    • Import predicted grades for existing REF2 records
    • Note this job only imports 'overall' predicted grades, not peer comments and predicted grades
• We have also delivered improvements to elements associated with REF Open Access compliance monitoring   
  
  • We believe that all bugs relating to the derivation of the REF Open Access compliance status are now resolved
  • In order to resolve the issue with Access date for files not updating when the accessibility properties of the file had been changed (e.g. from Open to Embargoed) (see Open Access compliance - Notes and issues CLOSED), we have introduced new functionality that enables specified users to 'Refresh' the system-generated Access date to reflect the updated accessibility properties. More information is available at Open Access compliance.
  • Upon upgrade, ensure you run the REF2020 : Generate OA Compliance Status for existing content job for the updated logic to be applied.
• We have delivered additional items in response to customer feedback:   
  
  • We have updated the REF2 navigation such that the landing page is the REF2 Summary screen, rather than the REF OA compliance tracking screen
  • We have improved REF2020 reporting (for example: enabling reporting on REF1a/c content when creating a REF2 report (available under Content > Person > Person, then select 'Click + to change default output'); introducing combined reporting functionality for Units of Assessment and REF1a/c)   
    

Roles affected: Personal Users, Editor of Persons, Administrator of Persons, Administrator, REF user roles

Notes:

• Note that the Enable predicted grades for REF2 to be visible to Personal users configuration can only be enabled if the Enable predicted grade and peer comments for REF2 configuration is enabled
  • (although in the Settings screen, if you try to enable the Enable predicted grades for REF2 to be visible to Personal users configuration while the Enable predicted grade and peer comments for REF2 configuration is disabled, it will appear as though it is enabled unless you navigate away and then return (when the configuration will be automatically disabled).

Further information: REF wiki

A new 'Researchmap' section has been added to the Administration tab, accessible to Administrator users. In the 'Researchmap' configuration screen, it is possible for the Administrator to generate and download a zip-file that can be uploaded to Researchmap.

In order to comply with Researchmap requirements, the following conditions must be met:

1. Researchmap Affiliation ID for the institution in question must be input in the 'Researchmap affiliation id' field in the Administrator configuration screen, and saved
2. Researchmap Researcher ID must have been added to the ID section of the Person profile in Pure for those persons that should have their researcher profile updated in Researchmap
3. Each researcher should have a translated (Japanese) name in the Name variant section of the person in Pure

Adding Researchmap researcher ID by using Master list data import

Researchmap researcher IDs can be added to Pure by uploading them via the Masterlist data import, where Researchmap Researcher IDs are added in the corresponding sheets and columns of the masterlist excel-file. To be specific, in the "Classifications" sheet, the uri for ClientID_2 must be specified as "researchmap", and in the "Persons" sheet the ClientID_2 should contain the Researchmap Researcher IDs.